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

[Natalia Portillo]

El 21/08/2011, a las 01:50, Rob Landley escribió:

> 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?

No, CP/M's BIOS just initializes the hardware.
BDOS contains the drivers.

PC BIOS do the same.

Toolbox initializes the drivers, contains the HAL, the kernel, the resource 
fork manager, the window manager, the mouse pointer, the quickdraw functions.
It's like having Windows 3.1 in ROM and the explorer.exe on disk.

>> 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?

Yes, Mac OS must load Linux, not a bootloader.
If Mac OS don't work, your chances of getting Linux to work (on a REAL 
macintosh emulator) are close to 0.

>> 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?)

Read it again, on Basilisk, Linux will find no storage device at all, no video 
device, no serial device, no nothing :p

>> 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.

That isn't so simple in Macs

>> 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.

So the answer to your questions is simple:

You don't want a macintosh emulator. :p

>> 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.

Check Linux-m68k, only one works on macs, whatever the other ones do have a 
driver or not, only one works :p

>> 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?)

As far as Mac hardware is concerned, and Linux-mac-m68k is concerned, if you 
don't have both, it will not boot.

You can create a m68k target designed specifically for your Linux-m68k needs, 
but you have stated clear that a mac-m68k target is not what you need at all :p

(Have you read Linux-m68k compatibility pages? It's compatible with 5% of the 
models, 10% of the hardware at most.)

No offense I think you're confusing things.

If you just need to boot Linux-m68k, a development board is a simpler, easier, 
faster to implement, and more suited to your needs, than Amiga, Atari or Apple 
hardware emulators (existent or not).