[olpc-help] Battery, embedded controller, and firmware conflict in 653

[Richard A. Smith]

Rafael Enrique Ortiz Guerrero wrote:

> but anyway if you want to know more you can mail richard smith. 
> richard at laptop.org <mailto:richard at laptop.org> he is the engineer in
> charge of all these issues at OLPC

I discourage people from contacting me directly for 2 major reasons.
1) I don't scale well.
2) The information does not get added to the information collective at
large.

Of course, there are plenty of questions that I'm the most qualified to
answer and I'm happy to help answer.  In those cases I think its best 
for people to use the standard community help channels and say in the 
message. "I've been told to ask richard about this..."  then the 1st 
level support volunteers have a chance to provide/aquire as much info as 
possible.  They can cc: me directly if they need my help answering. 
Involving the support people is the only way to make sure the knowledge 
gets archived and things scale.

I place a higher priority on responding to questions from the support
volunteers than questions from the mass public.  So you will probably 
get help from me _faster_ this way than by mailing me directly.

Now lets get into your issues....

> After updating to 653 my XO-1 failed to see the battery.

This seems odd to me.  The OS build (ie 650,653, joyride-xxx) has very
little to do with the battery management.  The OS has to talk to the EC
to get battery info but I've not yet heard of a case where updating the
build caused the battery to go unrecognized.  Perhaps you are the first.

The system firmware (q2d06, q2d07, etc) has _everything_ to do with
battery management.  Are you sure you aren't taking about a system
firmware update that might have caused you problems rather than a os
build update?

> Although it would power with A/C, it would not recharge (no led) as
> per ticket #543 I read this as a firmware conflict as well as an
> eeprom int conflict.

Not really.  The data in the eeprom and the firmware are pretty
independent.  There has never been a conflict.  What conflict exactly 
are you referring to?

> Problem is, I updated the
> firmware(http://wiki.laptop.org/go/Upgrading_the_firmware) before
> loading
> batman.fth(http://wiki.laptop.org/go/Battery_Charging#EEPROM_Init).

batman.fth is completely unrelated to a system firmware update. 
batman.fth is a specific tool that was used to detect and fix a case 
where older (much older) EC code would do bad things to the data inside 
the EEPROM of NiMH batteries.  It is not needed in a normal firmware 
update procedure.

batman.fth does NOT help with the batteries that were shipped in G1G1 
laptops as it only understands NiMH batteries.

> Now it will not boot, just hangs on the firmware update, and shuts
> down for lack of battery. Any ideas on flashing eeprom before the
> firmware boot?
> I was able to get it back up by a USB boot install. I went back to
> 650, incase It was 653 vs. q2d07. The reinstall put q2d06 back on,
> and I was able to get into sugar.

The above confuses me. OS 653 build has q2d06 as the system firmware 
which should be the same as the firmware that was installed on the 
laptop when it shipped.

So updating to 653 would not have caused a firmware update to happen.

Perhaps you updated to 653 and _then_ tried to update to q2d07?  If that 
s the case then your description makes more sense.  If you somehow lost 
your battery after you upgraded to 653 but before you tried to update to 
  q2d07 then the update to q2d07 would fail due to lack of battery.

Going back to build 650 would have fixed the issue but not because its 
build 650 but because it overwrote the bootfw.zip file with q2d06 and so 
the firmware upgrade procedure was skipped because you were already at 
q2d06.

> I'd love to use batman.fth to
> update the eeprom, but the instructions on the page ( 
> http://wiki.laptop.org/go/Battery_Charging#EEPROM_Init) seem to work
> on earlier builds only. I used: fload /media/"drive-label"/batman.fth
>  no command recognized

Openfirmware requires backslashes '\' for filepath names not '/'. '/' 
are device node indicators.  Where did you see the info on /media for 
openfirmware? /media is where usb disks get mounted under linux.

The proper command at the 'ok' prompt would have been.

fload u:\batman.fth
or
fload disk:\batman.fth

assuming 'batman.fth' is in the root directory of the usb disk. u: is 
shorthand for disk:

But anyway batman.fth won't fix your problems.  Well at least 
bat-check-and-recover won't.

However, we _can_ use batman.fth to diagnose whats going on and allow 
you to dump a copy of the EEPROM contents so I can take a look at it.

I'll update batman.fth (and fix the wiki) so that it knows about BYD Fe 
batteries and provide instructions for using it a bit later.

Using batman.fth as a diagnosis tool is helped greatly if you have a usb 
keyboard.  Many commands in batman.fth put the EC into reset so you lose 
the XO keyboard.  Which means that you would have to power cycle 
in-between every command.

Do you have a USB keyboard available?

-- 
Richard Smith  <richard at laptop.org>
One Laptop Per Child