RE: The latest instance in the A20 farce

RE: The latest instance in the A20 farce

[Dunlap, Randy]

> From: H. Peter Anvin [mailto:hpa@transmeta.com]
> Sent: Wednesday, January 10, 2001 4:10 PM
> 
> "Dunlap, Randy" wrote:
> > 
> > a. The BIOS isn't required to have int. 0x15, AH=0x2401 [Appx. A],
> >    but that is handled by your patch.
> 
> Idiots.  This should be required and be a null function; likewise
> AH=0x2400.  The only thing that the current spec means is that 
> 
> > b. The BIOS isn't required to have int. 0x15, AH=0x88 [Appx. A]
> >    (Ye Olde Traditional memory-size function).
> 
> Incorrect; see page 226.

Right.  Somehow I looked at that and didn't see it.

> >    Hopefully the other memory-size methods will always have
> >    priority.
> > c. A20M# is always de-asserted at the processor [Ch. 3, 
> item SYS-0047]
> > 
> > I bring these up because they may have some impact on SYSLINUX,
> > LILO, etc., and the data structures that they use (like the
> > memory_size item) and because some of these systems don't
> > have a "real mode," so loaders can't reliably assume that
> > they do (unless it's transparent to the loaders)...
> > and because you know something about SYSLINUX etc.
> > 
> 
> URRRK.  I get a feeling these specs are either there to make 
> life extra difficult for programmers,
> because the people that design them are too
> stupid to tie their own shoes, or because they want nothing but M$
> factory-installed to work.
> 
> A20M# always deasserted: this is all fine and good if we had 
> nothing else
> to worry about, but they really have managed to fuck up when 
> it comes to
> getting something to work *ACROSS THE BOARD*.  THEY DON'T 
> GIVE ME A WAY
> TO DETECT THE FACT THAT A20M# IS FIXED!!!!!  This is 
> particularly nasty
> when going back to real mode, since I don't have a way to 
> figure out that I can't turn A20M# back to its old state.  

I'm not sure about this, but I'm wondering if the
Fixed (as in Static) ACPI Description Table (FADT)
can indicate that the platform is a legacy-free system.

According to the ACPI 2.0 spec, FADT field "Boot Architecture
Flags", bit 0 (LEGACY_DEVICES) indicates whether there are
legacy devices (user-visible) on the system.  I'm not sure
that this is adequate/equivalent.  I'll continue to check into it.
Even if it is adequate/equiv, it's not pretty.

> I also really, really, *REALLY* hate them for killing serial 
> ports.  It's a Bad Idea[TM].

Got the Message.

> Worse, they define that port 92h, bit 1, is no longer 
> A20M#... but they
> don't forbid the system from using it for other things.

I don't quite see it that way.  Where do you see that?
Maybe it just needs to be more explicit.

Ch. 3 (SYS-0047) says that port 92h:bit 1 doesn't toggle/affect A20M#.
Appendix A says that port 92h is (still?) "System Control Port A"
(not defined here AFAIK).
(I haven't checked all of the other chapters/appendices.)

> 	-hpa
> -- 
> <hpa@transmeta.com> at work, <hpa@zytor.com> in private!

~Randy
_______________________________________________
|randy.dunlap_at_intel.com        503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
-----------------------------------------------

-
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: The latest instance in the A20 farce

[H. Peter Anvin]

"Dunlap, Randy" wrote:
> 
> I'm not sure about this, but I'm wondering if the
> Fixed (as in Static) ACPI Description Table (FADT)
> can indicate that the platform is a legacy-free system.
> 

Parsing ACPI is a nightmare on steroids.  That is just Not An Option[TM]
in a < 10K bootstrap routine.

> 
> > Worse, they define that port 92h, bit 1, is no longer
> > A20M#... but they
> > don't forbid the system from using it for other things.
> 
> I don't quite see it that way.  Where do you see that?
> Maybe it just needs to be more explicit.
> 

It probably was *intended*, but it isn't *specified*, and in fact some
manufacturers have been known to abuse this bit.

> Ch. 3 (SYS-0047) says that port 92h:bit 1 doesn't toggle/affect A20M#.
> Appendix A says that port 92h is (still?) "System Control Port A"
> (not defined here AFAIK).
> (I haven't checked all of the other chapters/appendices.)
> 

-- 
<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: The latest instance in the A20 farce

[Gerhard Mack]

On Mon, 15 Jan 2001, H. Peter Anvin wrote:

> "Albert D. Cahalan" wrote:
> > 
> > It looks like we let Microsoft fill the design guide void.
> > If you were to write "PC DESIGN GUIDE - For the Linux Operating
> > System" and a pile of test code, then there would be an
> > alternative to point people at.
> > 
> > Complaining is pretty useless.
> 
> I was thinking about this today.  If we write a Linux design guide, even
> as a delta spec, does anyone think it will be listed to?

I imagine linux has enough market share to get at least some of them to
listen to such a spec.
For better results you might see if the *bsd people would want to
collaberate on an open standard.

	Gerhard
 



--
Gerhard Mack

gmack@innerfire.net

<>< As a computer I find your faith in technology amusing.

-
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: The latest instance in the A20 farce

[H. Peter Anvin]

"Albert D. Cahalan" wrote:
> 
> It looks like we let Microsoft fill the design guide void.
> If you were to write "PC DESIGN GUIDE - For the Linux Operating
> System" and a pile of test code, then there would be an
> alternative to point people at.
> 
> Complaining is pretty useless.

I was thinking about this today.  If we write a Linux design guide, even
as a delta spec, does anyone think it will be listed to?

	-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: The latest instance in the A20 farce

[Albert D. Cahalan]

H. Peter Anvin writes:
> "Maciej W. Rozycki" wrote:
>> On Wed, 10 Jan 2001, H. Peter Anvin wrote:

>>> URRRK.  I get a feeling these specs are either there to make life extra
>>> difficult for programmers, because the people that design them are too
>>> stupid to tie their own shoes, or because they want nothing but M$
>>> factory-installed to work.
>>
>> The page is titled "PC DESIGN GUIDE - For the Microsoft Windows
>> Family of Operating Systems," so what do you expect?
> 
> Kind of says it all, doesn't it?

It looks like we let Microsoft fill the design guide void.
If you were to write "PC DESIGN GUIDE - For the Linux Operating
System" and a pile of test code, then there would be an
alternative to point people at.

Complaining is pretty useless.

-
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: The latest instance in the A20 farce

[H. Peter Anvin]

"Maciej W. Rozycki" wrote:
> 
> On Wed, 10 Jan 2001, H. Peter Anvin wrote:
> 
> > URRRK.  I get a feeling these specs are either there to make life extra
> > difficult for programmers, because the people that design them are too
> > stupid to tie their own shoes, or because they want nothing but M$
> > factory-installed to work.
> 
>  The page is titled "PC DESIGN GUIDE - For the Microsoft Windows Family of
> Operating Systems," so what do you expect?
> 

Kind of says it all, doesn't it?

	-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: The latest instance in the A20 farce

[Maciej W. Rozycki]

On Wed, 10 Jan 2001, H. Peter Anvin wrote:

> URRRK.  I get a feeling these specs are either there to make life extra
> difficult for programmers, because the people that design them are too
> stupid to tie their own shoes, or because they want nothing but M$
> factory-installed to work.  

 The page is titled "PC DESIGN GUIDE - For the Microsoft Windows Family of
Operating Systems," so what do you expect? 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

-
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: The latest instance in the A20 farce

[Olaf Titz]

> I also really, really, *REALLY* hate them for killing serial ports.  It's
> a Bad Idea[TM].

Why, it opens up the market for serial-ports-on-USB devices. HW
manufactures can make significantly more money on that than on $7.95
ISA multi I/O cards[1] ;-)

Olaf

[1] and I still dislike those, because they are only useful with lots
and lots of jumpers for which you always can't find the description...
but RS232 ports _are_ necessary in the real world, and more often than
you like you need more than 2 of them.
-
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: The latest instance in the A20 farce

[H. Peter Anvin]

"Dunlap, Randy" wrote:
> 
> a. The BIOS isn't required to have int. 0x15, AH=0x2401 [Appx. A],
>    but that is handled by your patch.

Idiots.  This should be required and be a null function; likewise
AH=0x2400.  The only thing that the current spec means is that 

> b. The BIOS isn't required to have int. 0x15, AH=0x88 [Appx. A]
>    (Ye Olde Traditional memory-size function).

Incorrect; see page 226.

>    Hopefully the other memory-size methods will always have
>    priority.
> c. A20M# is always de-asserted at the processor [Ch. 3, item SYS-0047]
> 
> I bring these up because they may have some impact on SYSLINUX,
> LILO, etc., and the data structures that they use (like the
> memory_size item) and because some of these systems don't
> have a "real mode," so loaders can't reliably assume that
> they do (unless it's transparent to the loaders)...
> and because you know something about SYSLINUX etc.
> 

URRRK.  I get a feeling these specs are either there to make life extra
difficult for programmers, because the people that design them are too
stupid to tie their own shoes, or because they want nothing but M$
factory-installed to work.  

A20M# always deasserted: this is all fine and good if we had nothing else
to worry about, but they really have managed to fuck up when it comes to
getting something to work *ACROSS THE BOARD*.  THEY DON'T GIVE ME A WAY
TO DETECT THE FACT THAT A20M# IS FIXED!!!!!  This is particularly nasty
when going back to real mode, since I don't have a way to figure out that
I can't turn A20M# back to its old state.  

I also really, really, *REALLY* hate them for killing serial ports.  It's
a Bad Idea[TM].

Worse, they define that port 92h, bit 1, is no longer A20M#... but they
don't forbid the system from using it for other things.

	-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: The latest instance in the A20 farce

[Dunlap, Randy]

hpa-

I tested this patch on a Pentium dual-proc system (440GX)
and on a Celeron system[1] (810) that lacks floppy, keyboard
controller, maybe some other things.

Linux 2.4.0 boots fine on each of these systems with this
patch applied.  I couldn't tell which method of
enabling A20 was actually successful.
Have you had any other reports on the patch?


[1] I'm not sure if this system qualifies as "legacy free"
or "legacy reduced."  However, for future (how far?)
reference, on legacy-free systems:
[from PDF file at http://www.pcdesguide.org/pc2001/default.htm]

a. The BIOS isn't required to have int. 0x15, AH=0x2401 [Appx. A],
   but that is handled by your patch.
b. The BIOS isn't required to have int. 0x15, AH=0x88 [Appx. A]
   (Ye Olde Traditional memory-size function).
   Hopefully the other memory-size methods will always have
   priority.
c. A20M# is always de-asserted at the processor [Ch. 3, item SYS-0047]

I bring these up because they may have some impact on SYSLINUX,
LILO, etc., and the data structures that they use (like the
memory_size item) and because some of these systems don't
have a "real mode," so loaders can't reliably assume that
they do (unless it's transparent to the loaders)...
and because you know something about SYSLINUX etc.

~Randy
_______________________________________________
|randy.dunlap_at_intel.com        503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
-----------------------------------------------

> From: H. Peter Anvin [mailto:hpa@zytor.com]
> Sent: Wednesday, December 06, 2000 3:55 PM
> 
> Okay, here is yet another A20 patch (against test12-pre6) this time
> for people to try out.  This patch uses the following algorithm for
> enabling A20:
> 
> 1. Try the BIOS call.  If it works, we're cool.
> 2. Try the KBC (using Linus' lowered timeouts.)
> 3. If the KBC doesn't work, or is very slow, flip port 92.
> 
> After 3 it sits into the same infinite loop waiting for A20 to become
> enabled (necessary on for example some Toshiba notebooks which have an
> extremely slow response to A20.)
> 
> The main differences between this patch and test12-pre6:
> 
> - Trying the BIOS first of all.  This should reduce the risk of the
>   BIOS getting confused while doing a suspend.  This also gives even
>   less of an excuse for any nonstandard arrangement -- if you didn't
>   implement the standard KBC *and* you didn't provide the BIOS call,
>   you have a seriously broken piece of hardware.
> 
> - If the KBC responds quickly enough (within about 10000 cycles), we
>   don't ever touch the fast A20 gate.  This is a difference from
>   previous code, where the fast A20 gate was toggled immediately after
>   the KBC, even if the KBC responded instantly.
> 
> - I had to move the A20 code somewhat earlier in setup.S in order for
>   the BIOS to still be available.
> 
> Please try it out and let me know as soon as possible...
> 
> 	-hpa
> 
> 
> --- arch/i386/boot/setup.S.12p6	Wed Dec  6 12:49:07 2000
> +++ arch/i386/boot/setup.S	Wed Dec  6 15:25:01 2000
...
> -- 
> <hpa@transmeta.com> at work, <hpa@zytor.com> in private!

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

The latest instance in the A20 farce

[H. Peter Anvin]

Okay, here is yet another A20 patch (against test12-pre6) this time
for people to try out.  This patch uses the following algorithm for
enabling A20:

1. Try the BIOS call.  If it works, we're cool.
2. Try the KBC (using Linus' lowered timeouts.)
3. If the KBC doesn't work, or is very slow, flip port 92.

After 3 it sits into the same infinite loop waiting for A20 to become
enabled (necessary on for example some Toshiba notebooks which have an
extremely slow response to A20.)

The main differences between this patch and test12-pre6:

- Trying the BIOS first of all.  This should reduce the risk of the
  BIOS getting confused while doing a suspend.  This also gives even
  less of an excuse for any nonstandard arrangement -- if you didn't
  implement the standard KBC *and* you didn't provide the BIOS call,
  you have a seriously broken piece of hardware.

- If the KBC responds quickly enough (within about 10000 cycles), we
  don't ever touch the fast A20 gate.  This is a difference from
  previous code, where the fast A20 gate was toggled immediately after
  the KBC, even if the KBC responded instantly.

- I had to move the A20 code somewhat earlier in setup.S in order for
  the BIOS to still be available.

Please try it out and let me know as soon as possible...

	-hpa


--- arch/i386/boot/setup.S.12p6	Wed Dec  6 12:49:07 2000
+++ arch/i386/boot/setup.S	Wed Dec  6 15:25:01 2000
@@ -532,6 +532,70 @@
 	movl	%cs:code32_start, %eax
 	movl	%eax, %cs:code32
 
+# Make sure interrupts really are disabled here...
+	cli
+
+#
+# That was painless, now we enable A20, which definitely isn't.
+#
+# First, we try the BIOS (INT 15:2401).
+# Second, try the keyboard controller with a timeout.
+# Third, try the "fast A20 gate" manually.
+#
+# The "fast A20 gate" is dangerous to use manually, because of
+# system and BIOS bugs -- some manufacturers have used it as an
+# extra GPIO pin(!!!!) and some BIOSes fail to save/restore it
+# on Suspend/Wakeup.
+#
+	movw	$0x2401,%ax			# BIOS: Enable A20
+	stc
+	int	$0x15
+	jc	a20_no_bios			# CF=0 if success
+	testb	%ah,%ah				# AH=0 if success
+	jnz	a20_no_bios
+
+	# BIOS reported success, verify that it really did work
+	call	a20_test
+	jnz	a20_done
+
+a20_no_bios:					# Try the KBC next...
+	call	empty_8042
+
+	movb	$0xD1, %al			# command write
+	outb	%al, $0x64
+	call	empty_8042
+
+	movb	$0xDF, %al			# A20 on
+	outb	%al, $0x60
+	call	empty_8042
+#
+# If A20 is enabled here, don't touch port 92
+#
+	call	a20_test
+	jnz	a20_done
+	
+#
+# Either the KBC is really slow, or we need to use fast A20.  Flip
+# fast A20 and then sit in a loop and spin waiting for A20 to come alive.
+#
+# 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			# System Control Port A
+	orb	$02, %al			# Fast A20 enable
+	outb	%al, $0x92
+
+# 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.
+
+a20_wait:
+	call	a20_test
+	jz	a20_wait
+	
+a20_done:	# A20 verified enabled here
+
 # Now we move the system to its rightful place ... but we check if we have a
 # big-kernel. In that case we *must* not move it ...
 	testb	$LOADED_HIGH, %cs:loadflags
@@ -581,6 +645,7 @@
 # We also then need to move the params behind it (commandline)
 # Because we would overwrite the code on the current IP, we move
 # it in two steps, jumping high after the first one.
+
 	movw	%cs, %ax
 	cmpw	$SETUPSEG, %ax
 	je	end_move_self
@@ -621,6 +686,9 @@
 	movw	%ax, %ds
 	movw	%dx, %ss
 end_move_self:					# now we are at the right place
+
+# Set up IDT/GDT for protected-mode use.
+
 	lidt	idt_48				# load idt with 0,0
 	xorl	%eax, %eax			# Compute gdt_base
 	movw	%ds, %ax			# (Convert %ds:gdt to a linear ptr)
@@ -630,41 +698,6 @@
 	lgdt	gdt_48				# load gdt with whatever is
 						# appropriate
 
-# that was painless, now we enable a20
-	call	empty_8042
-
-	movb	$0xD1, %al			# command write
-	outb	%al, $0x64
-	call	empty_8042
-
-	movb	$0xDF, %al			# A20 on
-	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.
-
-	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
-
 # make sure any possible coprocessor is properly reset..
 	xorw	%ax, %ax
 	outb	%al, $0xf0
@@ -859,6 +892,36 @@
 	popl	%ecx
 	ret
 
+# Wait for the A20 gate to become enabled.  Time out reasonably quickly;
+# return with ZF=0 is A20 now live; ZF=1 if A20 still masked.
+# The test location, memory address 0x200, is the INT 0x80 vector which
+# should be safe to use.
+
+a20_test:
+	pushw	%fs
+	pushw	%gs
+	pushw	%ax
+	pushw	%cx
+	xorw	%ax,%ax				# Low 64K
+	movw	%ax,%fs
+	decw	%ax				# HMA = segment 0xFFFF
+	movw	%ax,%gs
+	movw	%fs:(0x200),%ax
+	pushw	%ax				# Paranoia
+	movw	$0x1000,%cx			# Loop counter
+a20_loop:
+	incw	%ax
+	movw	%ax,%fs:(0x200)
+	cmpw	%ax,%gs:(0x210)			# Aliased?
+	loope	a20_loop			# If so, continue
+	# ZF=0 if no alias, ZF=1 if timeout
+	popw	%fs:(0x200)
+	popw	%cx
+	popw	%ax
+	popw	%gs
+	popw	%fs
+	ret
+	
 # Read the cmos clock. Return the seconds in al
 gettime:
 	pushw	%cx
-- 
<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/