I'm down in Uruguay this Xmas.

2015-12-09 Thread Richard A. Smith
I'm going to be spending my Christmas holiday on the beaches of La 
Paloma, Uruguay.   I'll be there Dec 24th - Jan 3.


One of those days my girlfriend and I plan to go in to Montevideo and 
look around the city.


I'd love to get a tour of the Plan Ceibal offices and chat, lunch, or 
dinner, with anyone still around who's working with XO's.


I've sent mail to various people I had contact with, Miguel, and to the 
stock email address cei...@ceibal.edu.uy.  Most of the emails bounced 
and the response from the ceibal@ address was that they would pass my 
info on to people on the project.  However, I've not heard back from 
anybody.


Anyone here know of someone I could contact @Ceibal who's involved with 
the XO's they have?


--
Richard A. Smith  <rich...@laptop.org>

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [Server-devel] [XSCE] activation server feature XSCE 5.0

2014-07-07 Thread Richard A. Smith

On 07/04/2014 07:36 PM, Sameer Verma wrote:


  I think the next step in diagnosis will be to find out what the XO
  does during the activation step, find out how XS-0.7 implements this,
  and ensure XSCE does as well.
 

A quick note. I remember that with XS 0.7 running on CentOS6.x it had to
be the 32 bit OS. Reuben Caron may know more.


I ran into this problem when porting the OLPC activation server from 
running on a 32-bit VM to running natively on owl.laptop.org which is 
64-bit.


The issues were with the toms libs that did all the crypto and optimised 
math.  They would not produce correct results in earlier 64bit releases. 
 This was fixed in later versions.


I can't remember the gory details but there's some tweaks that need to 
be made to the makefile and to pysign but after that it works.


Looking at my build of bios-crypto on owl I still have the changes 
should anyone want to build a package for 64bit.


--
Richard A. Smith  rich...@laptop.org
Former One Laptop per Child
___
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel


Re: Xubuntu on OLPC X-1

2014-07-02 Thread Richard A. Smith

On 07/01/2014 10:51 AM, Hellânio Costa wrote:

Thanks for listening,

Well, apparently I better go from idea to use fedora with xfce, but it
becomes unfeasible to use sd card in each device and therefore we
restricted the internal memory of the notebook.

I believe a teacher contact Ricardo Carrano can I get a case of
successful use of these notebooks.

The most important thing now is to get a developer key for me to use the
OLPC OS Builder and leave the system as clean as possible.


With the exception of Postal Mail one of the procedures listed here:

http://wiki.laptop.org/go/Activation_and_developer_keys

Should get you a developer key.

If you want to get keys for a lot of machines all at once then you 
should follow the collection stick procedure here:


http://wiki.laptop.org/go/Collection_stick

If you have any problems with getting the collection stick to work a 
very, very common failure is just a USB disk that behaves badly.  There 
are both hardware problems or formatting problems that can trip up the 
procedure.


If the collection stick doesn't seem to work then try a different USB 
disk.  If that doesn't help then just report back your scenario here and 
someone will be able to help you sort out where the problem is.


--
Richard A. Smith  rich...@laptop.org
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

2013-12-09 Thread Richard A. Smith

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  rich...@laptop.org
Former One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [Server-devel] [XSCE] Reflashing over a network

2013-08-29 Thread Richard A. Smith

On 08/29/2013 04:45 AM, Tony Anderson wrote:


The real advantage of wireless 'flashing' could be that a roomful of
laptops could be flashed concurrently as in NandBlast. I assume that
NandBlast is using the broadcast capability of the network. This is
getting beyond my understanding of networking, but wouldn't it be
possible to implement the 'sender' side of NandBlast on the server and
have it start broadcasting the image.


Nandblaster is much more complex than a simple broadcast.  It does use 
broadcast but it does it in as low level and as raw of a format 
possible.  The reason is that wireless is lossy and broadcast packets 
have no means of ack from the clients.  To compensate nandblaster uses 
forward error correction where it sends extra information with each 
block(s) of data. You can sort of think of it as RAID 5 for wireless. 
The actual amount of data is configurable but and example would be that 
for every 2 blocks of data 1 extra block is sent that allows you to 
reconstruct the 2 blocks of data from any of the 3 blocks.  In that case 
you could sustain a 33% data loss and still get 100% of the data.  But 
you have also decreased your throughput by that same 33%.


In order to make this scheme work you have to turn off a whole host of 
things that are stock with wireless.   The wireless card in XO-1 allowed 
operation at a very low level.  The cards in XO-1.5 and beyond had 
varying degrees of that low level functionality making it more difficult 
to make nandblaster TX work.


Over time I think some of those limitations were dealt with.  I've lost 
touch of the complete state of nandblaster.  James can perhaps update 
with exactly what works and what doesn't.


Getting a good nandblaster in a noisy wireless environment can be very 
tricky.  Unless you get 100% data the client has to wait an entire cycle 
of the image to pick up the missing blocks.  That can be a long time. 
But if you crank up the error correction so your 100% reception rate 
goes up the overall programming time still suffers because for 99% of 
the image data you sent error correction that was not needed.  You can 
quickly end up sending double the original image size.


When the image size increased in XO-1.5. Mitch Bradley and I spent a lot 
of time working on a wired version of nandblaster for the factory 
production line. (At the factory XO's were flashed via USB wired network 
adapters)  While it worked it was a bit twitchy based on what sort of 
equipment was in between the server and the XO clients.  Broadcast and 
multi-cast packets are not handled optimally by a lot of equipment.


We were able to get a lower programming time by using fiber-optics to 
the programming rack and a server that could handle the IO requirements 
of many stock http: connections sending the same file.  That eventually 
gave way to a gang programmer for XO-1.5 SD cards and then for XO-1.75 
and XO-4 the factory now preps a bunch of USB flash drives and uses those.


USB flash drives have the unique ability to scale perfectly with the the 
number of XOs you want to program at once.  It actually turns out to be 
cheaper than a bunch high performance equipment too.


Somewhere in the repositories we have the code (linux) that will 
generate a image file with the forward error correction and a server 
that will broadcast that image onto any network that can do multi-cast. 
 I think that should work with any wireless setup as long as its 
configured to allow multi-cast ranges.


The XO (OFW) client would night need some love as its not been used 
since 1.5.  IIRC the changes to stock nandblaster were not that 
extensive.  One could also make a tiny linux version of the client that 
you could netboot and do it that way although net booting in the face of 
massive multi-cast traffic might be problematic.  Perhaps you could load 
the tiny-linux client via USB and then let it join the multi-cast network.


If you have a lot of XOs to program and you don't require speed then a 
nandblaster type solution is very workable.  Its slow but requires very 
few resources.


Again I'm hazy on the current state of nandblaster so someone else will 
have to tell you how much effort is needed in the XO firmware to make 
that something that might be compatible with an XS broadcaster.


--
Richard A. Smith  rich...@laptop.org
Former One Laptop per Child
___
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel


So long and thanks for all the fish.

2013-06-19 Thread Richard A. Smith
This is my public announcement that I'm leaving OLPC. I have accepted a 
new position at Bobo Analytics.  My last day with OLPC is the 21st.


At Bobo I'll be working along side with Ed McNierney and Mitch Bradly so 
it won't feel too far away from OLPC.


The last 6.5 years have been an amazing journey.  There really aren't 
the words to express it.  I'm extremely honored to have had the chance 
to work at OLPC and been able to work with some of the most amazing 
people I've ever met.  I'm proud of what OLPC, its associates and 
volunteers have been able to accomplish and I'll always carry fond 
memories of my contributions to the project.


I'll continue to lurk on IRC and you can still reach me by my 
rich...@laptop.org address.  If that stops at some point then 
smithb...@gmail.com will be around as long as google keeps it.


Take care everyone.
Richard.

--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [Server-devel] help us finalize XS Community Edition version 0.3

2013-05-11 Thread Richard A. Smith

On 05/10/2013 05:10 PM, Holt wrote:


Now we're getting towards the halfway point of our community's 4th Hack
Sprint outside Toronto here ( photos @
http://haitidreams.wordpress.com/2013/05/09/school-server-community-edition-toronto-hack-sprint-begins/
) hoping for testers across XO-1 (maybe!), XO-1.5, XO-1.75 and XO-4 --
as things become much more reliable in coming weeks.


I've got XO-4s. I can test with.  I'll be happy to try it if things are 
far enough along.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel


Re: activation.laptop.org downtime Monday 2013-04-08

2013-04-08 Thread Richard A. Smith

On 04/04/2013 04:42 PM, Richard A. Smith wrote:


Monday, 2013-04-08 activation.laptop.org will respond with an error to
any activation requests.  It should be back up and running normally on
Tuesday. 2013-04-09.


Activation is back up and running.  The old server is in read-only mode 
if you connect and you get errors then your DNS has not updated yet.


The new IP for activation.l.o should resolve to 18.85.2.163

--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


activation.laptop.org downtime Monday 2013-04-08

2013-04-04 Thread Richard A. Smith
OLPC has has an upgrade of activation.laptop.org planned but it always 
seems to be in use when we try to schedule.  Switching the machines 
requires a full backup and then restore with the database off-line so 
there will be a service outage.


Since there is no best time I've declared that we just go ahead and do it.

Monday, 2013-04-08 activation.laptop.org will respond with an error to 
any activation requests.  It should be back up and running normally on 
Tuesday. 2013-04-09.


Moving to the new hardware should help with decreasing the time when 
large chunk of lease renewals is requested.


Thanks.

--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Developer key request issue ?

2013-04-03 Thread Richard A. Smith

On 04/03/2013 03:37 PM, lio...@olpc-france.org wrote:


Hi all,

Is there any issue with the Activation Service?

I asked a developer key for a XO-1 about 72h ago and I can’t retrieve
the key.

I’ve got the message: “Your developer key will be ready in 0 minutes.
Please check back later.”


You are behind a 71k laptop lease generation request.  Which looks like 
it still has another 40 hours to go before it finishes.  If you 
absolutely gotta have it now then send me your serial number and I'll 
see if I can get it generated for you.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Auckland Testing Summary 23 March 2013

2013-03-25 Thread Richard A. Smith

On 03/25/2013 02:03 PM, Richard Smith wrote:

Battery life on XO-4 C2 seems significantly improved over previous builds.
We would be interested in a confirmation or otherwise of this in the power
log analysis.


I guess you are comparing to 13.1.0 build 36?
The big difference here is that 13.1.0 build 36 has automatic power
management disabled, it is now enabled in 13.2.0 (not 100% stable just
yet, but we continue to shake out the bugs).


Its probably the firmware change rather than a build specific change.
We turned off unused cores and in q7b23 and that made almost 800mW
worth of difference across the board in operational power draw.  I'll
do a plot of your power logs though and confirm.


It appears there is considerable difference between your previous tests 
and now.  Last round of logs I have from you prior to this one was March 
2nd and prior to that was November 15, 2012 is that correct or did I 
miss a batch between November and March?


Here's a ploy of XO-4 only 13.1.0-32 vs 13.2.0-1 all your other XO-4 
13.1.0 builds I have were very early and not really interesting from a 
power standpoint.


http://dev.laptop.org/~rsmith/auckland_13.1_vs_13.2.png

Your peak decreased which I believe is from your firmware upgrade but 
does not explain the whole story.  A closer look at your log file shows 
a much, much higher suspend frequency in 13.2.  In your 13.1 tests you 
had perhaps 1 or 2 suspends whereas in the 13.2 log files almost every 
other line is a suspend event.


You didn't change your testing procedure did you?  Something that would 
allow for more idleness?


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [support-gang] Customization Sticks fails on 13.1.0 12.1.0 for XO-1

2013-03-11 Thread Richard A. Smith

On 03/11/2013 10:26 AM, Daniel Drake wrote:


would have to be signed by OLPC or Reuben would have to give them a Haiti
key thats installed via keyjector.


This is not a new situation for us, and the approach we have taken in
the past is to help such deployments un-secure all of their laptops,
or provide a keyjector to insert custom keys, upon their request.


Nod. Kejector for small deployments is new to me.  I thought keyjector 
was only for special cases.


I don't think most of the folks on say the support-gang list have any 
idea that keyjector is an option for them.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Possible fix for Gray dots forever problem

2013-03-11 Thread Richard A. Smith

This bug is is Trac #12618

When Nancie was at Twine she left me an XO-1 with this condition.

Based on Adams observation that laptops in this state also seem to 
ignore the power button I suspected that powerd problems were the root 
cause.


The root of the problem appears to be that the system date on the 
affected laptop was set to sometime in 1968.  This date is prior to the 
unix epoch date of 1970 and therefore all the timestamps were negative 
causing powerd to ignore all events.


Updating the system date to be current fixed both problems.

The mechanism for how this happens is currently unknown. In general the 
Linux kernel on our machines ignores the century field from the RTC and 
adds 2000 to the year value.  I was unable to find a setting of the RTC 
that would make linux read 1968 for the date.


The proposed fix is to either set the date from OFW using

ok ntp-set-clock

(you need a valid wifi or USB ethernet network)

or by using the check key to boot to linux and doing:

date --utc --set=-MM-DD HH:MM:SS
hwclock --systohc

The hwclock --systohc is necessary because 'date' only updates the 
systemclock and not the RTC.


