C710 Firmware Package

For anyone lacking a valid backup of their original Chrome OS firmware, I've constructed a ROM image with an invalid serial number from my C710-2847 (the launch model).

C710 Firmware.zip

I've included instructions on how to modify the image to match your actual device before you flash it, which I strongly recommend.  I can't predict how Google functionality may be effected by an invalid serial number or the default  firmware hardware ID.

Also, please note that these instructions may be specific for the C710-2847 so pay attention if you have another model.  There's only one recovery image for the C710, so I'm confident the firmware will work on all models.  But, you may need to change more than 8 digits of the serial number with other models, IDK.

[Edit]  If you have a C710-842G32ii, then I recommend using the BIOS.BIN contained in the shellball (which is also included).  For an explanation & discussion of the implications - see the comments below - specifically, my conversation with Schokobecher.

C720 News

According to Jay Lee (Author of the Chrubuntu Script), "Ron Minnich has confirmed all the post-Pixel x86 Chrome devices should do SeaBIOS CTRL+L legacy boot."  Reference

Makes one wonder why the pre-Pixel 3rd generation Intel devices haven't been given this ability.  I realize that upgrading the firmware isn't something most people would want to do, but the slot in the C710 firmware was left full of zeros anyway, so ... why not?

General Advice on Flashing Firmware

I guess relatively few people are as paranoid as I am, but given the ease and speed of flashing from CrOS or Linux on the C710 itself, I suggest the following process:

1. Before you flash an image, create a backup (BACKUP.BIN) of the current firmware and generate an md5sum for it.
2. Now, generate an md5sum for the image you're about to flash, let's say NEW_FW.BIN.
3. Flash the image.
4. Even if everything appears to go perfectly, create a backup of the firmware again, i.e. READBACK.BIN and either compare it to NEW_FW.BIN  or (I prefer to) generate an md5sum for READBACK.BIN and compare the md5sums of the two.

This will allow you to revert to the state of the firmware before you started (with your BACKUP.BIN) and guarantee that the EEPROM now contains what you intended.

How To ... Reconstruct your Firmware from an Invalid Backup

If you're stuck with an invalid backup of your factory firmware because you followed some other geek's flawed instructions ;), the best solution is to reconstruct your firmware by replacing the first 2 MB of code in your backup ROM image with the first 2 MB of code from the default C710 firmware (bios.bin in the shellball). This replaces the Intel Management Engine, which is the part that's trashed in the backup, but keeps the rest of your original ROM intact.

You want to keep the rest intact because the firmware contains the serial number of your C710 which is used by Google in some manner - I don't know exactly how.  So, anyway, here's the Intel Management Engine:

Download

Un-zipped, this file should be exactly 2048 kb or 2 MB. You need to replace the first 2 MB of your ROM backup with this 2 MB. So, the resulting COMBINED.ROM file will still be 8 MB in size. Then you can flash the COMBINED.ROM and you should be back to factory (or close enough).  

There are many ways to accomplish this, I used a Hex Editor to open my BACKUP.ROM and 01_SI_ALL.BIN, selected all of 01_SI_ALL.BIN, copied it to the clipboard, pasted it over the first 2 MB of BACKUP.ROM and then saved the new combined file as COMBINED.ROM.  Describing the process was more difficult than performing it, trust me.  And there are much simpler methods using the command line, but I hate typing, so you're on your own there! ;)

Special thanks to Chusheng Zheng for giving me a push to finally document this stuff!

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!!

Compatability Work-Around & Spreadsheet Update

Just a quick note to let folks know that a few more distros may prove to be compatable with Chromebooks. In particular, distros that refused to be installed on GPT media or failed to boot from such media, can be installed to media with an (old & archaic) MBR-style partition table.  Then, the rootfs partition can be cloned to (new & improved) GPT media.  I haven't had time to do much with this yet, but I did manage to get Fedora 19 booted & working with this method.




Click Here to Open in a New tab or window

USB Bootable Media Toolbox

First, let me acknowledge that this is not ready for prime-time!  I have only tested it with 2GB, 4GB, 16GB & 32GB media, although theoretically, it should work for all bootable media 512MB and larger.  It still contains the CrOS kernel from June 2013, because I haven't had time to debug the issues with the updated kernel.  At this point, you will need access to another machine running Debian (or Ubuntu or their progeny) or a working ChrUbuntu install on your Chromebook.  You'll still need another machine to install a distro on the media anyway, so I gave up on trying to eliminate this requirement.

