On Tue, 06 Aug 2013 13:37:51 +0200 Wolfgang Denk wd@denx.de wrote:
Dear Rob Herring,
In message CAL_JsqJTg4CVfk0o9hLd4ZVksj+DNEsKLjcv6T7-6F-=BR+J+Q@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