Baytrail Release

IMG_20150620_153449As some of you on the G+ community are aware, I made a bit of a breakthrough with Baytrail last weekend. I’ve spent a lot of time this week trying to build the BOOT_STUB CBFS in such a way as to get reasonable behaviour, and I’ve gone about as far as I’m going to at this point in time. I think it’s probably best to list the things which are known not working, so you are going in with your eyes wide open:

  • T̶h̶e̶ ̶b̶o̶o̶t̶ ̶m̶e̶n̶u̶ ̶w̶o̶n̶’̶t̶ ̶b̶o̶o̶t̶ ̶a̶n̶y̶t̶h̶i̶n̶g̶ ̶u̶n̶l̶e̶s̶s̶ ̶y̶o̶u̶ ̶p̶r̶e̶s̶s̶ ̶a̶ ̶k̶e̶y̶.̶
  • T̶h̶e̶ ̶p̶a̶y̶l̶o̶a̶d̶ ̶w̶i̶l̶l̶ ̶n̶o̶t̶ ̶r̶e̶c̶o̶g̶n̶i̶s̶e̶ ̶t̶h̶e̶ ̶e̶M̶M̶C̶ ̶d̶e̶s̶p̶i̶t̶e̶ ̶t̶h̶e̶ ̶C̶h̶r̶o̶m̶e̶O̶S̶ ̶S̶e̶a̶B̶I̶O̶S̶ ̶b̶r̶a̶n̶c̶h̶ ̶h̶a̶v̶i̶n̶g̶ ̶p̶a̶t̶c̶h̶e̶s̶ ̶s̶p̶e̶c̶i̶f̶i̶c̶a̶l̶l̶y̶ ̶f̶o̶r̶ ̶e̶M̶M̶C̶/̶S̶D̶.̶
  • O̶n̶ ̶s̶o̶m̶e̶ ̶m̶o̶d̶e̶l̶s̶ ̶b̶o̶o̶t̶i̶n̶g̶ ̶f̶r̶o̶m̶ ̶S̶D̶ ̶d̶o̶e̶s̶ ̶n̶o̶t̶ ̶w̶o̶r̶k̶ ̶a̶t̶ ̶a̶l̶l̶ ̶d̶u̶e̶ ̶t̶o̶ ̶t̶h̶e̶ ̶c̶o̶n̶t̶r̶o̶l̶l̶e̶r̶ ̶b̶e̶i̶n̶g̶ ̶i̶n̶ ̶A̶C̶P̶I̶ ̶m̶o̶d̶e̶ ̶a̶n̶d̶ ̶S̶e̶a̶B̶I̶O̶S̶ ̶n̶o̶t̶ ̶c̶u̶r̶r̶e̶n̶t̶l̶y̶ ̶c̶a̶t̶e̶r̶i̶n̶g̶ ̶f̶o̶r̶ ̶t̶h̶a̶t̶.̶
  • Sound does not yet work in Linux (although the hardware is recognised, possibly a sound “profile” issue).
  • It may have issues with certain models of USB stick, and possibly some SD cards too (although it was happy enough with the 2GB, 8GB MicroSD, and 32GB SD cards I have).

Having said all that, what does work:

  • It will happily boot from many SD/USB cards/sticks.
  • If you’ve kernel >= 4.x  the mouse works OOTB.
  • It’s more or less usable (except for the aforementioned sound).

Go, have fun, but most of all DON’T ask me to fix any of it, because I’m not a coder. Once some more code is added to ChromeOS SeaBIOS (there hasn’t been a commit since December), I will happily update the payload to see if anything’s been fixed.

Script Update

I’ve made a major script update that will just update/restore the BOOT_STUB area of the ROM to load SeaBIOS, as well as flash the full ROM’s of previous, backup/restore your product info (serial no. and hardware ID) and flash a shellball ROM. The main advantage of leaving the majority of the ROM alone is hopefully quality and consistency improvement. However, in some cases this will mean that suspend does not work and VMX is disabled. I will write more, and update the FAQ when people give feedback.

cd; rm -f; curl -k -L -O; sudo -E bash


