13 KiB
Please use at least Libreboot 20241206 revision 3 or higher. This is because older revisions contained a bug, where the NVMe SSD would be replugged under Linux, randomly, leading to data loss.
This is fixed in 20241206 rev3 or higher, by disabling PCI-E hotplug on the NVMe SSD slot.
See: Libreboot 20241206 release
Build ROM image from source
The build target, when building from source, is thus:
./mk -b coreboot dell3050micro_vfsp_16mb
Mate Kukri's deguard utility disables the Intel Boot Guard on this
machine. Libreboot uses this by default, along with me_cleaner to provide
a neutered ME setup; unlike on other platforms, arbitrary code execution is also
possible inside the ME on this mainboard, giving it much higher potential for
software freedom in the future.
Issues
This machine basically works flawlessly, as of the Libreboot 20241206 release. All the initial bugs were fixed, e.g. PWM fan control works now. A very nice machine, and inexpensive, plus very easy to set up for the average user. The ideal Libreboot desktop.
Note that HDMI audio does work, but you have to select it in your audio
server e.g. pipewire. The pavucontrol utility in Linux (with pipewire) lets
you have a lot of control over audio I/O. Libreboot patches the board to add
a verb, so headphones should work.
Selection of audio devices and outputs is a bit idiosyncratic on this board. Just play with pavucontrol for your setup and it should work fine.
Installation
Insert binary files
If you're using a release ROM, please ensure that you've inserted extra firmware required refer to the guide for that. (failure to adhere to this advice will result in a bricked machine)
Libreboot's build system automatically downloads and processes these files if you build Libreboot from source, but the same logic that it uses must be re-run if you're using a release image.
Of particular interest, this board uses the deguard software, to disable Intel Boot Guard. This means also that the ME firmware no longer has functional cryptographic signature checking for most of it; you can theoretically run whatever you want on the ME coprocessor.
Libre ME doesn't exist yet, but it's now possible. Example use-case for a libre ME could include, for example, running an out-of-bound packet filter on a secure network (with flash write protection, making it invincible to any OS-based software attacks).
MAC address
This has a realtek NIC inside, instead of Intel, so the MAC address will not change. This means: there is no GbE region in the flash.
You can still use something like GNU MAC Changer to change your MAC address from Linux if you want to.
This is great, because that's one less complexity to deal with during installation.
Flash a ROM image (software)
If you're already running Libreboot, and you don't have flash protection turned on, internal flashing is possible.
If you have factory firmware (Dell), you can short the service jumper. It's
near the RAM, under where the HDD goes (click the photos shown above).
Just put a short on it when booting,
and all flash protection is disabled; the factory firmware write might EFI
variables to flash during shutdown sequence, so you should pull the plug to
shut it down (remove the power by pulling the plug) after flashprog
says VERIFIED.
Flash a ROM image (hardware)
For general information, please refer to 25xx NOR flash instructions - that page refers to use of socketed flash.
The side cover comes off easily, and you can find the flash ICs next to the RAM. Simply remove the screw at the back. The top panel then slides forward, and you can remove the SSD caddy; from then on, the flash is accossible.
Observe the following photo of the flash (SOIC-8):
You can otherwise flash internally, including from factory firmware(if the service jumper is set).
Errata
Power-on after power failure
Older Libreboot revisions made this machine always turn on, when plugging in a power supply (charger brick), if a previous power loss was observed. This is because coreboot sets a special register in the PMC that configures such behaviour, but it was hardcoded to always-on. This is undesirable for most people, so Libreboot 20241206 revision 8 and newer releases contain the following modification:
https://browse.libreboot.org/lbmk.git/commit/?id=09a01477df67e3ddc36e11123c537332d7813c50
If you wish to modify this behaviour again, you could modify the patch
referenced there; the actual location of the .patch file may change over
time, so you can basically just modify the coreboot source file
at src/soc/intel/common/block/pmc/pmclib.c (for the coreboot tree
under src/coreboot/ in lbmk, pertaining to your board, which can be determined
by reading the tree variable in your board's target.cfg file within lbmk).
Use the patch as reference, to modify the coreboot behaviour as you wish, and re-compile from source.
TPM disabled
The TPM is disabled on this device, to prevent hanging/boot delay in SeaBIOS, due to buggy TPM drivers there.
Legacy 8254 timer
Legacy 8254 timer enabled in coreboot, to prevent SeaBIOS from hanging.
HyperThreading on 3050 Micro
Also called SMT. This is a feature where you get 2 threads on a single core. It can improve performance in some workloads, but is actually a performance liability in others, depending on your OS kernel/scheduler and the actual workload.
It is a security liability, due to the Spectre/Meltdown attacks, so we recommend turning it off, at the very least from your running operating system. On this platform, you can easily turn it off from coreboot.
Libreboot disables HyperThreading by default, from Libreboot 20241206 rev8 onward, on this board. To turn it back on, please build from source and before running the build command, do this:
./mk -m coreboot t480_vfsp_16mb # replace t480 with t480s if needed
In the menu that appears, go Chipset -> Enable Hyperthreading and turn it on. Then exit from the menu, saving the config where prompted. You will see this menu twice, because there are two configs for each of these boards.
SMT is rarely of benefit in practise, but can be useful in some circumstances. For example, if you're compiling a large codebase from source that takes hours, SMT increases the building speed by about 15 percent; for example, a 3 hour build job might take about 2 hours and 40 minutes instead.
Intel FSP copyright
Abstract
The initial Libreboot 20241206 release included Intel FSP directly inside the ROM images. Intel provides the FSP under a license which states (and I paraphrase): you must not modify it, but you can redistribute it freely, so long as the license notice is retained.
The FSP is a concatenation of three modules: FSP-T, FSP-S and FSP-M. T basically does CAR, S is essentially romstage components, and M is raminit. Due to how coreboot works, these components must be split into single components. Coreboot doesn't use T by default (it implements CAR itself), but has the option to use it. It will use M and S, only.
Technically, the process of splitting FSP into these three files counts as a modification. Furthermore, coreboot also rebases the M module by modifying certain pointers, so that it can integrate with coreboot to provide raminit.
Intel themselves own the copyright to the tool for splitting FSP,
at 3rdparty/fsp/Tools/SplitFspBin.py, and it seems that they do intend for
the FSP to be used this way. However, until now, those using the Intel FSP
have built coreboot images from source, so the issue of modified distributions
didn't come up.
By the strictest possible interpretation of Intel's licensing, Libreboot was technically in violation. To mitigate this, Libreboot 20241206 revision 8 and newer, will no longer include the Intel FSP inside images. Instead, the vendor inject script is used for inserting the FSP into release images, which is what we already do for several other components.
_fsp vs _vfsp targets
The original 20241206 release images had _fsp in the file name. From rev8
onward, _vfsp is specified instead.
Libreboot's inject script verifies checksums on files, when inserting into the images. Because of this, if we inject FSP after the fact, that means anyone using the old images will find errors when they try.
To mitigate this, the build targets containing _fsp in the name have been
retained, but these targets are set release="n" so that no ROM images are
provided in releases. The _vfsp images are provided pre-compiled, instead.
With this re-design, modern lbmk (from Libreboot 20241206 rev8 onward) can still
reliably inject Intel ME into the old _fsp images, if you already downloaded
those before.
Therefore, you must be especially careful to get this right. If you're running
the inject script into a tarball, it will generally detect the right one, but
inserting manually into individual image files is also possible; if you do this,
you must remember to correctly specify dell3050micro_vfsp_16mb,
or to specify the _fsp targets if you're doing this on older images.
It is extremely unlikely that Intel would have ever cracked down on Libreboot for its previous mistake, since many other projects exist that include FSP directly in coreboot images, even commercially. However, Libreboot wishes to respect Intel's license, in the most technically correct way possible.