2015-08-28 Librem 13: Weekly BIOS Update

Author: Larry.Moberg@puri.sm

This post gives some details on the Librem 15 rev2 prototype. One challenge with developing BIOS is finding parts that can be reused; coreboot makes heavy reuse of certain pieces of code.

Very Similar

Starting with the chips on the back of the mainboard, the 15 prototype uses the same ene KB3930QF-A1 as the Librem 13, and it is configured to read from an external Macronix MX25L512 SPI flash for firmware. The 15 has this SPI chip on the front side of the board between the DIMMs and the USB3 ports.

The 15 prototype uses a Realtek ALC269 codec via the AC’97. The Librem 13 should have a very similar codec.

On the front (the side visible just by removing the back laptop case), the 15 prototype uses an MX25L6406E SPI flash for the BIOS. The Librem 13 prototype uses a GD25Q64B, but other than the Intel Firmware Descriptor fields for JEDEC ID etc, these chips are interchangeable.

Both CPUs are Broadwell-U. They use the same FSP. They both have the LPC bus exposed on pads.

These similarities help us by reducing the amount of variation between the board subdirs in coreboot and can use the same development rig.

Acceptance Test Matrix

We’ve put together the following tests to validate coreboot builds:

  1. Cold boot: memory controller works.
  2. Cold boot: all installed DRAM is online.
  3. Cold boot: graphics controller works.
  4. Cold boot: SATA controller succeeds.
  5. Cold boot: EC controller responds ok to init code.
  6. Cold boot: LCD backlight turns on.
  7. Cold boot: linux boots ok in text mode.
  8. Cold boot: linux boots ok in framebuffer (boot splash) mode.
  9. Cold boot: X initializes the LCD at full native resolution.
  10. Cold boot: X enables hardware acceleration.
  11. Boot time: Cold boot to grub succeeds in less than a set timeout.
  12. Boot time: Reboot from linux back to linux succeeds in less than a set timeout.
  13. Boot time: Power down succeeds in less than a set timeout.
  14. SeaBIOS test: keyboard works.
  15. Grub test: keyboard works.
  16. Grub test: text mode and framebuffer graphics work.
  17. Cold boot to USB linux succeeds. (We plan to use SeaBIOS for boot device selection, barring major bugs.)
  18. Reboot to USB linux succeeds.
  19. EC test: fan spins.
  20. EC test: holding power for >5 seconds forces a power down.
  21. ACPI test: lid switch works.
  22. ACPI test: power button event received ok.
  23. ACPI test: AC power on/off event received ok.
  24. ACPI+EC+battery test: battery percentage works.
  25. Media keys on keyboard work in linux.
  26. Device tests: internal mic, internal speakers, webcam, webcam mic, wifi, bluetooth, hard drive, SSD, SD card, each USB port, headphone jack.
  27. prime95 (one instance bound to each hyperthread) for a fixed time to test CPU thermal management.
  28. glxgears for a fixed time to test GPU thermal management.
  29. During prime95 test, CPU digital thermal sensor should give reasonable results.
  30. Linux suspend ok.
  31. LCD backlight adjustable in linux.
  32. Linux kernel boot messages should not contain too many errors.

The effort to write Free Software implementations for all binary blobs will continue in parallel.

Secondary items would include further tweaks to PCI IRQ routing, additional ACPI tables, and optimizing battery life/power use.

2015-08-14 Librem 13: Weekly Progress Update

A question coreboot developers are commonly asked is this: “can you port coreboot to my board?”

For my first coreboot post I’d like to show some of the steps required to port coreboot to the Librem 13. In particular, this post is a good example of some of the challenges involved in such a port.

This post is also the first weekly progress update for the Librem 13. Please email me with questions or comments: larry.moberg@puri.sm.

LPC Bus

The Librem 13 has convenient test points for the LPC bus. This allows a bed-of-nails test setup to quickly diagnose problems during manufacturing. But it has the added bonus of facilitating coreboot development.

The earliest coreboot stages are the most important to get right. Debugging using port 0x80 writes on the Librem 13 is possible because port 0x80 writes are configured as LPC writes, which can be traced by connecting to the LPC pins.

