Promote C7 Development Efforts

If you can spare a few bucks for the cause, John Lewis is accepting donations for the purchase of an Acer C7 and other gear in his Coreboot+SeaBIOS project.  He's already come a long way in his quest to "open up" Chromebooks and is certainly deserving of our support.  If you'd like to have the option of using your  Chromebook as a more all-purpose laptop, he's definitely the horse to bet on in this race!

http://johnlewis.ie/

How To ... Turn a Brick back into a Chromebook!

As long as you have a valid backup of your original firmware, you can restore your C7 by following these instructions.

But, before you go any further, double check the contents of your backup at address 0x00001000 (like with a Hex Editor).  If that byte contains 0xFF, then your backup is invalid and will brick your C7 again, so STOP!  I will address this situation in another post soon.

OK now, first of all, you'll need the following gear:
1. A Bus Pirate
2. A Bus Pirate Probe cable
3. A Pomona 5250 SOIC Clip
Do not substitute the 3M part for the Pomona, as it won't work.  The Bus Pirate is an inexpensive hacker's tool that can serve as an external chip programmer.  It's supported by flashrom and although painfully slow, it does the job quite well.  It all cost me ~$60 including shipping.

This presentation will provide a good step-by-step guide to disassembling your C7 to get access to the EEPROM which is on the top side of the  motherboard (MB), under the keyboard.  It looks like a horrible nightmare, but thanks to these guys, it really isn't too difficult.  However, I do recommend disconnecting both the keyboard and the trackpad, their cables and connectors are too fragile to risk leaving connected, IMHO.  I will admit that reconnecting them is a royal PITA, though.
https://docs.google.com/file/d/0Bzig09VSdjW1azRKaEtqZk5MZW8/edit?usp=sharing

Here's an ASCII diagram detailing how to connect the Bus Pirate (BP) to the C7's EEPROM.

TXT
PNG

On my MB, the chip is a Macronix MX25L6406E, but yours might differ.  You should also be aware that there's more than one probe cable design and the color schemes vary.  I'm using the Seeed Studio probe cable design.  For more info on the BP, consult:
http://dangerousprototypes.com/docs/Bus_Pirate

For instructions on programming the EEPROM, consult this authority:
http://johnlewis.ie/unbricking-a-samsung-series-5-550-chromebook/
He's using a Samsung 550 Chromebook, but the procedure is the same.  The C7's battery pack is, of course, removable.  So, as long as the battery is disconnected, it's already "cut."

Important Discovery to Prevent Bricking

Through rigorous application of the experimental method, I have discovered that (at least on the C7) a valid backup of the firmware is only possible with hardware (HW) write-protect (WP) disabled.  In this context, software (SW) WP seems to be irrelevant.

To clarify, if you use flashrom to read the EEPROM without bridging the WP jumper on the motherboard first, that backup copy of the firmware will be invalid.  If you subsequently flash that backup (or a modded version of it) onto the EEPROM, it will brick the device.

Does this make any sense?  No, but it appears to be a fact.  Apparently, with HW WP enabled flashrom just silently (no error messages) fails to read the Intel Management Engine (and possibly other) code in the firmware image.  I have found references to the fact that Google patched flashrom so that it would not crash under these conditions, but have no idea why.  I would have preferred that it crash, rather than silently create an invalid image of the firmware.  Of course, I must acknowledge that these tools were never intended for use by the consumer.

With this knowledge, I have successfully enabled the Dev Mode Boot Screen bypass with the stock firmware.  So I can now confirm that "the hack" can be performed safely, as long as you keep this fact in mind.  But, be aware that some of the instructions on the web do not take this into account and if followed to the letter, will brick your C7.  I recommend only this source:

http://johnlewis.ie/neutering-the-developer-mode-screen-on-your-chromebook/

John's information was essential in my effort to de-brick my C7.  He's using a Samsung 550 Chromebook, but the platforms are similar enough in this case.

Acer Chromebook TNG

Looks pretty sexy, right?  No, I do not mean the guy in the background or the commentator.

What The ... ?!?

The situation with CrOS firmware is apparently more complex than I thought.  Now that I'm running the default Recovery firmware with both hardware and software write-protect disabled, I'm able to read the Intel Management Engine code with flashrom!

I'm completely baffled by this bizarre behavior, although it may begin to explain why "the hack" doesn't always brick the device.  Under current conditions, software write-protect can be enabled only temporarily, since it resets to disabled when I reboot.  It appears to me that only the CrOS version of flashrom supports the software write-protect feature.

C7 Default Firmware

I should also report that the default firmware for the C7 (contained in the recovery image) also has "the hack" enabled.  Given the CrOS developers consistent refusal to help anyone bypass the 30 second delay at the scary boot screen, I'm guessing that this may have been how it was discovered.

One consequence of "the hack" is that with only a 1.5 second pause at the scary boot screen, it's rather difficult to boot from USB.  It can still be done, but you've got to be quick.

"It's Alive!" The Resurrection of a Chromebook

Thanks to Bill Richardson (ChromeOS developer) my C7 has regained consciousness!

It boots again, although it's personality seems subtly different somehow.  It's currently running the default Parrot firmware - which I believe is responsible for the difference.  I'm still trying to figure out how to reconstruct the factory firmware, but I'm fairly confident that I'll get there eventually.

The problem, as I understand it, is that part of the firmware (the Intel Management Engine) is actually "cloaked" by the time the CPU is initialized.  As a result, a backup copy of the firmware read by Flashrom is invalid.  To conceal this code, the EC (Embedded Controller) returns 0xFF for every byte in this region.  Since Flashrom is unaware of this trickery, it merely writes the fake data (0xFF) to the backup copy.  If this backup is then written back to the EEPROM, it writes 0xFF over the entire Intel ME and Viola!  You just turned your Chromebook into a brick!

I have confirmed all of this information to my satisfaction by examining multiple firmware images.  Given these facts, what I can't understand is why "the hack" doesn't produce a brick every time it's attempted!

I'll post further details on de-bricking as time permits.

Death of a Chromebook

It's time for me to swallow my pride and admit that I killed my Chromebook. Oh, okay, so maybe it's not really dead, but it might as well be. I guess, technically speaking, it's in a persistant vegetative state - like a coma.

For those who don't yet know, there's a hack circulating the web that will supposedly allow you to shorten the 30 second delay at boot that comes with developer mode to 2-3 seconds with minimal risk of problems. You just have to flash the Read-only firmware. Well, verily, I say unto you, "Don't believe the pipe!" (RIP, Richard). It's a lie!

I wish to state for the record that I'm not exactly a noob at flashing EEPROMs. I've been flashing devices of some sort for probably 35 years and have never bricked anything that I couldn't recover ... until this Chromebook! I flashed the patched firmare and everything seemed to go perfectly. There was no indication of any sort of problem, so I rebooted and ... nada. It hasn't booted up since. It powers on and after 20 seconds or something, the fan kicks in, but thats all it ever does. Now, perhaps, you get the coma analogy.  The light comes on, but there's nobody home.

So 2 weeks, $60 in gizmos and probably 120 hours of research and hacking later, all I can say is: Kids, don't try this at home! Please!!