The archive contains a "ReadMe.txt" with detailed instructions.  In the end, you'll feel like you just did 16 cartwheels to move only a meter, but it works.  Be aware that everything I have tried to streamline or clarify the process has failed to produce bootable media, so substitutions or shortcuts of any kind are definitely not recommended.  Follow the instructions exactly, and you should end up with a piece of bootable media that you can install a Linux distro on.  Without further ado, here's the download:

Toolbox
MD5

Once you have bootable media, but before you install a distro on it (Step 10), you can create a backup of the disk with gdiskdump (included) and then restore it to this condition easily in the future.  Once a distro is running from USB, moving it to the HDD or SSD (say to to replace ChrUbuntu) is a relatively simple task.

Ooo...Boo...Who?

My final excuse for sticking with Ubuntu despite Canonical's descent into GUI madness is finally gone!  It turns out that "tap-to-click" can be enabled in Debian.  Find out how by looking here (Thanks Bob!).  Now, I will admit that I'll probably keep the ex-OS around to remind me exactly why I hate Unity with a passion.  But, having more options for the C7 is definitely a good thing!

Heads Up!

FYI, the latest CrOS kernel pushed out by Google (my C7 updated yesterday) breaks WiFi when combined with a pre-existing Ubuntu 12.04.2 install.  I don't have time to investigate the issue ATM, but be prepared to revert if you decide to give it a shot.

Spreadsheet Updated

I've updated the spreadsheet with my last few test results.  Still a few gaps to fill in, but my time is limited these days.



Click Here to Open in a New tab or window

New & Radically Improved ChrUbuntu!

If you abandoned ChrUbuntu some time ago, as I did, then you may have missed Mr. Lee's recent blog update.  Not only has he completely rewitten his ChrUbuntu script, he's conceptually changed his approach in several ways.  I haven't tried it out yet because I've got a number of things in-progress ATM, but I would definitely have to say that the new script looks "Impressive ... Most impressive!"  

New C7 with 16GB SSD at BestBuy for $199

BestBuy now has the revised model C710-2833 Acer C7 Chromebook with a 16GB SSD available for $199 with free shipping.  Otherwise, it appears to be identical to the original model C710-2847 sold by Google.  Don't miss the fact that BestBuy is selling it for $30 less than Acer's M.S.R.P.  I'm very curious if the SSD has a significant impact on battery life but haven't seen any reports yet.  No kickbacks here, I'm just trying to do my part to promote Chromebooks.

Media Player for Crouton

As an alternative to XBMC on Crouton, I am pleased to report that SMPlayer (a front-end for MPlayer) seems to work very well and that the visual quality of the video displayed is second to none.  My next candidate is VLC, primarily because I prefer multi-platform solutions.  That way, I have some reason to expect that a file I'm building or testing on Linux will play similarly on Windows (or vice-versa).

A Retraction

I sincerely regret that I must withdraw my enthusiastic endorsement of XBMC.  Although I remain very fond of the software, further use has revealed that the visual quality of the video it displays is noticably inferior to that of other media players.  I will admit that this difference may not be apparent to most people with most encoded video, but for me, it's a deal-breaker.  I have no idea why this is the case but hope it gets resolved.

CrOS Media Playback

I got the bright idea to exploit all that HDD real estate on the C7 by loading it up with media files. Unfortunately, Chrome OS's local video playback failed to impress me.  My testing was limited to the AVI & MP4 containers, standard definition video (DVD resolution) and mostly XviD & MP3, so other formats/codecs might fare differently.  In addition, I readily admit to being an obsessive videophile, so my expectations are very high.  In fairness to Google, I must also say that my opinion of Ubuntu's OOTB video playback is similar.

However, I can report that XBMC can be installed on Crouton and it works beautifully (at least for me)!  I would expect other media players to perform well too, but haven't yet confirmed this myself.

Chromebook Tips, Tricks & Errata

1. If, like me, you ever choose to clone partitions from your SSD/HDD to external media and then boot from that media - you'll swear someone slipped a hallucinogen into your coffee!  Be sure to complete the process by assigning the clone a new UUID like this:

