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

[Tom Rini]

On Mon, Jan 19, 2026 at 09:18:23PM +0100, Markus Schneider-Pargmann wrote:
> 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?

Just run-time test it as much as you can please. I forget if there's
still the ability to force inline functions with that, but I *think*
there is, and in turn I think everything should still work right.

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