Ken Nakata <kenn@eden.rutgers.edu>

BSD on MC68LC040-based Machines

Version 1.1.2, Apr. 4, 1997, Ken Nakata <kenn@eden.rutgers.edu>


Table of Contents

  1. Aim and Scope of This Document
    1. Disclaimer
  2. Why doesn't my MC68LC040 work with NetBSD/m68k?
    1. How about other BSD?
  3. What can I do about it?
    1. Software fix
      1. Who is(are) working on the problem?
      2. When will it be fixed?
      3. How can I help?
      4. The case in which you cannot fix things by software alone
    2. Hardware fix(upgrade)
      1. When is it necessary?
      2. How do I swap the chip myself?
      3. Where do I get a 68040 chip or an upgrade service?
  4. Points of contact
    1. The NetBSD mailing lists
    2. Allen Briggs
    3. The author of this document

1 Aim and scope of this document

This document is written in order to clear things up a little bit for users of MC68LC040-based machines who wish to run NetBSD/m68k(*) on their machines. As described and explained in detail in later sections, it is not yet possible to do useful things on an MC68LC040-based machines running NetBSD/m68k. See Section 2.1 for applicability of this document to OpenBSD.

*: NetBSD/m68k is a generic term which refers to all ports of NetBSD to the Motorola 68000 architecture. This includes amiga (Commodore Amiga), hp300 (HP 300/400), mac68k (Apple Macintosh), and sun3 (Sun 3). There are a few other m68k ports.

1.1 Disclaimer and Copyright

This document is written by a user/non-core developer of NetBSD/mac68k, who does not know much about the other NetBSD/m68k ports or about other BSD systems that run on the Motorola 68000. Thus, some things written here may be inaccurate under certain environment. Some things may even be inaccurate under NetBSD/mac68k, depending on the machine model and other variables.

Although I generally try my best to reflect as much as I know and verify that the information contained in this document is correct as much as possible, I take no responsibility for loss or damage caused by use of the information contained within this document.

This document is (c) 1997 by Ken Nakata.

2 Why doesn't my MC68LC040 work with NetBSD/m68k?

Right now, you cannot do useful things at all on your LC040-based machine (from hereon, referred to as an "LC040 box") running NetBSD/m68k. You can boot the kernel in single-user mode, but that's about it. As soon as you attempt to run almost any user program, you will get core dumps caused by segmentation faults, address errors, bus errors, and so on.

This is due to a bug in floating-point emulator (or FPE for short). It has been preventing NetBSD from properly running on any LC040 box. Granted, FPE has still more bugs than just this LC040 problem, but it at least lets FPU-less 68030 machines run some useful things, albeit very slowly. Anyway, FPE has a serious problem with LC040 such that some of the integer registers (including program counter) apparently get mangled when the execution returns from FPE to the user process which tried to use an FP instruction. This causes the seemingly random errors described above.

If you need further details on the problem, or have clues on the problem, please contact me.

2.1 How about other BSD systems?

As far as I know, there's at least one other free BSD system which runs on the Motorola 68000 architecture: OpenBSD/m68k. BSD/OS doesn't support the m68k, nor does FreeBSD.

Probably everything written here applies to OpenBSD/m68k as well, but I have almost no knowledge of it. That's the only reason why I use the word "NetBSD", and I have no intention to keep people from using OpenBSD on their computers. If you want to mentally s/NetBSD/OpenBSD/g when reading this document, please feel free to do so, but I make no guarantee of its applicability.

3 What can I do about it?

At this moment, there's a couple of things you can do about the situation:

3.1 Software fix

Software fix involves fixing the FPE bug(s).

3.1.1 Who is(are) working on the problem?

As the programmer of most part of the current FPE, I started working on the problem immediately after notified of it, but for quite some time, I've been more trying to find time to work on it than actually working on it.

Allen Briggs also expressed his willingnes to fix the problem, but he needs to find the time. Someone has loaned him an LC040-equipped machine.

Or, if you think you can do it, please offer your help and I'll gladly step down. However, it doesn't mean that I think there are better things for me to do than this. As I own an LC040 Macintosh, I myself have a vested interest in fixing the problem ;-)

3.1.2 When will it be fixed?

I'm not sure. It could be done in a couple of weeks or it might take a year. Please be patient if you are waiting for fix.

3.1.3 How can I help?

There's not that much you can help me fix the problem, as I have a working NetBSD system as well as an LC040 Macintosh. The largest obstacle for me is lack of time. However, if you could do some investigational work on an LC040 Macintosh for me, I would be very grateful. Please contact me.

Also, if you have a spare LC040 Macintosh you are willing to loan for the development for a while, please let Allen Briggs borrow it so that he could work on the problem.

3.1.4 The case in which you cannot fix things by software alone

However, there's a case in which you cannot fix the problem by software upgrade alone. Some mask revisions of MC68LC040 have a bug which prevents f-line trap handler (which catches attempts to execute FPU instructions and invokes the emulator) from properly working.

The bug even prevents SoftwareFPU, an FPU emulator for MacOS, from working on some LC040 Macintoshes. For more information about SoftwareFPU and the LC040 bug, please refer to John Neil Associates' SoftwareFPU Q&A page.

There is absolutely no software fix for this problem. You must replace the CPU chip with a newer, fixed one. In some cases, you can do it yourself by getting a 68040 chip, whereas you cannot do it yourself in other cases. In either case, please refer to the next section.

3.2 Hardware fix(upgrade)