If this fixes it I would recommend a reinstall of the OS after you do 
this to reset the date on a lot of files that that created when the OS 
first boots.  The funky date may cause other problems yet undiscovered.


Nancie:  You can help us figure out how this happens.  Before you try to 
fix your machines that have this problem please boot them (holding the 
check button) and look to see what the system date is set to.  Load up 
terminal and run 'date'

If the year is less than 1970 please do the following:

dmesg  dmesg-n.log
(where n is a number for each log file)
sudo hwclock -r

Send me the dmesg output files and the dates reported by hwclock

If the date is not less than 1970 please hold that machine for further 
inspection.


Hope this helps.

--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [support-gang] Customization Sticks fails on 13.1.0 12.1.0 for XO-1

2013-03-11 Thread Richard A. Smith

On 03/11/2013 10:08 PM, John Watlington wrote:


Nod. Kejector for small deployments is new to me.  I thought keyjector was only 
for special cases.

I don't think most of the folks on say the support-gang list have any idea that 
keyjector is an option for them.


I don't think it is an option.   A keyjector should not be made publicly 
available.


That is more along the line of what I thought was status quo.


Please don't redistribute secure laptops --- OLPC's policy since early 2009 has
been to deprecate the security system.   The exceptions have been deployments
large enough to have dedicated support staff capable of handling their own 
keys.


That policy is fine but perhaps needs to be more visible to the people 
going into areas where secure laptops were distributed and we should try 
to be helpful to those people when they request developer keys.


The point of my comments was clarification that olpc-os-builder is not 
an end all solution to the lack of the customization key not working 
anymore and should not be offered up as such.


Doing customization by a bash script after boot is a fine solution and 
now people can invest time in polishing that script.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [support-gang] Customization Sticks fails on 13.1.0 12.1.0 for XO-1

2013-03-11 Thread Richard A. Smith

On 03/11/2013 10:48 PM, John Watlington wrote:


That policy is fine but perhaps needs to be more visible to the
people going into areas where secure laptops were distributed and
we should try to be helpful to those people when they request
developer keys.


If someone isn't being helpful about providing developer keys, let me
know.


No specific instances that I know of but for some of these people its a 
daunting task especially if they have limited Internet.  Just a friendly 
reminder that some of these people may need a bit of hand holding.  I 
know because I've helped several of them in the past and sometimes it 
can be a bit frustrating. :)


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [support-gang] Customization Sticks fails on 13.1.0 12.1.0 for XO-1

2013-03-10 Thread Richard A. Smith

On 03/09/2013 01:35 PM, Kevin Gordon wrote:


I seem to remember from the devel list that martin and Daniel said
there are no plans to re-enable it.  The future is OOB.


Chopping the list down to just devel@ for my comments.

Perhaps I don't understand but I don't see how OOB can work for a setup 
like Adam is describing in Haiti where they have laptops in the mix that 
are secure.  Unless they first un-secure every laptop a custom OS build 
wth OOB would have to be signed by OLPC or Reuben would have to give 
them a Haiti key thats installed via keyjector.



--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: 13.1.0 development build 18 released

2012-12-14 Thread Richard A. Smith

On 12/11/2012 08:33 PM, James Cameron wrote:


Thanks for the logs off-list, I've reviewed them.  You hit a known
problem that has since been fixed.  The battery low status bit was not
necessarily cleared despite charging commencement.

This was fixed in
http://dev.laptop.org/git/users/rsmith/ec-cl4-mmp3/commit/?id=f3a823876d2084fd0b22e79f75bfc05f32b7626d

which was between EC 0.3.04 and EC 0.3.05.  Q7B07 contained the
former, and Q7B08 contained the latter.


I'm going to have re-do that and qualify the clear with a SOC 10 
conditional. I've realized that clearing the flag unconditionally 
bypasses OFW's check to make sure that the battery is not low prior to 
starting a firmware flash.  A battery that was very low but just plugged 
up to power should still be considered low.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [Sugar-devel] [TRANSIENT ISSUE] 3G-Modem not being recognised

2012-11-21 Thread Richard A. Smith

On 11/21/2012 02:40 AM, James Cameron wrote:


Perhaps this service provider can provide technical support?


If it's as simple as adding a single entry to powerd's usb-inhibits
file like how 'hid' is treated then why has this not been done?


My guess is priorities are elsewhere in the stack at the moment, and
we have very few deployments demanding this be fixed.


I don't think having an end-user with no experience with USB IDs add
an entry to the usb-inhibits file, or having to remember to turn off
a major feature is the correct long term solution IMHO.


Certainly not.  I didn't think you or Ajay were end-users though.  My
advice to end-users would be to wait for the problem to be fixed, or
ask their deployment technical people to turn off the major feature
permanently, or build a fix.



In the previous thread this was discussed in  (See Patch: Mobile 
dongles) the proposal was that inhibit would be triggered by the 
presence of module 'usb_wwan'.  Jerry submitted patches that did that. 
Paul was wondering if there was a better way than looking for a module 
loaded.


Powerd already has a mechanism where it disables suspend while an 
association is in process and Paul was wondering if you could leverage 
the existing infrastructure for this.


The thread dies after that.  So I think anyone wanting this to get 
integrated as a stock feature should investigate if you can use a NM 
hook to send the DBUS message to powerd to inhibit.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [Sugar-devel] [TRANSIENT ISSUE] 3G-Modem not being recognised

2012-11-21 Thread Richard A. Smith

On 11/21/2012 01:07 AM, Jerry Vonau wrote:



Dropping the power to the usb bus is making the modem play peek-a-boo
with the kernel: http://dev.laptop.org/ticket/10708.
http://dev.laptop.org/ticket/10708


And just to be clear its more than just a power dropping problem.  Both 
1.75 and XO-4 both have the ability to keep the USB bus powered during 
suspend (with an EC firmware change) but on resume the kernel resets the 
USB bus.  I don't know if the kernel has an option not to do that.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Xo1.5 crashes

2012-10-08 Thread Richard A. Smith

On 10/07/2012 10:21 PM, Mikus Grinbergs wrote:


IIRC, Richard warned about connecting an XO's USB socket to any USB
device where that devices's USB socket can emit power (that sets up a
 condition where a non-XO device can try to send power to the XO --
which is a no_no).


The details are fuzzy but in Kevin's case I believe he was trying to use
a external CDROM that drew a lot of juice tying to spin up and fail.  To
compensate he was connecting one of those rechargeable batteries with a
5V USB output via a Y cable.  So now you have 2 power sources fighting
it out on the USB bus and the XO-1.5 would lose.


So when i plug one usb device into the xo be it an ipod or a cell
phone while running on battery the screen goes white and the laptop
reboots. It works fine when plugged in charging though. I just wanted
to let you all know what im experiencing. I believe the devices are
drawing too much current from the laptop and forcing a reboot. It
doesnt matter which usb port i plug it into.


What production rev model is your 1.5?  Did you get it from the 
developer program?  I have a vague recollection that some of our earlier 
runs of 1.5 had a USB issue like that.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Attempting to re-purpose former XO 1.5 4GB microSD cards.

2012-09-16 Thread Richard A. Smith

On 09/16/2012 09:57 PM, Kevin Gordon wrote:


Therefore, I fear that I must have been an ESD devil this morning when I
took the cards out of the machine, and fried them by not taking
recommended precautions.  I can think of no other plausible reason. But,
it appears it's just these two cards, and not the process.   Next time,
no skipping the wrist strap.  Sorry for the bother.

Aaargh .. but thanks again for answering quickly and adding even more
doisk management  tools to the arsenal.


I doubt it was ESD.  Rather I suspect you were hit with what our 
manufactures called an SPO or sudden power off.  I suspect the card 
power bounced while the FTL was moving some blocks around.  You don't 
actually have to remove the card for this to happen as the power to the 
card socket is software controlled.


We dealt with this numerous times while qualifying SD cards.  The EC in 
the XO keeps the power up on the SD card for several seconds after the 
main power it turned off to help prevent this from happening.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Blinking red battery light on XO-1

2012-08-04 Thread Richard A. Smith

On 08/03/2012 11:38 PM, Hal Murray wrote:


I have a hack script that reboots the XO every 4 hours.  It's got a patch to
check
   /sys/class/power_supply/olpc-battery/error
and log the answer instead of rebooting.  The error was 20

(Sorry I didn't remember to look there earlier.)


20 is 0x14 which is bank zero error.  I think you are the 2nd person to 
report a transient bank 0 problem.   Thats odd since I would expect a 
bank 0 error to be permanent.  The code does several re-reads before 
giving up and throwing the error.  From errors that dsd has reported 
I've been suspecting that there is some timing that may be marginal 
since a reset fixes it I wonder if there is something that is going 
wrong and messing up the 1-wire timing.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO battery/performance [Devel Digest, Vol 76, Issue 21]

2012-07-22 Thread Richard A. Smith

On 07/21/2012 12:53 PM, Yioryos Asprobounitis wrote:


I'm sorry but I did not run any  bg-acr! commands except the one you
 suggested. The only command that I run outside your suggestions is
bg-acr@ .bg-acr with no batman.fth/batman-start first, which
certainly can not account for the erratic behavior.


Commands _like_ 'bg-acr!' that includes all of the bg-* commands and 
many others.  They _require_ batman-start to function.  If it hasn't 
been called then they do it for you.  Thus if you have run those command 
and not run batman-stop then the charging system will behave 
erratically.  bg-acr! changes values that take the EC close to a full 
cycle to recovery from so even after a full reset the reporting can be 
incorrect.



I keep saying that the battery EC might have a problem


There is no battery EC.  The battery only has a sensor chip. The EC on 
the XO talks to that chip and reads voltage, current, temperature, ACR 
and a few other values.



and you just
dismiss all the indications (like a full battery reporting as empty)


I'm sorry if my last mail came across the wrong way I was in a bit of a 
hurry before my flight.


Its just that I keep telling you that nothing you have presented so far 
indicates there is a communication problem between the EC and battery. 
I'll be the very first to tell you when I see something I think is 
funky.  Just like with the rollover bug.


I'm not dismissing what you say. I'm just trying to tell you that you 
aren't doing anything useful debugging wise when you try to figure out 
whats going on based on the charging LED or what sugar tells you.  The 
use of _any_ of the debugging commands I gave you will screw up the 
normal battery reporting.


If you want to known whats happening when you boot Linux then please do 
a full power cycle and run olpc-pwr-log.  Those log files are much, 
much, more useful than what the LED/Sugar is doing.  The LED/sugar can 
lie to you but the log files do not.  Normally, I boot the laptop 
without the battery installed, run olpc-pwr-log and then insert the 
battery. olpc-pwr-log will wait for a battery to show up.



 including even the fact that EC reports the battery is asleep while
 the discharge data show that is not.


Its not possible for the battery to go to sleep.  I don't understand 
what you are referring to.



Oh well, I do not think that one battery in a couple of millions
worths all this trouble.


Actually I believe it is worth the trouble because there is never just a 
single problem that doesn't happen to another machine.  If you have this 
failure then there are probably many more.  Its just never been reported.


I'm happy to keep working on this if you don't mind the time.

--
Richard A. Smith  rich...@laptop.org
One Laptop per Child


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO battery/performance [Devel Digest, Vol 76, Issue 21]

2012-07-22 Thread Richard A. Smith

On 07/22/2012 04:29 PM, Yioryos Asprobounitis wrote:


As I said before, the problem needs an engineer if it is to be investigated any 
further, and I'm not.
You are welcome to the battery.


Ok.  Well then please send me the battery.

Richard Smith
One Laptop per Child
222 3rd St. STE 0234
Cambridge, MA 02142
+1 617-714-4589

Thanks for all your help so far.

--
Richard A. Smith  rich...@laptop.org
One Laptop per Child


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO battery/performance [Devel Digest, Vol 76, Issue 21]

2012-07-21 Thread Richard A. Smith

On 07/21/2012 03:05 AM, Yioryos Asprobounitis wrote:


- ok bg-acr@ .bg-acr (Should print zero)


ACR: -0.42


Hmm... I was expecting zero.  I'm traveling to Taiwan right now and
don't have 1.0 or 1.5 with me to check.


- Insert battery

- ok bg-acr@ .bg-acr


ACR: -0.84


.42mAh / 24 hours = 17.5uA so very low.  Does not appear to be a
hardware fault in the battery.


- ok batman-stop - Poweroff - Remove AC - 25 h battery IN the XO -
remove battery - Plug AC - Boot XO and stop at OFW - ok batman-start
- Insert battery - ok bg-acr@ .bg-acr

ACR -469.52


Assuming -.84mAh was where you started thats
468.68 mAh / 25h = 18.7mA which is just about what olpc-pwr-log
indicated was happening.

This really smells like the EC not going to sleep although I thought we
proved it was going to sleep with an earlier test.  (Low battery LED
going out when you power off)

Please dump the registers and EEPROM (bat-dump-banks) again and I'll
program them into a battery and test it on a XO-1.  No rush though I
won't be able to do anything with this for at least 2 weeks when I back 
in Boston and working.


Perhaps I'll think of some other thing to look at between now and then.


-insert battery - ok bg-acr@ .bg-acr (no batman.fth/batman-start)


commands like bg-acr@ require batman-start to work correctly.  If
batman-start has not been called then they will call it for you.  We
call it explicitly so that the charging system is disabled prior to
inserting the battery.


Booted up with battery, plugged AC,  power LED stays red.


This is an invalid condition.  With AC connected you should either have:

Blinking red: Error
yellow (some say orange): Charging
Green: Full

If its not one of the above then either the EC charging system is 
disabled in which case the LED values are somewhat random or your power 
adapter is not providing power.



Booted without battery, inserted battery, battery shows empty and
charging. Charged to about 15% slowly, then jumped to 81% and then
97% in under 1 min and the power LED turned green!

Now, you are going to say again that I do not know what I'm doing,
but sure none of these looks very normal behavior to me and may have
to do with how the battery communicates its state than its state
per se.


Yes and I'll continue to say it as long as you continue to do things
that are invalid and will produce nonsensical results.  I've told you a
few times that when you run commands like bg-acr! that you are modifying
important values outside of the EC and that until you do a full
discharge/recharge cycle normal reporting won't yield valid results.

The jumps are when the EC detects specific conditions and tries to reset
the SOC accordingly. Normal and expected.

If you want to understand whats going on the please run olpc-pwr-log so
you can observe the voltage and current and see when the EC changes
things based on those values.

--
Richard A. Smith  rich...@laptop.org
One Laptop per Child


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO battery/performance [Devel Digest, Vol 76, Issue 21]

2012-07-13 Thread Richard A. Smith

On 07/04/2012 12:20 PM, Yioryos Asprobounitis wrote:


0 bg-acr! solved the problem of the erratic reading.
Logs look more reasonable now (though there is still a sudden jump from 87 to 
96% during charging in one log.


Thats normal.  There isn't any calibration of the capacity as the 
capacity of the battery decreases.  So while charging its going to reach 
full sooner.  When its full the SOC is set to 97%.



Battery capacity looks also improved (2.8Ah in one run)


I don't see any of your logs that have 2.8Ah they all look like 2.5Ah 
and 2.6Ah to me.  Which log are you referring to?



However, the original issue of battery losing ~12% charge per day while in the 
XO with the laptop off, is there.


There is certainly something up with your battery.  The charging log 
shows where the problem is.  Look at line 386 in 
pwr-120703-010410-355aaa250043.csv . Thats where the battery stop 
reaches its full condition (Voltage@ 7.4V and current  120mA). 
Normally the status would switch to Full and the current would bounce 
around very close to zero.  Your battery however has a constant 
discharge current of 16mA.  So despite having the power connected your 
battery is slowly discharging.  This seem strange but its possible 
because when the EC detected the battery was full it turned off the 
mosfet that is in the charging path.  So the battery is isolated from 
the system.  Only when you unplug power does the mosfet re-engage so the 
battery can then supply power.


If you want to prove its the battery then try the same test on other 
XO-1s and on your 1.75.  Another test you could do is to see if the ACR 
changes with the battery removed from the laptop.  You can do this with 
batman.  The steps would be:


1) Connect XO 1 or 1.5 to external power.
2) Boot the machine and stop at the open firmware prompt
3) Allow battery to charge up up until full.
4) print out the ACR with:
  ok bg-acr@ .bg-acr
