u-boot 2022-07 on STM32F746G-DISCO
Patrice CHOTARD
patrice.chotard at foss.st.com
Tue Sep 20 14:44:21 CEST 2022
Hi Waldemar
On 9/20/22 12:53, Waldemar Brodkorb wrote:
> Hi Patrice,
> Patrice CHOTARD wrote,
>
>> Hi Waldemar
>>
>> On 9/19/22 23:03, Waldemar Brodkorb wrote:
>>> Hi Patrice,
>>> Patrice CHOTARD wrote,
>>>
>>>> Waldemar,
>>>>
>>>> You can applied the following series on current U-Boot master
>>>> branch (a0759684e015bd7252be3af508c0fcfdbb8ec5dc):
>>>>
>>>> https://patchwork.ozlabs.org/project/uboot/list/?series=318991
>>>>
>>>
>>> I applied the patches on top of u-boot master and the non-SPL
>>> build still works fine. It seems only 2022.07 is broken, master is fine.
>>>
>>> The SPL build compiles, but I get no output via serial console after
>>> flashing. I changed the openocd command to use 0x8009000 for u-boot.
>>>
>>> /home/wbx/openadk/host_x86_64-linux-gnu/usr/bin/openocd \
>>> -f interface/stlink.cfg -f board/stm32f7discovery.cfg \
>>> -c "init" \
>>> -c "reset init" \
>>> -c "flash probe 0" \
>>> -c "flash info 0" \
>>> -c "flash write_image erase spl/u-boot-spl.bin 0x08000000" \
>>> -c "flash write_image erase u-boot-dtb.bin 0x08009000" \
>>> -c "reset run" \
>>> -c "shutdown"
>>>
>>> Is this change correct or do I misread your patches?
>>
>> Due to the flash layout (the 4 first sectors size is 32KB) using
>> "flash write_image erase" command, as you did, can't be used anymore due
>> to the SPL size increase.
>>
>> SPL size is over 32KB (0x8000), so SPL binary occupies the first and a part
>> of the second 32KB sectors.
>>
>> When you execute "flash write_image erase u-boot-dtb.bin 0x08009000",
>> this command erase the second 32KB sector (where a part of SPL has been
>> previously copied) before copying the u-boot-dtb.bin binary.
>>
>> So i advice you to use the method described in doc/board/st/stm32_MCU.rst
>> Copy directly the generated binary u-boot-with-spl.bin into the mass-storage
>> exposed by the board.
>>
>> Example, under Ubuntu you should see the following directory /media/$USER/DIS_F746NG
>
> When I copy u-boot-with-spl.bin to the mass-storage device I get
> following output on the serial console:
> U-Boot SPL 2022.10-rc5-00009-g41530b5b3e (Sep 20 2022 - 12:37:40
> +0200)
> Trying to boot from XIP
> fdt_root: FDT_ERR_BADMAGIC
> Hard fault
> pc : 08009000 lr : 0800070b xPSR : 41000000
> r12 : 2004f108 r3 : 40011000 r2 : 080c0000
> r1 : ffffffff r0 : 00000000
> Resetting CPU ...
>
> resetting ...
>
> How is it supposed to work to start the full u-boot-dtb.bin and
> u-boot-with-spl.bin? When I copy both files I get no output, it
> seems this is not supported, right?
u-boot-with-spl.bin is the concatenation of 2 binaries:
u-boot-with-spl.bin = u-boot-spl.bin + u-boot.bin
You should only copy u-boot-with-spl.bin in the board mass-storage.
At the end of u-boot-spl.bin binary, some padding is added to make sure
that u-boot.bin will be located at the expected offset, in our case offset
0x9000 (see CONFIG_SPL_PAD_TO 0x9000 in stm32f746-disco-spl_defconfig)
So u-boot-spl.bin is first executed, located at offset 0 (0x08000000),
then jump in u-boot.bin located at offset 0x9000 (0x08009000).
it's weird because everything looks correct in your log, pc is set with
0x08009000 but i can't understand why u-boot.bin is not executed in your
case ....
>
> Maybe I should stick with the normal non-SPL boot, I see no
> advantage to have the SPL boot. What is the advantage of the SPL
> build?
At the very beginning of stm32f746-disco support, Vikas Manocha introduces
SPL mode to use falcon mode (see doc/README.falcon)
With this mode you can jump directly in kernel after U-Boot SPL execution :
U-Boot SPL -> Kernel (previously flashed at offset 0x9000 and configured in XIP)
If during boot, you maintain the "c" key pressed, the SPL flow will be:
U-Boot SPL -> U-Boot (located in flash) -> Kernel (located in SD-card)
Have you try with stm32f746_disco_defconfig ? in this case, you have to copy
u-boot.bin binary in board mass-storage.
Patrice
>
> best regards
> Waldemar
More information about the U-Boot
mailing list