Flattened Device Tree

Flattened Device Tree

[Grant Likely]

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.

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

g.

> ---------- Forwarded message ----------
> Flattened Device Tree for embedded FreeBSD
>    URL: http://wiki.FreeBSD.org/FlattenedDeviceTree
>    URL:
>    http://p4db.FreeBSD.org/changeList.cgi?FSPC=//depot/projects/fdt/...
>    Contact: Rafal Jaworowski <raj-nYOzD4b6Jr9Wk0Htik3J/w@public.gmane.org>
>    The purpose of this project is to provide FreeBSD with support for the
>    Flattened Device Tree (FDT) technology, the mechanism for describing
>    computer hardware resources, which cannot be probed or self enumerated,
>    in a uniform and portable way. The primary consumers of this technology
>    are embedded FreeBSD platforms (ARM, AVR32, MIPS, PowerPC), where a lot
>    of designs are based on similar chips but have different assignment of
>    pins, memory layout, addresses bindings, interrupts routing and other
>    resources.
>    Current state highlights:
>      * Environment, supported tools
>           + Integrated device tree compiler (dtc) and libfdt into FreeBSD
>             userspace, kernel and loader build
>      * loader(8)
>           + Full support for device tree blob handling
>           + Load, traverse, modify (including add/remove) device tree
>             nodes and properties
>           + Pass the device tree blob to the kernel
>           + Both ARM and PowerPC loader(8) supported
>      * Kernel side FDT support (common)
>           + Developed OF interface for FDT-backed platforms
>           + ofw_bus I/F (and /dev/openfirm) available with FDT
>           + Integrated FDT resources representation with newbus (fdtbus
>             and simplebus drivers)
>      * PowerPC kernel (Freescale MPC85XX SOC)
>           + MPC8555CDS and MPC8572DS successfully converted to FDT
>             conventions
>      * ARM kernel (Marvell Orion, Kirkwood and Discovery SOC)
>           + Work in progress on integrating FDT infrastructure with ARM
>             platform code
>    Work on this project has been sponsored by the FreeBSD Foundation.
> Open tasks:
>     1. Complete missing pieces for PowerPC (PCI bridge driver conversion
>        to FDT).
>     2. Complete ARM support.
>     3. Merge to SVN.


--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: 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.f
 reebsd.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

Re: Flattened Device Tree

[Grant Likely]

On Thu, Jan 21, 2010 at 1:58 PM, Rafal Jaworowski <raj-nYOzD4b6Jr9Wk0Htik3J/w@public.gmane.org> wrote:
>
> On 2010-01-21, at 17:38, Grant Likely wrote:
> 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

It sounds like the loader-->freebsd interface is pretty much
effectively a freebsd internal thing.  Is loader ever expected to boot
anything outside of FreeBSD?  This says to me that the interesting bit
as far as boot interface is the method that a dtb gets handed from
firmware to the loader.  How the loader interacts with the FreeBSD
kernel has little bearing.

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

Even in this case I could still see it being useful to have a
standardized method for firmware to pass a dtb blob to the kernel or
the kernel wrapper.

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

ATAGs are a simple list of data values passed to the kernel via r2.  see here:

http://www.arm.linux.org.uk/developer/booting

ATAGs were designed well before the fdt, and the fdt certainly
supersedes them in terms of functionality, but they have the advantage
of being trivial to implement and already widely in use.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.