Hi,
On 11-09-15 11:31, Bernhard Nortmann wrote:
Hi!
Am 10.09.2015 um 20:36 schrieb Hans de Goede:
Hi,
I would prefer to have this like this:
"bootcmd_fel=" \
"if test -n ${fel_booted} && test -n ${fel_data_addr}; then " \
"echo '(FEL boot)';" \
"source ${fel_data_addr}; " \
"fi\0"
Sure, we could do that. I wanted to make clear that ${fel_booted} is
independent of a script being present (and thus ${fel_data_addr} set).
If the user feels inclined to do so, he might e.g. tweak bootcmd_fel
to override some defaults even with no boot.scr involved.
I think that an user advanced enough to do this can figure this out
anyways and the above is cleaner, so please switch to the above
construct for the next version.
Also if we are not using fel_data_size, then why do we even
have it ?
I thought it unnecessary to restrict ourselves to not being able to
pass the size information, and kept it optional deliberately.
Right, but by doing so you are taking our last reserved uint32, making
it unavailable for future use, I'm not sure if that is a good idea.
Admittedly it's pointless in the "standard" case of boot.scr, as that
is expected to be an image with a well-defined header (including data
size). I could imagine other uses, e.g. a customized fel utility
passing uEnv.txt-style data, and integrating that via bootcmd_fel
"import -t ${fel_data_addr} ${fel_data_size}". Personally I like to
do this when testing; I find it easier to simply edit a text file
(without having to go through a mkimage .scr on each cycle).
But your sunxi-tools patches depends on the header to detect that
a boot.scr is being loaded and set ${fel_data_addr} and ${fel_data_size}
in the spl header, so this requires hacking up things in both u-boot
and sunxi-tools. Given that this is already a pretty exotic use-case
I believe that the user having to have mkimage available (the calling
of it can be scripted away) is not a big deal.
I would rather see an as clean as possible solution focussing on just
the boot.scr use-case, as said that is exotic enough already to not
complicate things further.
Regards,
Hans
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
