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 review.coreboot.org to post this output. Logging in with your Google account is fine, but you will then need to go to http://review.coreboot.org/#/settings/http-password 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 https://johnlewis.ie/board-status.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. ;)


Another day, another slew of ROM’s. The evolution continues. Today’s is mostly about fixing things in the previous release (01/09/14). So, what’s in this release, I hear you ask?

  1.  I’ve removed the Intel framebuffer driver from Jeltka because Kernel Mode Setting doesn’t play nicely with kexec. Despite being a nice idea, VGA ROM independent Jeltka is therefore off the table.
  2. In addition to the automation and stability recently introduced by the script, having a separate coreboot tree for each base model (currently 12 not including the 2 ChromeOS coreboot trees I’ve kept hanging around after switching to upstream coreboot for Falco and Peppy), and moving to an md5sums file arrangement (simplifying upload and script maintenance), I’ve moved to having a “links” file for Haswell and Sandybridge/Ivybridge based Chromebooks, and using the same graphics id’s (0106 for Sandy/Ivybridge, 0406 for Haswell) across the board. This means there is much reduced chance of PEBKAC and ID-10T from my end resulting in ROM’s which don’t initialise the display (and leaving it to a Linux kernel to do it).
  3. The make process is now even simpler – make clean x 2, make, add choice of 2 links files, add Jeltka, upload.
  4. There will be *NO* Flashrom in Jeltka, as flashing with upstream Flashrom isn’t possible unless you’ve already used an external programmer on your Chromebook’s SPI chip. In lieu of that, I now recommend starting an Arch install to the point where you’ve setup the network, and then change VT’s to download flashrom and a ROM from my site. Similarly this is my recommended method of rescue, as the arch installer/rescue also has useful utils like Testdisk.

ROM Updates – 01/09/14

All ROM’s for all models have been updated. The main changes are:

  1. Subsystem vendor ID’s added to Falco, Peppy, Leon, and Wolf to ensure back-light is enabled by kernel > 3.15.
  2. All ROM’s now using a 4 MB CBFS with Jeltka as an ELF payload (this removes size overhead and other complications of floppy images).
  3. Jeltka updated to load the i915 frame-buffer driver (which means even if there’s something wrong with the VGA binary/ID’s you can still get a display by pressing ESC and 2 at the right times, assuming no USB device plugged in).
  4. Added e2fsprogs/fdisk/USB/MMC support to Jeltka (for basic filesystem/partition checking and manipulation). Be careful of Buildroot’s version of fdisk as it defaults to a first sector at 63 and DOS compatibility mode, and, if you switch it off by pressing “c”, fdisk will default to a first sector of “1”. This will probably cause problems, as most distros default to sector 2048 for alignment purposes. It means that resizing your filesystem will be tricky, if you forget to to recreate the partition at 2048, and it may appear that your filesystem is therefore b0rked!
  5. TPM conditionalised in dsdt.asl for any boards that have it, to avoid TPM being enabled and causing issues with suspend.
  6. I’ve made my own Panther/Zako compatible ROM to enable the 4MB CBFS for that model.

As always see the download page.

Suspend fixed in C720/Peppy ROM

As the name implies, suspend is fixed in the C720/Peppy ROM’s. Turns out I had forgotten to conditionalise/remove something from the board’s DSDT, which I didn’t forget for Falco/HP Chromebook 14.

Additionally, I have updated all the other Haswell Chromebook ROM’s to make sure the DSDT is suitable in those.

Jeltka has also had i915 frame buffer support added, so even if something is wrong with the graphics ID/ROM, you can still easily get the display to work. There’s probably something else in there which escapes me, but that seems like enough for the moment.

New ROM releases.

IMG_20140818_230211These contain an updated version of Jeltka. CentOS and Fedora installs now work wirelessly, I’ve added Arch support, and also rewritten the script from scratch. The script will semi-automatically configure the wireless connection – you just have to input SSID and PSK.

