On Thu, Jan 21, 2010 at 1:58 PM, Rafal Jaworowski <[email protected]> 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. _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
