qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions


From: Rob Landley
Subject: Re: [Qemu-devel] [RFC][PATCH 000/111] QEMU m68k core additions
Date: Sat, 20 Aug 2011 19:50:18 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11

On 08/20/2011 07:23 PM, Natalia Portillo wrote:
>>> Linux requires the MMU and an almost complete hardware emulation.
>>>  Standard m68k emulations (UAE, Aranym and specially BasiliskII)
>>> try to patch the OS to work.
>> 
>> That's kinda sad.  Is there a web page anywhere that elaborates on
>> this?
> 
> It is a known thing that Linux requires MMU, it appears on the
> installation guide of all m68k distros. On how and how much they
> patch the OS, check their sources.

Actually coldfire was nommu and thus m68k was one of the first nommu
platforms.  But what I was talking about was patching the OS.

The aranym patches (that i saw) were adding new virtual device drivers.
 (A bit like virtio, only different implementations.)

>>> Indeed BasiliskII is anything but a real macintosh emulator, as
>>> it patches heavily the Toolbox and Mac OS (that's why Linux and
>>> A/UX will never work on it)
>> 
>> I believe toolbox is the ancient mac bios, correct?  Does Linux
>> need/use it at all?
> 
> Yes and no to both. Mac OS is a really complex operating system where
> everything is divided in little pieces that can be loaded
> individually and independently (the Grand Unified Model, the reason
> why resource forks exist). Toolbox is the most important part, the
> one that resides inside the ROM chip, provides the specific model
> drivers (and in the II models, loads the video driver from the NuBus
> card), and loads the rest of the system from the System file inside
> MacOS.

CP/M got split into the BIOS and BDOS halves when Imsai asked Digital
Research to give them a driver pack they could tailor to their
non-Altair hardware, and then the other half could be board-independent.

This seems similarly relevant?

> It does not expect a boot loader, it's the OS itself, indeed in an
> specific model the whole OS is contained in ROM.
> 
> There is a table for OS functions that can be made to point to ROM
> (implemented on Toolbox) or in RAM (System file, bug or functionality
> updates).

Linux is an OS.  It generally doesn't call much out of PC bios or
openfirmware and so on after it boots up.  You're saying m68k is different?

> BasiliskII patches that table inserting their own functions (for
> example, the floppy driver is "enhanced" to provide access to the
> host disk images, instead of calling to the SWIM chip that will
> manage the floppy drive in a real macintosh).

I'm not even building the floppy driver in my kernel .config.  Does
Linux really have to use this table instead of having actual drivers
that run the chips?  (You're saying Linux calls the apple bios to access
devices?)

> The Linux bootloader is nothing more than a Mac OS application that
> loads the Linux kernel and gives it access to the full RAM, where it
> can (and as you see in the compatibility list, does not so well)
> access to the whole Macintosh hardware bypassing both Toolbox and
> System.

Real hardware needs bootloaders, yes.  Read hardware tends to use uboot
and grub and so on depending on your platform.

On qemu, we have the -kernel option that loads a kernel image into the
emulator's ram, and jumps to its entry point.

> Not long ago some people discovered a way to substitute the System
> file (RAM portion of the OS) so the Toolbox loads directly a Linux
> kernel. This is buggy for a lot of reasons (that was never the
> intended way, in-ROM drivers may be too buggy, so on).

Or you can go "qemu -kernel" so it can call load_elf() or similar.

> Apple UNIX (A/UX) on the other way provides a full System file
> (corresponding to Mac OS 7) and then loads its kernel, retaining the
> original table in memory for Mac OS applications compatibility and
> the GUI (yeah, while it's a UNIX and contains X11, native
> applications can be made that while being A/UX ones, use, calls and
> depend, on the Toolbox and System functions :D)
> 
> So unless an emulation is complete enough to make the Toolbox happily
> load a System file, it cannot be called a Macintosh emulator. It will
> be merely a custom-hardware-emulator capable of running Mac OS
> (BasiliskII) or Linux-m68k (nothing implemented right now).

I'm looking for an emulator capable of running Linux-m68k, yes.

> Saying this of pure memory, BasiliskII patches (and so, does not
> emulate them really) the following devices: floppy (calls host disk
> images, not a floppy emulated device, whatever if the image is an
> hdd, floppy, or cd, it appears as a floppy to the OS),

Linux can loopback mount floppy images, so all I really need is an
arbitrary block device that's big and reasonably well performing.  SCSI
works.

> SCSI (there is
> no scsi emulated at all, the driver is patched to call to host ASPI
> devices),

Linux has drivers for rather a lot of scsi chips, we just need to map it
at the right location for the driver to find it.

> framebuffer (any combination is available independently of
> the Toolbox's expected one),

I'm using a serial console on all the other targets.

> NuBus (not present or patched at all),
> sound (not DAC at all),

Not expecting to use either.

> network (again, no network card at all),

Wikipedia is of the opinion there was one via fairly generic chip.
Might even be true, who knows?

> graphics accelerators (none emulated, requires NuBus), filesystem
> code (to make the host folder appear in desktop).

Linux has filesystem drivers.

> Btw, vMac is more loyal to real hardware emulation.
> 
> And the hardware, and the whole Toolbox and System are heavily
> documented up to II machines in the Inside Macintosh Volumes.

Again, this is about running an ancient macos version I haven't got a
license for.  Half the OS was in ROM the other half was on disk.  As far
as QEMU is concerned both are files you load. (One as -rom one as -hda
or similar... not my problem?)

Rob



reply via email to

[Prev in Thread] Current Thread [Next in Thread]