Need analysis of embedded system article--great news?--warning long post

greenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread

I found this post at: Embedded System/chip Draft Report to UK Government http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=000Kgr

The author seems to be saying that the y2k problem has been far too much over emphasized and that more problems will result from faulty attempts to fix the problem that from date errors themselves. But I don't have the technical background to assess his report. So could one of you knowledgeable technicians sum it up for the rest of us. Thanks. ----------------

Natural Time Progression Report 12th December 1998. An Analysis of the Y2K Non date retention BIOS problem and recommendations on the Millennium Century Date Change Campaign with in UK

(Updates the Natural Time Report 30 June 1998)

Report on BIOS Date Non Retention Millennium Rollover from 31st December 1999 to 1st January 2000 and Natural Time Progression.

Note: This document can be copied and circulated and orally related as long as full acknowledgment is made to the originators, Visionaries IT Research. This document is posted at http://visit.internet2000-Plc.com for public viewing.

The Brief. *One of the main problems concerning not only PC Computer Systems but also Embedded Systems is the date retention problem. Visionaries IT have carried out tests on a varied range of computer systems that are prone to the date retention problem and have the following facts to report.

Visionaries IT have considered present thoughts and theories concerning PC Servers and time-date related Embedded systems and those systems that are tasked for specific purposes such as public safety or banking transaction and trading. After thorough research and benchmark testing, Visionaries IT have found that there is no real requirement to apply any software fix or upgrade.

The Reason: The simple fact is that the date retention problem only lasts for 24 hours.

Whilst on line (permanently switched on) prior to midnight 1st January 2000, a computer system or embedded system troubled by the retention problem will register the correct system date and time but when switched off will not retain the date. The systems relate only to the system time processed and stored in RAM memory. Whilst online, natural time progression leads to natural date progression and the normal system functions will not be interrupted in any way throughout the 24 hour Real Time Clock non date retention period.

In most cases at midnight on 1st January 2000, the daily rollover to the following day 2nd January 2000, will eradicate the problem in an instant. If the system is taken off line, i.e.: switched off, the date will be saved and registered in the correct manner.

(Prior to running any benchmark test, ensure that important data is backed up)

The Millennium Ready Benchmark. This benchmark test can be run on any 8086, 386, 486 or Pentium with a non date retention problem:

Set the Date to the last day of the 20th Century and the time to the last second.

At the DOS prompt type:

"Date 31/12/1999" (Set the Date) - Press the Enter Key

Then:

" Time 23:59:59" (Set the Time) - Press the Enter Key

Then leave the Computer System running for 24 Hours plus 1 Minute

Then close the system down (Windows 95, 98) and finally switch off.

Wait for a couple of minutes then switch the system on again. Once booted, view the system date.

At the DOS prompt type:

"Date" - Press the Enter Key

The date should read 2nd January 2000. If so, this proves that Natural Time Progression (NTP) will solve the problem.

What have we learnt:

That System Time does naturally progress and the system date progresses at each 24-Hour interval.

That Personal Computer systems which are up and running prior to the non retention period, will have no problem concerning loss of data or transactions whilst on line.

That if there is a time correction, there would be a non date retention problem thereafter.

On the process of debate open to experts on the electronic highway, we have found that there are too many experts and professionals within all professional bodies including the IT industry who have a lack of knowledge on the real problems they are offering services for. The IT specialists listed on the DTI Action 2000 web site would seem to have forgotten the Basic Computer Science studied within the first year at university or college concerning the BUS operations, BIOS software procedures, CMOS memory allocation and the Real Time Clock operations. Many wrongly suggest that the non-BIOS date retention problem is hardware related. The Y2K Software and OS problems have been confused with the BIOS software problem. We recommend that a test is taken by technicians prior to being recommended or seen as being recommended by the CSSA, Action 2000, DTI or its Agencies or any such organisation.

That there is a need for some form of ombudsman to police the IT Industries efforts on eradicating the Millennium Century Date Change problem. The present system and administration is not really seen to be a responsible and professional way to handle a problem that could affect United Kingdom trade, export, imports and day to day business transaction.

