Thank you for contacting Intel Communities.
Thank you for bringing this to my attention.
Can you please provide the model number of the boards that had this issue?
Please also provide the OS and BIOS version for each one.
This because this setting is only related to the CMOS, BIOS and OS.
I hope to hear from you soon.
New(er) board - Advantech PCM-9562 with AMI BIOS QNX 6.5 OS.
Old board - Ampro Littleboard 486 QNX 6.2 OS.
In both cases, the OS desktop is not used, so only the application is used to set the clock.
The BIOS does not have a setting for DST, only the time. It is used initially to configure the board, but after that, only the application changes the time.
The application directly accesses the MC146818/ICH8 registers. It also calls the OS function to set the system time.
clock_settime(CLOCK_REALTIME, &systime); // Update QNX system time updateCMOSClock(new_time);
// Update CMOS set up
where updateCMOSClock does OUTs to the various registers include REG B.
The real-time clock ICs and (later) chipsets implemented a static "spring forward" on the first Sunday in April (one second after 1:59:58 AM, the time changed to 3:00:00 AM) and a "fall backward" on the last Sunday in October (one second after the time reaches 1:59:59 AM for the first time that day, it switches to 1:00:00 AM). Why you were seeing only the "spring forward" occurring I do not understand; that configuration bit was certainly supposed to cause both to occur. Perhaps were you looking for the change to occur on the wrong date? Regardless, I sent an email to some old f@rt BIOS engineers to see if they have any insights into this (if they respond with anything, I will update it here).
It is certainly true that most of the support for daylight savings time has shifted into the O/S (runtime) environment. This was predicated by the fact that (no surprise!) the world couldn't continue to agree on when the "spring forward" and "fall backward" should occur. It became so complicated - and, over time, had to change - that it because necessary to implement it in the O/S, where knowledge of Time Zone and Country (and even State, where necessary) were available and also so that it could be modified if folks change their minds yet again. See these pages for an indication of how complicated it has gotten: Wikipedia: Daylight saving time by country and Wikipedia: Daylight saving time in the United States).
Hope this helps,
Thanks for the information. Yes, DST is complicated. We were not intentionally enabling it in the ICH8 or MC146818 - a code bug where the 12/24 hour bit was defined as "1" for b1 instead of "2".
Yes, strange it was not doing "fall back". We tried many dates - first Sunday in April, last Sunday in October, and also the original dates from the MC146818 as well as many others. We tried multiple years 2016 and 2017. "Fall back" is trickier since it only is supposed to work the first time for that day, so somehow the chip needs to keep track of that, but letting it run from before midnight it did not occur.
It is also strange it was not occurring on all PCBs even though all were running the same software, and that on a board where it was not occurring, after letting it run a couple days from March 30 to April 2, it did start occurring, and then was repeatable multiple times setting it to 4/2/17 1:58 am.
I'm not sure if it is BIOS or chip. I broke into the BIOS on boot and watched it update from 1:59 to 3:00.
The BIOS engineers that responded to my query (so far) didn't remember there being any issues with the RTC hardware. Suffice it to say, none of them remember ever using this daylight savings feature. Of course, the era that would have used this feature was way, way back and memories are growing vague (remember, we're talking old f@rts here). Stubbornly curious, I hauled out my old Programmer's PC Sourcebook, Norton bibles, an original IBM PC/AT Technical Reference (yes, I still have it) and even my Phoenix and AMI BIOS Reference manuals. There was nothing in any of them regarding this feature...
Thanks for looking. I am one of those old guys. I also pulled out my Norton book, MSDOS reference, etc. Unfortunately, I tossed out my original BIOS listing a few years ago. There has to be some weird interaction with QNX OS and the RTC, either timing or uninitialized variable, or some sticky bit inside the ICH8 for determining when to do the jump or not. I did eventually get the "fall back" case to happen.
Yes, I would like someone at Intel to help us understand why when the DSE bit is enabled in the RTC on the ICH8 that sometimes the DST adjustment is done and other times it is not done, Is there something else blocking the DST adjustment? Is there something internal to the RTC that needs to see some amount of time prior to 1:59:59 am on 4/2/2017 or it doesn't do the DST adjustment? Obviously, the RTC keeps track in the fall so it doesn't go in an infinite loop. This is on Advantech PCM-9652 SBC.
This feature is probably not used by anyone anymore because it is the wrong dates, but since we accidentally had it enabled, we need an explanation for why it doesn't work on all SBCs, or works sometimes.
Yes, we are already in contact with Advantech, but this seems more like a chip issue than BIOS because the AMI Bios does not even have support for DST. That is why my question is to Intel about what are the prerequisites for the ICH8 RTC actually doing the DST adjustment. If DSE bit is enabled, why does it sometimes not do the adjustment?
I found that register 6, Day of Week, needs to be set correctly in order for the DST adjustment to be made. There is a note about this in the Motorola MC146818B data sheet, but not in the intel ICH8 datasheet about the Day of the Week.
Is that all it uses for DST adjustment? Month=4, Date <= 7, DOW=1, time = 1:59:59? It doesn't calculate the 1st Sunday of April for each year?
This may likely be the case. Remember that gates were costly in these ICs way back when and any way to minimize them would have been used...