Hi, On 02/07/2015 04:17 AM, Siarhei Siamashka wrote: > On Thu, 5 Feb 2015 22:49:39 -0700 > Simon Glass <[email protected]> wrote: > >> Hi Siarhei, >> >> On 5 February 2015 at 02:36, 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 >> >> 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 -- 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.
