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.binThe 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 r0BTW, 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.