Re: Mac-on-Linux

Re: Mac-on-Linux

[Stefan Berndtsson]

"Jason S." <jhsterne@mindspring.com> writes:

> On Thu, May 20, 1999 at 07:24:59PM +0200, Samuel Rydh wrote:
> 
> > > Mac-on-Linux looks very promising.  One question though, are you planning
> > > to use 603 processors?  
> 
> > I would appreciate if someone could download try the Mac-on-Linux
> > patched kernel, also changing the
> 
> > 	#define NO_RELOAD_HTAB 1
> > to
> > 	#define NO_RELOAD_HTAB 0
> 
> > in 'arch/ppc/head.S' and 'arch/ppc/mm/init.c'. This might do the
> > trick. (Then Mac-on-linux should be able to let MacOS see
> > the 603 as a 604).
> 
> I tried this on a PowerBase 180 and got a kernel panic once it
> started the emulator:
> 
> kernel: Kernel panic: kernel access of bad area pc c0046cd8 lr c004696c address 3C00 tsk mm/175

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

>From manual work on the backtrace, the following functions are accessed:

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

Re: Mac-on-Linux

[Samuel Rydh]

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 <samuel@ibrium.se>  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.   ]]

Re: Mac-on-Linux

[Stefan Berndtsson]

Samuel Rydh <samuel@ibrium.se> writes:

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

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

Re: Mac-on-Linux

[Samuel Rydh]

On Fri, May 21, 1999 at 10:19:34PM +0200, Stefan Berndtsson wrote:
> > 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? :)

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 <samuel@ibrium.se>  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.   ]]

Re: Mac-on-Linux

[David A. Gatwood]

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
dgatwood@globegate.utm.edu                  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.   ]]

Re: Mac-on-Linux

[Stefan Berndtsson]

Samuel Rydh <samuel@ibrium.se> writes:

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

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

Re: Mac-on-Linux

[Samuel Rydh]

On Fri, May 21, 1999 at 09:35:21PM -0500, David A. Gatwood wrote:
> 
> 
> 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?

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 <samuel@ibrium.se>  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.   ]]

Re: Mac-on-Linux

[David A. Gatwood]

On Sat, 22 May 1999, Samuel Rydh wrote:

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

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
dgatwood@globegate.utm.edu                  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.   ]]