Hi,
On 31-08-15 13:45, Siarhei Siamashka wrote:
On Tue, 07 Jul 2015 10:54:36 +0100
Ian Campbell <[email protected]> wrote:
On Tue, 2015-07-07 at 11:19 +0200, Hans de Goede wrote:
We could agree upon a special magic signature between the fel tool
and the sunxi u-boot code which means that u-boot should patch
its boot_cmd in the env to load a script from DRAM (at a fixed
offset).
Having mangled the header could we also find/define a field for the DRAM
address?
Perhaps rather than patching the boot_cmd we could instead have this
early code set a flag (in the env) which the normal bootcmd could check
(first) as part of the normal series of attempts to boot from various
sources? That would let the user configure it via the env if they
wanted.
In the IRC chat a few days ago, I promised to Bernhard to post some
ideas to the mailing list regarding 'boot.scr' handling by the 'fel'
tool. And it seems like it's best to pick up this discussion.
Right now the 'mksunxiboot' tool creates 32 bytes header in the
beginning of the SPL. This header size can be always extended if
necessary by changing the first branch instruction. Only the first
20 bytes are used currently. And the 12 byte padding block at the
offset 0x14 is currently filled with garbage (which typically ends
up being zeros in real SPL files, but we can't rely on this):
http://git.denx.de/?p=u-boot.git;a=blob;f=tools/mksunxiboot.c;h=3361251c8e7fffcb4ccbc3e29eb5e2e956608b0c#l19
In the boot0 binary, the offset 0x14 contains the 'pub_head_size'
field, which is a 32-bit integer:
https://github.com/linux-sunxi/sunxi-tools/blob/v1.2/bootinfo.c#L38
In order to easily distinguish between boot0 and U-Boot SPL, some sort
of a 32-bit magic value can be placed by the mksunxiboot tool at the
offset 0x14. Because the 'pub_head_size' value in boot0 can't be large
(we can't reasonably expect it to be larger than the limit imposed
by the SRAM size), the high 16 bits of 'pub_head_size' are expected
to be zero. So the high 16 bits of the word at 0x14 can be used for
identification. It is a good idea to also implement some kind of
versioning scheme (in the lower 16 bites?) in order to allow future
extensions. The rest of the header should be explicitly cleared
instead of writing garbage there.
Now on the 'fel' tool side. If the 'fel' tool recognizes the U-Boot
SPL magic at the offset 0x14, then it knows that there are 8 bytes
of storage space at 0x18 (initilized to 0 by mksunxiboot).
And when handling the command line parsing, just like it is recognizing
the main U-Boot binary format now, the 'fel' tool can easily recognize
the format of the 'boot.scr' blob when it is written to some arbitrary
location in DRAM via the 'write' command. If it detects the boot.scr
format, then the address of the loaded boot.scr can be stored at the
offset 0x18 in the header. And instead of abusing the "write" command
functionality, we can alternatively introduce a new one, but this is
a minor detail.
Now when U-Boot is running, the 'misc_init_r' function can check if
the value at the address 0x18 is non-zero, then set something like
'fel_scriptaddr' or 'ram_scriptaddr' variable in the environment.
And this variable can be later checked and used by bootcmd from the
default environment.
I think having the ability for a fel-loaded u-boot to automatically
execute a fel-loaded boot.scr from its default environment, and to
only do so when fel loaded and not do so in other cases is a good idea.
As for the actual implementation I've no preference.
Regarding the custom user-saved environment. When booting over USB, we
don't transfer the environment blob to the device and have no way to
save it over USB back to the PC. Picking the environment from the SD
card is not a great idea in the FEL mode (this can lead to unexpected
surprises), and we probably want to make sure to suppress this somehow.
With the upcoming / wip nand support this is already a problem, since
I want to have a single/unified build for both mmc and nand booting.
The plan here is to teach (add code for) u-boot to dynamically select
where the environment comes from. This will basically mean calling
spl_boot_device() not only from the spl but also in u-boot itself,
and then based on the answer load the env from either mmc or nand,
or in the case it returns BOOT_DEVICE_BOARD, not load any env at all.
This should solve the problem with fel + env more or less for free.
Regards,
Hans
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
