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:
Pull pin 11 of the 16L8 PAL out of the board
Solder pin 11 of the IC to +5V (pin 20 of 16L8)
****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, see the section called The Amiga memory device driver (z2ram) in Chapter 8.
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 and 2.2 kernels, 16-bit RAM is automatically disabled on Zorro III-based 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 (revisions 3.0 and 3.1).
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 to the boot command you are using. However, this will result in irritatingly slow disk accesses.
A better solution is to replace the A3640 with a newer version of the card (revision 3.2) 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 encounters 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.