| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
same as on u-boot recently
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>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
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 19ec440a6f79dcbb089715fef814808a0fd40ae0.
|
|
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 cd9baca5d664d392316d94ccaa7deb209d4e1828.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
nvme worked but not sata. with this, t480 users with sata
ssds should be able to boot linux nicely
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
it just bootloops and doesn't seem reliable at the moment
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>
|
|
(#254) from alpernebbi/lbmk:u-boot-arm64-bootflow-menu into master
Reviewed-on: https://codeberg.org/libreboot/lbmk/pulls/254
|
|
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>
|
|
U-Boot on ARM64 also enables the bootflow menu.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Show it in the bootflow menu
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
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>
|
|
i'd copied the t1650 config and reselected the board lazily.
this fixes the issue:
https://codeberg.org/libreboot/lbmk/issues/242
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
This reverts commit 5b4c9158e5a79f8d7e776c8c4ece69dda5aa8690.
|
|
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>
|
|
was previously using the VGA ROM.
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>
|
|
alpernebbi/lbmk:uboot-v2024.10 into master
Reviewed-on: https://codeberg.org/libreboot/lbmk/pulls/253
|
|
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>
|
|
dGPU only, and starts in text mode.
will have to test with vesa framebuffer later on.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
there's a uart on the docking station
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
it has one on the docking station
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
it has one on the docking station
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
For some reason, 32-bit U-Boot only works when executed from
GRUB, but not SeaBIOS; 64-bit U-Boot only works from SeaBIOS!
This will have to be investigated. Standalone U-Boot, where
U-Boot is the primary payload, has not yet been tested in
Libreboot, and will not be provided for some time due to
stability concerns. More testing is needed!
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
The previous stability issues were resolved, thanks to
the previous revision which added a fix courtesy Simon Glass.
This reverts commit eba73c778a85d1c6ad2f0de57c82a8775cdd1c17.
|
|
U-Boot was hanging on hardware, but not Qemu. This is because on
the machines tested, namely the X200 and E6230 laptops supported
in Libreboot, the UART was disabled from coreboot.
This U-Boot patch from Simon Glass works around the issue by
silently disabling the UART when it isn't there. Instead,
output is sent to the display and U-Boot no longer hangs.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
It's really buggy on hardware. Disable for now.
I've contacted Simon Glass on IRC, asking about hardware.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
it's u, not b, for the U-Boot hotkey
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
