Boot interface for device trees on ARM

[Grant Likely]

On Fri, May 21, 2010 at 10:24 AM, John Rigby <jcrigby at gmail.com> wrote:
> Wow, no responses for almost two days, does that mean consensus has
> been reached?

No, it just means the merge window was open; not to mention the UDS hangover.

g.

>
> On Wed, May 19, 2010 at 2:22 PM, Nicolas Pitre <nico at fluxnic.net> wrote:
>> On Wed, 19 May 2010, Jamie Lokier wrote:
>>
>>> Nicolas Pitre wrote:
>>> > It is not up to the bootloader to "adjust" to the kernel.  But rather
>>> > for the kernel to cope with the bootloader's provided information.  If
>>> > the bootloader passes a specific machine ID with the ATAG list then the
>>> > kernel will use that, and if the bootloader passes a DT machine ID with
>>> > a DT blob then the kernel will use that.  You just have to configure
>>> > your kernel with both "machine types" at the same time.
>>>
>>> Scenario:
>>>
>>> You upgrade your systems to a new DT-capable kernel and DT-capable
>>> bootloader.  It works great.  You ship new instances of your device with this.
>>>
>>> Once they're in the field, someone reports a bug that doesn't happen
>>> with the older device instances.  It's not a bug you can reproduce,
>>> but you suspect the newer of kernel.  So you remote-update some of the
>>> newly shipped devices with an old, pre-DT kernel binary that's been
>>> stable on the older devices, to see if the bug goes away.
>>>
>>> Problem: The newer shipped devices have a DT-capable bootloader, and
>>> it can't boot old kernels, because they don't understand the DT format.
>>>
>>> You could remote-downgrade the bootloaders, but that's risky.  You
>>> could try building the old kernel with DT support, but that adds
>>> another variable to your testing.
>>>
>>> Anticipating this well in advance, you of course built your DT-capable
>>> bootloader with the ability to boot old and new style kernels...
>>
>> Exact.  Quoting myself:
>>
>> |I think that, for the moment, it is best if the bootloader on already
>> |existing subarchitectures where DT is introduced still preserve the
>> |already existing ability to boot using ATAGs.  This allows for the
>> |testing and validation of the DT concept against the legacy ATAG method
>> |more easily.
>> |
>> |On new subarchitectures, it might make sense to go with DT from the
>> |start instead of creating setup code for every single machine.  In that
>> |case the bootloader for those machines would only need to care about DT
>> |and forget about ATAGs.
>>
>>
>> Nicolas
>> _______________________________________________
>> devicetree-discuss mailing list
>> devicetree-discuss at lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/devicetree-discuss
>>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.