OSDev.org

OSDev wiki CMOS article (http://wiki.osdev.org/CMOS) paragraph "RTC Update In Progress" seems a bit confusing for me: why they reading time that way? When UIP flag is cleared we have at least 244 us for reading time. Proof from original Motorolla RTC chip datasheet MC146818A:

After the UIP bit goes high, the update begins 244 us later. Therefore, if a low is read on the UIP bit, the user has at least 244 us before the time/calendar data will be changed. If a '1' is read in the UIP bit, time/calendar data may not be valid

So, if UIP=0 we can read time, if UIP=1 we must wait until UIP=0 (in the worst case 244 us + 248 us for update itself) and read time. In case UIP=1 it is possible better variant: read time twice and compare and only if they don't match wait until UIP=0. Am I right? And author of CMOS article is wrong in his interpretation of UIP flag usage? He says:

... the update could begin immediately after the "Update in progress" flag was checked and the code could still read dodgy/inconsistent values...

Does this apply to all chips? What if the RTC is read from a pre-emptive thread or suddenly the CPU slows down considerably and you don't make it in time? You seem to assume that the RTC value is consistent at all times, that you either get the old or the new values, but the chip could be implemented in a manner where the value may not be consistent between the update start and update end.

Does this apply to all chips?

- I don't know, but only this behaviour is right (otherwise UIP flag is meaningless).

What if the RTC is read from a pre-emptive thread or suddenly the CPU slows down considerably and you don't make it in time?

- yes, that's right, but I think the author should add some words about 244 us. It is important to understanding of UIP flag.

You seem to assume that the RTC value is consistent at all times, that you either get the old or the new values, but the chip could be implemented in a manner where the value may not be consistent between the update start and update end

- I don't assume this. If I assume this I would not have any attention to UIP flag.

Hi,

suslik wrote:OSDev wiki CMOS article (http://wiki.osdev.org/CMOS) paragraph "RTC Update In Progress" seems a bit confusing for me: why they reading time that way? When UIP flag is cleared we have at least 244 us for reading time. Proof from original Motorolla RTC chip datasheet MC146818A:

After the UIP bit goes high, the update begins 244 us later. Therefore, if a low is read on the UIP bit, the user has at least 244 us before the time/calendar data will be changed. If a '1' is read in the UIP bit, time/calendar data may not be valid

So, you read the UIP bit, see that it is clear, then the user presses a key on their USB keyboard causing the firmware's "emulate PS/2" SMM code to mess with USB and PS/2 stuff for 1234 us, then your code (which can't prevent SMM and doesn't know about it) starts playing with RTC in the middle of an update?

Given that you should only ever read the time and date from the RTC once during boot; is it really worth the hassle of worrying about the exact behaviour of UIP (and if all RTCs behave the same or just some) just so you can shave a tiny fraction of time off of your boot times?


Cheers,

Brendan

Thanks a lot, Brendan. So, I see that UIP flag is useless now due to SMM (I think this should be pointed in CMOS/RTC wiki article and code that checks UIP should be deleted).

is it really worth the hassle of worrying about the exact behaviour of UIP

- yes, I hate coding something without understanding why.

By now you should realize the reason why it is useless is simply because you cannot guarantee in traditional operating systems on x86 that some task will finish within a certain amount of time (unless it's considerably higher than the task normally takes). Real-time operating systems try hard to make sure that things get done in time, but with things like automatic CPU slowdown, SSM, phase-of-the-moon, and more will interfere. It is foolish to design a solution that assume that things get done on time and do undefined behavior otherwise, there should always be some recovery path "Okay, I didn't get it done on time. Now what?".