From mboxrd@z Thu Jan  1 00:00:00 1970
From: Bernhard Nortmann <bernhard.nortmann@web.de>
Date: Sun, 5 Jun 2016 15:01:30 +0200
Subject: [U-Boot] [PATCH] sunxi: Add the ability to pass (script)
 filesize in the SPL header
In-Reply-To: <20160605144407.09c25a1c@i7>
References: <2a4fc4ba-9448-e871-460f-c5dc70ea1fc5@redhat.com>
 <1465060340-7209-1-git-send-email-bernhard.nortmann@web.de>
 <20160605144407.09c25a1c@i7>
Message-ID: <575422AA.5050505@web.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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