On Sat, 07 Feb 2015 10:21:46 +0100 Hans de Goede <[email protected]> wrote:
> 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: 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 -- 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.
