-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/16/2013 04:13 PM, Dennis Gilmore wrote: > 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.
I agree as well. >>>> 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. I would say whatever we get from the user (be it distro or individual) goes to fdt_addr_r and fdt_addr is for the provided dtb. And I would punt the logic of finding it from where to the distro-created but still board-agnostic boot whatever-you-wish-to-call it. - -- Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSElChAAoJENk4IS6UOR1WIZwP/04RPCKD1NCXOg0DF6WY1SPH +aOmeux+7c/TZD7jnWUNi5ZgocLDP0w1xFFMQMU0qa4+q00N7qDm35qd5llOWZJX SEXE3S1t4DvQkp42l9mbJ0gg9L48JjE0FX7tTFUUojo0yIO41ZJ6X/SbSQX2hjj/ hePlC/isD/3mVj7HxsZ92vmlFwZqHZFVhCJv8hmWqQA8AWvXJD+eEwvEJLuHpscZ Vp4a4xYGMmfyY6Q7l9b0gOiRjrEei9P/bLx5Q11w/+KDjedtdT68+dSKOKgJol+Y mEq9B+aLUMHOIyNsBzzbNMS7q36d0CG7FNrg6Q7MUijU/vdCTaUGsANzuMYhrYZz g0rqAxeIdUWhF0sx1UF/9yLv6CDWuFLHVHdAeF/kW+DlbVRqDeLpI0DqoJQQcIXH PDGqYtrmk6aLOpFbgSrRSFAAw1ukYMSh328R4TGi9i5DQguDblSTVPQY+pG77MQM klwpJ8udCXYSfT9PlKdYvg5gYPHoMYivmw1uiKem9W/IQ/AGas3QJ3wDqJeBYxCq KtUsFZ9U/A8a59pw7zUGxqNXCzvqBosb4jtlOjaWdQ8rH0nrpxI5QcviUIK/DDjn QJLifcJ7RJOBz0IYCKTsRPP3KAC2CRFh37hwrSMCWPhvmqGXS/whKvKJn0R/3oMe zSj514eAv7esZ8rzx8NR =akEH -----END PGP SIGNATURE----- _______________________________________________ cross-distro mailing list [email protected] http://lists.linaro.org/mailman/listinfo/cross-distro
