[U-Boot-Users] RTC Question

[U-Boot-Users] RTC Question

[Robin Getz]

All:

General question, in the specific processor (Blackfin BF533) that I am 
using, the on-board RTC can have a 32768 days, and defaults to starting at 
01Jan1970. This means that RTC rollover will occur around Fri, 19-Sep-2059 
11:59pm. On Sat 20-Sep-2059, the date will be displayed as Thur 01-Jan-1970.

Should I add extra complexity, to extend things past this?

I see issues in other code that will roll over around 19Jan2038, so I would 
expect that others are not concerned about it?

-Robin

[U-Boot-Users] RTC Question

[Wolfgang Denk]

In message <6.1.1.1.0.20041008090220.01e07ec0@wheresmymailserver.com> you wrote:
> 
> General question, in the specific processor (Blackfin BF533) that I am 
> using, the on-board RTC can have a 32768 days, and defaults to starting at 
> 01Jan1970. This means that RTC rollover will occur around Fri, 19-Sep-2059 
> 11:59pm. On Sat 20-Sep-2059, the date will be displayed as Thur 01-Jan-1970.
> 
> Should I add extra complexity, to extend things past this?

Hou could you fix this? U-Boot will probably not even be running when
the rollover happens, so it has zero chance to notice. Of course  you
can  assume that no board will ever show a legal time before 2004, so
you could always add of offset equivalent to 34 years to  your  RTC's
date,  shifting  the  problem until 2093 ... The offset is trivial to
implement, and probably all you ever need.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Microsoft Compatibility:
     your old Windows 3.11 application crash exactly as the new ones.

[U-Boot-Users] RTC Question

[Victor Wren]

> 11:59pm. On Sat 20-Sep-2059, the date will be displayed as Thur 01-Jan-1970.
> 
> Should I add extra complexity, to extend things past this?

> I see issues in other code that will roll over around 19Jan2038, so I would 
> expect that others are not concerned about it?

This is a common discussion on many boards.  Actually, most variants of Linux 
will roll over in 2038. Eventually (within the next five years, I'm guessing) 
the move will probably be made to 64-bit clocks.   It's not a matter of 32768 
days, but 2^31-1 seconds (for signed int), so a 64-bit clock will push out 
the rollover to the year 292,271,025,015 (roughly), or about 50 times the age 
of our solar system.

Considering that 2038 is 34 years away, though (remember that 34 years ago 
was 1970) it's pretty likely that hardware is going to be considerably 
different by then, and anything made today will be a distant memory.  I could 
be wrong.  Anybody still running embedded devices made in 1970?  

Victor Wren

[U-Boot-Users] RTC Question

[Frank]

--- Wolfgang Denk <wd@denx.de> wrote:

> In message

> Hou could you fix this? U-Boot will probably not even be
> running when
> the rollover happens, 
I seem to recall the Cobol programmers saying this before
Y2K.:-)



		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

[U-Boot-Users] RTC Question

[Wolfgang Denk]

In message <20041008215519.11048.qmail@web13827.mail.yahoo.com> you wrote:
> 
> > Hou could you fix this? U-Boot will probably not even be
> > running when
> > the rollover happens, 
> I seem to recall the Cobol programmers saying this before
> Y2K.:-)

I think you misinterpret my statement.

I mean that U-Boot is just a boot loader,  used  mostly  in  embedded
systems  which often run in 24/7/365.25 mode. Only a tiny fraction of
the total system time will ever be spent in U-Boot. Chances that  the
roll-over happens while an OS (or some other software) is running are
magnitudes bigger than that we see this event in U-Boot.

So calculate the probability that (1) the same hardware will still be
used in 2094, (2) it will still run U-Boot,  and  (3)  the  roll-over
happens exactly during a reboot of the system.

Now how much effort do you intend to spend on solving such a problem?

My recommendation is: document and ignore it. It's a  feature  (read:
limitation) of the hardware, and this type of hardware will go out of
existence soon enough.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
The use of Microsoft crippleware systems is a sin that  carries  with
it its own punishment.
         -- Tom Christiansen in <6bo3fr$pj8$5@csnews.cs.colorado.edu>

[U-Boot-Users] RTC Question

[Robin Getz]

Wolfgang Denk wrote:
>How could you fix this?

As you suggested - just a simple offset (exactly the same will need to go 
into the Linux kernel). If the overflow occurs - (if you see a date less 
then 18Sept1974, assume roll over has occurred, add 4 years, 9 months, and 
17 days). This will set things to the same day of the week structure as the 
roll over date (19Sep2058 is a Thursday, and so is 19Sept1974). This also 
should handle the leap years calculations properly.

After this it is a simple matter of just adding 84 years to the return 
value or display of the function.

>U-Boot will probably not even be running when the rollover happens, so it 
>has zero chance to notice.

U-boot may not have to be alive when rollover occurs to have an issue - for 
a contrived example that has less chance of actually happening than me 
willing the lotto, if you set U-Boot up to check a network connection 
monthly for updates, after 2058 it stops checking, because U-boot believes 
that Oct2058 never occurs.

However, by doing the above, all than happens is delaying things until 
2087, and then you run into the same problem. But since I plan on being 
dead by then, I am OK with that. (I'd like to be around in 50 years, but 
not 80).

-Robin