I currently check the downloaded files e.g. .exe file, but then I don't check - or even define - sha512sums for the files extracted from them e.g. me.bin This patch fixes that. It also caches the hashed files, so that extraction is faster on a re-run - this makes release builds go faster, when running ./mk release If a checksum is not defined, i.e. blank, then a warning is given, telling you to check a specific directory. This way, when adding new vendor files, you can add it first without specifying the checksum, e.g. me.bin checksum. Then you can manually inspect the files that were extracted, and define it, then test again. In a given pkg.cfg for config/vendor, the following variables are now available for use: FSPM_bin_hash for fsp m module FSPS_bin_hash for fsp s module EC_FW1_hash for KBC1126 EC firmware (1st file) EC_FW2_hash for KBC1126 EC firmware (2nd file) ME_bin_hash for me.bin MRC_bin_hash for mrc.bin (broadwell boards) REF_bin_hash for refcode (broadwell boards) SCH5545EC_bin_hash for sch5545 firmware (Dell Precision T1650) TBFW_bin_hash for Lenovo ThunderBolt firmware (e.g. T480/T480s) E6400_VGA_bin_hash for Dell E6400 Nvidia VGA ROM In practise, most people use release archives, and the inject script, so I knew those were reliable, because the ROM images were hashed prior to removing files. This patch benefits people using lbmk.git directly, without using release files, because now they know they have a valid file e.g. me.bin Previously, only the download was checked, not the extracted files, which meant that the only thing preventing a brick was the code not being buggy. Any number of bugs could pop up in the future, so this new level of integrity will protect against such a scenario, and provide early warning prompting bug fixes. Signed-off-by: Leah Rowe <leah@libreboot.org>
We used cbfstool from coreboot 4.13, because it was the last version to work with the particular format used for stage files, before the CBFS standard changed in newer releases of cbfstool. When I added this board to Libreboot, it was source-only at first so it didn't matter. I didn't want to do a standalone cbfstool binary, in case some people decided to use that one on newer boards, which would cause all sorts of issues. So I bodged it and just included an import of coreboot 4.13. Well, the cbfstool from coreboot 4.11, as used for FAM15H AMD boards, is compatible. I checked the code diff between the two, and there is no meaningful difference. I've tested this, and it works, since the last release or two now includes 820 G2 images, so I was able to use those with ./mk inject, to verify whether the refcode file is still grabbed properly. We need the refcode to handle MRC on Broadwell platform, but we extract it from an old Google Chromebook image, that uses the old CBFS stage file layout. This change solves my problem: the problem was that releases are bloated further, due to including this extra coreboot version. This should reduce the size of the next release considerably, especially after decompressing the tarball. Signed-off-by: Leah Rowe <leah@libreboot.org>
This is similar to the 9020SFF, but this board has ECC support. However, the native raminit isn't used here, even though it is otherwise compatible, because the native init doesn't do ECC yet. The broadwell mrc.bin has ECC support, which is also used on the HP EliteBook 820 G2. The MRC for broadwell can be used on haswell boards such as the T1700. Add both the SFF and MT variants. Since these are identical to the 9020 variants, except for slightly different PCH enabling ECC, we can just re-use the 9020 port without issue. We *could* add a variant to coreboot, for T1700, but there is not really any pressing need. It is simply the 9020sff/mt with mrc.bin Signed-off-by: Leah Rowe <leah@libreboot.org>
Signed-off-by: Leah Rowe <leah@libreboot.org>
The Libreboot 20241206 release provided FSP pre-assembled and inserted into the ROM images; the only file inserted by vendor.sh was the Intel ME. Direct distribution of an unmodified FSP image is permitted by Intel, provided that the license notice is given among other requirements. Due to how coreboot works, it must split up the FSP into subcomponents, and adjust certain pointers within the -M component (for raminit). Such build-time modifications are perfectly fine in a coreboot context, where it is expected that you are building from source. The end result is simply what you use. In a distribution such as Libreboot, where we provide pre-built images, this becomes problematic. It's a technicality of the license, and it seems that Intel themselves probably intended for Libreboot to use the FSP this way anyway, since it is they who seem to be the author of SplitFspBin.py, which is the utility that coreboot uses for splitting up the FSP image. Due to the technicality of the licensing, the FSP shall now be scrubbed from releases, and re-inserted. Coreboot was inserting the -S component with LZ4 compression, which is bad news for ./mk inject beacuse the act of compression is currently not reproducible. Therefore, coreboot has been modified not to compress this section, and the inject command doesn't compress it either. This means that the S file is using about 180KB in flash, instead of about 140KB. This is totally OK. The _fsp targets are retained, but set to release=n, because these targets *still* don't scrub fsp.bin; if released, they would include fsp files, so they've been set to release=n. These can be used on older Libreboot release archives, for compatibility. The new ROM images released for the affected machines are: t480_vfsp_16mb t480s_vfsp_16mb dell3050micro_vfsp_16mb Note the use of _vfsp instead of _fsp. These images are released, unlike _fsp, and they lack fspm/fsps in the image. FSP S/M must be inserted using ./mk inject. This has been tested and confirmed to boot just fine. The 20241206 images will be re-compiled and re-uploaded with this and other recent changes, to make Libreboot 20241206 rev8. Signed-off-by: Leah Rowe <leah@libreboot.org>
we encountered 1MB flash so far, but we may encounter other sizes on other machines when added to libreboot later on Signed-off-by: Leah Rowe <leah@libreboot.org>
Though not used in coreboot builds, and not injected into the builds in any way, these files are now created seperately when handling T480/T480s vendor files: vendorfiles/t480/tb.bin vendorfiles/t480s/tb.bin These are created by extracting Lenovo's ThunderBolt firmware from update files. The updated firmware fixes a bug; older firmware enabled debug commands that wrote logs to the TB controller's own flash IC, and it'd get full up with logs, bricking the controller. If you've already been screwed by this, you must flash externally, using a padded firmware from Lenovo's updates. Lenovo's own updater requires creating a boot CD or booting Windows. This patch in lbmk auto-downloads just the firmware, and you can flash it externally. You could simply do this as a matter of course, when installing Libreboot. You are recommended to update the Lenovo UEFI/EC firmwares first, before installing Libreboot; please look at the Libreboot documentation to know exactly which versions. Then dump the ThunderBolt firmware first, to be sure, and then you can flash these files. Flashing these updates will prevent the bug described here: https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-t-series-laptops/thinkpad-t480-type-20l5-20l6/20l5/solutions/ht508988 You can download Lenovo's installers for various ThinkPad models there, including T480s/T480s. It is these downloads that this lbmk patch uses, to extract those files directly. Signed-off-by: Leah Rowe <leah@libreboot.org>
Libreboot's binary blob reduction policy is crystal clear: If a blob can be avoided, it must be avoided. The ThinkPad T480 was using Intel's VGA ROM for graphics initialisation very briefly, before Mate fixed libgfxinit. Since libgfxinit is fixed, the Intel VGA ROM is obsolete, so we should not be handling this at all. Similarly, the Nvidia ROM handling has been removed, because Mate is hard-disabling that in the coreboot code anyway, since the Nvidia dGPU didn't work when tested anyway. Even if it did, Libreboot's blob policy makes it clear that Intel graphics with native init from coreboot is to be the preferred option. Signed-off-by: Leah Rowe <leah@libreboot.org>
Added t480s delta to deguard, for MFS config. Updated coreboot/next to latest t480 patch set, which includes t480s. This porting was done by Mate Kukri. also includes experimental t480s support Also added a data.vbt file (not in the gerrit patch) for the T480s. I had to turn on 8254 legacy timer on t480s, otherwise SeaBIOS would hang. Same issue I saw on OptiPlex 3050 Micro. Minor issue: On S3 resume, nvme0n1 for example got renamed to nvme0n2. This caused a crash if running Linux from the nvme. I confirmed this via live USB distro. So this port will need some tweaking before it can be considered stable. Also uses libgfxinit, which Mate recently fixed. I'm going to enable libgfxinit on regular T480 next. Signed-off-by: Leah Rowe <leah@libreboot.org>
This uses the excellent deguard utility, written by the excellent Mate Kukri. A few bugs but it mostly works. Documentation to come shortly, in lbwww.git. Signed-off-by: Leah Rowe <leah@libreboot.org>