-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 16 Aug 2013 12:14:45 -0400 Tom Rini trini@ti.com wrote:
On 08/16/2013 11:40 AM, Peter Robinson wrote:
On Thu, Aug 15, 2013 at 6:07 PM, Tom Rini trini@ti.com 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:
- 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.
- Standard environment variables telling me where that DTB is
located. Today this is often fdt_addr_r or fdt_addr.
- Standard environment variables telling me what a replacement
DTB would be named. Today ${soc}-${board} is almost reliable.
- 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).
my opinion is that any dtb loaded by the firmware should be loaded to fdt_addr its up to the vendor if they provide the dtb in non-volatile storage or they load from a known location i.e. local disk at /boot/dtb/<dtbfile> /dtb/<dtbfile> or they tftp load it from /dtb/<dtbfile> to me it is a must that u-boot load a dtb to fdt_addr
the user can override the vendors dtb by loading one to fdt_addr_r
while in the patch i sent upstream for u-boot fdt_addr and fdt_addr_r are different pointers to the same address, on further reflection they really should be separate.
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).
the answer is that we as distros will put the dtb files into a known location /boot/dtb/<dtbfile> or /dtb/<dtbfile> and u-boot will load them for us to fdt_addr. we could also support putting the dtb into some raw space where it could be loaded from also.
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.