To bring up each new build target, the creators of your container build toolchain of choice must bring together:

* a QEMU emulator for the target system
* a sufficiently complete Linux distro ported to that target
* the `binfmt_misc` kernel modules that tie these two together

QEMU is “easy” in the sense that the hard work has already been done; there are QEMU emulators for every CPU type MikroTik ever shipped. ([Details](https://www.qemu.org/docs/master/system/targets.html)) There’s a partial exception with TILE, which once existed in QEMU core but has been removed for years, following the removal of TILE support from the Linux kernel. The thing is, TILE hasn’t progressed in the meantime, so bringing up a QEMU TILE emulator should be a matter of putting in the work to port it to a decade-newer version of Linux.
QEMU is “easy” in the sense that the hard work has already been done; there are QEMU emulators for every CPU type MikroTik ever shipped. ([Details](https://www.qemu.org/docs/master/system/targets.html)) There’s a partial exception with TILE, which once existed in QEMU core but has been removed for years, following the removal of TILE support from the Linux kernel. The thing is, TILE hasn’t progressed in the meantime, so bringing up a QEMU TILE emulator should be a matter of digging that old code back out of source control, then putting in the work to port it to a decade-newer version of Linux.

The binfmt piece is also easy enough.

That leaves the Linux distros for the target platforms used as container base images. That’s the true sticking point.

One of the most powerful ideas in the OCI container ecosphere is that you don’t cross-compile programs, you boot an _existing_ Linux distro image for the target platform under QEMU, then use the native tooling to produce “native” binaries, which the `binfmt_misc` piece then turns back around and runs under QEMU again.