IBM PowerPC "Carolina" systems

This page contains some information and patches for running Linux on IBM PowerPC machines based on the "Carolina" motherboard. This includes Personal Computer Power Series 850/830 machines (model 6070 and 6050 desktops) , and the 7248 series 43P machines (not the later 7043 series). It also includes a little information on the Power Series 850 Thinkpad

The original of this page is at http://www.amberdata.demon.co.uk/carolina/. There is also a mirror at http://www.abcompcons.com/carolina/.

Dislaimers

• The standard disclaimers apply to anything you find on this page - if your machine breaks because of something here, it isn't my fault.
• All trademarks are owned by their respective owners.

What is it?

The "Carolina" motherboard is the basis for some of the older desktop PowerPC systems made by IBM. It was used in the Personal Computer Power Series 830 and 850 machines, which were probably meant to run Windows NT. These machines have IBM type numbers 6050 and 6070. It also appears in the early RS/6000 43P machines with type number 7248, which would have been sold to run AIX. (Almost all IBM machines have a 4 digit type number - generally those starting with "6" seem to indicate desktop PCs, and those with "7" indicate RS/6000 machines of some sort).

It is a fairly normal PReP-compliant PCI/ISA system board with the slots on a riser card. All the systems I've seen have PowerPC 604 chips running from 100 to 133MHz, although I believe earlier systems may have used the 601 chip instead. It includes the usual 2 IDE channels, floppy, parallel and 2 serial ports. It also has a built-in AMD 79C970A PCnet/PCI II ethernet, an S3 Vision 864 video controller with an S3 SDAC and 2M of video ram (an "E15" in AIX parlance), a Crystal CS4232 audio controller, and the boards built for the 7248 boxes have an NCR 53c810 SCSI host adapter as well. (This components for this were simply left off boards for the 6050/6070 - if you look at a 6070 board, just in front and to the left of the riser card slot you will see space for two missing chips (the larger one is the ncr53c810) and along the right hand edge of the riser slot is a missing 50 pin ribbon connector with "SCSI" printed next to it on the silkscreen).

Common extra cards in the machines include the "S15" graphics adapter (actually a Diamond Viper Pro minus the bios chip, which was based on the Weitek Power 9100/9130 chipset with an IBM RGB525 ramdac), the GXT150P graphics adaptor (all-IBM card, I think with 3D support), a PCI scsi host adapter card with an NCR 53c825 chip, and various random token ring and ethernet cards (usually ISA).

What works under Linux

There are a few issues with these machines under Linux. In particular, vanilla 2.2 kernels will probably fail to boot sucessfully at all. You will probably need a modified kernel, which you can create using the patches below. These are against 2.2.15+ kernels. I do not recommend trying to use anything earlier. 2.4 kernels currently almost work if you apply the patch below but there are probably still a few oddnesses to remove yet.

More details:

• the first hurdle is that the kernel miscalculates the hardware timer frequency badly, which means that almost any operation with a timeout fails instantly - eg probing the keyboard, SCSI, IDE, just about anything. The patches below fix this one. This actually seems to be related to the general problems with the i8259 interrupt controllers; with some versions of the patches to fix these problems the kernel actually gets the frequency right.
• The second problem is that there is a hardwired PCI interrupt to IRQ mapping table in the kernel which happens to be incorrect. This means that if you have a card in the PCI slots it will probably get incorrectly mapped to IRQ 10 instead of IRQ 15, which generally causes the kernel to get upset (certainly true for SCSI cards). This issue is also addressed by the patches below.
• Your IDE drives don't have the geometry you think they do. This will only be a problem if you want to boot off them. If you do, you will want to pass the kernel a parameter of the form "hdx=c,64,32", where "x" is the drive letter (usually a) and "c" is the number of cylinders your drive should have. To calculate these you will probably need to boot the system without this parameter, look at the values the kernel gets from the drive for cylinders, heads, and sectors-per-track, and then divide cylinders*heads*sectors by 2048 to get "c". To boot off the drive you will probably want to find the "ARC" floppy which came with the machine and tell it to prepare the boot partition for you - PReP machines boot by looking for a little-endian MS-DOS style primary partition with type 0x41. It should be possible to create this partition yourself, but make sure you put it at the beginning of the disk, and keep it pretty small (under say 8M). When you actually want to install a kernel on this disk, do "dd if=mykernelzImage of=/dev/hda1" (assuming your PReP boot partition is hda1).
• Your IDE drives may or may not be byteswapped. If you want to (un?)-byteswap a drive for some reason (like you wrote it with a kernel prior to about 2.2.12) then pass the kernel the argument "hdx=swapdata".

What doesn't work under Linux

With standard 2.2 or a recent 2.4 snapshot and the patches below, pretty much all the basic hardware should work fine. Things that don't are the better graphics adapters, and token ring cards. The SCSI host adapter appears to work fine.

PCI adapters other than those which were sold as options by IBM generally won't work at all with 2.2. This is because the firmware only appears to initialize cards it recognizes, leaving the ones it doesn't with all the PCI config space set to 0s. With some cards the machine simply won't even boot. For those where it does (eg Matrox G200 cards and Intel 82557 ethernet cards (eepro100 driver)) this problem should be solved by using 2.4, although the drivers may need fixing because the PReP architecture has an offset of 0xC0000000 when accessing memory on cards which most drivers don't know about.