And…It’s Gone

BIOS development is hard. I applied a little too much force on the SPI flash chip and tore the solder pads off the board.

Pads...gone

I attached the LPC connection to a test setup and didn’t check using a multimeter before applying power. LAD2 was shorted to LAD3. This immediately bricked the laptop without even releasing any smoke. Remembering to double check for shorts is a tedious but important lesson.
Don't Cross The Streams

The LPC bus wires go under the board. Don’t Cross The Streams!

Why It Matters

Imagine a laptop where the LPC bus is only available by soldering directly to the pins of the EC. Yes, they exist! That level of fine soldering is a significant barrier for future coreboot hackers. (The Librem 13’s external USB ports are all USB 3, which makes an EHCI debug port harder, but the LPC bus is a good substitute.)

Porting coreboot to a new laptop takes a lot of time and work. Even a good laptop design like the Librem 13 where the LPC pads are available still has a non-trivial level of engineering work to get to a Free Software BIOS.

Next week, I’ll document the engineering considerations around writing to the SPI flash chip, and how that affects coreboot development.

Flashrom 0.9.4 released – Flashing BIOS/ROM chips from the Unix/Linux command line using various programmers

flashrom logo

Forgot to mention this here: We released flashrom 0.9.4 a few days ago, the latest release of the open-source, GPL'd ROM chip flashing software for Linux, *BSD, DOS, and partially also Windows (work in progress, though).

Here's a quick summary of the release announcement. Some of the noteworthy news items include:

  • Support for new programmers: OpenMoko Neo1973/Neo FreeRunner debug board version 2 or 3, Olimex ARM-USB-TINY, ARM-USB-TINY-H, ARM-USB-OCD, and ARM-USB-OCD-H, Open Graphics Project development card (OGD1), Angelbird Wings PCIe SSD/88SX7042, ITE IT85xx embedded controllers, Intel NICs with parallel flash.
  • Dozens of added flash chips, chipsets, mainboards.
  • Improved Dediprog SF100 support.
  • Add support for more than one Super I/O or EC per machine.
  • Always read the flash chip before writing, for improved error checking and faster programming.
  • Enable write support on NVIDIA MCP6x/MCP7x.
  • Lots of bugfixes, documentation fixes, internal improvements, etc.

Get the latest release tarball, or download and build the most recent version via Subversion:

  $ svn co svn://flashrom.org/flashrom/trunk flashrom
  $ cd flashrom
  $ make

I already updated the Debian package to 0.9.4 (it has also already migrated to Debian testing and Ubuntu), other people have updated Fedora, Gentoo, NetBSD etc. etc.

There's already a huge amount of patches queued for the next release, including support for even more programmers, PowerPC support (tested on Mac Mini and others), and of course the usual "more boards, more chips" items...

u-boot as coreboot payload

U-boot is bootloader on ARMs, PowerPCs and other platforms, it has a nice set of commands and in general it feels like a small operating system. I’m not certainly sure if it is good direction, please feel free to compare with UEFI 😉 but I simply miss it on x86. I work at SYSGO with u-boot in daily basis and even port it to different boards/platforms. The x86 is no easy to init and I think this is the reason why there is only one x86 board in whole u-boot tree. This board is called eNET and it has a AMD ELAN SC520 SOC. But luckily, with coreboot we can init much more x86 boards and this leads to natural conclusion to have the u-boot as the coreboot payload. I would like to share with you part of this “fantastic” hacking journey to make it happen. Continue reading u-boot as coreboot payload

openbiosprog-spi, a DIY Open Hardware and Free Software USB-based SPI BIOS chip flasher using flashrom

openbiosprog-spi device

If you're following me on identi.ca you probably already know that I've been designing a small PCB for a USB-based SPI chip programmer named openbiosprog-spi.

The main use-case of the device is to help you recover easily from a failed BIOS upgrade (either due to using an incorrect BIOS image, due to power outages during the flashing progress, or whatever). The device only supports SPI chips, as used in recent mainboards (in DIP-8 form factor, or via manual wiring possibly also soldered-in SO-8 variants). It can identify, read, erase, or write the chips.

