Pali

The whole thing is broken. For 1.2 GHz variant is officially documented CPU errata related to CPU voltage together with workaround. But source of the issue is not documented and is Marvell secret. That workaround is implemented in kernel for a long time (including 5.15). But for some unknown reasons since some kernel version 1.2 GHz variant of CPU crashes even with workaround. And because only Marvell knows source of one documented crahes, we can just guess... if this that documented issue, or some other issue... Only HW engineer of that A3720 CPU can answer to those questions. Anyway, if somebody is interested in, wants to debug this issue and is skilled in compiling, patching and debugging kernel, I can forward some new test info which I have (write me an email).

Here is the issue. 1.2 GHz variant of A3720 CPU is not supported by Linux. Trying to do frequency scaling on that variant cause CPU crashes. Hence it was disabled. Yes, on many places and there is just a silence: https://lore.kernel.org/linux-pm/20210809040224.j2rvopmmqda3utc5@vireshk-i7/ https://github.com/MarvellEmbeddedProcessors/linux-marvell/issues/20 Contacting your support departement or directly Marvell FAE. Opening RMA or returning broken product back to seller.

You should add that chunk of dts code to the original source device tree file and not into the decompiled device tree binary (which you attached into the first post).

Use upstream U-Boot and not some OpenWRT fork which was broken. And after upgrading reset env variables to default and beware to not erase mac address of network controller (stored in env too). Armbian boot scripts explicitly erased mac address which lead to your U-Boot errors. Recent upstream U-Boot from this year used to work without any issues on Espressobin v5.