Porting to NuBus PowerMacs

Porting to NuBus PowerMacs

[Hubert Figuiere]

I'd like to know what would be the complexity of porting LinuxPPC
to NuBus PowerMacs ?

Here are my thoughts:

-we have BootX. So we can BootX LinuxPPC. We just need to build a
 fake OpenFirmware device tree for BootX so he can pass it the
 kernel

-we have the source of the Mach MicroKernel, hence we have enough
 to rewrite the specification to rewrite drivers for LinuxPPC.
 Some components and drivers may directly come from Linux Mac68k.


Note that I don't have a NuBus PowerMac. Only a 6200 (and my
PowerCenter Pro, already supported).

Any comments ?

Hub
-- 
> Je souhaiterais essayer Internet Explorer 4.0 sous Linux.
> Il existe 2 versions: une sous HP/UX et une sous Solaris
> Laquelle dois je utiliser?
-+- MJM in Guide du linuxien pervers : "Choisir son environnement" -+-

[[ 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. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Porting to NuBus PowerMacs

[Benjamin Herrenschmidt]

On Tue, Jan 12, 1999, Hubert Figuiere <Hubert.Figuiere@solsoft.fr> wrote:

>I'd like to know what would be the complexity of porting LinuxPPC
>to NuBus PowerMacs ?

<asun@saul6.u.washington.edu> is already thinking about it.

>Here are my thoughts:
>
>-we have BootX. So we can BootX LinuxPPC. We just need to build a
> fake OpenFirmware device tree for BootX so he can pass it the
> kernel

That was the original idea, but several things makes me wonder if it
wouldn't be simpler to just pass a list of known infos (total ram size,
processor type, machine ID and a couple of baseaddresses) to the kernel
and almost-hard-code things in drivers since this hardware will not
evolve very much now ;-)

Basically, I have to provide him a version of BootX that works on those
machines and provide the requested infos. I didn't have time to work a
lot on BootX those few last days, but I think I'll send him something
around the end of the week, maybe next week.

>-we have the source of the Mach MicroKernel, hence we have enough
> to rewrite the specification to rewrite drivers for LinuxPPC.
> Some components and drivers may directly come from Linux Mac68k.

We have also a lot of potentially useful things in the mac68k and APUS ports.

>Note that I don't have a NuBus PowerMac. Only a 6200 (and my
>PowerCenter Pro, already supported).

;-)

-- 
           E-Mail: <mailto:bh40@calva.net>
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. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Porting to NuBus PowerMacs

[David A. Gatwood]

On Tue, 12 Jan 1999, Hubert Figuiere wrote:

> I'd like to know what would be the complexity of porting LinuxPPC
> to NuBus PowerMacs ?
> 
> Here are my thoughts:
> 
> -we have BootX. So we can BootX LinuxPPC. We just need to build a
>  fake OpenFirmware device tree for BootX so he can pass it the
>  kernel
> 
> -we have the source of the Mach MicroKernel, hence we have enough
>  to rewrite the specification to rewrite drivers for LinuxPPC.
>  Some components and drivers may directly come from Linux Mac68k.

It's a lot harder than this, unfortunately.  The NuBus machines' memory
isn't contiguous.  Thus, code would have to be written and/or obtained to
find out what memory is available in the machine and where that memory is
located in RAM.  That's going to be a nasty problem unless some code is
pulled from the MkLinux booter.  I'd expect that to also require a
substantial number of changes to the way memory is handled in linux, but I
could be wrong.

Beyond that, it will also require changes to irq.c to handle the interrupt
controller and a lot of code for DMA, if that's desired (I don't think
it's even remotely similar, AFAICT).  Of course, that stuff can be
obtained from Mach, but it'll be a lot of work.  Oh, and the i/o base
address is different, which may or may not be a problem, and supporting
certain pieces of hardware (which will remain nameless) will also require
speed penalties (this is the other reason MkLinux is slower than
LinuxPPC...).


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

-----BEGIN GEEK CODE BLOCK-----
Version 3.1
GCS/CC/FA/H/L/MC/M/MU/PA/TW d-@ s:>- a-- C++ ++>$ UBLAS*++ ++>$
P+?>$ L++ +>$ !E--- W++ +>$ N++(++ +)>++ +$ !o? K-? !w--- !O
M++>$ !V-- PS+>$ !PE- Y+>$ PGP+>$ t++ +>$ 5+>++ ++$ !X- !R tv+>$
b++>$ !DI !D- G++(++ +)>$ e>++ ++ h--! r--- !y-
------END GEEK CODE BLOCK------


