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/ _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel