i386: rtc, nvram and the upper bank

[Andriy Gapon]

It seems that on at least "real Intel" i386 platform since 440/PIIX4
chipset times there 256 bytes of RTC NVRAM (minus actual timer/control
registers). Access to upper 128 bytes can enabled/disabled via chipset
configuration. For earlier chipsets it can be done via PCI config (e.g.
register 0xcb of Host-ISA bridge on PIIX4) or via memory mapped "root
complex" (e.g. for ICH9).
Ports 0x72 and 0x73 are used for access to the upper NVRAM when it is
enabled similarly to 0x70/0x71. When the upper NVRAM is disabled then
0x72/0x73 access the lower NVRAM.

Multi-piece suggestion:
1. fix signatures of rtcin/writertc functions - uint8_t for register
number and value (instead of ints), also rtcin() definition in
sys/i386/isa/clock.c seems to be "old-style".

2. either add rtcin2/writertc2 for access to upper NVRAM, or make
rtcin/writertc interpret reg numbers > 0x7f as access to upper NVRAM;
the latter proposal has a shortcoming on not being to explicitly control
0x80 bit ("NMI something") anymore, but I really doubt that that bit is
any useful or that it is actually used.

3. add a check/quirk somewhere[?] to enable access to upper NVRAM,
because sometimes BIOS disables it or chipset has it disabled by default.

4. update sys/dev/nvram to be able to access 256 bytes


Also, I understand that nvram device has an interface compatible with ts
Linux "brother", but I think it would better to address NVRAM bytes by
their true address and simply "mask out" control registers. I.e. always
return 0x00 or 0xff on reads and ignore writes. It is not really
userland's business to mess with those registers.
And I am not sure about checksum calculation/verification. I think it is
not the kernel's business. If a userland program modifies NVRAM content
it must already understand its structure and meaning, so it should
update any checksums on its own.

Also, something to look at, long-term.
Why not use rtc device/framework for i386 and amd64.
Why not re-use mc146818.
Why not extend rtc interface with NVRAM access methods.

I already have some code for 1-4 (used on a running system).

-- 
Andriy Gapon