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/f8008997-abc0-41f0-bd27-c2f5ed443e1dn%40googlegroups.com.