I’ve spent some time extracting shellball ROM’s for people who have flashed a full ROM, and want to go (semi) back to stock, but have mislaid their backup. For ChromeOS to update, you will need change the HWID to something valid e.g.

gbb_utility –set –hwid="PEPPY A2A-A2E-A5W" bios.bin

You’ll probably also want to download every file in the relevant directory to ensure the GBB script works. You can use lftp’s “mirror” feature to download all those files quickly and easily. Find the shellball ROM’s @

Legacy Slot Support for the Acer C740/Chromebook 11 and Acer C910/Chromebook 15

I’ve had a working updated legacy slot for the Acer C910/Chromebook 15 since mid-April, as some of you in the community may know. I took a few minutes tonight to incorporate that into the script, and I’ve also made it available for the Acer C740/Chromebook 11 (not that I’ve come across anyone who has one yet, but you never know). See the ROM Download page.

Clone your disk using Jeltka

Please note, if you don’t understand what’s going on here, it’s very easy to screw the source partition up, and lose your data! Be warned!

Obviously, boot into Jeltka first. Then, check the filesystem of the partition in question, in preparation for resizing the filesystem to it’s minimum size (please note, you may need to adjust device names accordingly):

e2fsck /dev/sda1

Then resize the filesystem to it’s smallest possible size using the -M flag of resize2fs:

resize2fs -M /dev/sda1

Mount the filesystem, check it’s size using df, and unmount it again (so fdisk can write the partition table successfully, later on):

mount /dev/sda1 /mnt
df -h
umount /dev/sda1

Now, we also need to reduce the size of the partition itself. This is so dd doesn’t copy more data than necessary (which could save you a lot of time). In the interests of safety, it’s always a good idea to make the partition at least 1GB bigger than the filesystem (fdisk and resize2fs, etc. calculate sizes in slightly different ways, the extra partition size ensures the partition is big enough to contain the filesystem). We also need to be careful because the version of fdisk included with Busybox uses the old 63 sector, default starting point for partitions, and your disk is probably partitioned with a 2048 sector starting point (this became the default in standard fdisk with the advent of GPT partitioning some years ago).

fdisk /dev/sda

To accommodate previous, we now change display units to sectors by pressing “u”. Press “p” to print the existing layout, to confirm the partition does indeed start at sector 2048. Then delete the existing partition – “d” followed by “1” (assuming the partition we’re concerned with is the first partition on the disk). Now we create a new partition with the same starting point – “n”, “p”, “1”, “2048”, “+14G” (where 14G is the size in gigabytes, you want the partition to be). Now type “p” again, and double check everything is as it should be, before hitting “w” to save the partition table and exit. Don’t worry too much if you’ve messed up here, as long as you can create a partition with the same starting point as the original, and enough size to accommodate the filesystem contained on it, you won’t lose any data. However, if you do something rash like create a new filesystem on an incorrectly sized/started partition, you will in fact be overwriting your nice data. In short, don’t do it!

Now we’re ready to do the actual copying using dd. I’m assuming here that you have a USB key/drive attached, and you’re going to output the partition image to a file on the USB key, with a view to dd’ing it onto a replacement HD/SSD, which you’ll physically put in your Chromebook subsequently. I’m assuming the USB key already has a compatible filesystem on it (ext4, FAT or NTFS, IIRC). Again, be careful to use the correct device name. First we’ll mount the USB stick somewhere suitable:

mount /dev/sdb1 /mnt

We should also backup the existing partition table and boot sector thusly:

dd bs=512 count=1 if=/dev/sda of=/mnt/bootsector.img

Then we’ll dd the partition to a file on the USB stick:

dd bs=1M if=/dev/sda1 of=/mnt/partition.img

If we had another console available, we could check on dd’s progress like so – find dd’s process number, and send a signal to it, to display progress every 60 seconds:

ps -e |grep dd
watch -d -n 60 kill -SIGUSR1 1234

Where “1234” is dd’s PID (will undoubtedly be something else entirely).

Assuming you didn’t run out of space on your USB whatever, dd will have completely successfully (eventually), and you can now set about swapping your HD/SSD out for a nice, shiny, big one. :)

Back already? Okay, now we’re ready to copy the partition table/bootsector over, and create a new partition to take advantage of all that space! Make sure you’ve mounted the USB whatever again.

