change python3-distutils to python3-distutils-extra
the latter is still available in debian sid, but not
the former. however, installing this should still
provide the additional files required.
with this, the debian script is now compatible with
both debian sid and debian stable(bookworm, presently).
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>
The appdir.patch file was used on the older deguard
version, prior to Mate Kukri's rewrite. This patch is
no longer required, and no longer used, so it can be
removed safely from lbmk.
Signed-off-by: Leah Rowe <leah@libreboot.org>
we needed these for extracting intel vga roms from
lenovoo updates, for t480, very briefly. about an hour
after i pushed that patch, mate kukri fixed libgfxinit
and then i removed the vgarom integration because it
wasn't needed anymore.
however, i forgot to remove geteltorito/mtools from
dependencies. some distros like fedora were problematic
about it.
the best thing about bugs is when you don't have to fix them.
Signed-off-by: Leah Rowe <leah@libreboot.org>
in this setup, seabios is never the default payload, grub is,
but only if grub is enabled.
set this in target.cfg:
payload_grubsea="y"
if payload_grub isn't enabled, this is auto-set to n
ditto if initmode=normal
NOTE: if flashing libgfx setups, you should make sure
that you're not booting with a graphics card, only intel
graphics. this setting will intentionally not be documented,
because it's not recommended, but is being implemented for
testing purposes (and i implemented it for some guy who i
think is cool). i'll probably also use this myself, since
i already do grub-only setups on all my own machines.
seagrub is the default on x86 because of past instabilities
with grub. to mitigate in case of future issues, since seabios
is always stable, we reduce the chance of bricks.
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 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 401efb24b2.
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>
Nope! Bootflow menu is cursed on this machine.
Too many issues in U-Boot on this machine. I did however
boot a Debian installer after it booted, using bootflow.
The installed system wouldn't boot with bootflow, but I could
then boot it with "bootefi bootmgr".
I'll rig up a uart on the T480 when I get round to it and
start investigating U-Boot bugs on this board.
I don't want people flashing something that doesn't work.
GRUB and SeaBIOS work, so ship those, and don't ship U-Boot.
This reverts commit 19ec440a6f.
u-boot does work after a few reboots. it just boot loops.
let it run. it should be able to boot from nvme. sata still needs
some work (sata only works in grub, on this machine)
This reverts commit cd9baca5d6.
Signed-off-by: Leah Rowe <leah@libreboot.org>
it's green there. different colour scheme apparently.
still works on x86. alper said his kevin chromebook was green!
Signed-off-by: Leah Rowe <leah@libreboot.org>
The bootflow menu is already the default boot command on x86. Switch
arm64 boards to that as well, so instead of booting the first thing we
find, we can easily choose what to boot.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Otherwise, you have to press enter to boot your distro.
With this, a timeout is created. After a number of seconds,
which can be reconfigured, the first option selected will be booted,
when generating a bootflow menu.
The timeout is disabled when you navigate the menu; it only
kicks in if you don't input anything on the keyboard.
More information about how this works is in the U-Boot patches,
within this patch. I've set the timeout to 8 seconds.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Otherwise, you have to press enter to boot, which is unacceptable
for headless operation.
Pressing anything other than enter an an option, such as the arrow
keys, will disable the timeout.
Signed-off-by: Leah Rowe <leah@libreboot.org>
On coreboot for example, as Mate has told me, if you're
making Kconfig changes and re-compiling, sometimes the
actual image that you build might still have the old one
in it, due to how coreboot's build system works.
To mitigate this, you can just always run distclean before
doing the build, but lbmk was doing just clean.
In practise, we did not find any issues, but this change should
be harmless, and might prevent such issues in the future. It's
even possible that we might have already encountered this before
and not realised, and we were just lucky that no noticeable issues
were caused.
It's *also* possible that the reverse is true: an issue that
was previously covered up, then that issue will now be exposed.
However, if that turns out to be true, then that is good because
we are exposing said bugs and then we will know to fix them!
Anyway, the variable in target.cfg is:
cleancmd="whatever_you_want"
e.g.
cleancmd="distclean"
You may also specify this in global mkhelper.cfg files, per
project; I've already done this for SeaBIOS, coreboot
and U-Boot, since all of these use Kconfig files.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Patchset 20 from:
https://review.coreboot.org/c/coreboot/+/83274/18..20
Updated to that. A bunch of changes I made locally have been
copied here, thus removed from lbmk.
The previous setup in lbmk was to have only the DIMM slot work,
on the ThinkPad T480S, without setting up SPD for the onboard RAM>
Mate Kukri reverse engineered the scheme by which the SPDs are
chosen at boot, based on the wiring of the board. This should
just about match the way Lenovo did it in their firmware.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This fixes an error where nvme disappears and gets renamed
on s3 resume. Mate Kukri told me to test that and it worked.
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>
I also enabled this on T480S, because otherwise SeaBIOS hung.
Enabling it shouldn't cause any harm on the T480, though Mate
did say that his machine seemed to work with my setup.
However, I believe that was when I gave him the ones that lbmk
built with the VGA ROM. Now it builds with libgfxinit, because
Mate was able to fix libgfxinit on this machine.
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>
We need to initialize the USB subsystem before we can use USB devices
like keyboards and external disks, by running `usb start`. Use the
PREBOOT config option to run the necessary command before U-Boot tries
to automatically boot anything. It's already enabled for boards other
than gru_kevin and gru_bob, so just update those two configs.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Set default U-Boot revision to v2024.10 and rebase patches on top of
that. The video subsystem now has switched to using the 'cyclic'
mechanism, so the code around one of the video patches changed a bit.
x86 boards were already switched to v2024.10. Update U-Boot for the
remaining ARM64 boards as usual:
- Turn old configs into defconfigs (./update trees -s u-boot)
- Save the diff from old upstream defconfig (diffconfig $theirs $ours)
- Update U-Boot revision, rebase patches, and clean old trees
- Prepare new U-Boot tree (./update trees -f u-boot)
- Review the diffconfigs to see if any options were renamed upstream
- Copy over the new upstream defconfigs and apply earlier diff
- Turn new defconfigs into configs (./update trees -l u-boot)
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
openssl-devel was split up in Fedora 41, and this package is required to build libreboot
on Fedora 41.
This was reported by "tweezers" on #libreboot.
Signed-off-by: Mate Kukri <km@mkukri.xyz>
This uses the "normal" config. Previous changes prevent
U-Boot images being built for this anyway, but it does
yield a warning message.
Remove the warning at the source.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Same concept as SeaGRUB, but for U-Boot. SeaBIOS starts, but
has a bootorder file loading U-Boot first, from flash.
You can interrupt it with the ESC menu, to boot something else
in SeaBIOS, including GRUB.
With this, we can effectively provide extremely user-friendly
UEFI-first setups in Libreboot.
Take that, edk2!
Signed-off-by: Leah Rowe <leah@libreboot.org>
This is a patch from Simon Glass. U-Boot clears the display
when it starts up, but was asking the VESA driver to do the
same, needlessly; this patch avoids the latter.
A further patch is also included, which provides a better
message when jumping into long mode on the SPL (64-bit) target,
dumping it on the serial console instead of using printf.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Leah Rowe