[PATCH v3 0/9] arm: am335x: Switch to upstream devicetree

[Markus Schneider-Pargmann]

Hi Tom,

On Fri Jan 16, 2026 at 7:45 PM CET, Tom Rini wrote:
> On Thu, Dec 04, 2025 at 11:25:36AM +0100, Markus Schneider-Pargmann (TI.com) wrote:
>
>> The series is split into two logical groups:
>> 
>> - Patches 1-4: Fixes for am335x-evm to boot and support the LCD panel
>>   with the current u-boot devicetree.
>> - Patches 5-8: Make upstream devicetree working with uboot. This
>>   adds tick-timer, adds compatibility of the board code for different
>>   USB probing and updates the defconfig.
>> 
>> The series has been tested on am335x-evm. Note that I don't have all
>> other boards built with the am335x_*evm_*defconfig, so tests are
>> appreciated. buildman reports builds are working.
>> 
>> Dependencies:
>>   - clk: ti: Cleanup common functions and omap-cm
>>       https://lore.kernel.org/r/20251128-topic-am33-clk-regmap-dep-v2026-01-v2-0-451b4f4e7e85@baylibre.com
>>   - dm: core: Support same compatible in host/gadget musb drivers
>>       https://lore.kernel.org/r/20251126-topic-musb-probing-v2026-01-v1-0-ff8d8c487130@baylibre.com
>>   - simple-pm-bus: Make clocks optional
>>       https://lore.kernel.org/r/20251128-topic-simple-pm-bus-optional-clocks-v2026-01-v1-1-e38040c88b6d@baylibre.com
>>   - video: simple_panel support for am335x evm panel
>>       https://lore.kernel.org/r/20251204-topic-am33-evm-lcd-v2026-01-v3-0-ca74853bd5f0@baylibre.com
>>   - power: domain: Add ti-omap-prm stub
>>       https://lore.kernel.org/r/20251128-topic-omap-prm-v2026-01-v1-1-72c5cc4c7728@baylibre.com
>
> All of the deps are now merged. Unfortunately, this now overflows SRAM
> by 80 bytes, when using the gcc-14.2.0 toolchain from kernel.org that CI
> uses. You might need to look at enabling LTO here, which I haven't tried
> in a long time but recall had its own problem unfortunately when I did.
> But that was years ago, and perhaps is no longer a problem.

I wasn't able to reproduce the issue so I reproduced it in the same CI
container, as mentioned on IRC.

LTO indeed helped in the container with gcc-14.2. But it failed for me
on gcc-15.2 where it produced code that is too large.

SPL_OPTIMIZE_INLINING is currently not set for am335x_evm and I think
this is a safe option. It helps both for gcc-14.2 and gcc-15.2. Are
there any pitfalls with this option that I am not aware of?

Thanks!

Best
Markus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 289 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260119/29d5ffdd/attachment.sig>