Any problems that affect Trade and Industry, will cause a recession and high Y2K expenses will lead to many companies down sizing and a rise in unemployment. At the present, non-administrated systems are producing a set of future problems due to unregulated software tools, metrologies, and lack of real skills that will certainly cause more problems than any Millennium bug. Many of these extra problems will have already been introduced to PC systems causing future timebomb's that will certainly be the cause for concern.

That our earlier advice related to government and the Parliamentary Select Science Committee was not fully implemented. Standards were not set and our proposed Millennium Act was not treated seriously to protect consumers and to give more control to the authorities and the methods used to ensure that the IT companies carried out a more responsible approach to provide solutions. It is thought that greater concern should be taken by government to ensure that the governments' responsibility to the well being of the British public is upheld. It is obvious that more control is required, plus the implementation of the earlier suggested Millennium certification, before any further step forward is taken.

That there is a need for a sensible well policed Internet Y2K Forum, where valid Y2K information can be exchanged. That research centres can test suggestions, benchmarks, and theories so that unbiased correct reporting can be produced. "Hands across the water". Equally, Personal Computer and Embedded System BIOS ROM's that do not fit the standard pattern can be posted for reference (after being tested by independent research analysts). The Internet should be used fullest extent as a useful and helpful IT tool. This will aid the Millennium Century Date Change crisis so that myths and theories can be squashed as these could be the cause of more problems than solutions, adding unnecessary high Y2K budget expenses.

Therefore, what secondary safeguards are there left to consider?

That system networks linked to a timeserver would be instantly rid of the non-date retention problem. That systems linked to an Internet time update service will be instantly rid of the non-date retention problem. That systems using an in-house timeserver would be instantly rid of the non-date retention problem.

Information about timeservers can be found at http://Visit.Internet2000-Plc.com

If these safeguards are imposed, then timeservers could be set up at the Greenwich Millennium Dome with visual log displays to show the public how such a simple safeguard has been used to safeguard against world recession etc. (good PR)?

This report is still open to debate and will always remain so until Year 2001.

Notes: Of course, those that prefer to use the Windows Control Panel Time and Date settings can still do so, do not forget to close Windows 95 or 98 down before switching off the PC System.

Computerised Equipment (containing Embedded Systems) can also be tested in a similar manner by using the appropriate key entries (Read the Operations Manuals). Summary: There is no real need to purchase BIOS ROM fix software applications, as the normal date progression will eradicate the problem completely. However, safeguards should be used to give peace of mind.

We have found no proof that any PC system purchased after 1990 will show the system date as being recorded as a 2-digit year after the 31st December 1999. However, we wish to be informed of the brand, model number, the BIOS ROM, make, and serial numbers of such beasts if they do really exist. It seems to be a software application problem only.

Workstations and servers that have the retention problem and are switched off at night will need only the date entered on the first day of operation.

They will be fully functional; it is only that the date will initially read 4th January 1980. In any case, most workstations will be relating to the servers network date when directed and connected to the Network giving plenty of time for the individual dates to be adjusted (these factors should be analysed by system managers).

This natural safeguard will in fact be relevant to any system using BIOS technology, including Embedded Systems. Whatever the customisation, it is believed that 99% of BIOS ROM's purchased after 1983 will react safely after the 24-hour Millennium NTP period passes by.

*Photocopiers, Fax Machines, and VCR's react exactly the same as PC Systems and can be tested in the same manner. Unfortunately, Visionaries IT do not have the resources to confirm that all Embedded System strictly obey the rule, so we can only state logical theory that this should be so. Those that we have benchmarked would seem to fulfil the logical pattern.

These factors however, should be taken into account:

That many Embedded Systems are only used as counters and do not relate to the time or date, once the computerised equipment is turned off the date resets to the BIOS ROM floor of 4th January 1980. They are not backed up by battery.

Many Embedded systems relate to Sunday to Monday, and the time only. Once the computerised equipment is turned off the date resets to the BIOS ROM floor of 4th January 1980. E.g. VCRs, Alarm Systems and Lawn Sprinklers etc. They are not backed up by battery.

