On Tue, Aug 6, 2013 at 1:22 PM, Dennis Gilmore dennis@ausil.us wrote: ...
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 the hardest part of whole chain to make it cross SoC (and cross Vendor SoC is even harder) as it needs to set pins and registers which vary from one to another. So even using DeviceTree there I am not aware of a way to make it to work for i.MX6 and Allwinner SoCs without using different binaries. You can certainly share the binary among different boards of same SoC (or SoC family) but across them I am not aware of it being possible.
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.
What Wolfgang is saying here is it will still be a single file but made in two steps. One U-Boot binary, another cluing the environment to it. ...
Regards,