Mac-on-linux is now working...

Mac-on-linux is now working...

[Samuel Rydh]

Mac-on-linux is an open source emulator which 
runs Mac OS on linuxPPC machines. Since the
processor is running unemulated it is very fast
(about 95% according to speedometer specmarks
on a 8500).

Currently Mac OS boots on the 7200 and 8500
without a ROM-image. Other machines should be 
able to run the software using a ROM-image 
from one of those two computers (G3 machines may
or may not boot Mac OS).

Brief status summary:

video:		full-screen video working
mouse/keyboard:	working
scsi:		working
floppy:		working
sound:		not implemented
ethernet:	not implemented (yet)
serial:		hack allowing OF interaction

More information (and the source code) can be found 
at <http://www.ibrium.se/linux/mac_on_linux.html>.

The project could have use a few more developers, so
please join the mac-on-linux team!


/Samuel Rydh

-- 

----------------------------------------------------------
  E-mail <samuel@ibrium.se>  WWW: <http://www.ibrium.se>
    Phone/fax: (home) +46 4418431, (work) +46 7908470   
----------------------------------------------------------

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Mac-on-linux is now working...

[Jens Ch. Restemeier]

Hi !

I'm currently downloading the source. Do you have any suggestions for
starting 603 support? What are the differences that need to be fixed?

Jens

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Mac-on-linux is now working...

[Samuel Rydh]

On Tue, May 11, 1999 at 09:50:12AM +0200, Jens Ch. Restemeier wrote:
> Hi !
> 
> I'm currently downloading the source. Do you have any suggestions for
> starting 603 support? What are the differences that need to be fixed?
> 
> Jens

I think it is only the MMU code which needs to be fixed. 
All processors except the 603 uses a TLB hash table for
page table entries. Mac-on-linux accesses this table
directly in a few places.

If the line

  #define NO_RELOAD_HTAB 1

is changed to

  #define NO_RELOAD_HTAB 0

in 'arch/ppc/kernel/head.S' and 'arch/ppc/mm/init.c',
then the kernel emulates a TLB hash table. Possibly
this will do the trick. (I would also suggest careful 
examination of the register contents for the faked 
"DSI/ISI" exception).

Some more modifications are necessary if one want
the 603 to behave as a 603 (and not as a 604).
I can't see why one should want that though.

/Samuel

-- 

----------------------------------------------------------
  E-mail <samuel@ibrium.se>  WWW: <http://www.ibrium.se>
    Phone/fax: (home) +46 4418431, (work) +46 7908470   
----------------------------------------------------------

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Mac-on-linux is now working...

[Kolbjørn Barmen]

On Mon, 10 May 1999, Samuel Rydh wrote:

> Mac-on-linux is an open source emulator which 
> runs Mac OS on linuxPPC machines.

LinuxPPC machines in general, or does it have to be PowerMacs?
Theoretically speaking ofcourse :)


 Kolbjørn Barmen |    a3k/o6o/6o4e/AmigaOS/MacOS/LinuxPPC   |    // T e a m
 <kolla@nvg.org> | a12ooCT/o3o/Linux-m68k  a6oo/o3o/AmigaOS | \XX/ A M I G A
 Nettverksgruppa |    "I met the Amiga and fell in love..." | <amiga.nvg.org>
             »» Norwegian University of Technology and Science ««


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Mac-on-linux is now working...

[Brad Midgley]

Samuel,

I am SO impressed with mol. I remember you saying a while back that you
were interacting with OF in a virtualized session and POOF now MacOS runs!

The few problems I've encountered are intriguing... I'm also touching on a
lot of issues I've thought of.

control-c doesn't work to shut mol down any more. maybe i messed something
up here...

my macos has bootx defaulting to linux but that's not what you want inside
the virtual machine. i think i'll install a small macos on another drive
that has bootx and remove bootx from the main mac system. (it IS a trip to
watch linux boot inside linux however :)

is there any reason to use hw, 53c94, or mesh over osi?

i have two mice. i have to hold down the button on both mice or dragging
doesn't work--macos under mol will confuse the other mouse's button-up. 
linux used to do this, beos did, and regular macos will IF i unplug the
adb chain and plug it back in so both mice have the same ID. I don't
understand the level of adb emulation inside mol so i'm not sure why it
would do that. 