5) remove battery
6) record the printed ACR number somewhere
7) Note time of battery removal
8) Wait 24 hours.
9) repeat steps 1-4
10) subtract the 2 ARC numbers to the the net ACR.

According to your log your average draw is 16.4mA.  So if you let it sit 
for 24h I would expect your net acr to be in the range of 390 - 400 mAh 
(the number is in uAh so thats 39 to 40)


If it happens outside the XO then you know its in the battery. If not 
then its some interesting combination of battery and XO.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO battery/performance [Devel Digest, Vol 76, Issue 21]

2012-06-16 Thread Richard A. Smith

On 06/12/2012 12:26 PM, Yioryos Asprobounitis wrote:


OK Attached are the screenlogs from the serial output

screenlog.charging is yesterdays log whith half full to fully charged battery


2339275:LDACR Update request ACR:-19791 LDACR:-19792
2339471:GC_LDACR=-19792 SOC = 58
2470692:LDACR Update request ACR:-19722 LDACR:-19792
2470857:GC_LDACR=-19792 SOC = 95
2477403:LDACR Update request ACR:-19719 LDACR:-19720
2477565:GC_LDACR=-19720 SOC = 96
2665019:  LCS:8 CFC:4 CHG=1 Vb:7395 Vavg:0x5eb3
Bat Full

Your battery jumped from 58% to Full while only receiving around 30mAh 
of charge.  So it has issues.


For an older battery I would suspect charge balance symptom but your 
serial number starts with 008 which is beyond the lot of problem 
batteries and you have indicated you already ran bat-recover.


So either your battery was not really at 58% or its suffered a lot of 
capacity loss.


The next step would be to do a full discharge/recharge/discharge cycle 
while running olpc-pwr-log (stop powerd first) to measure the existing 
capacity.


A quick summary of the procedure:

- Boot laptop; stop powerd; run olpc-pwr-log; disconnect external power 
let laptop power off shut off.
- Remove battery;connect external power; boot; stop powerd; run 
olpc-pwr-log; insert battery; let charge to full;
- Ctrl-C to stop olpc-pwr-log; re-run olpc-pwr-log; disconnect external 
power; let laptop power off;


You can try to figure out the log files from the code I previously 
pointed you at or you can send them to me.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO battery/performance [Devel Digest, Vol 76, Issue 4]

2012-06-11 Thread Richard A. Smith

On 06/10/2012 01:07 AM, Yioryos Asprobounitis wrote:



Took some time and a lot of juggling and ended up to a lot of
questionmarks in black diamonds so I do not really know if I did it
right or wrong, but here is the screen log just the same.


You may or may not have done anything wrong but the output is not valid. 
 Perhaps your comm settings are wrong?  115200,n,8,1 is what they 
should be set to.  Its exactly the same as if you were connected to the 
OFW or Linux output.


The EC output is readable text and if you press enter with no command 
you get back a prompt.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO battery/performance [Devel Digest, Vol 76, Issue 4]

2012-06-03 Thread Richard A. Smith

On 06/03/2012 04:43 AM, Yioryos Asprobounitis wrote:


serial connector loaded.  Its
the connector under the heat spreader.


There goes my new XO-1.75...


Think of it a a rite of passage.


Just to be sure, is the UART 4, CN23, shown in the attached picture in blue. 
Correct?


Correct.


If OK, please advise further actions.


First upgrade the firmware to the latest version and let it update the 
EC code.


Then just plug up the serial connector and then do a full power cycle of 
the unit by removing both external power and the battery and then 
plugging in the problem battery.  Send the output.  May or may not be 
anything of interest in that log.


Then see if the problem duplicates on the 1.75.  You can get a quick 
reading from the EC of the battery level by using the command 'b3'. 
Type b3 enter which turns on some simple debug info.  You can't leave 
that on however because it will prevent the EC from going into stop 
mode.  'b0' will turn it back off.


You have to be really quick with the serial commands when the XO is off. 
 When off and running on battery the EC will go into stop mode and it 
does that really fast.  When its in stop mode you can't talk to it on 
the serial port.I usually have one hand ready to type b3 and then 
wake the EC up by a very short power button press.  Then before it goes 
back into stop mode type b3enter.  Once a second it will output a 
short battery stat then type b0 to stop it and allow it to go back into 
stop mode.


So hook up the EC serial port and log the output. Then charge up the 
battery. b3 to get some readings. Disconnect external power and then b0 
.  You should see it go into stop mode.   In 24 hours wake the EC up do 
b3 to get a 2nd set of readings and then send the log output.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Battery losing charge while off [Devel Digest, Vol 75, Issue 63]

2012-06-01 Thread Richard A. Smith

On 06/01/2012 10:12 AM, Yioryos Asprobounitis wrote:


Done
See attached screenshot.


I don't see anything that looks obviously wrong.  So here's a test to 
see if the EC is going to sleep or not.  Run the battery down to where 
the red LED is active.  Then power off the laptop.  If the EC goes into 
stop mode the red LED should go out after a few seconds.  If you press a 
game button the EC should wake up briefly and the led will turn back on 
then in a few seconds go back out.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO battery/performance

2012-06-01 Thread Richard A. Smith

On 05/30/2012 03:34 AM, Yioryos Asprobounitis wrote:


If you want an idea of low-level performance, I can suggest
running LMBench.



Got the Debian lmbench_3.0-a7 source that compiles and runs fine w/o bitkeeper.
Run the hardware part of the tests on the XO-1.5 (os880) and xo-1.75 (os12- 
correct kernel) with the same configuration.

What was striking was that the XO-1.75 used 25% of the battery for 1 run while 
the XO-1.5 used 65% of the battery!


If you are going to do more of this then you really need a better tool 
than just the battery SOC measurement.  olpc-pwr-log can sample the 
information on a periodic basis and then my processing scripts can run 
through those logs and produce various reports.


All of my tools are in my olpc-pwrlogs repo

git://dev.laptop.org/users/rsmith/olpc-pwrlogs

Let me know if you are interested and want to know how to use the tools.


Most of the test had empty values but the informative ones (below) show that 
the XO-1.5 is better in basic integer operations and memory bandwidth while the 
XO-1.75 is better in float and double operations as well as in memory latency.
I'm not sure how much this means for real life usage :-/


I'm very suspect of this measurement.  The 1.5 has a hardware floating 
point unit and the 1.75 is still using soft-float.  Its extremely 
unlikely that the floating point performance on 1.75 is better than the 1.5.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Battery losing charge while off

2012-05-31 Thread Richard A. Smith

On 05/24/2012 11:59 PM, Yioryos Asprobounitis wrote:


laptop serial number.   Was it a
pre-production XO-1 ?


Both XO-1s used to test the battery are C2 machines
#CSH7470023EA
#SHF80701C99
The batery in question is
#00802091012110003588


So let me review and see if I have all the details.  Seems like each new 
email has more new details.


- Battery does not lose charge outside the laptop.
- Tested the battery in 2 different laptops and the loss is the same. 
Roughly 12% overnight.

- A different battery in those same laptops does not lose 12%

--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Battery losing charge while off

2012-05-31 Thread Richard A. Smith

On 05/31/2012 08:18 AM, Richard A. Smith wrote:


So let me review and see if I have all the details. Seems like each new
email has more new details.


I'm asking you to verify that these facts are true based on your testing.


- Battery does not lose charge outside the laptop.
- Tested the battery in 2 different laptops and the loss is the same.
Roughly 12% overnight.



- A different battery in those same laptops does not lose 12%


In case its not clear.  If you have not done this test with a different 
battery in the 2 laptops then please do so.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Battery losing charge while off

2012-05-24 Thread Richard A. Smith

On 05/24/2012 02:56 PM, Yioryos Asprobounitis wrote:


One of my XO batteries (~2years old) is loosing about

12% of its charge in 24h period while the XO is off.

This is not related to a specific XO but rather the

battery itself.

How are you measuring the loss?


Just looking at the Sugar battery monitor in 2 XO-1s running 21011o0 and os880 
(but this one with FW updated to q2f08)



What happens if the battery is not installed in an XO?


Actually, it does NOT discharge when off the XOs !

I guess I should get some power logs.
Anything else?


So now that you know its not the battery what are the symptoms?
 You turn off the XO at night and then in the morning the battery is 
12% less?


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Battery losing charge while off

2012-05-23 Thread Richard A. Smith

On 05/23/2012 10:04 AM, Yioryos Asprobounitis wrote:

One of my XO batteries (~2years old) is loosing about 12% of its charge in 24h 
period while the XO is off.
This is not related to a specific XO but rather the battery itself.


How are you measuring the loss?

What happens if the battery is not installed in an XO?

--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [PATCH runin] Port to systemd

2012-04-23 Thread Richard A. Smith

On 04/23/2012 01:08 PM, Daniel Drake wrote:


runin does make a lot of effort to be started early, but it explicitly
pulls in olpc-configure as a dependency before being run. I helped
Richard with this when it was originally implemented. My systemd port
maintains the same behaviour.


In the very early days runin started before anything else so Wad and 
Martin you do remember that correctly.  Runin, however, uses X and in 
the move to a consolidated build for 1.0 and 1.5 X needs different 
setups to start.  Rather than duplicate that code in runin Daniel worked 
with me to move runin to after olpc-configure.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO-1.75 - Kernel news

2012-03-12 Thread Richard A. Smith

On 03/12/2012 11:22 AM, Martin Langhoff wrote:


Grepping the log of the ping sender, it had18K successful pings, and
127 failures. Not perfect, but not a bad ratio either.


this setup has survived the weekend, with successful ~43K pings vs
~1400 dropped pings. So 3.2% of the ICMP messages are dropped, this is
on an AP using WPA2.


Do you have serial or EC logs for the XO or any sort of wakeup loop 
counter? (Powerd tries to log suspend/wakeup but I'm not sure it gets 
all of them)  It would be interesting to know if the machine woke up but 
didn't respond or if it never woke up.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Impacts of disabling Automatic Power Management

2012-02-04 Thread Richard A. Smith

On 02/04/2012 12:13 AM, Sridhar Dhanapalan wrote:


