Hi all,
a while ago, I posted a request here to add the "fast A20" enable sequence to
setup.S in order to enable booting Linux on boards that don't have a keyboard
controller. I was happy to see that this has been added into 2.4.0-test10
already. However, on some embedded boards, booting 2.4.0-test10 does work,
but it takes several minutes which the board spends in complete silence (it took
me almost a day to realize that I only had to wait long enough for the system
to boot ...)
The reason for this is that the A20 enable sequence in setup.S is still
accessing the (in my case not existing) keyboard controller. It times out
eventually, but the timeout takes *very* long, especially on a slowish
embedded 386EX@25MHz.
The attached patch fixes this by doing "fast A20" enable first and then
checking if A20 already is enabled. If it is, the keyboard controller sequence
is skipped. This works for me, so, could people please have a look at this.
Cheers
Rob
diff -ur linux-2.4.0-test10/arch/i386/boot/setup.S linux/arch/i386/boot/setup.S
--- linux-2.4.0-test10/arch/i386/boot/setup.S Mon Oct 30 23:44:29 2000
+++ linux/arch/i386/boot/setup.S Mon Nov 6 16:30:40 2000
@@ -631,6 +631,25 @@
# appropriate
# that was painless, now we enable a20
+# Try the "fast A20" version first:
+# You must preserve the other bits here. Otherwise embarrasing things
+# like laptops powering off on boot happen. Corrected version by Kira
+# Brown from Linux 2.2
+#
+ inb $0x92, %al #
+ orb $02, %al # "fast A20" version
+ andb $0xfe, %al # be sure not to reset CPU
+ outb %al, $0x92 # some chips have only this
+
+# See if that already did the job, skip keyboard controller
+# accesses if so: some boards do not have a keyboard controller.
+# These boards (especially if running on a slowish 386 EX)
+# can spend several *minutes* in silence, polling for the
+# non-existent keyboard controller.
+
+ call a20_check
+ jne a20_enabled
+
call empty_8042
movb $0xD1, %al # command write
@@ -641,31 +660,29 @@
outb %al, $0x60
call empty_8042
-#
-# You must preserve the other bits here. Otherwise embarrasing things
-# like laptops powering off on boot happen. Corrected version by Kira
-# Brown from Linux 2.2
-#
- inb $0x92, %al #
- orb $02, %al # "fast A20" version
- outb %al, $0x92 # some chips have only this
-
# wait until a20 really *is* enabled; it can take a fair amount of
# time on certain systems; Toshiba Tecras are known to have this
# problem. The memory location used here (0x200) is the int 0x80
# vector, which should be safe to use.
+a20_wait:
+ call a20_check
+ jne a20_enabled
+ jmp a20_wait # loop until no longer aliased
+
+
+a20_check:
xorw %ax, %ax # segment 0x0000
movw %ax, %fs
decw %ax # segment 0xffff (HMA)
movw %ax, %gs
-a20_wait:
incw %ax # unused memory location <0xfff0
movw %ax, %fs:(0x200) # we use the "int 0x80" vector
cmpw %gs:(0x210), %ax # and its corresponding HMA addr
- je a20_wait # loop until no longer aliased
+ ret
# make sure any possible coprocessor is properly reset..
+a20_enabled:
xorw %ax, %ax
outb %al, $0xf0
call delay
----------------------------------------------------------------
Robert Kaiser email: [email protected]
SYSGO RTS GmbH
Am Pfaffenstein 14 phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10
Followup to: <00110618083400.11022@rob>
By author: Robert Kaiser <[email protected]>
In newsgroup: linux.dev.kernel
>
> Hi all,
>
> a while ago, I posted a request here to add the "fast A20" enable
> sequence to setup.S in order to enable booting Linux on boards that
> don't have a keyboard controller. I was happy to see that this has
> been added into 2.4.0-test10 already. However, on some embedded
> boards, booting 2.4.0-test10 does work, but it takes several minutes
> which the board spends in complete silence (it took me almost a day
> to realize that I only had to wait long enough for the system to
> boot ...)
>
> The reason for this is that the A20 enable sequence in setup.S is still
> accessing the (in my case not existing) keyboard controller. It times out
> eventually, but the timeout takes *very* long, especially on a slowish
> embedded 386EX@25MHz.
>
> The attached patch fixes this by doing "fast A20" enable first and
> then checking if A20 already is enabled. If it is, the keyboard
> controller sequence is skipped. This works for me, so, could people
> please have a look at this.
>
This doesn't really work. Neither the fast A20 gate nor the KBC is
guaranteed to have immediate effect (on most systems they won't.)
What's worse, once you have done an "out" to the KBC you need to
finish the sequence. I need to think about this for a bit.
(Arguably, what you're doing is running on completely nonstandard
hardware, which may need a CONFIG_ option. However, if we can avoid
it I guess it's better.)
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
> This doesn't really work. Neither the fast A20 gate nor the KBC is
> guaranteed to have immediate effect (on most systems they won't.)
In that case, maybe I should do repeated calls to a20_check with a
(not too big) retry count after the port 92 write ?
Problem is, it happens to work this way on all hardware I have access to,
so I can't really reproduce such timing problems. Anyone ?
> What's worse, once you have done an "out" to the KBC you need to
> finish the sequence. I need to think about this for a bit.
??? I'm not touching the KBC if the port 92 access was successful at
enableing A20. If, however, A20 is still disabled, I'm doing the same KBC
sequence as the original code, so there shouldn't be any incomplete KBC
interactions (unless I mistyped something...).
> (Arguably, what you're doing is running on completely nonstandard
> hardware, which may need a CONFIG_ option. However, if we can avoid
> it I guess it's better.)
That was exactly my intention :-)
----------------------------------------------------------------
Robert Kaiser email: [email protected]
SYSGO RTS GmbH
Am Pfaffenstein 14 phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10
Followup to: <00110618083400.11022@rob>
By author: Robert Kaiser <[email protected]>
In newsgroup: linux.dev.kernel
>
> The attached patch fixes this by doing "fast A20" enable first and then
> checking if A20 already is enabled. If it is, the keyboard controller sequence
> is skipped. This works for me, so, could people please have a look at this.
>
I just looked at the code, and it's worse than I first thought: if
memory location 0x200 happens to contain 0x0001 when the kernel is
entered, this code with loop indefinitely.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
Followup to: <00110620483000.11673@rob>
By author: Robert Kaiser <[email protected]>
In newsgroup: linux.dev.kernel
>
> > This doesn't really work. Neither the fast A20 gate nor the KBC is
> > guaranteed to have immediate effect (on most systems they won't.)
>
> In that case, maybe I should do repeated calls to a20_check with a
> (not too big) retry count after the port 92 write ?
>
> Problem is, it happens to work this way on all hardware I have access to,
> so I can't really reproduce such timing problems. Anyone ?
>
> > What's worse, once you have done an "out" to the KBC you need to
> > finish the sequence. I need to think about this for a bit.
>
> ??? I'm not touching the KBC if the port 92 access was successful at
> enableing A20. If, however, A20 is still disabled, I'm doing the same KBC
> sequence as the original code, so there shouldn't be any incomplete KBC
> interactions (unless I mistyped something...).
>
The problem is that your test for A20 is faulty. Severely so.
Anyway, I just sent you a patch which will terminate the first empty_8042
loop (while it's still safe) if it finds A20 now enabled.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
On Mon, 06 Nov 2000 you wrote:
H. Peter Anvin wrote
> I just looked at the code, and it's worse than I first thought: if
> memory location 0x200 happens to contain 0x0001 when the kernel is
> entered, this code with loop indefinitely.
Ooops, you're right !
How about this one:
diff -ur linux-2.4.0-test10/arch/i386/boot/setup.S linux/arch/i386/boot/setup.S
--- linux-2.4.0-test10/arch/i386/boot/setup.S Mon Oct 30 23:44:29 2000
+++ linux/arch/i386/boot/setup.S Mon Nov 6 21:14:45 2000
@@ -631,6 +631,26 @@
# appropriate
# that was painless, now we enable a20
+# Try the "fast A20" version first:
+# You must preserve the other bits here. Otherwise embarrasing things
+# like laptops powering off on boot happen. Corrected version by Kira
+# Brown from Linux 2.2
+#
+ inb $0x92, %al #
+ orb $02, %al # "fast A20" version
+ andb $0xfe, %al # be sure not to reset CPU
+ outb %al, $0x92 # some chips have only this
+
+# See if that already did the job, skip keyboard controller
+# accesses if so: some boards do not have a keyboard controller.
+# These boards (especially if running on a slowish 386 EX)
+# can spend several *minutes* in silence, polling for the
+# non-existent keyboard controller.
+
+ movw $0x100,%cx # small retry count
+ call a20_check
+ jne a20_enabled
+
call empty_8042
movb $0xD1, %al # command write
@@ -641,20 +661,20 @@
outb %al, $0x60
call empty_8042
-#
-# You must preserve the other bits here. Otherwise embarrasing things
-# like laptops powering off on boot happen. Corrected version by Kira
-# Brown from Linux 2.2
-#
- inb $0x92, %al #
- orb $02, %al # "fast A20" version
- outb %al, $0x92 # some chips have only this
-
# wait until a20 really *is* enabled; it can take a fair amount of
# time on certain systems; Toshiba Tecras are known to have this
# problem. The memory location used here (0x200) is the int 0x80
# vector, which should be safe to use.
+a20_recheck:
+ movw $0xffff,%cx # large retry count
+ call a20_check
+ jne a20_enabled
+ jmp a20_recheck # loop until no longer aliased
+
+#
+# cx has retry count
+a20_check:
xorw %ax, %ax # segment 0x0000
movw %ax, %fs
decw %ax # segment 0xffff (HMA)
@@ -663,9 +683,11 @@
incw %ax # unused memory location <0xfff0
movw %ax, %fs:(0x200) # we use the "int 0x80" vector
cmpw %gs:(0x210), %ax # and its corresponding HMA addr
- je a20_wait # loop until no longer aliased
+ loopz a20_wait
+ ret
# make sure any possible coprocessor is properly reset..
+a20_enabled:
xorw %ax, %ax
outb %al, $0xf0
call delay
----------------------------------------------------------------
Robert Kaiser email: [email protected]
SYSGO RTS GmbH
Am Pfaffenstein 14 phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10
Followup to: <00110621255000.12156@rob>
By author: Robert Kaiser <[email protected]>
In newsgroup: linux.dev.kernel
>
> On Mon, 06 Nov 2000 you wrote:
> H. Peter Anvin wrote
> > I just looked at the code, and it's worse than I first thought: if
> > memory location 0x200 happens to contain 0x0001 when the kernel is
> > entered, this code with loop indefinitely.
>
> Ooops, you're right !
>
As I already discussed with you in email, I think the patch I sent you
is better. I have attached it below for the benefit of other people,
I would very much like it if as many people as possible tested it out,
since the A20 stuff is mostly black magic; especially on systems that
are known to be troublesome, such as Toshiba laptops.
-hpa
--- setup.S.old Mon Oct 30 14:44:29 2000
+++ setup.S Mon Nov 6 12:13:50 2000
@@ -631,39 +631,45 @@
# appropriate
# that was painless, now we enable a20
+
+#
+# First, try the "fast A20 gate".
+#
+ inb $0x92,%al
+ orb $0x02,%al # Fast A20 on
+ andb $0xfe,%al # Don't reset CPU!
+ outb %al,$0x92
+
+#
+# Now comes the tricky part: some machines don't have a KBC and thus
+# would end up looping almost indefinitely here. HOWEVER, once we
+# have done the first command write, we must not stop the sequence.
+# Therefore, the first empty_8042 should check to see if the fast A20
+# did the trick and stop its probing at that stage; but subsequent ones
+# must not do so.
+#
+ movb $0x01,%dl # A20-sensitive
call empty_8042
+ jnz a20_wait # A20 already on?
movb $0xD1, %al # command write
outb %al, $0x64
+ xorb %dl,%dl # Not A20-sensitive
call empty_8042
movb $0xDF, %al # A20 on
outb %al, $0x60
+ xorb %dl,%dl # Not A20-sensitive
call empty_8042
-#
-# You must preserve the other bits here. Otherwise embarrasing things
-# like laptops powering off on boot happen. Corrected version by Kira
-# Brown from Linux 2.2
-#
- inb $0x92, %al #
- orb $02, %al # "fast A20" version
- outb %al, $0x92 # some chips have only this
-
# wait until a20 really *is* enabled; it can take a fair amount of
# time on certain systems; Toshiba Tecras are known to have this
# problem. The memory location used here (0x200) is the int 0x80
# vector, which should be safe to use.
- xorw %ax, %ax # segment 0x0000
- movw %ax, %fs
- decw %ax # segment 0xffff (HMA)
- movw %ax, %gs
a20_wait:
- incw %ax # unused memory location <0xfff0
- movw %ax, %fs:(0x200) # we use the "int 0x80" vector
- cmpw %gs:(0x210), %ax # and its corresponding HMA addr
- je a20_wait # loop until no longer aliased
+ call a20_test
+ jz a20_wait
# make sure any possible coprocessor is properly reset..
xorw %ax, %ax
@@ -825,14 +831,24 @@
#
# Some machines have delusions that the keyboard buffer is always full
# with no keyboard attached...
+#
+# If %dl is nonzero on entry, terminate with ZF=0 if A20 becomes alive,
+# otherwise terminate with ZF=1.
empty_8042:
pushl %ecx
- movl $0x00FFFFFF, %ecx
+ movl $0x000FFFFF, %ecx
empty_8042_loop:
decl %ecx
- jz empty_8042_end_loop
+ jz empty_8042_end_loop # ZF=1
+
+ # Always call the test routine to keep delays constant
+ call a20_test
+ jz ignore_a20
+ and %dl,%dl
+ jnz empty_8042_end_loop # ZF=0
+ignore_a20:
call delay
@@ -847,10 +863,38 @@
no_output:
testb $2, %al # is input buffer full?
jnz empty_8042_loop # yes - loop
+ # ZF=1
+
empty_8042_end_loop:
popl %ecx
ret
+a20_test:
+ pushw %ax
+ pushw %cx
+ pushw %fs
+ pushw %gs
+ xorw %ax, %ax # segment 0x0000
+ movw %ax, %fs
+ decw %ax # segment 0xffff (HMA)
+ movw %ax, %gs
+ movw 0x100,%cx
+ movw %fs:(0x200),%ax # So we keep cycling...
+ pushw %ax # Be extra paranoid...
+a20_loop:
+ incw %ax # unused memory location <0xfff0
+ movw %ax, %fs:(0x200) # we use the "int 0x80" vector
+ cmpw %gs:(0x210), %ax # and its corresponding HMA addr
+ jnz a20_ret # if ZF not set A20 is functional
+ loop a20_loop
+a20_ret:
+ popw %fs:(0x200)
+ popw %gs
+ popw %fs
+ popw %cx
+ popw %ax
+ ret # if ZF set A20 is not operational
+
# Read the cmos clock. Return the seconds in al
gettime:
pushw %cx
@@ -867,7 +911,8 @@
# Delay is needed after doing I/O
delay:
- jmp .+2 # jmp $+2
+ outb %al,$0x80 # What the main kernel uses
+ outb %al,$0x80
ret
# Descriptor tables
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
> This doesn't really work. Neither the fast A20 gate nor the KBC is
> guaranteed to have immediate effect (on most systems they won't.)
Fast A20 gate happens to be immediate on all the embedded kit I know so its
probably acceptable, and if its too slow it still does the kbc timeout. Since
its generally on chip they dont muck about talking to keyboard and other junk
I/O controllers.
Followup to: <[email protected]>
By author: Alan Cox <[email protected]>
In newsgroup: linux.dev.kernel
>
> > This doesn't really work. Neither the fast A20 gate nor the KBC is
> > guaranteed to have immediate effect (on most systems they won't.)
>
> Fast A20 gate happens to be immediate on all the embedded kit I know so its
> probably acceptable, and if its too slow it still does the kbc timeout. Since
> its generally on chip they dont muck about talking to keyboard and other junk
> I/O controllers.
>
I'd rather do it "right", which is to poll for A20 in the same loop as
we wait for the KBC to become available.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt