On Sun, Jun 12, 2011 at 12:20 PM, Florian Fainelli [off-list ref] wrote:

On Wednesday 08 June 2011 09:15:14 Geert Uytterhoeven wrote:

quoted

On Wed, Jun 8, 2011 at 01:02, David VomLehn [off-list ref] wrote:

quoted

I took a look at the issue of passing device trees to the kernel and
started by surveying the methods currently in use for passing
information from the bootloader to the kernel. I came up with the ten
approaches:

How MIPS Bootloaders Pass Information to the Kernel
---------------------------------------------------
Apologies for any errors; this was meant more to be a quick survey
rather than a detailed analysis.

6.      a0 - argc
       a1 - argv
       a2 - non-standard envp
       Command line created by concatenating argv strings, starting at
       argv[1]. The envp is a pointer to a list of char ptr to name/char
       ptr pairs.
       Platforms: txx9

This depends on the actual boot loader. My rbtx4927 has a VxWorks boot
loader, which just doesn't pass anything.

Cfr. commit 97b0511ce125b0cb95d73b198c1bdbb3cebc4de2 ("MIPS: TXx9:
Make firmware parameter passing more robust").

Thinking about this more, on platforms for which we do not have control about
the bootloader, we can usually still get it to boot a wrapper. Such a wrapper
could do the following:

- embedd the kernel
- embedd the appropriate dtb
- copy the relevant a0-a3 values and pass to the kernel a pointer to the valid
dtb in the aX register

such a wrapper already exists, which is the code responsible for decompressing
the kernel in arch/mips/boot/compressed.

If we want to support multiple flavors of the same SoC, using the same kernel
image, we only need to relink the boot wrapper with the correct dtb (and
kernel of course).

I'm definitely in favour of this approach (passing the dtb via a
register) instead of passing it via the command line or something
similar.

What strikes me about this debate (aside from the fact that it is the
same debate we had on other architectures when DT was adopted) is that
it seems to be focused on "here are all the different things all the
MIPS platforms are doing now, so how can each of them be modified to
graft in DT support".  However, switching to DT is absolutely a new
boot interface, regardless of how you cut it (or how the dtb address
gets passed).  Since this is something new, I *strongly* recommend
using the opportunity to standardize on a single boot interface when
passing a DT, and it does *not* have to be the same as any of the
existing interfaces.  By having only a single interface into the
kernel, it eliminates any questions about which data the kernel should
use as authoritative (which data takes precidence, legacy or DT), and
you can get away from per-platform interface quirrks.  Firmware needs
to be modified regardless to take advantage full advantage of DT, so
you may as well make them all change to use the same thing.

For firmware that does not, or can not be modified (like deployed
firmware), the zImage wrapper is the ideal place to translate old
firmware data into a DT representation.

On ARM, the kernel can be passed either an ATAGs list (legacy
interface), or a DTB, and because of the signature on the data
structures it can detect which interface it should be using.
On PowerPC, we straight out dropped all the old boot interfaces from
the kernel proper, and we use the zImage wrapper to inject data from
old firmware interfaces into the DT at boot time (linked into the
wrapper)

g.