On Mon, Feb 28, 2011 at 4:02 PM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006@gmx.net> wrote:
Auf 01.02.2011 00:54, David Hendricks schrieb:
> On Mon, Jan 31, 2011 at 3:53 PM, David Hendricks <
dhendrix@google.com>wrote:
>
>> A few months ago, ITE open sourced the initial IT8500 EC patch on this
>> mailing list [...] updated since then.
>>
>> The attached patch basically does the same thing and has been deployed and
>> tested to work on the Cr-48. There are a few caveats, though:
>> - The boot BIOS straps register must be modified to select LPC. This can be
>> done with the attached "select_bbs.sh" script (Install iotools (
>>
http://code.google.com/p/iotools/) before using select_bbs). We worked
>> around this in the Chromium OS branch by adding a bus argument to the
>> programmer option, ie "flashrom -p internal:bus=lpc".
>>
That's something I don't understand. If the BBS are SPI, the flash
behind the EC should be invisible anyway. If the BBS are LPC, the flash
behind the EC should be visible and no BBS changes would be needed.
Could you clarify this?
That's correct. However, the correct BBS value might not be set by default.
For example, on the Cr-48 we have two SPI flash parts; the BIOS ROM which is connected directly to the southbridge's SPI controller and the EC firmware ROM connected to the EC (which is connected to the southbridge via LPC). When the machine comes up, the BBS setting is set for SPI. To flash the EC firmware, you need to set it to LPC.
>> - It is very important to disable power management daemons before running
>> Flashrom on this EC. I commented out the brute force method we use in the
>> Chromium OS branch that disables powerd, since IIRC Carl-Daniel has a better
>> approach in the works.
>>
While I advocate stopping powerd and related services, I have other
reasons for doing so: powerd may mess with the timing of flashrom, and
that may cause failures on some hardware.
The comments in your code indicate that you didn't manage to isolate the
reason for the powerd related failures back then. Any progress on that
issue?
Yes -- On the Cr-48 the ambient light sensor is attached to I2C via the EC. Polling the light sensor interrupts the EC and can cause very bad things to happen during firmware updates.
Also, the EC has a debugging mechanism which logs port80h traffic if enabled. This is helpful, but unfortunate if your kernel uses port80h as an IO delay mechanism (CONFIG_IO_DELAY_TYPE_0X80). I recommend that anyone using a laptop select one of the alternative IO delay mechanisms (port 0xED or udelay) to avoid issues.