[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 Thu, 05 Feb 2015 21:41:27 +0100
Hans de Goede <hdegoede@redhat.com> wrote:

> Hi,
> 
> On 05-02-15 20:54, Siarhei Siamashka wrote:
> > On Thu,  5 Feb 2015 11:36:23 +0200
> > 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
> >>
> >> The free space in SRAM is scattered in the FEL mode across multiple
> >> locations. We just split SPL into individual chunks, upload them
> >> to the free locations in SRAM and also upload a small startup code,
> >> which is responsible for harvesting and gluing the pieces of SPL
> >> together. Additionally, the eGON checksum is verified to ensure
> >> that no data corruption has happened due to some unexpected clash
> >> with the FEL protocol code from the BROM.
> >>
> >> After this is done, it is not possible to return back to FEL anymore
> >> (both IRQ and normal stacks of the BROM are overwritten). However
> >> it is still possible to transfer control to the FEL init code (so
> >> that it re-initializes the USB hardware and all the other things):
> >>
> >>      /* Jump to the FEL entry point in BROM */
> >>      movw  r0, #0x20
> >>      movt  r0, #0xffff
> >>      bx    r0
> >
> > BTW, we still have the plan B in the case if the jump to 0xffff0020
> > turns out to be way too problematic.
> >
> > Essentially, the problem that we want to solve here is to ensure a
> > sufficiently large and consistent SRAM address space for the SPL
> > without any potentially SoC variant specific holes in the case of
> > booting over USB via FEL.
> >
> > This can be achieved by injecting special entry/exit code fragments,
> > which would reshuffle data in SRAM to provide a contiguous space for
> > the SPL at the beginning of SRAM and preserve the data from the BROM
> > stacks in the higher addresses of SRAM. Then move the BROM stacks
> > back into the original place just before returning control to FEL
> > (using the return address from the 'lr' register as usual). Doing it
> > this way, we get the current FEL boot behaviour, except that dealing
> > with the SRAM address space layout is abstracted in the 'fel' tool and
> > the SPL can just always use the 0x20 entry point and a big contiguous
> > area in the lower addresses of SRAM. The available SRAM space will be
> > less than 32 KiB though (but at least larger than 16 KiB), because the
> > backups of the BROM stacks have to be preserved.
> 
> Cool, I like the idea of saving the BROM data to some other SRAM area,
> and then restoring it before returning to FEL, I think that is better
> then re-initializing the usb connection each step.
>
> If only the BROM would use a more sane memory layout to begin with ...
> 
> > Either way, I hope to send some fully working solution tomorrow to
> > replace this proof-of-concept patch.
> 
> Cool, thanks for your work on this.

https://github.com/ssvb/sunxi-tools/commits/20150206-fel-large-spl-support

All of this seems to work very nicely. Now I can, for example, even
boot regular old SD-card based SPL files over FEL, and they successfully
pick up the main u-boot binary and the rest of the system from the SD
card.

The SPL files built from updated u-boot (using my local hacks, based on
Simon's patches) naturally can differentiate between SD and FEL boot
at runtime.

-- 
Best regards,
Siarhei Siamashka