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). Videos BIOS is not yet fully replaced (openatom doesn't have a working framebuffer, yet, but it can draw a bitmap in user space, using a special utility) - openatom in github. SMU needs replacing (ruik/funfuctor/patrickg/mrnuke might be able to help).
  - HIGH PRIORITY! ASUS KFSN4-DRE - fam10h, already in coreboot, seems to have native graphics initialization already, fam10h, already in coreboot. Works without CPU microcode updates, has native graphics initialization (text-mode and framebuffer mode). PLCC flash chip, but can be read/flashed from factory firmware so just boot up, dump, hot-swap and flash the dump to make a backup, then check that the system boots with the backup. Then flash the original chip with libreboot. External PLCC flash programmer not needed!
  - HIGH PRIORITY! ASUS KGPE-D16 - code not yet public, ported by Raptor Engineering Inc. (USA). They are asking for 50K* USD to pay for the work to upstream the code (do code review, add more patches, get it merged in coreboot master repository - a lot of work!). Crowd funding will be necessary. Crowd funding will be necessary. See coreboot mailing list. This board uses DIP-8 (socket) SPI flash, so it's easy to flash (external flashing required for initial install). * was 35K. The extra 15K is a stretch goal for S3 support and full text-mode graphics initialization (bugs eliminated).
  - HIGH PRIORITY! F2A85-M and E350M1 (libreboot_*_headless.rom). Test openatom (video BIOS replacement). SMU firmware is a problem. XHCI firmware is a problem.
  - 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). Unknown if PM45 is compatible with GM45.
  - 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)

Platform-specific bugs

HIGH PRIORITY! Fix these issues on GM45/GS45 targets:
- X200: text-mode is broken. only framebuffer graphics work. Git-bisect is needed.
- X200/X60: battery drained even while system is "off" on some systems. investigate.
- Sound (internal speaker) broken on T500 (works in lenovobios). external speaker/headphones work. - probably a different hda_verb
- Test this patch for X200 Tablet digitizer support: https://paste.debian.net/plainh/65cd0a55 - tty0_ wants to know whether it breaks the X200 (non-tablet version) or not. (It's probably fine)
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.
- 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 systems (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 systems 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.

Build system

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
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.

Improvements to the utilities

Stop deleting flash chip definitions in flashrom. Instead, modify flashrom to ignore a list of chip definitions. This is a much cleaner solution. (add an option to override the ignore).
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

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. Get them for the following remaining boards: X60, T60, macbook21, R400

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

LUKS key in initramfs: Add Trisquel documentation for docs/gnulinux/encrypted_trisquel.html. See http://projects.mtjm.eu/work_packages/39

PLCC flashing guide is needed: 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).

PROPOSAL (only a proposal, for now): 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 system 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/).

Back to top of page.