Re: L68K: Re: Afterburner and Linux

From: Doug Little <doug_at_innerworkings.co.uk>
Date: Mon, 8 Jun 1998 11:16:57 +0100

>> That means it's either hardware registers being cached - which should not
>> be possible so long as they lie in the usual address space for hardware


> Can this configured by TK?


No, because there is absolutely no reason you would want your registers to
be cacheable - they are *always* noncacheable. Cacheable registers = totally
inoperable Falcon. The TK makes all hardware registers non-cacheable by
default. They are also serialized, to ensure write-sequences are not
interfered
with.

>Yes, but I have problems with XHDI if caches are on. XHDI doesn't work
>correctly (some operations, XHDosLimits for example) if the data cache is
>on.


Then it is very probably using direct DMA operations into cacheable ST-ram.

These programs should really be taking care of the caches themselves. It
is very very difficult to intercept these kinds of operations when they go
direct
to hardware in order to read/write SCSI devices. All you can do is turn the
CPU caches off around the program, or turn them off completely, or mark the
area of ram being used by their DMA transfers as non-cacheable. That means
you have to know where that RAM is - and that means you have to know how
the programmer designed it.

DMASNOOP will mark all STRam from itself upwards, so if it doesn't help,
then the program must be using STRam allocated BEFORE DMASNOOP
was executed. That means it's ram allocated by an earlier program - which
in turn means it's probably a FRB or something installed very early in the
boot sequence.

So, it could be the disk driver itself allocating cacheable STRam for a DMA
buffer. The solution could be to find the buffer and mark it noncacheable.
Look
at your cookies to see what is there. If XFRB exists, then it could be the
problem.

>doesn't help. If data cache is on (after boot) and I use XHDosLimits
>something goes *very* wrong.


It could be the same problem. XHDI could have allocated a block of cacheable
STRam for it's DMA buffer very early in the boot sequence. If the caches are
on
at any point afterwards, it is very likely that DMA transfers will fail
because they
are taking place to/from this cacheable ram.

Look for an XFRB cookie. If it exists, try to remove it and reboot. See if
the _FRB
cookie installed by the TK will work on it's own. That uses non-cacheable
RAM
and should therefore be safe. So long as XHDI recognises and uses it after
TK
is installed. You may have to re-run XHDI after TK to get it to 'see' the
buffer.

Doug.
Received on ma. juni 08 1998 - 18:34:00 CEST