Excellent!! I just tried it and it does indeed work. I'm seeing something
else strange that maybe somebody can explain. Early in the boot I configure
all of the serial ports to the following settings (using CSC registers):
SC400 internal - 0x3f8, IRQ4
external 1 (middle) - 0x2f8, IRQ3
external 2 (right) - 0x3e8, IRQ5
In my initialization script I use "setserial" to configure these just for
good measure, and then run getty's on each. The two external ports work
flawlessly, but the internal one has a very strange behavior. It will ever
so slowly spit out 16 characters at a time. At first I assumed that Linux
wasn't seeing the interrupts from the UART, but when I looked at
/proc/interrupts, I saw one interrupt (on IRQ4) for each 16 character chunk.
Also, I found that if I type a charater on the attached terminal I
immediately get a couple interrupts and another 16 characters of output. I
can't think of an explanation for this except that the BIOS is configuring
some strage CSC combo that is causing problems. I've looked at the SC400
user's guide but can't see anything I'm doing wrong.
--andy
-----Original Message-----
From: Bjorn Eriksson [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 13, 1999 9:35 AM
To: 'Michael Binninger'
Cc: '[EMAIL PROTECTED]'
Subject: SV: AMD SC400 evaluation board, DiskOnChip 2000 and Kernel
2.0.35 won't tango.
>we had the same problem running Linux on the AMD SC400.
>In the A20 gate implementation of the SC400 is a little bug. If the
keybord-processor
>is initialized in the usual way it is possible that the A20 propagation is
changed by
>normal keyboard-processor access. (see the attached AMD-Errata No23 for
details)
>This crashes the kernel usualy at boottime. The curious thing is that the
point where the
>crash occurs is depending on clock-speed.
I couldn't postpone the point of crash no matter what I tried. I even
rigged a small video
camera to record the endless rebooting just for fun.
>Workaround: (tested for Kernel 2.0.35)
>in i386/boot/setup.s and i386/boot/setup.S you can find the following
>sequence:
It works! Thank you very very much.
----snip----
! that was painless, now we enable A20
call empty_8042
mov al,#0xD1 ! command write
out #0x64,al
call empty_8042
mov al,#0xDF ! A20 on
out #0x60,al
call empty_8042
----snip----
Put in both files before call empty_8042 the following four lines
and recompile the kernel. This is the in the AMD-Errata23 mentioned
workarround.
----snip----
! that was painless, now we enable A20
in al, #0x92
or al, #2
and al, #0xfe ! We don't want a reset in case it's set.
out #0x92, al
call empty_8042
mov al,#0xD1 ! command write
out #0x64,al
call empty_8042
mov al,#0xDF ! A20 on
out #0x60,al
call empty_8042
----snip----
//Björn (Happy happy happy) Eriksson.
