Resurrecting mkLinux

Resurrecting mkLinux

[Roy Wood]

I've got a little time and an old 6100, so I'm giving some thought to 
raiding the mkLinux sources and getting a monolithic version of the 
kernel going (i.e. getting rid of the whole Mach layer).

My plan is to get video working first, then the ADB keyboard, followed by 
SCSI and network support.  Oh-- and maybe serial too, eventually.

Stop me right now if this is a stupid idea, please, but don't forget to 
tell me why it is.  :-)


Anyway, I was hoping some of you people here might be able to offer 
advice or have some useful comments about what I'm considering doing.

Anybody?  Anyone?


-Roy

[[ 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: Resurrecting mkLinux

[David A. Gatwood]

On Tue, 6 Apr 1999, Roy Wood wrote:

> I've got a little time and an old 6100, so I'm giving some thought to 
> raiding the mkLinux sources and getting a monolithic version of the 
> kernel going (i.e. getting rid of the whole Mach layer).
> 
> My plan is to get video working first, then the ADB keyboard, followed by 
> SCSI and network support.  Oh-- and maybe serial too, eventually.
> 
> Stop me right now if this is a stupid idea, please, but don't forget to 
> tell me why it is.  :-)

It's not a stupid idea, but there are a handful of issue sthat would have
to be resolved before drivers come into play.  The biggest one is the
physical RAM.  On the x100 PowerMacs, RAM is not (ever) contiguous.  I
have some info about it in a PDF file somewhere, but not with me.  Anyway,
there's a table you can read to get the addresses of the banks of memory.
That will produce a wrinkle, if I'm reading the LinuxPPC code right, since
it appears to only be willing to handle a single memory region.  Also, the
LinuxPPC booter would have to incorporate the code to read that table, and
pass it in as part of the kernel boot args or whatever.  Further, since
the machines don't have OpenFirmware and there are substantial differences
between them and PCI machines, it would be wise to pass in the machine ID
(gestalt) along with that.  There's no reason to fake an OF tree -- it
would clutter the booter unnecessarily, and in virtually every place where
you'd do an OF check for addresses or interrupts, you'd probably have to
have a switch statement with a PDM case anyway, so there's not much point.

In a related problem, it you're using motherboard video, it claims
motherboard RAM.  Thus, you have to do some additional memory mapping in
that case.  Something to watch out for.

Next issue: interrupts.  Few, if any drivers would be functional without
interrupts.  Unlike on PCI macs, they aren't assigned neat little PCI
interrupt numbers.  The numbers used by MkLinux are arbitrary.  PDM
machines also have two VIA "chips" (they're really part of another chip) 
that are cascaded as part of the interrupt controller (in contrast, I
believe PCI machines only have one).  The way the interrupts are set up is
substantially different from PCI machines, too.  DMA interrupts are all
cascaded into a single interrupt on the VIA, if I remember correctly.
Thus, once you've detected a DMA interrupt, you have to check a series of
locations to see if a DMA interrupt occurred for each device that you have
DMA code for.  The Mach kernel's interrupt handling code should be a good
model.

Surprisingly, the original PDF file about the hardware virtually contained
enough information to write the interrupt handler....  Addresses amd
everything.  Sadly, it doesn't give DMA addresses.  YOu'll just have to
rip those from MkLinux.  BTW, the floppy addresses aren't all correct yet.
Just a word of warning.  Still working on it.  :-)

But really, before either of those, you should work up the serial driver.
Be sure to set it up to allow use in polling mode so that it can be used
for debugging before interrupts are enabled.  

Last, you'll need a compile option to use one of two macros for eieio(),
sync(), and isync().  There are certain common cards used in a large
percentage of PowerMac x100's that will do some sort of illegal access at
the address stored in some register (I forget the details) if you use
those without clearing the register first, so... well, it's in one of the
header files in the POWERMAC directory.

Beyond that, it's mostly a matter of hard-coding addresses into drivers,
putting if then else statements around all of the DBDMA stuff, writing
appropriate AMIC DMA code (MkLinux, again, should be a good model), and
writing additional drivers for video and audio (AWACS support is
apparently substantially different on PDM's, as it's a separate driver
under MkLinux).  All of the other hardware already has drivers (SCSI, ADB,
serial) that will just need some modifications (DMA, addresses, possibly
differences in the register maps).

Oh yeah.  The Swim III used for floppies has different register spacing on
PDMs.  I would expect other chips to have something similar.  MkLinux gets
around this by having a structure containing pointers to the registers,
and filling them by adding the base address to the offset from one of two
static structures. according to the machine class.  Thanks to the Copland
team for the idea -- the structures and the idea were in the headers, just
not implemented.... :-)  Anyway, it's something to watch out for.