Many Embedded Systems relate only to the time, once the computerised equipment is turned off, the date resets to the BIOS ROM floor of 4th January 1980. E.g. Cookers, Microwaves etc. They are not backed up by battery.

*Those that do use the Time and Date functions, normally function the same as PC Systems, and the testing procedure should be based on the same principles.

*We suggest that UK Government Departments arrange for an establishment to independently check out the Millennium-ready System Benchmark on computerised equipment containing Embedded Equipment, as we only relate to those that are purely built around the Intel type /DOS BIOS ROM. It would be a good idea to set up a sensible related Internet Forum specifically for Analysts and Engineers to swap test results and actual Embedded System Facts.

Lifts, Fax Machines, and other equipment such as VCR's will function well without any foreseeable problems. There may be problems, that is of course a power cut or failure, which could require direct attention within the Millennium NTP period. It is suggested that companies may find the best protection would be to ensure computer systems managers are on duty or call out during the Millennium NTP period. This could also be a precaution, to ensure that business and security systems can be checked or taken off line if data errors occur, to prevent any further corruption or costly mistakes.

This report is not a statement that computerised equipment should not be tested, but that upgrading and renewal should always take lower priority to ensure that budgets are kept low and the consumer is aware of all options.

Our findings are a clear statement that the mild BIOS ROM software fault will not be the cause to civil unrest, national disaster, planes falling from the sky, atomic disaster or any other silly problem. As Computers and software can be tested very simply within a 21st Century environment it is thought that 21st Century Operation facts can be obtained very easily if more responsible control is placed by government. At present we have an army of unqualified fortune hunters bringing utter confusion to the Y2K problem, that will lead the road to utter confusion and expensive mistakes. We have but one chance at getting it right, with just enough time to set responsible and effective safeguards in place.

Notes: All benchmark tests are carried out three times, to be sure that the test results are correct. Visionaries IT are not making any statement that Computerised equipment should not be tested, only that great consideration should be made that upgrading or renewal should be the last option and not the first. We are actually stating that establishments and experts should take great care to manually benchmark test equipment before making bold statements that could backfire into a legal risk.

The problem with Information Technology is that the Consultants and Specialists behave like academics and make even the simple technologies seem like an Einstein equation. When their reasoning is attacked, they use the wizardry of the trade, more Einstein equations to protect their livelihoods. This is becoming very expensive to the Consumer and the Taxpayer. A question for the experts and manufacturers that know the truth of the issue.

Prior to any test being carried out it may be best to backup all PC system data as a few applications have a way of retrieving the delete old file option from the date. They do normally prompt yes or no, but human error could result in a minor calamity. Several readers of the first draft brought this to our attention. We thank them for their sensible input and fair criticism. We value criticism from any outside source, from free thinking analysts and solution providers.

We feel that many of the good safeguards related within the proposed Rt. Hon David Atkinson MP. Millennium Act show that David's and our original fears are now showing to be a reality that the consumers and stock holders require their rights to be protected. Many of the points researched by Visionaries IT require reviewing by government, the Bill has not been observed for its importance to the well being of Trade and Industry.

(c) Visionaries IT 1998 for free distribution.

Analysis of BIOS Software Hexadecimal (Machine Code) source code:

Most BIOS ROM's manufactured between 1983 and 1995 contain two software date loops. The first is a 20th Century loop that finishes at Midnight 31/12/99. The second 21st Century loop begins at midnight 01/01/2000. This 24-hour period causes an error to occur. On an error, the BIOS date reverts to the floor of 04/01/80, the very beginning of the 20th century loop. OEM manufacturers are oblivious to the problem as the accepted date and time BIOS program code has been copied, used and thought to be a set standard. Any amendment to the software has been an additive to the original code with no amendments to standard format.

For background material on Basic Computer Science concerning BIOS ROM, CMOS, Real Time Clock, and the BUS please visit http://internet2000-plc.com http://internet2000-plc.com Year 2000 section. We have links to Universities and the prominent Doctors and Professor's study notes used by 1st Year Computer Science Graduates.

