setup.S: A20 enable sequence (once again)

setup.S: A20 enable sequence (once again)

[Robert Kaiser]

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: 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/

Re: setup.S: A20 enable sequence (once again)

[H. Peter Anvin]

Followup to:  <00110618083400.11022@rob>
By author:    Robert Kaiser <rob@sysgo.de>
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

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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/

Re: setup.S: A20 enable sequence (once again)

[H. Peter Anvin]

Followup to:  <00110618083400.11022@rob>
By author:    Robert Kaiser <rob@sysgo.de>
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
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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/

Re: setup.S: A20 enable sequence (once again)

[Alan Cox]

> 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.



-
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/

Re: setup.S: A20 enable sequence (once again)

[H. Peter Anvin]

Followup to:  <E13stqG-0006eJ-00@the-village.bc.nu>
By author:    Alan Cox <alan@lxorguk.ukuu.org.uk>
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

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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/

Re: setup.S: A20 enable sequence (once again)

[H. Peter Anvin]

Followup to:  <00110621255000.12156@rob>
By author:    Robert Kaiser <rob@sysgo.de>
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
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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/

Re: setup.S: A20 enable sequence (once again)

[Robert Kaiser]

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: 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/

Re: setup.S: A20 enable sequence (once again)

[H. Peter Anvin]

Followup to:  <00110620483000.11673@rob>
By author:    Robert Kaiser <rob@sysgo.de>
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
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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/

Re: setup.S: A20 enable sequence (once again)

[Robert Kaiser]

> 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: 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/