In article <Pine.LNX.3.95.1001015201830.32012A-100000@chaos.analogic.com>,
root@chaos.analogic.com (Richard B. Johnson) writes:
> On Sun, 15 Oct 2000, Robert Kaiser wrote:
>
>> > The AMD/Elan box snoops for the sequence sent to the keyboard
>> > controller to enable A<20>.
>>
> Robert Kaiser didn't write this. I did. And yes. It makes no difference
> about the 'board' it's in the chip.
Well, if it is in the chip, then what ever is in there doesn't work properly:
I have seen several different AMD Elan boards that failed to boot Linux. Adding
the "fast A20 enable" via port 0x92 to setup.S fixed the problem in all cases.
>> > The AMD/Elan chip also comes to life after a hardware reset with
>> > A<20> enabled. So, if you don't turn it OFF, there won't be any
>> > problem during the protected-mode transition.
>>
>> Sure, but whether you CAN leave it on depends on the board's BIOS.
>> Some of them are "smart" and won't let you configure the initial
>> A20 state. Adding the port 0x92 method to setup.S as I'm suggesting
>> would be safe in all cases (assuming it won't break anything else).
>>
>
> Many who use Linux in embeded systems write their own BIOS as I
> have done. Then you don't have to pay $10/box you ship to a BIOS
> vendor who ripped off all the code anyway.
I hope you are not seriously suggesting that everyone who uses Linux
in embedded systems should be prepared to write their own BIOS.
Of course it's nice if you don't have to pay BIOS royalties, but in
my experience, people who have a high enough volume so that writing
their own BIOS would make sense tend to go for a different architecture
(PPC, ARM, MIPS, SH) in the first place.
(BTW, is your BIOS under GPL perchance ?)
> FYI, the code that was submitted can't possibly work (it was backwards).
> If it made your board 'work' there is something else broken.
Yep, my fault: The code _did_ work in a 2.2.x kernel, but I applied the
change to the latest 2.4 kernel, not realizing that the assembly syntax
had been changed in the meantime. I should have at least tested it. See below
for a corrected version. This time I've tested it: the unmodified kernel fails
to boot on a JUMPtec DIMM-PC (with AMD Elan SC410), the patched kernel
does boot.
Some may argue that simply writing 0x02 to port 0x92 would do the job and
they may well be right (it does work that way on the DIMM-PC). My suggested code
makes sure to keep bits #7-#2 unmodified and it always clears bit #0 (CPU
reset). Call me paranoid, but I think this is worth two extra assembly
instructions :-).
diff -urN linux-2.4.0-test8/arch/i386/boot/setup.S linux/arch/i386/boot/setup.S
--- linux-2.4.0-test8/arch/i386/boot/setup.S Wed Jul 19 07:00:33 2000
+++ linux/arch/i386/boot/setup.S Mon Oct 16 15:27:48 2000
@@ -631,6 +631,16 @@
# appropriate
# that was painless, now we enable a20
+
+# enable the "fast" A20 gate
+
+ inb $0x92, %al
+ orb $0x02, %al
+ andb $0xfe, %al
+ outb %al, $0x92
+
+# enable the keyboard controller A20 gate
+
call empty_8042
movb $0xD1, %al # command write
----------------------------------------------------------------
Robert Kaiser email: rkaiser@sysgo.de
SYSGO RTS GmbH
Am Pfaffenstein 14 phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:09 EST