<div>Hello all!</div><div><br></div><div>We're building a new machine derived from MACH_AT91SAM9M10G45EK. As it is very similar, we'd prefer to use DeviceTree, especially as we have slightly different revisions already.</div>
<div><br></div><div>What we are planning to do:</div>
<div><ul><li>generate the machine dtb from dts and stored on the machine persistent storage (not linked to kernel to facilitate updates)</li><li>build a zImage stored on the machine persistent storage with generic AT91 DT support</li>
<li>create a text file containing kernel parameters on machine persistent storage</li>
<li>custom bootloader starts on machine</li><ul><li>load zImage from machine storage into memory</li><li>load dtb from machine storage into memory</li><li>set ATAGs, including kernel parameters from text file</li>
<li>pass location of loaded DTB using ATAG</li><li>boot kernel</li><li>kernel creates devicetree from DTB</li></ul></ul></div><div>We prefer ATAG as this is how we specify the kernel parameters line sourced from a text file on the local storage. It's simple and it works.</div>
<div><br></div><div><div>This option in the kernel is tantalizing:</div><div><br></div><div><font face="'courier new', monospace">CONFIG_ARM_ATAG_DTB_COMPAT:</font></div><div><font face="'courier new', monospace">                                                                                                              </font></div>
<div><font face="'courier new', monospace">   Some old bootloaders can't be updated to a DTB capable one, yet</font></div><div><font face="'courier new', monospace">   they provide ATAGs with memory configuration, the ramdisk address,</font></div>
<div><font face="'courier new', monospace">   the kernel cmdline string, etc.  Such information is dynamically</font></div><div><font face="'courier new', monospace">   provided by the bootloader and can't always be stored in a static</font></div>
<div><font face="'courier new', monospace">   DTB.  To allow a device tree enabled kernel to be used with such</font></div><div><font face="'courier new', monospace">   bootloaders, this option allows zImage to extract the information</font></div>
<div><font face="'courier new', monospace">   from the ATAG list and store it at run time into the appended DTB.</font></div></div><div><br></div><div>However, it is only enabled if CONFIG_ARM_APPENDED_DTB is on. This is reflected in arch/arm/boot/compressed/head.S with one being a #ifdef inside the other. The magic seems to happen in a call to arch/arm/boot/compressed/atags_to_fdt.c for the conversion.</div>
<div><br></div><div>As we've explained above, we'd rather load DTB to RAM independently and pass the location using something like ATAG_DEVTREE (I've seen patches for adding this ATAG floating around).</div><div>
<br></div><div>The only alternative I found is the r2 mechanism from the current kernel document (Documentation/platform/booting-without-of.txt) where it seems to be either ATAG *OR* DTB.</div><div><br></div><div>Would adding ATAG_DEVTREE and making it work with CONFIG_ARM_ATAG_DTB_COMPAT be a valid approach?  I'd imagine parsing the ATAG and then applying the code from atags_to_fdt to it. I'm not sure why this conversion call is early in the assembly right now instead of in arch/arm/kernel/devtree.c:setup_machine_fdt...</div>
<div><br></div><div>On the subject of ATAG and DTB, All I could find so far is this long and contentious discussion from a year ago: </div><div><br></div><div><a href="https://lists.ozlabs.org/pipermail/devicetree-discuss/2011-June/thread.html#5880">https://lists.ozlabs.org/pipermail/devicetree-discuss/2011-June/thread.html#5880</a></div>
<div><br></div><div>What's the current consensus? Should we stick with CONFIG_ARM_APPENDED_DTB and CONFIG_ARM_ATAG_DTB_COMPAT?</div><div><br></div><div>Thank you for your help! Sorry if I sound a bit confused, this is all new to me.</div>
-- <br>伍思力 | Ricky Ng-Adam | Lophilo Ltd | <a href="http://lophilo.com" target="_blank">http://lophilo.com</a> | <a href="tel:%28%2B86%29186-2126-2521" value="+8618621262521" target="_blank">(+86)186-2126-2521</a><br>