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

[Rob Landley]

On 08/20/2011 09:02 PM, Natalia Portillo wrote:
> 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.

The bios contains the drivers necessary to talk to the hardware you need
for booting.  BDOS didn't duplicate drivers that were in the BIOS, there
was no room.  It continue to use them.

DOS started as a more or less clone of CP/M, and continued to call into
the BIOS for things like disk access.

Linux, running on the same hardware, did not use the BIOS, or DOS, after
boot.  LOADLIN was one option for booting Linux, but not the only one.

> PC BIOS do the same.

DOS continues to make fairly extensive use of BIOS calls after boot.  I
used to program for DOS, I know this firsthand.

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

And Linux uses neither.  Why would the mac be different?

I'm aware there was an early microkernel-based mac port in the early
90's back before Linux had its 1.0 release, but that wasn't what got
merged into the kernel.  Linux supports m68k on Atari and Amiga as well
as old mac, it doesn't need MacOS installed on Atari or Amiga.  It has
drivers, which talk directly to chips.

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

I don't want a real macintosh emulator then, I want qemu to emulate an
m68k and give me a board I can get a shell prompt on.  I don't care if
it's closer to amiga, atari, or mac, since all three share the exact
same binary identical root filesystem (at least when you're not using
x11 and the drivers therein) and the only difference is kernel .config.

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

Ctrl-alt-google, read the technical manual...

  http://basilisk.cebix.net/TECH

Quote the technical manual at you:

  More precisely spoken, MacOS under Basilisk II behaves like on a Mac
  Classic or Mac II because, apart from the CPU, the RAM and the ROM,
  absolutely no Mac hardware is emulated. Rather, Basilisk II provides
  replacements (usually in the form of MacOS drivers) for the parts of
  MacOS that access hardware.

The reason Linux does not find any devices is because basilisk does not
emulate any devices.  This is because Basilisk is not a real emulator,
and when you say "on a REAL macintosh emulator" above, I do not think it
means what you think it means.

  http://tvtropes.org/pmwiki/pmwiki.php/Main/DidNotDoTheResearch

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

This is how hardware works.

Look, on power up, a timing circuit holds the processor's reset line
until current supply and distribution stabilize, then it releases it to
start executing code in a known (simple) state at a known location.  The
caches and MMU is generally disabled during this, and on SMP systems one
processor is designated the boot processor and the rest remain halted.
The physical address the boot processor starts executing code at has
non-volatile memory mapped at that location containing bootstrapping
code.  (You can work around all this with a jtag and crank the bus by
hand from an external source, but this is how self-contained systems boot.)

The boot processor starts by initializing the DRAM controller (unless
the system has only SRAM, which is basically only really small embedded
systems), sets it to the right timing and waits for it to stabilize,
sometimes by interactively hunting for various parameters like voltage.
(Last month the other guy in my office had to debug a fun one where the
timing was too fast and 10% of the time the uboot search wouldn't
converge.)  Coreboot (formerly the Linux Bios Project) does a fun little
trick where they set up a TLB entry and fault in a few cache lines, zero
them out, and then set the stack pointer to the start of that cached
memory, which lets them jump to C code early and set up the DRAM
controller in C instead of assembly.  QEMU doesn't need to do this
becaue it doesn't emulate a DRAM controller, although getting uboot NOT
to do this and then try to copy itself out of flash into dram was a pain
for a long time...

At about THAT point you can start worry about finding the boot device,
loading your OS from it, and performing device enumeration.

Macs aren't magic.  The ones we're talking about are 30 year old
technology, they're pretty simple by modern standards and work pretty
much the same way everyting else does.

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

I want something that emulates the macintosh hardware, not just a CPU
emulator hooked up to a hacked copy of the MacOS roms that doesn't
emulating any of the actual underlying hardware, such as basilisk provides.

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

Largely because 68k macs stopped being sold 16 years ago and this is
retrocomputing, you mean?

I want to get the Dec Alpha running too, but that's lower on the list.
M68k used to be really widely deployed and some embedded systems use
m68k variants.  Alpha died when DEC was bought by a windows company that
didn't make its own chips, and the chip design team was scooped up by
AMD and went on to design the Athlon and Opteron.

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

I'm fairly certain this is not true, but if it is I might be able to fix it.

> 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

Actually I'm pretty sure a mac-m68k target would work fine for my needs,
I just don't care that much what m68k board QEMU gives me.  An existing
one is great, but a PC variant would work too, as would a bunch of
virtio devices if that ever gets documented.  (Virtconsole is still a
black box that can't talk to qemu stdin/stdout.)

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

The m68k branch has the start of a quadra 800, but the actual board file
is a powerpc board with just about everything "#if 0"ed out.

Mostly i want an existing board so I don't have to perform extensive
surgery on Linux's kconfig to build a kernel for it.  (Device trees
should eventually make that suck less.  I look forward to them.)

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

Care to suggest one?  I'm not that familiar with what's available in
m68k land, I just know how the other dozen hardware platforms I've used
work.

Rob