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>

nitrocaster boards are hard to find nowadays and i'm not
comfortable supporting the knockoff chinese gear; quality
varies greatly, and i can't know how reliable they are.

nitrocaster has been out of business so it's just not
viable to support this mod anymore. in fact, keeping the
eDP-based targets is a liability to libreboot.

regular x220/x230 (non-eDP-modded) are retained. the eDP
modkit from nitrocaster let you use eDP screens instead
of lvds, on thinkpad x220 and x230, letting you use
higher resolution screens.

older lbmk revs can still be used, if you happen to come
across one of these boards. i only recommend using the
official nitrocaster board, if youcan find one unused.

ymmv with the chinese gear. better just use an unmodded
x230 or get a different machine.

Signed-off-by: Leah Rowe <leah@libreboot.org>

Signed-off-by: Leah Rowe <leah@libreboot.org>