What build are you basing your images off of?


We're building from Dextrose 3, which is in turn based on 11.3.0.

This version is still in development and hence isn't used in the
field. I'm not sure how useful data from the currently-deployed OS
(10.1.3) would be.


Its not as useful as it could be but its not useless.  There is a bug in 
10.1.3 where the time in suspend is not tracked correctly.


So from the logs we can tell how many times is suspended per second of 
run time but we can't tell the exact percentage of suspend time vs runtime.


Its still a place to start.  If you have lots of suspends/run time then 
you know that turning off aggressive suspend/resume will affect your 
battery life.  If you have few then it probably won't matter much.


Of course the ASR setting may not really matter.  Have you actually 
tested what your battery life is with the 3G modem connected up and the 
machine idle with ASR disabled?


I've heard that 3G modems suck quite a bit of power and USB itself sucks 
power.  With that extra load the savings you get from anything but a 
_lot_ of idleness may not really amount to much.


If you run a base line test then we can estimate what your life would be 
if for say you added 20% of idle suspend on top of that.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Impacts of disabling Automatic Power Management

2012-02-04 Thread Richard A. Smith

On 02/04/2012 12:28 AM, Sridhar Dhanapalan wrote:


Let's _not_ include it in the development builds, so developers and
testers suffer (and fix).

end users need not suffer.


+1 for this. This is negatively impacting classrooms. Teachers are
shying away from using collaboration. We don't have time to wait for a
'perfect' solution.


I wasn't suggesting that we don't come up with a workaround for your 
current problem.  I was commenting that adding a hook into sugars API 
that globally disables suspend while collaboration is active is headed 
in the wrong direction.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Impacts of disabling Automatic Power Management

2012-02-01 Thread Richard A. Smith

On 01/31/2012 11:43 PM, Paul Fox wrote:

sridhar wrote:
We are considering disabling Automatic Power Management because of its
impact on collaboration and 3G connectivity.
  
What kind of battery life can we expect from an XO-1.5 with Automatic
Power Management disabled as opposed to enabled? I understand that
this can vary wildly with usage, but is there an average estimate?

he's on a very long plane flight, but i'll try and channel richard:

 it depends.

how did i do?  :-)


You have learned well.

Sirdhar:  Unfortunately theres no way we can answer your question ( or 
even make a SWAG) without known how much idleness is in your normal 
workload.  Automatic Power Management only makes a big difference if 
there is a lot of time spent idle.  If you are running Tam-Tam the 
entire time then turning off aggressive suspend/resume will make zero 
difference.


powerd tracks this though so if you can collect some powerd logs from 
some of your users then we can make a guess at figuring out what your 
impact will be.


powerd logs are located in the ~olcp/power-logs directory.  Copy all the 
files in there off of several machines that have been used in the 
classroom and send them to me and we can take a look at what sort of 
profile you have.


What build are you basing your images off of?

--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Impacts of disabling Automatic Power Management

2012-02-01 Thread Richard A. Smith

On 02/01/2012 08:32 PM, Martin Langhoff wrote:

On Wed, Feb 1, 2012 at 6:08 PM, Sridhar Dhanapalan
srid...@laptop.org.au  wrote:

Maybe it should be
standard to suspend power management for any collaboration session?
That would be smarter than turning it off entirely.


I'd be supportive of a patch that does that.

Simon, given the collaboration API in 11.2.x, would it be possible to
keep a file in existence all the while that a collaboration session
exists?



While I understand the frustration, this is going to wrong direction. 
We need to hunt down the problems and fix them.


Its a good short term fix to be  enabled on a per-deployment basis but 
if this becomes the default then I worry  all our work on making 
aggressive suspend/resume work will begin to fade away because its never 
active.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Run OFW heat spreader test

2012-01-23 Thread Richard A. Smith

On 01/23/2012 01:32 AM, Sridhar Dhanapalan wrote:


On 23 January 2012 17:20, James Cameronqu...@laptop.org  wrote:

I thought you were doing this test to detect early units that may have
a failed heat spreader, and you were doing it at the time of reflashing
because that's when you had some control.


Yes, that's the primary reason. Our initial batch of XO-1.5s have an
inefficient heat spreader. They've been burning out, and replacing the
motherboards is getting expensive and time consuming. We'd like to
detect potentially faulty units early, and recommend a heat spreader
change for them.


Hmmm... Something else is the problem here.  You can't damage the 
processor via thermal overload because it has an automatic clock back 
off.  If you have motherboards that are failing its not due to a bad 
heat spreader.  At worst all you would get would be hangs.


Can you acquire the serial number of the failed motherboards or is that 
not lost?


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO-1 cpu temperature [Devel Digest, Vol 71, Issue 43]

2012-01-23 Thread Richard A. Smith

On 01/23/2012 02:56 AM, Yioryos Asprobounitis wrote:



The thing is that XO-1.5 has about twice the XO-1 processing power and is quite 
usable. So getting another 50%+ out of the XO-1 (albeit with risks) may keep it 
in stride with the new software versions a bit longer.
Of course I do realize that this should have nothing to do with OLPC, thus the 
vague questions ;)


It won't work that way.   Although in some cases you can increase the 
clock frequency a bit and have it still function the system is designed 
to run at the specified frequency.  We didn't use parts that were rated 
for 1Ghz and then dial it down.  We used the highest speed parts that we 
could get in our cost range and designed for that operating frequency.



But may be all this is irrelevant now as pushing  the XO-1 to 600MHz (extrapolating from 
these guys) results in kernel panics and/or errors.
If this is because of the protection mechanisms I would appreciate if someone 
lets me know off-list (I promise not to tell) of a possible way around it.


Its not a protection mechanism. Its because one of the system buses is 
corrupted because its being forced to operate above its design rating.


A thermal shutdown will be a hang since the clock to the CPU is stopped. 
The thermal shutdown is not configurable and you can't bypass it.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO-1 cpu temperature [Devel Digest, Vol 71, Issue 43]

2012-01-23 Thread Richard A. Smith

On 01/23/2012 04:20 PM, Mikus Grinbergs wrote:



Please (I'm trying to ask nicely!), can you all tell me what I need to
tweak to make customizing the olpc.fth (plus run 'rpm -U kernel...')
be effective on 12.1.0. [ I know how to make them work on 11.3.0. ]



Ah.. I misunderstood you.  When you said device I thought you were 
referring a to an OFW device tree device, like the device that lets you 
do MSR access.  I didn't realize you were talking about access to the 
boot partition.  I could help you with a firmware issue but I'm afraid I 
can't help much with 12.1.0.


The boot partition is supposed to be accessible via /bootpart/boot or 
/boot if its not then its just a bug that will get fixed up later. 
12.1.0 is still in its infancy.  I wouldn't expect much to work for quit 
a few more builds.


Like Martin's e-mail suggested you can open 'olpc.fth' in a small editor 
under OFW.  You can edit the file there and make your changes.  No Linux 
involved.  Although I'm not sure if that version of firmware can edit 
files on the bootpart correctly.  There have recently been a bunch of 
fixes for OFW  ext2/3/4 support.


Alternatively you could decompress the os image file on a desktop 
machine, edit the file and then re-compress it.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO-1 cpu temperature

2012-01-22 Thread Richard A. Smith

On 01/21/2012 09:58 AM, Yioryos Asprobounitis wrote:

I was wondering if there is anyway to monitor the geode temperature on the XO-1.
I would like to test how far I can push it without ruining it.


The CPU is protected by a thermal shutdown circuit it will shutdown 
before you cause any thermal damage.


Unless you are trying hardware modifications I doubt you will do 
anything worse than these guys.


http://www.olpcnews.com/forum/index.php?topic=2389.0

What exact are you going to try and push?

--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Run OFW heat spreader test

2012-01-22 Thread Richard A. Smith

On 01/22/2012 09:00 PM, Sridhar Dhanapalan wrote:

 We are using a custom olpc.fth to present a boot menu so that users
 can easily flash their XOs. As a precaution, we run a lid switches
 test before the OS installation begins. Some of our XOs have older,
 less effective heat spreaders, and we would like to catch these before
 they get burnt-out by the flashing process.

The CPU has an internal thermal shutdown.  It won't burn out.  I run 
1.5's without heat spreaders all the time.  The reason you want to catch 
them is that fs-update will hang.


 The automatic lid switches test is confusing some teachers. Ideally we
 only want to run the heat spreader test part of it, so that the test
 is transparent and the user doesn't need to close the lid.

 Is this possible?

Yes.  I don' have a 1.5 with me at the moment but from looking at the 
OFW source I think you want ' .temp-rise '.


ok .temp-rise

That should run the thermal test and print a pass fail message.  It also 
returns back a true or false on the stack for if the test passes or fails.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Run OFW heat spreader test

2012-01-22 Thread Richard A. Smith

On 01/23/2012 12:23 AM, Jerry Vonau wrote:



Thanks, looking into that part of OFW code.


.temp-rise returns a ? from the OK prompt.


Ah... I see its part of the /switches node .

Try this:

ok select /switches
ok .temp-rise


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Run OFW heat spreader test

2012-01-22 Thread Richard A. Smith

On 01/23/2012 12:17 AM, Jerry Vonau wrote:


Is this possible?


I thought with the physical layout of the motherboard, CPU towards the
outside of the screen lid, that e-book mode would be the hardest on the
XO in terms of heat dissipation. Given there in no active cooling, is
the heat spreader test not measuring the difference in temperature
between the 2 modes of operation?


No.  The heat spreader test runs the cpu in a tight loop and watches the 
rate of change in cpu temp.  If it rises to quickly then the heat 
spreader isn't making good contact.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Run OFW heat spreader test

2012-01-22 Thread Richard A. Smith

On 01/23/2012 12:41 AM, Richard A. Smith wrote:

On 01/23/2012 12:23 AM, Jerry Vonau wrote:



Thanks, looking into that part of OFW code.


.temp-rise returns a ? from the OK prompt.


Ah... I see its part of the /switches node .

Try this:



oops.. forgot to get back out of that device node instance.
That should be:

ok select /switches
ok .temp-rise
ok unselect


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO-3 Announcement?

2012-01-10 Thread Richard A. Smith

On 01/07/2012 06:40 PM, Alan Eliasen wrote:

 I'm also curious about the power claims.  What is its power
 consumption and charging requirements?

Its still much too early to lay out exact claims for this.  These are A1 
prototypes.  This is the stage where we start finding all the things 
that are using more power than we would like and try to reduce them. The 
exact size of the battery is also changing as we maximize the space in 
the battery cavities.


We don't/won't start making any exact claims on power until it moves 
well into the B and C series builds.


That said, a lot of the internals are almost identical to the 1.75 so 
the things I've previously said about 1.75 are going to be a good 
approximation of the XO-3.  As John indicated the traditional display 
does consume more power than the Pixel-Qi.


In case you missed my previous comment on 1.75 on devel@ the maximum 
runtime power draw of the 1.75 is 5W. (Not including the extra 5W you 
can draw from the USB port.)


The power input front end of the XO-3 is currently identical to the 
XO-1.75 which matches the specifications of XO-1.5.  11V-25V input range 
and a maximum input rating of 25W.  Unlike the XO-1.5 the XO-1.75 almost 
never gets to the 25W maximum because its runtime power is much lower. 
So the peak power draw only happens if its charging a very low battery.


One difference between the XO-1.75 and XO-3 is that the XO-3 can _also_ 
be powered by USB On-The-Go (OTG).  OTG has a strict 5V/7.5W power 
specification so charging via OTG will take longer.  No. I've not yet 
measured how much longer. :) Sadly its not a nice linear thing that you 
can just do the math and figure out.  There are many variables some of 
which will change with the next prototypes.


Having a robust, wide voltage range, high power input is an important 
feature when using alternative power sources.  Alternative power can be 
very unclean and very sporadic.  You must be very forgiving on what you 
allow and when its available you want to maximize your input.


I don't think any other tablet made so far would survive long term if 
you connected it directly up to an automotive 12V power system.


 Has it actually been
 demonstrated to be chargeable by solar panels, hand cranks and other
 alternative power sources?  Especially ones not requiring systems which
 cost many times more than the price of the laptop, nor require someone
 with the green skin color of the XO to crank.

This claim isn't really new.  Evey XO generation we have made to date 
matches this claim.  In each generation we made an improvement over the 
previous.


Its always been possible to charge an XO from alternative power sources. 
There are sites in Rwanda, Peru, Haiti and the Solomon Islands (just to 
name a few) that are powered entirely by solar.  These are using XO-1 
and XO-1.5.  Some of these use a more commercial type solar system and 
some just are just raw solar panels that connect directly to the XO.


The XO-1 and XO-1.5 both had maximum runtime peak power draws in the 10W 
range.  Running things like the camera activity which keeps the system 
busy would draw that power continuously. If you didn't have 10W of input 
you go backwards.  Most people don't really realize how much work 10W of 
continuous power is.  The physical size of a 10W solar panel isn't huge 
but its still pretty large and you need perfect solar conditions for 
that 10W.  So what you really need is a 20W solar panel that so that a 
wide range of solar conditions still work.  A 20W panel is pretty large 
and not something easy to lug around.


