That’s pretty much what I have (plus a 2nd RB5009 as a backup) and no issues whatsoever after upgrading to 7.19. So go ahead!
In fact, I have been using RouterOS for more than ten years, and I have never failed to update the system and firmware from winbox, so I don’t think there is any need to worry too much. This time, I downloaded the firmware and updated it from an unconventional channel, which led to the failure.
As is written above: The bricking issue is not related to the 7.19 release but to having upgraded your protected RouterBOOT environment which you shouldn’t have done on a RB5009.
You have an appropriate avatar 
, Bork, bork, bork! 
Let me see what I can do.
The hardware required is pretty simple. Just a USB to TTL adapter (I use a cheap $3 one off AliExpress, but most local DIY Electronics shops carry them as well) and a USB Flash Drive are required.
From a software perspective you’d need Linux. I don’t have Windows and I’m not very familiar with it, so I can’t really build anything for that.
It would seem so. It also wiped a bit more than 600KB (about 638KB), so it’s both the ATF and a chunk from the start of the backup bootloader that is gone. I think the way RouterOS exposes the flash to the OS is that it just exposes a contiguous 1MB chunk of it, so it doesn’t have each component broken out as a single partition like OpenWrt has.
The MikroTik provided ATF does not boot the device when provided via UART. I did try that.
So I had to build my own ATF with U-Boot embedded (like the OpenWrt folks did, I didn’t figure this out on my own).
I added two partitions to the DTS file for the RB5009 (target/linux/mvebu/files-6.6/arch/arm64/boot/dts/marvell/armada-7040-rb5009.dts) to expose the ATF+backup boot section as well as the entire flash:
partition@1 {
label = "atf_bb";
reg = <0x0 0xaf000>;
};
partition@2 {
label = "full_flash";
reg = <0x0 0x1000000>;
};
That allows you to dump the entire flash with dd for backup purposes as well as writing the ATF+bb back to the device using mtd.
You have to build your own ATF. The bootloader payload is embedded as BL33 as part of the build process. In my case I used U-Boot which boots my OpenWrt build from a USB flash drive.
The process is described here: https://forum.openwrt.org/t/add-support-for-mikrotik-rb5009ug/104391/193
This creates a flash-image.bin which you can then pass to the mrvl_uart.sh tool:
./mrvl_uart.sh /dev/ttyACM0 flash-image.bin
Uploading takes about 2 minutes via UART but then it boots off of a FAT or ext4 formatted USB where it looks to find a “openwrt-mvebu-cortexa72-mikrotik_rb5009-initramfs-uImage.itb” file.
Usually it takes good timing to catch the moment when the router accepts the magic packets from UART to go into UART recovery mode. But 5009s broken by the universal package will automatically go into that mode and then you have all the time in the world to launch the mrvl_uart.sh script.
I’m sure a u-boot script could be made that automatically flashes back the broken part, for those that don’t want to mess with OpenWrt. I wasn’t able to use the ext4write function in U-Boot to write a backup of the SPI NOR back to the USB flash drive. It just crashes with an error in the USB stack. That’s why I went for OpenWrt instead.
just for my understanding … i still have a RB5009 that i want to upgrade to 7.18.2 … are the downloads from here “safe” ?
https://mikrotik.com/download/archive
Yes, those are just fine. The issue getting all the attention is something completely different.
Here’s my guide for recovering the device: https://github.com/kaechele/rb5009-unbrick
Let me know if it works for you and is fool-proof enough.
Just tested it again on my 5009 and it works there.
That’s a nice bit of engineering work. With the static binary and everything. Kudos!
Bonus points for the Latvian saying.
Very good work! 
Besides the good engineering work, the Latvian proverb is a touch of genius. 
If I may make a suggestion, you should put some better reference here (possibly with a link to the forum thread):
MikroTik distributed a backup bootloader upgrade on their support Wiki which supposedly was “universal” and for all platforms. Unfortunately, when applied on the RB5009 it erases the ATF and Backup Bootloader and renders the device unbootable and unrecoverable via Netinstall.
Something like
Around the first week of May 2025, Mikrotik distributed a backup bootloader upgrade on their support Wiki which supposedly was “universal” and for all platforms. Unfortunately, when applied on the RB5009 it erases the ATF and Backup Bootloader and renders the device unbootable and unrecoverable via Netinstall.
Mikrotik Forum discussion topic:
RB5009 cannot enter the system after restart
Thanks! I added a reference to the forum based on your suggestion.
You sir are freaking amazing! I’m all restored and living the RB5009 life again. No RMA with shipping costs and weeks/months of service time. Just like 15 minutes of time and done. I even learned that you can take an Arduino and short the reset and ground and you have an improvised USB to TTL adapter. So easy and so happy to have recovered the device. Cannot convey my true gratitude for your ingenuity, time, and willingness to share. Nothing short of legendary!
BRAVO
lol - “RMA” indeed. Nice bit of work there felixka, thankfully the OpenWRT folks are hard core
Don’t quote me on this but I think a raspberry pi’s gpio serial pins could also be used to get at the rb5009 console, for those of you in a jam and without a proper TTL adapter laying about.
Edit: Ah - looks like the recovery binary in felixka’s repo is x86_64 only, so using a pi is no go, unless you recompile the recovery binary as arm.
mvebu64boot command (provided in this repository as a static x86_64 binary)
Let it be clear: I posted that article that you point to, but it clearly says: "so when you get those warnings about NAND stability after an upgrade, now is the time to upgrade the bootloader to fix that"
Then, when you started listing the type numbers of routers that support it, I posted: "You only need to upgrade the backup bootloader when you got one of the error messages"
It was YOU (rextended) that spread the FUD "There is more underneath (unsaid, don't ask) that makes it worth updating."
That is probably what made people upgrade their bootloader without having any issue with the existing one.
I personally fell victim to that thread (regardless of who wrote what). I thought it was some new evolution in the new mode restrictions. When I went to the help page, I further believed that this was some new evolution in bootloader security and figured it certainly wouldn't hurt to install given how simple that installation is. If my device didn't need it, it would either ignore or it would just reinstall it over the existing one. That's how things normally tend to work. So, yes, I will take some heat for my decision and perhaps not having read closely enough. But I've inadvertently installed same version software on many devices before and merely been greeted by an error message explaining my idiocy. Never had something destroyed by doing so. My biggest heartburn was the response for Mikrotik. I never would have expected the tone and "our bad but you're stupid" messaging.
@pe1chl
I want to be clear and precise: I am not saying that this is your error in any way.
By the way, as you can see, I also tried it personally on the RB5009, and it seemed to work… Until I turned it back on day after when I read the problem on forum…
What I was referring to is written here,
http://forum.mikrotik.com/t/v7-19-1-stable-is-released/183849/1
and is for this: (now fixed)
http://forum.mikrotik.com/t/netinstall-on-rm3011-fails-need-help-technical-questions/183302/1
but it is difficult to blame the users or the forum,
also because none of us have put a direct link for the download of the file,
but to the help section where everything is explained…
and to find the right link you still had to search the document and read what is written…
And everything was well written even before MikroTik added the text a little.
I think that it is wrong or at least useless to analyze this accident attempting to put the blame on this or that forum user or this or that line of text or its (mis-) interpretation.
Accidents often happen because of multiple concurrent causes or because the preventive measures and appropriate procedures (that should be there) were incomplete or not correctly implemented or a particular event came out unexpected.
The main thing is instead IMHO understanding WHY It happened and change adequately the procedures in such a way that a similar accident has less probabilities to happen again.
I get an error like “bootrom did not respond” after it recognized the rb5009 and tries to upload some bits.
I suspect my cable, but maybe anyone has a better idea. I use a RS232 to TTL cable and power it with 3.3v from the RB5009.
That very much sounds like a bad contact interrupting the transfer.
By the way, the “7.18.2” Factory Firmware string that’s now in the hard config can simply be replaced with 7.0.5 with a hex editor and written back to flash if it bothers anyone. Worked fine on my end.