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

[Siarhei Siamashka <siarhei.siamashka@gmail.com>]

On Sat, 07 Feb 2015 10:21:46 +0100
Hans de Goede <hdegoede@redhat.com> wrote:

> 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:

That's the (longer term) plan.

> 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.

I would perhaps prefer to keep the current 'spl' command name just for
the SPL alone. And invent some new name for a more advanced command to
use it with the future u-boot v2015.07 release.

> Maybe we should also do something for old kernels where script.bin needs
> to be loaded, maybe:
> 
> fel spl-old-kernel ... ??

Isn't the script.bin normally loaded exactly at the same address
as the dtb? So nothing special is really needed for old kernels here.

> > 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.

Anyway, I think that we already have a solution for v2015.04
And unless unexpected problems are identified in the current
implementation, I don't have plans to do any additional work
on this FEL boot stuff at least for a few weeks. Anyone is
welcome to pick it up from this point.

The linux-sunxi wiki is back from read-only mode. And I have
edited the http://linux-sunxi.org/FEL/USBBoot page to add more
up to date instructions. I think, this wraps it up.

-- 
Best regards,
Siarhei Siamashka