> I'm not absolutely sure as different specs contradict each other. For example,
> Intel Triton PIIX datasheets clearly say these bits are always valid, on the other
> hand Tech Help and several DOS port description guides define these bits as
> XT keyboard disable. AMD-640 chipset specs don't mention this port at all
> and OPTI Vendetta chipset specs state the same as Intel. => It seems bits 6 and 7
> are always valid on modern MB's, but maybe not on the old ones.
>
Which means you can't have the kernel using these bits at all without knowing
what hardware it's using. That's the problem. Any code that uses specific ports
had better be absolutely sure it know what's going on.
Also, I wouldn't depend on "modern" motherboards doing the same thing from one
revision to another.
> > > The kernel should _not_ enable these bits as it would break lots of systems
> > > having non-parity memory.
> >
> > How?
>
> This would probably enable the parity checks there causing approx. half of all
> memory accesses to cause NMI.
>
> Conclusion: We should not enable these bits explicitly and we should honor
> the information in bits 6 and 7 only if the corresponding NMI sources are set
> in bits 2 and 3 (they are hopefully readable on all MB's since the XT).
>
> Martin
>
I don't think we should even read these bits because we don't *know* if they are
valid. Only the use and the motherboard know whether parity or non-parity RAM is
installed.
This is really an issue about where hardware initialization should occur. The
real-mode setup.S seems to be the intended place to do this sort of thing, but
very few people like writing assembler code so it tends to clutter up the kernel
proper. I have a few ideas about this. Maybe something will happen in a few
weeks.
John