On Thu, 8 Aug 2013 11:26:37 -0400 Tom Rini <tr...@ti.com> wrote: > On Wed, Aug 07, 2013 at 06:04:23PM -0500, Dennis Gilmore wrote: > > On Wed, 7 Aug 2013 09:19:21 -0400 > > Tom Rini <tr...@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 <tr...@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).
I really don't want to ship environment files. If we need to we need one of a few things. either u-boot needs to ship them and they are in a directory with a name matching the dtb, or we need to have a bunch of variables provided that enable us to load everything supported by the u-boot binaries. We as distros have no business needing to deal with memory locations. it really is one of the biggest pain points with u-boot. Dennis _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
