RE: The latest instance in the A20 farce

[Dunlap, Randy]

> From: H. Peter Anvin [mailto:[e-mail]]
> 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
> -- 
> <[e-mail]> at work, <[e-mail]> 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.|
-----------------------------------------------