On Wed, 7 Aug 2013 09:19:21 -0400 Tom Rini trini@ti.com wrote:
On Tue, Aug 06, 2013 at 06:11:25PM -0500, Dennis Gilmore wrote:
On Tue, 6 Aug 2013 17:42:31 -0400 Tom Rini trini@ti.com wrote:
On Tue, Aug 06, 2013 at 11:22:22AM -0500, Dennis Gilmore wrote:
[snip]
The only way I could see having us write a file to disk with the environment working is if all boards implement standard variable to define the memory locations and that is compiled into the u-boot binary.
some variables that would need to be compiled in
fdt_addr fdt_addr_r
Why two?
from cmd_pxe.c
[snip]
u-boot by default would load a dtb to fdt_addr but a user could at least in the pxe/extlinux case load their own dtb if the want/need to.
the only way a dtb would be optional is if fdtfile is not set
OK, so fdt_addr is for a memory-mapped location of the DT existing somewhere already, basically.
right, how that gets there would be up to the vendor. but distros should put dtbs in a known place so that they can pulled from there.
kernel_addr_r ramdisk_addr_r pxefile_addr_r scr_addr_r uenv_addr_r
this should allow for for people to use boot.scr uEnv.txt or pxe/extlinux
This is what I think we need to work towards. A board opting into this standard must set CONFIG_CMD_A/B/C (or maybe we add a CONFIG_SUPPORT_GENERIC_LINUX_DISTRO that does this in one of the fallback files, whatever) and provide the following variables PLUS a, and this needs some thinking I think, auto-boot tries to load said file from ... ?
We cannot provide a built-in environment that works for every distro and case, we want the distro to tell us things it knows, and we'll tell it what it can't easily know.
we absolutely can, I would like for u-boot to load a dtb before doing anything. u-boot should know what devices can be booted from and likely an order of preference. i.e. removable media through to fixed, and finally pxe.
Looking at a couple of device trees, no, we can't. I don't see any useful information like "this is an SD controller" for example (and all of the mmc bindings that might provide a reliable clue are optional ones). So, at the high level, if U-Boot relied on DTs in every driver, we might be able to do what you're talking about. But we don't do that today, and probably won't for a long time, if ever.
But we will know what devices are likely to exist and be bootable, at build time. What we can do is try and load a file from everywhere we expect might be someplace with this file in it. We could even set some standard variables based on having found and loaded this file, so it can assume that everything else exists in this same place (or the file we have loaded knows better).
I was thinking more along the lines of us knowing what is likely to be there than pulling it from the DT and basically doing something like you mentioned here.
i would like for u-boot to first try to load /boot/extlinux/extlinux.conf then /extlinux/extlinux.conf failing that try to load a /boot/uEnv.txt then /uEnv.txt and import that running with what is in it, then falling back to a /boot/boot.scr then /boot.scr then finally running dhcp, pxe get, and pxe boot.
I'd like to see most of that logic held in the file we load (so that when something replaces extlinux.conf as the preferred method, it just works still, or whatever) and run a command from. And fall back to dhcp+pxe for the install case.
where should the file we load come from? i would think when something comes along to replace extlinux.conf its likely going to need an updated u-boot to add some new functionality
Dennis