Is it OK to enable A20 AFTER moving to protected mode?
James Harris
mode but considering the work required to enable it - at least for the
keyboard (0x60, 0x64) and system (0x92) options - I can't see a reason
not to change it once in protected mode.
As long as the memory restrictions are honoured does anyone know a
reason not to wait until protected mode is running? Has anyone tried
it?
James
Alexei A. Frounze
I think it should work just fine in protected mode. I can't see any
statements in the docs on #a20m not working in protected mode.
Alex
Rod Pemberton
news:5345c6b6-9de9-49b6...@m25g2000yqc.googlegroups.com...
No. Yes. (Some time separates those two answers...)
Honoring memory restrictions is probably a good reason not to, at least for
the large kernels OSes are creating today.
> Has anyone tried
> it?
Enabling A20 once in protected mode? No.
Even if technically feasible, enabling A20 reliably seems to be
problematic - even for real mode... I.e., why introduce more problems into
the equation? Supposedly, DOS had seventeen or more methods to enable A20
on various machines.
Technically, it should work. Well, I thought it should work - just prior to
looking at the cpu datasheets...
1) One 486 datasheet explicitly says A20 "should be [disabled] only when the
processor is in Real Mode". (I.e., do not disable A20 while in protected
mode ... ?)
2) Another 486 datasheet says A20 state is recognized in SMM. This is
contrary to expected behavior in Note #1 on sandpile.org (below).
3) The Intel Pentium datasheet says the effect of A20 "is undefined in
protected mode" and that it should be enabled.
If the others aren't bad news, I'd say #3 is bad news...
> Has anyone tried
> it?
Ben Lunt probably came closest. Ben Lunt tried it for "unreal" mode. His
FYSOS was enabling A20 in "unreal" mode. It worked on all the machines he
tried. But, it wasn't liked by an old 233MHz machine of mine. His solution
was to enable A20 in real mode. I don't think we ever found out what the
problem with enabling A20 in "unreal" mode was.
The 233Mhz machine would only enable via keyboard ("AT method") controller
and was very finicky about the code sequence. There also seems to be a
"block-out" delay, or perhaps just slowness on that machine, if one enables
and disables A20, you can't re-enable it for a few seconds.
On an AMD K6-2 500 MHz machine, if I enabled A20 via port 92h, I had to
disable via port 92h. I don't recall how I stumbled across this, but I
probably tried to enable via 92h and tried to disable via keyboard
controller. That could cause problems for someone who thought they disabled
A20 via keyboard controller... (if 92h turned it on). If you look at the
chart for A20M# in the link below, you can "see" this "override" effect for
port 92h vs. keyboard controller.
Also, this Note #1 on A20 may be of interest.
http://www.sandpile.org/ia32/legacy.htm
IIRC, one of the UHCI documents has it's own A20 enable sequence. I forgot
who pointed that out to me. Anyway, it doesn't wait to send DFh to port
60h. It has a read from 64h, like a wait to send, but out of order and
without waiting. And, it sends an unknown value to 64h also. Wierd...
Rod Pemberton
Alexei A. Frounze
> "James Harris" <james.harri...@googlemail.com> wrote in message
>
> IIRC, one of the UHCI documents has it's own A20 enable sequence. I forgot
> who pointed that out to me. Anyway, it doesn't wait to send DFh to port
> 60h. It has a read from 64h, like a wait to send, but out of order and
> without waiting. And, it sends an unknown value to 64h also. Wierd...
>
> Rod Pemberton
Was it somewhere here?:
http://groups.google.com/group/alt.os.assembly/browse_thread/thread/1d7019aea4f73a19/3597c63acce159a2?lnk=raot
Alex
Rod Pemberton
news:9b96f039-bc23-4317...@d20g2000yqh.googlegroups.com...
> > IIRC, one of the UHCI documents has it's own A20 enable sequence. I
forgot
> > who pointed that out to me. Anyway, it doesn't wait to send DFh to port
> > 60h. It has a read from 64h, like a wait to send, but out of order and
> > without waiting. And, it sends an unknown value to 64h also. Wierd...
> >
>
> [link]
Oh. I guess I found it.
By "it," you mean A20 sequence for UHCI?
It's called A20PTEN or A20Gate Pass Through Enable. It's in the Intel
datasheets for 82340FX, PIIX and PIIX3, and 460GX motherboard chipsets, and
also in Intel UHCI Design Guide (UHCI11D.pdf) . AIUI, if a bit is enabled
in the chipset, the A20 gate sequence is passed through to the keyboard
controller - instead of being handled by the chipset. However, the sequence
or ordering of instructions that it allows to pass through is wrong from my
experiences. I.e., certain keyboards might not recognize the sequence.
Rod Pemberton
Rod Pemberton
news:hhpmhi$apu$1...@speranza.aioe.org...
> > Technically, it should work. Well, I thought it should work - just
prior to
> > looking at the cpu datasheets...
> >
> > 1) One 486 datasheet explicitly says A20 "should be [disabled] only when
the
> > processor is in Real Mode". (I.e., do not disable A20 while in
protected
> > mode ... ?)
> >
> > 2) Another 486 datasheet says A20 state is recognized in SMM. This is
> > contrary to expected behavior in Note #1 on sandpile.org (below).
> >
> > 3) The Intel Pentium datasheet says the effect of A20 "is undefined in
> > protected mode" and that it should be enabled.
> >
> > If the others aren't bad news, I'd say #3 is bad news...
From the AMD K6-2 datasheet:
a) "The assertion of A20M# in System Management Mode (SMM) is ignored."
b) "When A20M# is sampled asserted in Protected mode, it causes
unpredictable processor operation. A20M# is only defined in Real mode."
c) "To ensure A20M# is recognized before the execution of an instruction, a
serializing instruction must be executed between the instruction that
asserts A20M# and the targeted instruction."
----
So, one cpu does and one doesn't recognize A20 in SMM... But, a serializing
instruction is needed to ensure A20 is disabled in/for RM... !?!? Did read
that correctly?
RP
wolfgang kern
James Harris asked:
My reason is just that my code starts in the 2nd MB (aka HMA FFFF:0010h...)
> Has anyone tried it?
Yes I tried, before I found the HMA as a better startup place, :)
but this didn't do any good, because entering proteced means also
setup of segment-registers.
So A20_on could work right after altering CR0...jmpfar PM:16 (unchecked).
before someone ask why I see HMA as a better place:
* larger contigous memory range starts here
* PM/RM-linker can reside there
* keeps the low 640K for another dumb OS ie: DOS_6.00 as a 'real' box.
__
wolfgang
James Harris
...
> Even if technically feasible, enabling A20 reliably seems to be
> problematic - even for real mode... I.e., why introduce more problems into
> the equation? Supposedly, DOS had seventeen or more methods to enable A20
> on various machines.
I read that somewhere recently though I gather some of the 17 were
only timing differences. The only methods I am aware of are
* the BIOS - though I'd be wary of RBIL's comment on int 0x15-2401
that it can fail because "keyboard controller is in secure mode." If
that fails where can we go next?
* ports 0x64 and 0x60 - whether real or emulated
* port 0x92 - whether real or emulated.
The query started in part because of wondering how USB keyboards would
be supported - i.e as keyboards not as places to change the A20 mask.
>
> Technically, it should work. Well, I thought it should work - just prior to
> looking at the cpu datasheets...
>
> 1) One 486 datasheet explicitly says A20 "should be [disabled] only when the
> processor is in Real Mode". (I.e., do not disable A20 while in protected
> mode ... ?)
>
> 2) Another 486 datasheet says A20 state is recognized in SMM. This is
> contrary to expected behavior in Note #1 on sandpile.org (below).
>
> 3) The Intel Pentium datasheet says the effect of A20 "is undefined in
> protected mode" and that it should be enabled.
>
> If the others aren't bad news, I'd say #3 is bad news...
Um, yes. I wonder if they mean "undefined" as any of
* CPU could halt and catch fire
* actions are known but could vary between implementations
* implementations will misbehave strangely in certain circumstances
that are so unusual we don't see a need to define them. After all, who
in his right mind would run protected mode with A20 disabled?
I suspect code running code or accessing data near the end of a
megabyte could cause speculative fetches into the adjacent megabyte.
These could cause trouble.
...
> Ben Lunt probably came closest. Ben Lunt tried it for "unreal" mode.
...
> But, it wasn't liked by an old 233MHz machine of mine. His solution
> was to enable A20 in real mode. I don't think we ever found out what the
> problem with enabling A20 in "unreal" mode was.
>
> The 233Mhz machine would only enable via keyboard ("AT method") controller
> and was very finicky about the code sequence. There also seems to be a
> "block-out" delay, or perhaps just slowness on that machine, if one enables
> and disables A20, you can't re-enable it for a few seconds.
>
> On an AMD K6-2 500 MHz machine, if I enabled A20 via port 92h, I had to
> disable via port 92h. I don't recall how I stumbled across this, but I
> probably tried to enable via 92h and tried to disable via keyboard
> controller. That could cause problems for someone who thought they disabled
> A20 via keyboard controller... (if 92h turned it on).
AIUI either can turn it on and BOTH need to have A20 turned off for it
to be off. That may not be right, of course, or may apply only to some
systems.
> If you look at the
> chart for A20M# in the link below, you can "see" this "override" effect for
> port 92h vs. keyboard controller.
The chart is copied below. Not sure I understand it. It seems to be
saying that either 0x60/0x64 or 0x92 need to be set to allow flat
memory access - i.e. with A20 enabled.
KBC PS/2 A20M#
L 0 wrap L 0 pass L wrap #1
H 1 flat L 0 pass H flat #2
L 0 wrap H 1 flat H flat #3
H 1 flat H 1 flat H flat #3
#1 Ideally the processor should honour A20M#
even when it is not in real mode, but it should
ignore A20M# when it is in SMM. However,
some processors don't implement it that way.
#2 This is the default state after RESET, which
gives (historical) precedence to the KBC.
#3 The PS/2 state after INIT is chipset-specific.
Older chipsets (eg. PIIX) leave it unchanged.
Newer chipsets (eg. ICH) set it to flat.
>
> Also, this Note #1 on A20 may be of interest. http://www.sandpile.org/ia32/legacy.htm
It is. And it seems to go against the "undefined" definition from the
CPU makers. Of course, they should know best but as mentioned above
they may be hedging their bets.
> IIRC, one of the UHCI documents has it's own A20 enable sequence. I forgot
> who pointed that out to me. Anyway, it doesn't wait to send DFh to port
> 60h. It has a read from 64h, like a wait to send, but out of order and
> without waiting. And, it sends an unknown value to 64h also. Wierd...
You mean
out 0x64, 0xD1 (with or without waiting)
out 0x60, 0xDF (without waiting)
in 0x64
That is weird. Surely that's not the only way on UHCI.
I found an older useful thread on the topic
http://groups.google.co.uk/group/alt.lang.asm/browse_frm/thread/1d7019aea4f73a19
James
James Harris
> > "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote in message
It does look like it is needed when entering masked mode - possibly to
ensure that memory accesses by/for the next instruction are made with
the bit as intended.
Here's a quote that I think you referred to in the prior thread
mentioned above. It is for a device without PS/2 ports showing, I
think, what the USB system expects in order to emulate the A20 control
in the imaginary keyboard controller. Notably it seems to use system
management mode to deal with the logic. I wasn't aware SMM could be
used that way.
This is from the AMD Geode support doc 33238G_cs5536_db.pdf. KEL is
keyboard emulation.
The A20 sequence is initiated with a write of D1h to I/O
Address 064h. On detecting this write, the KEL sets the
A20Sequence bit (KEL Memory Offset 100h[5]). It captures
the data byte (KEL Memory Offset 104h[7:0]), but does not
set the InputFull bit (KEL Memory Offset 10Ch[1]). When
the A20Sequence is set, a write of a value to I/O Address
060h, that has bit 1 set to a value different than A20State
(KEL Memory Offset 100h[8]), causes InputFull to be set
and causes an ASMI. An ASMI with both InputFull and
A20Sequence set, indicates that the application is trying to
change the setting of FA20 on the keyboard controller.
However, when A20Sequence is set, and a write of a value
to I/O Address 060h that has bit 1 set to the same value as
A20State is detected, then no ASMI will occur.
As mentioned above, a write to I/O Address 064h of any
value other than D1h causes A20Sequence to be cleared.
If A20Sequence is active and a value of FFh is written to
I/O Address 064h, A20Sequence is cleared but InputFull is
not set. A write of any value other than D1h or FFh causes
InputFull to be set, which then causes an ASMI. A write of
FFh to I/O Address 064h when A20Sequence is not set
causes InputFull to be set. The current value of the
A20_Mask is maintained in two unconnected places: the
A20State bit (KEL Memory Offset 100h[8]) in Port A and
the value of A20State is only changed via a software write
to KEL_HCE_CTRL. It is set to 0 at reset. The value of bit 1
in Port A changes on any write to Port A. From reset,
PortA[1] is 1.
It may not win awards for brevity and clarity but it does show the
sequence this chipset and SMM software expect.
James
James Harris
...
> > IIRC, one of the UHCI documents has it's own A20 enable sequence. I forgot
> > who pointed that out to me. Anyway, it doesn't wait to send DFh to port
> > 60h. It has a read from 64h, like a wait to send, but out of order and
> > without waiting. And, it sends an unknown value to 64h also. Wierd...
...
> http://groups.google.co.uk/group/alt.lang.asm/browse_frm/thread/1d701...
Here is the A20 code referred to by HPA at the top of that thread as
being freely usable without licence restrictions.
http://git.etherboot.org/?p=wraplinux.git;a=blob;f=reloc/a20.S
It includes the null command which is apparently required by the UHCI
spec.
Is this code definitive? I guess it's widely used successfully so it
could be.
However, from the point of view of being more informative I think I
would prefer to
1. avoid the BIOS (in case of bugs)
2. generate log entries as to which options were being tried, the
results of attempts and how long they took
3. try to confirm the presence of a keyboard controller before writing
it too much - by issuing a self-test 0xAA or loopback 0xD2. I know
these are extra writes but they are at least informative.
4. read 0x92 first to see if the A20 bit is already as required
5. not loop continually but stop and say why after a decent period
6. not write to port 0x80 as it clobbers any BIOS post codes sent
there
7. query the empty_8042 routine - this is a separate issue.
The reason for the tests on points 3 and 4 is to guard against making
changes to another device at the address(es) BUT I guess I'd have to
retract the tests if it turns out that emulations ("simulations"?) are
confused by them.
It was a desire to verify the presence of a keyboard controller before
proceeding and the slowness of the keyboard controller reported on
some Toshiba laptops that prompted me to query whether A20 could be
enabled after multitasking was running (in protected mode). The idea
was to make enabling A20 part of the physical memory manager and get a
bunch of other initialisation work done while waiting for A20 to be
enabled.
James
Rod Pemberton
> Here is the A20 code referred to by HPA at the top of that thread as
> being freely usable without licence restrictions.
>
> http://git.etherboot.org/?p=wraplinux.git;a=blob;f=reloc/a20.S
>
> It includes the null command which is apparently required by the UHCI
> spec.
>
> Is this code definitive? I guess it's widely used successfully so it
> could be.
I'd suspect their sequence breaks the A20PTEN sequence... They are doing
in's against both 0x60 and 0x64 instead of just 0x64. And, they are doing
them between initial writes, i.e., in empty_8042. If I read the A20PTEN
sequence correct, they should only have on empty_8042 prior to the 0xFF
emit. But, I doubt that hardly anyone has ever enabled the chipset bit
necessary to get A20PTEN to work. (IIRC, HPA might have.)
> 1. avoid the BIOS (in case of bugs)
That's my opinion, but (IIRC) HPA once said that the BIOS was the most
reliable way to enable A20...
> 2. generate log entries as to which options were being tried, the
> results of attempts and how long they took
I once mentioned maybe someone should write a DOS app that tested all useful
BIOS functions and store the returned info in a file that could be use by
the OS upon loading.
> 3. try to confirm the presence of a keyboard controller before writing
> it too much - by issuing a self-test 0xAA or loopback 0xD2. I know
> these are extra writes but they are at least informative.
Yeah, I have a "no mouse present" detect in my OS, but not one for a
keyboard - although I left myself a note. The question, for me, is: How
often do you come across a PC without a keyboard? I know there is a device
to eliminate keyboards from dedicated PC's, but I suspect it has a keyboard
controller in it too. It's definately safer to check, but what would you do
if there was no keyboard? It wouldn't be useable, except perhaps remotely.
In which case, it'd probably have an Etherboot type of BIOS, wouldn't it?
> 4. read 0x92 first to see if the A20 bit is already as required
For enabling, 0x92 works just as well as keyboard. But, some of those old
posts or perhaps RBIL indicated there are a few machines (Olivetti...?) that
don't like one messing with 0x92.
> 6. not write to port 0x80 as it clobbers any BIOS post codes sent
> there
port 0x80... ? I'll have to look that up.
Rod Pemberton
Rod Pemberton
On 3 Jan, 09:02, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
>
> * the BIOS - though I'd be wary of RBIL's comment on int 0x15-2401
> that it can fail because "keyboard controller is in secure mode." If
> that fails where can we go next?
> * ports 0x64 and 0x60 - whether real or emulated
> * port 0x92 - whether real or emulated.
There are a few machines that have other odd or unique methods to enable
A20. I've got no plans to support them in my OS.
Also, my understanding is that the BIOS didn't always have the Int 0x15
function to enable A20. I don't know when they started implementing it.
> The query started in part because of wondering how USB keyboards would
> be supported - i.e as keyboards not as places to change the A20 mask.
Hmm, well, I don't know exactly.. This machine has legacy USB, and
apparently a bunch of hardware, perhaps BIOS and/or SMM, emulating IDE for
SATA, and emulating the keyboard controller for the USB keyboard, and
emulating PS/2 mouse for USB mouse, I guess - because that's the hardware
I've got... It works as if those devices actually are IDE, PS/2, and AT
keyboard - just like for my old machine. I'm not sure how one switches them
over to USB, SATA, and non-legacy operation. Someone could point out the
spec. to me if they know.
> > On an AMD K6-2 500 MHz machine, if I enabled A20 via port 92h, I had to
> > disable via port 92h. I don't recall how I stumbled across this, but I
> > probably tried to enable via 92h and tried to disable via keyboard
> > controller. That could cause problems for someone who thought they
> > disabled
> > A20 via keyboard controller... (if 92h turned it on).
>
> AIUI either can turn it on and BOTH need to have A20 turned off for it
> to be off. That may not be right, of course, or may apply only to some
> systems.
Correct.
> > If you look at the
> > chart for A20M# in the link below, you can "see" this "override" effect
> > for
> > port 92h vs. keyboard controller.
>
> The chart is copied below. Not sure I understand it. It seems to be
> saying that either 0x60/0x64 or 0x92 need to be set to allow flat
> memory access - i.e. with A20 enabled.
Yes. Wow, you really had me confused here for a few minutes...
If either can turn it on, then the one that turned it on should turn it off.
Let's start from the first line "a20 off" or "wrap", instead of the second
line which sandpile.org says is the default startup state. So, we'll be
enabling A20 from the off or wrap state. If we enable a20 by KBC, we go
from the first line to the second line. If we enable a20 by PS/2, we go
from the first line to the third line. The only way to get from either line
2 or 3 back to the first line is by disabling by the same method, yes?
That's what I saw. If we attempt to disable either from line 2 or 3 via the
opposite method, we remain on the same line. If we attempt to enable either
from line 2 or 3 via the opposite method, we end up at line 4. So, one must
disable both to ensure A20 is off or wrapped and one should disable by the
same method one enabled by. Phew...
> > IIRC, one of the UHCI documents has it's own A20 enable sequence. I
> > forgot
> > who pointed that out to me. Anyway, it doesn't wait to send DFh to port
> > 60h. It has a read from 64h, like a wait to send, but out of order and
> > without waiting. And, it sends an unknown value to 64h also. Wierd...
>
> You mean
>
> out 0x64, 0xD1 (with or without waiting)
> out 0x60, 0xDF (without waiting)
> in 0x64
out 0x64, 0xD1 (one or more, without waiting)
out 0x60, 0xDF (without waiting)
in 0x64 (zero or more, i.e., waiting)
out 0x64, 0xFF (without waiting)
> That is weird. Surely that's not the only way on UHCI.
To bypass the UHCI controller's handling of A20, one must set a bit in the
chipset. Then, that exact sequence will get passed to the keyboard
controller. I doubt anyone enables that bit. But, if one did and one
follows the exact sequence, I think a few keyboards will fail to accept the
sequence. If one does and one sends a better sequence, then the UHCI
controller rejects the pass through. This looks botched to me.
Rod Pemberton
James Harris
> "James Harris" <james.harri...@googlemail.com> wrote in message
>
> news:24eb068f-8d70-4b8c...@26g2000yqo.googlegroups.com...
>
> > Here is the A20 code referred to by HPA at the top of that thread as
> > being freely usable without licence restrictions.
>
> > http://git.etherboot.org/?p=wraplinux.git;a=blob;f=reloc/a20.S
>
> > It includes the null command which is apparently required by the UHCI
> > spec.
>
> > Is this code definitive? I guess it's widely used successfully so it
> > could be.
>
> I'd suspect their sequence breaks the A20PTEN sequence... They are doing
> in's against both 0x60 and 0x64 instead of just 0x64. And, they are doing
> them between initial writes, i.e., in empty_8042. If I read the A20PTEN
> sequence correct, they should only have on empty_8042 prior to the 0xFF
> emit. But, I doubt that hardly anyone has ever enabled the chipset bit
> necessary to get A20PTEN to work. (IIRC, HPA might have.)
Yeah, I need to read that empty_8042 routine again. It's not easy to
decipher. At first reading it seems to clear the 8042 in both
directions for some reason.
...
> > 3. try to confirm the presence of a keyboard controller before writing
> > it too much - by issuing a self-test 0xAA or loopback 0xD2. I know
> > these are extra writes but they are at least informative.
I must have had a brain hiccup. Rather than saying they were
informative I thought I'd said that the tests - and hence the extra
writes - needed to be done anyway. (They are not needed in absolute
terms but anything I can do to recognise and report a problem rather
than ignoring the it and muddling through is on my to-do list. So, for
me, these things have to be done - and are needed in that sense.)
> Yeah, I have a "no mouse present" detect in my OS, but not one for a
> keyboard - although I left myself a note. The question, for me, is: How
> often do you come across a PC without a keyboard? I know there is a device
> to eliminate keyboards from dedicated PC's, but I suspect it has a keyboard
> controller in it too. It's definately safer to check, but what would you do
> if there was no keyboard? It wouldn't be useable, except perhaps remotely.
> In which case, it'd probably have an Etherboot type of BIOS, wouldn't it?
The tests I mentioned, 0xAA and loopback 0xD2, are for the presence of
a keyboard *controller*, not for a keyboard. Only the controller is
needed to change the A20 gate. As far as I know the keyboard isn't
required for this.
Taking up your point about the keyboard, though, I'd like to support
servers which sit in a dark room with no keyboard, or mouse, or
monitor etc. This doesn't seem to be a problem as long as the BIOS can
be set to boot past any keyboard check and not sit waiting for the
user to press F1 or whatever.
That said, I'd have to deal with the vast majority of machine
configurations where a keyboard is required. The OS would have to
address a user inadvertently booting without a keyboard. The key (sic)
thing seems to be to allow a keyboard to be connected at any time
after boot. For a long time I puzzled over why a Unix box we used at
work would never recognise a keyboard being plugged in after it had
been booted. I now think it probably relied on the BIOS report of
attached devices and never checked again for a keyboard.
It shouldn't be a problem in an OS either to check for a keyboard
either periodically or on an otherwise unexpected IRQ1. So I think we
should always be able to configure and use a keyboard even if the
machine was booted without one. This would allow a user to plug in a
keyboard and take control at any time.
>
> > 4. read 0x92 first to see if the A20 bit is already as required
>
> For enabling, 0x92 works just as well as keyboard. But, some of those old
> posts or perhaps RBIL indicated there are a few machines (Olivetti...?) that
> don't like one messing with 0x92.
OK. I suppose I could use system port A at 0x92 first. It is faster
and simpler. My problem with it is that it's harder to be sure that
there is a system port A at 0x92 and not something else.
Having said that I noticed in an old post by Chris Giese that BIOS int
0x15=2403 reports in BX whether 0x92 (and the keyboard controller) can
be used to enable A20. So that's maybe the best means of identifying
it - if the BIOS supports the call.
> > 6. not write to port 0x80 as it clobbers any BIOS post codes sent
> > there
>
> port 0x80... ? I'll have to look that up.
IIRC there was a long discussion about an IO delay with some of the
key Linux authors and that they chose 0x80 because it was already
reserved as an output port much to the disappointment of some people
who used 0x80 as diagnostic output.
I'm not sure why writing to the port was required as part of the IO
delay. For some reason reading a port is apparently not as good a
delay and/or serialisation as writing to a port. Maybe someone can
explain that?
James
James Harris
...
> Also, my understanding is that the BIOS didn't always have the Int 0x15
> function to enable A20. I don't know when they started implementing it.
Yes, all we have from RBIL is "later PS/2s."
...
> > > If you look at the
> > > chart for A20M# in the link below, you can "see" this "override" effect
> > > for
> > > port 92h vs. keyboard controller.
...
> If either can turn it on, then the one that turned it on should turn it off.
Yes
>
> Let's start from the first line "a20 off" or "wrap", instead of the second
> line which sandpile.org says is the default startup state. So, we'll be
> enabling A20 from the off or wrap state. If we enable a20 by KBC, we go
> from the first line to the second line. If we enable a20 by PS/2, we go
> from the first line to the third line. The only way to get from either line
> 2 or 3 back to the first line is by disabling by the same method, yes?
That's how I read it.
> That's what I saw. If we attempt to disable either from line 2 or 3 via the
> opposite method, we remain on the same line. If we attempt to enable either
> from line 2 or 3 via the opposite method, we end up at line 4. So, one must
> disable both to ensure A20 is off or wrapped and one should disable by the
> same method one enabled by. Phew...
Very clear. And, yes, that's how it reads to me.
James
Rod Pemberton
> The tests I mentioned, 0xAA and loopback 0xD2, are for the presence of
> a keyboard *controller*, not for a keyboard. Only the controller is
> needed to change the A20 gate. As far as I know the keyboard isn't
> required for this.
Doh! I guess I never clarified that. Good to know. Yeah, like the
keyboard has more that transmit, receive, power, and ground... :-( Some
days, I tell ya.
> Taking up your point about the keyboard, though, I'd like to support
> servers which sit in a dark room with no keyboard, or mouse, or
> monitor etc.
USB KVM switch? USB over Ethernet?
> The key (sic)
> thing seems to be to allow a keyboard to be connected at any time
> after boot.
Hot plug on the keyboard? It'd have to be USB. Otherwise, possible "magic"
smoke...
> For a long time I puzzled over why a Unix box we used at
> work would never recognise a keyboard being plugged in after it had
> been booted. I now think it probably relied on the BIOS report of
> attached devices and never checked again for a keyboard.
Was it USB? If not, didn't you kill the port?
> It shouldn't be a problem in an OS either to check for a keyboard
> either periodically or on an otherwise unexpected IRQ1.
Do you plan to install a flag in the ISR routine to indicate that the
keyboard has been init-ed or not? Are you initializing your keyboards?
And, you'd have to keep the keyboard init routine resident. You could be
connecting and disconnecting a few times. That'd imply you'd need to poll
the keyboard repeatedly to know if it's there and needs initing again.
Shouldn't USB help with this - both initing and notifying? Recent versions
of Windows are USB hot plug-in aware.
> OK. I suppose I could use system port A at 0x92 first. It is faster
> and simpler. My problem with it is that it's harder to be sure that
> there is a system port A at 0x92 and not something else.
Well, A20 isn't enabled in my OS. It's upto the bootloader or my custom
startup at this point. If I had to guess at how to rank the two, I'd rank
keyboard as a "hair" more standard. But, 0x92 has been around since the
PS/2 (1987)... (pretty old) At this point, does one or the other or both
make that much difference? I'd expect them both to be present and working
in PC's for many years. If not, then I'd cross that bridge when it comes.
I did toss-in a couple rare reset methods in my reboot code I couldn't test.
But, there is enough "standard" stuff to keep busy on for a long time. Why
should I support oddities?
> Having said that I noticed in an old post by Chris Giese that BIOS int
> 0x15=2403 reports in BX whether 0x92 (and the keyboard controller) can
> be used to enable A20. So that's maybe the best means of identifying
> it - if the BIOS supports the call.
Ok.
Rod Pemberton
Maxim S. Shatskih
>work would never recognise a keyboard being plugged in after it had
>been booted.
PS/2 interface (i8042) has no hot-plug capability at all, neither on physical level nor on software.
--
Maxim S. Shatskih
Windows DDK MVP
ma...@storagecraft.com
http://www.storagecraft.com
wolfgang kern
James Harris in discussion with Rod Pemberton:
[...about topic...]
USB-keyboards are part of the PCI-story and don't touch
the usually anyway present or emulated KEYBD-controller
at 60/64h except for A20 gating and RESET.
I know three ways (which are used by BIOS) to enable A20:
1. out 64,D1 |wait for bit 1 = 0 (in 64) or TimeOut,
out 60,DF ;out 60,DD will turn A20 off.
2. set bit 1 of port 92h.
3. set a bit in PCI-config (host<->SB-bridge, Vendor specific).
the latter may direct do what the chipset emulates to remain
compatible with port-addresses that aren't present anymore.
__
wolfgang
James Harris
...
> > The tests I mentioned, 0xAA and loopback 0xD2, are for the presence of
> > a keyboard *controller*, not for a keyboard. Only the controller is
> > needed to change the A20 gate. As far as I know the keyboard isn't
> > required for this.
>
> Doh! I guess I never clarified that. Good to know. Yeah, like the
> keyboard has more that transmit, receive, power, and ground... :-( Some
> days, I tell ya.
:-)
I found it helpful to make up spreadsheets of the commands that could
be sent to each type of device. I've now put them online as tables in
case they are of use to someone else.
The first page shows controller commands. The second page shows
commands for the keyboard and its responses. Mouse data packets are
not included.
http://aodfaq.wikispaces.com/mkbc
http://aodfaq.wikispaces.com/keyboard
...
> USB KVM switch? USB over Ethernet?
...
> Hot plug on the keyboard? It'd have to be USB. Otherwise, possible "magic"
> smoke...
...
> Was it USB? If not, didn't you kill the port?
To all three questions: you are maybe aware of a problem I am missing.
I see Maxim has made a similar point. It was PS/2 rather than USB.
What's the problem with hot plugging a PS/2 keyboard?
>
> > It shouldn't be a problem in an OS either to check for a keyboard
> > either periodically or on an otherwise unexpected IRQ1.
>
> Do you plan to install a flag in the ISR routine to indicate that the
> keyboard has been init-ed or not? Are you initializing your keyboards?
> And, you'd have to keep the keyboard init routine resident. You could be
> connecting and disconnecting a few times. That'd imply you'd need to poll
> the keyboard repeatedly to know if it's there and needs initing again.
> Shouldn't USB help with this - both initing and notifying? Recent versions
> of Windows are USB hot plug-in aware.
Yes, the init code would have to remain available but it is very
small. You could possibly detect PS/2 keyboard disconnect and
reconnect a few ways such as detect change of scan codes, see a
transmission error, send 0xAB to the keyboard controller periodically.
To detect a keyboard being added to a machine which booted without one
(the case under discussion) may be even simpler - detecting IRQ1. It
is the controller which is told whether to generate interrupts or not
and it (the controller) is permanently connected.
Any of those any good?
>
> > OK. I suppose I could use system port A at 0x92 first. It is faster
> > and simpler. My problem with it is that it's harder to be sure that
> > there is a system port A at 0x92 and not something else.
>
> Well, A20 isn't enabled in my OS. It's upto the bootloader or my custom
> startup at this point. If I had to guess at how to rank the two, I'd rank
> keyboard as a "hair" more standard. But, 0x92 has been around since the
> PS/2 (1987)... (pretty old) At this point, does one or the other or both
> make that much difference? I'd expect them both to be present and working
> in PC's for many years. If not, then I'd cross that bridge when it comes.
> I did toss-in a couple rare reset methods in my reboot code I couldn't test.
> But, there is enough "standard" stuff to keep busy on for a long time. Why
> should I support oddities?
Yes, for the time being and for a number of reasons, for A20 enable I
think I'll stick with the keyboard method first, falling back to 0x92.
James
James Harris
wrote:
> >after boot. For a long time I puzzled over why a Unix box we used at
> >work would never recognise a keyboard being plugged in after it had
> >been booted.
>
> PS/2 interface (i8042) has no hot-plug capability at all, neither on physical level nor on software.
You mean one cannot disconnect and later reconnect a PS/2 keyboard, or
connect another PS/2 keyboard?
I can believe there is no software support for it but what's the
hardware problem?
James
Rod Pemberton
> What's the problem with hot plugging a PS/2 keyboard?
I'm unware of any actual failure on a PC by this. The stated reason was
electrical failure. AIUI, until USB, no device were to be connected to the
PC while it (and the connection) were powered, i.e., hot-plugged.
You'd know if you failed. The PC or keyboard will be non-responsive, likely
due to a blown sub-miniature fuse or thermal protection part somewhere. Or,
you'll smell "magic" smoke. "Magic" smoke is the *very* distinct smell of
burnt electronics or failed IC's. When a through hole IC fails, its case
cracks between the top and bottom of the plastic packaging. This allows in
oxygen which in combination with power to the chip inside produces a "puff"
of white smoke. The case separation is usually due to heat damage.
Usually, EE's will adjust the circuitry of ports and connections so it has
*some* protection against damage from users. E.g., in power amps, they'll
put a low ohm resistor in the circuit for the outputs. The purpose of this
resistor is to burn, literally, under certain circumstances. It'll produce
lots of "magic" smoke quickly. The resistor, once burnt, will disconnect
the power flowing through the outputs. It's there to stop users from
back-feeding power into the outputs, or short circuiting the outputs while
powered. The resistor is cheap and easy to fix. The circuitry, if damaged
by the user, is expensive to fix and replace.
RP
Maxim S. Shatskih
> connect another PS/2 keyboard?
This can cause physical damage.
Also, MS's i8042prt does not support hot-plug. The ex-maintainer of this code (Doron Holan) told that, according to what MS do, 8042 is not a hot-plug device at all.
wolfgang kern
James Harris wrote:
...
> I found it helpful to make up spreadsheets of the commands that could
> be sent to each type of device. I've now put them online as tables in
> case they are of use to someone else.
> The first page shows controller commands. The second page shows
> commands for the keyboard and its responses. Mouse data packets are
> not included.
http://aodfaq.wikispaces.com/mkbc
http://aodfaq.wikispaces.com/keyboard
Thanks, I'll check on this
...
>> USB KVM switch? USB over Ethernet?
>...
>> Hot plug on the keyboard? It'd have to be USB. Otherwise, possible
>> "magic"
>> smoke...
:) true (confirmed by experience).
...
>> Was it USB? If not, didn't you kill the port?
> To all three questions: you are maybe aware of a problem I am missing.
> I see Maxim has made a similar point. It was PS/2 rather than USB.
> What's the problem with hot plugging a PS/2 keyboard?
The problem just is that the connector is under power !
Powered hot plugging often result in permanent damage like oxidized pins,
blown tantals and broken chips in keyboard and/or controller caused
by sparking (somehow expensive if the controller lost confidence).
And even if the hardware survives such an attack, power-line jitters
may put keybd + controller in a non-recoverable state and will need
a hw-RESET, because sw-reset may not work then. PS/2 mouse and keybd
share one port, both IRQ-routines will be confused by any hot-plug.
USB is hot-plug designed, but not as hot-unplug, so if you don't
wait for 'save to remove', you will produce sparcs here as well.
Even USB-ports are much better protected than PS/2, frequently
ignoring the advice will soon lead to burned pins at least.
...
> To detect a keyboard being added to a machine which booted without one
> (the case under discussion) may be even simpler - detecting IRQ1. It
> is the controller which is told whether to generate interrupts or not
> and it (the controller) is permanently connected.
> Any of those any good?
Good for USB, not that good for PS/2 keybd and mousies.
[about...92h/64h]
> Yes, for the time being and for a number of reasons, for A20 enable I
> think I'll stick with the keyboard method first, falling back to 0x92.
I just kept my old way by trying first the faster port 92h-method and
if this fails I try port 64/60h. So I actually don't know nor care
which method worked, because I turn A20 on early and never off.
__
wolfgang
wolfgang kern
> ...
>> I found it helpful to make up spreadsheets of the commands that could
>> be sent to each type of device. I've now put them online as tables in
>> case they are of use to someone else.
>
>> The first page shows controller commands. The second page shows
>> commands for the keyboard and its responses. Mouse data packets are
>> not included.
> http://aodfaq.wikispaces.com/mkbc
On a first glimpse: the ready status-bit isn't bit3 in my docs.
> http://aodfaq.wikispaces.com/keyboard
>
> Thanks, I'll check on this
partially done, even your source seem to be conform with RBIL,
some of the controller-commands never worked on my PS/2 (F7..F9 ?).
__
wolfgang
Maxim S. Shatskih
For both.
> wait for 'save to remove',
"Safe to remove" does not power down the port in most cases. This depends on a driver.
James Harris
> > James Harris wrote:
> > ...
> >> I found it helpful to make up spreadsheets of the commands that could
> >> be sent to each type of device. I've now put them online as tables in
> >> case they are of use to someone else.
>
> >> The first page shows controller commands. The second page shows
> >> commands for the keyboard and its responses. Mouse data packets are
> >> not included.
> > http://aodfaq.wikispaces.com/mkbc
>
> On a first glimpse: the ready status-bit isn't bit3 in my docs.
Thanks for pointing this out. It is now corrected and I've added new
pages on the status register and other aspects of keyboard
programming:
http://aodfaq.wikispaces.com/mkbc-status-reg
http://aodfaq.wikispaces.com/mkbc-ram
http://aodfaq.wikispaces.com/ibm-kadc
> > http://aodfaq.wikispaces.com/keyboard
>
> > Thanks, I'll check on this
>
> partially done, even your source seem to be conform with RBIL,
> some of the controller-commands never worked on my PS/2 (F7..F9 ?).
According to The Undocumented PC these commands affect the keyboard
only "when scan code 3 is set." Could that apply?
James
wolfgang kern
James Harris wrote:
...
>>> http://aodfaq.wikispaces.com/mkbc
>> On a first glimpse: the ready status-bit isn't bit3 in my docs.
> Thanks for pointing this out. It is now corrected and I've added new
> pages on the status register and other aspects of keyboard
> programming:
> http://aodfaq.wikispaces.com/mkbc-status-reg
> http://aodfaq.wikispaces.com/mkbc-ram
> http://aodfaq.wikispaces.com/ibm-kadc
>> http://aodfaq.wikispaces.com/keyboard
>> Thanks, I'll check on this
> partially done, even your source seem to be conform with RBIL,
> some of the controller-commands never worked on my PS/2 (F7..F9 ?).
> According to The Undocumented PC these commands affect the keyboard
> only "when scan code 3 is set." Could that apply?
Sorry I don't know, non of my keyboards support set 3. And conversion
of set 2 scan-codes into single byte key-codes may be easier.
__
wolfgang
wolfgang kern
Maxim S. Shatskih mentioned:
>> USB is hot-plug designed, but not as hot-unplug,
> For both.
>> wait for 'save to remove',
>"Safe to remove" does not power down the port in most cases.
> This depends on a driver.
Oh thanks for the literal correction :)
Hard to see sense of a safe unplug if it would power down
the port after the device is disconnected ...
__
wolfgang
James Harris
...
>>> partially done, even your source seem to be conform with RBIL,
>>> some of the controller-commands never worked on my PS/2 (F7..F9 ?).
>> According to The Undocumented PC these commands affect the keyboard
>> only "when scan code 3 is set." Could that apply?
>
> Sorry I don't know, non of my keyboards support set 3. And conversion
> of set 2 scan-codes into single byte key-codes may be easier.
Don't worry, the question was largely rhetorical. I meant that your
keyboard may have not responded to F7..F9 because those commands
apparently only work with scan code set 3. If you were using scan code
set 2 it sounds like those commands *should* have failed.
At any rate it is documented so I've added the info as a footnote to
the relevant keyboard commands.
http://aodfaq.wikispaces.com/keyboard#cmd0xf7
James
wolfgang kern
Thanks, I missed this info in my peronal keyboard docs which mainly
reflect older RBIL and PC-internal books.
__
wolfgang
Maxim S. Shatskih
The _only_ sense of "Safe to Remove" is FS cache flush.