[flashrom] [PATCH] Initial ITE IT8500 EC support (second try)

[Carl-Daniel Hailfinger]

Auf 01.02.2011 00:54, David Hendricks schrieb:
> On Mon, Jan 31, 2011 at 3:53 PM, David Hendricks <dhendrix at 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?


>> - 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 at 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 at gmx.net>
and committed in r1263.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/