$ sudo cgpt add -i 3 -u $(uuidgen) /dev/sdb

and avoid taking the trip to Wonderland all together.

___________________________________________________

2. To identify the current rootfs & kernel partitions: 

$ rootdev -s

will return the partition mounted as / like this:

/dev/sda#

where # is 3, 5, or 7. So, just subtract 1 from # to identify the current kernel partition.

___________________________________________________

3. Interestingly, the Acer C7 seems unable to boot from an SD card in the on-board card reader.  I have successfully created bootable SD cards using the slot, but must move them to an external USB reader to boot from them.  The only conclusion I can draw is that the firmware can only boot from a device connected via USB and that the card reader slot is, in fact,  not USB.

___________________________________________________

4. To fix the erratic trackpad behavior in Ubuntu:

sudo gedit /usr/share/X11/xorg.conf.d/50-synaptics.conf

after MatchIsTouchPad "on" in the file, insert these lines:

Option "FingerLow" "4"
Option "FingerHigh" "10"

Reboot and the problem should be resolved.  However, it's possible that a system upgrade (i.e. 12.04 to 12.10) may wipe out this change, so keep that in mind.

___________________________________________________

5. Another factor to consider regarding Linux Distros on Chromebooks is the version of kernel that the distro ships with.  Since Google's current CrOS kernel is version 3.4.0, I've generally stuck to distros that included kernel 3.4.0 or earlier.  While the CrOS kernel apparently incorporates some features of later kernels, for optimal compatibility, 3.4.0 seems like a good logical target.

Postscript - 05/30/13 - Just ran across this excellent explanation of the issue:
https://github.com/dnschneid/crouton/issues/129
I was merely speculating based on reasoning and experience.

Installation Method

[Edit]  This method is now deprecated in favor of the USB Bootable Media Toolbox.  This post remains  for historical reference only.  [08/31/13]

Here's a rather verbose & needlessly complex explanation of how I test Linux Distros on the Acer C7.  However, I think it should work with any Chromebook capable of booting from USB, but might require modification in some cases.  It is and will always be a "work-in-progress", so please let me know if something isn't clear.

Requirements

     1. A Chromebook in "Developer Mode."
     2. Same Chromebook running Developer Firmware.
     3. Same Chromebook with USB Boot enabled.
     4. USB bootable media (thumb drive or SD card).  From 4 - 16 GB will suffice.  16 GB will match the internal storage of every Chromebook prior to the Pixel, except for the Acer C7.  So, you could duplicate your SSD for development purposes.  See Tips #1 & #3 for relevant info.

