On Tue, 06 Aug 2013 13:37:51 +0200 Wolfgang Denk <w...@denx.de> wrote:
> Dear Rob Herring, > > In message > <CAL_JsqJTg4CVfk0o9hLd4ZVksj+DNEsKLjcv6T7-6F-=br+...@mail.gmail.com> > you wrote: > > > > > Why would you ever want to compile this into U-Boot at all? Then > > > any changes you need to make mean compiling and installing a new > > > U-Boot, which is something you normally don't want to do. > > > > You may want to have factory default and "user" settings. Building > > in the factory settings would be one way to accomplish that. > > No. Handling these independently, outside of the compiled U-Boot image > is as easy, and much more flexible. How exactly should it be handled outside of the compiled u-boot image. with my distro hat on, I honesty do not want to deal with u-boot at all. The limit of my dealing with u-boot will be to run a script that installs the u-boot binary onto disk for those systems that don't have it in nand/nor/spi etc flash storage. In my mind you are talking about some file I need to write to disk that gets loaded at boot time. the problem with this is its not flexible nor portable. I honestly think one of the worst thing hardware vendors ever did was to ship hardware that doesn't have anywhere built into it to load and run u-boot from. My issue with this is, we produce a unified image, it could be an installer image or a installed disk image. it has a unified kernel in it and can run on any number of soc's but we also need to provide tooling that will setup the u-boot image so that it can be loaded by different boards. be it copying files into place or dding the binary into some offset. it kills the portability. i can't pull a sdcard from one board with one type of soc and plug it into another and have it just boot. > > > U-Boot is perfectly able to import such settings from text files > > > (or text blobs stored somewhere, even attached to the U-Boot > > > image, if you want), so just use the text files separately, > > > instead of hard compiling them into the code. > > > > In my case, I don't want to compile the environment into u-boot. But > > some people do as I copied my scripts from Tegra which has them > > built-in. Since built-in is C and standalone is text file, sharing > > is impossible. That is the main thing I'd like to see changed. > > Whether we support merging builtin and standalone envs is secondary. > > Who says "impossible" here? When using a file system with write > support, you can use "env export -t" to create a text representation > and write it out to the file system (or store it in some reserved area > on some storage device). Exactly what i want to avoid. I really do want it compiled into the binary. because then I only have to put one file into place. on those systems needing it. another solution for me would be a unified u-boot that runs on all soc's and all boards. Everytime we have to do something different for a board or soc family is a step away from having something truly universal and portable. 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 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 Dennis _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