The 1.75 (and tablet) have a runtime peak power draw in the 5W range and 
they idle even lower.  So now devices that produce power in the 10W 
range can fully power the new XO devices in a variety of conditions.  So 
you can envision taking an XO outside into the field connected to 
smaller solar panel (say 5-7W) and have a net power draw very close to 
zero.  A 10W panel would almost certainly have a net draw of zero unless 
the solar conditions were really terrible.


In my testing here in Boston I have powered a 1.75 directly (no battery) 
from the OLPC 10W panel in January sun.  Here's a video Chris Ball and I 
shot Jan 9, 2012 showing a 1.75 completely powered by our 10W thin-film 
PV panel.


http://www.youtube.com/watch?v=ITHNbOrPQyM

Hope this info helps,

--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [Sugar-devel] 883 on XO1

2012-01-08 Thread Richard A. Smith

On 01/06/2012 03:46 AM, Alec Muffett wrote:

At the risk of sounding perverse you could do block-level repair on
this by having someone put the same file up for Bittorrent somewhere,
and David could start the torrent, pause his repeat download,
install a copy of previously-downloaded file, restart his Bittorrent
client and have it download/repair the corrupted blocks for fairly
small bandwidth consumption.


Having builds available via bittorrent or some other p2p tool would be 
very useful when the dev team in in China.  Bandwidth at the factory is 
limited on per IP basis.  If the builds were available via p2p with 
swarming then the team could peer each other and we all would download 
chunks in parallel.   We do this sometimes manually now by cutting up 
the file into chunks and each of us download a chunk.


I started to do this one trip but got stuck trying to find a text mode 
bittorrent server that you could work with via ssh and then get it 
working. I'm only a casual bittorrent user.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [Sugar-devel] Happy Holidays fruitful break

2011-12-24 Thread Richard A. Smith

On 12/24/2011 03:30 PM, Sameer Verma wrote:



Sugar leads to Rum, leads to power, leads to use of Sugar. Richard
needs to get to work on this one!


*gulp* I'm working on it right now.

--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO-1.75 power testing

2011-12-05 Thread Richard A. Smith

On 12/05/2011 03:39 PM, Carlos Nazareno wrote:


Will reflash Bonnie, the 1.75 1B1 after the auckland game developer
meetup  do power testing on latest 11.3.1 build, mostly for read
standbye, hibernate etc times.


We don't do hibernate.  Hibernate saves active state to file on your 
storage media and powers off then reloads the file on boot.  We only do 
suspend. We call it suspend because its suspend-to-ram in ACPI speak. 
I've been calling it ASR or agressive suspend/resume because most 
systems only suspend when you close the lid or after it sits idle for a 
long time.  But we have our settings measured in seconds rather than 
minutes.



Tried running it idle the other day in Sugar overnight in idle.

After some time, it automatically went into hibernate (blinking LED),


ASR not hibernate.


and then when I woke up in the morning, it had shut down, but still
had quite some juice in the battery, something I found curious.

Was this on purpose or a glitch?


On purpose.  Default powerd config will wake up and turn off the machine 
if its been in-suspend for 4 hours.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO 1.75 battery life?

2011-12-02 Thread Richard A. Smith

On 11/29/2011 05:11 AM, Peter Robinson wrote:



How's the battery life on the 1.75 going for Read, web browsing
suspend? (3 of the most important functions) Anyone doing tests on
these yet?


I have begun doing battery life testing.  But aggressive suspend/resume 
is not 100% functional yet (but its very close).  Until aggressive 
suspend resume (ASR) is 100% I can't do a full round of usage mode testing.


I do have some data points and I can give you an minimum value.  One of 
the nice things about the 1.75 is that its maximum power draw from the 
battery is coming in at 5W regardless of how loaded the machine is. 
This makes a minimum battery life value much easier to predict.  The 
average value of the minimum for battery juice is 18Wh.  So 18Wh/5W is 
3.6hours.  So I feel safe in making the claim that regardless of what 
you do [1] with a 1.75 you can run for 3.5 hours.


That said you have to have a lot of stuff going to keep that at constant 
5W.  Certainly using Read or browsing the web you won't be at 5W so the 
battery life will be longer.


My existing data points have been collected under the following conditions:

 - Machine idle at sugar home screen (zero user input) with power 
management off.

 - Backlight at our default of 80%.

This is of course an artificial test since zero user input is not very 
useful as a battery life estimate but it allows me to do OS to OS 
comparisons and represents and upper bound of non-suspend runtime.


In that mode we I see abot 2.75W which on the above 18W est is 6.5 hours 
of runtime.  I have run logs that range from 6-7 hours for that test.


So I'm expecting to see in-the-wild numbers for people who disable ASR 
to be in the 4-5 hour range.


If you are outside and can turn off the backlight then that lower bound 
drops to 1.8W. With the backlight off I've got idle runs that show 
between 8.5-10 hours.


Throwing ASR into the works adds a _huge_ dynamic.  During ASR our low 
power drops from 2.75W to about 1.2W and even lower if the backlight has 
a chance to dim or turn off.  So if you can spend a lot of time in this 
mode then the battery life will increase quite a bit.


We don't have any good estimates of how much suspend time you can get 
out of things like Read or web browsing.  Powerd can now collect this 
sort of info but unfortunately a kernel bug in build 860 prevents the 
information from being accurate.


If you wanted to help and you have a 1.5 you can.  People with 1.5s can 
provide accurate usage info they install the latest release, make sure 
the date is set correctly, and then allow powerd to do ASR (ie don't 
disable it).  Then use the XO as you normally would but use it on 
battery as much as possible. Only charge up the battery when it gets 
low.  Powerd logs are kept in /home/olpc/power-logs .  After a few 
cycles of the battery send me all the logs in that directory.


[1] There's always a disclaimer. :) Thats without any USB devices 
plugged in.  the USB subsystem can provide up to 5W to an external 
device.  If you were to also draw 5W from USB then the draw would be 10W 
and your battery life will be much less.  In between 1 and 1.5h. (The 
harder you draw a battery the less capacity it can provide so its not a 
straight /2)


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Battery - small irritation

2011-11-27 Thread Richard A. Smith

On 11/27/2011 07:16 AM, Kevin Gordon wrote:


GREEN.  I then went to my email, and alas then saw your procedure. Sorry.

So, I have put a little tape indicator on the battery, and if it
misbehaves again, I will instead run what you sent me.  (Unless you
think it still instructive to  perform that test, but I fear my dabbling
may have trumped the evidence.)

Thanks for your quick reply, sorry I didn't get to it first to provide a
better analysis.


No worries.  That suggests that your cells were out of balance.  How 
long was the longest you ever let it sit before running bat-recover?


In theory just sitting there (yellow LED) waiting for the taper current 
should be able to balance as well.


If you are experiencing balance issues I wonder if you have any reduced 
capacity to go along with that.  You can check that with olpc-pwr-log. 
The procedure would be to stop powerd; insert the battery on ext power 
and make sure its full; run olpc-pwr-log and then remove external power 
right when you see the first line of output.


Then you just want to let the laptop sit there idle until it shuts off. 
 Unless you have an old build olpc-pwr-log tracks the net ACR in the 
8th column.  Its in uAh.  The range I use for good is 280-320 
uAh.  If your olpc-pwr-log is old enough that it doesn't have a net ACR 
column then you can compute the value by subtracting the Full ACR value 
in 6th column on the 1st line by the value in the last line in the log file.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: New XO-1 testing firmware q2f04rd [Devel Digest, Vol 69, Issue 7]

2011-11-06 Thread Richard A. Smith

On 11/06/2011 09:05 AM, Kevin Gordon wrote:

J  R:

I now  have q2f04rd on each of an 860/874/883, and q2e48 on each of an
860/874/883 - all 6 show 'C2', some are SHC, some are SHF, some are CSN
serial numbers.  Like YA,  I am experiencing no issues with any of the 6.

Is there a specific 'smoke-test' you'd like me to check?  Also, I do
have an older C1, which I seldom use, currently still 'way back' at 802.

Would you like me to check any specific function on any specific build
or combination?


Nope.  The test surface is everything.  :)

Given there haven't been any failure reports on this pre-release I think 
its time to spin a new XO-1 release and then hand it off to .uy for them 
to put it through the ringer before they roll it out.


Thanks to all the intrepid beta-testers.

--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


New XO-1 testing firmware q2f04rd

2011-11-03 Thread Richard A. Smith
Thanks to some great work by Paul Fox the previous problems with q2f04rc 
should now be fixed.


Give this new version a try and see if it holds up:

http://dev.laptop.org/~rsmith/q2f04rd.rom

Thanks.

--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [OLPC-AU] XO-1.75 relative performance

2011-11-01 Thread Richard A. Smith

On 11/01/2011 08:54 PM, C. Scott Ananian wrote:

the online benchmarks will probably be Android-based, and won't tell
you anything about battery life and power consumption, where OLPC has
put its focus and made great improvements.)


I suppose Its probably time to start throwing out some worst case 
battery life numbers.  We have built enough revs of the 1.75 now that 
the works case numbers aren't going to change.


My battery logs show that the minimum useful Wh we get out of our 
battery is 18Wh.  Fully loaded I've yet to see the XO-1.75 draw more 
than 5W [1].  So 18Wh/5W is 3.6h.  I feel safe in saying that regardless 
of what you do on the 1.75 you are going to get 3.5 hours of battery 
life. Period.  Thats a lot better than the worst case values of 1.5 
which was difficult to pin down.


Since suspend/resume is still undergoing heavy development I don't have 
any good estimates yet for user based workloads but early indicators 
look promising.  In the coming weeks I'll get some good numbers.


An interesting data point is that the 1.75 is the first laptop of the XO 
series that has ran 100% from a solar panel for an extended period. 
During my solar testing I often swap in different batteries.  The 1.75 
can consistently survive battery removal under moderate solar conditions 
when connected to the OLPC 10W solar panel.


[1] Excluding connecting an external USB device drawing full power which 
would be an extra 5W.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: EC corruption by q2f04rc firmware

2011-10-31 Thread Richard A. Smith

On 10/31/2011 12:34 AM, Kevin Gordon wrote:


RS:
Symptoms identical using multiple batteries, same XO.  Same batteries
worked fine in another XO. No flashing red using Q2E48, see Flashing red
over time using the rc, even with A/C in.


EEPROM read errors don't change based on the presence of external power.


So, now with a fixed target, upon physical inspection, the copper prongs
inside the battery compartment seemed 'bent'.

Not sure why the new firmware would do the flashing red for this
problem; but,


The new firmware has a lot of validity checks on data reads.  If the 
reads were resulting in invalid data then thats why you would get an error.



I realigned the prongs, put the batteries in, and I no
longer get any flashing reds, just perfectly charging batteries, all
three; and watch-battery shows no errors.


Glad it was something simple.  Bent prongs is a new one.

--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [BULK] Re: harvesting energy

2011-10-27 Thread Richard A. Smith

On 10/27/2011 11:45 PM, Richard A. Smith wrote:


Is the XO running or powered off?
Is it for a XO-1.5 or XO-1.5?


Oops.  XO-1 or XO-1.5

--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: EC corruption by q2f04rc firmware

2011-10-25 Thread Richard A. Smith

On 10/22/2011 03:42 PM, Yioryos Asprobounitis wrote:


Used q2f04rc firmware in my old XO-1 (os882) and I got repetitive EC corruption 
requiring removal of battery to reset.
The most reliable method to trigger  corruption is to suspend the XO-1 (power 
button).
All the XO lights go off there is one blink of the camera led, then the charge 
light comes up for 1 second (while not plugged in an outlet), then everything 
goes off (no blinking power light).
On wakeup keyboard and touchpad are dead, but an external mouse works fine.
On restart after that, OFW suggests to reset the EC by removing battery and 
power plug.
Before I stumbled on the suspend trick, I had a keyboard miss-mapping that also 
required EC reset to fix.
Back to q2e48 everything is back to normal.


Thanks for testing.  I'm traveling and the XO-1 I have with me is just a 
bare PCB so I'll have to wait and look at this when I get back.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: EC corruption by q2f04rc firmware

2011-10-25 Thread Richard A. Smith

On 10/23/2011 05:50 PM, Kevin Gordon wrote:


It appears that the battery is not recharging when the A/C is plugged
in.  I've tried two different batteries, and they drain to flashing red,
even when the plug is in.  Reverting to Q2E48 seems to have fixed that
behaviour.  I will continue testing.


Flashing red indicates an error. If you get flashing red then the 
battery subsystem is halted.


Stop at OFW run 'watch-battery' and then press a key to exit.
watch-battery will tell you what the error is.

Making an educated guess I'd say your error source is EEPROM corruption 
caused by ESD.  The new code backported from 1.5 detects this condition. 
 If its caught early then the code can prevent it from getting 
committed into the EEPROM but it can't fix it if its already committed.


Since charging works on XO-1 your EEPROM(s) are not corrupted so bad 
that it fatal. However, if you are getting corruption then its a not a 
matter of 'if' but 'when' until you hit the bits that will break your 
battery.


You can dump the battery EEPROM with 'bat-dump-banks' and take a look. 
You should not see a long series of 0xff or 0x00 in the data.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


New q2f series XO-1 firmware needs testing

