setup.S: A20 enable sequence (once again)
Hi all,
a while ago, I posted a request here to add the "fast A20" enable sequence to setup.S in order to enable booting Linux on boards that don't have a keyboard controller. I was happy to see that this has been added into 2.4.0-test10 already. However, on some embedded boards, booting 2.4.0-test10 does work, but it takes several minutes which the board spends in complete silence (it took me almost a day to realize that I only had to wait long enough for the system to boot ...)
The reason for this is that the A20 enable sequence in setup.S is still accessing the (in my case not existing) keyboard controller. It times out eventually, but the timeout takes *very* long, especially on a slowish embedded 386EX@25MHz.
The attached patch fixes this by doing "fast A20" enable first and then checking if A20 already is enabled. If it is, the keyboard controller sequence is skipped. This works for me, so, could people please have a look at this.
Cheers
Rob
arch/i386/boot/setup.S +28 -11
@@ -631,6 +631,25 @@ # appropriate # that was painless, now we enable a20 +# Try the "fast A20" version first: +# You must preserve the other bits here. Otherwise embarrasing things +# like laptops powering off on boot happen. Corrected version by Kira +# Brown from Linux 2.2 +# + inb $0x92, %al # + orb $02, %al # "fast A20" version + andb $0xfe, %al # be sure not to reset CPU + outb %al, $0x92 # some chips have only this + +# See if that already did the job, skip keyboard controller +# accesses if so: some boards do not have a keyboard controller. +# These boards (especially if running on a slowish 386 EX) +# can spend several *minutes* in silence, polling for the +# non-existent keyboard controller. + + call a20_check + jne a20_enabled + call empty_8042 movb $0xD1, %al # command write
@@ -641,31 +660,29 @@ outb %al, $0x60 call empty_8042 -# -# You must preserve the other bits here. Otherwise embarrasing things -# like laptops powering off on boot happen. Corrected version by Kira -# Brown from Linux 2.2 -# - inb $0x92, %al # - orb $02, %al # "fast A20" version - outb %al, $0x92 # some chips have only this - # wait until a20 really *is* enabled; it can take a fair amount of # time on certain systems; Toshiba Tecras are known to have this # problem. The memory location used here (0x200) is the int 0x80 # vector, which should be safe to use. +a20_wait: + call a20_check + jne a20_enabled + jmp a20_wait # loop until no longer aliased + + +a20_check: xorw %ax, %ax # segment 0x0000 movw %ax, %fs decw %ax # segment 0xffff (HMA) movw %ax, %gs -a20_wait: incw %ax # unused memory location <0xfff0 movw %ax, %fs:(0x200) # we use the "int 0x80" vector cmpw %gs:(0x210), %ax # and its corresponding HMA addr - je a20_wait # loop until no longer aliased + ret # make sure any possible coprocessor is properly reset.. +a20_enabled: xorw %ax, %ax outb %al, $0xf0 call delay
----------------------------------------------------------------
Robert Kaiser email: [email protected]
SYSGO RTS GmbH
Am Pfaffenstein 14 phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10
-
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/
Followup to: <00110618083400.11022@rob> By author: Robert Kaiser <[email protected]> In newsgroup: linux.dev.kernel
Quoted 17 lines
Hi all,
a while ago, I posted a request here to add the "fast A20" enable sequence to
setup.Sin order to enable booting Linux on boards that don't have a keyboard controller. I was happy to see that this has been added into 2.4.0-test10 already. However, on some embedded boards, booting 2.4.0-test10 does work, but it takes several minutes which the board spends in complete silence (it took me almost a day to realize that I only had to wait long enough for the system to boot ...)The reason for this is that the A20 enable sequence in
setup.Sis still accessing the (in my case not existing) keyboard controller. It times out eventually, but the timeout takes *very* long, especially on a slowish embedded 386EX@25MHz.
Quoted 5 lines
The attached patch fixes this by doing "fast A20" enable first and then checking if A20 already is enabled. If it is, the keyboard controller sequence is skipped. This works for me, so, could people please have a look at this.
This doesn't really work. Neither the fast A20 gate nor the KBC is guaranteed to have immediate effect (on most systems they won't.)
What's worse, once you have done an "out" to the KBC you need to finish the sequence. I need to think about this for a bit.
(Arguably, what you're doing is running on completely nonstandard hardware, which may need a CONFIG_ option. However, if we can avoid it I guess it's better.)
-hpa
Signature · 7 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - 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/
Quoted 2 lines
This doesn't really work. Neither the fast A20 gate nor the KBC is guaranteed to have immediate effect (on most systems they won't.)
Fast A20 gate happens to be immediate on all the embedded kit I know so its probably acceptable, and if its too slow it still does the kbc timeout. Since its generally on chip they dont muck about talking to keyboard and other junk I/O controllers.
-
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/
Followup to: <[email protected]> By author: Alan Cox <[email protected]> In newsgroup: linux.dev.kernel
Quoted 9 lines
Quoted 3 lines
This doesn't really work. Neither the fast A20 gate nor the KBC is guaranteed to have immediate effect (on most systems they won't.)
Fast A20 gate happens to be immediate on all the embedded kit I know so its probably acceptable, and if its too slow it still does the kbc timeout. Since its generally on chip they dont muck about talking to keyboard and other junk I/O controllers.
I'd rather do it "right", which is to poll for A20 in the same loop as we wait for the KBC to become available.
-hpa
Signature · 7 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - 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/
Followup to: <00110618083400.11022@rob> By author: Robert Kaiser <[email protected]> In newsgroup: linux.dev.kernel
Quoted 5 lines
The attached patch fixes this by doing "fast A20" enable first and then checking if A20 already is enabled. If it is, the keyboard controller sequence is skipped. This works for me, so, could people please have a look at this.
I just looked at the code, and it's worse than I first thought: if memory location 0x200 happens to contain 0x0001 when the kernel is entered, this code with loop indefinitely.
-hpa
Signature · 7 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - 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/