parent
d75c3bb9dd
commit
81f5521bfd
|
|
@ -7,6 +7,10 @@ This page contains a curated list of tasks that are to be worked on, or tasks
|
|||
that are being worked on. This is intended to complement
|
||||
the [issue pages](https://codeberg.org/libreboot/lbmk/issues/).
|
||||
|
||||
Many of these entries will pertain to *lbmk*, which is Libreboot's build
|
||||
system, but some entries may relate to documentation, or organisational
|
||||
changes.
|
||||
|
||||
General auditing
|
||||
================
|
||||
|
||||
|
|
@ -58,7 +62,7 @@ Boards
|
|||
not much different code-wise to the D16 mainboard, so differences
|
||||
in coreboot `4.11_branch` could be adapted to provide a Dasharo port.
|
||||
|
||||
FSDG boards
|
||||
Blobless boards
|
||||
-----------
|
||||
|
||||
Not yet supported, but interesting for the project. Separated thus:
|
||||
|
|
@ -135,6 +139,38 @@ Ryzen-based chromebooks, and there is interest in adapting that code for
|
|||
Ryzen-based desktops. AMD Ryzen CPUs are quite powerful, currently among the
|
||||
best available at least on consumer-grade hardware.
|
||||
|
||||
AMD Family16 boards
|
||||
-------------------
|
||||
|
||||
See: <https://review.coreboot.org/c/coreboot/+/71607>
|
||||
|
||||
This is part of a patch series, from 9 September 2023 onward, re-adding
|
||||
AMD Family 16 platform to coreboot, most notably enabling use of the new
|
||||
allocator and other things in coreboot.
|
||||
|
||||
The linked patch is for mainboard: HP T620 - of note, it may also be suitable
|
||||
for Canoeboot. Worth looking into.
|
||||
|
||||
AMD AGESA-based platforms were removed from coreboot, because they weren't
|
||||
being maintained anymore, so they were dropped. Some of those boards are
|
||||
still quite decent today. Various efforts here and there have revived some
|
||||
of them, e.g. the Dasharo project.
|
||||
|
||||
Also referenced there: Biostar A68N-5200 mainboard. Check
|
||||
coreboot `4.18_branch` for these boards. Coreboot started removing the
|
||||
AGESA boards after release 4.11.
|
||||
|
||||
Lenovo G505s
|
||||
------------
|
||||
|
||||
Old board, removed from coreboot ages ago, but one of the fastest pre-PSP
|
||||
AMD laptops, has full init in coreboot - it does require a VGA ROM for
|
||||
graphics. Anyway:
|
||||
<http://dangerousprototypes.com/docs/Lenovo_G505S_hacking>
|
||||
|
||||
This page was linked to me ages ago by Mike Banon. It contains instructions
|
||||
for how to configure the machine. It might be worth integrating into lbmk.
|
||||
|
||||
UEFI payload
|
||||
============
|
||||
|
||||
|
|
@ -476,3 +512,159 @@ Layers!
|
|||
|
||||
Security is all about layers. When you want to lock down the flash, use every
|
||||
method available to you.
|
||||
|
||||
lbwww: Document MXM graphics
|
||||
============================
|
||||
|
||||
MXM graphics modules are present, on some laptops that we do not yet support,
|
||||
because certain functionality is needed on them that we do not implement yet.
|
||||
|
||||
See: <https://codeberg.org/libreboot/lbmk/issues/112>
|
||||
|
||||
Unlike on several other setups, many of these modules require certain data
|
||||
tables to be present, provided by a BIOS interrupt, which the VGA ROMs then
|
||||
use. These tables essentially contain config for things like ports, and power
|
||||
management. More information, including links to PDF files containing the
|
||||
specs for it, are provided for in the above linked issue page.
|
||||
|
||||
Several more high-end HP EliteBook machines use MXM graphics modules,
|
||||
e.g. HP EliteBook 8560w.
|
||||
|
||||
John lane GRUB patches
|
||||
======================
|
||||
|
||||
The GRUB project itself has started merging some of this functionality, for
|
||||
things like detached LUKS headers. We had these for GRUB in Libreboot 2016
|
||||
releases, but they were since removed.
|
||||
|
||||
Current functionality works on most setups, and we merge [Argon2
|
||||
KDF support](../news/argon2.md) into GRUB, out-of-tree.
|
||||
|
||||
See: <https://grub.johnlane.ie/>
|
||||
|
||||
Interesting, the Arch Linux AUR has several of these patches for its
|
||||
GRUB 2.06 package. See:
|
||||
<https://aur.archlinux.org/packages/grub-luks-keyfile>
|
||||
|
||||
These could be re-based for GRUB 2.12, which is what Libreboot uses.
|
||||
|
||||
Use crossgcc for SeaBIOS and GRUB
|
||||
=================================
|
||||
|
||||
We currently use hostcc for the SeaBIOS and GRUB payloads. This, among other
|
||||
things, means lbmk is currently only supported for amd64 machines.
|
||||
|
||||
See other notes on this page about Linuxboot. When that work is done, we will
|
||||
have better infrastructure for cross compilation, which could also be used for
|
||||
this purpose.
|
||||
|
||||
In particular, GRUB's build system requires you to build certain utilities
|
||||
first. We use `grub-mkstandalone` to then provide the coreboot payload. For
|
||||
GRUB specifically, we should therefore use musl-cross-make. SeaBIOS can be
|
||||
built using crossgcc.
|
||||
|
||||
Port lbmk to BSD systems
|
||||
========================
|
||||
|
||||
In particular, FreeBSD is of interest.
|
||||
|
||||
We probably don't need to natively port it, because FreeBSD has Linux ABI
|
||||
compatibility in its kernel, using *linuxlator*, and you can bootstrap a
|
||||
Debian system under it.
|
||||
|
||||
See: <https://docs.freebsd.org/en/books/handbook/linuxemu/>
|
||||
|
||||
See: <https://docs.freebsd.org/en/books/handbook/linuxemu/#linuxemu-debootstrap>
|
||||
|
||||
We may still need certain build system modifications anyway, but this would
|
||||
probably be mostly just documenting how to use lbmk that way.
|
||||
|
||||
FreeBSD specifically offers many advantages, such as really good OpenZfs
|
||||
integration (better than ZFS-On-Linux setups), which it can do natively because
|
||||
the licensing in BSD is compatible; Linux can't merge ZFS due to CDDL licensing.
|
||||
|
||||
An actual native port to FreeBSD is also feasible, and coreboot itself already
|
||||
has some support for that, as does GRUB. If using crossgcc to build all payloads,
|
||||
this could be even easier.
|
||||
|
||||
Building a Linux kernel might be slightly more challenging, but again: crossgcc.
|
||||
|
||||
Adapting musl-cross-make for use in FreeBSD could be interesting. Other notes
|
||||
on this TODO page talk about using musl-cross-make to provide static linked
|
||||
utilities in releases, but this has only Linux in mind. Doing them for
|
||||
FreeBSD may also be desirable.
|
||||
|
||||
Libreboot already has excellent support for booting all of the BSDs. Having the
|
||||
build system be compatible would just be another great boon.
|
||||
|
||||
Package lbmk in distros
|
||||
=======================
|
||||
|
||||
Providing binaries of Libreboot in distros wouldn't make sense, because we
|
||||
do that anyway, on Libreboot RSYNC, but having ports of the build system on
|
||||
various Linux distros and BSDs might be desirable.
|
||||
|
||||
Distro package managers could check when changes are made to a given board,
|
||||
and if the system you're on matches that given board, the package manager could
|
||||
provide you with an option to *flash* it.
|
||||
|
||||
This would probably only be provided on systems where that is extremely safe,
|
||||
specifically that those systems have been well-tested. Some ports in Libreboot
|
||||
are a bit flaky and would require extra work.
|
||||
|
||||
It's unlikely that this job will ever be done, but it's on the TODO page
|
||||
anyway. Distro package managers concern themselves with OS applications, kernel,
|
||||
libc, bootloaders and so on; Libreboot is a step below them, earlier on in
|
||||
the boot process.
|
||||
|
||||
But then again, there are things
|
||||
like [fwupd](https://github.com/fwupd/fwupd) that provide firmware updates in
|
||||
distros, so there's no reason Libreboot couldn't do something equivalent - we
|
||||
could even do binaries, though I'm mostly thinking of the Libreboot build
|
||||
system itself. A distro could package lbmk to build for a specific Libreboot
|
||||
version, and handle all of the dependencies and everything.
|
||||
|
||||
Vendor scripts
|
||||
==============
|
||||
|
||||
Bruteforce more files
|
||||
---------------------
|
||||
|
||||
We bruteforce extract IME but some other firmwares are more or less
|
||||
hardcoded in config.
|
||||
|
||||
In particular, VGA ROM extraction could be improved. We could modify
|
||||
the `romheaders` utility to return zero status or non-zero status based on
|
||||
a given PCI vendor/device ID; non-zero if it's not a match, for a given file,
|
||||
or it isn't a VGA ROM. We currently extract an nvidia ROM for certain models
|
||||
of Dell Latitude E6400, but the logic is more or less hardcoded.
|
||||
|
||||
The script at `script/vendor/download` auto-downloads vendor firmwares needed
|
||||
on certain mainboards, during build time. Libreboot's build system
|
||||
uses the script at `script/vendor/inject` to add or remove such files after
|
||||
the fact, on release ROMs, because those firmwares are *deleted* at release
|
||||
time. This work began mostly after mid-2022, and has since been expanded to
|
||||
cover many types of firmwares, used on various mainboards.
|
||||
|
||||
Investigate 16MB flash setups
|
||||
=============================
|
||||
|
||||
On some ivybridge and sandybridge boards, where flash is 8MB or 12MB,
|
||||
it is feasible (with some soldering) to upgrade it to 16MB setups.
|
||||
|
||||
The IFD is configured accordingly, but some board modification besides
|
||||
that may be required. For example, on the ThinkPad T440p, SPI2 is easily
|
||||
accessible but SPI1 requires full disassembly. One could re-wire the board,
|
||||
removing the Chip Select resistor for SPI1, and the SPI2 CS resistor, then
|
||||
re-wiring CS1 to CS2 via a resistor, so that only SPI2 is used (thanks go
|
||||
to Nicholas Chin for describing this idea) - then you stick one big 16MB flash
|
||||
on SPI2, which is easily flashable.
|
||||
|
||||
These upgrades are really only recommended for advanced users. We do already
|
||||
provide images for them; 16MB ROM images on many GM45 thinkpads, and also
|
||||
the ThinkPad X230.
|
||||
|
||||
A 16MB setup was attempted on the ThinkPad T440p, but didn't boot, and I now
|
||||
believe it was because I didn't insert the MRC firmware at the correct offset
|
||||
during that test. Libreboot's build system now handles that correctly, in
|
||||
the vendorfile inject script at `script/vendor/inject`.
|
||||
|
|
|
|||
Loading…
Reference in New Issue