The Method

     A. From ChromeOS, use cgpt to create a GPT partition table on your media (I'm using a 16GB SD card in the reader slot), add a kernel partition #6 which is 16 MB in size, and add a rootfs partition #7 using the remaining space.  Something like this:

cgpt create /dev/mmcblk0
cgpt show /dev/mmcblk0
       start        size    part  contents
           0           1          PMBR
           1           1          Pri GPT header
           2          32          Pri GPT table
    31537119          32          Sec GPT table
    31537151           1          Sec GPT header
cgpt add /dev/mmcblk0 -i 6 -b 34 -s 32768 -t kernel -l KERN-C -P 1 -T 1

The size of partition #7 here is the beginning sector of "Sec GPT table" (31537119) MINUS the beginning sector of partition #7 (32802).  Yes, the font is very tiny, but it preserves the appearance of the output.

cgpt add /dev/mmcblk0 -i 7 -b 32802 -s 31504317 -t rootfs -l ROOT-C
cgpt show /dev/mmcblk0

       start        size    part  contents

           0           1          PMBR

           1           1          Pri GPT header

           2          32          Pri GPT table

          34       32768       6  Label: "KERN-C"

                                  Type: ChromeOS kernel

                                  UUID: B6BF18B8-5B01-384F-AA69-7AD61AB56646

                                  Attr: priority=1 tries=1 successful=0

       32802    31504317       7  Label: "ROOT-C"

                                  Type: ChromeOS rootfs

                                  UUID: F33BC249-4577-D94A-8B7B-5B13D68DE423

    31537119          32          Sec GPT table

    31537151           1          Sec GPT header

Please note that (at least on the C7) although you can use the built-in card reader to create such media, you may be unable to boot from it without an external USB card reader.  At least, I haven't been able to.  So, it may be more practical to simply use a thumb drive. See Tip #3 for a theory.

     B. Create a debugging-enabled kernel from the current kernel, copy it to partition #6 and prioritize it to boot once.  See Tip #2 for an explanation here.

rootdev -s
    /dev/sda3
dd if=/dev/sda2 of=kernel_2.blob
dump_kernel_config kernel_2.blob > kernel_2.cfg
cp kernel_2.cfg kernel_debug.cfg

Now, replace the contents of kernel_debug.cfg with the following:

add_efi_memmap 
boot=local 
console=tty1 
disablevmx=off 
i915.modeset=1 
init=/sbin/init 
kern_guid=%U 
loglevel=7 
lsm.module_locking=0 
rw 
root=PARTUUID=%U/PARTNROFF=1 
rootwait 
tpm_tis.force=1 
tpm_tis.interrupts=0

These are commandline arguments passed to the kernel, so they should only be separated by spaces.  Here, I've alphabetized them on separate lines for clarity.  Now, wrap the new kernel with the verified block and  the new config:

vbutil_kernel --repack kernel_debug.blob \
  --keyblock /usr/share/vboot/devkeys/kernel.keyblock \
  --version 1 \
  --signprivate /usr/share/vboot/devkeys/kernel_data_key.vbprivk \
  --config=kernel_debug.cfg \
  --oldblob kernel_2.blob

Make sure the new kernel verifies OK and finally copy it to partition #6 and prioritize it.

vbutil_kernel --verify kernel_debug.blob
dd if=kernel_debug.blob of=/dev/mmcblk0p6
cgpt add /dev/mmcblk0 -i 6 -P 1 -T 1

     C. Boot your chosen distro on another machine (real or virtual) and install it onto partition #7 of your bootable media.  In some cases, you may need to create a filesystem on partition #7 prior to the installation, so I do just in case.  I've used both Ext2 and Ext4 successfully.  Either skip installing a bootloader or attempt to place the bootloader on partition #7.  I assume the distro must support GPT disks in order for this to work.

     D. Double check the GPT partition table for any changes that might prevent booting.

     E. Copy the necessary stuff from the current Chrome OS rootfs to partition #7.  Include the following complete folders:

/lib/firmware
/lib/modules
/usr/share/vboot

And these files as well:

/usr/bin/cgpt
/usr/bin/dump_kernel_config
/usr/bin/vbutil_*

Overkill perhaps, but handy for working on kernels from Linux too.

     F. Cross your fingers, reboot & attempt to boot from USB.  If it boots, reprioritize partition #6 and mark it as having booted successfully.

cgpt add /dev/sdb -i 6 -P 1 -T 0 -S 1


I adapted this method from the technique published by Olof Johannson, a member of the Chrome OS development team.

A Beginning

Prior to the introduction of the Pixel, running Linux on a Chromebook has required using the Chrome OS [CrOS] kernel with another distro's root file system.  As I understand it, Jay Lee, the developer of ChrUbuntu, recently switched from 32-bit (<=11.10) to 64-bit (>=12.04) Ubuntu which required him to substitute the Open Source Chromium OS kernel for the CrOS kernel distributed by Google.  Numerous issues with ChrUbuntu and a general lack of support led me to wish that I could switch back to Google's official (and constantly evolving) 32-bit kernel for CrOS.

Based primarily on the belief that Chromebook users would be better off sticking with Google's current CrOS kernel, I began testing 32-bit x86 Linux distros on my Acer C7. So far, the results of my experiments have been encouraging - not only does 32 bit Ubuntu 12.04.1 run without issues but it seems that most distros with Debian and/or Ubuntu lineage do as well.  Results with other distros have been mixed.  One key factor seems to be the use of initrd, which the CrOS kernel apparently does not support.  Keep in mind that I'm only reporting that these distros install and boot using my method because I did not test them extensively.



x86 Distros on the C7

Here, I'll attempt to document my method so that others can benefit.  IMHO, the distros I've highlighted represent the best match for the C7's hardware and resources.

In the meantime, I highly recommend checking out the Crouton script method developed by David Schneider.  It essentially enables you to run Ubuntu as an application on CrOS.  Credit for this find goes to Craig Errington.