> On Jan 3, 2024, at 9:16 AM, Jason Thorpe <thor...@me.com> wrote:
>
> There’s really nothing Qemu specific about it, other than Qemu version number
> extraction.
Let me elaborate, actually, now that I am not constrained by thumbs-only typing.
It uses the generic Linux m68k “bootinfo”, which specify the machine type and
address of the various devices, and provisions for how reset/halt are handled
are also dealt with generically. Every Linux m68k platform uses this mechanism
and I would be shocked (SHOCKED) if some hypothetical future non-Qemu m68k
VirtIO platform did not support Linux natively. The Qemu version extraction is
actually done with one of those “bootinfo” records.
There are really only two assumptions that are made:
- RAM starts at PA $0000.0000, the kernel starts with the MMU disabled, and is
loaded at its link address.
- I/O devices start at PA $FF00.0000, and that they can be mapped VA==PA with a
TT register.
The latter would be pretty easy to deal with dynamically if the situation
arose. And the former would be possible to adapt to if that assumption were to
suddenly not be valid. Heck, the hp300 kernel is linked at VA=$0000.0000 and
knows how to deal with the start of RAM varying based on how much memory is
installed (whereas the end of RAM is always at the same location, at the top of
the physical address space. Weirdos.)
-- thorpej