[support-gang] Real time clock battery during XO storage

[James Cameron]

On Sun, Dec 15, 2013 at 08:05:40PM -0500, Nathan C. Riddle wrote:
> On Sun, Dec 15, 2013 at 4:20 PM, Adam Holt wrote:
> > James wrote:
> > > [... that clock battery bricking no longer occurs with latest
> > > firmware, which is also compatible with older operating system
> > > releases, see http://wiki.laptop.org/go/Upgrading_firmware ...]
> >
> > Tremendous advance for all our 12.1.0 XO-1s, thanks James:
> > [...]
>
> Point of clearification please.   I understand the great value of
> the simplified version of loading a firmware.

It is of no unusual value, as it has always been present.  People had
learned arcane alternatives and promoted them when asked, so I've
rewritten the Wiki page in the past year.

> However, I understood from earlier post that nothing prevents the
> discharge of the RTC battery -- various firmware just ignores the
> discharged battery and boots anyway.

No.

On an XO-1, the clock battery can be prevented from discharging by
leaving a main battery in the laptop, or by removing and replacing the
clock battery without turning the laptop on.

On an XO-1.75 and XO-4, the clock battery can be prevented from
discharging by typing a firmware command.

Firmware for all models now boot without error if the clock is
cleared.  (If the laptop is subject to a deployment lease, the
operating system will try to obtain a new lease).

> Has not all the OLPC versions since Q2D06 done this, but also
> provided a System Date error message ? The improvement here appears
> to just set a valid time (not actual time) and proceeds with the
> boot without the error message ?  I have not run q2f19 yet.

No, versions since Q2D06 did not do this.

You should test it.  There was not good documentation for how to test
it, so I added some:

http://wiki.laptop.org/go/Fix_Clock#Reproducing

The design change was by Daniel Drake initiated 16th March 2013.

The purpose was to make the design consistent across all models, and
also to reduce the repair load in deployments.  Of particular
importance was feedback from Uruguay and Nicaragua.

When the clock is invalid, all laptops are to reset the clock to a
fixed past point.  An effect is removing the "Invalid System Date"
condition.

Discussion was between 16th March and 27th March, with implementation
by 18th April, and final testing on 4th June in Nicaragua.

The functional change is more than what you describe.  In particular,
the clock is reset to a fixed past point, 2013-01-01 00:00:00, and if
it contains a century of 19 it is treated as a century of 20.  The actual
change in Forth as a patch looks like this:

Index: dev/ds1385r.fth
===================================================================
--- dev/ds1385r.fth	(revision 3043)
+++ dev/ds1385r.fth	(revision 3689)
@@ -88,15 +88,55 @@
    cr  
    then
 ;
+: reinit
+   h# 20 h# 1a rtc! \ century
+   h# 13 h#  9 rtc! \ year
+   h#  1 h#  8 rtc! \ month
+   h#  1 h#  7 rtc! \ day of the month
+   h#  2 h#  6 rtc! \ day of week, monday
+   h#  0 h#  4 rtc! \ hours
+   h#  0 h#  2 rtc! \ minutes
+   h#  0 h#  0 rtc! \ seconds
+   ." RTC cleared" cr
+;
 true value first-open?
 headers
 : open  ( -- true )
    my-unit  2  " map-in" $call-parent  is rtc-adr
    first-open?  if
       rega-mode d# 10 rtc!
       regb-mode d# 11 rtc!
       \ If the battery is bad, display a message, but go open the device anyway
-      check-battery battery-message drop
+      check-battery battery-message  if  reinit  then
       false to first-open?
    then
    true
@@ -130,13 +170,7 @@
    bcd-time&date  >r >r >r >r >r >r
    bcd>  r> bcd>  r> bcd>  r> bcd>  r> bcd>  r> bcd>  r> bcd> ( s m h d m y c )
 
-   \ We allow the century byte to force the year to 20xx, but not to force
-   \ it to 19xx, because that would cause a problem when the century
-   \ rolls over.
-   dup  d# 20 <>  if
-      drop  dup d# 94 <  if  d# 20  else  d# 19  then
-   then
-
+   d# 20 max
    d# 100 * +  		\ Merge century with year
 ;
 : set-time  ( s m h d m y -- )

CC: devel@ since this has moved again into a development
discussion, not really what support-gang@ is for.

-- 
James Cameron
http://quozl.linux.org.au/