On 2/24/25 15:58, Patrice CHOTARD wrote:
>
>
> On 2/3/25 08:23, Patrice CHOTARD wrote:
>>
>>
>> On 1/31/25 17:01, Tom Rini wrote:
>>> On Fri, Jan 31, 2025 at 03:41:37PM +0100, Patrice CHOTARD wrote:
>>>>
>>>>
>>>> On 1/29/25 23:01, Tom Rini wrote:
>>>>> On Tue, Jan 28, 2025 at 09:04:26AM -0600, Tom Rini wrote:
>>>>>> On Tue, Jan 28, 2025 at 08:04:56AM -0600, Tom Rini wrote:
>>>>>>> On Tue, Jan 28, 2025 at 08:47:37AM +0100, Patrice CHOTARD wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 1/15/25 15:44, Tom Rini wrote:
>>>>>>>>> On Wed, Jan 15, 2025 at 03:39:20PM +0100, Patrice CHOTARD wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 1/15/25 15:24, Patrice CHOTARD wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 1/15/25 14:19, Simon Glass wrote:
>>>>>>>>>>>> Hi Patrice,
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, 15 Jan 2025 at 03:19, Patrice CHOTARD
>>>>>>>>>>>> <patrice.chot...@foss.st.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi
>>>>>>>>>>>>>
>>>>>>>>>>>>> I am currently converting STM32MP platforms to OF_UPSTREAM.
>>>>>>>>>>>>> As we use same binary for several boards, flags
>>>>>>>>>>>>> CONFIG_OF_UPSTREAM_BUILD_VENDOR=y
>>>>>>>>>>>>> and CONFIG_OF_UPSTREAM_VENDOR="st" are set.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So all dts/upstream/src/arm/st/* dts files are compiled.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I am facing an issue with
>>>>>>>>>>>>> dts/upstream/src/arm/st/stm32mp151a-prtt1* and
>>>>>>>>>>>>> dts/upstream/src/arm/st/stm32mp15*-mec*.* files.
>>>>>>>>>>>>>
>>>>>>>>>>>>> To be more precise, these files are using a syntax which follows
>>>>>>>>>>>>> this
>>>>>>>>>>>>> format &{label/subnode} to override some nodes.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This leads to DTC error:
>>>>>>>>>>>>>
>>>>>>>>>>>>> AR drivers/usb/gadget/built-in.o
>>>>>>>>>>>>> LD u-boot
>>>>>>>>>>>>> OBJCOPY u-boot.srec
>>>>>>>>>>>>> OBJCOPY u-boot-nodtb.bin
>>>>>>>>>>>>> SYM u-boot.sym
>>>>>>>>>>>>> DTC dts/upstream/src/arm/st/stm32mp157c-dhcom-picoitx.dtb
>>>>>>>>>>>>> DTC dts/upstream/src/arm/st/stm32h750i-art-pi.dtb
>>>>>>>>>>>>> DTC
>>>>>>>>>>>>> dts/upstream/src/arm/st/stm32mp157a-microgea-stm32mp1-microdev2.0-of7.dtb
>>>>>>>>>>>>> DTC dts/upstream/src/arm/st/stm32mp157a-iot-box.dtb
>>>>>>>>>>>>> DTC dts/upstream/src/arm/st/stm32746g-eval.dtb
>>>>>>>>>>>>> DTC dts/upstream/src/arm/st/stm32mp151c-mecio1r0.dtb
>>>>>>>>>>>>> DTC dts/upstream/src/arm/st/stm32mp157a-dhcor-avenger96.dtb
>>>>>>>>>>>>> DTC dts/upstream/src/arm/st/ste-nomadik-s8815.dtb
>>>>>>>>>>>>> Error:
>>>>>>>>>>>>> ../dts/upstream/src/arm/st/stm32mp15x-mecio1-io.dtsi:338.1-2
>>>>>>>>>>>>> syntax error
>>>>>>>>>>>>> FATAL ERROR: Unable to parse input tree
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> At line 338 in dts/upstream/src/arm/st/stm32mp15x-mecio1-io.dtsi
>>>>>>>>>>>>> we got :
>>>>>>>>>>>>>
>>>>>>>>>>>>> &{qspi_bk1_pins_a/pins} {
>>>>>>>>>>>>> pinmux = <STM32_PINMUX('F', 8, AF10)>, /* QSPI_BK1_IO0 */
>>>>>>>>>>>>> <STM32_PINMUX('F', 9, AF10)>, /* QSPI_BK1_IO1 */
>>>>>>>>>>>>> <STM32_PINMUX('F', 7, AF9)>, /* QSPI_BK1_IO2 */
>>>>>>>>>>>>> <STM32_PINMUX('F', 6, AF9)>; /* QSPI_BK1_IO3 */
>>>>>>>>>>>>> /delete-property/ bias-disable;
>>>>>>>>>>>>> bias-pull-up;
>>>>>>>>>>>>> };
>>>>>>>>>>>>>
>>>>>>>>>>>>> If i update it as following , the DTC compilation is OK :
>>>>>>>>>>>>>
>>>>>>>>>>>>> &qspi_bk1_pins_a {
>>>>>>>>>>>>> pins {
>>>>>>>>>>>>> pinmux = <STM32_PINMUX('F', 8, AF10)>, /*
>>>>>>>>>>>>> QSPI_BK1_IO0 */
>>>>>>>>>>>>> <STM32_PINMUX('F', 9, AF10)>, /*
>>>>>>>>>>>>> QSPI_BK1_IO1 */
>>>>>>>>>>>>> <STM32_PINMUX('F', 7, AF9)>, /*
>>>>>>>>>>>>> QSPI_BK1_IO2 */
>>>>>>>>>>>>> <STM32_PINMUX('F', 6, AF9)>; /*
>>>>>>>>>>>>> QSPI_BK1_IO3 */
>>>>>>>>>>>>> /delete-property/ bias-disable;
>>>>>>>>>>>>> bias-pull-up;
>>>>>>>>>>>>> };
>>>>>>>>>>>>> };
>>>>>>>>>>>>>
>>>>>>>>>>>>> On kernel side, the DTC compilation is ok, but not on U-Boot
>>>>>>>>>>>>> side. I am not able to understand the difference.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Could it be that the kernel dtc is newer?
>>>>>>>>>>>
>>>>>>>>>>> I have tested with dtc Version: DTC 1.7.0-gbcd02b52 which is the
>>>>>>>>>>> same dtc version than kernel tag next-20250114
>>>>>>>>>>
>>>>>>>>>> I mean, it's ok with newer version of dtc : DTC 1.7.0-gbcd02b52.
>>>>>>>>>
>>>>>>>>> Ah, so, sigh, we need to update DTC. I stopped my last upgrade there
>>>>>>>>> because other changes it made grew the binary size for everyone and
>>>>>>>>> didn't get back to it. I guess another attempt is in order.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Hi Tom
>>>>>>>>
>>>>>>>> Do you know when you will be able to provide a DTC update in master or
>>>>>>>> next branch ?
>>>>>>>
>>>>>>> Unfortunately trying to update resync-dtc-v1.6.0-31-gcbca977ea121-v5 to
>>>>>>> be on top of current (the first step to moving to 1.7.0 or 1.7.1)
>>>>>>> produced some test failures that don't exist when using the host dtc.
>>>>>>> Can you confirm if dtc 1.7.0 is new enough for this syntax? We might
>>>>>>> just need to change to building pylibfdt and not dtc as well (as having
>>>>>>> pylibfdt come via system python or pipx is differently tricky it seems).
>>>>>>
>>>>>> The pipeline is at
>>>>>> https://source.denx.de/u-boot/u-boot/-/pipelines/24243 and that's just
>>>>>> the v5 branch currently under WIP/ rebased to then-current master.
>>>>>
>>>>> To push this as far as I can at least, there's now also
>>>>> WIP/resync-dtc-v1.7.1-v1 which brings us to dtc-1.7.1 (good!) but also
>>>>> some silent failure to boot on a least one of the TI K3 platforms I
>>>>> have, and some other failures in CI too.
>>>>>
>>>> Hi Tom
>>>>
>>>> I rebase my "STM32 OF_UPSTREAM" series on top of your branch
>>>> WIP/resync-dtc-v1.7.1-v1,
>>>> that fixes the issue i described in my initial mail.
>>>>
>>>> Thanks for this update
>>>
>>> Well, please note that branch is a problem. I have no idea why some
>>> tests, and then some platforms fail. I also don't have the time to look
>>> in to it. I posted this so that at least the groundwork is done for
>>> someone else with motivation / need to finish fixing things.
>>>
>>
>> OK i will try to have a look at it.
>
> Hi
>
> I found that most of the issue are due to these 2 following DTC patches :
>
> 5e735860c478 libfdt: Check for 8-byte address alignment in fdt_ro_probe_()
> b07b62ee3342 libfdt: Add FDT alignment check to fdt_check_header()
>
> If i reverted these 2 patches, there are 4 tests which are still remaining
> fail:
> (see CI tests :
> https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/24800)
> _ "sandbox test.py" and "sandbox with clang test.py"
>
> => test/py/tests/test_sandbox_opts.py => fixed see commit 8a8aa1e30b02
> "fixup! sandbox: Update dts files again"
>
> _ "sandbox_noinst test.py" and "sandbox_noinst with LOAD_FIT_FULL test.py"
>
> test/py/tests/test_spl.py::test_spl[ut_dm_dm_test_of_plat_clk] -
> OSErr...
> test/py/tests/test_spl.py::test_spl[ut_dm_dm_test_of_plat_dev] -
> OSErr...
> test/py/tests/test_spl.py::test_spl[ut_dm_dm_test_of_plat_gpio] -
> OSEr...
> test/py/tests/test_spl.py::test_spl[ut_dm_dm_test_of_plat_parent] -
> OS...
> test/py/tests/test_spl.py::test_spl[ut_dm_dm_test_of_plat_phandle] -
> O...
>
> test/py/tests/test_spl.py::test_spl[ut_spl_test_spl_test_blk_FIT_EXTERNAL]
>
> test/py/tests/test_spl.py::test_spl[ut_spl_test_spl_test_blk_FIT_INTERNAL]
>
> test/py/tests/test_spl.py::test_spl[ut_spl_test_spl_test_mmc_FIT_EXTERNAL]
>
> test/py/tests/test_spl.py::test_spl[ut_spl_test_spl_test_mmc_FIT_INTERNAL]
>
> test/py/tests/test_spl.py::test_spl[ut_spl_test_spl_test_nand_FIT_INTERNAL]
>
> test/py/tests/test_spl.py::test_spl[ut_spl_test_spl_test_net_FIT_EXTERNAL]
>
> test/py/tests/test_spl.py::test_spl[ut_spl_test_spl_test_net_FIT_INTERNAL]
>
> test/py/tests/test_spl.py::test_spl[ut_spl_test_spl_test_nor_FIT_INTERNAL]
>
> test/py/tests/test_spl.py::test_spl[ut_spl_test_spl_test_spi_FIT_INTERNAL]
>
> I didn't start to look at these tests.
>
>
> So i checked which tests are impacted by the 2 above DTC patches on "sandbox
> test.py" :
>
> 1) fix arch/sandbox/dts/sandbox.dtsi which generate warnings and made
> buildman fail
> => commit 8a8aa1e30b02 "fixup! sandbox: Update dts files again"
>
> 2) ./test/py/tests/test_extension.py
> => commit 27c909792ef4 ("fix test_extension.py")
>
> 3) ./test/py/tests/test_vboot.py :
> => First analysis: If FIT embeds a DTB, currently nothing ensure that this
> embedded DTB is
> located at an offset 8 bytes aligned from the FIT beginning during the
> FIT generation.
>
> 4) ./test/py/tests/test_android/test_abootimg.py:
> => same issue as FIT generation, reading the way to generate boot.img or
> vendor_boot.img
> at the beginning of test_abootimg.py, the 2 embbed DTBs must be all
> located at an offset
> 8 bytes aligned from the start of the image.
>
> I didn't find a way to ensure that both embedded DTBs are 8 bytes
> aligned with mkbootimg.
>
> PS: the 2 fixes mentioned are available on STM32_U-boot_custodian tree.
>
> I will continue to investigate, but if someone can help it would be great ;-)
Hi Tom, Simon
I have spent some time to investigate on the above issues due to DTC 1.7.1
migration.
I have fixed some "visible" failure highlighted by U-Boot CI Build.
Most of issue are linked to the constraints to have DT header aligned to 8
bytes.
To ensure that DT header is always 8 bytes aligned imposes update in a lot of
part of U-Boot
and honestly it's touchy.
The more i digged, the more i discovered impact in a lot of components of
U-Boot's tools
(mkimage, binman) or the way binaries are generated (Makefile ..).
So i will not go further. Instead i will simply backport some DTC patches
needed to solve the inital issue
i saw, that means adding label relative path references to DTC.
See submitted patch :
https://patchwork.ozlabs.org/project/uboot/patch/20250328163115.642347-1-patrice.chot...@foss.st.com/
I applied this patch over WIP/27Mar2025-next, run CI-Build with no regression:
https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/25384
Thanks
Patrice
>
> Thanks
> Patrice
>>
>> Thanks
>> Patrice