2011-10-20 Thread Richard A. Smith
Over the past 2 years XO-1 EC firmware has been held at pq2e34 which was 
released in March of 2009.


During that time the EC XO-1 code evolved into the trees for XO-1.5 and 
then into EC-1.75.  Many, many, many fixes and improvements to the 
codebase have happened since pq2e34.


The new RTC anti-roll back feature in OFW required a EC-1.5 feature that 
was not present in XO-1 EC code.  Gaining that feature meat moving to 
the so called f series of EC code.


The f series of EC code was the next generation of EC code for 1.0 but 
it never saw a widespread release for XO-1.  Instead it turned into the 
EC code for XO-1.5.  Over the past 2 years Paul and I have kept the XO-1 
f series updated with backports from XO-1.5.  All of the XO-1 machines 
in my testbed ran f series and Paul runs it on one of his XO-1 machines.


As such, f has never really seen any in-the-wild testing although the 
same code and features are all working fine on 1.5.  Most of the 
backported code is identical except for the differences in the IO pin 
out between the XO-1 and the XO-1.5.


So although the difference between the previous release of XO-1 EC 
firmware and this version is _huge_ I'm only expecting minor bugs.


f has now become the new EC 1 code base and has a version number 
similar to what is used on 1.5 and 1.75.  This release is EC-1 1.2.0


For you testing pleasure I've built a new XO-1 firmware with the new EC 
code and the latest OFW.  I'd like to get some public testing before it 
gets put in an official release.


http://dev.laptop.org/~rsmith/q2f04rc.rom

Thanks.

--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: How to disabled xo security without developers key

2011-09-17 Thread Richard A. Smith

On 09/15/2011 12:55 PM, Alan Jhonn Aguiar Schwyn wrote:

 Can anyone tell me how to get OK prompt without developers key??

In secure mode getting to an OK prompt won't help.  The firmware lockout 
is enabled.  The only way to upgrade firmware in secure mode is to 
disable with a developer key or use a signed firmware build.



And if you don't like it.. You can use the Serial Port on the XO... No?


No you can't. The firmware lockout happens before you get an ok prompt 
on the serial port.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: risk factor - ext4 and disk corruption

2011-09-08 Thread Richard A. Smith

On 09/07/2011 01:26 PM, Martin Langhoff wrote:

On Wed, Sep 7, 2011 at 12:52 PM, John Watlingtonw...@laptop.org  wrote:

The classic trigger for corruption problems (especially w. SD cards)
is sudden power off events.   I believe we now have the ability


Wrote http://dev.laptop.org/attachment/ticket/11220/fstorture.sh which
uses sysrq to tell the kernel to do a hard reboot. Happy to replace
that with a direct EC command issued via debugfs if we have one.


I think you missed my response on IRC.

 echo 4b:0  /sys/kernel/debug/olpc-ec/generic

Will tell the EC to power cycle.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Light sensor on XO-1.75

2011-08-30 Thread Richard A. Smith

On 08/30/2011 09:50 AM, Bert Freudenberg wrote:


Its proportional because that's how  the sensor works.  The amount of
light changes the time to bleed off the charge stored in the diode
when you reverse bias it.


Ah, so you use the LED itself to sense light? And then time how long a cycle 
takes in the EC? Awesome design!


Yes. Its not the same LED but its the same light pipe.  We stuck an 
additional LED right next to the WLAN led.  Thats why it as to be turned 
off during the reading period.



This almost takes the cake over the analog mic hack.


Thanks.  Its a nice inexpensive solution.

--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Removing linux-firmware from the build

2011-07-31 Thread Richard A. Smith

On 07/29/2011 01:49 PM, Peter Robinson wrote:


I don't have mine handy but I have a  OLPC serial adapater


What leads you to believe that the OLPC serial adapter needs firmware 
downloaded?


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: *.laptop.org issues

2011-07-07 Thread Richard A. Smith

On 07/07/2011 03:30 AM, Bert Freudenberg wrote:



Doesn't fix the download.laptop.org problem though:

bert$ traceroute download.laptop.org
traceroute to pedal.laptop.org (18.85.2.148), 64 hops max, 52 byte packets


Things have not settled yet .148 is still the problem IP.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: xo-1.75 support in olpc-utils

2011-06-27 Thread Richard A. Smith
On 06/25/2011 11:00 AM, Daniel Drake wrote:

 Thanks for sharing it. I agree with developing it as a scratch branch,
 while temporary hacks are needed and it targets F13 instead of F14.

 Looking at what is there already, I'm hopeful that you will soon have
 device tree access working (this is not a big job) which would
 eliminate the olpc-configure changes, and the X stuff seems to be in
 flux so I think a scratch branch is the right place for now.

How are you determining in olpc-utils that you are running on a 1.75?
Is this available for runin to pickup?

Right now the battery test seems to skate by.  We have a minimum SOC 
diff of 20 clicks and the battery discharge test is coming in at 24 
clicks.  From the sample set I have so far the runin power draw seems to 
be very consistent and a margin of 4 may be enough but its pretty close. 
  I may need to adjust the test levels if a 1.75 is detected.

-- 
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Installing powerd on earlier F11 builds

2011-05-25 Thread Richard A. Smith
On 05/24/2011 11:37 PM, Paul Fox wrote:

 certainly not as serious as with XO-1.5:
  http://dev.laptop.org/ticket/10402#comment:5

 what's not clear is a) whether this condition can be caused by
 lid-switch, and b) whether it can be caused in your charging
 racks.  from my experience with those racks, i suspect the effects
 won't be as severe as with vertical stacking.

Its the other way around.  The original problem was reported by people 
using the racks.  We just theorized that people who stack them would 
also have a similar problem.

-- 
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Installing powerd on earlier F11 builds

2011-05-25 Thread Richard A. Smith
On 05/25/2011 01:20 PM, Paul Fox wrote:

 Its the other way around.  The original problem was reported by people
 using the racks.  We just theorized that people who stack them would
 also have a similar problem.

 yes.  but quozl's test of xo-1 laptops, as reported in the above
 comment link, showed screen damage when vertically stacked.  he
 didn't test in a rack.  i was suggesting that the temperatures might
 not rise as high in the charging racks, which is sridhar's use case.

Perhaps not quite as high but I think it will still get high enough to 
cause the LCD damage.  I often discharge batteries by leaving a bank of 
machines at OFW running watch-battery.  Once I was using a bank of XO-1s 
and tried to save floor space by leaving the laptops closed and placing 
them up against the wall.  The not exactly like they would be in a rack 
but very similar.  When I returned the laptops in the middle were very 
hot.  So hot I almost could not handle them.

-- 
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Testers wanted, fast fs-update of os860 (10.1.3)

2011-04-28 Thread Richard A. Smith
On 04/28/2011 04:18 AM, James Cameron wrote:

2 Machines both: Q3B02 1.5 C4 prototype

#1 Mfg ID: 0x03 OEM ID: SD Name: SU04G Rev: 8.0 Date 2009-9

regular: 00:11:00
  sparse: 00:06:19

#2 Mfg ID: 0x1d OEM ID: AD Name SD Rev 1.0 Date 2010-4

regular: 00:09:37
  sparse: 00:06:00

