Yes, it doesn't work, at least for me. I tried it a million times. piątek, 27 maja 2022 o 17:57:13 UTC+2 Jeroen van Jaarsveld napisał(a):
> I might be totally out of my depth here, but are you aware of the process > described in board/sunxi/README.nand? > Allwinner NAND flashing > ======================= > > A lot of Allwinner devices, especially the older ones (pre-H3 era), > comes with a NAND. NANDs storages are a pretty weak choice when it > comes to the reliability, and it comes with a number of flaws like > read and write disturbs, data retention issues, blocks becoming > unusable, etc. > > In order to mitigate that, various strategies have been found to be > able to recover from those issues like ECC, hardware randomization, > and of course, redundancy for the critical parts. > > This is obviously something that we will take into account when > creating our images. However, the BROM will use a quite weird pattern > when accessing the NAND, and will access only at most 4kB per page, > which means that we also have to split that binary across several > pages. > > In order to accommodate that, we create a tool that will generate an > SPL image that is ready to be programmed directly embedding the ECCs, > randomized, and with the necessary bits needed to reduce the number of > bitflips. The U-Boot build system, when configured for the NAND (with > CONFIG_MTD_RAW_NAND=y) will also generate the image sunxi-spl-with-ecc.bin > that will have been generated by that tool. > > In order to flash your U-Boot image onto a board, assuming that the > board is in FEL mode, you'll need the sunxi-tools that you can find at > this repository: https://github.com/linux-sunxi/sunxi-tools > > Then, you'll need to first load an SPL to initialise the RAM: > sunxi-fel spl spl/sunxi-spl.bin > > Load the binaries we'll flash into RAM: > sunxi-fel write 0x4a000000 u-boot-dtb.bin > sunxi-fel write 0x43000000 spl/sunxi-spl-with-ecc.bin > > And execute U-Boot > sunxi-fel exe 0x4a000000 > > On your board, you'll now have all the needed binaries into RAM, so > you only need to erase the NAND... > > nand erase.chip > > Then write the SPL and its backup: > > nand write.raw.noverify 0x43000000 0 40 > nand write.raw.noverify 0x43000000 0x400000 40 > > And finally write the U-Boot binary: > nand write 0x4a000000 0x800000 0xc0000 > > You can now reboot and enjoy your NAND. > > Op woensdag 11 mei 2022 om 20:08:26 UTC+2 schreef ku...@szczodrzynski.pl: > >> The files you attached are encrypted. It seems that LiveSuit images are >> encrypted entirely, I don't know the details. I used "imgRePacker" to dump >> my stock image, and it produced encrypted files in the "_img.files" >> directory (which looked just like your .axf files), and normal files in >> "home" directory. Though I think this is image-specific, as another .img I >> tried had an "_extract" directory (apart from the "_img.files") which also >> contained encrypted files. >> >> I'm not sure if imgRePacker version matters. You probably just have to >> try unpacking A20 images until you find one that produces unencrypted files. >> >> The reason for your error is likely that my files were packed in >> "unencrypted" form - your packer expected to pack encrypted files. Then A20 >> (or FEX) tried to "decrypt" my file (which was unencrypted) and probably >> got garbage in result. >> >> I don't know how are these images encrypted. One could probably build a >> simple encrypt-decrypt tool, as all of these images look the same when >> encrypted - that could mean they use the same key. >> >> środa, 11 maja 2022 o 11:48:17 UTC+2 Daft Soft napisał(a): >> >>> Hi! >>> I've tested your update_boot0.axf and update_boot1.axf which you've sent >>> on 25 Apr with A20. >>> This is what I get >>> [FES]Err:ERROR : elf_loader() magic error >>> >>> I'm using so called bootfix (CLI tool). It is slightly modified by me >>> ("makeup" modification mostly). >>> It looks like it supports A13: >>> >>> switch ((buf.soc_id >> 8) & 0xFFFF) { >>> case 0x1610: soc_name = "fes"; break; >>> case 0x1623: soc_name = "A10"; break; >>> case 0x1625: soc_name = "*A13*"; break; >>> case 0x1633: soc_name = "A31"; break; >>> case 0x1651: soc_name = "*A20*"; break; >>> case 0x1650: soc_name = "A23"; break; >>> case 0x1680: soc_name = "H3" ; break; >>> } >>> >>> But A13 is SUN5I family, while A20 is SUN7I. Bootfix includes two >>> subdirs: sun4i and sun7i >>> which contain AXFs and FEXs. Actually I don't know how bootfix supports >>> SUN5I and does >>> it support it at all - there is no sun5i directory at all. (And I have >>> no A13 board to test it). >>> >>> I suppose ELF error is all about difference in families. >>> >>> I attach original AXFs for sun7i family. If you modify them I'll test >>> them on my A20 and will >>> give you feedback. >>> On Monday, 2 May 2022 at 23:35:24 UTC+3 ku...@szczodrzynski.pl wrote: >>> >>>> About the last part of your mail: >>>> What you highlighted is only the checksum. The header is not that short >>>> - it's about 32 KiB in size, iirc. You didn't fill "rest of the header" >>>> with zeroes, just the beginning of it. If you want to find modifications, >>>> you have to read a page at offset 0x81D0. That's where it gets modified. >>>> Somewhere on the net there are sources of bootloaders, with the header >>>> structure described. SPL jumps over your entire header, but only part of >>>> FEX's header (32 KiB vs 0x2000 B in your case). Also, "ef be ad de" is >>>> obviously not a valid B instruction, but you probably know this. >>>> >>>> Yes, I'm flashing proper without header because SPL doesn't need it, >>>> just like we said before. I built SPL from mainline, I didn't touch >>>> Michał's repo. >>>> >>>> I can't figure out the correct settings. I tried what's said in >>>> datasheet for my Micron NAND. Also the SPL seems to ignore these options >>>> anyway, looks like it's trying all one by one (I printed every of these >>>> tries, and the one that supposedly succeeded had wrong params). Maybe >>>> other >>>> parts of the Kconfig I have set incorrectly. Parameters from FEX seemed to >>>> match what I set in these config options, but no luck in reading by SPL. >>>> czwartek, 28 kwietnia 2022 o 10:07:26 UTC+2 Daft Soft napisał(a): >>>> >>>>> Hi! >>>>> "Not exactly. >>>>> ... >>>>> to be able fo fix it that far." >>>>> It looks like your SPL is built with wrong MTD driver settings. SPL >>>>> itself is >>>>> read by BROM, but U-Boot Proper is read by SPL. So MTD/NAND part of >>>>> SPL has to >>>>> be configured correctly. I think first you should figure out what NAND >>>>> chip >>>>> you use - you didn't mention which one. Mine is Micron, it was >>>>> supported out >>>>> of the box. Get params of your NAND from datasheet then configure SPL >>>>> to make >>>>> it use correct parameters, rebuild and go. >>>>> >>>>> I'm not PRO in MTD/NAND devices but as I remember, NAND doesn't >>>>> contain all >>>>> params of itself, so you need to specify them. You mentioned "adding >>>>> NAND id" - >>>>> maybe in your case you'll have to do this >>>>> (drivers/mtd/nand/nand_ids.c). >>>>> >>>>> You've mentioned DT. SPL includes reduced part of DT. I didn't modify >>>>> DT of >>>>> U-Boot at all. SPL is loaded by BROM, it loads U-Boot Proper in RAM >>>>> with it's >>>>> hardcoded params ("SPL" in CONFIG_NAND_SUNXI_SPL_XXX config lines also >>>>> points to >>>>> that these params are not loaded from DT by SPL), then (in my case) >>>>> Proper reads >>>>> DT for kernel from SATA, loads kernel and boots it. >>>>> >>>>> If your SPL is flashed correctly (if it starts - it is flashed >>>>> correctly) then >>>>> you can get some hints about your NAND while flashing - FEX outputs >>>>> some info >>>>> about it. In my case it is (with some my comments): >>>>> >>>>> [SCAN_DBG] ==============Nand Architecture Parameter============== >>>>> [SCAN_DBG] Nand Chip ID: 0x4b44642c 0xffffffa9 >>>>> [SCAN_DBG] Nand Chip Count: 0x1 >>>>> [SCAN_DBG] Nand Chip Connect: 0x1 >>>>> [SCAN_DBG] Nand Rb Connect Mode: 0x1 >>>>> [SCAN_DBG] Sector Count Of Page: 0x10 // 16 >>>>> [SCAN_DBG] Page Count Of Block: 0x100 // 256 >>>>> [SCAN_DBG] Block Count Of Die: 0x1000 // 4096 >>>>> [SCAN_DBG] Plane Count Of Die: 0x2 // 2 >>>>> [SCAN_DBG] Die Count Of Chip: 0x1 >>>>> [SCAN_DBG] Bank Count Of Chip: 0x1 >>>>> [SCAN_DBG] Optional Operation: 0x21788 // >>>>> [SCAN_DBG] Access Frequence: 0x1e // 30 >>>>> [SCAN_DBG] ECC Mode: 0x5 >>>>> [SCAN_DBG] Read Retry Type: 0x400a01 >>>>> ^^^^^^^^ >>>>> ead_retry_mode = >>>>> (read_retry_type>>16)&0xff; // 40h = Micron >>>>> read_retry_cycle >>>>> =(read_retry_type>>8)&0xff; // 10 >>>>> read_retry_reg_num = >>>>> (read_retry_type>>0)&0xff; // 1 >>>>> >>>>> Again, if your SPL is flashed correctly you can rely on this info from >>>>> FEX. >>>>> >>>>> Just to resume and make it finally clear - your SPL, correctly built >>>>> and >>>>> including correct header will load anyway/always, because it is loaded >>>>> by >>>>> BROM (which initializes and works with NAND on this stage). But when >>>>> SPL >>>>> is loaded - you are on your own. Thus SPL has to be configured >>>>> correctly >>>>> to work with appropriate NFC and MTD/NAND or whatever... >>>>> >>>>> "Note that you shouldn't change CONFIG_SPL_TEXT_BASE, like that commit >>>>> does." >>>>> I don't know what exactly in this branch (a20_nand) from this repo >>>>> helped me >>>>> to start U-Boot from NAND (I could not start mainline SPL from NAND >>>>> nor Proper, >>>>> but unfortunately I have no time to prepare whole diff with mainline). >>>>> But it >>>>> works with exactly that value. And I thought that this value is one of >>>>> the >>>>> "magic" of this branch/repo compared to mainline. Did you build SPL >>>>> (which >>>>> you've managed to start from NAND )from mainline or you're using >>>>> Michał >>>>> Motyl repo? >>>>> >>>>> "Could you share these modifications somewhere?" >>>>> I was wrong a little bit - it does not read ALL NAND, it just outputs >>>>> bytes >>>>> which are read while loading Proper. Add these lines in >>>>> sunxi_nand_spl.c to >>>>> nand_read_buffer()after ret = nand_read_page(conf, offs, dest, >>>>> conf->page_size); >>>>> >>>>> #if 0 >>>>> int j; >>>>> for(j = 0; j < conf->page_size; ++j) >>>>> { >>>>> // if (((((uint8_t*) dest)[j]) >= 32) && ((((uint8_t*) >>>>> dest)[j]) <= 126 )) >>>>> // printf("%c", ((uint8_t*) dest)[j]); >>>>> if ((j % 16) == 0 ) >>>>> printf("\n"); >>>>> printf("%02x ", ((uint8_t*) dest)[j]); >>>>> } >>>>> printf("\n\n"); >>>>> #endif >>>>> >>>>> But if you need to read whole NAND chip I suppose you can just set >>>>> CONFIG_SYS_NAND_U_BOOT_OFFS to zero or any offset you wish. >>>>> >>>>> "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." >>>>> >>>>> Of course, you're right. We need correct "B" instruction (as well as >>>>> header >>>>> itself) only for BT0 (because we can't omit BROM). After that if we >>>>> can flash >>>>> Proper without header we don't need it. >>>>> >>>>> P.S. >>>>> Yes, you're right. Tested one more time. It looks like FEX >>>>> recalculates CRC >>>>> - 4 bytes next to eGON.BT1 differ with those in my boot1 file. But >>>>> after that >>>>> I see some zeroes (I fill rest of header with zeroes) and the whole >>>>> page >>>>> (2000h bytes - sizeof(header)) filled with FFh (my "alignment") and no >>>>> modification. So I don't see what kind of "storage data" is modified >>>>> by FEX. >>>>> (Screenshot attached). >>>>> Anyway this should not be the problem - SPL should jump over whole >>>>> header. >>>>> So I still see the ARM "b" instruction as the cause of not starting >>>>> Proper >>>>> even when SPL starts and reads it from standard offset. You can play >>>>> around >>>>> with this with my prints in SPL and see. Maybe on A13 something is >>>>> different. >>>>> >>>>> >>>>> [image: Proper from NAND.png] >>>>> >>>>> On Tuesday, 26 April 2022 at 16:37:38 UTC+3 ku...@szczodrzynski.pl >>>>> wrote: >>>>> >>>>>> I'm also attaching stock updater binaries, so if anyone wants to know >>>>>> what changed, these files can be compared to the patched versions. It's >>>>>> very likely that there exist many versions of these flashers (maybe they >>>>>> even vary by CPU?). >>>>>> >>>>>> Note: my flashers are for A13. I'm not sure if they'll work for you >>>>>> on A20. If your stock binaries are the same as these attached, then it >>>>>> will >>>>>> work. If you attach your files, I can try to modify them too. >>>>>> >>>>>> wtorek, 26 kwietnia 2022 o 15:34:31 UTC+2 Oranż Metylowy napisał(a): >>>>>> >>>>>>> "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/f3b8ba51-5d6a-4261-8a02-658de385282bn%40googlegroups.com.
