(Much of this section written by Jesper Skov)
Since the release kernels found at the various Linux/m68k sites are compiled for the average user, they contain drivers for just about every piece of hardware supported by Linux. They will also be compiled so they can be run on all the processors in the Motorola 68000 family.
This scheme enables everybody to boot Linux, but it also reduces the performance of Linux: drivers for hardware you don't have or use take up (non-swapable) memory, and in case of processor specific programming, it is required to check which set of instructions to run.
Therefore, if you are a bit adventurous and have time to spare, you should recompile a kernel for your machine configuration. Especially if you are not a kernel hacker (i.e., you don't care about all those 2-3 line patches :) and use the same kernel for several days/weeks, the time will be well spent.
Recompiling your own kernel will make it possible to configure it to your exact machine configuration, thus giving the best performance possible.
The Linux/m68k sources are available by ftp from sunsite.auc.dk in ``/local/os/linux/680x0/vx.x'', x.x denoting the latest version numbers.
The sources are also mirrored at the sites listed in FTP Sites.
You will need at least gcc version 2.7.2 (preferably 2.7.2.1 or later) to compile the kernel.
Recompiling the kernel for the MC68060 processor requires binutils 2.7.0.3 or later, fixing a linking problem with the ifpsp (integer/floating point support) files.
Linux 2.1.x and later require binutils 2.7.0.3 (or later) with the CHIP fix. This makes it possible to specify which processor (chip) the instructions should be assembled for. Thus it is now possible to write mnemonics instead of opcodes for the bigger processors which eases the reading of the code and removes the problem of wrong mnemonic/opcode translations.
GCC can be found at any of the Linux/m68k FTP sites (see Linux/m68k ftp sites). The required version of the binutils package can be found at ftp://sunsite.auc.dk/local/os/linux/680x0/bin/.
Linux/m68k releases are built and released by Jes Degn Sørensen. ``Built'' means that you can write a patch against the current version or patchlevel and send it to them or the mailing list and they will integrate it into one of the next releases. Make sure you state against which version the patch was made. Please note that Jes has no way to test Atari-specific patches.
Note: If you patch processor-specific code (e.g. 68030 vs. 68040 MMU or FPU) make sure that you document the dependencies.
Send bug reports to the author of the code or to Jes. Probably a better approach is to post it to the linux-m68k mailing list or to the appropriate newsgroup. If there are bugs that will probably stay in the code for an extended period of time let me know so I may publish them here.
Problem:
Linux reports *** COPROCESSOR PROTOCOL VIOLATION *** FORMAT=9 or
something similar.
Fix:
Pull the 16L8 PAL's pin 11 free (this is the signal 'XBG') and solder it to +5V. This prevents the PAL from tri-stating AS and DS until XBGACK has gone low.
To make your 32 MHz daughter-card work:
****This applies to the CA400771 32 MHz daughter board****
**********Other boards should not have this bug***********
_______________________________________________________________
Atari 32 Meg Daughter Board / PGA |
|
___________________ |
| | |
| | |
2 1 1 1 1 1 1 1 1 1 |
0 9 8 7 6 5 4 3 2 1 |
. . . . . . . . . . . . . . . . . . . . |
PAL 16R4-7PC PAL 16L8-7PC |
. . . . . . . . . . . . . . . . . . . . |
1 2 3 4 5 6 7 8 9 1 |
0 |
CA400771 |
___________________________________________________________|
|
|
___|
Problem:
When using a GVP card with 16 bit RAM on an Amiga with 68040, Linux/m68k dies. (This also happens with Commodore A2052 boards.)
Fix:
Unfortunately, there is no known solution to that problem. So your best bet is to get some real 32 bit RAM. The 16-bit RAM may still be used as a ramdisk using the z2ram device.
When using the 2.0.x (and earlier) kernels, you must stop it from being used as normal RAM (-m option of amiboot). Quoting from the README for amiboot:
If you have some non-AutoConfig memory you want to use under Linux, or if you
want to disable some parts of your memory (e.g. Zorro II RAM on '040 based
systems), you have to use a memory file and the --memfile option. This file
contains information about the memory chunks you want to use under Linux. The
format for the file is:
chipramsize
[0xfastchunkaddr fastchunksize]
[0xfastchunkaddr fastchunksize]
...
For example, if you don't want Linux to use your 2nd meg of chipram, you would
create a file that looks contains only:
1048576
If you had 1M of chip ram, 2M of 16 bit FAST ram at address 0x200000 and 16M of
32 bit FAST ram at address 0x80000000, and you didn't want Linux to use the
slow 16 bit FAST ram, you'd create a file that looks like:
1048576
0x80000000 16777216
The memory file can also be used to specify in which block of memory the kernel
will be put. Normally Amiboot will put the kernel in the first block of Fast
RAM it will find. If you use a memory file, it will put the kernel in the first
block of fast RAM you specify.
In recent 2.1.x kernels, the 16-bit ram is automatically disabled on Zorro-III systems, so you don't need to make a memory file.
Problem:
You get strange system crashes and segmentation faults with a Zorro II SCSI controller and an Amiga 3000 or 4000 with a Commodore A3640 revision 3.0.
Fix:
The immediate fix is to make your SCSI controller stop using DMA. If
you're using a A2091 or GVP Series II controller, add the kernel
parameter wd33c93=nodma:1 to the boot command you are using.
This will result in irritatingly slow disk accesses.
A better solution is to replace the A3640 with a newer version of the card or a third-party card like the Phase5 Cyberstorm, Warp Engine, GVP/QuikPak 4060D, or Apollo 4060. You may also be able to upgrade your A3640 yourself, if you have some electronics knowledge.
(written by Jesper Skov)
Problem:
In order to streamline the design of the MC68060, Motorola left out the implementation of a few addressing modes and instructions. The '060 remains user-level compatible with the other family members by emulating these addressing modes and instructions in software.
Whenever the '060 encounter an unimplemented instruction, a special exception is taken that enters the ifpsp (Integer and Floating Point Software Package), which is part of the kernel. Here the instruction is emulated and processing is resumed.
Obviously, this adds an overhead to the use of the system and since gcc 2.7.2 uses the unimplemented instructions for 64 bit multiplication and division there is reason for concern. Judging from my tests (highly inaccurate :) I expect a boost of at least 10% when applications can be recompiled with an 060 aware gcc (that would be release 2.8.0, due out last year ;)
Fix:
Recompile applications with an 060-aware gcc when available. A patch to gcc 2.7.2 was recently posted that may also help.