rtc migrations / century byte used

[Alexander Couzens]

Hi,

I mentioned some problems while debugging windows on a x201.
Also linux throw a warning with the RTC, but it could recover
the correct time.
coreboot multiple use of one nvram byte on lots of boards.
On most board 0x32/b400 is used by some nvram settings as well as the OS interprets the time (century) from the same byte.
The century byte saves the century in bcd format. The default location is 0x32 / b400.

find src/mainboard/ -iname cmos.layout | xargs grep -h '^400'  | sort | uniq -c
    112 400          1       e       1        power_on_after_fail
     33 400          1       e       2        hyper_threading
      1 400          8       h       0        century
      9 400          8       h       0        volume
      1 400         8         r       0        stumpy_usb_reset_disable
      2 400         8       h       0        volume
# 37 boards can be removed from this list, because they disabled the century byte in facp.

This leads to 3 topic:
 * how can we change cmos.layout in a way no or less settings gets lost? e.g. add a version field and a way to migrate these. or do we ignore the loss of data?
 * do we want to support the century byte?
 * how do we fix the multiusage, because it makes problems atm.

best
lynxis

mail: [e-mail]
jabber: [e-mail]
mobile: [phone]

[Jonathan A. Kollasch]

On Thu, Jul 02, 2015 at 07:42:39PM +0200, Alexander Couzens wrote:
> Hi,
>
> I mentioned some problems while debugging windows on a x201.
> Also linux throw a warning with the RTC, but it could recover
> the correct time.
> coreboot multiple use of one nvram byte on lots of boards.
> On most board 0x32/b400 is used by some nvram settings as well as the OS interprets the time (century) from the same byte.
> The century byte saves the century in bcd format. The default location is 0x32 / b400.
>
> find src/mainboard/ -iname cmos.layout | xargs grep -h '^400'  | sort | uniq -c
>     112 400          1       e       1        power_on_after_fail
>      33 400          1       e       2        hyper_threading
>       1 400          8       h       0        century

this is probably winent/mb6047, which I recently fixed.
>   9 400          8       h       0        volume
>   1 400         8         r       0        stumpy_usb_reset_disable
>   2 400         8       h       0        volume
>
> # 37 boards can be removed from this list, because they disabled the century byte in facp.
>
> This leads to 3 topic:
> how can we change cmos.layout in a way no or less settings gets lost? e.g. add a version field and a way to migrate these. or do we ignore the loss of data?

Doesn't look like any of the affected settings are extremely important.
> do we want to support the century byte?

We pretty much have to.  Between all the FACPs that say to use it and
the OSes (such as NetBSD) that look at byte 0x32 for the century without
checking the FACP.
> how do we fix the multiusage, because it makes problems atm.

I say we mark it like I did mb6047 or mark it reserved.  Also we
probably have a problem with checksumming come January 1st 2100 A.D....

Jonathan Kollasch