Unfortunately many publications and policies on the Millennium Century date problem need to be reviewed and amended, anything less will lead to high risks of legal address by many consumers. Y2K Policies should not be built on non-researched theories.

We now wish to make a witness statement to the Parliamentary Select Science and Technology Committee as it is thought that the recommendations made within its April 1998 recommendations to the House of Commons, need to be reviewed due to the evidence provided by this report. We also feel that many of Taskforce 2000's views should be taken into consideration, mainly the time factor scenario.

Author: Robin Johnson-Perkins Research Analyst for Internet2000 UK Ltd. (Visionaries IT Research).

-- Bob Johnson-Perkins (Bob@Internet2000-Plc.com), December 24, 1998

-- c (buerkle@uiuc.edu), February 07, 1999

Answers

Is "learnt" a word? Suspect.

-- (kcj33@aol.com), February 07, 1999.

I've been writing PC BIOS code since 1987. I'll try to clarify what this confusing article is saying. Be warned that this is a technical issue, and an explanation of what's going on must necessarily be a technical explanation.

Before I dive in, I should mention that many embedded systems are based on fairly generic AT-style motherboards. These may look wildly different from the outside, but under the hood there's just a PC in there. What I'm explaining here applies to PCs and those systems based on PCs. Non-PC embedded systems are explicitly *not* discussed here.

Time in a PC is actually kept by two different clocks - by the RTC (real time clock), and a by a timer chip programmed to generate an interupt 18.2 times per second. The RTC operates from battery power when the PC is turned off, and never 'forgets' the time (unless the battery dies). The timer chip does not operate at all when power is removed from the PC.

The hardware in the RTC keeps track of time in 1-second intervals. The hardware can handle up through a 2-digit year -- it does not keep track of the century*. The RTC chip also contains a number of battery- backed ('permanent') memory locations, the number varies depending on RTC model. One of these locations is used by the BIOS to store the century. It is up to the BIOS to make sure the century value is correct. Not every BIOS does this.

*footnote: Some recent RTC chips *do* keep track of century in hardware, but I have never seen any BIOS that takes advantage of this.

When the PC is powered on, the operating system (during the OS boot process) requests the current date from the BIOS. This date is retrieved one time from the RTC and passed to the requesting OS. So long as the OS is running (the PC is powered on and the OS doesn't crash), the OS maintains time and date from the timer chip, NOT from the RTC chip.

Early BIOSs contained no century-specific code. The only way to get the BIOS to change the century value in battery-backed memory was through an explicit BIOS request to set the century (as part of setting the current RTC date). At that time, the BIOS set whatever date was contained in the request.

More recent BIOSs are a bit smarter, and have logic in two places to actually check the century and correct it if it has become obsolete. These two places depend on whether the century changed when the PC was powered off, or whether it was powered on.

If the unit was off, the first check happens during the power-up sequence. At this time, the BIOS examines the current RTC year. If the current RTC year is 00 (some BIOSs) or less than 80 (other BIOSs), the BIOS then checks the century. If the century is 19, the BIOS changes it to 20. When the OS requests the date, it receives the correct date.

If the unit was on, things are kind of messy. The RTC has no way to alert the system that the century just changed. This means that the BIOS must examine the date periodically. This examination happens whenever any program (including the OS) requests the current date from the BIOS. At the time of this get-date request, the BIOS updates the century value if required, based on the same logic.

This means that the RTC date is incorrect during the interval between century rollover and the first BIOS get-date request. Here are the ramifications to this: If nobody (no process executed on the PC) ever requests the BIOS to either set or get the date, the RTC date remains incorrect. In theory this shouldn't matter, since program requests to the OS get the right date (remember the OS is doing this independently), and program requests to the BIOS get the right date (since it's changed at the time the request is made), and those *should* be the only ways to get the date.

