On Sun, Jun 12, 2011 at 12:20 PM, Florian Fainelli <florian@xxxxxxxxxxx> wrote:
> On Wednesday 08 June 2011 09:15:14 Geert Uytterhoeven wrote:
>> On Wed, Jun 8, 2011 at 01:02, David VomLehn <dvomlehn@xxxxxxxxx> wrote:
>> > 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.
