That's tricky. My friend did this with the C64 (BMC64) by making VICE run basically as a unikernel on the Pi. It's a lot of work. There's payoff there for something like the C64 where latency is super important for video games etc. But on the ST, I dunno if I see the advantage esp if you're running MiNT etc.
If you mean actually running the OS sans emulation, like a port of TOS/MiNT to ARM; I actually started down this road many years ago, trying to port as much of EmuTOS over to native ARM as I could... and others have fiddled with it, too. But it's a huge endeavour with little payoff. There's no binaries to run, so you'd end up hosting an emulator in it, and the endianness is entirely different so it's just... awkward. I found the transition to 32-bit and little endian and totally different graphics hardware made much of the EmuTOS sources useless.
Take something like the AES. It uses 16 bit big-endian values throughout, hardwired into C-structs, basically. And this maps 1:1 with resource file contents. You either have to rewrite everything incompatible with ST-AES and resource files and use 32-bit little endian. Or you have to be constantly swizzling values back and forth. Or do both. Awkward.
Or the VDI that's written there. I actually made "ok" progress writing a fresh VDI from scratch for the Pi framebuffer. But then... what's the value? The API is not really compatible because word sizes, framebuffer depth etc. It just starts to look really anachronistic.
Better to just build something new.