Libreboot task list

Important tasks for the libreboot project

Board ports

• Current candidates (new boards) for libreboot:
  • Libreboot has so far been biased towards Intel. This needs to end (the sooner, the better). A nice start:
    • HIGH^2 PRIORITY! Lenovo G505S (works without CPU microcode updates). Video BIOS is an issue (unfinished replacement: openatom), as is the SMU firmware (ruik will know more). Other non-essential blobs may also still be present (but possible to remove). http://projects.mtjm.eu/work_packages/44 - It's AMD, so no ME either!
      • funfunctor (afaik) in the coreboot IRC channel is the person who ported this laptop, he might be able to help
      • mrnuke in the coreboot IRC channel is the person responsible for openatom
      • Add this board to the LTS Candidates page on the coreboot wiki
    • HIGH PRIORITY! ASUS KFSN4-DRE - fam10h, already in coreboot, seems to have native graphics initialization already, CPUs probably work without microcode updates, looks like this can already run blob-free. NOTE: PLCC flash chip (see vultureprog. BBB might be possible, it has GPIO pins etc) - external flashing not required. Flashing internally from stock firmware works. Recommendation: boot with proprietary firmware, dump it, hot-swap the chip and copy the dump to the new chip. Do this a few times. Now you have a backup. Then flash coreboot/libreboot. No external programmer needed (not even for brick recovery, since you backed it up onto spare flash chips).
    • HIGH PRIORITY! ASUS KGPE-D16 - ported by Raptor Engineering Inc. (USA). They use it internally, but have not yet released the code. According to tpearson in #coreboot this will run completely blob-free with full functionality. They are asking for $35,000 (USD) to pay for the work to upstream it (get it into coreboot master repository). Crowd funding will be necessary! See this thread on the coreboot mailing list. - note: external flashing required for initial install (internal flashing works with coreboot/libreboot running). It uses a DIP-8 (socket) SPI flash chip, so it's easy to flash.
    • HIGH PRIORITY! F2A85-M and E350M1 (libreboot_*_headless.rom). Test openatom (video BIOS replacement). SMU firmware is a problem. XHCI firmware is a problem.
    • HP Pavillion 1035DX (same chipset as G505S. See notes above)
    • BioStar AM1ML - just recently ported to coreboot. blob situation unknown.
    • Thinkpad E135 and Thinkpad E145 - port to coreboot. Apparently, the CPU used is based on the E350 (zacate) CPU used is the ASrock E350M1 which is in coreboot, and already a libreboot candidate. Blob situation is unknown, though it will probably rely on AGESA if ported and will probably need SMU firmware or Video BIOS (which must be replaced). It is unknown what other blobs may exist when ported, and whether or not this system will work reliably without the CPU microcode updates.
      • Difficulty: unknown
    • TODO: Add ARM candidates here (the above systems are all AMD).
    • This list needs to expand!
  • That doesn't mean Intel is off the table just yet:
    • HIGH PRIORITY! ThinkPad R500: http://projects.mtjm.eu/work_packages/43
    • HIGH PRIORITY! ThinkPad W500: they all use switchable graphics (ATI+Intel), the native init code in coreboot (for Intel) needs to disable the ATI chip and use Intel (this isn't done yet) - NOTE: This uses the PM45 chipset, but it might be compatible with the existing coreboot src for GM45.
      • Compaq Presario CQ60 - same comment
    • Non-lenovo GM45 laptops:
      • HIGH PRIORITY! Dell Latitude E6400 - quite a few of these online. This is a good laptop to target in coreboot and libreboot. NOTE: EC support. ALSO: DDR2 memory (coreboot raminit for GM45 currently only supports DDR3)
    • add roda rk9 support (contact nico to ask for more details about hw). This is GM45 but these machines do not have a descriptor (no ME), should be easy
      • This board lacks native graphics initialization (it should be easy to add in Kconfig files, but it has to be tested beforehand)
    • T400S and X301. These both seem to be GS45. X301 uses only the low-performance mode CPUs, so raminit is the main blocker there. They both probably use WSON-8 flash chips.
    • Add proper GS45 raminit for enabling all X200S and X200 Tablets to work properly. (maybe other machines) See hcl/x200.html#x200s_raminit
    • ThinkPad X201 - ME ignition is an issue. 30min reset watchdog for ME is an issue. Might be possible to disable watchdog in the flash descriptor (soft straps) - sgsit in the libreboot or coreboot IRC channel is interested in this.
    • T410S is supported but not yet merged. This uses the same chipset as the X201. http://review.coreboot.org/#/c/7975/ has the patch. This should be tested by someone and should ideally be merged in coreboot. pecg has one. help him.
    • This page contains a list of basically every thinkpad that would ever be a candidate for libreboot: http://psref.lenovo.com/WithdrawnBook - take a look at this PDF.

Platform-specific bugs

• HIGH PRIORITY! Fix these issues on GM45/GS45 targets:
  • X200: text-mode is broken. only framebuffer graphics work. Commit bde6d309dfafe58732ec46314a2d4c08974b62d4 in coreboot is what broke it. Investigate.
    • It might not be that commit; it's only an educated guess, based on running git log on src/northbridge/intel/gm45/gma.c - an actual git bisect has not yet been done.
  • Sound (internal speaker) worked on the T500, but stopped after all subsequent boots. (might just be this machine). investigate. (external speaker works)
  • tty0_ in #libreboot got tablet functions on X200T to work. Wait for it to land in gerrit (and master)? also test it first. For now, here is a paste: https://paste.debian.net/plainh/65cd0a55 - tty0_ wants to know whether it breaks the X200 (non-tablet version) or not. (It's probably fine)
  • On the X60, linux-libre 3.13.0-49 used from the Trisquel repositories, installed barebones (just TTY), the backlight would be on but screen would be blank at login. Connecting a VGA cable to an external monitor worked; also, the output on LVDS started working. Investigate. (does this happen on other distros, or on other kernel versions?)
• X200: when undocking, the beep persists and never stops. Beep beep beep. Fix it (EC-related. fix should be done in coreboot and added to libreboot afterwards) - might also affect T400/T500/R400/R500
  • On another X200, this did not occur. It might be that old versions of the EC have this bug
• Finish all work listed in future/index.html
• Fix these issues on i945 targets (X60/T60/macbook21)
  • HIGH PRIORITY! Fix remaining incompatible LCD panels in native graphics on T500. See hcl/t500.html.
  • HIGH PRIORITY! i945: Linux 3.19 doesn't boot. UPDATE: Patch to fix it is on linux bug tracker (see below), we are waiting for it to merge in linux upstream/mainline. For now, we are getting this patch into the GNU/Linux distros typically used with libreboot. (also affects T60/macbook21). Preliminary bug report (kernel, linux) pstuge said http://biosbits.org/ patricg says https://wiki.ubuntu.com/HardwareEnablementTeam/Documentation/FirmwareTestSuiteLive
    • It's commit aaecdf61 (drm/i915: Stop gathering error states for CS error interrupts) in linux that introduced the regression
    • This patch linked on the bug report page above: https://bugzilla.kernel.org/attachment.cgi?id=172941 - fixes the problem, and makes the i945 laptops boot up again.
      • Parabola has temporarily merged it in a kernel update - when it's merged upstream, let Emulatorman know (#parabola on IRC freenode)
      • So has Guix - when it's merged upstream, let mark_weaver know (#guix on IRC freenode)
      • So has freesh (for Trisquel) - when it's merged upstream, let jxself and lxo know (#linux-libre on IRC freeode)
    • Since 3.19, there are still some warning messages now, after applying the patch. See Mono's comments on the bug report page - https://bugzilla.kernel.org/show_bug.cgi?id=93171#c27
      • https://bugzilla.kernel.org/show_bug.cgi?id=93171#c29 https://bugzilla.kernel.org/show_bug.cgi?id=93171#c30 - it seems that these warnings have been fixed, and will soon land in upstream.
    • TODO: this fix in linux is a workaround, the real bug is in coreboot. (without the patch, 3.19/higher doesn't boot on coreboot/libreboot i945 with native graphics, but does boot on lenovobios with 3.19/higher - it probably also boots with coreboot+vgarom, since the bug is in the video init code.
  • i945: fix VRAM size (currently 8MB. should be 64MB). See future/index.html#i945_vram_size.
  • Fix remaining incompatible LCD panels in native graphics on T60. See future/index.html#lcd_i945_incompatibility.
  • i945: the intel video driver used to initialize the display without native graphics initialization and without the extracted video BIOS. It no longer does, so investigate why it does not, and fix the regression (fix has to be done in the kernel, Linux). See http://www.coreboot.org/pipermail/coreboot/2014-June/078104.html and http://www.coreboot.org/pipermail/coreboot/2014-June/078105.html
  • Add fake_vbt tables on i945 machines (also GM45).
  • Commit 26ca08caf81ad2dcc9c8246a743d82ffb464c767 in coreboot, see the while (1) loop that waits for the panel to power up on i945. This is an infinite loop if the panel doesn't power up. Fix it. Also, are there panels that don't power up? Test this, and fix it.

Flashing from lenovobios to libreboot (and vice versa)

• Implement everything outlined in hcl/gm45_remove_me.html#demefactory and test it.

Payloads

• Add ProteanOS payload to machines with big enough flash chips. (eg X200/R400). This page (outdated, but still useful according to the maintainer) has some info: http://www.proteanos.com/doc/plat/porting/. pehjota says that once the port is done, prokit can be modified to generate the entire distribution as a vmlinuz and initrd.img file.
• Related to MemTest86+:
  • Todo: modify memtest86+ to work with libpayload (coreboot framebuffer) and delete all the text-mode ROM images. See http://projects.mtjm.eu/work_packages/17

Build system

• PaulePanter reported in #coreboot that cbfstool currently fails to build on 32-bit x86 hosts. This patch is supposed to fix it: http://review.coreboot.org/#/c/9995/
• HIGH PRIORITY! All parts of libreboot that download non-intergrated parts (coreboot/grub/memtest/bucts/flashrom) rely on only a single repository link, which means single-point-of-failure. Make them fall back on alternative (backup) repositories if the main ones are down.
  • The coreboot one also cherry picks patches from review.coreboot.org (gerrit), but coreboot.org is sometimes down. When that happens, libreboot cannot be built from git. The solution is to directly include those patches that are used, as patch/diff files under resources/libreboot/patch/, instead of cherry picking from gerrit (but still include a commented-out link to the gerrit patch that the diff file came from)
• HIGH PRIORITY! When downloading coreboot/grub/memtest/etc using the download scripts, it currently does not check the integrity of these sources at all. Libreboot releases are signed, but what can be done to improve it is to check the sha512sums of all files downloaded by these scripts (which are in the git repository, but not the release archives, because the release archives already include these sources). Do this for all non-integrated modules used in libreboot.
• HIGH PRIORITY! Make memtest86+ build using coreboot's own crossgcc toolchain. Currently, memtest86+ doesn't even work at all when cross-compiled using the toolchain in x86-64 trisquel7
• HIGH PRIORITY GRUB does not display any text at all when using EHCI debug. Investigate.
  • It has to do with the dongle used. Use the default one in menuconfig, not BBB.
  • HIGH PRIORITY Confirm that the EHCI debug options enabled in coreboot menuconfig are correct for the current versions of the BBB (rev. C or higher). Search EHCI debug on install/bbb_setup.html
• Make libreboot (all of it!) build reproducibly. This is very important. See http://projects.mtjm.eu/work_packages/16.
• build/release/archives currently fails on Parabola (it only works well in Trisquel). That script is buggy, and full of ugly hacks anyway, so re-write it and make it modular/portable this time.
• Reduce the size of libreboot releases. See http://projects.mtjm.eu/work_packages/19
  • Proposal: unify ROM images (don't duplicate). See http://projects.mtjm.eu/work_packages/20.
• Make GRUB build using coreboot's own crossgcc toolchain
• Delete all parts of coreboot that libreboot doesn't use. For instance, delete boards that aren't used in libreboot. This will reduce the size of the source tarballs considerably.

Improvements to the utilities

• Stop deleting flash chip definitions in flashrom. Instead, modify flashrom to accept a list of known flash chips, provided by a text file or naming them on the argument (eg --flashchips "chip 1" "chip 2"), where flashrom would ignore any detected flash chips that are not on the list. Make the flashing scripts use it, by default.
• Make ich9gen/ich9deblob portable. They both rely extensively on bitfields, and they assume little-endian; for instance, mapping a little endian file directly to a struct, instead of serializing/deserializing. Re-factor both utilities and make them fully portable. See http://projects.mtjm.eu/work_packages/18
• Adapt linux-libre deblob scripts for use with coreboot. Libreboot is already deblobbed using its own script, but updating it is still a bit too manual. linux-libre's deblob scripts do an excellent job and (adapted) will make it much easier to maintain coreboot-libre.
• Add a whitelist entry to board_enable.c in flashrom, for the ThinkPad R400 and T400
• Improve the deblobbing scripts (see http://projects.mtjm.eu/work_packages/40)
  • .spd.hex files. These aren't blobs? Don't remove them? (in coreboot). See deblob script. Categorize blobs and non-blobs more clearly, explaining what they are for and why they are (or are not) blobs.

BeagleBone Black

• Get libre distros ported to it. Eg proteanos, trisquel, parabola, librecmc and so on.
• See BBB screwdriver - from the coreboot project, this is an openwrt-based image for the BBB that comes with EHCI enabled out of the box. Look into re-basing that on librecmc (librecmc is a deblobbed version of openwrt).

Documentation improvements

• HIGH PRIORITY! Add information from hw registers on all boards. See http://projects.mtjm.eu/work_packages/15
  • We currently have them for X200 (4MiB flash chip), T400 but not complete
  • Get them for more boards:
    • X60
    • T60
    • macbook21
    • X200 (make sure to have it for both flash chip sizes)
    • R400 (make sure to have it for both flash chip sizes)
    • T400 (make sure to have it for both flash chip sizes)
    • T500 (make sure to have it for both flash chip sizes)
• Apparently, leaving HOLD and WP pins floating (unconnected) isn't a good idea. Information online says that this needs to be connected along with 3.3V - look into this. (it is specific to each flash chip, so read the datasheets).
  • eg http://flashrom.org/FT2232SPI_Programmer - " The WP# and HOLD# pins should be tied to VCC! If you leave them unconnected you'll likely experience strange issues."
  • <pehjota> stefanct: We've never had any "strange issues" with leaving WP# and HOLD# unconnected on the Macronix and Atmel SOIC-8 and SOIC-16 flash chips on the X200. IIRC, the datasheets don't say how those pins are wired internally or whether they can be left unconnected. But I tested their voltages while flashing, and they float high on their own, so they seem to support it fine.
  • <pehjota> fchmmr: You would connect the WP# and HOLD# pins to 3.3 V (on an ATX PSU you'd hook up more cables to the other orange pins, with your PSU I guess you'd wrap more wires around the 3.3-V screw), just like you do VCC. But as I said above, it doesn't seem to be necessary (WP# and HOLD# seem to be held high already).
    <pehjota> I got a solid ~3.3 V (i.e. pulled high, not floating between high and low) from WP# and HOLD# with just VCC, GND, MOSI, MISO, CS#, and SCLK connected. Plus, we haven't had any write protection issues as I'd expect from floating WP# and HOLD#, AFAIK.
    <pehjota> fchmmr: These pins do nothing if they're held high. The "#" (not) means they cause different behavior when held low.
  • <stefanct> fchmmr: pehjota: it may not be a problem if the chip is soldered to the x200, but it surely is when it isnt.
  • <stefanct> yes... <stefanct> a small note noting that would be appreciated because there are enough people out there already that ignore those pins and get stuck >pehjota> stefanct: You mean a note in the libreboot documentation explaining why we don't have to connect HOLD# and WP# to anything and how they would have to be tied to VCC on a chip not soldered to a board? <Kamilion> How about a more useful note that explains the whole discussion you two had succinctly? <Kamilion> Not everyone is going to be an EE to know about the # indicating the pin should be pulled low to be active. <Kamilion> reminds me, I need to pull out my pomona and try to fix some intel NIC roms <stefanct> pehjota: yes
• Adapt the notes at install/bbb_setup.html#stability into a full guide.
• There are no instructions for how to use the GRUB terminal to find a grub.cfg manually, or how to boot an installed GNU/Linux manually, so some users get stuck after the initial installation of libreboot not knowing how to boot the GNU/Linux system that they had before installing. Fix that. (also, promote the FSF-endorsed distros while you do it)
• Add guides for GM45 laptops in docs/security/
• Add guides for GM45 laptops in docs/hardware/
• Convert documentation to Sphinx/ReST See http://projects.mtjm.eu/work_packages/5 and http://projects.mtjm.eu/work_packages/12
• Maintainence manual. How to contribute to libreboot. See http://projects.mtjm.eu/work_packages/11
  • Work has begun. maintain/index.html
• Add cubieboard SPI flashing instructions to libreboot. mrnuke's github page with patches. mrnuke in IRC knows about the cubieboard
• LUKS key in initramfs: Add Trisquel documentation for docs/gnulinux/encrypted_trisquel.html. See http://projects.mtjm.eu/work_packages/39
• image, image, image - work with mrnuke on getting info about vultureprog PLCC flashing into libreboot. Libreboot needs server boards. https://github.com/mrnuke/vultureprog, https://github.com/mrnuke/qiprog, https://github.com/mrnuke/vultureprog-hardware. He also uses the sigrok logic analyzer (free/libre): http://www.dx.com/p/logic-analyzer-w-dupont-lines-and-usb-cable-for-scm-black-148945

Project (institutional) improvements

• HIGH PRIORITY! Add proper guidelines for contributions, like Development Guidelines on the coreboot wiki. For instance, require Sign-off-by in all commits for libreboot. Consulting with the FSF about this (licensing@fsf.org).
• HIGH PRIORITY! Libreboot needs to be factory firmware, not the replacement. It needs to be *the* firmware. Consult with the openlunchbox project (and maybe others) on getting hardware manufactured with libreboot support (out of the box, from the factory).
• Look into the possibility of expanding libreboot to support non-coreboot systems. (u-boot, for instance). Currently, libreboot presents itself as a deblobbed coreboot distribution. There are other systems out there that use other firmware, such as u-boot, which libreboot could theoretically support. This would mean that the build scripts know how to build things other than just coreboot/grub.
  • Allwinner A10 (ARM) SoCs
  • PMON?
  • barebox (u-boot derivative)
  • etc
  • http://zedboard.org/product/zedboard might be a candidate, according to the main developer of openlunchbox.
• Set up a routine (project-wise) for testing each machine with the latest kernel version. See http://projects.mtjm.eu/work_packages/22 and http://projects.mtjm.eu/work_packages/21

EC firmware

http://www.coreboot.org/Embedded_controller Replace this on all libreboot targets. Some laptops use an extra SPI flash chip for the EC, some have EC in the main chip, some don't use SPI flash at all but have the firmware inside the EC chip itself. If the EC has integrated flash then you need to be able to get to the pins on the chip or be able to program them over LPC or SPI (if they have that feature). The lenovo laptops currently supported in libreboot all use H8 EC chips (contains flash inside the chip). Read the datasheets on how to externally programme the EC. Chromebooks seem to have free EC (https://chromium.googlesource.com/chromiumos/platform/ec/+/master/chip/).