[[ 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. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Porting to NuBus PowerMacs

[a sun]

[David Gatwood wrote:]

    It's a lot harder than this, unfortunately.  The NuBus machines'
    memory isn't contiguous. Thus, code would have to be written and/or
    obtained to find out what memory is available in the machine and where
    that memory is located in RAM.  That's going to be a nasty problem
    unless some code is pulled from the MkLinux booter.  I'd expect that
    to also require a substantial number of changes to the way memory is
    handled in linux, but I could be wrong.

erk. i hadn't thought about that. from looking at the ppc mm code
though, it looks like it should be able to handle chunks of
memory. the m68k and the apus code certainly look like they can handle
being passed chunks of addresses/sizes. hopefully, it shouldn't be too
bad...

so, ben, i guess i'll also need memory addresses/sizes as well. after
perusing the m68k code, i think that's the only thing that i forgot to
tell you about. this will essentially make bootx report essentially
the same information as the m68k boot loader.

    Beyond that, it will also require changes to irq.c to handle the
    interrupt controller and a lot of code for DMA, if that's desired (I
    don't think it's even remotely similar, AFAICT).  Of course, that
    stuff can be obtained from Mach, but it'll be a lot of work.  

well, my "oh so clever plan" is actually to use the gestalt
information to mock up something that i pass to the m68k interrupt
routines. presto! no more uglification of irq.c. given the
similarities between the apus stuff and the nubus powermac stuff, i'm
actually turning the nubus powermacs into a variant of apus for now. a
lot of my fiddling actually ends up making some minor changes to the
m68k code and calling that instead. 

for now, i'm conveniently ignoring the dma stuff, but it looks like
modifying the mac68k devices will actually prove to be more useful
than dealing with the the standard pci powermac stuff. 

    Oh, and the i/o base address is different, which may or may not be
    a problem, and supporting certain pieces of hardware (which will
    remain nameless) will also require speed penalties (this is the
    other reason MkLinux is slower than LinuxPPC...).

heh. am i correct in assuming then that just using memory barriers
just won't cut it for a certain device that seems to have a bunch of
delay()'s sprinkled throughout it? strangely, this same piece of
hardware seems to be necessary to get the newer tech g3 extension and
the mklinux booter happy... any insights there?


-a
asun@u.washington.edu

[[ 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. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Porting to NuBus PowerMacs

[Paul Mackerras]

David A. Gatwood <marsmail@globegate.utm.edu> wrote:

> Beyond that, it will also require changes to irq.c to handle the interrupt
> controller and a lot of code for DMA, if that's desired (I don't think
> it's even remotely similar, AFAICT).  Of course, that stuff can be
> obtained from Mach, but it'll be a lot of work.  Oh, and the i/o base

I gather that DMA is not cache-coherent on the NuBus powermacs, which
opens a whole new can of worms... it means you have to do explicit
flush/invalidate requests, but it also means that you *have* to make
sure that the cpu isn't accessing any words in any of the cache lines
that the dma controller is accessing.  If the dma buffer isn't
cacheline-aligned, and is preceded or followed by unrelated stuff, you
are in trouble.

Paul.

[[ 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. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Porting to NuBus PowerMacs

[David A. Gatwood]

On Tue, 12 Jan 1999, Benjamin Herrenschmidt wrote:

> That was the original idea, but several things makes me wonder if it
> wouldn't be simpler to just pass a list of known infos (total ram size,
> processor type, machine ID and a couple of baseaddresses) to the kernel
> and almost-hard-code things in drivers since this hardware will not
> evolve very much now ;-)

RAM chips on that machine are... according to a reliable source... aligned
on 64 meg boundaries, and are thought to be mirrored throughout that bank
if they're <64 megs.  Question is... what happens if a bank isn't filled. 
This is left as an exercise for the reader.  But determining the memory
layout is critical to getting it working.  I'm hoping that I can get that
bit of code from the MkLinux booter, but I'm not making any promises.


> Basically, I have to provide him a version of BootX that works on those
> machines and provide the requested infos. I didn't have time to work a
> lot on BootX those few last days, but I think I'll send him something
> around the end of the week, maybe next week.

Also, please pass the machine gestalt (for model detection), video
address, processor speed, and a flattened OF tree, if you could (and if
you aren't already).  That would ease porting the Mach MK to BootX-style
booting (which is basically the only way MkLinux will ever run on iMacs
and the new G3 MiniTower machines, unless we add OF booting, which I don't
want to muck with right now).


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

-----BEGIN GEEK CODE BLOCK-----
Version 3.1
GCS/CC/FA/H/L/MC/M/MU/PA/TW d-@ s:>- a-- C++ ++>$ UBLAS*++ ++>$
P+?>$ L++ +>$ !E--- W++ +>$ N++(++ +)>++ +$ !o? K-? !w--- !O
M++>$ !V-- PS+>$ !PE- Y+>$ PGP+>$ t++ +>$ 5+>++ ++$ !X- !R tv+>$
b++>$ !DI !D- G++(++ +)>$ e>++ ++ h--! r--- !y-
------END GEEK CODE BLOCK------


[[ 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. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Porting to NuBus PowerMacs

[Dan Malek]

Benjamin Herrenschmidt wrote:

> That was the original idea, but several things makes me wonder if it
> wouldn't be simpler to just pass a list of known infos (total ram size,
> processor type, machine ID and a couple of baseaddresses) to the kernel
> and almost-hard-code things in drivers since this hardware will not
> evolve very much now ;-)

This is what we do with the embedded LinuxPPC ports now.
The data structure is a combination of things the boot rom gives
us and other configuration tidbits the Linux boot loader can find.
It wouldn't be hard to expand this to other systems.

The next challenge would be to support OF fucntions (like find_devices(), etc.)
for those drivers that run on both platforms.  As the embedded systems
mature, we may soon be doing this.......

    -- Dan



[[ 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. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Porting to NuBus PowerMacs

[Ron Nelson]

I know you guys are only in the early stages with this but I have a 6100 
that I will run anything you come up with on.. I don't have mklinux on it
right now but I could get that on it and be a guinea pig if you need one..

Ron Nelson

----------
>From: "David A. Gatwood" <marsmail@globegate.utm.edu>
>To: Benjamin Herrenschmidt <bh40@calva.net>
>Cc: linuxppc-dev@lists.linuxppc.org, Hubert Figuiere
<Hubert.Figuiere@solsoft.fr>
>Subject: Re: Porting to NuBus PowerMacs
>Date: Tue, Jan 12, 1999, 5:12 PM
>

>
> On Tue, 12 Jan 1999, Benjamin Herrenschmidt wrote:
>
>> That was the original idea, but several things makes me wonder if it
>> wouldn't be simpler to just pass a list of known infos (total ram size,
>> processor type, machine ID and a couple of baseaddresses) to the kernel
>> and almost-hard-code things in drivers since this hardware will not
>> evolve very much now ;-)
>
> RAM chips on that machine are... according to a reliable source... aligned
> on 64 meg boundaries, and are thought to be mirrored throughout that bank
> if they're <64 megs.  Question is... what happens if a bank isn't filled.
> This is left as an exercise for the reader.  But determining the memory
> layout is critical to getting it working.  I'm hoping that I can get that
> bit of code from the MkLinux booter, but I'm not making any promises.
>
>
>> Basically, I have to provide him a version of BootX that works on those
>> machines and provide the requested infos. I didn't have time to work a
>> lot on BootX those few last days, but I think I'll send him something
>> around the end of the week, maybe next week.
>
> Also, please pass the machine gestalt (for model detection), video
> address, processor speed, and a flattened OF tree, if you could (and if
> you aren't already).  That would ease porting the Mach MK to BootX-style
> booting (which is basically the only way MkLinux will ever run on iMacs
> and the new G3 MiniTower machines, unless we add OF booting, which I don't
> want to muck with right now).
>
>
> 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
>
> -----BEGIN GEEK CODE BLOCK-----
> Version 3.1
> GCS/CC/FA/H/L/MC/M/MU/PA/TW d-@ s:>- a-- C++ ++>$ UBLAS*++ ++>$
> P+?>$ L++ +>$ !E--- W++ +>$ N++(++ +)>++ +$ !o? K-? !w--- !O
> M++>$ !V-- PS+>$ !PE- Y+>$ PGP+>$ t++ +>$ 5+>++ ++$ !X- !R tv+>$
> b++>$ !DI !D- G++(++ +)>$ e>++ ++ h--! r--- !y-
> ------END GEEK CODE BLOCK------
>

[[ 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. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Porting to NuBus PowerMacs

[Hubert Figuiere]

According to Benjamin Herrenschmidt <bh40@calva.net>:

> >-we have the source of the Mach MicroKernel, hence we have enough
> > to rewrite the specification to rewrite drivers for LinuxPPC.
> > Some components and drivers may directly come from Linux Mac68k.
> 
> We have also a lot of potentially useful things in the mac68k and APUS ports.
> 
> >Note that I don't have a NuBus PowerMac. Only a 6200 (and my
> >PowerCenter Pro, already supported).
> 
> ;-)

I'm investigating the possibilities to support 5200/6200 (and its
little brother 5300/6300) just because this machine is:

a) not supported by either MkLinux or LinuxPPC
b) I have one (in fact my fiancee has it).

There are several custom chips inside (like on any other Mac).
First the big problem is that 6200 is a PowerPC inside a 68040
machine. It uses a "CAPELLA" custom chip as a bus translation
unit. This may be a problem since I don't think it is used in any
supported PowerMac.

RAM: 2 simm slot on a 68040 data bus.

Video: It is a "Valkyrie" Chip using a DRAM frame buffer. If I
remember, Valkyrie is available in several PowerMacs and is
already supported.

Memory Controller: it is a "F108" as in the LC 630 (ses Linux 68k
port) that also handles IDE, SCSI and SCC serial ports. SCSI in
this chip is a NCR 53C96. SCC is like the 8530 SCC (that we find
in several Macs too).

ADB: "CUDA" chip similar to several 68k Mac. Accessed thru the
"PrimeTime II". It is the 68HC05 and also handles PRAM, RTC,
power supply control.

Sound: a "DFAC II" chip.

Other: "PRIMETIME II" chip manages SWIM II, VIA1, VIA2, sound
controller and I/O bus adpater. Manages ADB sounds, CommSlot, PDS.

You can find the technote here:

http://developer.apple.com/techpubs/hardware/hardware2.html

Note that I have no porting experience. :-)


Hub
-- 
> Je souhaiterais essayer Internet Explorer 4.0 sous Linux.
> Il existe 2 versions: une sous HP/UX et une sous Solaris
> Laquelle dois je utiliser?
-+- MJM in Guide du linuxien pervers : "Choisir son environnement" -+-

[[ 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. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Porting to NuBus PowerMacs

[Kaoru Fukui]

> bh40@calva.net>
> Subject: Re: Porting to NuBus PowerMacs
> Date: Tue, 12 Jan 1999 22:40:11 -0700
> CC: linuxppc-dev@lists.linuxppc.org,Hubert Figuiere <Hubert.Figuiere@solsoft.fr

> >
> 
> 
> I know you guys are only in the early stages with this but I have a 6100 
> that I will run anything you come up with on.. I don't have mklinux on it
> right now but I could get that on it and be a guinea pig if you need one..
> 
> Ron Nelson
================================================================

       ---------------------------
         Rawhide world on MklinuxG06
        ---------------------------

 Let's go "Rawhide world" using the vmlinux+installer like DR3,
    together Nubus users too.

   This vmlinux+installer is useful linuxppc/R5 in linuxppc box,too.
    
   There is <ftp://ppc.linux/pub/users/fukui/Drugstore-in Rawhide
          /Installer-on-MkLinux-G06R5>. 

                                  Kaoru Fukui <fukui@ppc.linux.or.jp>
                                  Sun 10 Jan 1999

  ** How to install as MkLinux** 

 1. Download many RedHat/RPMS files from 
             ftp://ftp.linux.org/pub/linuxppc/linuxppc-pre-R5/RedHat/RPMS.
     Not use for linuxppc files.
     (kernel-pmac,kernel-prep,kernel-source,kernel-chrp,pmac-utils,linuxconf
)

     Put RPMS files on ext2.

     Remove filenames for linuxppc in comps,
      or use Installer-on-MkLinuxG06R5/RedHat/base/comps,it's alredy rewrite
.
    Download RedHat/base/hdlist and put it in RedHat/base. 

 2. Download these files from 
       ftp://ppc.linux.or.jp/pub/users/fukui/Drugstore-in-Rawhide/Installer-on-MkLinux-G06R5
/*.
     Add four files from Installer-on-MkLinux-G06R5/RedHat/RPMS/* 
     to Redhat/RPMS installed.
     (clock-mklinux,mklinux-release,mklinux_server,rc.loca-linuxppc)

     Add these filenames in comps,or use My comps.

 3. Uncompress Mac_Files.sit, put in MacOS.
 4. Put mach_servers in MacOs.
 5. Go restart Mac. 

 [note]
   I istalled R5 useing these files on PM6100.
   Then Select custom,Scsi driver is no,Disk Setup,use fdisk,
   Edit Partition is "/",
   Do link for startx function," cd /etc/X11,ln -sf /usr/X11R6/bin/Xpmac X"

 [Problem]
   The comps has many bugs.Take care.

   Xfree86-3.3.3-10d.ppc.rpm could not nomeal end.
   It,s works fine, but hitkey "ctrl D" to go freeze.
   I used to end "sync,reboot","sync,halt".

   More problem, it's not X_LOCAE, Xemacs doesnot work. 


 Mac_Files.sit have "Mach kernel" from globegate.utm.edu/MkLinux generic 06.
 The other fuiles are same.
 

>Installing the Mac OS-side files
>================================

>There are five files in the "Mac Files" folder.  Copy the two files "MkLinux

>Booter" and "Mach Kernel" to your Extensions folder.  Copy the control panel

>"MkLinux" to your Control Panels folder.  Copy the two files "lilo.conf" and

>"MkLinux.prefs" to your Preferences folder.

>The initial boot of MkLinux just runs the installer.  Currently, things are


 Vmlinux+installer was rebuilt using "Mklinux generic 06" and 
   "Linuxppc release 5's installer".

 I got ramdisk.image.gz-RH5-new from Martin's 
      <http://www.maths.univ-rennes1.fr/~costabel/linux/R5/>,
 it's have not /dev/* and not /mnt.
 Installer said "can not mount".
 I fixed that. Thanks Martin. 


Enjoy Rawhide on MklinuxG06!

Thanks
Kaoru Fukui <fukui@linux.ppc.or.jp>


[[ 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. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Porting to NuBus PowerMacs

[Gary Thomas]

On 13-Jan-99 Hubert Figuiere wrote:
> 
> According to Benjamin Herrenschmidt <bh40@calva.net>:
> 
>> >-we have the source of the Mach MicroKernel, hence we have enough
>> > to rewrite the specification to rewrite drivers for LinuxPPC.
>> > Some components and drivers may directly come from Linux Mac68k.
>> 
>> We have also a lot of potentially useful things in the mac68k and APUS ports.
>> 
>> >Note that I don't have a NuBus PowerMac. Only a 6200 (and my
>> >PowerCenter Pro, already supported).
>> 
>> ;-)
> 
> I'm investigating the possibilities to support 5200/6200 (and its
> little brother 5300/6300) just because this machine is:
> 
> a) not supported by either MkLinux or LinuxPPC
> b) I have one (in fact my fiancee has it).
> 
> There are several custom chips inside (like on any other Mac).
> First the big problem is that 6200 is a PowerPC inside a 68040
> machine. It uses a "CAPELLA" custom chip as a bus translation
> unit. This may be a problem since I don't think it is used in any
> supported PowerMac.
> 
> RAM: 2 simm slot on a 68040 data bus.
> 
> Video: It is a "Valkyrie" Chip using a DRAM frame buffer. If I
> remember, Valkyrie is available in several PowerMacs and is
> already supported.
> 
> Memory Controller: it is a "F108" as in the LC 630 (ses Linux 68k
> port) that also handles IDE, SCSI and SCC serial ports. SCSI in
> this chip is a NCR 53C96. SCC is like the 8530 SCC (that we find
> in several Macs too).
> 
> ADB: "CUDA" chip similar to several 68k Mac. Accessed thru the
> "PrimeTime II". It is the 68HC05 and also handles PRAM, RTC,
> power supply control.
> 
> Sound: a "DFAC II" chip.
> 
> Other: "PRIMETIME II" chip manages SWIM II, VIA1, VIA2, sound
> controller and I/O bus adpater. Manages ADB sounds, CommSlot, PDS.
> 
> You can find the technote here:
> 
> http://developer.apple.com/techpubs/hardware/hardware2.html
> 

This document does not have enough detail to be able to make a port 
for this hardware.  As far as I know, such details are only available
directly from Apple under NDA until they decide to "leak" the info
out, such as releasing ports, drivers, etc.

> Note that I have no porting experience. :-)

We all start somewhere :-)


------------------------------------------------------------------------
Gary Thomas                              |
email: gdt@linuxppc.org                  | "Fine wine is a necessity of
   ... opinions expressed here are mine  |        life for me"
       and no one else would claim them! |
                                         |      Thomas Jefferson
------------------------------------------------------------------------



[[ 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. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Porting to NuBus PowerMacs

[Hubert Figuiere]

According to Gary Thomas <gdt@linuxppc.org>:

[ porting to 6200 ]
 
> > You can find the technote here:
> > 
> > http://developer.apple.com/techpubs/hardware/hardware2.html
> > 
> 
> This document does not have enough detail to be able to make a port 
> for this hardware.  

I know this. But it helps finding out the general architecture
and tells what is inside so we can start to gather code from
other ports that already guessed things. (like Linux Mac68k)

> As far as I know, such details are only available
> directly from Apple under NDA until they decide to "leak" the info
> out, such as releasing ports, drivers, etc.

I know this too. 

> > Note that I have no porting experience. :-)
> 
> We all start somewhere :-)

Well... you are probably right. I'd better try to boot Linux on
my BeBox :-)


Hub
-- 
> Je souhaiterais essayer Internet Explorer 4.0 sous Linux.
> Il existe 2 versions: une sous HP/UX et une sous Solaris
> Laquelle dois je utiliser?
-+- MJM in Guide du linuxien pervers : "Choisir son environnement" -+-

[[ 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. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

[OT] Re: Porting to NuBus PowerMacs

[Geert Uytterhoeven]

On Wed, 13 Jan 1999, Hubert Figuiere wrote:
> I know this. But it helps finding out the general architecture
> and tells what is inside so we can start to gather code from
> other ports that already guessed things. (like Linux Mac68k)

There's no such thing is Linux Mac68k, AmigaLinux, AtariLinux, ApolloLinux...
They're all called Linux/m68k.

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ 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. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Porting to NuBus PowerMacs

[David A. Gatwood]

On Wed, 13 Jan 1999, Hubert Figuiere wrote:

> I'm investigating the possibilities to support 5200/6200 (and its
> little brother 5300/6300) just because this machine is:
> 
> a) not supported by either MkLinux or LinuxPPC
> b) I have one (in fact my fiancee has it).
> 
> There are several custom chips inside (like on any other Mac).
> First the big problem is that 6200 is a PowerPC inside a 68040
> machine. It uses a "CAPELLA" custom chip as a bus translation
> unit. This may be a problem since I don't think it is used in any
> supported PowerMac.

I don't think the Capella support will be too big a hassle, as I'm under
the impression that such hardware should be mostly software-transparent.
I could be completely wrong, though, as it might need some configuration
with regards to the memory management code or something.  Hopefully not.


> Video: It is a "Valkyrie" Chip using a DRAM frame buffer. If I
> remember, Valkyrie is available in several PowerMacs and is
> already supported.

Yes, and I added some code to at least get closer to suppporting the
Valkyrie on x200/x300 machines already.  That shouldn't be a problem, I
don't think.


> Memory Controller: it is a "F108" as in the LC 630 (ses Linux 68k
> port) that also handles IDE, SCSI and SCC serial ports. SCSI in
> this chip is a NCR 53C96. SCC is like the 8530 SCC (that we find
> in several Macs too).

The memory controller _may_ require some tweaks, but I doubt it, since
booting the machine gets a lot farther than I'd expect if the memory
mapping stuff didn't work.  :-)


> ADB: "CUDA" chip similar to several 68k Mac. Accessed thru the
> "PrimeTime II". It is the 68HC05 and also handles PRAM, RTC,
> power supply control.

As long as we can get the base of the cuda portion of the chip, that's
easy enough.


> Sound: a "DFAC II" chip.

There probably wouldn't be sound support initially, but that's not exactly
a super-high priority compared to booting.  ;-)


> Other: "PRIMETIME II" chip manages SWIM II, VIA1, VIA2, sound

Are you sure it's not a SWIM III?  Because if it's a II, we may have to
add some stuff to the floppy support eventually.  We can probably swipe
code from NetBSD-mac68k, though.  It'll be a pain in the rear, but
workable.  Just a few swimii_blah functions or whatever....

Right now, the big problem is the interrupt controller.  The moment we
enable it, the monitor shuts off (according to several reports).  That's
on the 5x00's, of course, since I don't suppose you can turn off the
monitor in software on the 6x00's.  :-)  Anyway, there are some critical
addresses missing.  If I don't hear any details, I'll try to hack some in
MacsBug....


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

-----BEGIN GEEK CODE BLOCK-----
Version 3.1
GCS/CC/FA/H/L/MC/M/MU/PA/TW d-@ s:>- a-- C++ ++>$ UBLAS*++ ++>$
P+?>$ L++ +>$ !E--- W++ +>$ N++(++ +)>++ +$ !o? K-? !w--- !O
M++>$ !V-- PS+>$ !PE- Y+>$ PGP+>$ t++ +>$ 5+>++ ++$ !X- !R tv+>$
b++>$ !DI !D- G++(++ +)>$ e>++ ++ h--! r--- !y-
------END GEEK CODE BLOCK------


[[ 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. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Porting to NuBus PowerMacs

[David A. Gatwood]

On Tue, 12 Jan 1999, a sun wrote:

>     Oh, and the i/o base address is different, which may or may not be
>     a problem, and supporting certain pieces of hardware (which will
>     remain nameless) will also require speed penalties (this is the
>     other reason MkLinux is slower than LinuxPPC...).
> 
> heh. am i correct in assuming then that just using memory barriers
> just won't cut it for a certain device that seems to have a bunch of
> delay()'s sprinkled throughout it? strangely, this same piece of
> hardware seems to be necessary to get the newer tech g3 extension and
> the mklinux booter happy... any insights there?

Oh, so you heard about that one, eh?  :-)  I got the impression from
sources that will remain nameless that if a certain register is set to
certain values, that certain piece of hardware will either write data to
or read data from the address stored in the register (details are fuzzy,
sorry), and that the issue is forcing the instructions to execute in the
correct order, thus putting a safe value into the register before the sync
instruction (I think) gets called, by means of delays, carefully crafted
branch instructions and other stuff to keep from having to do anything
nasty like a pipeline flush (i.e. even worse delay).  I think I remember
hearing that it only caused problems if the motherboard 601 was running
the machine (i.e. not an upgrade card), but I could be remembering wrong.


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

-----BEGIN GEEK CODE BLOCK-----
Version 3.1
GCS/CC/FA/H/L/MC/M/MU/PA/TW d-@ s:>- a-- C++ ++>$ UBLAS*++ ++>$
P+?>$ L++ +>$ !E--- W++ +>$ N++(++ +)>++ +$ !o? K-? !w--- !O
M++>$ !V-- PS+>$ !PE- Y+>$ PGP+>$ t++ +>$ 5+>++ ++$ !X- !R tv+>$
b++>$ !DI !D- G++(++ +)>$ e>++ ++ h--! r--- !y-

------END GEEK CODE BLOCK------


[[ 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. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Porting to NuBus PowerMacs

[David A. Gatwood]

On Tue, 12 Jan 1999, a sun wrote:

> heh. am i correct in assuming then that just using memory barriers
> just won't cut it for a certain device that seems to have a bunch of
> delay()'s sprinkled throughout it? strangely, this same piece of
> hardware seems to be necessary to get the newer tech g3 extension and
> the mklinux booter happy... any insights there?

Actually, on looking at it, there is the use of memory barriers.  The real
change is in the code for the memory barriers (and possibly in other
places, too... not certain).  See 

.../osfmk/src/mach_kernel/ppc/proc_reg.h:440

in the MkLinux sources.  :-)


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

-----BEGIN GEEK CODE BLOCK-----
Version 3.1
GCS/CC/FA/H/L/MC/M/MU/PA/TW d-@ s:>- a-- C++ ++>$ UBLAS*++ ++>$
P+?>$ L++ +>$ !E--- W++ +>$ N++(++ +)>++ +$ !o? K-? !w--- !O
M++>$ !V-- PS+>$ !PE- Y+>$ PGP+>$ t++ +>$ 5+>++ ++$ !X- !R tv+>$
b++>$ !DI !D- G++(++ +)>$ e>++ ++ h--! r--- !y-
------END GEEK CODE BLOCK------


[[ 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. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Porting to NuBus PowerMacs

[David A. Gatwood]

On Wed, 13 Jan 1999, Gary Thomas wrote:

> > http://developer.apple.com/techpubs/hardware/hardware2.html
> 
> This document does not have enough detail to be able to make a port 
> for this hardware.  As far as I know, such details are only available
> directly from Apple under NDA until they decide to "leak" the info
> out, such as releasing ports, drivers, etc.

True, but some of the information is frequently available through other
means, like information available in MacsBug, especially where hardware
addresses are concerned.  It should be enough to at least get past the
interrupt hurdle (since I think the code's currently putting the interrupt
controller somewhere in the middle of either the ADB hardware or video
hardware (hence the monitor shutting off).  It's not as easy as working
with docs, but it's still (historically speaking, anyway) easier than
actually obtaining docs. ;-)


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

-----BEGIN GEEK CODE BLOCK-----
Version 3.1
GCS/CC/FA/H/L/MC/M/MU/PA/TW d-@ s:>- a-- C++ ++>$ UBLAS*++ ++>$
P+?>$ L++ +>$ !E--- W++ +>$ N++(++ +)>++ +$ !o? K-? !w--- !O
M++>$ !V-- PS+>$ !PE- Y+>$ PGP+>$ t++ +>$ 5+>++ ++$ !X- !R tv+>$
b++>$ !DI !D- G++(++ +)>$ e>++ ++ h--! r--- !y-
------END GEEK CODE BLOCK------


[[ 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. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Porting to NuBus PowerMacs

[Tom Vier]

On Tue, 12 Jan 1999, David A. Gatwood wrote:

> It's a lot harder than this, unfortunately.  The NuBus machines' memory
> isn't contiguous.  Thus, code would have to be written and/or obtained to

doh!

> find out what memory is available in the machine and where that memory is
> located in RAM.  That's going to be a nasty problem unless some code is
> pulled from the MkLinux booter.  I'd expect that to also require a
> substantial number of changes to the way memory is handled in linux, but I
> could be wrong.

hhmmm. don't some other arch's have non contiguous memory?

> Beyond that, it will also require changes to irq.c to handle the interrupt
> controller and a lot of code for DMA, if that's desired (I don't think
> it's even remotely similar, AFAICT).  Of course, that stuff can be
> obtained from Mach, but it'll be a lot of work.  Oh, and the i/o base
> address is different, which may or may not be a problem, and supporting
> certain pieces of hardware (which will remain nameless) will also require
> speed penalties (this is the other reason MkLinux is slower than
> LinuxPPC...).

what pieces of hardware? important ones?

--
Tom Vier - 0x82B007A8
thomassr@erols.com       | goto the Zero Page at:
Tortured Souls Software  | http://www.erols.com/thomassr/zero/


[[ 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. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Porting to NuBus PowerMacs

[Tom Vier]

i'd also be willing to help. i've never really done any low-level
hardware coding, but i can certainly tweak and test things. i have
7100/80 w/ 48megs ram and a spare 1gig i can use to test things, so i
don't screw up my other drives.

On Tue, 12 Jan 1999, Ron Nelson wrote:
> I know you guys are only in the early stages with this but I have a 6100 
> that I will run anything you come up with on.. I don't have mklinux on it
> right now but I could get that on it and be a guinea pig if you need one..

--
Tom Vier - 0x82B007A8
thomassr@erols.com       | goto the Zero Page at:
Tortured Souls Software  | http://www.erols.com/thomassr/zero/



[[ 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. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Porting to NuBus PowerMacs

[Troy Benjegerdes]

> well, my "oh so clever plan" is actually to use the gestalt
> information to mock up something that i pass to the m68k interrupt
> routines. presto! no more uglification of irq.c. given the
> similarities between the apus stuff and the nubus powermac stuff, i'm
> actually turning the nubus powermacs into a variant of apus for now. a
> lot of my fiddling actually ends up making some minor changes to the
> m68k code and calling that instead. 

Cort is in the process of rewriting irq.c, and I have a (somewhat large)
patch based on Corey Minyard's work which redid irq.c and most all the
machine dependant functions. You might want to take a look at this, since
I suspect it might make help reduce the 'uglification'.

it's at 

ftp://ftp.microux.com/pub/linux/linuxppc-rework-troy-2.patch.gz

Btw, I have a 7100/80 I'd like to try this on if you ever get it working
;)

--------------------------------------------------------------------------
| Troy Benjegerdes    |       troy@microux.com     |    hozer@drgw.net   |
|    Unix is user friendly... You just have to be friendly to it first.  |
| This message composed with 100% free software.    http://www.gnu.org   |
--------------------------------------------------------------------------


[[ 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. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Porting to NuBus PowerMacs

[a sun]

   Actually, on looking at it, there is the use of memory barriers.  The real
   change is in the code for the memory barriers (and possibly in other
   places, too... not certain).  See 

   .../osfmk/src/mach_kernel/ppc/proc_reg.h:440

   in the MkLinux sources.  :-)

oh my. i hadn't noticed that. thanks for pointing it out to me. i
guess a plain eieio() is sometimes not good enough... no doubt, the
designers of certain unmentionable devices were being directed by some
cosmic purpose that we, the uninitiated, can only vaguely envision and
hope to understand.

luckily, my trusty g3 upgrade card handily curtails my pursuit into
the ineffable nature of such visionaries. i guess i'll have to add a
CONFIG_601 to deal with certain "third-party" devices though. that
way, we can have just as much fun as the other architectures with
processor-specific tweaks.

-a
asun@u.washington.edu


[[ 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. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Porting to NuBus PowerMacs

[David A. Gatwood]

On Wed, 13 Jan 1999, a sun wrote:

> oh my. i hadn't noticed that. thanks for pointing it out to me. i
> guess a plain eieio() is sometimes not good enough... no doubt, the
> designers of certain unmentionable devices were being directed by some
> cosmic purpose that we, the uninitiated, can only vaguely envision and
> hope to understand.

Actually, I think that the sync was the problem, but eieio might be, too.
I note similar assmbly junk for both, so... who knows....

> luckily, my trusty g3 upgrade card handily curtails my pursuit into
> the ineffable nature of such visionaries. i guess i'll have to add a
> CONFIG_601 to deal with certain "third-party" devices though. that
> way, we can have just as much fun as the other architectures with
> processor-specific tweaks.

Yeah.  I'm planning on releasing certain development kernels (possibly not
mainstream) that use plain old sync and eieio and see what speed
difference it makes.  We might find out that MkLinux's drivers aren't so
bad after all....  You never know.  Anyway, I don't think that register
has always been supported, but somebody with more memory of the MkLinux
coding history could say more (maybe).


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

-----BEGIN GEEK CODE BLOCK-----
Version 3.1
GCS/CC/FA/H/L/MC/M/MU/PA/TW d-@ s:>- a-- C++ ++>$ UBLAS*++ ++>$
P+?>$ L++ +>$ !E--- W++ +>$ N++(++ +)>++ +$ !o? K-? !w--- !O
M++>$ !V-- PS+>$ !PE- Y+>$ PGP+>$ t++ +>$ 5+>++ ++$ !X- !R tv+>$
b++>$ !DI !D- G++(++ +)>$ e>++ ++ h--! r--- !y-
------END GEEK CODE BLOCK------


[[ 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. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Porting to NuBus PowerMacs

[Benjamin Herrenschmidt]

On Tue, Jan 12, 1999, a sun <asun@saul9.u.washington.edu> wrote:

>so, ben, i guess i'll also need memory addresses/sizes as well. after
>perusing the m68k code, i think that's the only thing that i forgot to
>tell you about. this will essentially make bootx report essentially
>the same information as the m68k boot loader.

I'll download this bootloader and see what it does. I don't know exactly
how to get this memory map yet, it would be great if David could manage
to find the info ...

>well, my "oh so clever plan" is actually to use the gestalt
>information to mock up something that i pass to the m68k interrupt
>routines. presto! no more uglification of irq.c. given the
>similarities between the apus stuff and the nubus powermac stuff, i'm
>actually turning the nubus powermacs into a variant of apus for now. a
>lot of my fiddling actually ends up making some minor changes to the
>m68k code and calling that instead. 
>
>for now, i'm conveniently ignoring the dma stuff, but it looks like
>modifying the mac68k devices will actually prove to be more useful
>than dealing with the the standard pci powermac stuff. 

I think so too. And PCI powermac is still evolving, it would be more
difficult to take care of not breaking the NuBus support during evolutions.

-- 
           E-Mail: <mailto:bh40@calva.net>
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. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Porting to Nubus PowerMacs

[Alexander Gustav Deucher]

While we are on the subject of porting, How hard would it be to
get linux ppc to boot on machines with NT firmware?  Does
anyone know why this firmware is so problematic? Is there
anywhere one could find documentation on it, etc.

Alex

[[ 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. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Porting to NuBus PowerMacs

[Jules Bean]

On Wed, 13 Jan 1999, David A. Gatwood wrote:

> 
> On Wed, 13 Jan 1999, Hubert Figuiere wrote:
> 
> > I'm investigating the possibilities to support 5200/6200 (and its
> > little brother 5300/6300) just because this machine is:
> > 
> > a) not supported by either MkLinux or LinuxPPC
> > b) I have one (in fact my fiancee has it).
> > 
> > There are several custom chips inside (like on any other Mac).
> > First the big problem is that 6200 is a PowerPC inside a 68040
> > machine. It uses a "CAPELLA" custom chip as a bus translation
> > unit. This may be a problem since I don't think it is used in any
> > supported PowerMac.

I've got a 5200, which I am keen to get Linux running on at some point.
The amount of time I can put aside is rather variable, but I do have some
limited kernel hacking experience from my NetBSD/m68k days..

Willing to help, in short,

Jules

/----------------+-------------------------------+---------------------\
|  Jelibean aka  | jules@jellybean.co.uk         |  6 Evelyn Rd	       |
|  Jules aka     | jules@debian.org              |  Richmond, Surrey   |
|  Julian Bean   | jmlb2@hermes.cam.ac.uk        |  TW9 2TF *UK*       |
+----------------+-------------------------------+---------------------+
|  War doesn't demonstrate who's right... just who's left.             |
|  When privacy is outlawed... only the outlaws have privacy.          |
\----------------------------------------------------------------------/


[[ 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. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Porting to NuBus PowerMacs

[Michael Schmitz]

At 12:55 PM -0600 1/13/99, David A. Gatwood wrote:
>On Wed, 13 Jan 1999, Hubert Figuiere wrote:
>> ADB: "CUDA" chip similar to several 68k Mac. Accessed thru the
>> "PrimeTime II". It is the 68HC05 and also handles PRAM, RTC,
>> power supply control.
>
>As long as we can get the base of the cuda portion of the chip, that's
>easy enough.

The CUDA hangs off VIA1 in the m68k machines. If this machine is just a
040 Mac with a PPC glued on top, the m68k code should do.

VIA1 and VIA2 are at fairly constant base addresses throughout the
m68k series. But Apple might have played some tricks on us again :-(

	Michael



[[ 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. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Porting to NuBus PowerMacs

[David A. Gatwood]

On Thu, 14 Jan 1999, Michael Schmitz wrote:

> The CUDA hangs off VIA1 in the m68k machines. If this machine is just a
> 040 Mac with a PPC glued on top, the m68k code should do.

Basically, yeah.


> VIA1 and VIA2 are at fairly constant base addresses throughout the
> m68k series. But Apple might have played some tricks on us again :-(

'course I don't even know the base address for the IO space, but I'm
gathering it's the same as the PDMs, and I vaguely remember reading that
somewhere.  Right now, the question basically boils down to the display
going off (or black or something) when interrupts are enabled.  If we can
get past that, it should be mostly smooth sailing.  We'll have to have
base addresses for the IDE hardware, but I'd expect it to share that with
the NuBus PowerBooks....  Apple's addresses seem to be very similar
between the PDMs, the PERFORMA class, and the POWERBOOK class (NuBus).


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

-----BEGIN GEEK CODE BLOCK-----
Version 3.1
GCS/CC/FA/H/L/MC/M/MU/PA/TW d-@ s:>- a-- C++ ++>$ UBLAS*++ ++>$
P+?>$ L++ +>$ !E--- W++ +>$ N++(++ +)>++ +$ !o? K-? !w--- !O
M++>$ !V-- PS+>$ !PE- Y+>$ PGP+>$ t++ +>$ 5+>++ ++$ !X- !R tv+>$
b++>$ !DI !D- G++(++ +)>$ e>++ ++ h--! r--- !y-

------END GEEK CODE BLOCK------


[[ 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. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Porting to Nubus PowerMacs

[Gabriel Paubert]

On Thu, 14 Jan 1999, Alexander Gustav Deucher wrote:

> 
> While we are on the subject of porting, How hard would it be to
> get linux ppc to boot on machines with NT firmware?  Does
> anyone know why this firmware is so problematic? Is there
> anywhere one could find documentation on it, etc.

This firmware might even try to boot the image in little endian mode,
handling the setting of the processor is rather simple, but resetting the
host bridge to big endian operation might be very complex and HW
dependant. 

Could you try the zImage and the preploader on my ftp site:

	ftp://vcorr1.iram.es/pub/zImage-2.2.0-pre5
	ftp://vcorr1.iram.es/pub/preploader.tgz

(preploader is an experimental early boot code which will take your
/usr/src/vmlinux and build a zImage ready to boot from 0x41 partition). It
could be hacked to spit out a lot of info about what the state of the
machine is when the loaded image gets control.

	Gabriel.


[[ 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. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Porting to Nubus PowerMacs

[Troy Benjegerdes]

On Thu, 14 Jan 1999, Gabriel Paubert wrote:
> On Thu, 14 Jan 1999, Alexander Gustav Deucher wrote:
> 
> > 
> > While we are on the subject of porting, How hard would it be to
> > get linux ppc to boot on machines with NT firmware?  Does
> > anyone know why this firmware is so problematic? Is there
> > anywhere one could find documentation on it, etc.

Is this Open Firmware or some derivative of PPCbug?? I though NT required
Open Firmware (which would mean the preploader wouldn't work too well)

> 
> This firmware might even try to boot the image in little endian mode,
> handling the setting of the processor is rather simple, but resetting the
> host bridge to big endian operation might be very complex and HW
> dependant. 
> 
> Could you try the zImage and the preploader on my ftp site:
> 
> 	ftp://vcorr1.iram.es/pub/zImage-2.2.0-pre5
> 	ftp://vcorr1.iram.es/pub/preploader.tgz
> 
> (preploader is an experimental early boot code which will take your
> /usr/src/vmlinux and build a zImage ready to boot from 0x41 partition). It
> could be hacked to spit out a lot of info about what the state of the
> machine is when the loaded image gets control.
> 
> 	Gabriel.
> 
> 
> 

--------------------------------------------------------------------------
| Troy Benjegerdes    |       troy@microux.com     |    hozer@drgw.net   |
|    Unix is user friendly... You just have to be friendly to it first.  |
| This message composed with 100% free software.    http://www.gnu.org   |
--------------------------------------------------------------------------


[[ 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. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Porting to Nubus PowerMacs

[Gabriel Paubert]

On Fri, 15 Jan 1999, Troy Benjegerdes wrote:

> On Thu, 14 Jan 1999, Gabriel Paubert wrote:
> > On Thu, 14 Jan 1999, Alexander Gustav Deucher wrote:
> > 
> > > 
> > > While we are on the subject of porting, How hard would it be to
> > > get linux ppc to boot on machines with NT firmware?  Does
> > > anyone know why this firmware is so problematic? Is there
> > > anywhere one could find documentation on it, etc.
> 
> Is this Open Firmware or some derivative of PPCbug?? I though NT required
> Open Firmware (which would mean the preploader wouldn't work too well)
> 

This is a message I got from Alois Fertl:

AF> I tried the preploader on a Motorola Pro2000/200. This is a system
AF> originally developed to run Windows NT. It has a 603ev, IBM660 PCI
AF> bridge and a WINBOND chip (no SCSI, E-Net and VGA on the mainboard).
AF> This system by default was shipped with the Motorola PowerPC firmware
AF> (not PPCBug) which claims to be able to boot PReP operating Systems
AF> but I never got this Firmware to boot ppclinux.
AF>
AF> With some small changes to misc.c of the normal boot code I got it
AF> to successfully load, uncompress but "Now booting the Kernel"
AF> was the last message I ever got from this system. After many hours
AF> of poking around I found the reason why this happens. The Firmware
AF> uses one IBAT and all DBAT registers but does not deinitialize them
AF> before it calles the loaded core. I think the kernel code than
AF> initializes those BAT entries it wants to use and enables the MMU.
AF> This will also reactivate the remainding BAT entries which are
AF> never invalidated. This and residual related items also keep the
AF> preploader from working correctly.

I have added code to invalidate BATs early in my latest preploader,
so yes I think it's still worth testing on more machines. There are 
other issues on which I'm still waiting for patches from Alois
(residual data and PCI configuration related) but he got it to boot. 

	Gabriel.


[[ 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. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Porting to Nubus PowerMacs

[Alois Fertl]

Gabriel Paubert wrote:
> 
> On Fri, 15 Jan 1999, Troy Benjegerdes wrote:
> 
> > On Thu, 14 Jan 1999, Gabriel Paubert wrote:
> > > On Thu, 14 Jan 1999, Alexander Gustav Deucher wrote:
> > >
> > > >
> > > > While we are on the subject of porting, How hard would it be to
> > > > get linux ppc to boot on machines with NT firmware?  Does
> > > > anyone know why this firmware is so problematic? Is there
> > > > anywhere one could find documentation on it, etc.
> >
> > Is this Open Firmware or some derivative of PPCbug?? I though NT required
> > Open Firmware (which would mean the preploader wouldn't work too well)
> >
It is something called "Motorola PowerPC firmware.
During the "PPC NT period" there where three different kinds of firmware
on Motorola products:
   PPCBug
   Motorola PowerPC firmware 	- Used on boxes shipped with NT
   PowerPC Open Firmware

Alexander can you please give me the version of the firmware (something
like 3.0x.0x.
I hasitate to make to much noise about my findings because
1) I'm struggeling a problem with different versions of this Firmware;
   one boots the floppy but the other one refuses this.
2) I'm not shure how many potential systems there are.
3) To get the kernel running with the standard IDE equipment I had to add
   some changes which according to Cort will break IDE on IBM.

Please also cc responses to alois_fertl@TalkNet.de
   Alois
> 
> This is a message I got from Alois Fertl:
> 
> AF> I tried the preploader on a Motorola Pro2000/200. This is a system
> AF> originally developed to run Windows NT. It has a 603ev, IBM660 PCI
> AF> bridge and a WINBOND chip (no SCSI, E-Net and VGA on the mainboard).
> AF> This system by default was shipped with the Motorola PowerPC firmware
> AF> (not PPCBug) which claims to be able to boot PReP operating Systems
> AF> but I never got this Firmware to boot ppclinux.
> AF>
> AF> With some small changes to misc.c of the normal boot code I got it
> AF> to successfully load, uncompress but "Now booting the Kernel"
> AF> was the last message I ever got from this system. After many hours
> AF> of poking around I found the reason why this happens. The Firmware
> AF> uses one IBAT and all DBAT registers but does not deinitialize them
> AF> before it calles the loaded core. I think the kernel code than
> AF> initializes those BAT entries it wants to use and enables the MMU.
> AF> This will also reactivate the remainding BAT entries which are
> AF> never invalidated. This and residual related items also keep the
> AF> preploader from working correctly.
> 
> I have added code to invalidate BATs early in my latest preploader,
> so yes I think it's still worth testing on more machines. There are
> other issues on which I'm still waiting for patches from Alois
> (residual data and PCI configuration related) but he got it to boot.
> 
>         Gabriel.

[[ 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. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Porting to Nubus PowerMacs

[Cort Dougan]

I didn't mean to reject them outright.  They do need to be reworked a bit
so they don't kill IDE on the IBMs, though.

}3) To get the kernel running with the standard IDE equipment I had to add
}   some changes which according to Cort will break IDE on IBM.


[[ 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. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]