OSDev.org

Posted: **Fri Feb 04, 2005 5:57 pm**

I found some code in Minix that has me scratching my head. It resets the CPU by pulsing the reset line, which makes sense. What's kind of odd is that it also pulses the A20 line. There's a comment that attempts to explain why, but it doesn't really make sense to me. Here's the code:

Code: Select all

if (protected_mode) {
        /* Use the AT keyboard controller to reset the processor.
         * The A20 line is kept enabled in case this code is ever
         * run from extended memory, and because some machines
         * appear to drive the fake A20 high instead of low just
         * after reset, leading to an illegal opode trap.  This bug
         * is more of a problem if the fake A20 is in use, as it
         * would be if the keyboard reset were used for real mode.
         */
        kb_wait();
        out_byte(KB_COMMAND,
                 KB_PULSE_OUTPUT | (0x0F & ~(KB_GATE_A20 | KB_RESET)));
        milli_delay(10);

        /* If the nice method fails then do a reset.  In protected
         * mode this means a processor shutdown.
         */
        printf("Hard reset...\n");
        milli_delay(250);
  }

Any idea why the A20 line is pulsed? Do you think this is really necessary...?

Posted: **Fri Feb 04, 2005 7:42 pm**

A20 isn't being pulsed, it's being enabled

It must be enabled for the CPU to reset properly:

http://my.execpc.com/~geezer/osd/gotchas/index.htm#a20_reboot

I discovered this when I used this reset method in a real-mode OS.

Posted: **Fri Feb 04, 2005 8:42 pm**

Seriously freaky stuff.

Very odd bug that would keep A20 disabled after a reboot. What's stranger to me though is that the code shown is only used if the system is already in protected mode. Now if they are already in protected mode, and A20 is still disabled, then surely the keyboard controller A20 technique didn't work in the first place, so it seems pointless to try it again.

Posted: **Fri Feb 04, 2005 8:50 pm**

Chris Giese wrote: A20 isn't being pulsed, it's being enabled

The comments above that code seem to agree with what you're saying. What's confusing me is that the code doesn't seem to agree with the comments... In order to enable A20, isn't it necessary to actually write to the output register (command 0xD1 IIRC)? I thought command 0xFx (which is what KB_PULSE_OUTPUT is) was specifically for pulsing those signals for 6 usecs or so... Does the A20 gate behave differently for some reason? Is it "sticky" or something...?

It must be enabled for the CPU to reset properly:

http://my.execpc.com/~geezer/osd/gotchas/index.htm#a20_reboot

I discovered this when I used this reset method in a real-mode OS.

See Curufir's observation about this code only running in protected mode... That makes me scratch my head too.

I've stared at the comment a few more times, and here are the parts that are giving me trouble:

and because some machines appear to drive the fake A20 high instead of low just after reset, leading to an illegal opode trap.

Just so it's crystal clear, this means that the A20 gate is active-low, right? As in, low = enabled, high = disabled? Also, what do you think it means by the "fake A20"? I'm aware of the A20 line and the A20 gate... Does "fake" A20 refer to one of these, or something else entirely?

leading to an illegal opode trap.

I assume this is what the author observed, but more generally it's the result of executing garbage at 0xFFEFFFF0...

This bug is more of a problem if the fake A20 is in use, as it would be if the keyboard reset were used for real mode.

Something else that suggests that this is really only a problem when in real mode.... I get the feeling this is redundant if the A20 gate is already enabled, but I can't be sure. I can't figure out how to parse "fake A20 is in use"... "A20 gate is disabled" maybe?

I also found a very interesting comment in the Linux kernel source that makes me wonder if they ran into some variant of this problem. From the 2.6.10 version of Linux/arch/i386/kernel/reboot.c, line 148:

The following code and data reboots the machine by switching to real mode and jumping to the BIOS reset entry point, as if the CPU has really been reset. The previous version asked the keyboard controller to pulse the CPU reset line, which is more thorough, but doesn't work with at least one type of 486 motherboard.

Posted: **Fri Feb 04, 2005 9:07 pm**

"Fake A20" is, I think, a reference to the fact that A20 is no longer really done with the keyboard controller, but for compatibility's sake the A20 part of the keyboard controller is emulated.

Did some digging for the constants and things start to get very odd indeed.

That code is effectively OUT 0x64, 0xFC

Now reading the 8042 specs this would mean that bit 1 and bit 2 are pulsed low for 6 usecs before being returned to high. Which means A20 is being disabled (Bit 2 = low means disabled) at the same time as the processor is reset.

I don't mind saying that I'd love to know wtf is going on.

I'm speculating that would mean the A20 bit is returned to high just after the (buggy?)processor resets, resolving the A20 disabling problem and therefore the memory problem.

Still seems freakin' bizarre. Maybe I'm just not seeing what's happening properly.

OSDev.org

Using 8042 to reset the CPU

Using 8042 to reset the CPU

Re:Using 8042 to reset the CPU

Re:Using 8042 to reset the CPU

Re:Using 8042 to reset the CPU

Re:Using 8042 to reset the CPU