Mac-on-Linux

I've tried this on a Performa 6400/180 (603e), and also got a panic right after Meta-G.

c0044c7c: c0044c04 t insert_pte
c004498c: c004485c t page_fault
c004478c: c0044704 t mmu_data_access_hook
c0041d80: c0041d78 t access_exception

This is a cvs-kernel, but not the one from the mac-on-linux-site, but the patches applied cleanly.

/Stefan

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

Thanks for the testing! My directions were bad though. I missed the fact that the kernel source uses #ifdef and not #if, so the line

#define NO_RELOAD_HTAB 1

should be commented out in 'arch/ppc/kernel/head.S' and 'arch/ppc/mm/init.c'.

I've looked through the Mac-on-Linux kernel source, and I think this should be sufficient to add support for the 603. (There is a 603 incompatible function used by the debugger, but I don't think it is used normally.)

/Samuel

----------------------------------------------------------
E-mail <[email protected]> WWW: <http://www.ibrium.se>
Phone/fax: (home) +46 8 4418431, (work) +46 8 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. ]]

Ok.. this seems to help a lot. It no longer panics, and I've got a rom-image for my performa 6400, but when I tell it to start with Meta-G, it just sits there.

This machine has a valkyrie graphics card, and since platinum seems to be more or less the only thing supported, I can guess that's why I don't see anything.

Is that why? :)

Anyway.. it exits when I press Ctrl-C, so the machine is alive and all.

One step in the right direction :)

/Stefan

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

No. There is a hardware independent video driver which uses the framebuffer device. Does singlestepping (Meta-S) work? Also, remeber to specify 'processor: 4' in the molrc file.

Btw. I've uploaded a new release of Mac-on-Linux (with binaries) which works properly on G3 machines. It is possible that the G3 fix also solves the 603 problem.

/Samuel

----------------------------------------------------------
E-mail <[email protected]> WWW: <http://www.ibrium.se>
Phone/fax: (home) +46 8 4418431, (work) +46 8 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. ]]

Quick question: what is the nature of the kernel support for mac-on-linux? Some folks in the MkLinux camp have been discussing writing equivalent 2.0.xx kernel code that works through mach. I know that it will likely need to be able to map the ROMs into user space. I also suspect that handling code (which could be very messy, but we'll cross that bridge when we get to it) and possibly the memory management code. Beyond that, what other hurdles are there?

Later,
David

David A. Gatwood Visit globegate's internet
[email protected] talker, Deep Space 36
http://globegate.utm.edu telnet globegate.utm.edu:9624

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

I've compiled the new one, and patched the kernel as well with the newest patches for that.

The result is identical to me. Meta-S gives the same hanging 'mm', as Meta-G does, which seems to be resolvable only by a Ctrl-C, which then exists the program.

I am specifying '4' as processor too..

/Stefan

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

The Mac-on-Linux kernel support code has in principle the following tasks:

- Emulate privileged instructions.
- Handle the MMU (maps ROM, RAM etc.)

The implementation is primarily based upon hooks in the low-level exception handlers. Besides this, the interaction with the kernel has been kept at a minimum.

I believe the exception hooks must be put into the mach kernel - possibly it is easiest to put all code there.

/Samuel

----------------------------------------------------------
E-mail <[email protected]> WWW: <http://www.ibrium.se>
Phone/fax: (home) +46 8 4418431, (work) +46 8 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. ]]

There would be advantages and disadvantages. Speed-wise, it'd be great if it were all in mach and if the mac-on-linux binary were mach aware, detecting Mach's presense, and using direct calls into Mach. Simplicity-wise, we could stick an abstraction layer in there in the linux server so that it mostly looked the same to mac-on-linux whether it was running on LinuxPPC or MkLinux. Not sure which would end up being the most advantageous, but it's probably a moot point until the Mach handling changes are made. :-)

Later,
David

David A. Gatwood Visit globegate's internet
[email protected] talker, Deep Space 36
http://globegate.utm.edu telnet globegate.utm.edu:9624

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