Auf 01.02.2011 00:54, David Hendricks schrieb:
On Mon, Jan 31, 2011 at 3:53 PM, David Hendricks dhendrix@google.comwrote:
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?
- 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?
- Due to dependencies which may be introduced by the OEM/ODM EC firmware,
the code is not guaranteed to work for anything other than the Cr-48.
Noted.
- Carl-Daniel pointed out that the code might ignore the result of it87
init code. I've attempted to mitigate this in the patch (see internal.c), but I think it's just the symptom of a larger problem with how we detect and initialize IO bridges, and should probably be dealt with in a separate patch.
AFAICS the new probing just moved the problem elsewhere without solving it. A real fix would require our infrastructure to handle multiple Super I/O chips. I hope to add support for that soon, as it is a hard requirement for most laptops.
Signed-off-by: David Hendricks dhendrix@google.com
The code is not hooked up yet because probing needs to be sorted out.
Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net and committed in r1263.
Regards, Carl-Daniel