Of course the whole "toolchain" of software tools I used for creating the hardware is open-source, and the hardware itself (schematics and PCB layouts) are freely released under a Creative Commons license (i.e., it's an "Open Hardware" device). The user-space source code is part of flashrom (GPL, version 2), the schematics and PCB layouts are licensed under the CC-BY-SA 3.0 license and were created using the open-source Kicad EDA suite (GPL, version 2).

openbiosprog-spi schematics
openbiosprog-spi Kicad PCB layout

The schematics, PCB layouts, and other material is available from gitorious:

  $ git clone git://gitorious.org/openbiosprog/openbiosprog-spi.git

You can also download the final Gerber files (ZIP) for viewing them, or sending them to a PCB manufacturer.

Some more design notes:

  • The device uses the FTDI FT2232H chip as basis for USB as well as for handling the actual SPI protocol in hardware (MPSSE engine of the FT2232H).
  • Attaching the SPI chip:
    • There's a DIP-8 socket on the device so you can easily insert the SPI chip you want to read/erase/program.
    • Optionally, if you don't want a DIP-8 socket, you can solder in a pin-header with 8 pins, which allows you to connect the individual pins to the SPI chip via jumper wires or grippers/probes.
  • The PCB board dimensions are 44mm x 20mm, and it's a 2-layer board using mostly 0603 SMD components.

Basic usage example of the device on Linux (or other OSes supported by flashrom):

  $ flashrom -p ft2232_spi:type=2232H,port=A -r backup.bin (reads the current chip contents into a file)

openbiosprog-spi PCBs
openbiosprog-spi parts list

Over at the main projects page of openbiosprog-spi at

  http://randomprojects.org/wiki/Openbiosprog-spi

I have put up a lot more photos and information such as the bill of materials, the Kicad settings I used for creating the PCBs, the Gerber files and the Excellon drill files and so on.

The first few prototype boards I ordered at PCB-POOL.COM (but you can use any other PCB manufacturer of course), the bill of materials (BOM) lists the Mouser and CSD electronics part numbers and prices, but you can also buy the stuff elsewhere, of course (Digikey, Farnell, whatever).

I already hand-soldered one or two prototypes and tested the device. Both hardware and software worked fine basically, you just need a small one-liner patch to fix an issue in flashrom, but that should be merged upstream soonish.

In order to make it easy for interested users to get the PCBs I'll probably make them available in the BatchPCB Market Place soonish, so you can easily order them from there (you do still need to solder the components though). Note: I'm not making any money off of this, this is a pure hobby project.

All in all I have to say that this was a really fun little project, and a useful one too. This was my first hardware project using Kicad (I used gEDA/PCB, also an open-source EDA toolsuite, for another small project) and I must say it worked very nicely. I didn't even have to read any manual really, it was all pretty intuitive. Please consider not using Eagle (or other closed-source PCB software) for your next Open Hardware project, there are at least two viable open-source options (Kicad, gEDA/PCB) which both work just fine.

coreboot porting to jetway PA78VM5 have been 95% successful.

i am  glad to say that the Jetway PA78VM5 mainboard can run coreboot sucessfully. The configuration of Jetway PA78VM5 can be found at PA78VM5.the coreboot+filo can work fine. The kernel began booting, but the only problem is after kernel shows”jumping to **” the serial port stoped showing anything. And i have already set the kernel parameter with “console=ttyS0,115200”

First of all thank olsen provide me this mainboard.

The mainboard have an SPI flash W25X80A, my SF100+testchip SO08 can detect the flash type, but can not erase the flash correctly. After contacted with dediprog engineer. i remove the flash from the board, it seems fine, the programming is fine, but i can not use it with the mainboard unless i can bear removing the flash chip every time i need to rebuild the coreboot. After that, i replace that flash chip with an sst 080b. it worked pretty fine. 🙂

another problem is while the coreboot booting, it stoped while corebooting trying to extract the cbfs files. i debugged this for a long time, finally thanks to patrick, i take his advice remove the $(CBFS_COMPRESS_FLAG).it worked.

the latest problem is that amd famlily10 may have much problem with the current build version.

i should find out what difference between btdc and coreboot public version caused problems.

my next step may focus on this things merge the code, and find out why the kernel did not show the booting message.

i am so glad that coreboot can finally booting the Jetway PA78VM5

First successful Nvidia MCP6x/MCP7x SPI access

Since a few hours, my Nvidia MCP61/MCP65/MCP67/MCP73/MCP78S/MCP79 SPI driver is tested and it works well. Only probing for a flash chip was tested, but still… this means my SPI bitbanging code is correct, and Michael Karcher’s reverse engineered docs are correct, and my implementation of the Nvidia GPIO interface used for bitbanging SPI is correct as well.

This is big news because with this patch flashrom finally has 100% support for all x86 chipsets we saw in the last ten years.

Huge thanks go to Michael Karcher for reverse engineering the interface and writing up cleanroom documentation which I could use for implementing the interface.
Huge thanks to Johannes Sjolund for testing my patch on his hardware although it was completely untested before.

Get the patch here: http://patchwork.coreboot.org/patch/1520/ (click on the “patch” link on that page to get a download).
Continue reading First successful Nvidia MCP6x/MCP7x SPI access

flashrom 0.9.2 released — Open-Source, crossplatform BIOS / EEPROM / flash chip programmer

The long-pending 0.9.2 version of the open-source, cross-platform, commandline flashrom utility has been released.

From the announce:

New major user-visible features:
* Dozens of newly supported mainboards, chipsets and flash chips.
* Support for Dr. Kaiser PC-Waechter PCI devices (FPGA variant).
* Support for flashing SPI chips with the Bus Pirate.
* Support for the Dediprog SF100 external programmer.
* Selective blockwise erase for all flash chips.
* Automatic chip unlocking.
* Support for each programmer can be selected at compile time.
* Generic detection for unknown flash chips.
* Common mainboard features are now detected automatically.
* Mainboard matching via DMI strings.
* Laptop detection which triggers safety measures.
* Test flags for all part of flashrom operation.
* Windows support for USB-based and serial-based programmers.
* NetBSD support.
* DOS support.
* Slightly changed command line invocation. Please see the man page for details.

Experimental new features:
* Support for some NVIDIA graphics cards.
* Chip test pattern generation.
* Bit-banging SPI infrastructure.
* Nvidia MCP6*/MCP7* chipset detection.
* Support for Highpoint ATA/RAID controllers.

Infrastructural improvements and fixes:
* Lots of cleanups.
* Various bugfixes and workarounds for broken third-party software.
* Better error messages.
* Reliability fixes.
* Adjustable severity level for messages.
* Programmer-specific chip size limitation warnings.
* Multiple builtin frontends for flashrom are now possible.
* Increased strictness in board matching.
* Extensive selfchecks on startup to protect against miscompilation.
* Better timing precision for touchy flash chips.
* Do not rely on Linux kernel bugs for mapping memory.
* Improved documentation.
* Split frontend and backend functionality.
* Print runtime and build environment information.

The list of supported OSes and architectures is slowly getting longer, e.g. these have been tested: Linux, FreeBSD, NetBSD, DragonFly BSD, Nexenta, Solaris and Mac OS X. There's partial support for DOS (no USB/serial flashers) and Windows (no PCI flashers). Initial (partial) PowerPC and MIPS support has been merged, ARM support and other upcoming.

Also, the list of external (non-mainboard) programmers increases, e.g. there is support for NICs (3COM, Realtek, SMC, others upcoming), SATA/IDE cards from Silicon Image and Highpoint, some NVIDIA cards, and various USB- or parallelport- or serialport- programmers such as the Busirate, Dediprog SF100, FT2232-based SPI programmers and more.

More details at flashrom.org and in the list of supported chips, chipsets, baords, and programmers.

I uploaded an svn version slightly more recent than 0.9.2 to Debian unstable, which should reach Debian testing (and Ubuntu I guess) soonish.