I just got a MikroTik RB5009UG+S+IN recently, especially because it was listed as a compatible device for OpenWRT.
Sadly, that's not the case for newer models. My router shipped with RouterOS 7.19.6. pre-installed, so I can't downgrade to ROS 6 and OpenWRT is incompatible with the RouterBOOT bootloader of ROS 7.
For some MikroTik Routers, there are now ROS 7 compatible versions (*squashfs-sysupgrade-v7.bin), but not for this model.
Is there any way to add RouterBOOT v7 support for this device? (custom compile)
No, it is more specific than that. The commit messages try to make it clear that the issue was with Mikrotik NOR devices (which boot OS from NOR).
I can't quite follow, the RB5009 is a NAND device, was the ROS 7 patch only developed for NOR devices..? NAND devices running ROS 7 are obviously incompatible as well.
This is a NAND device. Follow the commit message instructions mvebu: add support for RB5009UG+S+IN with the official image.
Which commit message instructions are you referring to? Doesn't this patch just add OpenWRT support for the device running ROS 6?
Is there currently a way to compile a ROS 7 version of OpenWRT which runs on the RB5009 or not? The wiki pages for this device and general Mikrotik device just suggest "use the *squashfs-sysupgrade-v7.bin firmware images", which doesn't yet exist for this device.
Jumping back in here, because I'm still not quite following the basis of the claim
The original post mentioned a squashfs-sysupgrade-v7.bin image that's supposedly missing for the RB5009. Looking at the current wiki entry for the RB5009, I can't find any reference to such a -v7-named image ā it still just references the regular squashfs-sysupgrade.bin file.
Looking at the linked commit, the flow actually seems to match exactly what's described in the wiki:
So U-Boot as an intermediate step ā no separate "OpenWrt v7 image" needed. I'm not quite sure where such an image would even come from or what it would be needed for.
For what it's worth, I can speak from personal experience here: my device was running RouterOS 7.20.7 or 7.20.8, and I successfully switched over to OpenWrt by following this exact wiki guide ā no issues at all.
If the existing wiki procedure genuinely doesn't work anymore on RouterOS 7.x for others: what's the specific error message you're hitting? Would love to hear more details ā just trying to figure out whether this is an actual technical issue or more of a precautionary assumption.
If you still have RouterOS in place, you can look for the oldest firmware your hardware can fallback to by : using Winbox, navigate to System > RouterBOARD
Although it is a setting for U-BOOT (ie. bootloader, not the running OS), the running OS firmware could not predate the Factory Firmware version listed in the box above. In this example, you cannot install any version earlier than 6.43 even if you wish.
=======
I believe RB5009 has a factory firmware of 7.0.x since release and there was no factory firmware in 6.x series for this product. See also this thread in Mikrotik forum.
I think the OP was talking about info in this Wiki page.
My suggestion would be for anyone running RouterOS 7 upgrade their U-boot to latest version in System > RouterBOARD, then select Upgrade. Then it will ensure they are running a bootloader that is newer than 7.19.6.
Although for RB5009, 6.x firmware was never supported since product release. See my prior post on how to check the factory firmware version released with a Mikrotik product.
Status 2026-02-10: The next OpenWrt release 25.12.0 (currently -rc4) current_testing_seriesopenwrt_2512
has additional sysupgrade images named *squashfs-sysupgrade-v7.bin that
should work with recent MikroTik RouterOS v7 bootloaders (successfully
tested on mikrotik_routerboard-mapl-2nd). The images
*squashfs-sysupgrade.bin (without -v7) are obviously for MikroTik
RouterOS v6 bootloaders.
Other Mikrotik devices received such system images, the RB5009 did not.
I'm not quite sure where such an image would even come from or what it would be needed for.
It would be needed to permanently flash OpenWRT (completely the NAND installation) using an image which is compatible with the RouterBOOT v7 bootloader. I can successfully boot OpenWRT using U-BOOT (but only using BOOTP, DHCP / USB boot aren't working either), but after flashing the sysupgrade image, the router is in a bootloop.
For what it's worth, I can speak from personal experience here: my
device was running RouterOS 7.20.7 or 7.20.8, and I successfully
switched over to OpenWrt by following this exact wiki guide ā no issues
at all.
If the existing wiki procedure genuinely doesn't work anymore on
RouterOS 7.x for others: what's the specific error message you're
hitting? Would love to hear more details ā just trying to figure out
whether this is an actual technical issue or more of a precautionary
assumption.
My router shipped with RouterOS / RouterBOARD / RouterBOOT 7.19.6.
I tried following the flashing guide for this device to no avail. It only booted U-BOOT using the BOOTP method described in the Mikrotik common Wiki. But after flashing the sysupgrade image using LuCI, the device entered a bootloop.
look for the oldest firmware your hardware can fallback
Mine shipped with 7.16.9, so that's the Factory Firmware and the oldest I can fall back to.
I believe RB5009 has a factory firmware of 7.0.x since release and there
was no factory firmware in 6.x series for this product. See also
this thread in Mikrotik forum.
Then this is very confusing and kind of contradicting information compared to the Mikrotik common Wiki:
OpenWrt is not compatible with the bootloader of RouterOS v7. Do NOT upgrade the firmware on your device to RouterOS v7 or, if you did, downgrade to RouterOS Firmware v6 before installing OpenWrt.
RouterOS doesn't allow to downgrade below factory firmware version, but OpenWrt boots and works fine with
versions up to 6.49.19 or beyond. Confirmed working: 6.47.10 (tested on SXTsq 5 ac), 6.49.19 (tested on RB750r2).
My suggestion would be for anyone running RouterOS 7 upgrade their
U-boot to latest version in System > RouterBOARD, then select
Upgrade. Then it will ensure they are running a bootloader that is newer than 7.19.6.
Because my router was stuck in a bootloop, I recovered it using Netinstall and it it's currently running Router OS and RouterBOOT version 7.23.1.
Should I just try to flash OpenWRT again? Why should the bootloader be newer than 7.19.6?
I tried following the flashing guide for this device to no avail.
Yes, like I said in my reply 5 minutes ago. This guide doesn't work, the router won't boot from USB nor DHCP, only BOOTP. That's why I decided to follow the Mikrotik common Wiki guide, because at least the described initramfs booting procedure on there worked. Then I just flashed the sysupgrade image in LuCI.
Would it have been necessary to execute the
I think I can see what went wrong ā and yes, the manual steps do matter!
When you flashed the sysupgrade image directly via LuCI, you skipped three critical steps that are specific to the RB5009 installation process. The RB5009 wiki guide requires you to connect to the running initramfs system via SSH first, and then manually execute:
Install U-Boot into YAFFS ā this permanently writes u-boot.elf into the YAFFS partition on NAND, so RouterBOOT always loads U-Boot on startup
Wipe the NAND UBI partition ā this removes the old RouterOS filesystem from NAND
Flash OpenWrt permanently ā only then run sysupgrade from within the SSH session
The SSH session is not RouterOS ā it's the OpenWrt initramfs system running in RAM after U-Boot loaded it. Once you can reach 192.168.1.1, you SSH in as root (no password) and run those commands from there.
Since BOOTP already worked for you, you're actually past the hardest part. With RouterBOOT 7.23.1 you should now be in good shape ā just follow the RB5009 wiki guide from the "Connect to the initramfs system" step onwards, and make sure to run all three manual SSH commands before doing anything in LuCI.
One more observation ā which I actually contributed to the wiki myself:
When using TFTP boot, you can follow exactly what's happening in the server log ā first u-boot.elf is transferred, then the initramfs image. The wiki guide explicitly points this out and states to keep holding the reset button until both files show as transferred in the log.
This is actually a very simple way to verify early on whether the boot process is running correctly ā before anything gets flashed at all. So if something seems off on the next attempt, that's a good place to look first.
If I read the Wiki correctly, the only part that may be skipped is Optional: Flash RouterBOOT with UART enabled -- but perhaps it's better to flash that too, so you can have UART serial access later on.
PS: There is a Github page on Unbrick your universally bricked RB5009. It was created to tackle the hard-brick situation arised even when Netinstall does not work. You should not need this, but I just put it here for reference.
Understood, thanks you two! I will try again this weekend.
When using TFTP boot, you can follow exactly what's happening in the server log ā first u-boot.elf is transferred, then the initramfs image.
That's the thing, when booting over DHCP, the router won't request the u-boot.elf file. It gets and IP Adresse no problem, but it didn't request tftp once. When using BOOTP it worked immediately, but then it was stuck sending the u-boot.elf over and over again. I had to restart the tftp service and then finally the initramfs image was requested. This took me about 15 hours to figure out. And booting over USB also didn't work, it just booted straight into RouterOS...
Just thinking: Maybe try another USB stick and format in FAT32 to see if it can work. Of course, you should be able to detect this USB stick inside RouterOS as confirmation.
I seems like I can't edit this thread title anymore to make it reflect the actual problem.
Flashing by following the RB5009 Wiki worked like a charm, in 5mins I was up and running.
Maybe I will look into how to contribute to the Wiki, I would like to add a few notes to resolve some contradicting information and add the tip to try BOOTP if DHCP/USB booting fails.
