Does anyone has experience with OpenWRT on a Mikrotik mANTBox 15s / RB921GS-5HPacD-15S serial number ending on /r3
In the fora I only see thing about /r1 and /r2. Is this a new release?
I managed to install OpenWRT on it, but it does not see a wi-fi chipset in the kernel log.
I managed to boot the ar71xx initramfs from 19.07.08. But then I am successful in doing any sysupgrade. When I do a sysupgrade with 19.07.08 image then mANTBox is rebooting but after 10sec it is rebooting again and now with RouterOS. Looks like something went wrong while booting the sysupgrade image and as fallback RouterOS is started.
With 21.02.0 there should be an ath79 initramfs image but this image is missing in the official download folder. Don't know why. Maybe we should build it by ourselves and try it out.
We managed to install OpenWrt on /r3. It works with OpenWrt 21.02.0 ath79. As of today there is no official image for rb921 for download (https://downloads.openwrt.org/releases/21.02.0/targets/ath79/mikrotik/). Maybe this is some bug in the build system.
But if you build the image yourself then you can flash /r3 mANTBoxes.
@monomartin and @rodebiet - thanks for this thread!
I've just brought a bunch of the r3 devices after testing on r2!!! Of course, I'm grateful that you guys have confirmed that r3 is workable - albeit that the images are not built.
Can I ask you to point me in the right direction of how to build the image for the Mantbox 15s /r3 device? I can boot to an elf via DHCP/TFTP (doesn;t see Wifi) but then I now need the correct .bin to flash.
Thanks in advance!
T
To build the image do the following:
If you follow all these steps you should find the compiled image in bin/ dir, see https://openwrt.org/docs/guide-developer/toolchain/use-buildsystem#locating_images
HI, i'm build image with 21.02, but he's just always rebooting.
P.S.: kernel-initramfs normal load after bootp
@Spblizard - I fear I'm having the same issue as you.
So we had to remove ldconfig-stub from the makefile include to get it to work....but it then build cleanly - producing...
openwrt-ath79-mikrotik-mikrotik_routerboard-921gs-5hpacd-15s-initramfs-kernel.bin (SHA1: 07AC2A9A5353D31930191BEACEC02746E6DA6C28)
openwrt-ath79-mikrotik-mikrotik_routerboard-921gs-5hpacd-15s-squashfs-sysupgrade.bin (SHA1: A5DA0FDD0EB31785F1B34BFE7E1A3C861E6555CA)
---So - I booted from an ELF file (openwrt-19.07.7-ar71xx-mikrotik-vmlinux-initramfs.elf to be precise)....then logged in and tried with each to flash
--- got the "force upgrade" red message in OpenWRT when trying to flash. I forced it.
--- But it never came back.
So alas - I seem to have failed at the first hurdle.
If any of you guys have managed to make a bin (sysupgrade bin) which has been tested working on the r3 hw - and would be happy sharing it - I'd be ever so ever so grateful....
Thanks
Tris
Can you try the following sysupgrade image: https://drive.google.com/file/d/1BgkfniGUUF6dZ4nuhGF1fRzg6_7Z9DD_/view?usp=sharing ? Click on the download link on the top right to download the image file.
@monomartin - thanks again for this. Sadly - no dice. But I have a knowledgable OpenWRT consultant working on this for me right now - so if we make it work...I'll share. Seems @rodebiet that the builds don't auto-build anymore for the NAND based devices (see https://openwrt.org/toh/hwdata/mikrotik/mikrotik_rb921gs-5hpacd-15s where it says "NAND snapshot image build disabled with commit 9d96b6fb720d9cecc" as it seems there can be issues with OpenWRT killing the nand-chip with too much writing to the NAND......I'm paraphrasing)
So - with quite a number of the r3 devices sitting here - even if our man can build a working image for OpenWRT - I'm not happy deploying a bleeding edge version into production - and may roll out preinstalled RouterOS until OpenWRT has been properly stress tested. Pity. We tested r2 for months (with 802.11r and everything) - and then we ordered a bunch and the r3 arrived! DOH! Lesson learned with Mikrotik and their randon hw revisions.
thanks again everyone - I'll post more if I get there!!!
NB - here's my hardware label that we've got.....would be useful to know we're all shooting for the same star!
Hello @trissyruss,
for the root cause please see:
Which points to the respective commit and detailed explaination:
Basically you can brick the device during flashing. We do have here currently a small install using also a couple of r3s very nice to hear you are working with DEV on the issue and hopefully we will do see some basic/better support for YAFFS 
As for the HW change: This looks quite normal to me looking back at many different embedded hardware manufactures. Most popular devices do change some chips and pieces over the time. Seams unchanged since 15+ years. Since we currently also are in an apoch of the so-called 'chip crisis' I personally would not blame Mikrotik - they even might were forced to work around the lack of some chips.
Nevertheless: Really enjoyed your message and hope you can manage it with the DEV. Let as know if we can help somehow or may be provide some small funding / hardware sponsoring e.g. (I'm working at the same installs as @monomartin for a community project). Currently running here four r3 devices at a "burn in test" at home.
Have a great day.
Hey @mathiashro
Thanks for your kind email and good work.
I agree on the Miktrotik chip-change (prob due to global supply issues) - and furthermore we (as hackers!) cannot rely on them for consistency of hw. Same applies for all other manufacturers of course ,esp those who wish to prioritise their own (chargable) OS.
In our case - we have 140 of these babies ready to deploy! So I'm going to work on the OpenWRT - but - I think we'll be using RouterOS/CAPSMAN and DUDE to manage these devices for the time being....
We'll keep y'all posted!
We do have here currently a small install using also a couple of r3s
Did you manage to get OpenWRT running on these? With the bin image that @monomartin shared?
Cheers!
I have not dealt with any of these Mikrotik ath79 NAND (YAFFS) devices, but I can give you a few hints:
First thing you want to check, is that the NAND chip is supported, and it's flash parameters match what is expected? see dmesg | grep nand
I know that some rb450gx4 Mikrotik devices have NAND chips with 128k blocksize + 2048 pagesize, others use NAND chips with double these parameters… so they do do this.
If RouterBOOT is reading NAND for kernel with different parameters to what was written (kernel image settings here, kernel2minor params), it probably won't work, and (with default RouterBOOT boot device settings) the fail reading a flash kernel will boot from network.
If you detail a little more we can narrow down what might be happening: If you leave RouterBOOT settings as default (boot flash-then-eth-if-fail), and force netboot through the hardware button, or eth-once RouterBOOT setting, then run sysupgrade: The device will reboot by itself when sysupgrade succeeds or fails. If device then immediately requests netboot file again, it could not read kernel from flash. This means the RouterOS kernel was erased, but there was a problem writing (or RouterBOOT reading) the OpenWrt kernel. Maybe NAND params mismatch, or too many bad blocks, or something else.
You could then netboot OpenWrt again, and read back the NAND kernel partition to check that it matches what was written.
Your best path to debug this is to connect to serial console to see if something is failing in sysupgrade: kernel is written here. This most likely means soldering leads on to the pads on the board.
To get RouterBOOT to output to console (on hardware without advertised console), you can flip the no_uart bit in the hard_config SPI NOR partition. You could do this with kmod-mtd-rw: read a whole eraseblock, flip the bit, erase that block, then write back your modified block.
Otherwise, you can step through the sysupgrade process manually over ssh, to see if something is failing.
Edit:
You also want to check that your initramfs image includes nandwrite from the package nand-utils. A builtbot settings (CONFIG_TARGET_MULTI_PROFILE,
CONFIG_TARGET_PER_DEVICE_ROOTFS, CONFIG_TARGET_ALL_PROFILES) initramfs does not include DEVICE_PACKAGES
Hello @johnth,
as for our installs (@monomartin and I) the R3 version is flashed successfully and running on four devices. No upgrade or first time flashing task outstanding.
But looking forward for general support / resolution of the YAFFS blocker....
Regards,
Mathias
As long as they are using YAFFS for whatever reason and RouterBoot only knows how to boot YAFFS then I doubt you will see official images as there is no YAFFS support upstream (And it looks like there never will be) so using the current image where you statically pack the rootfs is really risky on NAND as you can easily write part of the rootfs on a bad block
