[olpc-help] Battery, embedded controller, and firmware conflict in 653
Richard A. Smith
richard at laptop.org
Sun Jan 6 18:14:45 EST 2008
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
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
> 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
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
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
> 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.
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
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
More information about the community-support