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 ;-)
Thanks
Patrice
>
> Thanks
> Patrice
