[U-Boot] [PATCH sunxi-tools] WIP: fel: Add a command for loading U-Boot SPL binaries in eGON format

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 02/07/2015 04:17 AM, Siarhei Siamashka wrote:
> On Thu, 5 Feb 2015 22:49:39 -0700
> Simon Glass <sjg@chromium.org> wrote:
> 
>> Hi Siarhei,
>>
>> On 5 February 2015 at 02:36, Siarhei Siamashka
>> <siarhei.siamashka@gmail.com> wrote:
>>> !!! Works only on Allwinner A20 so far and needs a bit more
>>> !!! debugging. And even on A20, the transition from the SPL to
>>> !!! the main U-boot binary has some glitches.
>>>
>>> Now it should be possible to load and execute the same U-Boot SPL,
>>> as used for booting from SD cards. The only argument for this new
>>> command is the name of the SPL binary file (with eGON header).
>>> It can be run as:
>>>
>>>     fel spl u-boot-sunxi-with-spl.bin
>>
>> This looks great! Does it write only the SPL portion or does it write
>> U-Boot also?
> 
> Yes, it only takes care of the SPL part at the moment, but surely
> this can be improved later.
> 
> The biggest inconvenience is that we need to provide the 'fel' tool
> with with the magic address for the main u-boot binary. This address
> is hidden in the u-boot sources:
> 
>     http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/sunxi-common.h;h=6cfd7e148900#l28
> 
> But the users need to know it in order to set in as the command
> line argument for the 'fel' tool.
> 
> We could probably do a better job and store the necessary addresses
> in the SPL header. Currently 'mksunxiboot' provides only a
> minimalistic header with the "eGON.BT0" signature and a checksum,
> because otherwise it will refuse to boot from the SD card:
> 
>     http://git.denx.de/?p=u-boot.git;a=blob;f=tools/mksunxiboot.c
> 
> But probably we can extend this header and also add the
> CONFIG_SYS_TEXT_BASE value there. Together with "kernel_addr_r",
> "fdt_addr_r", "scriptaddr" and "ramdisk_addr_r" values.
> After this change, the 'fel' tool will be able to extract all
> the necessary information from u-boot-sunxi-with-spl.bin
> file without relying on the command line too much.
> Moreover, these addresses are sometimes changing, and some
> users are IMHO rightfully upset whenever this happens:

I think that adding a new header for this sounds like a good idea, this
header should start with some 8 byte magic marker so that the fel tool
can be 100% sure if it is there.

>     http://permalink.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/14919
> 
>> I don't really understand how it works but will leave that to you and Hans.
>  
> OK :) Anyway, now I have finally pushed a supposedly properly working
> implementation to the following github branch:
> 
>     https://github.com/ssvb/sunxi-tools/commits/20150206-fel-large-spl-support

Cool (note I've not looked at the actual code yet), this all sounds quite
nice.

It would be really cool if when the new header is present and with a new
enough fel tool + u-boot bin we could do:

fel spl u-boot-sunxi-with-spl.bin zImage - dtb

or:

fel spl u-boot-sunxi-with-spl.bin zImage initrd dtb

And everything would just work, note that the "zImage initrd dtb" order
is the same as u-boot's bootm command, and the - is there to indicate
there is no initrd.

Maybe we should also do something for old kernels where script.bin needs
to be loaded, maybe:

fel spl-old-kernel ... ??



> Yes, we can handle most of this stuff with Hans. But some communication
> with you is still needed. In particular, we still need to decide a way
> to distinguish between booting from the SD card and over USB. Your
> RFC/WIP patch from
>     http://lists.denx.de/pipermail/u-boot/2015-February/203858.html
> was checking the value in the 'lr' register, but this is not going to
> work anymore. To address this, right now I'm just replacing the
> "eGON.BT0" signature in memory to a new "eGON.FEL" signature at the
> address 0x0004. The idea is that this signature is critical for booting
> from the SD card. If there is some other value instead, then we are
> pretty sure that the SPL was not booted from the SD card. And having it
> as "eGON.FEL" serves as an indication of what exactly it is.

I think that replacing eGON.BT0 with eGON.FEL when loading the SPL
through the new mode is a good way of doing this, ACK to that.

> Additionally, we might even not need to store the "lr" and "sp"
> registers in save_boot_params(). If we settle on using the "eGON.FEL"
> signature in memory for distinguishing between the FEL and the SD boot,
> then we can also reuse the other parts of of header (for example,
> the checksum) to store the return address.

We'll have to see how this all works out to determine whether or not that
is a good idea.

> As you have figured out earlier, avoiding setting VBAR and CP15
> stuff is important. Right now the FEL code in the BROM has an
> active interrupt handler in use (which I'm suppressing by disabling
> interrupts early) and the SPL needs to keep interrupts disabled,
> while trying not to mess its configuration.

Ack.

Regards,

Hans