Re: Performa 5200

Re: Performa 5200

[Benjamin Herrenschmidt]

On Wed, Aug 25, 1999, David A. Gatwood <dgatwood@mvista.com> wrote:

>It's a bad idea to have any of these three in the same class.  They don't
>act a thing alike.  The NuBus PowerBooks and Performas are KIND of close,
>in that neither has DMA, but their IDE works with different offsets
>between registers, their interrupt handling is almost completely
>different, the video is different... it's substantial enough to make it
>far better to define them as separate classes.  Otherwise, all those
>pieces of code will be riddled with switch statements for a huge list of
>gestalts (16 different numbers for the PDMs alone).
>
>If you want to maintain some sense of naming consistency with MkLinux
>(which is a good idea), we use:
>
>POWERMAC_CLASS_PCI       - almost everything
>POWERMAC_CLASS_PDM       - 6/7/81xx, AWS 6/7/81xx
>POWERMAC_CLASS_POWERBOOK - NuBus PowerBooks
>POWERMAC_CLASS_PERFORMA  - NuBus Performas
>POWERMAC_CLASS_LEGACY    - 68k PowerMacs w/ upgrade cards

BootX already provides this classification (and the huge list of machine
IDs), It only lacks POWERMAC_CLASS_LEGACY for now. (BTW. what about
switching MkLinux to use BootX too instead of the current closed source
booter ?).

We can have all those in the same "Nubus" class in a sense that support
for all those machine can be compiled at the same time (eventually having
optional compiled-in subclasses for the different classes, except PCI).
I'm still wondering if we can have this support without killing the PCI
support (if they must be exclusive). They are not with mklinux but I
don't want to pollute the PCI version of linux/ppc with things like the
eieio/sync hack needed for some NuBus machines, and the memory management
cludges needed for PDM.

>Note that the last two are not quite working yet.  We were close on the
>performas, and the 68k PowerMacs aren't quite as close, but at least some
>of them start booting now with the right config.

I must have a PPC ugrade card and the Quadra 800 that goes with it
somewhere, I'll try to find it, I think it's still in Strasbourg (500Km
away from where I live now).

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

Performa 5200

[Tony Mantler]

Hello PPC folk,

I recently obtained for myself up a Performa 5200, and I've been playing
with trying to hack linux into shape on it. (I'm usually a Mac68k guy)

I compiled a kernel from a stock 2.2.10 tree that I have laying around
(from ftp.kernel.org, most every config option turned off, booting with
BootX) and, after sprinkling around a bit of debug code, found that it
makes it past the prom.c code where it draws the "Welcome to linux
[blahblah] booting...", but doesn't make it to start_kernel after that.

I'm not particularily fluent in PPC ASM, so head.S makes fairly opaque
reading for me. I'm wondering if someone might have some pointers to where
this would likely be dying, so I have good a place to start?

Thanks.


Cheers - Tony :)


--
Tony Mantler         Renaissance Nerd Extraordinaire         eek@escape.ca
Winnipeg, Manitoba, Canada                       http://www.escape.ca/~eek


