On Tue, 6 Jun 2000, Richard B. Johnson wrote:
> > I can't recall Linux using INT 0x15, function 0x87... This is
> > irrelevant.
>
> LILO uses it to load the kernel above the "1 megabyte boundary".
> This is, therefore, quite relevant.
Of course, but LILO exits long before there is a chance for our NMI
handler to be invoked.
> > If you start from a cold-boot, the BIOS checks for a cold startup
> > condition in the 8042 before checking the shutdown byte. It's usually
> > just after executing a far jump at 0xf000:0xfff0. There is only a smsw
>
> The BIOS for most new processors, i.e., after the 486/DX does not do
> a far jump at 0xf000:fff0. What you see there with `debug` is after
> the BIOS has been shadowed. That vector usually points to some low-
> memory code before jumping to the previous vector.
Hmm, have I written anything about debug? Just mmap() 64kB of /dev/mem
at 0xffff0000 and study it with objdump. You'll see what I mean.
> Upon startup, the BIOS does _not_ exists at 0xF000:0000, with the
> reset-vector at 0xF000:FFF0!!
Most if not all current chipsets decode both 0xffff0000 and 0x000f0000 to
the ROM chip upon reset (they also decode 0xffef0000 to account for
masking of the A20 line). These two (three) ranges are the same. Other
areas, such as 64kB at 0xfffe0000 may differ as there might be the rest of
the ROM mapped. Talk to linuxbios people -- they chased 2Mbit Flashes
recently.
> This condition continues as long as only 'near' jumps occur. Therefore,
> the reset vector contains a near jump to the code that determines how
> the processor reset occured. If it was a hard reset, the BIOS PROM (NVRAM)
> has to be enabled at 0xF000:0000 before a far jump occurs. This far jump
> is, therefore, never at 0xF000:FFF0, even though it's there by the time
> you look at it with `debug`.
Most current chipsets decode 0x000f0000 for the BIOS area all the time.
It's just simpler -- there is no point in having this configurable given
nobody needs it. The only difference is that after a warm restart, they
may decode to the so called shadow RAM with a copy of the BIOS instead.
> Incidentally, the PCI specification requires that all BIOS modules
> run in RAM, not PROM. Therefore most everything you see with debug
> has the potential of being somewhat different than what is actually
> burned into PROM (or NVRAM) and different than what executed upon
> power-up.
I can't imagine how this could be achievable -- after a poweron there is
no DRAM refresh, even -- how can you expect the CPU to fetch the first
instruction from RAM?
> A processor reset from protected mode does not affect the cold-start
> status of the keyboard controller. A power failure or the power switch
Agreed.
> results in undefined status in the keyboard controller. That's why it
What do you mean by an "undefined status"? It just gets its RESET
triggered, which sets its internal registers to a predefined state.
> is reset/reprogrammed if a check of the CMOS shutdown byte shows that
> the reset was not a processor-only reset from protected mode. Note
Funny, it's actually the reverse. Unless you have a custom/weird board.
> that the keyboard controller is a uP with mask-ROM code. It takes
> time for it to come out of reset during power-up. That's why its
> status is undefined.
I've never disassembled the 8042's internal code but it just works as I
described. After a RESET the status byte returned by the 8042 has it's
bit #2 reset.
> I am a BIOS 'vendor'.
Great -- so you may fix whatever is wrong. Just get it working in an
AT-compatible way. If it already does then I don't see any problem.
> > Surely -- the problem is it cannot be easily done without a side effect
> > of reprogramming the index.
>
> It does not reprogram the index. The high-bit of the index is the
> NMI enable bit. An index of 0x80 == 0x00 for the CMOS.
But the index might have been programmed for another value. For example
a NMI might be invoked after a driver (such as the RTC driver) performed
outb(0x03, 0x70) but before it performed outb(x, 0x71) to set minutes of
the alarm. Unfortunately we have no way in the NMI handler to see that it
was 0x03 that was the last value written to 0x70 so we cannot keep it
unchanged. Whether you write 0x00 or 0x80 makes no difference here --
neither of these means 0x03 for the RTC.
> Sure., but it's better than not booting until somebody hits the reset
> button. The whole idea is to make sure that, should power fail, the
> system will reboot when power is restored. You help do this by making
> sure the shutdown byte cannot be corrupted during the power failure.
If you are so concerned of the shutdown byte then we may use an index of
0x0d -- the relevant location is read-only so nothing will get corrupted.
Just submit a patch.
-- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available +- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:28 EST