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/abdd7f46-04b5-42cd-8af8-3ff2d7b492adn%40googlegroups.com.