Patches

• caro-min-2.4-bk011111.diff.gz

  • Version: 0.9
  • Description: This patch contains the minimum necessary to get your carolina system running on 2.4. It includes:
    • The fix to i8259.c which uses the "read from 0xbffffff0 to generate an ack" trick (thanks Hollis!).
    • A fix to make sure that early versions of the ncr53c810 scsi chip found in some TP850s (which don't set the PCI class correctly) get remapped by the pci resource code.
    • A hack to work around the evil PCI-VL bridge which is responsible for the graphics card on the TP850 (if we allow the PCI code to remap the PCI device, the VGA console stops working).
    • Define CONFIG_ISA to be Y which allows kernel PCMCIA code to work properly on TP850.
    • Support for reading the PReP residual data from /proc/residual.
  • Status: Patch is against the BitKeeper linuxppc_2_4_devel tree as of 11 November 2001.
  • Errata:
    • I've been told that the i8259 changes break some other systems but I'm not sure which. It is known that i8259 handling on PPC is broken right now; so don't expect these patches to work on your Motorola box for example.

• caro-min-2.2.diff.gz

  • Version: 1.2
  • Description: This patch contains the minimum necessary to get your carolina system running with a 2.2 kernel. It includes:
    • One-line fix to get the decrementer frequency from residual data instead of trying to calculate it.
    • A corrected hard-coded PCI IRQ routing table - on the carolina, all PCI interrupts are routed to IRQ 15.
    • Trivial fix to allow framebuffer consoles to be initialised when CONFIG_VGA_CONSOLE isn't set (although I don't believe any of the framebuffers will actually work at this stage; the vga16fb code doesn't allow for the video memory being mapped at an offset the way the PReP architecture does IIRC).
  • Status: Patch is against 2.2.18 (from ftp.kernel.org), but should work against most 2.2.14+ kernel trees (including vger and bitkeeper).

• carolina.diff.gz

  • Version: 2.2
  • Description: This patch includes various useful things to get your carolina system working:
    • One-line fix to get the decrementer frequency from residual data instead of trying to calculate it.
    • Fix to extract the PCI interrupt mappings from the residual data, rather than relying on (possibly incorrect) hardcoded values.
    • Support for /proc/residual, a way to access the residual data from userland.
    • Trivial fix to allow framebuffer consoles to be initialised when CONFIG_VGA_CONSOLE isn't set.
  • Status: Patch is against 2.2.18 (from ftp.kernel.org), but should work against most 2.2.14+ kernel trees (including vger and bitkeeper). There appears to be a problem if CONFIG_NVRAM is set, so don't. Here is the .config I used.

• ibm_e15fb.diff.gz

  • Version: 0.5
  • Description: This patch should allow you to use the onboard video subsystem of the Carolina as a console framebuffer.
  • Status: Patch is against 2.2.18 (from ftp.kernel.org) + carolina.diff.gz above, but should work against most 2.2.14+ kernel trees (including vger and bitkeeper). It currently supports modes from 640x480@60Hz to 1024x768@60Hz, 8bpp pseudocolour. It also does all sorts of evil stuff like assume there is nothing at 0x20000000 on your PCI bus etc etc. It works as a text mode console and also works with XF68_FBDev v3.3.6 and XFree86 4.0. YMMV!
  • Todo: Get higher resolutions and pixel depths working.
  • Errata:
    • Produces "snow" as the video clock gets to around 60MHz. I haven't figured out how to cure that one yet, but I suspect moving to clock-doubled modes may help.

Utilities

• lsresidual.tar.gz

  • Version: 0.3
  • Description: This tool parses the contents of /proc/residual (see carolina.diff.gz above) and prints it out in a human-readable form.
  • Status:Parses and prints the VPD and the residual data, including the devices section and the long PNP tags; doesn't parse the short tags yet.

Misc

• Not getting any video output from Linux? Check that you have your monitor cable plugged into the video port on the motherboard (bottom right connector as you look at the rear of the case when it is sitting flat), and not into a second video card on the PCI bus. The firmware will initialise all the video cards it finds in the machine, but currently Linux will only find the built-in one.
• The 6050 and 6070 machines are functionally identical (the motherboard unit is the same); the 6070 comes in a larger case. The 6050 was only available at 100MHz with 256K cache, whereas the 6070 came in 120MHz and 133MHz variants with 512K cache as well.
• Can't find parity memory? These machines appear to work fine using non-parity RAM if you remove the cache module. The only side effect (apart from the lack of cache) is that the machine won't reset correctly on reboot and will have to be power-cycled.
• Having trouble with your PCMCIA on the Thinkpad 850? Try passing the following options to the i82365 driver:

  do_scan=0 i365_base=0x3e0 irq_list=3,5,9,14
  

  If you are getting messages abouut not being able to find any i82365 chips in the system, its highly probable that you have managed to build i82365.c with CONFIG_ISA set to n; the 2.4 patch above solves this for 2.4 kernels; for 2.2 kernels you need to hack and rebuild the pcmcia-cs package appropriately.

Last Update: Sun Mar 25 18:36:06 BST 2001
Email: David Monro <davidm@amberdata.demon.co.uk>
Homepage: http://www.amberdata.demon.co.uk/personal