On 08/16/2013 11:40 AM, Peter Robinson wrote: > On Thu, Aug 15, 2013 at 6:07 PM, Tom Rini <[email protected]> wrote: >> On 08/15/2013 12:02 PM, Brendan Conoboy wrote: >>> On 08/14/2013 05:37 PM, Nicolas Pitre wrote: >>>> Using /boot implies a distro filesystem and we'd rather wish for DT to >>>> be independent from a distro or even Linux. The DTB should therefore be >>>> stored and accessed in a way which is hardware/bootloader specific. The >>>> distro being installed on top shouldn't have to care. >>> >>> Yes. As a distro provider I would like to see the following from >>> uBoot-using hardware: >>> >>> 1. Every device ships with a DTB embedded in non-volatile storage. >>> Basically, if it ships with uBoot it includes a device tree sufficiently >>> accurate to boot a kernel configured to support the SoC. >>> >>> 2. Standard environment variables telling me where that DTB is located. >>> Today this is often fdt_addr_r or fdt_addr. >>> >>> 3. Standard environment variables telling me what a replacement DTB >>> would be named. Today ${soc}-${board} is almost reliable. >>> >>> 4. A method by which to update the DTB stored in nonvolatile memory >>> without updating uBoot itself. This could be done via management >>> controller or within u-boot (Again, using the variables from 2 and 3 >>> above). >>> >>> The core idea is that the device provide all the information necessary >>> to boot the device. In the event that information becomes inaccurate >>> relative to the needs of later kernels there needs to be a way to update >>> that information, either per-boot or permanently. >> >> What I don't see above is something about loading the full DTB from >> non-volatile storage and into memory. > > I believe he alluded to that in section 2 in the standard location to > load it from.
Being nit-picky since it's important for this to be clear (as we're talking about things that will be done by people just reading this later), section 2 is a location in memory. fdt_addr_r is where "device tree coming from somewhere will now reside in memory at this location" and "fdt_addr" is "a device tree currently lives in memory at this location". Arguably, if we expect firmware/bootloader to know where a device tree is (because it came with the hardware) it should load it to fdt_addr, and fdt_addr_r is for a user-specified (in their extlinux.conf or whatever) tree, rather than how it's often used today (fdtaddr or fdt_addr or fdt_addr_r all around, with very few using both fdt_addr and fdt_addr_r). >> The only problem I see is you're not dealing with platforms that don't >> include non-volatile storage on the board itself (Beaglebone White, >> Pandaboard, RPi, Allwinner boards without eMMC/NAND, etc). Or are you >> including somehow stored on SD card in the list? > > In this case for Fedora at least we're shipping our own built binaries > with the options we need. If upstream uboot includes the dtbs as part > of the uboot we'd likely build them as part of the the various uboots > we ship but in the interim we're using the ones we ship with the > kernel. I'm sorry, but I don't see the answer to my question here. The long term plan is that DTs are not bundled with the kernel nor with U-Boot but live on their own. So I guess I'm thinking / asking, is a file in the SD card good enough for the non-volatile storage side of things (and U-Boot looks for, loads the 'master' DT into fdt_addr and then user/distro can override into fdt_addr_r however they like). > Ultimately a DT shipped within a firmware will some what depend on the > DT being abi stable so that people know that it should always be able > to boot with the shipped DT no matter what the kernel is even if the > ABI is extended with time. Agreed. -- Tom _______________________________________________ cross-distro mailing list [email protected] http://lists.linaro.org/mailman/listinfo/cross-distro
