ramips: missing mikrotik bootloader check in `platform.sh`

[corncobble]

Describe the bug

Mikrotik devices running v7 of the bootloader utilize a separate sysupgrade-v7 image (example) for upgrades.

When using Attended Sysupgrade or owut, it seems the wrong image is being used:

root@OpenWrt:/tmp# owut check --verbose
owut - OpenWrt Upgrade Tool 2026.01.13~2526d84b-r1 (/usr/bin/owut)
ASU-Server     https://sysupgrade.openwrt.org
Upstream       https://downloads.openwrt.org
Target         ramips/mt7621
Profile        mikrotik_routerboard-750gr3
Package-arch   mipsel_24kc
Root-FS-type   squashfs
Sys-type       sysupgrade
Version-from   25.12.0 r32713-f919e7899d (kernel 6.12.71)
Version-to     25.12.2 r32802-f505120278 (kernel 6.12.74)
Build-commit   https://git.openwrt.org/?p=openwrt/openwrt.git;a=shortlog;h=f505120278
Build-FS-type  squashfs
Build-at       2026-03-25T20:09:53Z (~28 days ago)
Image-prefix   openwrt-25.12.2-ramips-mt7621-mikrotik_routerboard-750gr3
Image-URL      https://downloads.openwrt.org/releases/25.12.2/targets/ramips/mt7621
Image-file     openwrt-25.12.2-ramips-mt7621-mikrotik_routerboard-750gr3-squashfs-sysupgrade.bin
Installed      163 packages
Top-level      131 packages
Default         29 packages
User-installed 103 packages (top-level only)

Image-file above should be openwrt-25.12.2-ramips-mt7621-mikrotik_routerboard-750gr3-squashfs-sysupgrade-v7.bin (note the -v7).

I'm not sure what the full set of changes are to fix this, but from what I've found:

• The Mikrotik bootloader check is done for ath79 devices, found here, and some further upgrade logic is found here. None of this logic seems to be included for ramips devices (here).

I hope this provides enough information to at least get started. Let me know if I can provide any further info.

OpenWrt version

r32713-f919e7899d

OpenWrt release

25.12.0

OpenWrt target/subtarget

ramips/mt7621

Device

MikroTik RouterBOARD 750Gr3

Image kind

Official downloaded image

Steps to reproduce

No response

Actual behaviour

No response

Expected behaviour

No response

Additional info

No response

Diffconfig

Terms

• I am reporting an issue for OpenWrt, not an unsupported fork.

[efahl]

Yeah, this a case of the image naming going rogue and adding new information that's unknown to the standard tooling.

...ramips-mt7621-mikrotik_routerboard-750gr3-squashfs-sysupgrade-v7.bin

Rather than tacking on the -v7 to the end of the image basename, it should probably be the case that it becomes part of the device name, like for example, the Linksys E8450 does with its ubi and non-ubi variants:

$ git grep e8450 target/linux/mediatek/image/
target/linux/mediatek/image/mt7622.mk:define Device/linksys_e8450
...
target/linux/mediatek/image/mt7622.mk:define Device/linksys_e8450-ubi
...

Resulting in image names like this, and more importantly providing board_name that allows fwtool, sysupgrade and ASU to all deal with the image without special case code.

...mediatek-mt7622-linksys_e8450-squashfs-sysupgrade.bin
...mediatek-mt7622-linksys_e8450-ubi-squashfs-sysupgrade.itb

[map-b]

There are two issues then:

• sysupgrade's platform checks to avoid sysupgrade to success with incompatible bootloader version.
• and ASU sysupgrade be able to handle these bootloader version specific sysupgrade images.

I think the latter should be handled in on-board ASU clients (owut and Luci ASU) since you need runtime information to determine the running bootloader version?

A separate image profile and DTS (or a custom sysinfo board_name which check the running bootloader and generate a different board_name) could work, I think too.

How many cases do you know of profiles with multiple sysupgrade images efahl?

[map-b]

@corncobble So, can you confirm that to check the bootloader version you have efahl/owut#68 (comment)

root@RB750Gr3:~# cat /sys/firmware/mikrotik/soft_config/bios_version
7.20.5

but there is no /sys/firmware/mikrotik/hard_config/booter_version like the check done in the ath79?

[corncobble]

Someone who is more familiar with the RouterBoot flash layout (here) would be better for answering this, but I believe that /sys/firmware/mikrotik/hard_config/booter_version is the factory bootloader version that comes installed on the device when purchased and is not modified when applying bootloader updates via RouterOS:

root@OpenWrt:~# cat /sys/firmware/mikrotik/hard_config/booter_version
3.41

Whereas the current bootloader version is:

root@OpenWrt:~# cat /sys/firmware/mikrotik/soft_config/bios_version
7.20.5

More information on this is here.

But there are two bootloaders in flash (/dev/mtd1 and /dev/mtd3) and I don't know which is used when booting OpenWRT. If it is in fact utilizing the factory bootloader than perhaps it is unnecessary to run the v7 image, but then again would the v7 image even be working if that were the case?

[map-b]

Thanks for the info, it seems so. But the actual check implemented in ath79 are being done against the booter_version which would be wrong since that does not indicate the current RouterBOOT version? @dangowrt ?

• generic: support creating images for RouterBOOT v7 #20144