-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 16 Aug 2013 12:14:45 -0400 Tom Rini <[email protected]> wrote:
> 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). 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. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlIOh+kACgkQkSxm47BaWfeppwCgjkK/gB6xwfVcwN1Sq+A8LMmN Ht8AnRjJAKOwPRVWHNBbuh+OgGtE4wpp =ww27 -----END PGP SIGNATURE----- _______________________________________________ cross-distro mailing list [email protected] http://lists.linaro.org/mailman/listinfo/cross-distro
