Flattened Device Tree

[Rafal Jaworowski]

On 2010-01-21, at 17:38, Grant Likely wrote:

> Oops, originally bcc'd the mailing list instead of cc'd.  resend.
> 
> ---------- Forwarded message ----------
> 
> Hey Rafal,
> 
> A friend pointed this status update out to me on the FreeBSD mailing
> list.  I'm thrilled to see that you're making progress.

Hi Grant,
I'm glad you bring this up as I was about to ask a couple of questions on FDT for ARM, not actually about the boot i/f (mine are more bindings-related), but we can discuss that separately.

> I'm also working on adding Linux FDT support to the ARM architecture,
> and I think we need to coordinate.  Specifically, I'd like to agree on
> a common boot interface for FDT booting on ARM (and PowerPC for that
> matter).
> 
> For PowerPC, I assume you're adopting the boot interface specified in
> ePAPR and are using r3 to pass the FDT blob pointer (page 53 of
> ePAPR).  Correct?
> 
> What are you using for the ARM boot interface?  For the experiments
> performed to date, the dtb is getting passed to the kernel in a new
> ATAG, but I thing ATAGs are Linux specific.  Ideally, I'd like to have

We are a bit different. For both ARM and PowerPC platforms we're initially bringing FDT for, we have full FreeBSD booting environment which means using the native loader(8) -- it is the last stage boot loader running on top of BIOS/U-Boot/whatever. loader(8) from end-user perspective has uniform touch and feel accross various architectures FreeBSD supports, and it's main goal is loading kernel, preparing environment for it, setting flags, loading dynamic modules (yes, before kernel is run) and so on. All these supplementary items for the kernel are called metadata, and the kernel is provided with the metadata pointer when executed. Now, for FDT-oriented platforms, in the presence of loader(8) the DT blob is just part of our metadata. You can see a couple of use examples here: http://wiki.freebsd.org/FlattenedDeviceTree/loader

However, there are many embedded platforms, where loader(8) cannot be run or is undesired. For these we'll need to have a way to embed the DTB somehow with the kernel, although this is rather the problem of a wrapper technique much like there's a couple of approaches in Linux right now.

> exactly one method of passing the dtb to the kernel, and I don't see
> any good reason for Linux, FreeBSD, or any other OS to use different
> methods.  However, I also don't want to break booting older operating
> system images that don't support FDT.  The ATAG approach is nice for
> Linux because it just adds an additional data item in a backwards
> compatible way.
> 
> Thoughts?


As you can observe, we could mostly get away from these kind of questions so far :-) In general I'm all for having a unified convention for ARM FDT, but am not familiar with ATAG too closely, so I need to dig into it first. 

Rafal