[syslinux] re: Problem with FreeDOS + himem64 + PXELINUX + memdisk

[H. Peter Anvin]

Eric Auer wrote:
> Hi Pat, your patches and/or MEMDISK have the problem that they do
> not DETECT which A20 setting styles work and which not!
> 
> - PS/2: port 92h -> or 2 to enable, and ~2 to disable A20
> - 8042: command d1 / port 60 ... here, too, ONLY bit 1 should be messed
>   with (or 2 / and ~2). It is important to do "wait until 8042 is ready"
>   and "wait until A20 actually switched". 8042 is slow!
> - BIOS: your BIOS call may or may not function, depending on the BIOS.
> 
> So you should try PS/2 first. If this does not work, try BIOS. Finally,
> try 8042. Then keep using only the "tested and working" access method.
> Some hardware has the A20 stuck to enabled, should not be a problem. Just
> display a warning. Sometimes BIOS CMOS setup has a menu entry to switch
> between PS/2 and 8042 style support. You could tell the user about that if
> you detect that only slow 8042 access works.

Okay, this is definitely not advisable.  The Linux kernel as well as
SYSLINUX/MEMDISK use the algorithm Pat described (although his patches
might not have) because it has been tested.

Note: it only tries all methods on the first attempt.

> Finally, MEMDISK hooks int 15.87? HIMEM does, too. But the HIMEM hook only
> helps programs which are loaded AFTER HIMEM. Interesting. So the MEMDISK
> hook more or less has to help HIMEM ;-).

MEMDISK hooks INT 15h, but only to reserve memory.  It *calls* INT 15h,
AH=87h to copy disk.  MEMDISK never frobs A20 itself except for at
initial installation time.

> And I do think that this is a SYSLINUX problem, so CCing them.
> 
> Both MEMDISK (part of SYSLINUX package) and FreeDOS XMS drivers should
> be careful and select a fast and working A20 switching method. Retrying
> 255 times is not that good. Better try only once and allow for some
> waiting until it switches. Even after initial checks, the driver should
> always WAIT until the 8042 (if used) is really ready and WAIT until the
> A20 state really changed.

Better yet: the XMS drivers should pick a method and install handlers
for INT 15h, AX=2400/2401h assuming that the BIOS didn't have them already.

> I read in RBIL 61 ports.txt that on some systems the A20 gate is
> gate enabled = PS/2 gate enabled "or" 8042 gate enabled,
> but this depends on your CMOS setup and on your hardware. Some setup
> values can mean "only use PS/2 gate setting" or "only use 8042 gate setting"
> or even "keep A20 stuck to enabled" or even more weird things. It might be
> an idea to check if the logical connection is an OR if you find both PS/2
> and 8042 working: In that case you would want to DISABLE through 8042 and
> SWITCH through PS/2 later. If the connection is an AND... well, imagine
> yourself. If connection is AND and 8042 is on "disable A20", you can do
> anything with PS/2 without success. This is very UNLIKELY, but still. If
> the connection is OR and 8042 is left on "enable A20", you cannot turn
> A20 off through PS/2... does not really hurt (A20 stuck to enabled does not
> really hurt at all in most cases). But of course there is this stupid MS
> EXEPACK software which needs A20 off if you try to load a file without
> LOADFIX (which moves the load segment beyond the first 64k)... I think
> EXEPACK is the only software which ever needed a "disable-able" A20 :-(.
> 
> Confusing topic maybe, but definitely needs to be handled with care, so
> better do more checks than less. Luckily most of the checking code does
> not have to stay in RAM after initialization.

It's worse than that.  As I described earlier, on some systems port 92h
has completely unrelated effects.  This is why Linux and SYSLINUX probe
the KBC first.

	-hpa