However, it is possible for a process to read the date directly from the RTC chip itself, bypassing both the OS and the BIOS. If whoever wrote this direct-access code was smart enough to handle the RTC properly (not trivial), but NOT smart enough to do a sanity check on the date, then this process can get the wrong date. NOTE that this mistake can only happen during the interval between rollover (RTC is temporarily wrong) and first legitimate BIOS date request (RTC is now correct again).

Now, are there any programs out there that make this mistake? It's certainly possible. I know that both Compaq and Dell have searched for one, and have yet to find one.

As this article says, Windows 95 (and later) issues the set-date call to the BIOS to bring the RTC up to the correct date during the shutdown process. Of course this isn't done if the shutdown process is not executed (hard crash, power failure, etc.). A modern BIOS should correct the century anyway during the next power-up sequence. Some don't.

There is (to my knowledge) one BIOS (1994 Award) that refuses to set the century to 20 under any circumstances. And of course there are many old PCs out there with dead batteries (the XT didn't even have an RTC). In these cases, the date must be reset each time the PC is turned on. In the case of that Award BIOS, requests for the date made directly to the BIOS will get the wrong century as well.

Bottom line: BIOSs that do not handle the century update with special logic require the user to set the date each time the PC is powered up. If the BIOS handles the century, this is not necessary so long as the battery is still good.

If I've confused anyone or left out anything important, please let me know and I'll keep trying.



-- Flint (flintc@mindspring.com), February 07, 1999.


Oops, correction already, sorry.

If the battery is dead, you must set the date each power-up.

If century rollover is not handled by the BIOS, you must set it correctly ONE TIME after rollover.

If century rollover is properly handled, you don't need to do anything.

-- Flint (flintc@mindspring.com), February 07, 1999.


I'm afraid the report only covers a portion of the embedded systems issue.

The embedded systems problem that I'm concerned about is the stand- alone microprocessor/micro-controller that isn't a PC and therefore, doesn't use a BIOS. These devices, the PLC-controlled hardware and sensors are going to be the most numerous and hence most troublesome embedded devices that we'll see. And since these devices don't include an operator interface, special tools are required to plug- into and analyze the operation and programming of these devices before any repair can take place.

WW

-- Wildweasel (vtmldm@epix.net), February 07, 1999.


Here's another reference on the embedded systems issue:

http://www.ngb.dtic.mil/y2k/closer.htm

-- Kevin (mixesmusic@worldnet.att.net), February 07, 1999.



For someone who has done considerable software programming, but not BIOS, ME, the above technically fine explanation by Flint should stand as an example to all those DGI friends of ours who say, "Hey, it's a simple problem after all. Someone will simply fix it". It's not simple and the attempted fixing can interject more problems if misunderstood. The misunderstanding is inherent in Flint's technical description: Not all BIOSs act the same in tandem with the RTC and OS.

Case in point: The Year2000.com site posts threads to BIOS quick fixes available from several different vendors. Each vendor has an approach to fixing the RTC and BIOS rollover problem. One or two are proprietary, to the extent the fixes only work with the BIOS installed on that vendor's computer main boards. e.g., Dell Computer.

When I ran one analysis (test) of the capability an old 486 motherboard with an AMI BIOS dated in 1993, the test said the BIOS would not properly perform a date rollover, but would recognize the Feb. 29 leap year. Okay. That was about as expected. What's next?

The fix is to install a little Terminate and Stay Resident(TSR) patch program by calling it from the autoexec.bat file at bootup. (Note. This particular fix is not called from config.sys)

It did appear to fix the problem, IF, installed with a date of 12-31-1999 and time of 23:xx:xx hours. But it will not run properly if installed NOW with a current 1999 date - not on this particular computer it won't! The date and time act erratically.

This is a rude awakening that generally means you should leave the computer powered off on "the night", unless you intend to be there to install the TSR yourself. Or, obviously, find a better patch. That subject is worthy of a post of its own.

The bottom line is that this type of fix is not really permanent at all. It creates the potential for more problems: (1) If you install it before 12-31-1999, at or near midnight, or(2) you miskey the call to the TSR program, or (3) the called TSR program somehow gets clobbered or erased, or (4) some date/time sensitive event occurs in the config.sys sequence - that is executed BEFORE the autoexec.bat calls the date fix.

I'm not a believer that all old hardware should be replaced simply because of this discussion. It can be fixed well enough for your time/date sensitive software to work properly. BUT THIS IS WHY "VALIDATION" IS SUCH AN IMPORTANT STEP, AFTER "REMEDIATION" AND "TESTING"! This obviously applies to main software packages as well as BIOS repair.

BW

-- Bob Walton (waltonb@kdsi.net), February 07, 1999.


I just got a personal email asking what programming I have done that exposes these date problems.

I have written an extensive software application that generally may be described as a combination of sofware/hardware for the purpose of running a home's mechanical processes: Security (including video), lighting, various controls such as furnace, watering system, weather measurement database, etc. Also included are voice recognition and voice answering using a video capture card and audio card. All of these processes may be manipulated remotely using various remote communication software available off the shelf.

Computer languages used in my project are Assembly, C++ and Visual Basic. The entire program is date/time sensitive and it is Y2K compliant using four bytes (characters) for the date.

I am a licensed developer for Creative Labs, dating back to 1993.

BW

-- Bob Walton (waltonb@kdsi.net), February 07, 1999.


learnt is a bonafide word according to Webster's.

-- Webster's (Dictionary@alert.com), February 07, 1999.

While a lot of what Bob Johnson-Perkins writes is OK, he consistently overpromotes his "BIOS Date Non Retention Millennium Rollover" and "Natural Time Progression" as representing the bulk of Y2k problems, seemingly not acknowledging that there are many other dimensions to Y2k than the narrow slices for which his company sells solutions.

If you decide to discount my above opinion because I'm miffed that Mr. Johnson-Perkins has incorporated some of my suggested modifications to his statements but has not thanked me or acknowledged me in any way because I post anonymously, go ahead. It's true anyway. :-)