[[ 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: Performa 5200

[Benjamin Herrenschmidt]

On Tue, Aug 24, 1999, Tony Mantler <eek@escape.ca> wrote:

>I recently obtained for myself up a Performa 5200, and I've been playing
>with trying to hack linux into shape on it. (I'm usually a Mac68k guy)
>
>I compiled a kernel from a stock 2.2.10 tree that I have laying around
>(from ftp.kernel.org, most every config option turned off, booting with
>BootX) and, after sprinkling around a bit of debug code, found that it
>makes it past the prom.c code where it draws the "Welcome to linux
>[blahblah] booting...", but doesn't make it to start_kernel after that.
>
>I'm not particularily fluent in PPC ASM, so head.S makes fairly opaque
>reading for me. I'm wondering if someone might have some pointers to where
>this would likely be dying, so I have good a place to start?

is this a NuBus class machine or a PCI based one ? If it's a NuBus one,
then you are out of luck, or if you have time to spend, you can begin
porting linux/ppc to those beasts. (Basically, RAM is not contiguous and
you cannot rely in the kernel beeing loaded at physical 0, since the
frame buffer may be hard coded at physical 1Mb). Look at the various
parameters BootX pass for a NuBus machine (using the latest 2.1.12 kernel
from vger or Paul's rsync, you should have the latest bootx.h).


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

Re: Performa 5200

[Dave Weis]

> >I'm not particularily fluent in PPC ASM, so head.S makes fairly opaque
> >reading for me. I'm wondering if someone might have some pointers to where
> >this would likely be dying, so I have good a place to start?
> 
> is this a NuBus class machine or a PCI based one ? If it's a NuBus one,
> then you are out of luck, or if you have time to spend, you can begin
> porting linux/ppc to those beasts. (Basically, RAM is not contiguous and
> you cannot rely in the kernel beeing loaded at physical 0, since the
> frame buffer may be hard coded at physical 1Mb). Look at the various
> parameters BootX pass for a NuBus machine (using the latest 2.1.12 kernel
> from vger or Paul's rsync, you should have the latest bootx.h).

Depending on how in to the 68k boxes you are, the impression I got is that
the memory structure is very similar to the 68ks of the same shape/era. I
tried it on my wife's 6114CD and it hung with just the desktop background
visible. Mix and match some of the mac68k code and you should be done in
no time :-) haha

If you need any other machines to test a kernel on, let me know.

dave

-- 
David Weis                | 10520 New York Ave, Des Moines, IA 50322
djweis@plconline.com      | Voice 515-278-0133 Ext 231

When they took the Fourth Amendment, I was quiet because I didn't deal drugs.
When they took the Sixth Amendment, I was quiet because I was innocent.
When they took the Second Amendment, I was quiet because I didn't own a gun.
Now they've taken the First Amendment and I can't say anything.


[[ 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: Performa 5200

[David A. Gatwood]

On Tue, 24 Aug 1999, Dave Weis wrote:

> Depending on how in to the 68k boxes you are, the impression I got is that
> the memory structure is very similar to the 68ks of the same shape/era. I
> tried it on my wife's 6114CD and it hung with just the desktop background
> visible. Mix and match some of the mac68k code and you should be done in
> no time :-) haha

It's a nasty mismatch.  It's basically a Quadra 630, but with Valkyrie for
video, a few other small changes, and an added PPC to 68k bus bridge that
probably needs to have at least minimal support, and a bunch of other
oddities.  Hmmm.  That brings up another place where the code could be
going wrong.


David


[[ 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: Performa 5200

[Tony Mantler]

>On Tue, Aug 24, 1999, Tony Mantler <eek@escape.ca> wrote:
>
>>I recently obtained for myself up a Performa 5200, and I've been playing
>>with trying to hack linux into shape on it. (I'm usually a Mac68k guy)
>>
[...]

At 4:06 AM -0500 8/24/99, Benjamin Herrenschmidt wrote:
>is this a NuBus class machine or a PCI based one ? If it's a NuBus one,
>then you are out of luck, or if you have time to spend, you can begin
>porting linux/ppc to those beasts. (Basically, RAM is not contiguous and
>you cannot rely in the kernel beeing loaded at physical 0, since the
>frame buffer may be hard coded at physical 1Mb). Look at the various
>parameters BootX pass for a NuBus machine (using the latest 2.1.12 kernel
>from vger or Paul's rsync, you should have the latest bootx.h).

(2.1.12? I assume that's 2.3.12?)

It's a NuBus machine (though it doesn't actually have any NuBus slots). It
shares the same address maps as the 68k machines, which puts ram in a
contiguous block starting at 0x0, ROM at 0x40800000, IO at 0x50F00000 and
NuBus 'super' regions from 0x90000000 to 0xEFFFFFFF, and NuBus 'regular'
regions from 0xF9000000 to 0xFEFFFFFF (framebuffer is in slot $9 'regular'
space, starts at 0xF9001000).

I'm not sure which models have the f*ed up address maps, but I'm sure glad
I don't have one of them. :)


At 10:38:51 AM -0700 8/24/99, David A. Gatwood wrote:
>If I were you, I'd look at MkLinux, _not_ LinuxPPC.  I got about 2/3rds of
>the 52/53/62/6300 support already in there.  The interrupt handling code
>is written and should be close to correct, along with hard-coded addresses
>for serial hardware, video, IDE, SCSI... it's basically 90% finished.
>It's the 10% that I can't do anymore, since I no longer have access to the
>machines in question.

Yeah, I should probably work on MkLinux, but what would the fun in that be? :)

I think I'm mostly partial to LinuxPPC because I can actually pretend to be
familiar with how the Monolithic linux kernel works, and because I think
LinuxPPC should have the option of supporting all PPC models.


>Some models of machines in that family get a long way into the boot
>process, some freeze at the MkLinux Booter's splash screen, and I haven't
>have time to try to figure out the difference.  Could be anything from RAM
>size to whether it has a 603 vs. 603e.  I'm leaning towards the latter.
>That's probably what's wrong in LinuxPPC's head.S, too, since I don't
>think either one has ever supported a machine w/ an original 603.  Grab
>yourself a couple of microprocessor reference guides.  :-)

Time to learn PPC ASM I guess. :)


>LinuxPPC's interrupt handling code is not well suited to the design of the
>interrupt hardware in the NuBus 5x00 machines, since A. it has no master
>interrupt flag register or interrupt control register, and B. it has other
>interrupt hardware scattered in weird places throughout the hardware.
>It woudl be a _very_ massive hack to get it working under LinuxPPC,
>especially since even 6/7/8100 support isn't there (which is a necessary
>foundation for some of the MkLinux 5x00 changes).  It's also a heck of a
>lot easier to start with something that almost works than to start with
>somnething that's not remotely close.  ;-)

Yeah, I figure the two biggest hurdles I'm going to have to deal with is a:
getting it to boot, and b: getting the interrupts to work. After that, it's
just a matter of tweaking drivers, and luckily there's a whole lot of
shared code between Mac68k and LinuxPPC drivers. (CUDA ADB, Valkyrie video,
I think the serial driver too, and so forth)

(If anyone's interested, I wrote up a few docs on Mac68k interrupts, and
the functioning of the evil VIAs (and emulations thereof))


I'm starting to think that I should carve out a new machine class in the
config options (#ifdef CONFIG_WUSSY_68K_PMAC?) ;)


Cheers - Tony :)


--
Tony Mantler         Renaissance Nerd Extraordinaire         eek@escape.ca
Winnipeg, Manitoba, Canada                       http://www.escape.ca/~eek


[[ 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: Performa 5200

[Benjamin Herrenschmidt]

On Tue, Aug 24, 1999, Tony Mantler <eek@escape.ca> wrote:

>(2.1.12? I assume that's 2.3.12?)

Sorry for the typo, it's actually 2.2.12, I don't know if all this was
already included in the 2.3.x tree.

>It's a NuBus machine (though it doesn't actually have any NuBus slots). It
>shares the same address maps as the 68k machines, which puts ram in a
>contiguous block starting at 0x0, ROM at 0x40800000, IO at 0x50F00000 and
>NuBus 'super' regions from 0x90000000 to 0xEFFFFFFF, and NuBus 'regular'
>regions from 0xF9000000 to 0xFEFFFFFF (framebuffer is in slot $9 'regular'
>space, starts at 0xF9001000).
>
>I'm not sure which models have the f*ed up address maps, but I'm sure glad
>I don't have one of them. :)

all the x100 machines have address maps that depends on the population of
the RAM slots. Also, some of them have a DRAM-based frame buffer working
at a fixed physical address which can be either 0 or 1Mb.
BootX will load the kernel in the first contiguous region in memory it
can find, but that means that we have to copy the exception vectors to 0,
adjust them so they call correctly the kernel routines in the real base
of the kernel (which will not be 0 on some machines), and we'll have
virt_to_phys and co be non-constant. I read an interesting suggestion
some time ago of reserving a register during kernel compile with gcc and
using this register to store the real base of the kernel. Modules will
not be compatible, but that's not a real issue for now.
I don't know how the APUS code works, but I heard it is similar.

Also, we'll have to handle cache incoherency of DMA, and so on, but if
you manage to get the basic work done, I'll be able to help writing
driver (if I manage to get one of those machines, which is not sure).

>>LinuxPPC's interrupt handling code is not well suited to the design of the
>>interrupt hardware in the NuBus 5x00 machines, since A. it has no master
>>interrupt flag register or interrupt control register, and B. it has other
>>interrupt hardware scattered in weird places throughout the hardware.
>>It woudl be a _very_ massive hack to get it working under LinuxPPC,
>>especially since even 6/7/8100 support isn't there (which is a necessary
>>foundation for some of the MkLinux 5x00 changes).  It's also a heck of a
>>lot easier to start with something that almost works than to start with
>>somnething that's not remotely close.  ;-)
>
>Yeah, I figure the two biggest hurdles I'm going to have to deal with is a:
>getting it to boot, and b: getting the interrupts to work. After that, it's
>just a matter of tweaking drivers, and luckily there's a whole lot of
>shared code between Mac68k and LinuxPPC drivers. (CUDA ADB, Valkyrie video,
>I think the serial driver too, and so forth)
>
>(If anyone's interested, I wrote up a few docs on Mac68k interrupts, and
>the functioning of the evil VIAs (and emulations thereof))

>
>I'm starting to think that I should carve out a new machine class in the
>config options (#ifdef CONFIG_WUSSY_68K_PMAC?) ;)

Or simply CONFIG_NUBUS_PMAC... BootX will tell you if you are running on
one of those and will tell you if it's a PDM based (x100), performa or
powerbook (5300/1400). It will also give you the gestalt machineID and
the phys. memory map table. If you need more infos, tell me, but I
beleive most of the other infos will have to be hard coded.

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

Re: Performa 5200

[Tony Mantler]

At 5:23 AM -0500 8/25/99, Benjamin Herrenschmidt wrote:
>On Tue, Aug 24, 1999, Tony Mantler <eek@escape.ca> wrote:
>
>>(2.1.12? I assume that's 2.3.12?)
>
>Sorry for the typo, it's actually 2.2.12, I don't know if all this was
>already included in the 2.3.x tree.

Ah, ok. I'm on a 28.8 here, so I'm trying to avoid downloading too many
kernels.


[...]
>all the x100 machines have address maps that depends on the population of
>the RAM slots. Also, some of them have a DRAM-based frame buffer working
>at a fixed physical address which can be either 0 or 1Mb.
>BootX will load the kernel in the first contiguous region in memory it
>can find, but that means that we have to copy the exception vectors to 0,
>adjust them so they call correctly the kernel routines in the real base
>of the kernel (which will not be 0 on some machines), and we'll have
>virt_to_phys and co be non-constant. I read an interesting suggestion
>some time ago of reserving a register during kernel compile with gcc and
>using this register to store the real base of the kernel. Modules will
>not be compatible, but that's not a real issue for now.
>I don't know how the APUS code works, but I heard it is similar.

Yeek. Sounds like a messed up version of RBV (IIsi). On that particular
machine (iirc), the start of real useable ram, where the kernel is located,
is remapped down to 0x0, and the framebuffer is mapped way up into (I
think) slot $9 regular space to mimic the configuration of the slightly
more sane macs.


>Also, we'll have to handle cache incoherency of DMA, and so on, but if
>you manage to get the basic work done, I'll be able to help writing
>driver (if I manage to get one of those machines, which is not sure).

I know the '040 maintains consistiency during the operation of alternate
bus masters by snooping and spiking the bus according to what's in the
cache. I haven't read up on how the PPC does it, but I would have expected
it to be made code-level compatible with what the 040 does, atleast in
these early PMacs.


>>I'm starting to think that I should carve out a new machine class in the
>>config options (#ifdef CONFIG_WUSSY_68K_PMAC?) ;)
>
>Or simply CONFIG_NUBUS_PMAC... BootX will tell you if you are running on
>one of those and will tell you if it's a PDM based (x100), performa or
>powerbook (5300/1400). It will also give you the gestalt machineID and
>the phys. memory map table. If you need more infos, tell me, but I
>beleive most of the other infos will have to be hard coded.

Or something like that.

Penguin collects a pile of LM globals and passes them in the bi struct, but
most of those can be implied from the gestalt machine ID. Considering the
number of NuBus PMacs, I don't think it would be terribly difficult to
guess anything that's not passed in explicitly.

But, I shan't pay any note of it 'till *after* I get a kernel to boot. :)


Cheers - Tony :)


--
Tony Mantler         Renaissance Nerd Extraordinaire         eek@escape.ca
Winnipeg, Manitoba, Canada                       http://www.escape.ca/~eek


[[ 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: Performa 5200

[David A. Gatwood]

On Wed, 25 Aug 1999, Tony Mantler wrote:

> [...]
> >all the x100 machines have address maps that depends on the population of
> >the RAM slots. Also, some of them have a DRAM-based frame buffer working
> >at a fixed physical address which can be either 0 or 1Mb.
> >BootX will load the kernel in the first contiguous region in memory it
> >can find, but that means that we have to copy the exception vectors to 0,
> >adjust them so they call correctly the kernel routines in the real base
> >of the kernel (which will not be 0 on some machines), and we'll have
> >virt_to_phys and co be non-constant. I read an interesting suggestion
> >some time ago of reserving a register during kernel compile with gcc and
> >using this register to store the real base of the kernel. Modules will
> >not be compatible, but that's not a real issue for now.
> >I don't know how the APUS code works, but I heard it is similar.
> 
> Yeek. Sounds like a messed up version of RBV (IIsi). On that particular
> machine (iirc), the start of real useable ram, where the kernel is located,
> is remapped down to 0x0, and the framebuffer is mapped way up into (I
> think) slot $9 regular space to mimic the configuration of the slightly
> more sane macs.

Not quite.  It moves from 0 to something like 0x10000, but there may be
more zeroes than that.  That's the PDM's.  If you're asking about the
52/53/62/6300's, though, they use a Valkyrie just like the 5400.  They
have nothing in common with the 6100.  They don't even have DMA support.


> >>I'm starting to think that I should carve out a new machine class in the
> >>config options (#ifdef CONFIG_WUSSY_68K_PMAC?) ;)
> >
> >Or simply CONFIG_NUBUS_PMAC... BootX will tell you if you are running on
> >one of those and will tell you if it's a PDM based (x100), performa or
> >powerbook (5300/1400). It will also give you the gestalt machineID and
> >the phys. memory map table. If you need more infos, tell me, but I
> >beleive most of the other infos will have to be hard coded.

It's a bad idea to have any of these three in the same class.  They don't
act a thing alike.  The NuBus PowerBooks and Performas are KIND of close,
in that neither has DMA, but their IDE works with different offsets
between registers, their interrupt handling is almost completely
different, the video is different... it's substantial enough to make it
far better to define them as separate classes.  Otherwise, all those
pieces of code will be riddled with switch statements for a huge list of
gestalts (16 different numbers for the PDMs alone).

If you want to maintain some sense of naming consistency with MkLinux
(which is a good idea), we use:

POWERMAC_CLASS_PCI       - almost everything
POWERMAC_CLASS_PDM       - 6/7/81xx, AWS 6/7/81xx
POWERMAC_CLASS_POWERBOOK - NuBus PowerBooks
POWERMAC_CLASS_PERFORMA  - NuBus Performas
POWERMAC_CLASS_LEGACY    - 68k PowerMacs w/ upgrade cards

Note that the last two are not quite working yet.  We were close on the
performas, and the 68k PowerMacs aren't quite as close, but at least some
of them start booting now with the right config.


Later,
David


[[ 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: Performa 5200

[Tony Mantler]

At 10:43 PM -0500 8/25/99, David A. Gatwood wrote:
>On Wed, 25 Aug 1999, Tony Mantler wrote:
>
[...]
>> Yeek. Sounds like a messed up version of RBV (IIsi). On that particular
>> machine (iirc), the start of real useable ram, where the kernel is located,
>> is remapped down to 0x0, and the framebuffer is mapped way up into (I
>> think) slot $9 regular space to mimic the configuration of the slightly
>> more sane macs.
>
>Not quite.  It moves from 0 to something like 0x10000, but there may be
>more zeroes than that.  That's the PDM's.  If you're asking about the
>52/53/62/6300's, though, they use a Valkyrie just like the 5400.  They
>have nothing in common with the 6100.  They don't even have DMA support.

Actually the ESP SCSI and SONIC ethernet (comslot) should do DMA on the
performas. Anything else stuck in the Comslot or PDS can do DMA too. (iirc)

It's not very *good* DMA support, but, you know...


[...]
>> >Or simply CONFIG_NUBUS_PMAC... BootX will tell you if you are running on
>> >one of those and will tell you if it's a PDM based (x100), performa or
>> >powerbook (5300/1400). It will also give you the gestalt machineID and
>> >the phys. memory map table. If you need more infos, tell me, but I
>> >beleive most of the other infos will have to be hard coded.
>
>It's a bad idea to have any of these three in the same class.  They don't
>act a thing alike.  The NuBus PowerBooks and Performas are KIND of close,
>in that neither has DMA, but their IDE works with different offsets
>between registers, their interrupt handling is almost completely
>different, the video is different... it's substantial enough to make it
>far better to define them as separate classes.  Otherwise, all those
>pieces of code will be riddled with switch statements for a huge list of
>gestalts (16 different numbers for the PDMs alone).

I think seperating based on how the interrupts are handled is a good idea.
The Video, DMA bits and IDE are just a matter of different drivers, not
really worth splitting the machine class on it's own.


>If you want to maintain some sense of naming consistency with MkLinux
>(which is a good idea), we use:
>
>POWERMAC_CLASS_PCI       - almost everything
>POWERMAC_CLASS_PDM       - 6/7/81xx, AWS 6/7/81xx
>POWERMAC_CLASS_POWERBOOK - NuBus PowerBooks
>POWERMAC_CLASS_PERFORMA  - NuBus Performas
>POWERMAC_CLASS_LEGACY    - 68k PowerMacs w/ upgrade cards
>
>Note that the last two are not quite working yet.  We were close on the
>performas, and the 68k PowerMacs aren't quite as close, but at least some
>of them start booting now with the right config.

I'm curious why you separated the Performa's from the PPC upgraded 68k's.
>From what I understand, the logical layout of the hardware is very similar
(PPC chip bridged onto the 68k bus), and Linux/Mac68k has no troubles
supporting all 68k machines under one machine class. Are there differences
in the way the PPC->68k bridging is done?


Anyways, I really must get myself a dead-tree version of the PPC
Programming Environment Manual. Does Motorolla still give those books away
for free?

Cheers - Tony :)


--
Tony Mantler         Renaissance Nerd Extraordinaire         eek@escape.ca
Winnipeg, Manitoba, Canada                       http://www.escape.ca/~eek


[[ 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: Performa 5200

[David A. Gatwood]

On Wed, 25 Aug 1999, Tony Mantler wrote:

> >Not quite.  It moves from 0 to something like 0x10000, but there may be
> >more zeroes than that.  That's the PDM's.  If you're asking about the
> >52/53/62/6300's, though, they use a Valkyrie just like the 5400.  They
> >have nothing in common with the 6100.  They don't even have DMA support.
> 
> Actually the ESP SCSI and SONIC ethernet (comslot) should do DMA on the
> performas. Anything else stuck in the Comslot or PDS can do DMA too. (iirc)

It's based on the Q630 (I believe), not the AV Quadras.  In other words,
it has no DMA controller chip, which rules out real DMA.  The SONIC card
should have its own memory on the card that it uses for buffers, AFAIK. 
Optimally, you'd to pseudo-DMA on the "ESP" (53C94).


> I think seperating based on how the interrupts are handled is a good idea.
> The Video, DMA bits and IDE are just a matter of different drivers, not
> really worth splitting the machine class on it's own.

Maybe.  You're still dividing it the same way, though.  There are three
primary setups:

PDM       Has master ICR/IFR
PowerBook similar to PDM with DMA stripped, IDE added, some other changes
Performa  Not similar to anything -- no master ICR, etc.  Interrupt
          regs do not match more recent machines.
Legacy    similar to Performa, with different secondary interrupt control
          hardware at different locations, I think.


> >Note that the last two are not quite working yet.  We were close on the
> >performas, and the 68k PowerMacs aren't quite as close, but at least some
> >of them start booting now with the right config.
> 
> I'm curious why you separated the Performa's from the PPC upgraded 68k's.

We have to do some weird twiddling to make the ppc-upgraded 68k's get past
the booter.  That and I don't think the ppc<- ->68k bus bridge is the same
in the two machines, though I'm not sure about that.  The most annoying
thing is that the 68k machines had no main interrupt controller, and I
think some of the interrupt hardware is in different places on the
Performas, which makes it obnoxious.  It's workable to keep them together,
and I seriously considered it before deciding to go with a separate class.
I think there may have been other reasons, but I can't remember what.


> >From what I understand, the logical layout of the hardware is very similar
> (PPC chip bridged onto the 68k bus), and Linux/Mac68k has no troubles
> supporting all 68k machines under one machine class. Are there differences
> in the way the PPC->68k bridging is done?

I _think_ it's a different bridge chip, but I haven't actually dismantled
a PPC upgrade card to find out for sure.  :-)


> Anyways, I really must get myself a dead-tree version of the PPC
> Programming Environment Manual. Does Motorolla still give those books away
> for free?

Heheh.


David


[[ 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: Performa 5200

[Tony Mantler]

At 11:38 PM -0500 8/25/99, David A. Gatwood wrote:
>On Wed, 25 Aug 1999, Tony Mantler wrote:
>> Actually the ESP SCSI and SONIC ethernet (comslot) should do DMA on the
>> performas. Anything else stuck in the Comslot or PDS can do DMA too. (iirc)
>
>It's based on the Q630 (I believe), not the AV Quadras.  In other words,
>it has no DMA controller chip, which rules out real DMA.  The SONIC card
>should have its own memory on the card that it uses for buffers, AFAIK.
>Optimally, you'd to pseudo-DMA on the "ESP" (53C94).

Well, the macsonic.c driver has plenty of DMA type code in it, so I'd be
inclined to belive that there is indeed some form of DMA (especially
considering the driver works). :)

http://maclinux.plcom.on.ca/cvsweb/linux-mac68k/drivers/net/macsonic.c?rev=1.24

I recall the Apple docs specifically say in regards to the 5200 that both
the Comslot and PDS can bus-master for the sake of DMA (or other nasty
bus-mastering deeds), and the PDS can also use the slot $E shared memory
region and interrupt.

I'm pretty sure the ESP does DMA too if you ask it nicely enough, though
the Mac68k code (which, iirc, sucks royally) just uses the standard mode
access.

However, that's all just driver issues to be dealt with *after* I get the
machine booting and the interrupts working. :)


>> I think seperating based on how the interrupts are handled is a good idea.
>> The Video, DMA bits and IDE are just a matter of different drivers, not
>> really worth splitting the machine class on it's own.
>
>Maybe.  You're still dividing it the same way, though.  There are three
>primary setups:
>
>PDM       Has master ICR/IFR
>PowerBook similar to PDM with DMA stripped, IDE added, some other changes
>Performa  Not similar to anything -- no master ICR, etc.  Interrupt
>          regs do not match more recent machines.
>Legacy    similar to Performa, with different secondary interrupt control
>          hardware at different locations, I think.

The interrupt structure up to the point of the 68k bus should (in theory,
atleast) be almost identical across the Performas and Legacy machines,
atleast as much as the 68k machines they're based on.


>> >Note that the last two are not quite working yet.  We were close on the
>> >performas, and the 68k PowerMacs aren't quite as close, but at least some
>> >of them start booting now with the right config.
>>
>> I'm curious why you separated the Performa's from the PPC upgraded 68k's.
>
>We have to do some weird twiddling to make the ppc-upgraded 68k's get past
>the booter.  That and I don't think the ppc<- ->68k bus bridge is the same
>in the two machines, though I'm not sure about that.  The most annoying
>thing is that the 68k machines had no main interrupt controller, and I
>think some of the interrupt hardware is in different places on the
>Performas, which makes it obnoxious.

I'm not really familiar with how the 68k autovector interrupts are
presented to the PPC, so I wouldn't be able to comment on that.

Speaking of which, is there any documentation on the subject? (code,
commented code, dead trees, whatever)


>It's workable to keep them together,
>and I seriously considered it before deciding to go with a separate class.
>I think there may have been other reasons, but I can't remember what.

I'm inclined to keep them together, though it's not like I have a PPC
upgraded legacy machine laying around here for me to write support for.
(donations welcome) :)


>> >From what I understand, the logical layout of the hardware is very similar
>> (PPC chip bridged onto the 68k bus), and Linux/Mac68k has no troubles
>> supporting all 68k machines under one machine class. Are there differences
>> in the way the PPC->68k bridging is done?
>
>I _think_ it's a different bridge chip, but I haven't actually dismantled
>a PPC upgrade card to find out for sure.  :-)

I know the 5200 uses the Capella chip, but I haven't been able to find any
documentation whatsoever about the PPC upgrade cards.

I would be surprised if Apple did bother to make 2 different 68k <-> PPC
bridge chips, as in both cases they perform the exact same function. But
then, Apple does do that sort of thing.


Cheers - Tony :)


--
Tony Mantler         Renaissance Nerd Extraordinaire         eek@escape.ca
Winnipeg, Manitoba, Canada                       http://www.escape.ca/~eek


[[ 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: Performa 5200

[Benjamin Herrenschmidt]

On Thu, Aug 26, 1999, Tony Mantler <eek@escape.ca> wrote:

>I know the 5200 uses the Capella chip, but I haven't been able to find any
>documentation whatsoever about the PPC upgrade cards.
>
>I would be surprised if Apple did bother to make 2 different 68k <-> PPC
>bridge chips, as in both cases they perform the exact same function. But
>then, Apple does do that sort of thing.

I think those PPC upgrade card were actually made by Daystar (but maybe
using Apple chips. In those old days, Apple and Daystar used to work very
closely).

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

Re: Performa 5200

[David A. Gatwood]

On Thu, 26 Aug 1999, Tony Mantler wrote:

> Speaking of which, is there any documentation on the subject? (code,
> commented code, dead trees, whatever)

At the moment, the only thing I'm aware of is the MkLinux code.  I'm not
sure how far that goes, since it only makes it out of the booter on about
half the machines.


David


[[ 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: Performa 5200

[Benjamin Herrenschmidt]

On Wed, Aug 25, 1999, Tony Mantler <eek@escape.ca> wrote:

>I know the '040 maintains consistiency during the operation of alternate
>bus masters by snooping and spiking the bus according to what's in the
>cache. I haven't read up on how the PPC does it, but I would have expected
>it to be made code-level compatible with what the 040 does, atleast in
>these early PMacs.

I didn't check but someone (I think Paul) told me that snooping was not
done accross the PPC<->68k bus bridge used by those machines.

Note that I'm working on another cache-incoherent platform, and I'm
struggling with similar issues, I beleive we should manage to
"officialise" some vmalloc_uncached functions in the kernel for
cache-incoherent platforms (and define a standard way to tell a driver
it's running on a non-coherent machines). The current macros in io.h are
definitely not enough.
>
>Or something like that.
>
>Penguin collects a pile of LM globals and passes them in the bi struct, but
>most of those can be implied from the gestalt machine ID. Considering the
>number of NuBus PMacs, I don't think it would be terribly difficult to
>guess anything that's not passed in explicitly.

I think that's what MkLinux does.

>But, I shan't pay any note of it 'till *after* I get a kernel to boot. :)

Yep, of course ;-)


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

Re: Performa 5200

[David A. Gatwood]

On Wed, 25 Aug 1999, Benjamin Herrenschmidt wrote:

> all the x100 machines have address maps that depends on the population of
> the RAM slots. Also, some of them have a DRAM-based frame buffer working
> at a fixed physical address which can be either 0 or 1Mb.
> BootX will load the kernel in the first contiguous region in memory it
> can find, but that means that we have to copy the exception vectors to 0,
> adjust them so they call correctly the kernel routines in the real base
> of the kernel (which will not be 0 on some machines), and we'll have
> virt_to_phys and co be non-constant. I read an interesting suggestion
> some time ago of reserving a register during kernel compile with gcc and
> using this register to store the real base of the kernel. Modules will
> not be compatible, but that's not a real issue for now.
> I don't know how the APUS code works, but I heard it is similar.

Wait a sec.  Don't you have code to remap the video to 1 meg?


David


[[ 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: Performa 5200

[Benjamin Herrenschmidt]

On Wed, Aug 25, 1999, David A. Gatwood <dgatwood@mvista.com> wrote:

>Wait a sec.  Don't you have code to remap the video to 1 meg?

Yep, it's in BootX already (but yet untested).

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

Re: Performa 5200

[Geert Uytterhoeven]

On Wed, 25 Aug 1999, Benjamin Herrenschmidt wrote:
> BootX will load the kernel in the first contiguous region in memory it
> can find, but that means that we have to copy the exception vectors to 0,
> adjust them so they call correctly the kernel routines in the real base
> of the kernel (which will not be 0 on some machines), and we'll have
> virt_to_phys and co be non-constant. I read an interesting suggestion
> some time ago of reserving a register during kernel compile with gcc and
> using this register to store the real base of the kernel. Modules will
> not be compatible, but that's not a real issue for now.
> I don't know how the APUS code works, but I heard it is similar.

The latest APUS patches use a fixup section and code to adjust KERNELBASE after
boot up.

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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Performa 5200

[Hubert Figuiere]

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

> is this a NuBus class machine or a PCI based one ?

5200 is basically, like the 6200, which is a LC 63O with a
PowerPC... :-) This means that Linux Mac68k may be of great help,
and this may lead to a mix of PPC and 68k source trees :-)



Hub

[[ 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: Performa 5200

[Geert Uytterhoeven]

On Wed, 25 Aug 1999, Hubert Figuiere wrote:
> According to Benjamin Herrenschmidt <bh40@calva.net>:
> 
> > is this a NuBus class machine or a PCI based one ?
> 
> 5200 is basically, like the 6200, which is a LC 63O with a
> PowerPC... :-) This means that Linux Mac68k may be of great help,
> and this may lead to a mix of PPC and 68k source trees :-)

Originally the idea was to create machine specific directories for machine
stuff that's shared between architectures (m68k and PPC Amigas and Macs, m68k
and SPARC Suns, `PC' for ia32/PPC/MIPS/AXP/SPARC, ...) in 2.3.x, but due to the
feature freeze announce we won't be able to do that in time...

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. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Performa 5200

[Benjamin Herrenschmidt]

On Thu, Aug 26, 1999, Geert Uytterhoeven
<Geert.Uytterhoeven@cs.kuleuven.ac.be> wrote:


>Originally the idea was to create machine specific directories for machine
>stuff that's shared between architectures (m68k and PPC Amigas and Macs, m68k
>and SPARC Suns, `PC' for ia32/PPC/MIPS/AXP/SPARC, ...) in 2.3.x, but due to
>the
>feature freeze announce we won't be able to do that in time...

But we do have drivers/macintosh already, we can use it or eventually
sub-divide it for ppc-only and m68k-only drivers, keeping common drivers
at the root level. Also, we could re-merge some drivers, like the zilog
driver (especially since it doesn't use DMA, i never finished it) and the
ADB mouse/keyboard stuff.


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

Re: Performa 5200

[David A. Gatwood]

On Tue, 24 Aug 1999, Tony Mantler wrote:

> I recently obtained for myself up a Performa 5200, and I've been playing
> with trying to hack linux into shape on it. (I'm usually a Mac68k guy)
> 
> I compiled a kernel from a stock 2.2.10 tree that I have laying around
> (from ftp.kernel.org, most every config option turned off, booting with
> BootX) and, after sprinkling around a bit of debug code, found that it
> makes it past the prom.c code where it draws the "Welcome to linux
> [blahblah] booting...", but doesn't make it to start_kernel after that.
> 
> I'm not particularily fluent in PPC ASM, so head.S makes fairly opaque
> reading for me. I'm wondering if someone might have some pointers to where
> this would likely be dying, so I have good a place to start?

If I were you, I'd look at MkLinux, _not_ LinuxPPC.  I got about 2/3rds of
the 52/53/62/6300 support already in there.  The interrupt handling code
is written and should be close to correct, along with hard-coded addresses
for serial hardware, video, IDE, SCSI... it's basically 90% finished.
It's the 10% that I can't do anymore, since I no longer have access to the
machines in question.

Some models of machines in that family get a long way into the boot
process, some freeze at the MkLinux Booter's splash screen, and I haven't
have time to try to figure out the difference.  Could be anything from RAM
size to whether it has a 603 vs. 603e.  I'm leaning towards the latter. 
That's probably what's wrong in LinuxPPC's head.S, too, since I don't
think either one has ever supported a machine w/ an original 603.  Grab
yourself a couple of microprocessor reference guides.  :-)

LinuxPPC's interrupt handling code is not well suited to the design of the
interrupt hardware in the NuBus 5x00 machines, since A. it has no master
interrupt flag register or interrupt control register, and B. it has other
interrupt hardware scattered in weird places throughout the hardware.
It woudl be a _very_ massive hack to get it working under LinuxPPC,
especially since even 6/7/8100 support isn't there (which is a necessary
foundation for some of the MkLinux 5x00 changes).  It's also a heck of a
lot easier to start with something that almost works than to start with
somnething that's not remotely close.  ;-)


David


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