dd if=/mnt/bootsector.img of=/dev/sda

Then use fdisk to create a new partition, as we did previously, only this time don’t specify a size (it will default to the end of disk).

Then, copy the partition image to the new partition we just created, using dd:

dd bs=1M if=/mnt/partition.img of=/dev/sda1

When this has finished, check you can mount the filesystem! Assuming you can, we can now resize the filesystem to take advantage of all that juicy space you’ve just purchased:

e2fsck /dev/sda1
resize2fs /dev/sda2


Another Month, Another ROM

“Yay”, I hear you say – someone has actually found a bona fide, reproducible problem with the last release. Apparently, the keyboard polling option in SeaBIOS causes double keyboard output in Grub, with devices which are capable of keyboard output via IRQ. So, I’ve made another release with the keyboard polling option of SeaBIOS removed. I recommend everybody using the last release (18/11/14) update if they ever envisage needing to use the Grub shell. Happy holidays!

A Call To Arms

Right, ladies and gentlemen. It’s time to give a little something back to the coreboot community who’ve made all this possible. I’ve created a self-extracting binary which will upload some information about the ROM you’re currently using (along with your dmesg output from boot) to the coreboot board-status repository. This repository is hopefully to be used to ascertain which boards a) currently work with coreboot and b) should remain “live” within the coreboot codebase. You will need an account at to post this output. Logging in with your Google account is fine, but you will then need to go to to find out what your username and password is to actually post the output (once the script tries to upload it using git).

What we would really like to see is hundreds of commits, as the repository has so far not been used very much. By putting everything into this self-contained, self-extracting script, the idea is to reduce the amount of dependencies and get a lot more people uploading information. I’d appreciate it if anyone reading this and using one of my ROM’s would download and run forthwith. Thanks.

New ROM Release – 181114

There’s a new ROM release today. What’s changed? Not very much, hopefully:

  1. Same underlying coreboot build/revision.
  2. Updated SeaBIOS which aside from improved SD/MMC support contains a “keyboard-polling” option, which may (or may not) have an effect for people who’ve been experiencing keyboard issues.
  3. Some slight tweaks to Jeltka, the main of which being the addition of the tg3 driver for the C710, so C710 owners can use Jeltka with a wired connection.

If your current ROM is working well, there’s no need to update, but this release will hopefully help improve things for the people who’ve had niggly problems.

Tentative fix/work-around for i915 GPU hangs

Some of you may have noticed the GPU hangs on Haswell Chromebooks in recent versions of you favourite distro. Well, a man called Fabrice G. (via email) furnished me with what appears to be a fix, this afternoon. It’s rather a long addition to the kernel cmdline, and I’m not sure if *absolutely* all of it is needed, but it certainly appears to be doing the job on my HP Chromebook 14, in CentOS 7, with a 3.17 kernel.

Simply add the following to GRUB_CMDLINE_LINUX in /etc/default/grub:

drm.debug=0 drm.vblankoffdelay=1 i915.semaphores=0 i915.modeset=1 i915.use_mmio_flip=1 i915.powersave=1 i915.enable_ips=1 i915.disable_power_well=1 i915.enable_hangcheck=1 i915.enable_cmd_parser=1 i915.fastboot=0 i915.enable_ppgtt=1 i915.reset=0 i915.lvds_use_ssc=0 i915.enable_psr=0

then run:

su -c "grub2-mkconfig > /boot/grub2/grub.cfg"

in CentOS/Fedora, or:


in Debian/Ubuntu/etc


Intermittent Website Issues

Apologies if you received a 502 “Bad Gateway” error when trying to visit the site in the last number of days/weeks – for some reason, without any apparent configuration change (although I guess there must’ve been a change in a default config somewhere) the server has decided to start resolving localhost as both *and* ::1. What governs which result is returned, I do not know, but the PHP FPM backend is only listening on the IPV4 address. Consequently, when ::1 gets returned for localhost and Nginx attempts to connect, there is nothing listening on that address and port, hence the error.

I’ve since hard-coded into the necessary config files, and the logs look good so far. Hopefully the number of visitors will stop going down now. ;)