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/5c01bc18-1b55-45e5-bbbb-05a87a84768dn%40googlegroups.com.