You can always replace your crippled LC040 chip with the full 040 chip to get boost on floating-point performance. This should cause no software compatibility problem, and that way, you can not only get NetBSD to run on your machine, but also get it to run much faster than it would with the software FP emulator.

Please note that, in some case, it is MANDATORY to upgrade your chip even if FPE is fixed to properly handle LC040. This is because some mask revisions of 68LC040 have a bug which prevents any FPU emulation software from properly working on them. For more information, please see the next section.

3.2.1 When is it necessary?

As I wrote in Section 3.1.4, in certain cases you cannot fix the problem with software upgrade alone, but you need a hardware fix/upgrade.

There's Motorola's official device errata for MC68040 and its all derivatives (including LC040), and it says, at the bottom, Mask 2E71M corrects "#E4" among other bugs. This "#E4" is the bug which breaks things for SoftwareFPU, according to John Neil and Associates. It will cause problems with NetBSD's FPE as well.

If your box's LC040 is a mask revision prior to 2E71M, it is mandatory (rather than "advisable" or anything milder) to upgrade the chip to newer mask revision, or to a full 68040, in order to run NetBSD on it.

However, Motorola SPS group's Web site does not list all the broken mask revisions. We only know that the mask revision 2E71M is Ok. In other words, I don't know how you can tell, by looking at the chip, whether or not it's a buggy one. If you have more information on the mask revisions, please contact me so I could add it to this document.

To conclude this section, I cannot provide you with a definitive procedure to determine whether or not you need a hardware upgrade. However, if your machine is an LC040 Macintosh, you can try running SoftwareFPU and some application program which is known to require FPU. If SoftwareFPU does not crash, the bug is fixed in your CPU chip. If it crashes your machine, the bug is still in the CPU chip, thus you need an upgrade.

3.2.2 How do I swap the chip myself?

If your machine has the CPU socketted, you can pull out the CPU from the socket and put a 68040 back into the socket. You have to be very careful when doing this, as you can mechanically and/or electrically damage the chips and/or the logic board. It is advisable to ground your body when working inside the computer. Also, you should be very careful when inserting the new CPU chip into the socket: misoriented insertion could fry your CPU chip and/or the logic board! If you don't feel like risking your computer, I'd suggest that you have a professional do the job.

If your machine is a laptop such as the PowerBook 540c, it is most likely that the CPU chip is directly soldered on the print circuit board. It may be true for some desktop computers or some VME-bus board computers as well. If this is the case, you should not attempt to swap the chip yourself unless you know you have enough unsoldering and soldering experience with surface-mounted devices. Probably you should be equipped with specialized tools. If you don't satisfy these conditions but try it anyway, you may cause hardware damages which will be very expensive to fix (e.g. ones requiring entire part replacements). Thus, your only practical solution is to get a professional to do it for you.

3.2.3 Where do I get a 68040 chip or an upgrade service?

Here is some of the places where you can purchase MC68040 CPUs and/or CPU upgrade services:

The third and fourth entries are from Gerald Krall <cruller@unicom.net>. The last one is taken from Colin Wood's NetBSD/mac68k FAQ in which it is listed as one of the places where you can get a PMMU chip.

Please note that you cannot hold any of us (i.e. Colin, Gerald and/or me) responsible for the information listed here. Although we usually try to avoid fishy suppliers in any sense, we cannot guarantee that you will never have any trouble with them. That means, as usual, you are on your own when you do business with these people. YOU'VE BEEN WARNED.

4 Points of contact

4.1 The NetBSD mailing lists

There are a number of mailing lists regarding various aspects of running and/or developing NetBSD. Discussions regarding all of the m68k ports are held on the port-m68k list, whereas issues specific to a single port (such as amiga, hp300, mac68k, and sun3) are held on separate port-<port name> (e.g. port-amiga, port-hp300, port-mac68k, port-sun3, and so on).

For help message on usage of the mailing list server, send an empty-bodied message to majordomo@NetBSD.ORG, and a reply will be automatically sent back to you. This address is very important to remember as it's the address by writing to which you can subscribe to or unsubscribe from any list.

4.2 Allen Briggs

Allen Briggs can be reached at briggs@ninthwonder.com.

Anyway, BSD on mac68k would never have gotten this popular without him. There's no doubt about it. He had been the NetBSD/mac68k port master until recently, and he now works for both NetBSD and OpenBSD. Unlike some skillful people on the Net, he's extremely nice. He's always been nice to anyone who's ever wanted to use BSD on Mac. I believe he would be the last person to engage in a flamewar if there were one involving every programmer on earth.

He's been working on PowerPC port (particularly PowerMacintosh port) of BSD for quite a while, but he kindly offered his time to fix the m68k FPE problem if anyone can loan him an LC040 Macintosh. Please contact him if you have a spare LC040 machine.

4.4 The author of this document

You can reach me at kenn@eden.rutgers.edu. Right now, I'm taking summer sessions. My major is (of course!) CS, and I'm hoping to get out of the school by the end of the year. I learned of NetBSD/mac68k back when I was a student of NJIT and immediately started using it, and I did my FPE work after I transferred to Rutgers.

The current shape of FPE greatly owes Gordon Ross' framework of m68k FPE for its basic organization, and Chris Torek's Sparc FPE for its internal floating-point number representation and basic floating-point operations such as fadd, fsub, fmul, fdiv and sqrt. Without them, it would never have gotten this far.


Ken Nakata <kenn@eden.rutgers.edu>