Later,
David

David A. Gatwood                         Visit globegate's internet
dgatwood@globegate.utm.edu                  talker, Deep Space 36
http://globegate.utm.edu                telnet globegate.utm.edu:9624


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

Re: Resurrecting mkLinux

[Dave Weis]

We got around a lot of this in the linux-ma68k port. I think these series
of powermacs are pretty similar to the top-of-the-line 68k's. I've put
more comments below.

> It's not a stupid idea, but there are a handful of issue sthat would have
> to be resolved before drivers come into play.  The biggest one is the
> physical RAM.  On the x100 PowerMacs, RAM is not (ever) contiguous.  I
> have some info about it in a PDF file somewhere, but not with me.  Anyway,
> there's a table you can read to get the addresses of the banks of memory.
> That will produce a wrinkle, if I'm reading the LinuxPPC code right, since
> it appears to only be willing to handle a single memory region.  Also, the
> LinuxPPC booter would have to incorporate the code to read that table, and
> pass it in as part of the kernel boot args or whatever.  Further, since
> the machines don't have OpenFirmware and there are substantial differences
> between them and PCI machines, it would be wise to pass in the machine ID
> (gestalt) along with that.  There's no reason to fake an OF tree -- it
> would clutter the booter unnecessarily, and in virtually every place where
> you'd do an OF check for addresses or interrupts, you'd probably have to
> have a switch statement with a PDM case anyway, so there's not much point.

We passed along a structure that contained addresses of ram chunks to be
mapped.

> In a related problem, it you're using motherboard video, it claims
> motherboard RAM.  Thus, you have to do some additional memory mapping in
> that case.  Something to watch out for.

Used the macos routines to find the beginning of video memory and passed
that along too.

