From mboxrd@z Thu Jan 1 00:00:00 1970 From: grant.likely@secretlab.ca (Grant Likely) Date: Thu, 3 Jun 2010 15:12:17 -0600 Subject: Boot interface for device trees on ARM In-Reply-To: References: <201005181054.32325.jeremy.kerr@canonical.com> <20100519200819.GF1693@shareable.org> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Fri, May 21, 2010 at 10:24 AM, John Rigby 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 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.