Why does my build fail after moving to Zephyr 4.5?

Before you roll anything back, run west build directly on the failing target instead of going through twister. Twister gives you a trimmed summary and it's easy to miss the actual line number in the devicetree error. A plain build with your board and overlay flags will print the full message, and that usally tells you exactly which property or node it's choking on. I went through something like this moving from 4.3 to 4.5 on an F4 board. The GPIO binding files themselves didn't get renamed in any way that broke me, but the board dts files did get touched, and my overlay was quietly depending on a label in the board file that no longer existed in the same form. That whould also explain why your Nucleo is fine while the Discovery isn't. Two boards, two diferent dts files, and only one of them changed in a way that matters to your overlay. Easiest way to check: keep a copy of your old 4.2 tree around (or a fresh clone of that tag) and diff the board dts and the files under dts/bindings between the two versions. Five minutes with git diff and you'll see wheather anything your overlay references moved or changed spelling. One other thing worth trying after you see the real error: some STM32 pin setups got stricter about the parent gpio port being explicitly enabled in the overlay. If your overlay only touches the pin node itself, adding an explicit status okay on the parent port has fixed this pattern for me before. My bet is a two line overlay edit, not a version rollback situation.

I ran into this exact thing a while back, but on a much smaller F0 board, which is quite different from your F4 setup. My problem wasn't with the GPIO names or bindings at all, but with the default clock tree settings. After updating the OS version, the way it handled peripheral initialization changed slightly, causing timing issues even if the code looked identical. It’s hard to tell if it’s a tree format change or just how the clock constants are configured. I ended up manually overriding some of the timing defaults just to get things to link up.

It’s rarely just the bindings themselves that trip people up during a kernel upgrade. When I moved to Zephyr 4.5 on my F7 hardware, I noticed a related, much weirder issue stemming from the peripheral memory map changing. Specifically, I found that if the system wasn't properly configured, it would choke on the resource allocation for the device tree nodes. I fixed it by bumping the CONFIG_NR_MAX_PERIPH setting from the default of 32 to 64 in my configuration files. That change completely stabilized the linking process on the discovery board while keeping the clock setup clean. definitly check that limit if the diff shows nothing broken.

I've run into similar wierd issues during big version bumps before, and it wasn't always the tree definitions that were the problem. Sometimes it's something much deeper with how the build system handles config dependencies. I once tried updating a peripheral driver and it wouldn't compile untill I manually tweaked a Kconfig setting because the default memory mapping had shifted. It might be that your new Zephyr version expects a specific configuration enabled that you're missing. Check your board's configuration options.

When looking at large jumps like 4.2 to 4.5, I sometimes find that the breakage isn't actually in the immediate peripheral binding declaration itself, but rather in the underlying dependency resolution of the Kconfig system that dictates how resources are mapped across the SoC. I recall a past issue where adjusting a memory region's defined address range in the core board definition meant that downstream drivers were referencing a stale or conflicting base address, which certainly presents as a compilation failure during tree processing. Have you verified that the resource allocation flags within your overlay perfectly align with the address constraints defined by the parent board configuration? That usually resolves the phantom node errors that seem to pop up during these major kernel upgrades.