is there any reason to fear making volumes read-write? is a regular
shutdown inside mol enough to make sure the volumes stay coherent? 

cpu load is high but i imagine that's just the nature of macos. i won't be
leaving it running in the background.

i'd suggest larger swap partitions for people who plan to run mol. what
used to be fine for x + netscape + etc. isn't high enough if you want mol
to commit 32M or 64M. mol effectively reduces your swap available by the
amount of ram you give it. mol didn't thrash however--it just wants to
commit the memory up front. i love the idea of using REAL virtual memory
inside today's macos.

once mol is solid i'd like to see the user experience changed a little--a
flag to mol to have it not launch the debugger and making shutdown inside
macos stop mol would improve it vastly.

i wrote a script to help with launching mol. it should be run from the
console:

#!/bin/sh
vmode 17 32
echo Starting Mac-on-Linux emulator...
echo
MOLHOME=/usr/share/mol
cd $MOLHOME
if [ $? -ne 0 ]; then
 echo "Couldn't change to $MOLHOME (the directory may be missing)"
 exit
fi
if [ ! -f data/rom/ROM-image ]; then
 echo "Couldn't find ${MOLHOME}/data/rom/ROM-image"
 echo "You should copy your ROM-image to ${MOLHOME}/data/rom/"
 exit
fi
umount -a -thfs
if [ $? -ne 0 ]; then
 echo
 echo "Warning: At least one hfs filesystem couldn't be unmounted."
 echo "Make sure you don't use any volume concurrently in mol"
 echo "and as a mounted Linux filesystem unless they're BOTH read-only."
 echo
 sleep 10 
fi
nice ./mol $*
mount -a -thfs

if you plan to make mol run within an x window, i suggest to write it to
libGGI. if it was written to libGGI, then full-screen and within-X could
both be easily achieved with the same binary.

> Currently Mac OS boots on the 7200 and 8500
> without a ROM-image. Other machines should be 
> able to run the software using a ROM-image 
> from one of those two computers (G3 machines may
> or may not boot Mac OS).

FYI I needed the image on my 7500.

> floppy:		working

I couldn't find floppy support documented...

> sound:		not implemented
> ethernet:	not implemented (yet)

especially ethernet will be great. how will you do it though? Will the mac
box get an ip address of its own and have two addresses bound to the card? 

mol couldn't be a dhcp client--imagine how confusing that would get... 
you could stick with one bound address and have the mac box masqueraded
maybe.

great work. i'm glad to see Ben has participated.

I'd like to see more discussion on what issues are giving you problems.
That's an important way to get more involvement.

Brad
brad@pht.com | http://www.pht.com/~brad/






