"So let me make it clear. At the moment we can flash U-Boot SPL, flash U-Boot Proper without any modification and signature at all" Yes, that's what I did and my FEX flasher accepted and wrote the files to NAND.
"And let me guess - at the moment you get something like" Not exactly. After adding some debugging printfs, I figured that SPL detects "correct" NAND parameters (which differ from actually correct params). Then it uses these params to read U-Boot Proper to RAM (all read operations return 00000000 and an error - it's ignored by SPL). Then it jumps to U-Boot Proper which are all 0's, because reading everything failed. I don't know why SPL thinks that wrong params are correct. I don't have enough knowledge (nor a JTAG debugger, sadly) to be able fo fix it that far. Though if your SPL can read from NAND successfully, my flasher should allow you to get mainline running. Well, after you add your DTBs and NAND params, per that commit from that gitlab repo. I don't know if adding NAND id in *drivers/mtd/nand/sunxi_nand_spl.c* <https://gitlab.com/m.motyl83/u-boot/-/commit/71bf1501f1f5e677c5d4a13cbd7268f2fbfd2f64#ef4bb1fea714108750d582a1b10114df1223c60a> is needed. Note that you shouldn't change CONFIG_SPL_TEXT_BASE, like that commit does. "I've modified my SPL - it read all NAND and outputs it byte by byte to UART." Could you share these modifications somewhere? It could be useful for me to debug which NAND configuration is correct in my case (if I ever get back to that topic...). "I didn't see any modifications" Maybe you just missed it. The code gets corrupted at about 32 KiB offset, and you probably didn't check the entire Proper by hand... that would be impossible. First bytes of mainline without headers are also "b" instructions (afaik). The eGON header is useful only for stock boot0, SPL doesn't read it. Jumping to offset 0 of eGON just skips the header and goes to Proper's own "b" instructions. No header means no eGON, and jumping straight into Proper. "How did you see that update boot1 modified contents while flashing?" I disassembled update_boot1.axf to simply disable magic and CRC checking, then I found that the code does more than that (in IDA Pro - it can decompile ARM to C-pseudocode pretty well). wtorek, 26 kwietnia 2022 o 11:46:19 UTC+2 Daft Soft napisał(a): > 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/72351c5d-e7f0-470e-a88d-133435e054b3n%40googlegroups.com.
