> From: H. Peter Anvin [mailto:[EMAIL PROTECTED]]
> 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
> --
> <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
