> 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

Reply via email to