> Next issue: interrupts.  Few, if any drivers would be functional without
> interrupts.  Unlike on PCI macs, they aren't assigned neat little PCI
> interrupt numbers.  The numbers used by MkLinux are arbitrary.  PDM
> machines also have two VIA "chips" (they're really part of another chip) 
> that are cascaded as part of the interrupt controller (in contrast, I
> believe PCI machines only have one).  The way the interrupts are set up is
> substantially different from PCI machines, too.  DMA interrupts are all
> cascaded into a single interrupt on the VIA, if I remember correctly.
> Thus, once you've detected a DMA interrupt, you have to check a series of
> locations to see if a DMA interrupt occurred for each device that you have
> DMA code for.  The Mach kernel's interrupt handling code should be a good
> model.

That took a while to get running. We didn't get dma running on the few
machines that supported it either (AV's).

> Beyond that, it's mostly a matter of hard-coding addresses into drivers,
> putting if then else statements around all of the DBDMA stuff, writing
> appropriate AMIC DMA code (MkLinux, again, should be a good model), and
> writing additional drivers for video and audio (AWACS support is
> apparently substantially different on PDM's, as it's a separate driver
> under MkLinux).  All of the other hardware already has drivers (SCSI, ADB,
> serial) that will just need some modifications (DMA, addresses, possibly
> differences in the register maps).

Between the 68k and ppc scsi drivers, there should be enough info. I did
most of the 68k one and used info from the macbsd driver.


djweis

-- 
David Weis                | 10520 New York Ave, Des Moines, IA 50322
djweis@plconline.com      | Voice 515-278-0133 Ext 231
http://www.plconline.com/ | "Great spirits will always encounter violent
                          | opposition from mediocre minds" - Einstein


[[ 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: Resurrecting mkLinux

[David A. Gatwood]

On Tue, 6 Apr 1999, Dave Weis wrote:

> We got around a lot of this in the linux-ma68k port. I think these series
> of powermacs are pretty similar to the top-of-the-line 68k's. I've put
> more comments below.

They're remarkably like the AV Quadras, yes, though I belive the DMA
hardware is different.  They may also have a slightly different SCSI chip,
though I'm fuzzy on that.  They're similar enough, though, that it's
probably no big deal.  And don't the Quadras use a SWIM II for floppy? 
The 5200, which was based on one of the 040/LC040 designs, uses a SWIM II,
which is why I was asking.  Anyway, floppy support isn't quite as critical
as memory mapping or interrupt handling....  ;-)


> > In a related problem, it you're using motherboard video, it claims
> > motherboard RAM.  Thus, you have to do some additional memory mapping in
> > that case.  Something to watch out for.
> 
> Used the macos routines to find the beginning of video memory and passed
> that along too.

No problem there.  That's how we do it under MkLinux, too.  Be careful,
though, as you need to use that address to detect whether it's using the
motherboard video or an AV or HPV card.  MkLinux does the motherboard RAM
with a BAT.  I'm not sure if that's essential, but unlike memory up in the
pre-mapped normal i/o space like you'd find with a card, you can't just
ignore the fact that it starts near 0, I believe....  I'm very, very fuzzy
on that aspect of things, still.


> > Next issue: interrupts.  Few, if any drivers would be functional without
> > interrupts.  Unlike on PCI macs, they aren't assigned neat little PCI
> > interrupt numbers.  The numbers used by MkLinux are arbitrary.  PDM
> > machines also have two VIA "chips" (they're really part of another chip) 
> > that are cascaded as part of the interrupt controller (in contrast, I
> > believe PCI machines only have one).  The way the interrupts are set up is
> > substantially different from PCI machines, too.  DMA interrupts are all
> > cascaded into a single interrupt on the VIA, if I remember correctly.
> > Thus, once you've detected a DMA interrupt, you have to check a series of
> > locations to see if a DMA interrupt occurred for each device that you have
> > DMA code for.  The Mach kernel's interrupt handling code should be a good
> > model.
> 
> That took a while to get running. We didn't get dma running on the few
> machines that supported it either (AV's).

I don't know much about the Quadra AV DMA engine, except that I don't
think it's the same one used in the PowerMacs.  Anyway, about the PowerMac
PDM DMA, there's a lot of information available in various docs, but there
are still some details that can only be obtained (legally) from MkLinux's
source.  If anyone wants a copy of these two PDF files with a bunch of
AMIC info and VIA register info and stuff, let me know, but really, the
MkLinux source says it more readably (and accurately)....  :-)


> > Beyond that, it's mostly a matter of hard-coding addresses into drivers,
> > putting if then else statements around all of the DBDMA stuff, writing
> > appropriate AMIC DMA code (MkLinux, again, should be a good model), and
> > writing additional drivers for video and audio (AWACS support is
> > apparently substantially different on PDM's, as it's a separate driver
> > under MkLinux).  All of the other hardware already has drivers (SCSI, ADB,
> > serial) that will just need some modifications (DMA, addresses, possibly
> > differences in the register maps).
> 
> Between the 68k and ppc scsi drivers, there should be enough info. I did
> most of the 68k one and used info from the macbsd driver.

Sure.  Either one would probably be compatible, simply by adjusting the
base address (and DMA address, if you use DMA).  The x100's use a 53C96
SCSI chip, just like the external bus on most PCI PowerMacs.  Note,
however, that the 8100 has two SCSI busses: the standard 53C96 for
external SCSI (a superset of the 53C94 which IIRC was used in the AV
Quadras), and a 53FC96 (or is it CF?) fast SCSI for its internal bus. 
Again, all of the details can be found in the MkLinux driver or in Apple's
technical specs PDF file (I forget what Apple site I dl'ed that from, but
I can't seem to find it anymore... dunno).  A word of warning: the Apple
PDF file appears to contain numerous errors in the VIA register diagram,
especially where SCSI is concerned. Specifically, on one of the registers,
the bits were nearly all marked SCSI B, where some were obviously SCSI A.
I'd strongly advise using working source (Mach Kernel) as a reference,
because...  well, it's working.  ;-)


Later,
David

p.s. globegate: 119 days uptime under MkLinux.  ;-)

David A. Gatwood                         Visit globegate's internet
dgatwood@globegate.utm.edu                  talker, Deep Space 36
http://globegate.utm.edu                telnet globegate.utm.edu:9624


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

Re: Resurrecting mkLinux

[a sun]

   We got around a lot of this in the linux-ma68k port. I think these
   series of powermacs are pretty similar to the top-of-the-line
   68k's. I've put more comments below.

benh and i have been talking about this off and on. both of our
schedules have been pretty busy though. anyways, here's the scoop on
what's been happening:
  1) bootx needs to be modified to boot on nubus powermacs and pass in
     chunks of memory (ala the m68k booter) either because memory is
     discontiguous or video memory is sitting at 1MB. 

  2) the APUS code needs modifications to allow use by the
     powermac. in case you don't already know, the APUS platform is
     basically an m68k platform with a PPC card in it. sound familiar?
     as a result, things just need to be generalized a bit for
     powermacs. for example, i already have some of the interrupt
     glue. 

     so, most of the work essentially ends up being changes to the
     m68k code base to add in "newer" models. in addition, the mm code
     needs to be a little less restrictive. it already handles memory
     chunks, but the apus code doesn't use it that way.

once a working boot loader is done, it actually shouldn't be too
difficult to get things working. the hairiest part will probably be
the tweaking that head.S needs. however, the apus code actually
fiddles with the exception table and copies its virttophys constant
into a specific memory location. i think we should be able to do
something similar with the nubus powermac code as well to deal with
memory holes if need be.

beyond that, using the m68k drivers should pretty much work as the
apus stuff needs to do that anyway. from my look at the code, we
should be able to replace CONFIG_APUS with a CONFIG_M68KPPC.

anyways, feel free to dive in if you have time. i've been using the
absence of a working boot loader as an excuse not to do much with
it. just create a mach_m68k directory in arch/ppc, stick the amiga
directory in there, create a mac subdirectory and maybe a common
directory, and merge away. the more files that end up being links to a
slightly modified m68k code base the better.

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

Re: Resurrecting mkLinux

[Jesper Skov]

>> once a working boot loader is done, it actually shouldn't be too
>> difficult to get things working. the hairiest part will probably be
>> the tweaking that head.S needs. however, the apus code actually
>> fiddles with the exception table and copies its virttophys constant
>> into a specific memory location. i think we should be able to do
>> something similar with the nubus powermac code as well to deal with
>> memory holes if need be.

I decided to skip support for multiple memory segments on APUS since
memory other than the one on the main board is horrendously slow
(comparatively).  People use the Amiga Zorro device which allows other
memory segments to be used as a swap device.

>> beyond that, using the m68k drivers should pretty much work as the
>> apus stuff needs to do that anyway. from my look at the code, we
>> should be able to replace CONFIG_APUS with a CONFIG_M68KPPC.

Sounds good to me.

>> anyways, feel free to dive in if you have time. i've been using the
>> absence of a working boot loader as an excuse not to do much with
>> it. just create a mach_m68k directory in arch/ppc, stick the amiga
>> directory in there, create a mac subdirectory and maybe a common
>> directory, and merge away. the more files that end up being links
>> to a slightly modified m68k code base the better.

I am waiting for 2.3.x to be unleashed so I can start working
again. 

My top priority is to get away from having an Amiga directory under
arch/ppc (or arch/ppc/mach_m68k). I would prefer to move all mach
drivers into a new mach hierarchy (so there would be e.g. mach/amiga
in the root of the kernel sources just as we now have arch/m68k).

The main motivation is obviously to avoid maintaining two different
sets of sources that do the same thing. Most of the ppc/amiga sources
are just 

 #include "../../m68k/amiga/foobar.c"

which works OK, but is a bit daft. 

Also, the files that do not look like that are so because Jes (m68k
maintainer) didn't like '#ifdef __powerpc__' or CONFIG_APUS in
arch/m68k specific files... Which I agree with (kind of). With the
mach hierarchy, though, both arguments becomes moot and I'll fix up
the sources to my liking ;)

Jesper

[[ 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: Resurrecting mkLinux

[Benjamin Herrenschmidt]

On Wed, Apr 7, 1999, Jesper Skov <jskov@cygnus.co.uk> wrote:

>My top priority is to get away from having an Amiga directory under
>arch/ppc (or arch/ppc/mach_m68k). I would prefer to move all mach
>drivers into a new mach hierarchy (so there would be e.g. mach/amiga
>in the root of the kernel sources just as we now have arch/m68k).
>
>The main motivation is obviously to avoid maintaining two different
>sets of sources that do the same thing. Most of the ppc/amiga sources
>are just 

Sounds good. The changes I'm making to the ADB code shoud fit nicely in
this too. I beleive I could merge ADB of mac 68k and PPC implementations
quite easily.

Question: Who is using drivers/char/adbmouse.c ? I know linux-pmac does,
of course, but could someone tell me what are the other archs/machines
using this specific file. I would like to make changes to it (I tried to
avoid them as much as possible until now) so I'll need to fix other archs too.

Basically, adb.c core should be shared by all implentations, mac_keyb.c
and it's specific mouse handlers too since those devices can be
potentially plugged in any ADB machine (but defaults keymaps will
probably be different). adbmouse as a bus-mouse compatibility driver
should not depend on any implementation neither, I still need to cleanup
things in this regard, but we won't get rid of the global-based "hook" if
we want it to still be a module. I will probably put the definition of
the global itself in adb.c core, eventually encapsulated within a structure.

I'm also thinking about letting userland install an auto-poll handler
thru the /dev/adb device. This would allow to write userland drivers for
non-mouse things (a tablet GIMP plugin for example) more easily. One
could "override" the default mouse_input/kbd_input handler by the
userland one, possibly inside a given vt (but the vt switch should
probably be handled by the userland code itself, I need some clues about
this).
This would also be useful for the mac-on-linux emulator, to grab directly
the ADB flow and pass it "as-is" to the emulator, lowering the overhead
when moving the mouse and allowing support of special devices vith MacOS
drivers inside the emulator.

So if you have anything in mind about ADB, please tell me now. I sent a
first set of patches last week to Cort and i still plan to add more
things in the upcoming one or two weeks and then I'll stabilize it and
submit the changes to Cort.


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

Re: Resurrecting mkLinux

[Geert Uytterhoeven]

On Wed, 7 Apr 1999, Benjamin Herrenschmidt wrote:
> On Wed, Apr 7, 1999, Jesper Skov <jskov@cygnus.co.uk> wrote:
> 
> >My top priority is to get away from having an Amiga directory under
> >arch/ppc (or arch/ppc/mach_m68k). I would prefer to move all mach
> >drivers into a new mach hierarchy (so there would be e.g. mach/amiga
> >in the root of the kernel sources just as we now have arch/m68k).

Hence we need

    mach/amiga (m68k and PPC)
    mach/mac (m68k and PPC)
    mach/sun (SPARC and SPARC64)
    mach/pc (all legacy stuff)
    ...

> >The main motivation is obviously to avoid maintaining two different
> >sets of sources that do the same thing. Most of the ppc/amiga sources
> >are just 
> 
> Sounds good. The changes I'm making to the ADB code shoud fit nicely in
> this too. I beleive I could merge ADB of mac 68k and PPC implementations
> quite easily.
>
> Question: Who is using drivers/char/adbmouse.c ? I know linux-pmac does,
> of course, but could someone tell me what are the other archs/machines
> using this specific file. I would like to make changes to it (I tried to
> avoid them as much as possible until now) so I'll need to fix other archs too.

PowerMac, CHRP and Mac.

> Basically, adb.c core should be shared by all implentations, mac_keyb.c
> and it's specific mouse handlers too since those devices can be
> potentially plugged in any ADB machine (but defaults keymaps will
> probably be different). adbmouse as a bus-mouse compatibility driver
> should not depend on any implementation neither, I still need to cleanup
> things in this regard, but we won't get rid of the global-based "hook" if
> we want it to still be a module. I will probably put the definition of
> the global itself in adb.c core, eventually encapsulated within a structure.

Hence we need

    drivers/adb
    drivers/usb
    ...
    bus/pci
    bus/zorro
    bus/isa
    bus/dio
    bus/nubus
    bus/sbus
    bus/mbus
    bus/eisa
    bus/mca
    ...

Lot's of clean ups for 2.3.x ;-)

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: Resurrecting mkLinux

[a sun]

   My top priority is to get away from having an Amiga directory under
   arch/ppc (or arch/ppc/mach_m68k). I would prefer to move all mach
   drivers into a new mach hierarchy (so there would be e.g. mach/amiga
   in the root of the kernel sources just as we now have arch/m68k).

yep. actually, we probably should call it "machine" as that has less
of a chance of getting confused with the mach microkernel given that
arch/mach has the possibility to show up in 2.3.x as well.

   Also, the files that do not look like that are so because Jes (m68k
   maintainer) didn't like '#ifdef __powerpc__' or CONFIG_APUS in
   arch/m68k specific files... Which I agree with (kind of). With the
   mach hierarchy, though, both arguments becomes moot and I'll fix up
   the sources to my liking ;)

heh. luckily, most of the nubus stuff can be done by adding more
gestalt values. hmm, i do have wonderful things like #ifdef
__powerpc__ in the via_write/via_read code to do deal with memory
barriers and such.

-a

[[ 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: Resurrecting mkLinux

[David A. Gatwood]

On Wed, 7 Apr 1999, a sun wrote:

>    Also, the files that do not look like that are so because Jes (m68k
>    maintainer) didn't like '#ifdef __powerpc__' or CONFIG_APUS in
>    arch/m68k specific files... Which I agree with (kind of). With the
>    mach hierarchy, though, both arguments becomes moot and I'll fix up
>    the sources to my liking ;)
> 
> heh. luckily, most of the nubus stuff can be done by adding more
> gestalt values. hmm, i do have wonderful things like #ifdef
> __powerpc__ in the via_write/via_read code to do deal with memory
> barriers and such.

On a related point, I'm assuming that NuBus support will eventually be
expended to include the nubus PowerBooks and eventually, the 52/62/53/
63xx powermac/performa machines.  If not, then you really wouldn't have to
have the gestalt value.  But it's probably better to go ahead and put that
in, rather than having to mess with it later.  :-)

Also, a correction: the NuBus machines have a 53C94 and 53CF94, not 53C96
and 53CF96 as I reported previously.  I'm not sure why I thought they used
96es.  Oops.  :-)


Later,
David

David A. Gatwood                         Visit globegate's internet
dgatwood@globegate.utm.edu                  talker, Deep Space 36
http://globegate.utm.edu                telnet globegate.utm.edu:9624


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

Re: Resurrecting mkLinux

[Geert Uytterhoeven]

On Tue, 6 Apr 1999, Dave Weis wrote:
> We got around a lot of this in the linux-ma68k port. I think these series
> of powermacs are pretty similar to the top-of-the-line 68k's. I've put
> more comments below.
> 
> > It's not a stupid idea, but there are a handful of issue sthat would have
> > to be resolved before drivers come into play.  The biggest one is the
> > physical RAM.  On the x100 PowerMacs, RAM is not (ever) contiguous.  I
> > have some info about it in a PDF file somewhere, but not with me.  Anyway,
> > there's a table you can read to get the addresses of the banks of memory.
> > That will produce a wrinkle, if I'm reading the LinuxPPC code right, since
> > it appears to only be willing to handle a single memory region.  Also, the
> > LinuxPPC booter would have to incorporate the code to read that table, and
> > pass it in as part of the kernel boot args or whatever.  Further, since
> > the machines don't have OpenFirmware and there are substantial differences
> > between them and PCI machines, it would be wise to pass in the machine ID
> > (gestalt) along with that.  There's no reason to fake an OF tree -- it
> > would clutter the booter unnecessarily, and in virtually every place where
> > you'd do an OF check for addresses or interrupts, you'd probably have to
> > have a switch statement with a PDM case anyway, so there's not much point.
> 
> We passed along a structure that contained addresses of ram chunks to be
> mapped.

I'm not 100% sure, but I expect Linux/PPC on APUS to handle non-contiguous
memory. APUS is just a PPC expansion for Amigas.

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: Resurrecting mkLinux

[Gary Thomas]

On 06-Apr-99 Roy Wood wrote:
> 
> I've got a little time and an old 6100, so I'm giving some thought to 
> raiding the mkLinux sources and getting a monolithic version of the 
> kernel going (i.e. getting rid of the whole Mach layer).
> 
> My plan is to get video working first, then the ADB keyboard, followed by 
> SCSI and network support.  Oh-- and maybe serial too, eventually.
> 
> Stop me right now if this is a stupid idea, please, but don't forget to 
> tell me why it is.  :-)
> 
> 
> Anyway, I was hoping some of you people here might be able to offer 
> advice or have some useful comments about what I'm considering doing.
> 
> Anybody?  Anyone?
> 

