Re: [support-gang] Real time clock battery during XO storage
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
Re: [support-gang] Real time clock battery during XO storage
Really need some essential data before diagnosing and testing this, because the ambiguity leads to an explosion of combinations that make it impractical, so please answer these questions: 1. what is a serial number from the batch? (I don't have access to records that identify Elaine, but I do have a list of serial numbers and associated data). 2. what version of OLPC OS was installed? (You didn't say, and it is critical). 3. what was the symptom that led you to determine the laptops needed debricking? 4. what was done with serial adapters to debrick them? 5. did you install the latest firmware at the same time as debricking them, or did you leave the laptops with the same problematic firmware? 6. if you left the laptops with the same problematic firmware, can you please explain why? Do ask your contacts in the deployment to get these answers if you can't supply them, thanks. It is my hope that I can tell you how to approach the situation now, and in the future. On Mon, Dec 09, 2013 at 08:19:32PM -0800, Nancie Severs wrote: > Sorry, I'm still traveling and had not checked these posts lately. I hope my > explanation here is helpful. > > I refer to the 1000 plus XO-1's that Elaine N/Cambodia received (she says from > Walter) in 2008. My observation comes from these facts: > > The Cambodia deployment has kept many of these original XO-1s in their > original > shopping boxes, unopened, unbooted and to date has perhaps 200+- still > undistributed to projects or children. When the boxes are opened to for > example > distribute 20 of these XOs to a new project, as they did in March of 2013, > then > the XOs charge, and boot fine to the originally installed Sugar OS. The system > date can be set & the laptops can be reflashed to the desired build. (I don't > know what date shows up when they boot. I have not been present at the opening > of the stored laptops.) > > These laptops will work if used continuously. But this is what has happened to > laptops from this original 1000+ group (I don't know the stats of what was > originally received.) Like a G1G1 XO in the US that was booted, used a bit and > then stored, the Cambodia XOs from this group will brick if stored long enough > for the clock battery to completely discharge. In Cambodia's case, some XOs > distributed to a project that were unused after some time, were returned to > the > project village teacher/director. They were bricked. Other Cambodia projects > also report having some that were put away for whatever reason and are > bricked. Adam & I taught the repair & I left a serial adapter in Cambodia for > sharing among the several and distant locations (but had only one I could > spare). > > (By the way, when unpacking brad new stored XO-1s they are finding the blotchy > screen problem in about 1 in 5 of these long stored XO-1. There is another > thread on this conversation.) > > For whatever reason, the bricking occurs when the laptops are stored AFTER > being booted. I don't htink it is practical to remove the clock bateery for > storage. For large #'s of XOs, the labor involved removing clock batteries > from > the motherboard & the risk of popping the battery holder off the motherboard > and sometimes breaking it or otherwise damaging the motherboard makes this > impractical. > > Note, that once debricked, the same XOs will not brick again. > Nancie:) > Nancie Severs > OLPC Support Volunteer > > > On Tuesday, December 10, 2013 8:08 AM, James Cameron wrote: > Summary: a method for storing an XO-1 by turning off the RTC; remove > the main battery, and the RTC battery for five seconds and then > replace it. Store without turning on. > > On Mon, Dec 09, 2013 at 09:00:20AM -0500, Nathan C. Riddle wrote: > > On Sun, Dec 8, 2013 at 10:44 PM, James Cameron wrote: > > > On Fri, Dec 06, 2013 at 08:52:34PM -0500, Nathan C. Riddle wrote: > > > > I noticed this in Nancie's blog on Planet about her current trip > > > > to Cambodia: > > > > > > > > "And because the Cambodia XO-1 laptops are susceptible to > > > > bricking if stored AFTER THE FIRST BOOT, it is important that > > > > everyone know those laptops are not broken and should not be > > > > scrapped." > > > > > > It would be interesting to see which particular type of bricking > > > Nancie is talking about there. I have no further details from > > > her. There are many causes leading to bricking, and they aren't > > > all related to the RTC battery that you focus on in the rest of > > > your post: > > > > > > > This brings to mind a puzzlement : > > > > > > > > XO's recently received in unopened boxes and manufactured in > > > > late 2008 or early 2009 had RTC batteries sufficiently charged > > > > to properly boot the XO-1 without any date / time error. > > > > > > No, it would be more correct to say that those XOs were > > > manufactured with a version of the firmware that does not fail in > > > the same way as earlier firmware. > > > > The RTC batteries in the recei
Re: [support-gang] Real time clock battery during XO storage
On Mon, Dec 09, 2013 at 10:04:28PM -0500, Richard A. Smith wrote: > On 12/09/2013 08:07 PM, James Cameron wrote: > > The symptom is that pressing the power button gives about a one > > second pulse on the power indicator, then it goes blank. There is > > no serial cable output from the processor. > > Take a look at the EC output. It won't be as verbose as later > generations but might provide some clues Thanks. Indeed it does. We are hitting WorkingTimeout. The power LED is driven for about 860 to 880ms. !!POI!! 2003- Ver:1.2.1 WDT:0 BootDeepSleep 15437:SCI:01 15437:SCI:20 15437:PwrInit2 DEEP_SLEEP -> RUNNING_STATE 15559:PwrUP 15599:Seq t30 PrepSysIO MAIN_ON disable 15604:MAIN High 15805:Seq t200 16017:SysWork WorkingTimeout SysPwrOff MAIN_ON OutLOW 16730:MAIN Low wake wlan 16755:SCI:20 -> D_S_STATE Yawn..z > > >The laptop starts fine with the RTC oscillator stopped, provided it > >stopped because of removal of the RTC battery. It just won't start if > >the RTC oscillator is stopped by writing to RTC control register. > > Seems to me that this is may be some sort of OFW issue. I seem to > remember that we store some state in the RTC memory that is checked > at early startup. Just stopping the OSC would leave the memory as > is (I think). Perhaps that confuses OFW and its waiting for the > something to respond that never will. I like that idea, but I'm not getting a peep out of OFW. OFW doesn't touch the RTC until the startup chain, which happens after serial output begins. (i.e. after the 'i' to interact point). > >Speculation: the XO-1 embedded controller is not detecting a 32 KHz > >signal from ball C8, GPIO27, or is not detecting some other normal > >response of the processor, and is abandoning the power up. > > Nope. Not for XO-1. Thats the SCI# signal and its an output from > the EC (and not used). Unlike 1.5 and beyond in XO-1 there is > minimal feedback to the EC about the state of the CPU booting. It's > mostly just EC timers. I won't say its impossible but I don't have > any memory of anything like that and a quick look at the system > power up code doesn't bring back an memories. Thanks, I'll have a closer look at the code. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [support-gang] Real time clock battery during XO storage
On 12/09/2013 08:07 PM, James Cameron wrote: The symptom is that pressing the power button gives about a one second pulse on the power indicator, then it goes blank. There is no serial cable output from the processor. Take a look at the EC output. It won't be as verbose as later generations but might provide some clues The laptop starts fine with the RTC oscillator stopped, provided it stopped because of removal of the RTC battery. It just won't start if the RTC oscillator is stopped by writing to RTC control register. Seems to me that this is may be some sort of OFW issue. I seem to remember that we store some state in the RTC memory that is checked at early startup. Just stopping the OSC would leave the memory as is (I think). Perhaps that confuses OFW and its waiting for the something to respond that never will. Speculation: the XO-1 embedded controller is not detecting a 32 KHz signal from ball C8, GPIO27, or is not detecting some other normal response of the processor, and is abandoning the power up. Nope. Not for XO-1. Thats the SCI# signal and its an output from the EC (and not used). Unlike 1.5 and beyond in XO-1 there is minimal feedback to the EC about the state of the CPU booting. It's mostly just EC timers. I won't say its impossible but I don't have any memory of anything like that and a quick look at the system power up code doesn't bring back an memories. -- Richard A. Smith Former One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [support-gang] Real time clock battery during XO storage
Summary: a method for storing an XO-1 by turning off the RTC; remove the main battery, and the RTC battery for five seconds and then replace it. Store without turning on. On Mon, Dec 09, 2013 at 09:00:20AM -0500, Nathan C. Riddle wrote: > On Sun, Dec 8, 2013 at 10:44 PM, James Cameron wrote: > > On Fri, Dec 06, 2013 at 08:52:34PM -0500, Nathan C. Riddle wrote: > > > I noticed this in Nancie's blog on Planet about her current trip > > > to Cambodia: > > > > > > "And because the Cambodia XO-1 laptops are susceptible to > > > bricking if stored AFTER THE FIRST BOOT, it is important that > > > everyone know those laptops are not broken and should not be > > > scrapped." > > > > It would be interesting to see which particular type of bricking > > Nancie is talking about there. I have no further details from > > her. There are many causes leading to bricking, and they aren't > > all related to the RTC battery that you focus on in the rest of > > your post: > > > > > This brings to mind a puzzlement : > > > > > > XO's recently received in unopened boxes and manufactured in > > > late 2008 or early 2009 had RTC batteries sufficiently charged > > > to properly boot the XO-1 without any date / time error. > > > > No, it would be more correct to say that those XOs were > > manufactured with a version of the firmware that does not fail in > > the same way as earlier firmware. > > The RTC batteries in the received (unopened boxes) XO-1's appeared > not discharged after more than 4 years, since the XO turned on and > booted with no "system date error". I'll rephrase; an XO turned on and booted without "system date error" is not _proof_ that the RTC battery was not discharged. It depends on the firmware version, the manufacturing tags, and whether it was powered up since the RTC battery was inserted. > I think a manufacturer would expect more than 2.5 months for > distribution of a laptop. Not this one. We're different. ;-) The 2.5 months is for the XO-1.5, the XO-1 is 4 months, and the XO-1.75 is 12 months ... you had not been specific about model, so I chose the minimum. Rather than use a primary battery that would require replacing, OLPC used a rechargeable battery. The laptops were intended to stay with the learners. Also, laptops were intended to be manufactured immediately prior to deployment. > Yes, these would have had the later firmware allowing boot with > discharged RTC battery, but all XO-1's that I have seen would have > displayed an system date error message. So, the observed was > perplexing. > > > > > Get me a serial number, and I can read from our database what > > version of firmware was flashed by the factory. > > > > Given the time since manufacture, the RTC batteries will be > > entirely discharged, and the newer firmware on those laptops > > doesn't consider that to be a problem, especially as all the > > registers of the RTC will be invalid rather than just one or two. > > > > > Yet, RTC batteries charged for 30 hours (XO on and not asleep) > > > at the end of a school year discharged by the start of school in > > > the fall (main battery stored separately). > > > > How long is that? I don't know the length of the school year you > > refer to, nor which hemisphere it is in. (fall = autumn). > > June 1 to September 1 is storage time. Three months. Every three month storage time will degrade the RTC battery more. If you have been in the habit of doing this over several years, then the battery will have aged more rapidly. Stopping the oscillator will reduce the problem. > > In the scenario you describe (main battery stored separately), 2.5 > > months is the expected minimum operating time, at the start of the > > product life. This will degrade as the product ages. It will > > more quickly degrade if the RTC battery is ever fully discharged, > > or stored at temperatures outside the specifications for the > > laptop. > > > > Five years after manufacture, I'd expect a minimum operating time > > of about three to five weeks. Yet another reason not to bless the > > learners with XO-1s. > > > > Once the RTC voltage falls sufficiently, bit rot occurs in the RTC > > registers, and this gives a completely different error to a fully > > discharged battery. > > > > > This suggests some sort of "unpacking" similar to the first boot > > > on a PC or an XO tablet. > > > > I disagree, there are other explanations for what you describe, > > which I have detailed above. > > > > There is yet another explanation; that the RTC batteries vary in > > how much they exceed the battery manufacturer's capacity > > specification. > > > > (Yes, there is a first-boot expansion of the filesystem on XO-1.5, > > XO-1.75, and XO-4, but this has nothing to do with the operating > > time of the RTC in the absence of the main battery.) > > > > > If so, is there a way to set parameter(s) in firmware back to > > > the factory value so the RTC battery does not discharge during > > > storage ? > > > > No, there
