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>

boring is good

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

libreboot has a lot of users worldwide, some of whom live in
countries that punish being gay; if they look at libreboot or
boot it and it has the pride colours on it, it could actually
get them in trouble.

this fact occured to me, and i've decided therefore to revert
back to the boring plain logo.

though, perhaps we could actually properly design a new logo?
a new, modern logo, and a nicer website.

we'll see!

This reverts commit 401efb24b2213454732e769531f660605771e538.

for some reason, when the background is in memdisk, inserting
it into cbfs afterward doesn't override, despite this
being the behaviour in grub.cfg

put it in cbfs explicitly, and skip inserting into memdisk

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

same as on u-boot recently

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

f/m are scripts i'm gradually working on. easy flash scripts
for lbmk. no promises when/if i push them.

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

see patch for rationale. this should prevent instability caused
when the nvme randomly replugs under linux. sometimes e.g. nvme0n1
becomes nvme0n2 while the system is running.

in my case, that caused my raid1 to become unsynced every few days.
this issue was fixed on t480 by disabling pcie hotplug for its nvme
device, so the same fix has been applied for dell optiplex 3050 micro.

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

this was done with the following command:

./mk -u coreboot t480s_fsp_16mb t480_fsp_16mb

it was set to 256 but should be 512. the SPD is what
contains configuration data for raminit, which training
code uses so that the timings will be correct. if the SPD
size is wrong, the machine won't boot

in practise, lbmk always runs "make oldconfig" on
a coreboot config, before building it, so this was
already being corrected automatically at build time.

however, if that fact ever changes in the future, this
wrong configuration would cause the machines not to boot.

therefore, this can be considered a preventative or perhaps
pre-emptive bug fix.

this fix does not need to be applied to the 20241206 release,
because of the behaviour described above. the final ROM images
do have the spd size set correctly to 512, because of this
design feature in lbmk.

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