There is a addtional uboot function reading the eeprom and returning an uboot env variable which is then used for the DTB selection https://github.com/turing-machines/BMC-Firmware/blob/d9c55b7adaa06ec9abcc707e6a2cc20e1195ee2a/tp2bmc/board/tp2bmc/boot.scr#L19C1-L22C68 ⁨``` ... # read hardware version from EEPROM tpi_info hw_version tpi_hw_version setenv fit_boot_args "${loadaddr}#config-${tpi_hw_version:-v2.4.0}" ...

⁩
If tpi_hw_version is bogus instead of the expected empty it will prevent booting in current HEAD.
In <@412601802693804032> 's case there is something like ⁨`tpi_hw_version=v31.31.63`⁩ in tthe uboot environement.
If we assumne that for 2.5.x board the eeprom is always correct, (except the user interfered with its contents), we can safely say it is a v2.4.0 board if there is another version string comming out of tpi_info.

So this will be the fix I would introduce:
⁨

tpi_info hw_version tpi_hw_version # only accept known revisions, and fall back to v2.4.0 if test "$tpi_hw_version" = "v2.5.0"; then setenv tpi_hw_version "v2.5.0" elif test "$tpi_hw_version" = "v2.5.1"; then setenv tpi_hw_version "v2.5.1" elif test "$tpi_hw_version" = "v2.5.2"; then setenv tpi_hw_version "v2.5.2" else setenv tpi_hw_version "v2.4.0" fi setenv fit_boot_args "${loadaddr}#config-${tpi_hw_version:-v2.4.0}" ```⁩ As ${tpi_hw_version:-v2.4.0} only helps if there is no bogus in eeprom. https://github.com/j0ju/sbc-fw-alchemy/commit/35fc707e1bc77a245cd9abd0ab8d84b8c4793299