[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Mac-on-linux is now working...

[Benjamin Herrenschmidt]

On Thu, Jun 3, 1999, Brad Midgley <brad@turbolinux.com> wrote:

I'm giving you some answers, Samuel is busy this week, he may want to
correct me later however on some points.

>control-c doesn't work to shut mol down any more. maybe i messed something
>up here...

Did you try switching to the debugger VC before pressing control-C ?

>my macos has bootx defaulting to linux but that's not what you want inside
>the virtual machine. i think i'll install a small macos on another drive
>that has bootx and remove bootx from the main mac system. (it IS a trip to
>watch linux boot inside linux however :)

I think I'll have to fix that...

>is there any reason to use hw, 53c94, or mesh over osi?

That depends if OSI works fine for you or not, all this is quite early.
Also, OSI works only with MacOS, not MacOS X nor Linux. But in the
longterm, I beleive OSI will be faster (I didn't bench the current version).

>i have two mice. i have to hold down the button on both mice or dragging
>doesn't work--macos under mol will confuse the other mouse's button-up. 
>linux used to do this, beos did, and regular macos will IF i unplug the
>adb chain and plug it back in so both mice have the same ID. I don't
>understand the level of adb emulation inside mol so i'm not sure why it
>would do that. 

Probably something in the adb emulation. I have some plans in mind to add
better support in the kernel for routing directly ADB datas to MOL.
Currently, MOL reconsitutes ADB datas from the Xpmac pseudo-keycodes send
by the kernel to the front VC.

>is there any reason to fear making volumes read-write? is a regular
>shutdown inside mol enough to make sure the volumes stay coherent? 

It should work, but it's still early and not large-scale tested. I use it
read-write on one machine, but it's a test machines with nothing
important. I didn't crash the disk yet (running MacOS 8.6). I've not
encountered a specific case of data corruption, and I didn't see Samuel
writing about one.

>cpu load is high but i imagine that's just the nature of macos. i won't be
>leaving it running in the background.

This can be improved in the future, especially since MacOS itself
improved that in 8.6 (processor in DOZE mode when idle). But I beleive
MOL will always be a resource eater. Should be fine in MP ;-)

>if you plan to make mol run within an x window, i suggest to write it to
>libGGI. if it was written to libGGI, then full-screen and within-X could
>both be easily achieved with the same binary.

I wrote most of the video driver, so I'm interested in any infos/tips you
have about libGGI (I know nothing about it). Currently MOL maps the
physical frame buffer in mac-os space for efficiency and provides MacOS
with a video drivers thru a fake PCI card expansion ROM. I have few
control over MacOS, I mean MacOS requires access to a complete
framebuffer. When switching VCs, the framebuffer is unmapped and a piece
of memory is mapped instead. 
For GGI/X, I don't know if direct mapping of the fb is possible without
hacks. If not, we either have to blit all the time, add more MacOS hacks
to try to "sense" changes to the screen via JShieldCursor patch or
something like that, or use the MMU to catch writes to the fb.

>FYI I needed the image on my 7500.

What happens if you boot without the images ? (You should keep oftree and
ROM images in sync. If not using the ROM image, don't use the oftree
image neither). Also, avoid using the bundeled nvram image if using a
different ROM than the 8500. Use the debugger command "nvramzap" to zap
it before starting emulation, and "nvramwi" later during boot to write it.

>especially ethernet will be great. how will you do it though? Will the mac
>box get an ip address of its own and have two addresses bound to the card? 
>
>mol couldn't be a dhcp client--imagine how confusing that would get... 
>you could stick with one bound address and have the mac box masqueraded
>maybe.

Hum, I will probably also write the network stuff (actually, I began the
MacOS side) and it will be based on Basilic/Sheepshaver driver for
getting copies of incoming eth packets and inserting outgoing eth
packets. I don't know Linux kernel router well enough to adapt this
driver so that it can be a "branch" of linux router, currently the driver
must be "attached" to a network interface. if linux provides virtual
interfaces, then we could attach the driver to it.

>great work. i'm glad to see Ben has participated.

Thanks ;-)

>I'd like to see more discussion on what issues are giving you problems.
>That's an important way to get more involvement.

You may help for the network, track bug, help supporting more hw with
their own ROMs, etc... There is still a lot to do ;-) I'll let Samuel
give you more details.

-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>




[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

control-c [Re: Mac-on-linux is now working...]

[Brad Midgley]

fyi, i found out that control-c doesn't stop mol if mol was started from
my shell script. so it may be something to do with signal handling...

perhaps when run from a script bash gets the control-c and sends the
interrupt signal to mol but mol was looking for a raw control-c? maybe
stty could change that behavior...

Brad
brad@pht.com | http://www.pht.com/~brad/



[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Mac-on-linux is now working...

[Brad Midgley]

sorry i'm filling you mailbox :)

> >the virtual machine. i think i'll install a small macos on another drive
> >that has bootx and remove bootx from the main mac system. (it IS a trip to
> >watch linux boot inside linux however :)
> 
> I think I'll have to fix that...

is there a way bootx could tell it was running inside a mol session?

> Probably something in the adb emulation. I have some plans in mind to add
> better support in the kernel for routing directly ADB datas to MOL.
> Currently, MOL reconsitutes ADB datas from the Xpmac pseudo-keycodes send
> by the kernel to the front VC.

interesting approach. the xpmac code in the kernel could be fixed to deal
with multiple mice better (i'll have a look). /dev/adbmouse does deal
correctly with multiple mice--did you ever think of translating busmouse
info into an adb stream?

Brad
brad@pht.com | http://www.pht.com/~brad/




[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]