On the Linux side, I’ve put ext utils in, and enabled USB mass storage, so Jeltka can act as a rudimentary embedded rescue, getting files off or even partition images, as long as you stick to EXT2/3/4 for your FS.

I’ve managed to do all this and keep it within the original 2.88MB limit, so there’s still over 500k to play with. Suggestions welcome as long as it doesn’t mean SSL support, which balloons the image over the 3.44MB limit as is.

Running should be self-explanatory, except you should run jeltka.sh once logged in. Go get ‘em.


Making the touchpad work on a HP Pavilion Chromebook in Ubuntu 14.04 and 14.10

For Ubuntu 14.04 you have to add the following to /etc/rc.local before “exit 0″:

modprobe -r chromeos_laptop
modprobe i2c-i801
modprobe chromeos_laptop

For Ubuntu 14.10 you also have to add a “sleep 1″ after loading the i2c module, so it would in this case read:

modprobe -r chromeos_laptop
modprobe i2c-i801
sleep 1
modprobe chromeos_laptop

Then copy /usr/share/X11/xorg.conf.d/50-synaptics.conf to /etc/X11/xorg.conf.d/51-synaptics.conf and edit it adding the following lines to the inputclass section named “touchpad catchall”:

 Option "FingerHigh" "5"
Option "FingerLow" "5"

Reboot, and there you have it!

Extracting the shell-ball ROM using a ChromeOS image

As an example I’m performing this on Fedora 20. I assume that you’re doing it from your home directory.

1. Download the linux script for downloading ChromeOS images. From the cli type/paste:

wget https://dl.google.com/dl/edgedl/chromeos/recovery/linux_recovery.sh

2. Make the script executable so it will run:

chmod +x linux_recovery.sh

3. Run the script:


4. Type the model name of the Chromebook you’re trying to get the ROM for e.g. “HP Chromebook 14″, then type the number of the corresponding image e.g. “8”. Once the file has downloaded, the script will attempt to extract it with a view to writing to USB, however, the tmp mount in Fedora doesn’t get allocated enough space and you get the following error:

chromeos_5712.88.0_falco_recovery_stable-channel_mp-v2.bin: write error (disk full?). Continue? (y/n/^C) 

To which I say “n”.

5. Remove the partially extracted file, or you will get space errors:

rm /tmp/tmp.crosrec/*.bin

6. Note the name of the file above, as it will be needed for subsequent commands. Unzip the file into your home directory like so, adding “.zip” onto the end of the filename you noted above:

unzip /tmp/tmp.crosrec/chromeos_5712.88.0_falco_recovery_stable-channel_mp-v2.bin.zip

7. Use kpartx to make sense of the image’s partition structure. First of all make sure it’s installed. This is also a good time to install another dependency which will be needed later (specifically by the extract script):

sudo yum install kpartx sharutils

8. Run kpartx to add a mountable mapping to each of it’s partitions in /dev/mapper:

sudo kpartx -a /tmp/tmp.crosrec/chromeos_5712.88.0_falco_recovery_stable-channel_mp-v2.bin

9. The partition we want to get at is the system partition, which is now mapped to /dev/mapper/loop0p3 however, we have to mount it read-only otherwise mounting will fail:

sudo mount -o ro /dev/mapper/loop0p3 /mnt

10. Create a directory for the extracted files (you don’t want them messing up your home directory):

mkdir shellball

11. Do the extraction:

/mnt/usr/sbin/chromeos-firmwareupdate --sb_extract shellball

12. Write a valid hardware id (you can get a list of all id’s by running the linux_recovery.sh script without any search terms) to the shellball ROM so that ChromeOS will update, for example:

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

13. Optionally set GBB flags as you like:

gbb_utility –set –flags=0x489 bios.bin bios.bin.new

14. Download statically linked flashrom and flash extracted BIOS:

wget --no-check-certificate https://johnlewis.ie/flashrom &&  sudo ./flashrom -w shellball/bios.bin


Linux & custom Chromebook firmware