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/71d27795-200d-4a86-ba09-2b53aba81360n%40googlegroups.com.
