Re: Afterburner and Linux

From: Michael Schmitz <schmitzm_at_uclink4.berkeley.edu>
Date: Mon, 8 Jun 1998 15:24:24 -0700

At 12:00 AM +0100 6/9/98, Petr Stehlik wrote:
>MS>The only problem the AB040 poses on top of that is not doing bus snooping
>MS>(plus maybe other weirdness we didn't discover yet). But the ball is
>back in
>
>Linux worked on my AB040 since a friend from Australia compiled first
>kernel with support for 040 only (back in 1996). Current versions
>(2.0.33 and 2.1.99) run on my AB040 OK as well. I haven't played with
>ST/FastRAM caching yet. So I'd say that a plain Linux kernel can run
>fine on *some* AB040 at least.

Fine, apparently Thomas' AB040 had some more problems than yours. How much
ST-RAM do you have?

>As for the peculiarities of AB040 (compared to stock Falcon):
>
>- SCSI is very sensitive (when VIDEL generates screen the SCSI timeouts
> and/or produces errors or hangs whole kernel). When it happens to work
> (for example with NOVA graphics) the performance is painful (90 kB/s
> compared to 950 kB/s under TOS (yes I know I must not compare it)).

That's what I experienced: 16 cols and not above 35 kHz, 740x4xx resolution
did work, above that it was playing havoc with my filesystems. But from earlier
discussions on the linux-m68k ML I got the impression that SCSI doesn't work
reliable under any circumstances? Guess I could have saved myself the effort
then ...

Comparing Linux and TOS ... we've had that discussion before, and it seems
there are sufficiently large differences to make comparisons difficult. I
was amazed to learn that MiNT doesn't use the MMU just now.
I'm not exactly happy with the SCSI performance in Linux either but I didn't
dig into the drivers any further.

>- when kernel is in FastRAM, the interrupts from MFP timer are somehow
> missed or lost, which causes wrong timming, scary BogoMIPS values and

Couldn't test that ... or rather, didn't try because I remembered these
reports.

>>From the lines above it sounds like AB040 is a completely brain-dead
>hardware hack that has a plenty of design bugs and can't actually run.
>Surprisingly, many people use it for several years under TOS/MiNT or

Yep, I'm not saying it doesn't work at all, it's just weird enough to not
work with Linux. And a lot of broken hardware was made to work with Linux.

>even MagiC, they use both overclockers and SCSI drivers and are quite
>happy with it. I think Linux still could be patched somehow to be more
>AB040 friendly (by respecting its hardware misdesign, probably).

I agree. And as I don't have the AB040 to test on, I'll leave figuring out
that 'somehow' to the people who have the hardware. Sorry for getting involved
here.

>MS>Please also try running the kernel in FastRAM, just for reference.
>
>Since ATABOOT version 3.1 it's impossible to place kernel in FastRAM,
>just because FastRAM is there only if PMMU is correctly programmed.

Ok, that explains it. Seems that the booter needs to do some MMU magic on
its own to blow the FastRAM mapping away and use physical addressing
for it, before loading the kernel to FastRAM. Where does the FastRAM get
mapped, and where is it located physically?

Should be not too hard to let the kernel startup code set up a temporary
transparent mapping to deal with the 'logical 0 != physical 0' case. We've
had to do this for the Macs anyway so the code to handle this should be
present.
The crucial thing seems to be using the physical addresses for FastRAM.

Alternatively: you have a booter version that is capable of loading the kernel
to FastRAM. Why don't you try booting the kernel with all RAM non-cacheable
and see if the timing problems are gone?

        Michael
Received on ti. juni 09 1998 - 20:01:00 CEST

This archive was generated by hypermail 2.3.0 : ti. nov. 03 2015 - 20:07:54 CET