A few months ago, ITE open sourced the initial IT8500 EC patch on this mailing list ( http://www.flashrom.org/pipermail/flashrom/2010-August/004382.html) so that we could check it in to the Chromium OS branch. It didn't quite make it upstream, and has been 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".
- 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.
- 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.
- 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.
*Here is the text from the original patch submission: The attached patch adds generalized support for IT8500/IT8502 embedded controllers. The patch was developed by Google for Flashrom r1082, but applies cleanly against r1130. It was tested for IT8500E on a Chrome OS platform and may require modification depending on ODM/OEM customization and EC firmware version.
This patch is not officially supported by ITE Tech Inc.*
Signed-off-by: David Hendricks dhendrix@google.com (The original patch also included a sign-off from Yung-chieh Lo @ Google and Donald Huang @ ITE).
-- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.
argh! of course I forgot to actually attach the patch. Here we go again:
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 ( http://www.flashrom.org/pipermail/flashrom/2010-August/004382.html) so that we could check it in to the Chromium OS branch. It didn't quite make it upstream, and has been 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".
- 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.
- 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.
- 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.
*Here is the text from the original patch submission: The attached patch adds generalized support for IT8500/IT8502 embedded controllers. The patch was developed by Google for Flashrom r1082, but applies cleanly against r1130. It was tested for IT8500E on a Chrome OS platform and may require modification depending on ODM/OEM customization and EC firmware version.
This patch is not officially supported by ITE Tech Inc.*
Signed-off-by: David Hendricks dhendrix@google.com (The original patch also included a sign-off from Yung-chieh Lo @ Google and Donald Huang @ ITE).
-- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.
Signed-off-by: David Hendricks dhendrix@google.com
...and the select_bbs.sh script.
I need more coffee.
On Mon, Jan 31, 2011 at 3:54 PM, David Hendricks dhendrix@google.comwrote:
argh! of course I forgot to actually attach the patch. Here we go again:
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 ( http://www.flashrom.org/pipermail/flashrom/2010-August/004382.html) so that we could check it in to the Chromium OS branch. It didn't quite make it upstream, and has been 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".
- 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.
- 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.
- 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.
*Here is the text from the original patch submission: The attached patch adds generalized support for IT8500/IT8502 embedded controllers. The patch was developed by Google for Flashrom r1082, but applies cleanly against r1130. It was tested for IT8500E on a Chrome OS platform and may require modification depending on ODM/OEM customization and EC firmware version.
This patch is not officially supported by ITE Tech Inc.*
Signed-off-by: David Hendricks dhendrix@google.com (The original patch also included a sign-off from Yung-chieh Lo @ Google and Donald Huang @ ITE).
-- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.
Signed-off-by: David Hendricks dhendrix@google.com
-- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.
Signed-off-by: David Hendricks dhendrix@google.com
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
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.
On Mon, Feb 28, 2011 at 4:02 PM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006@gmx.net> 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.
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.
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
-
Carl-Daniel Hailfinger -
David Hendricks