I can confirm that this works (the method for running SPL as Boot0). I've researched this a bit further and I know the reason for why that modification helps. When flashing with LiveSuit, the updater binaries (update_boot0.axf and update_boot1.axf) first grab the images to RAM, then parse their headers, check the checksum. Then, a part of the header called "storage data" is populated with data received from some other part of the updating process (possibly another .axf file, maybe related to configuration of the sys_config.fex). Boot0 and Boot1 have that part at 0x1C8 and 0x81D0 offset, respectively. Considering that U-Boot SPL doesn't have the entire eGON header and it starts at 0x60, the updater is overwriting part of SPL code - thus resulting in a corrupted firmware. As for U-Boot as Boot1, it overwrites code at 0x81D0. You have placed the code at 0x2000, so my guess is that you still have some part in the firmware overwritten. Maybe it just works by accident.
Anyways, I'm currently working on a binary-patched updater image, that will allow to flash Boot1 without any 0-byte padding, straight from U-Boot mainline. It won't even need an eGON header and will ignore the checksum. After that, I'll probably also patch the Boot0 updater not to overwrite anything, making it possible to just grab the SPL and flash it. poniedziałek, 4 kwietnia 2022 o 11:42:07 UTC+2 Daft Soft napisał(a): > Hi, all! > So, I have the complete solution to make A20 boot from NAND (SPL, U-Boot) > + > SATA (DTB, Kernel, RootFS). This is to exclude SD-Card from boot process. > > First part is a20_nand branch from U-Boot from > https://gitlab.com/m.motyl83/u-boot.git <http://U-Boot> > > NB! > a20_nand branch is crucial > > This will make appropriate SPL (spl/sunxi-spl.bin), which can be loaded to > NAND via FEX and will boot. > > At this moment we have one problem: we have no U-Boot proper prepared for > flashing via FEX (u-boot-dtb.bin will be rejected as file with wrong > signature). > U-Boot does not build U-Boot proper with SUNXI eGON.BT1 signature at all. > > So I've modified original mksunxi hosttool from U-Boot (source file > included). > It places correct signature to header of image followed by U-Boot proper > code. > > eGON.BT signatures start from ARM "B" instruction (4 bytes - instruction > opcode > and address to branch to). > Original mksunxi calculates this "branch" instruction (address) to jump > over > eGON header. For Boot0 it works perfectly (because it is standard offset > which > is used in any Boot0 image by BROM - be it proprietary Boot0 or U-Boot > SPL). > But not for Boot1... > > I don't know where IP (instruction pointer) points to when SPL loads > U-Boot > proper and tries to "jump" (speaking in terms of x86) to it. So, I didn't > know how to calculate address of this instruction. > But we know that U-Boot proper code works when SPL jumps right to it > (this is proved by inspecting u-boot-sunxi-with-spl.bin and playing with > loading images via USB-FEL). > > Thus I've modified generation of Boot1 image - it places U-Boot proper > code with some constant offset (2000h, filled with zeroes). > (Also we need to make more space in SUN4I_SRAM_SIZE, because it is Boot1 - > it is larger than Boot0). > > Next step is to modify config. We need to tell SPL to load U-Boot proper > from specific offset (avoiding BROM signature and "B" instruction - it > will > not read it from NAND at all). > This lines are: > > CONFIG_SYS_NAND_U_BOOT_OFFS=0x802000 > CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND=0x802000 > > (These lines are for SPL, so you need to rebuild it to work with U-Boot > proper > which is generated by modified mksunxi). > > After all this we can use modified mksunxi (I call it mksunxi-bt1) to > build > Boot1 image which contains signature, correctly placed U-Boot proper code, > can be flashed via FEX and started by SPL (with modified "U-Boot Offs"). > -- 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 linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/f9fd1012-434d-4459-9f9b-e29c948f74ddn%40googlegroups.com.
