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.
Thanks
Patrice
