On Wed, Aug 07, 2013 at 06:04:23PM -0500, Dennis Gilmore wrote:
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]
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.
Right. For clarity, the problem is that DTs aren't useful like that. They describe the hardware, but in non-generic terms.
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
I'd like to see the file come from the distro. And given that another option here is 'go'ing to a copy of GRUB, I think we've got at least a good chance of future expansion being handled OK with this method. We try and load something from the distro that is generic, and make the hand-off there. (In the GRUB example, we just need to make sure we have a standard name for the standalone app load address).