I'm hoping that other extracted Google blobs are not so finicky - the Embedded Controller blob, for instance?
As far as the EC, it's all open source, and in public repos at Google. You can rebuild it instead of using their binary.
Thanks for that Martin. Still, I'm intimidated by the EC blob.
On my board, Google's forked flashrom says: Found Nuvoton flash chip "NPCX796F". Some Nuvoton ECs, and probably this one, are ARM chips.
3rdparty/chromeec/README.md says: If you want instant gratification, you can fetch the source code directly. However, you will need the tool-chain provided by the Chromium OS development environment to build a binary.
And then, at http://goo.gl/i5sMq, "Flashrom @ Chromium.org" says: For these examples, we assume the x86 firmware ROM is connected directly to the host via SPI and the EC ROM is connected via the EC to LPC.
And then, no matter how this EC blob is acquired, that Google page does not seem to disclose exactly *how* this EC ROM image is suppose to get from the coreboot ROM image, and into the separate EC ROM.
But, for instance, I see u-boot/cmd/Kconfig actually has: menu "Firmware commands" config CMD_CROS_EC bool "Enable crosec command" depends on CROS_EC default y help Enable command-line access to the Chrome OS EC (Embedded Controller). This provides the 'crosec' command which has a number of sub-commands for performing EC tasks such as updating its flash, accessing a small saved context area and talking to the I2C bus behind the EC (if there is one).
So, even after going to the trouble of getting an EC ROM image into coreboot, how does this get into the EC ROM? Does coreboot have some "magic" that checks the EC ROM version, and then automatically flash the EC ROM? Or, does this have to be done manually?
And, if manually, and if u-boot is not being used, does this "crosec" command have to be found or built, to run in an x86 linux for instance, and used to actually flash the EC ROM?