Your biggest problems will be:
  * Booting - perhaps BootX can be made to help here
  * Lack of Open Firmware - used to "size up" the hardware
  * 601 support - biggest worries are actually the in the hardest
    to debug - boot time and machine initialization.

Other than that, it should work.  Of course, I'm not saying it is
easy or else I would have done it myself long ago...

[[ 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: Resurrecting mkLinux

[Hubert Figuiere]

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

> Your biggest problems will be:
[...]
>   * 601 support - biggest worries are actually the in the hardest
>     to debug - boot time and machine initialization.

601 support is already in  since LinuxPPC works on 7200, 7500 and 8200
which are 601 powered (and non expandable for all but the 7500).



Hub
-- 
Allianceware: see Coopetition
Coopetition: see Allianceware

[[ 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: Resurrecting mkLinux

[Benjamin Herrenschmidt]

On Wed, Apr 7, 1999, a sun <asun@saul9.u.washington.edu> wrote:

>once a working boot loader is done, it actually shouldn't be too
>difficult to get things working. the hairiest part will probably be
>the tweaking that head.S needs. however, the apus code actually
>fiddles with the exception table and copies its virttophys constant
>into a specific memory location. i think we should be able to do
>something similar with the nubus powermac code as well to deal with
>memory holes if need be.

I think I'll finally have to dive into this now ;-)

So basically, I'll keep BootX behaviour similar, but the device-tree
pointer in the boot-infos will be 0, and I'll add a couple of fields
(machine ID and memory ranges extracted from MacOS nanokernel). I'll make
sure the internal video is located at 1MB phys instead of 0.

Just a question: Where should I place the kernel ? Current BootX copies
the kernel pages at 0 (physical). Should I do the same with a hole in the
kernel, should I do the same without a hole (overriding video memory: the
screen will display garbage during boot), or should I put the kernel in
the first large enough physically contiguous piece of memory I find and
let it relocate itself ?

BootX can do any kind of relocation quite easily before entering the
kernel, the little "bootstrap" that I run when switching to supervisor
and before entering the kernel will, after disabling the MMU, execute a
list of page copy operations, this list is pre-built by BootX, and so can
easily be adapted to make the necessary hole.

What is the APUS bootloader doing ? (Will it load the kernel at a fixed
address ?)

For those who didn't follow earlier discussions, there are actually two
problems with the memory mappings:

 - The on-board video uses the in-RAM framebuffer at either 0 or 1Mb
(physical). I know how to change it from 0 to 1Mb if MacOS sets it to 0.

 - The memory banks are generally not physically contiguous. Depending on
the motherboard and the organisation and population of the SIMM slots
(each SIMM bank resides at a fixed address, and I think on-board soldered
RAM lives at 0).

I'm working on BootX now (still those problems with boards still doing
DMA while the kernel is beeing copied), I'll try to find some time to put
some basic code for NuBus this week. Stay tuned.

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

Re: Resurrecting mkLinux

[a sun]

   Just a question: Where should I place the kernel ? Current BootX copies
   the kernel pages at 0 (physical). Should I do the same with a hole in the
   kernel, should I do the same without a hole (overriding video memory: the
   screen will display garbage during boot), or should I put the kernel in
   the first large enough physically contiguous piece of memory I find and
   let it relocate itself ?

hmm. i think we're going to have to know about relocations anyway and
where the start of the kernel really is. so, i would go for the last
option. the first option would essentially duplicate some of the code
that's in head.S already. we still need the kernel start address
though. assuming that there are enough registers lying around, we
could always do a -ffixed-# and store it there to make things
easier. the apus code would benefit from that as well. if not, we can
do the apus thing and choose a memory location.

so, how about just sticking the kernel somewhere contiguous and
passing in the start of the kernel as part of the boot info struct?
that way, the decision on how to handle things can be left to head.S.

back to the question of registers, how do people feel about allocating
a fixed register in the kernel for the nubus powermacs and apus
machines to store the phystovirt mapping? having things in a register
would simplify things a bit.
  

-a
although, the second option would be humourous.




[[ 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: Resurrecting mkLinux

[Jesper Skov]

[Thanks for forwarding it to me, Geert]

Benjamin> What is the APUS bootloader doing ? (Will it load the kernel
Benjamin> at a fixed address ?)

The problem on APUS systems is that the start address of physical
memory is unknown. So after bootup, when the address has been
determined, I patch all the virt<->phys constants used throughout the
kernel.

The memory on an APUS system is contiguous though, so the fix used on
APUS may not be enough for you.


My code is not in the vger tree yet. If you want to have a look at it,
get a diff from ftp://sunsite.auc.dk/local/os/linux/apus/kernels (or
thereabouts).

Jesper

[[ 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: Resurrecting mkLinux

[Ben Martz]

>On 06-Apr-99 Roy Wood wrote:
>>
>> I've got a little time and an old 6100, so I'm giving some thought to
>> raiding the mkLinux sources and getting a monolithic version of the
>> kernel going (i.e. getting rid of the whole Mach layer).
>>
...
>>
>> Anyway, I was hoping some of you people here might be able to offer
>> advice or have some useful comments about what I'm considering doing.
>>
>> Anybody?  Anyone?
>>
>
>Your biggest problems will be:
>  * Booting - perhaps BootX can be made to help here
>  * Lack of Open Firmware - used to "size up" the hardware
>  * 601 support - biggest worries are actually the in the hardest
>    to debug - boot time and machine initialization.
>
>Other than that, it should work.  Of course, I'm not saying it is
>easy or else I would have done it myself long ago...

Roy,

I have some very old booting code from the defunct PowerOS project that
works just fine on x100 machines. (It was the second public use of the Gary
mode hack that I am aware of, after MkLinux) I also have some more recent
work based on BootX that you may find useful.

http://home.earthlink.net/~benmartz/poweros/

Oh, in case anyone is wondering, you won't find any of the kernel code up
there because I am still working on it =) It's just a little project that I
am doing for my own enjoyment to stretch my mind a little.


----
Ben Martz - benmartz@earthlink.net



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