On Thu, 05 Feb 2015 21:41:27 +0100 Hans de Goede <[email protected]> wrote:
> Hi, > > On 05-02-15 20:54, Siarhei Siamashka wrote: > > On Thu, 5 Feb 2015 11:36:23 +0200 > > Siarhei Siamashka <[email protected]> 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 -- 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.
