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>
I'm adding ThinkPad T480 support next, which requires the new revision of deguard. Mate Kukri changed the way deguard is used, in a rewrite of the project, so lbmk has to change too. Signed-off-by: Leah Rowe <leah@libreboot.org>
Copy the downloaded deguard source code into appdir, and patch it to run as part of lbmk, instead of standalone. The archived one in src/ is not directly used; instead, the hotpatched version is used. This is because the standalone version already has download logic for the .zip file, but we already cache that file in cache/ and use that. Signed-off-by: Leah Rowe <leah@libreboot.org>
replace it with logic that simply uses "." to load files directly. for this, "vcfg" is added as a variable in coreboot target.cfg files, referring to a directory in config/vendor/ containing a file named pkg.cfg, and this file then contains the same variables as the erstwhile config/vendor/sources config/git files are now directories, also containing pkg.cfg files each with the same variables as before, such as repository link and commit hash this change results in a noticeable reduction in code complexity within the build system. unified reading of config files: new function setcfg() added to lib.sh setcfg checks if a config exists. if a 2nd argument is passed, it is used as a return value for eval, otherwise a string calling err is passed. setcfg output is passed through eval, to set strings based on config; eval must be used, so that the variables are set within the same scope, otherwise they'd be set within setcfg which could lead to some whacky results. there's still a bit more more to do, but this single change results in a substantial reduction in code complexity. Signed-off-by: Leah Rowe <leah@libreboot.org>
Command: ./vendor download kcma-d8-rdimm_16mb Output was: include/lib.sh: line 115: kcma-d8-rdimm=config/vendor: No such file or directory That will have to be audited later on, but the recent more stringent error checking in vendor.sh triggered this previously untriggered error message. The error was in fact already occuring before, silently. Anyway, mitigate by renaming all coreboot targets so that they do not contain hyphens in the name. This should avoid triggering errors in that eval command, on line 115 in lib.sh Signed-off-by: Leah Rowe <leah@libreboot.org>
broadwell mrc is retained, because it's needed on 820 g2 it's no longer needed on haswell, because nri is stable. nri is short for "native ram initialisation", and libreboot provides this for: thinkpad t440p, thinkpad w541, dell optiplex 9020 mt, and dell optiplex 9020 sff remove, in line with libreboot's binary blob reduction policy previous revisions, prior to the recent release, stated that it would be retained for compatibility, but it's really not right to retain it, because doing so violates libreboot's policy the recent release excluded mrc-based rom images for haswell machines, providing only those rom images that use the libre raminit, while retaining support for mrc in the build system, so that users could still run the lbmk inject script on older release roms that use mrc again: libreboot's binary blob reduction policy is very clear: https://libreboot.org/news/policy.html it is a policy that can be summarised, thus: if a blob can be avoided, it must be avoided. therefore, we will avoid the Haswell MRC raminit blob Signed-off-by: Leah Rowe <leah@libreboot.org>