Killing caches: fool-proof method?
Hi,
Does anyone have a nice blob of code for disabling caches across all 680x0? Let's assume this is just before or after taking over the system, ExecBase still available. I'm aware there's a little dance of poking control registers that may not all exist so need to be tested for, or the resulting exceptions handled. Alternatively (or as well): would CacheControl(bits=0,mask=-1) be suitable system-friendly approach? I haven't actually yet found an example of someone calling this to disable all caches, but I guess I haven't foraged *that* hard. ;) Cheers! |
If you have LVOCacheControl available, it should be fine. Beware that you need Exec V37+ for it to be present.
|
000~060, all KS
Code:
start |
Quote:
|
I remember CPUSHA BC (branch cache? 68060?)
|
ross's example code sets VBR to 0 in the supervisor routine but doesn't restore it afterwards. May not be a problem if you're killing the system/OS anyway though.
|
Quote:
CPUSHA pushes and possibly invalidates selected cache lines (IC=instruction, DC=data, BC=both). BC works, but if you disable all caches (CACR=0) then a DC suffice. For the 060 i've disabled also the Superscalar Dispatch (ESS bit in PCR register). |
Quote:
You can simply add: Code:
move.l a5,(a2) EDIT: well, the moveq #0,d1 actually only serves if you plan to use the previous base and you are on a 000 not much if the next instruction is movec d0,vbr, so one of the two can be removed ;) |
I like the way your code does NOT test CPU family explicitly. Nice.
|
Quote:
Zeroing VBR in this routine is quite nice if you're eventually killing the system: in some cases whatever you end up jumping into might well not consider non-zero VBR itself. Secondly I wondered whether touching INTENA is necessary -- is it just because touching exception vectors is frowned on? I suppose it might stop AV or debug software going nuts. |
Interesting update on this: I found the CPUSHA instruction can hang on some (specifically, Apollo) 68020 and 68030 accelerators. I didn't track down the root cause -- sometimes it hangs, while in other places it might appear to execute (without the expected F-Line exception). The CPUSHA will cause a bus cycle on 020/030, so perhaps the Apollo glue mucks up the handling.
I fixed this by gating execution of CPUSHA on a 'safer' 040+ instruction (MOVEC ITT0,D1) which does not depend on external decode logic. |
Quote:
|
Quote:
|
Ah, so that's what you are saying. Indeed, one should *not* attempt to run CPUSHA on these processors at all since the instruction is unsupported on them. To clear the cache, use CacheClearU() in exec, which is processor-independent.
|
Properly designed hardware should reject CPU co-processor IDs that don't exist by activating bus error signal when CPU attempts to access non-existing co-pro which CPU internally converts to normal F-line exception. This is documented in official 020/030 documentation.
Unfortunately some 020/030 boards fail to do it. |
Quote:
By the way, tangentially related: I have had reported that 'PMOVE TC' (to disable MMU on 68851/68030) would give an unexpected exception on a Furia 68020 card (Coprocessor Protocol Violation, which was a new one on me). I figure that since 68851 is external, 68020 must do bus cycles for that instruction too and is also subject to vagaries of external logic. So I am making that instruction 68030-only: I assume that since 030 doesn't support external PMMU, the PMOVE to disable MMU must be safe even on 68EC030 which does not 'support' MMU? No bus cycles there? |
Quote:
Quote:
Quote:
|
Quote:
Why would you want to do this? Just as a means of slowing down the CPU even more? AFAIK having superscalar on doesn't cause any compatibility problems with anything. Only possibility I can think of is if you're doing some weird externally-modified code that changes an opcode for the very next instruction fetch somehow. |
Quote:
-- So the code blob need to be modified, I had no idea that the CPUSHA in some accelerator can hang the machine.. How to fast recognize 020/030 CPUs (w/o SO)? |
Quote:
Not sure it's what you want, but here are a few tricks : - set some 040+ bit in cacr - if it reads back as 0, then 020-030 - try to access caar register - if not illegal, then 020-030 - trace a trap instruction - if you get to the trap vector instead of trace, then 040+ - try some cpsave opcode (e.g. $FF10) in user mode - if privilege violation instead of line-F, then 020-030 Note that it's possible emulators get caught and won't behave properly :p |
All times are GMT +2. The time now is 10:34. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.