All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ricky Ng-Adam <rngadam-Cdz4rsCscHxBDgjK7y7TUQ@public.gmane.org>
To: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
Cc: Shyu Lee <shyu.lee-Cdz4rsCscHxBDgjK7y7TUQ@public.gmane.org>
Subject: ATAG and DTB /chosen for kernel parameters
Date: Thu, 12 Jul 2012 21:09:09 +0800	[thread overview]
Message-ID: <CAOAMTYQRqXq+xu6d1Ph_hJqpuhVBo-2RwuDAn2FNFczKSitPiQ@mail.gmail.com> (raw)


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

                 reply	other threads:[~2012-07-12 13:09 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAOAMTYQRqXq+xu6d1Ph_hJqpuhVBo-2RwuDAn2FNFczKSitPiQ@mail.gmail.com \
    --to=rngadam-cdz4rscschxbdgjk7y7tuq@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=shyu.lee-Cdz4rsCscHxBDgjK7y7TUQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.