I was able to boot Ampere/ARM64 ISO on Qemu with KVM acceleration: https://github.com/ayufan-research/mikrotik-qemu-arm64. Works just fine. Tested on Raspberry PI 5 and Rock 5B.
I tried on Equinox Metal, but couldn’t get it work. I do not think it’s Mikrotik fault… Metal uses iPXE with netboot.xyz for custom OSes. I use VMWare on X86… so I gave up quick since I don’t know iPXE stuff (although similar problem as here – what’s the kernel & initfs to use for RouterOS ). But kinda did want to see it boot on something before spelunking on ARM Mac. But no success on Metal.
I don’t have an ARM Mac handy, but next time I can check I’ll see what happens. At the end of the day, Apple Virtualization needs some EFI executable file and a ramdisk with RouterOS file system (e.g. routeros.npk uncompressed AFAIK) — just how it find/pick them may be tricky align.
Thanks for sharing your scripts. Some working examples always help.
FWIW… this is a likely a good call:
... qemu-system-aarch64 ...
-vga none -nographic -monitor none
-serial chardev:term0 -chardev stdio,id=term0
RouterOS X86 seems to have problems with VirtIO displays (e.g. on Apple, some Hyper-V, etc) — doubt that be fixed in ARM64.
Still… might be worth a check to see if virtual display actually works with “Ampere”+QEMU
I have a Studio and MacBook Pro. You’ve given me a couple ideas to try. There is an efiboot.img on the ISO. It also has all the packages on the ISO. Kernel boots on Apple and on QEMU but doesn’t know where init is.
I’m not expect here, but re-packaging I can do. I added ZIP file output to my GitHub “X86 UEFI CHR builder”, while it doesn’t have symlinks and stuff. If you extract the ZIP file, you can see how the IMG get’s structured without mounting the disk on Mac (since it’s cannot read the 2nd partition):
https://github.com/tikoci/fat-chr/releases/tag/Build8160661125-testing
The CHR ARM64 ISO has a very different structure… My wild ass guess is somehow though the sysconfig stuff it mounts routeros-7.15beta4-arm64.npk as the ramdisk. While it ends in .npk, it’s still a normal LZMA compressed file (e.g. 7-Zip) that EFI boot loader tries to find.
But I’m really not the expert on UEFI and Linux boot details, especially on ARM64… If someone figures out the magic sauce, I can automate it.
This is likely problem of UEFI or HVF accelerator implemented in QEMU on MacOS.
In general if you disable Use Hypervisor kernel will boot. The UTM requires to use NVME disk for storage, and I was not able to configure CDROM. I cannot force UTM to use virtio-blk-pci for CDROM device. Once you install (somehow) the ARM64 MikroTik will boot in non-hypervisor mode via UTM.
sysconfig for x86 is to boot via legacy BIOS.
OK. You can boot/install via UTM:
- Create new VM => Virtualize => Linux.
- For Virtualization Engine: Keep
Use Apple Virtualizationunmarked. For Boot Image: Select arm64.iso. Then, continue. - Set min 512MB of memory, and at least one CPU core, at least 1GB of disk size. Then, continue a few times.
- Edit then VM Settings.
- In QEMU, unselect Use Hypervisor.
- Go to Display, and click Delete. Then go to Sound and click Delete.
- Under Devices, add Serial.
- Go to VirtIO Drive, change Interface to NVMe.
- Go to USB Drive, and Delete. This remove the iso image.
- Under Drives, click New. Select VirtIO, click Import, find mikrotik-arm64.iso.
- You should be able to start and install. After you install, you can remove the ISO drive.
Of course Hypervisor will not work, so the performance will be slow.
Sweet. I got it installed and booted.
Now to figure out how to boot it under Apple’s Virtualization Framework to get closer to the CPU.
Works for me as well, but I almost forgot that ROS is payed software - we need CHR for ARM 
With CHR using x86 emulation we can play for free and boot time is similar to that ARM.
Just for fun, I tried the ARM64 ISO, emulated in UTM on Intel Mac — WORKED.
Instructions almost just work on Intel UTM with QEMU emulation… Clearly the NVMe disk seem required (tried IDE or VirtIO – neither worked). But for Intel UTM, the ISO image seems to need to be first converted manually to a .qcow2 with VirtIO for the 1st partition to boot before importing it.
qemu-img convert -O qcow2 mikrotik-7.15beta4-arm64.iso mikrotik-7.15beta4-arm64.qcow2
Now for Apple Virtualization on ARM MacOS… My best guess is the new RouterOS “ARM64 ISO” is missing a needed “virtio_blk.ko” (at least doesn’t appear in ISO or any .NPK)
And since VirtIO is only* disk option on Apple Virtualization, kinda problematic (*if there isn’t virtio_blk, there isn’t NBD in RouterOS, while NBD is supported by Apple’s APIs, it’s not in UTM with Apple VM set). Explain why QEMU seem requires NVMe emulation to boot in UTM…
I think the “ARM virtio disk problem” is same problem as video one: just another missing different virtio driver…
Sorry
Secure warning !!
Be careful if you download images other than from the official Mikrotik one.
warning secured…
The step 10. does this conversion (or rather attachment of RAW).
The NVMe device is required as MikroTik requires some Serial Number to be configured to get Hardware ID. The VirtIO does not allow that.
I’m personally running ARM64 variant on my Rock 5B now via KVM virtualization, and it achieves maximum throughput!
Yeah that may be a bug in UTM (or gremlins)… it seem to try to convert it, and then reports in dialog it cannot find mikrotik-7.15beta4-arm64_.qcow_. Just something I noticed. (Keep in mind, I tested on Intel Mac using emulation, so may not happen on ARM Mac)
Ah yes, the license scheme is different. Which also makes sense why there isn’t a virtio blk driver for it either.
Nice! There is hope.
I’ll have to try it via KVM on my SolidRun Honeycomb LX2 that’s collecting dust. It doesn’t support UEFI boot and their UEFI shim is out of date. Otherwise I’d have spent some more time on booting it natively.
Via KVM it works just fine. No objections there, and especially a better idea for something that will rather be unsupported by MikroTik.
I personally think it better to always use a hypervisor. In years of using Mikrotik, never once tried metal X86 before here.
Mikrotik need to just build a ARM64 CHR version of “AMPERE”, since it’s not just Apple where this comes up.
And the “security warning” in this thread on UEFI image… easily fixed by Mikrotik changing their build to add one more CHR image with FAT as boot. I put GitHub on that task, and since CI runners are free in public project, easy to share. FWIW, the entire build process is observable/auditable, but it’s a fair warning. And I’d rather not be involved package building.
And it is also possible to compare checksums from original files is someone is concerned…
I made a tiny bit of headway trying to boot the installer on my Honeycomb LX2.
Using a UEFI image from SolidRun, the ISO boots via USB. It looks for an NVMe drive (SATA are ignored), and then burps because it can’t find the CD-ROM.
Based on what we saw with QEMU, I wonder if it expects the CD-ROM to be on the PCIe bus or something. Booting from a SATA drive doesn’t make a difference. Going to try two NVMe drives just for fun.