-- No Spam Please (anon@ymous.com), February 07, 1999.


"We have found no proof that any PC system purchased after 1990 will show the system date as being recorded as a 2-digit year after the 31st December 1999."

Where are these guys looking for dates, the video card? I can't think of a SINGLE system from the early, or even MID 90's that DID have a working century in the RTC. This is the biggest pile of BS since, since... damn, I can't think of anything. This may be the biggest pile of BS I've EVER seen!

-- Sysman (y2kboard@yahoo.com), February 08, 1999.



Thanks for the post c. A look at the underlying hardware supports the post.

The MC146818 CMOS clock chip in the original IBM AT, as well as subsequent emulations of it in the PCs in quesion here, all support 4 digit dates. As defined for the AT, the byte of SRAM at offset 32H holds a BCD-coded representation of the century. Presumably, the designers did not think that it was necessary to implement an automatically updated register for an event that would only happen once. Unless the CMOS chip is defective, this byte works as advertised. Systems firmaware and software should, of course, properly support the hardware, but they do not always do so. Fortunately, BIOS extensions to do so are easily implemented on a PC.

Robert

-- Robert Neely (robert_neely@ncsu.edu), February 08, 1999.


*sigh* Sysman and Robert, didn't I already say this? Do I really have to say this all over again?

The MC146818 and clones do NOT support the century in hardware. IBM elected to use CMOS RAM to contain a century value, but it is up to the firmware protocol to maintain this value -- the 146818 does NOT do this. Offset 32h is only a memory location, not in any sense a date register supported by the RTC timekeeping hardware.

Certain recent RTC chips (National Semiconductor 317 and SMC 93x) DO support the century in hardware, along with maybe a couple of others. Each of these devices has a separate, non-obvious access method for reading and setting this hardware register. I am not aware of any current BIOS that ever either reads or writes this register in any RTC that supports it.

The current century continues to be maintained or not, as the case may be, by software. If the software is correctly written (I have yet to see an entirely correct RTC access method, but that's another story), the MC146818 will be good until 2099. By which time it will be impossible to find a replacement battery for it anyway.

Sheesh

-- Flint (flintc@mindspring.com), February 08, 1999.


Moderation questions? read the FAQ