Wow! Great work. So let me make it clear. At the moment we can flash U-Boot SPL (built by stock mainline U-Boot's build system without modification of addresses/offsets, but still with eGON.BT0 signature), flash U-Boot Proper without any modification and signature at all. Did I get it clear?
And let me guess - at the moment you get something like Trying to boot from NAND SPL: failed to boot from all boot devices Right? P.S. I've modified my SPL - it read all NAND and outputs it byte by byte to UART. And the data was correct from the 800000h and so on... I didn't see any modifications. That's why I thought the problem was not in storing Proper in NAND rather in "jumping" ("b" - first instruction of eGON header). I thought it was incorrect due to it's "technical nature". I'm not familiar with ARM architecture, enough, so I don't know how should parameters (address) of this instruction be generated. After that I've modified offset in SPL and added padding in U-Boot Proper. Flashed and SPL jumped straight to Proper and it worked. How did you see that update boot1 modified contents while flashing? On Monday, 25 April 2022 at 16:27:25 UTC+3 ku...@szczodrzynski.pl wrote: > I know that changing the address is needed in your case. > However, I wanted to use stock U-boot build system, without Boot1 > generation modifications. I binary-patched LiveSuit updater files to allow > flashing generated images directly via FEX. > (SPL with small header and U-Boot without eGON header) > > The required modifications for update_boot0.axf were to remove writing > "storage data" to SPL header. Modifications to update_boot1.axf are: > - remove writing "storage data" (which would overwrite part of u-boot code) > - disable checking header magic (eGON.BT1) > - disable checksum validation (there's no header, so no checksum) > > The binaries allow flashing SPL and U-Boot straight out of official U-Boot > build through FEX/LiveSuit. The offsets don't even have to be changed, as > there's no header - offset stays 0x800000. > > However, I got stuck with SPL not recognizing correct NAND parameters at > all, resulting in not being able to read U-Boot. I checked with SD-card > U-boot that the data is actually stored in the NAND. > > I'm attaching the patched binaries. When flashing, they also print "Hello, > Update boot0. Patch v1" on UART. > poniedziałek, 25 kwietnia 2022 o 12:23:54 UTC+2 Daft Soft napisał(a): > >> I didn't just place code at 2000h. It wouldn't work. I had also to modify >> U-Boot SPL to make it load U-Boot Proper from specific address: >> >> CONFIG_SYS_NAND_U_BOOT_OFFS=0x802000 >> CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND=0x802000 >> >> These lines in .config are crucial (as rebuilding U-Boot SPL with them). >> On Tuesday, 5 April 2022 at 00:21:44 UTC+3 ku...@szczodrzynski.pl wrote: >> >>> >>> 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/abdd7f46-04b5-42cd-8af8-3ff2d7b492adn%40googlegroups.com.