EHCI Debug Gadget & ChromeOS Flashrom on BBB in Arch Linux

su root

EHCI Debug Gadget

pacman -Syu wget
tar -xzf Ehci-debug-gadget-patches.tar.gz
cp usbdebug-gadget/g_dbgp.ko /lib/modules/`uname -r`/kernel/drivers/usb/gadget
cat /dev/ttyGS0

ChromeOS Flashrom

pacman -Syu git make gcc dtc
git clone -b firmware-nyan-5771.B
cd flashrom
echo BB-SPIDEV0 > /sys/devices/platform/bone_capemgr/slots
flashrom/flashrom -p linux_spi:dev=/dev/spidev1.0


Procedure for building ChromeOS Flashrom on BeagleBone Black

Why do this? – Because you want to try to make sure you have a version of flashrom that will recognise all Chromebook SPI chips. Also, you may just want to write an area of the ROM instead of the whole thing (such as BOOT_STUB or RW_LEGACY) and upstream Flashrom doesn’t allow you to do that.

Before beginning you will need to make sure your BBB is connected to the internet. If you’re connecting using the micro-USB cable, you will need to do some network setup. On the computer the BBB is attached to run:

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A POSTROUTING -s -o wlp1s0 -j MASQUERADE

Where wlp1s0 is the name of the internet connected interface on the BBB attached computer.

On the BBB run:

route add default gw

Also make sure you have a valid DNS server/forwarder entered in /etc/resolv.conf (nameserver=) and that you run ntpdate to make sure the BBB’s time and date are correct (for validation of HTTPS certs, and also making sure any rebuilds get done properly due to modification time) e.g.


Install essential dependencies:

apt-get install build-essential libpci-dev libfdt-dev

Clone a suitable branch of the ChromeOS Flashrom repo (I chose this one as a reasonably new ARM Chromebook’s Flashrom, so hopefully it’s quite up to date):

git clone -b firmware-nyan-5771.B

Change into the flashrom directory and run:


Follow the “spidev” setup instructions from

Reboot, and from your home directory run:

flashrom/flashrom -p linux_spi:dev=/dev/spidev1.0

You will getting an error about the EEPROM, but that means it’s working, believe it or not. :D

Test with a command such as:

flashrom/flashrom -p linux_spi:dev=/dev/spidev1.0 -w -i BOOT_STUB:some_boot_stub.cbfs

I’m not sure if “enjoy” is the right word.

Procedure to get sound working in Fedora 22 on ASUS C300 Chromebook

This will probably work with other distro’s/Baytrail Chromebook models.

  1. Get to a terminal.
  2. Type “alsamixer”.
  3. Press the brightness down key AKA F6.
  4. Find “Left Speaker Mixer Left DAC” and press “m” to unmute.
  5. Find “Right Speaker Mixer Right DAC” and press “m” to unmute.
  6. Update your distro to hopefully as new a kernel as possible (mine went to 4.1.4-200). This ensures that the sound card has the latest available firmware.
  7. Reboot.
  8. Enjoy shiny (and possibly slightly dodgy) sound.

Test ASUS C300 SeaBIOS image with full SD/eMMC support

Thanks to Kevin O’Connor’s brilliant work this week, I now have an image for you to test. Please bear in mind that I’ve only tested this to the extent that I’ve loaded Fedora 22 onto the eMMC and booted from it. There is no guarantee that it won’t do something horrid to your data, so don’t put anything important on there unless you have a backup.

As the keyboard doesn’t yet work in syslinux using the new image, you’ll have to use the latest image from the script to boot your LiveUSB, install you distro to the eMMC, and then flash the test image to get it to boot from the eMMC.



(From where the files are downloaded).

sudo ./flashrom -w -i BOOT_STUB:asus-c300-test.cbfs

Link to the code:

Baytrail WIP

Thanks to some big, recent donations I’ve managed to pick up an ASUS C300 and I’m working with Kevin O’Conner (of the SeaBIOS project) to get upstream SeaBIOS working properly on Baytrail Chromebooks.

What’s been found so far:

  1. Interrupts are not working at all, hence why the boot menu gets stuck.
  2. At least on some of the Baytrail Chromebooks, the SD/eMMC controller is in ACPI mode which SeaBIOS doesn’t currently pick up, hence why the eMMC and SD cards won’t work at all, at boot, on some models.
  3. Once interrupts are (hopefully) working and an address hard-coded for the SD/eMMC controller, it should mean that the keyboard works (both internal and external), the boot menu doesn’t need a key press any more, and both eMMC and SD are bootable.

Hopefully won’t be too long before we have some good news for Baytrail hopefuls.