10 November 2010, 13:45 | #1 |
Soldering Ironman
Join Date: Sep 2008
Location: Germany, NRW
Posts: 79
|
Found nasty bug in 68030 CPU!
Hi guys,
as I am currently writing the software for the upcoming ACA630/1230 cards, I encountered a possibly undocumented bug in the MC68030 CPU line. This bug is so subtle and hard to find, probably no coder has ever noticed it, but as it happens, it drove me crazy for several days, since of course I blamed our hardware design for it first, but later realized that it was perfectly reproducable on all kinds of hardware. I formulate the bug now in one sentence, and explain what it means: On longword accesses, the 68030 ignores the Cache Inhibit (CIIN) pin What does that mean? The 68030 has a Cache Inhibit pin, which is used to disable the instruction and data caches for certain memory areas. In case of the Amiga, this usually contains all the register areas, since the contents of certain chipset registers change dynamically, so the 68030 needs to be told not to cache any data being written to those registers. Most Amiga chip registers are write-only. Any readback yields unreliable bus trash. Like this: Code:
move.w #$dead,$dff180 move.w $dff180,d0 Now do this longword access with activated caches: Code:
move.l #$deadbeef,$dff180 move.l $dff180,d0 Try the same now with disabled caches, and now the trashed values also appear on longword accesses. The 68030 is now reading again the actual bus values! This bug ONLY appears on long word read/writes, which is probably the reason why most accesses to chip registers, which are usually word sized and most probably do not involve reading-back status registers using londwords, like DMACONR, do work. However, I am sure that any potential reader who has the expertise to interpret this stuff can imagine lots of potential scenarios, which might be rare, but which can lead to very confusing, nasty and hard to find bugs. This might be valuable information for WHDLOAD patches, since I know that lots of games do weird and nasty stuff, which probably triggers this bug in some cases. Last edited by Oliver_A; 10 November 2010 at 14:11. |
10 November 2010, 14:42 | #2 |
Puttymoon inhabitant
|
How this bug affects those upcoming cards? And is it possible to avoid?
|
10 November 2010, 14:51 | #3 | |
Soldering Ironman
Join Date: Sep 2008
Location: Germany, NRW
Posts: 79
|
Quote:
I made this report here primarily for coders, since it might affect behaviour in old games. Since from AmigaOS2 on, cache behaviour is taken into account, this shouldn't affect any "clean" code. How to avoid? Don't read status registers using longwords, especially chipset registers. Flush caches after DMA operations. |
|
10 November 2010, 16:30 | #4 |
Coder/webmaster/gamer
Join Date: Oct 2001
Location: Canberra/Australia
Posts: 2,673
|
Well spotted. Have you told Freescale about this bug?
|
10 November 2010, 17:00 | #5 |
Registered User
Join Date: Aug 2006
Location: Augusta, Georgia, USA
Posts: 552
|
"The assertion of CIIN is ignored when the appropriate cache is not enabled or when cache inhibit
out (CLOUT) is asserted. It is also ignored during write cycles or translation table searches. " Not sure if that applies here, but that is from the Motorola manuals. I would think something that big would be by design or at least well-known. |
10 November 2010, 17:00 | #6 |
Targ Explorer
|
is this related to the 68030 cache bug referred to by Dave Haynie in the A3000 system spec? (page 23, para 1, line 6)
http://www.thule.no/haynie/research/...ocs/a3000p.pdf |
10 November 2010, 17:03 | #7 | |
Registered User
Join Date: Mar 2008
Location: Poland
Posts: 159
|
Quote:
If the WA (Write Allocation) bit is set in the CACR register every long-word aligned long-word write will allocate an entry in the data cache. |
|
10 November 2010, 17:24 | #8 | ||
Soldering Ironman
Join Date: Sep 2008
Location: Germany, NRW
Posts: 79
|
Quote:
Quote:
Point remains: data should never ever be retrieved from cache during a read cycle when CIIN is asserted. This IS a hardware bug. Last edited by Oliver_A; 10 November 2010 at 17:47. |
||
10 November 2010, 21:04 | #9 | |||
Registered User
Join Date: Mar 2008
Location: Poland
Posts: 159
|
Quote:
The purpose of the CIIN input is to prevent the data read from the memory to be put into the cache. It doesn't prevent the data from the cache to be accessed by the CPU. There is no way to find out from the outside of the CPU what is the address of the data the CPU wants to access until there is a cache miss and an external bus read cycle is started. During this cycle the CIIN input can be used to prevent caching of the accessed data. I think it's very clear. Quote:
Quote:
The problem is caused by writing a long-word to long-word aligned address with the WA (Write Allocate) bit set. In this case an entry in the cache is always allocated regardless of the state of the CIIN input and all successive reads from this location will access the data in the cache (unless it's flushed) with no external bus read cycle generated. Since it's documented it's a feature and not a bug. |
|||
10 November 2010, 23:39 | #10 |
Ya' like it Retr0?
Join Date: Jul 2005
Location: United Kingdom
Age: 49
Posts: 9,768
|
@yaqube
I am sure I heard M$ use that line "Since its documented it's a feature and not a bug" =D I would be curious to know if this feature/bug is inherent in the 020. |
10 November 2010, 23:57 | #11 |
Registered User
Join Date: Mar 2008
Location: Poland
Posts: 159
|
|
13 November 2010, 15:39 | #12 |
Moderator
Join Date: Nov 2001
Location: Germany
Posts: 875
|
whdload slave authors should be aware of this behavior
using the options SnoopOCS/ECS/AGA WHDLoad will detect all reads to write-only and writes to read-only custom registers, with that problems caused by this behavior can be detected without much effort also if MMU is used custom/cia regions are marked as uncacheable it should also be noted that write allocation is only needed if usermode and supervisor mode acceses the same memory, for several games running only in supervisor mode WA can be disabled |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Swap CPU for a cooler running 68030 in ACA630 | Photon | support.Hardware | 25 | 24 July 2013 02:58 |
CPU(?) bug since 2.4.1 | hceline | support.WinUAE | 2 | 09 January 2013 18:40 |
Found and fixed a bug in Phantasie III | Nogg | Retrogaming General Discussion | 48 | 04 August 2011 10:39 |
FPU bug found WinUAE 2.3.1 beta 7 | Cosmos | support.WinUAE | 5 | 18 December 2010 00:57 |
WinUAE needs a 68030 CPU Option | Exodus | request.UAE Wishlist | 3 | 28 April 2004 10:00 |
|
|