ATAG and DTB /chosen for kernel parameters

Ricky Ng-Adam rngadam at lophilo.com
Thu Jul 12 23:09:09 EST 2012


Hello all!

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.

What we are planning to do:

   - generate the machine dtb from dts and stored on the machine persistent
   storage (not linked to kernel to facilitate updates)
   - build a zImage stored on the machine persistent storage with generic
   AT91 DT support
   - create a text file containing kernel parameters on machine persistent
   storage
   - custom bootloader starts on machine
      - load zImage from machine storage into memory
      - load dtb from machine storage into memory
      - set ATAGs, including kernel parameters from text file
      - pass location of loaded DTB using ATAG
      - boot kernel
      - kernel creates devicetree from DTB

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.

This option in the kernel is tantalizing:

CONFIG_ARM_ATAG_DTB_COMPAT:


   Some old bootloaders can't be updated to a DTB capable one, yet
   they provide ATAGs with memory configuration, the ramdisk address,
   the kernel cmdline string, etc.  Such information is dynamically
   provided by the bootloader and can't always be stored in a static
   DTB.  To allow a device tree enabled kernel to be used with such
   bootloaders, this option allows zImage to extract the information
   from the ATAG list and store it at run time into the appended DTB.

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.

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).

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.

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...

On the subject of ATAG and DTB, All I could find so far is this long and
contentious discussion from a year ago:

https://lists.ozlabs.org/pipermail/devicetree-discuss/2011-June/thread.html#5880

What's the current consensus? Should we stick with CONFIG_ARM_APPENDED_DTB
and CONFIG_ARM_ATAG_DTB_COMPAT?

Thank you for your help! Sorry if I sound a bit confused, this is all new
to me.
-- 
伍思力 | Ricky Ng-Adam | Lophilo Ltd | http://lophilo.com | (+86)186-2126-2521
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/devicetree-discuss/attachments/20120712/0fd7a024/attachment.html>


More information about the devicetree-discuss mailing list