All of lore.kernel.org
 help / color / mirror / Atom feed
* ATAG and DTB /chosen for kernel parameters
@ 2012-07-12 13:09 Ricky Ng-Adam
  0 siblings, 0 replies; only message in thread
From: Ricky Ng-Adam @ 2012-07-12 13:09 UTC (permalink / raw)
  To: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ; +Cc: Shyu Lee


[-- Attachment #1.1: Type: text/plain, Size: 3015 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 4350 bytes --]

[-- Attachment #2: Type: text/plain, Size: 192 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2012-07-12 13:09 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-07-12 13:09 ATAG and DTB /chosen for kernel parameters Ricky Ng-Adam

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.