-- 
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO won`t suspend sometimes

2011-04-27 Thread Richard A. Smith
On 04/26/2011 03:06 PM, Matías Poloni wrote:

 I'm working with the XO 1.0 with the 802 image (i've found this image the 
 most accurate one for my project).

Power management in general is much better in the newer builds.  I 
encourage you to use 860 rather than 802.  What is it in 802 that you 
need thats not in 860?  With 10.1.3 (860) powerd manages suspend and 
resume and its very configurable.

 It's very important for this project that the XO goes to sleep without
 any problem because it will be working for a long time (almost a month
 or even more) without user intervention. And it's important to use
 pm-suspend because I use the pm-utils hooks to run some scripts after
 resume.

What sort of power source do you have?  The XO battery won't last that 
long in suspend.

-- 
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO power management

2011-04-20 Thread Richard A. Smith
On 04/19/2011 03:52 PM, Pablo Iguiniz wrote:
 Hello Richard,

 This is Eng. Javier Iguiniz from Ceibal. Ismael has recently changed
 work so I am now taking over part of his tasks, in particular the
 testing related to the XO batteries.

Welcome Javier.

 I tried to catch up with the plan, so we have carried the test to
 another batch of batteries we had here. The initial batch had 50
 batteries and there was all kind of them: newer and older from different
 years.
  From the 50 units only 28 remained functional, meaning that they could
 accoplished the full charge/discharge test cycle. The damaged batteries
 showed different problems, which I list below:

 Battery not recognized  - No Battery reported , LED does not light up.

This failure is possibly recoverable if you have an external 1-wire 
interface.

Check these batteries by putting them in a XO. Stop at OFW and run 
'see-bstate'.  If you see a series of 0 1 2 over and over then you will 
need an external 1-wire interface to recover the batteries.  If you see 
more numbers than 0 1 2 then the battery should be recoverable with OFW.

 Battery recognized but error message is shown, red LED blinks

This should be recoverable.  Do you have a XO-1.5 handy?  In the latest 
XO-1.5 firmware 'watch-battery' will tell you what the error is when you 
exit.  So put the battery in a 1.5 and let the LED blink red.  Then run 
'watch-battery' and after it prints a line then press a key to exit.  It 
will print out what the reported error is.

 Bad data retrieved from EEPROM

Please describe this more.  You can get a listing of the EEPROM by 
running 'bat-dump-banks' from the OFW prompt.  Its handy if you have a 
serial port connected so you can log the results.

Also try to put the battery in a XO-1.5 with the latest firmware.  The 
1.5 firmware has code that can try and fix some types of EEPROM 
problems.  If not then we can fix the EEPROM via OFW.

 Never finishes trickle mode
 Battery appears as full but doesn´t allow the XO to start
 Initial tricke mode, does not charge after recover phase

These are interesting.  Only the 4 you show in the spreadsheet have this 
problem or do you have more?  There are only 47 entries in your 
spreadsheet.

  From those 28 functional batteries I´m ataching a zip file with data
 collected and a file with the batteries status summary . I hope you
 could find it useful.You may find some files which have a minor data
 process or include a graph.

Your .zip file contains mostly .xls files that have been converted from 
the .csv files.  My processing tools cannot operate on excel files. 
Please send me the .csv files that olpc-pwr-log generated.  They do not 
have to be in separate directories.  You can copy them all into a single 
directory.

 At the moment we don´t have many more batteries left. I will try to find
 some more from now on.

I'm confused.  I thought you had hundreds of batteries to process. 
Thats why you needed the fast procedure.

 I saw that there was another side on the investigation regarding the
 information of charge and discharge cycles collected  in EEPROM. I would
 like to know if you had any chance to go further on this point.

I've modified my processing tool to output the lifetime numbers but 
right now they don't appear to be useful.  They don't make sense.  After 
you send the rest of the .csv files I'll summarize the results.

-- 
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: New XO 1.5 firmware with MPPT. Please test!

2011-04-08 Thread Richard A. Smith
On 04/07/2011 03:43 PM, Samuel Greenfeld wrote:
 Is there any expected impact to battery health or life from using a MPPT
 (maximum power point tracking) charging technique?

The mppt does not affect charging.  It affects power input into the 
system.  So no there is zero impact on battery health.

 How does this behave when it encounters an external charger which may be
 inflexible in terms of voltage or current generated?

It doesn't quite work that way.  You draw power from a power source. 
It's not pushed.

The exact behavior depends on the adapter and the state of the laptop. 
When external power is detected the new code attempts to figure out if 
its a PV type device or a power adapter.  It does this by turning on the 
and sampling the input voltage with the input power limit set to 0 and 
then again with it set to max.  If the deltaV between these 2 readings 
is greater than a threshold then PV is assumed OR if the absolute value 
of the 2nd reading under load is  a threshold.

PV or adapter influences the starting point of the MPPT algorithm. An 
adapter starts with no power limit and a PV starts with almost full 
power limit.  The reason for this is that when the laptop is running and 
the power limit is set very low its difficult for the MPPT to figure out 
what to do.  The dynamic power draw of the laptop means that my 
adjustments to the input power may or may not be correlated with an 
actual input power increase or decrease.  So the algorithm can have a 
bit of a slow start until it gets enough correlation and starts 
tracking.   The adapter check tries to jump around that since we know 
there is enough power available.

Your inflexible adapters are actually more flexible than you think. 
The white ones seem to have a loose enough voltage regulation that some 
of them trip the PV check and so it starts charging slowly.  This quick 
check feature is a new addition and I'm still fine tuning the values.

-- 
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: New XO 1.5 firmware with MPPT. Please test!

2011-04-07 Thread Richard A. Smith
On 04/05/2011 12:47 PM, Richard A. Smith wrote:

Latest version.

http://dev.laptop.org/~rsmith/q3a62e.rom

This one really fixes the keyboard problem.  This is what I hope to be 
the final test release.

In addition to the normal does this work for you. I need one specific test.

Please flash then boot and stop at openfirmware.  Then run 
'watch-battery'. Remove external power and  allow you battery to 
discharge to 60% or more. ie (= 60%).

Then re-plug up external power and watch what the battery current does. 
  It should pretty quickly go up to around 1A or more.  If it does not 
then please connect up a serial terminal with logging enabled. ( you 
will have to power cycle or reboot to get ofw serial) Remove external 
power and then rather than 'watch-battery' run 'watch-mppt' and then 
replug up power. Let it run for perhaps a minute or so and then send me 
the serial log.

Thanks
-- 
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: New XO 1.5 firmware with MPPT. Please test!

2011-04-07 Thread Richard A. Smith
On 04/06/2011 03:18 PM, Ismael Schinca wrote:

 Hey Richard! Here's a log from a partial battery charge in the following
 conditions:

 - XO 1.5HS using the firmware you sent
 - Connected to an unregulated 10W panel
 - Using the script rtcwake-log you sent I think it was from december
 last year

Thanks.  Your logs look good. FYI. I have a new version of that called 
panelpwr-log.  You should use that rather than rtcwake-log

http://dev.laptop.org/~rsmith/power/panelpwr-log

 Quick comments:
 - The XO charging light was always on with the panel conected, even with
 very low light.

Yes.  This is expected.  Its trying very hard to charge (since the panel 
has voltage) but there just isn't any power.

 - When the battery was full, the XO started doing that buzzing sound,
 like when it works with a low voltage, only this time it was louder than
 in that situation. I'm guessing maybe as the battery wasn't charging the
 panel reached close to open circuit voltage and there was some pretty
 heavy regulation going on?

Sort of.  I disabled the mppt when the battery was full which means that 
the panel will get pulled down and the switcher will start to oscillate. 
  You hear the oscillations.  My latest version does not disable mppt 
when the battery is full.  This should fix that.

 Just from this one, I would say that the firmware worked great! It's a
 pitty I cannot verify with hard numbers the MPPT function.

Thanks for your testing. Can you give q3a62e a spin with the new 
panel-pwr log?  That would be useful info for me.

-- 
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO power management

2011-04-05 Thread Richard A. Smith
On 04/05/2011 09:33 AM, Ismael Schinca wrote:
 Thanks! This is very useful information. I'll try to run some new tests
 and try to look at the data more thoroughly. The new batteries' capacity
 is pretty puzzling. I'll repeat the tests on these batteries and add a
 couple more of new ones to get more results.

Please continue to run the test on your other batteries as well.  More 
data is better than lest data.  Grab  as many XO's as you can and run 
new tests daily on your stock of batteries.

 I think it's a good idea to think about discarding the 07 batteries.
 They are pretty old anyways.

Even if you plan to recycle the  008 batteries please continue to 
include them in the your tests.  That way I can build up a profile of 
what the _actual_ capacity loss over time vs my estimates.

-- 
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: New XO 1.5 firmware with MPPT. Please test!

2011-04-05 Thread Richard A. Smith
On 04/04/2011 06:22 PM, Richard A. Smith wrote:

 There is one known problem. On your very first flash you might lose the
 keyboard/mouse. You can prevent this by doing a full power cycle of the
 EC. ie no ext power and no battery.

New version:

http://dev.laptop.org/~rsmith/q3a62b.rom

This one hopefully fixes the keyboard issues.  Anyone who experienced 
that problem please reflash your previous firmware and then flash in 
this new one.

Thanks.

-- 
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO power management

2011-04-04 Thread Richard A. Smith

On 03/31/2011 03:43 PM, Ismael Schinca wrote:

Richard, Ceibal about to start working heavily in reworking how to
classify used batteries. Due to the number of batteries involved, we
were asked to devise a good enough procedure to estimate the battery
condition in less than 10 minutes. The plan would be to get several
parameters from the batteries and try to estimate it's condition based
on them. Have you been able to analyze the results from the logs I sent
you?


Sorry.  I've been very busy lately and its taken me a while to look at 
them.  I'm currently in route to Taiwan where I'll be for the next 2 
weeks.  I've been looking at your logs on the plane.  Note that after 
about 4pm PST I'll be out for a day or so . After that I'll be out of 
sync with your timezone  (I'll be +11 or +12 or so from you) and I'll be 
very busy so my responses my lag quite a bit.


I'm afraid its difficult to make any judgments from the data you have 
sent so far.   You are going to have to test many more batteries to get 
more data.


I'm going to have to do some work on my processing tools to help with 
the comparison.  I'll try to get to that later on.


Here's a quick look at the capacity of the batteries you have tested so 
far.  Thank you very much for the battery serial number in the filename 
that is very helpful.  Please continue to do that.  I've broken up the 
serial number so that we can see the age easily. The 2nd column is the 
ammount of Watthours that was extracted from the battery sorted into 
ascending order of Watthours.


00401 071229 110002160OLD.csv   -4.177
00401 071229 110002221OLD.csv   -11.663
00602 080608 11600.csv  -13.915
00802 100751 10002447NEW.csv-13.992
00602 080616 110002384.csv  -14.405
00802 100804 110003201NEW.csv   -14.803
00802 090331 110002400.csv  -15.066
00802 081130 110001133.csv  -15.768
10102 080109 31524.csv  -15.863
00702 080710 11901.csv  -16.009
00802 090829 110001062.csv  -15.914
00802 081231 11683.csv  -16.576
00702 080714 11474.csv  -16.826
00802 090415 110001059.csv  -16.995
00802 090429 110002159.csv  -17.705
00802 090206 110001307.csv  -18.489

The first thing to notice is that it roughly correlates with age which 
makes sense.  The both the 004's are suffering from charge balance. 
Something you can see from the charging voltage logs.  If you want a 
quick first pass of segregating the batteries then you can use the first 
3 digits as guide.  Any battery with the first 3 digits that are less 
than 008 (ie, 007,006,005,004...) is subject to charge balance.  I 
recommend you group your batteries int  008 and = 008.  Depending on 
how many you have you may or may not want to even try to analyze the  
008 group.


The next thing to notice is that your batteries that you marked as NEW 
are showing a capacity that is much less than expected.  Those should 
have had a capacity of 18Wh or more.  Please re-run the test on those 
batteries and see if the data is consistent.


I've estimated that the capacity loss should be .025% per/cycle. If we 
assume the rough age of the batteries is 2 to 3 years and that they 
average 1 cycle per day then I'm expecting the available capacity to be 
in the 73% to 82% range or 15-16 Wh.  Looking at your numbers I say its 
right on par.  So perhaps you can also use the battery age as a guide.


What is the minimum capacity you want to allow to be re-used?

The attached graph shows your charging voltage in detail.  As you can 
see the the screen turning off and on has an effect on the voltage. 
This graph also illustrates why this is going to be a difficult thing to 
accomplish in only a 10 minute test.



Another question. Is there information in the battery controller
regarding total number of charge/discharge cycles?


There is an attempt to do that and the logs extract that information 
from the EEPROM.  However,  I don't have any idea how accurate it is. 
Its legacy code that I've never had a reason to examine closely.  I'll 
examine the code that does that in detail and then add decoding of the 
values to my processing script next so I can take a look at the numbers.


--
Richard A. Smith  rich...@laptop.org
One Laptop per Child


chg_voltage.pdf
Description: Adobe PDF document
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: New XO 1.5 firmware with MPPT. Please test!

2011-04-04 Thread Richard A. Smith
On 04/04/2011 06:05 PM, Richard A. Smith wrote:
 Attached to this email is q3a62a.rom. This is a pre-release of new XO
 1.5 firmware with MPPT code enabled. It is also available at:

Sorry about the attachment.  I was sending copies of this to all the 
deployments to test and didn't think about the multiplication factor 
sending to devel.

 http://dev.laptop.org/~rsmith/q3a62a.rom

There is one known problem.  On your very first flash you might lose the 
keyboard/mouse.  You can prevent this by doing a full power cycle of the 
EC.  ie no ext power and no battery.

If it happens any other time other than the first the please report it.

-- 
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO power management

2011-03-24 Thread Richard A. Smith
On 03/24/2011 08:55 AM, Ismael Schinca wrote:
 Thanks, for starters this is really useful, because it's not at all
 similar to what I've been observed. The computer powers off with battery
 levels between 10-15% and the led starts blinking around 5-10%. I'm
 using several batteries on the same XO 1.0 computer. Granted, the
 batteries are not fresh ones, but that's exactly what I am trying to
 figure out. How the battery behaviour changes when battery capacity
 starts to decrease over time.
 Any additional information will be most welcome.

What you are observing is exactly what will happen as the battery 
reduces capacity.  We don't have a calibration procedure so the SOC 
assumes 3100mAh.  The SOC is a mAh/1% counter.  After so many mAh it 
subtracts 1%.  The critical level is a voltage reading.  Its not coupled 
to the SOC.  So with a battery that has less capacity you will reach the 
critical level sooner.

Whats the serial number of your battery?  You may also want to run a 
olpc-pwr-log run with that battery so you can determine what the actual 
capacity of the battery is.

-- 
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO power management

2011-03-24 Thread Richard A. Smith
On 03/24/2011 09:15 AM, Richard A. Smith wrote:

 Whats the serial number of your battery? You may also want to run a
 olpc-pwr-log run with that battery so you can determine what the actual
 capacity of the battery is.

Even better you are in a position to help me figure out how best to deal 
with this.Adding a full blown calibration procedure is perhaps 
possible but its tricky to do automatically.  A possible 1st step could 
be the addition of a manual value that let you adjust the maximum mAh. 
Then you could run a manual calibration procedure and update the value.

You say you have many of these batteries?  Would you be able to run 
olpc-pwr-log on each one of them?

-- 
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO power management

2011-03-24 Thread Richard A. Smith
On 03/24/2011 09:25 AM, Ismael Schinca wrote:

 I have several batteries, some of them pretty old (that's the idea). A
 couple of S/Ns:


 00602 080616 110002384
 00602 080608 11600

The mfg is embedded in the serial number pos 6-11 format YYMMDD

So these 2 batteries where produced 2008/06/16 and 2008/06/08.  Close to 
33 months old.  Indeed I would really like charge/discharge profiles 
from these batteries.

 know if the results were valid since I was having different starting
 points. Some batteries started from 5%, some from 10%, etc. Now I know
 that's probably correct anyways.

Please do a charge/discharge cycle while running olpc-pwr-log.

-- 
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO power management

2011-03-24 Thread Richard A. Smith
On 03/24/2011 09:53 AM, Ismael Schinca wrote:
 OK. Just read this email.
 So the plan would be:
 - Start from a fully charged battery, run the olpc-pwr-log script until
 poweroff.
 - Remove battery, plug XO, run script and insert battery until fully
 charged.

Yes.  Or the other way around if you have an empty battery.  Start 
discharged, charge, then discharge.  But only do it that way if the 
battery is very low.

 If you would prefer a different test please let me know.

Nope thats it.  I'd like the serial number for each battery as well.  Do 
you have a hand held USB barcode scanner?  If so then you can use it to 
quickly read the battery serial number.  I find them very useful when 
dealing with a large number of batteries.

-- 
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO power management

2011-03-24 Thread Richard A. Smith
On 03/24/2011 09:53 AM, Ismael Schinca wrote:

 If you would prefer a different test please let me know.

oh and if this is a build that running powerd then you need to stop it 
or disable power management and turn off dpms screen blanking.  On 1.5 
dpms is not active but it is on XO 1.0.  The machine needs to be running 
idle so don't use it for anything either.

If its an older build with ohmd then you need to stop that as well.  We 
don't want power management to kick in for this test.  Also what version 
of olpc-pwr-log are you runing?

There is a version output field in the log file and you can also see by 
looking at the file. It's a bash script.

-- 
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO power management

2011-03-24 Thread Richard A. Smith
On 03/24/2011 09:45 AM, Ismael Schinca wrote:
 We would really like to have a relatively accurate result *as fast as
 possible *of the condition of a battery. That's what I'm trying to get to.
 I could run the olpc-pwr-log on 15 batteries aprox. Used batteries but
 in a probably good condition.

If you run _exactly_ the same test under the same conditions. Same 
temperature, same test duration, same XO, then it might be possible to 
compare the current voltage, to the SOC and make a fast assessment.  The 
battery voltage is dependent on a lot of different variables and those 
will need to be held constant.

The profiles you are about to generate will tell us if this is possible.

 I'm also trying to get some really bad but functioning batteries to test
 them. Don't have them yet.

Sounds good.

 I'll try to run the script on those 15 batteries today and share the
 results here. I could attach the csv files for example. My idea is to
 deplete the batteries and run the script from that point on. Let me know
 if you would prefer another procedure.

Today?  Each charge takes approx 2 hours. Are you going to do it on 15 
different XO's?   That procedure is fine for the charge files.

-- 
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO power management

2011-03-24 Thread Richard A. Smith
On 03/24/2011 10:31 AM, Richard A. Smith wrote:

 If you run _exactly_ the same test under the same conditions. Same
 temperature, same test duration, same XO, then it might be possible to
 compare the current voltage,

Battery temperature will also be a concern. If you test the discharge 
immediately after a charge when the battery is hot you are going to get 
a different result than if the battery was sitting on the table all 
night and is at room temperature when you start the discharge.

-- 
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Memory replacement

2011-03-14 Thread Richard A. Smith
On 03/13/2011 06:34 PM, Mikus Grinbergs wrote:
 The tests have also helped expose other issues with things like sudden
 power off.  In one case a SPO during a write would corrupt the card so
 badly it became useless.  You could only recover them via a super secret
 tool from the manufacturer.

 Is there any sledgehammer process available to users without a super
 secret tool ?

Wasn't just secret to users.  They would not give us the info on how to 
do it either.  It was vendor specific so not really worth the effort of 
trying to reverse engineer.

-- 
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: 'menu' in OFW on an XO-1

2011-03-13 Thread Richard A. Smith
On 03/13/2011 01:15 AM, Sridhar Dhanapalan wrote:
 With firmware Q2E45 on an XO-1 (yes, I finally got it unlocked!), I
 type 'menu' at the ok prompt.

 On an XO-1.5, I get a very useful list of icons that run different
 hardware tests. On this XO-1, I only get an array of square outlines.
 The first (top-left) is blue. The others are black. Clicking on them
 does nothing.

 Is that expected behaviour?

Not expected but not surprising.  The graphical hardware 
tests/diagnostics were developed for the 1.5. In XO 1.0 we only had the 
text based tests. I suspect that the 1.5 graphics stuff came along for 
the ride when we started building newer XO-1 firmwares.

We should disable that command for XO-1.

-- 
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Discovering the XOs local timezone in a bash script

2011-03-13 Thread Richard A. Smith
On 03/13/2011 11:15 AM, Daniel Drake wrote:

 On 13 March 2011 03:21, Samuel Greenfeldgreenf...@laptop.org  wrote:
 Sugar reports only relative times in its core GUI, so I don't know how
 common it is for deployments or other users to actually change this
 setting.  Setting a time zone other than UTC with 10.1.3 and prior may
 also expose a flaw where the offset is repetitively applied every
 reboot, shifting the clock.

 Just to remove any doubt..
 Setting the time zone from the control panel doesn't have any adverse
 effects such as the clock shift described above. This is is because
 sugar's time zone is isolated from the rest of the system as described
 here.

Thanks for clearing that up.  I've checked on build 860 and `date` 
reports the timezone selected via the control panel.  So that gives me 
what I need.

-- 
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: 'menu' in OFW on an XO-1

2011-03-13 Thread Richard A. Smith
On 03/13/2011 11:21 AM, Mitch Bradley wrote:

 Not expected but not surprising. The graphical hardware
 tests/diagnostics were developed for the 1.5. In XO 1.0 we only had the
 text based tests. I suspect that the 1.5 graphics stuff came along for
 the ride when we started building newer XO-1 firmwares.

 Actually, it has been around for a long time. The menu framework and
 command came along for the ride with the graphics infrastructure that is
 used for pretty boot and the graphical depiction of security status.
 Only with 1.5 did we populate the menu with actual icons and behavior.

So its not even a regression. :)  Few people knew it existed so it never 
got tried.  Now that menu is a regular part of a tech users vocab we 
should fix it or disable it on the next XO-1 firmware release.

-- 
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Discovering the XOs local timezone in a bash script

2011-03-13 Thread Richard A. Smith
On 03/13/2011 11:56 AM, Daniel Drake wrote:
 On 13 March 2011 15:49, Richard A. Smithrich...@laptop.org  wrote:
 Thanks for clearing that up.  I've checked on build 860 and `date` reports
 the timezone selected via the control panel.  So that gives me what I need.

 That only applies when you're in the sugar environment though.
 If you're dealing with data generated by powerd, or from a cron script
 or something like that, you'll get UTC regardless of what was selected
 inside sugar.

Bah.. :(  I was testing from the terminal activity.  I usually have 
people run my script from inside terminal anyway but I'll have to make 
sure I tell them that. Thanks.

Its unfortunate for the powerd logs but not a showstopper.  The 
panel-pwr script doesn't use powerd because we fight over the rtc for 
wakeups.

-- 
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Memory replacement

2011-03-13 Thread Richard A. Smith
On 03/13/2011 01:21 PM, Arnd Bergmann wrote:

 Do you have test results somewhere publically available? We are currently
 discussing adding some tweaks to the linux mmc drivers to detect cards
 with certain features, and to do some optimizations in the block layer
 for common ones.

 http://wiki.laptop.org/go/NAND_Testing

 Ok, so the testing essentially means you create an ext2/3/4 file system
 and run tests on the file system until the card wears out, right?

The qualifying test is that the card must pass 3TB of writes with no 
errors.  We run that on samples from the various mfg's.

There's a 2nd round of test(s) that runs during the manufacturing and 
burn-in phases. One is a simple firmware test to see if you can talk the 
card at all and then one runs at burn in.  It doesn't have a minimum 
write size criteria but during the run there must not be any bit errors.

 It does seem a bit crude, because many cards are not really suitable
 for this kind of file system when their wear leveling is purely optimized
 to the accesses defined in the sd card file system specification.

 If you did this on e.g. a typical Kingston card, it can have a write
 amplification 100 times higher than normal (FAT32, nilfs2, ...), so
 it gets painfully slow and wears out very quickly.

Crude as they are they have been useful tests for us.  Our top criteria 
is reliability.  We want to ship the machines with a SD card thats going 
to last for the 5 year design life using the filesystem we ship.  We 
tried to create an access pattern was the worst possible and the highest 
stress on the wear leveling system.

If a card pases the 3TB abuse test then we are pretty certain its going 
to meet that goal.  There were many cards that died very quickly.

The tests have also helped expose other issues with things like sudden 
power off.  In one case a SPO during a write would corrupt the card so 
badly it became useless.  You could only recover them via a super secret 
tool from the manufacturer.

 I had hoped that someone already correlated the GC algorithms with
 the requirements of specific file systems to allow a more systematic
 approach.

At the time we started doing this testing none of the log structure 
filesystems were deemed to be mature enough for us to ship. So we didn't 
bother to try and torture test using them.

If more precision tests were created that still allowed us to make a 
reasonable estimate of data write lifetime we would be happy to start 
using them.

-- 
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Discovering the XOs local timezone in a bash script

2011-03-12 Thread Richard A. Smith
I've added a new feature in my power logging processor that allows the 
plotting of power input vs time of day.  To do this I have to know the 
local timzone so I can translate the UTC datestamp back to the local time.

`date` says the XO's timezone is set to UTC so I'll have to get it from 
somewhere else.

Can someone give me a quick rundown of how we are managing timezones so 
I know what to look at to determine this?

-- 
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Discovering the XOs local timezone in a bash script

2011-03-12 Thread Richard A. Smith
On 03/12/2011 10:21 PM, Samuel Greenfeld wrote:
 The XO image OLPC supplies defaults to UTC. Users can select a time zone
 offset in Sugar if they want, but it is purely a numerical control at
 last check and does not allow you to choose a setting that is regional
 (like America/New York or EST5EDT, which include Daylight Savings
 support).

ok so not automatic but I can still work with that.  I'll make sure to 
tell people testing solar to please set that to the value for their region.

 Sugar reports only relative times in its core GUI, so I don't know how
 common it is for deployments or other users to actually change this
 setting. Setting a time zone other than UTC with 10.1.3 and prior may
 also expose a flaw where the offset is repetitively applied every
 reboot, shifting the clock.

Apparently not very common.  Grepping through my collection of 1217 
power log files I only found 61 of them that had that value set to 
something other than GMT or UTC.  Granted that most of those files where 
generated by me and I didn't know about that control but I also have a 
lot of logs from users.

Thanks for the info.

-- 
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Initial tests of Activities, as shipped, on a New XO-1.5

2011-03-03 Thread Richard A. Smith
On 03/02/2011 08:34 AM, Thomas C Gilliard wrote:
 Attached is an OpenOffice.org Calc spreadsheet of my initial testing of
 activities on a new XO-1.5

Did you test while on battery or on external power?  If you were on 
battery and power management was enabled the the log files in your 
power-logs directory would be useful to me.

Thats pretty much a blanket statement for everyone doing any sort of 
testing for say .5h or more.  Run on battery enable power management and 
send me a copy of the logs in power-logs dir when you are done.

Even better if you _use_ the XO for extended periods on battery and have 
power management enabled then I'm also interested in your power-logs.

Both XO-1 and XO 1.5

Thanks.

-- 
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Voltage from the rtc battery

2011-02-23 Thread Richard A. Smith
On 02/23/2011 09:27 AM, Ismael Schinca wrote:
 Hi everyone. I would like to know if there's any way to check from the
 openfirmware or os prompt the voltage from the rtc battery.
 Thank you!

Nope.  You have to use a voltmeter.

-- 
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Announcing XO EC-1.75

2011-01-17 Thread Richard A. Smith
 all the way to the Linux command 
line but soon after the A2 bring up dust settles it will be finished and 
undergo wider testing.  If it proves to be viable then the private code 
will be deprecated and eventually dropped from the tree.  We hope that 
removal of the PS/2 and keyboard/mouse code will bring the size back 
down to a point where an SDCC image will fit in the IO3731 and a fully 
open codebase + toolchain can be realized.

[3] Works as long as you can check out the private tree.  Compile fails 
if not.

Datasheets:

The public datasheet for the IO3731 is available here:

http://wiki.laptop.org/images/5/56/IO3731_v12_OLPC_20110117.pdf

This datasheet has the descriptions of the non-public interfaces removed.

Discussion:

Since the OpenEC mailing list already exists [4] I don't really see much 
value in creating a list thats specific to EC-1.75.  Any discussions are 
valuable to both code bases.  Therefore please see the OpenEC list if 
you want to follow the development of EC-1.75.  Questions on this 
announcement and simple questions or discussions are fine for devel@.l.o 
but please send things like patches or very detailed questions to the 
OpenEC list.

[4] http://lists.laptop.org/listinfo/openec

So, that's the plan -- right now we're using a non-free compiler (Keil) 
to build a mostly free (except for PS/2) EC for 1.75, but we're near to 
replacing the non-free compiler and the non-free PS/2 code at the same 
time.  As always, we welcome your help!

-- 
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [PATCH 1/3] olpc-battery: add support for CHARGE_FULL_DESIGN

2010-12-10 Thread Richard A. Smith
On 12/10/2010 10:22 PM, Andres Salomon wrote:

  Alright, thanks.  I guess a comment in the (kernel) source saying as
  much would be useful.
 
  On Fri, 10 Dec 2010 21:41:00 -0500 Paul Foxp...@laptop.org  wrote:
 
  i'm pretty sure those numbers (and the corresponding numbers from the
  1.5 DSDT) came from the battery manufacturer.  obviously we could move
  the data to the EC, but i'm not sure what the advantage of that would
  be.  i know that the numbers don't come from the battery itself.

Some history for those who may not know:

The design of the battery system in the EC is sort of out in its own 
class. OLPC sort of forced that to happen.

1) We used battery chemistry's few laptop have used and used both of 
them at the same time. NiMH and LiFePO4. (In the LiFePO4 case, I think 
we are the only laptop that has used it.)

2) In XO-1 we had the We hate the evil ACPI mantra.

To top it off we had this requirement of the battery lasting 2000 
cycles.  This requires some very funky stuff in the NiMH case. 
Basically for NiMH there is a really complex 12 page flowchart on 
charging.  We have now stopped caring about NiMH but the 1.0 and 1.5 
carry around a lot of legacy NiMH baggage.  In 1.75 we have purged all 
of that.

We had (good) reasons for doing all of the above but we basically forced 
quanta to come up with a battery subsystem on their own.  Not one that 
followed any of the accepted standards at the time.

The system that they came up with does not have any concept of battery 
capacity.  It uses markers inherent in the battery characteristics to 
determine when the battery is full and empty.  To track the state of 
charge (SOC) each chemistry has a setting for what the net difference 
for 1% SOC is in the accumulated current register (ACR).  If the ACR 
goes up or down that value then the SOC is ++ or -- 1%.  The ACR is used 
as a free running counter of charge.  When a full or empty marker is 
found the SOC is snapped to a full (97%) or empty (7%) [1].

So none of the max capacity values that you are asking about exist in 
the EC because they aren't necessary for things to work.  All the values 
about max capacity are values that I pulled from the manufactures 
datasheet and put up on the wiki.

http://wiki.laptop.org/go/Laptop_Batteries

Until now there hasn't been a reason to add this info into the EC code. 
  There is nothing hard about adding them except that its a few more 
commands for the EC, OFW, and kernel to add and then all be in sync.

There's also no concept of calibration in the EC code.  Last time Sascha 
brought all this up I began to think about how to do some sort of 
calibration.  It would be a nice feature to have.  We already have a 
some issues because the battery capacity varies +/- 5%.  If I had 
calibration then I could store the real capacity in the eeprom of the 
battery.  Hopefully I can get a chance to figure out a good way to do 
this for 1.75 and keep it so that batteries are backward compatible. in 
1.5 and 1.0

If you want the max capacity values added to the EC code with EC 
commands to fetch that extra the data then that's not a big problem just 
tell me.  But that won't help with running your new kernel on an old XO 
with older firmware so you will still have to hardcode it for them.

I think it makes sense to hardcode them until such time as I have 
calibration in the EC code and then the kernel can ask the EC (or OFW 
via DT for them)


[1]  I have no idea where those values came from. I'm changing them in 
1.75 to be more sane.

-- 
Richard A. Smith  rich...@laptop.org
One Laptop per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


  1   2   3   4   >