Hi Siarhei!
Am 05.06.2016 um 13:44 schrieb Siarhei Siamashka:
Hello Bernhard,
[...] How does this work in general with "boot.scr" and "uEnv.txt" use cases? Could you provide a bit more detailed description?
I mean, who is going to do "import -t ${fel_script_addr} ${filesize}" invocation?
This particular FEL feature in the SPL header is used to allow running a boot script provided by the user (boot.scr). Without it, we only have the default U-Boot environment. And the default U-Boot environment does not have the "import -t ${fel_script_addr} ${filesize}" statement yet. This looks a bit like a chicken/egg problem or am I missing something?
No, you're right and not missing anything. Setting ${filesize} alone doesn't achieve much, and would require further customization to do the actual import. Since this whole idea of having the script length didn't go down too well when I initially proposed it (back in September 2015), I stayed away from adding additional U-Boot modifications this time.
One approach would be to have a modified "bootcmd_fel" that either tests for a non-empty ${filesize}, or tries to import the script data as a fallback ("source ${fel_scriptaddr} || import -t <...>;"). Another way is to always assume "uEnv.txt style" whenever fel_script_length is set, and do a himport_r() of the script data right away (the programmatic equivalent of "import -t"). I'm doing this in an experimental branch of mine, as it allows overriding everything from the default environment - including the "bootcmd" itself.
Of course, all of this also requires support from the sunxi-fel side of things (i.e. fel_script_length getting set in the first place). A quick-and-dirty solution I'm currently using is to assume a uEnv.txt script (and set fel_script_length) whenever sunxi-fel detects uploads of pure ASCII data. This could also be done easily with a dedicated command, and I can even image sunxi-fel building the uEnv.txt string itself from given ("env") key/value pairs.
I have no real opinion about this, but "filesize" looks like a rather generic name for this environment variable. Are there some advantages/disadvantages picking this particular name instead of something like "fel_scriptsize"?
Well... this _is_ the generic name that U-Boot itself tends to use for data transfers. E.g. "load" or "tftp" commands set the ${filesize} too.
That said, I have no objections to supporting "uEnv.txt" for FEL boot, as long as it works correctly and does not regress the existing "boot.scr" support.
Our sunxi-fel utility is already testing for the script.bin format and can preserve the existing functionality by simply forcing fel_script_length to 0 in that case. And additional safeguards might be placed before "actively" setting that value to anything non-zero.
Regards, B. Nortmann