Resurrecting mkLinux
Dave Weis
djweis at plconline.com
Wed Apr 7 11:11:59 EST 1999
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 at 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. ]]
More information about the Linuxppc-dev
mailing list