Auf 07.03.2011 20:42, David Hendricks schrieb:
On Mon, Feb 28, 2011 at 4:02 PM, Carl-Daniel Hailfinger wrote:
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.
AFAICS the only reason why you need to set BBS to LPC for EC flashing is to make sure the MEM interface to the EC works because that interface lives in the 4G-something region. However, given that you use the I/O interface by default for EC communication, isn't that requirement obsolete unless someone explicitly changes the source to switch to MEM based EC communication?
On Mon, Feb 28, 2011 at 4:02 PM, Carl-Daniel Hailfinger wrote:
- 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.
Ouch! If powerd is stopped, can the user still suspend/shutdown the system? If yes, that may be another problem source.
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.
We should add most of the contents of your mail to the wiki on this page: http://www.flashrom.org/Laptops Would that be OK for you? The issues you describe are not limited to the Cr-48 and I'd rather have some info directly visible in the wiki before someone complains.
Regards, Carl-Daniel