| Age | Commit message (Collapse) | Author |
|---|
|
I should have copied the extract directory, in cases
where it appears as filename_extracted/ under cache/,
but I was moving it instead.
Both locations (cache/file/*_extracted/
and vendorfiles/appdir/) get deleted, on every run of
the vendor script, per target, so this is OK.
The only sin is additional use of disk space, for
archives that are mostly very small and get immediately
deleted anyway.
This one lbmk bug, minor though it may be, prevented
the Libreboot 20241205 release, which (since it's now
the 6th of December) will become Libreboot 20241206
instead - and that gives me time to contemplate whether
I want to do one more change that I had planned for the 5th!
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 is used for factoryy bios dumps, in cases where
boards require extraction of ME and so on,
instead of downloading online.
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>
|
|
Otherwise, if PATH was set before, it will be re-used
again in the next pass. We previously unset CROSS_COMPILE
to avoid using the wrong cross-compiler when switching to
another target within a multi-tree project such as U-Boot.
Well, PATH was also being set, to use coreboot xgcc first.
This is fine, but the next target may not use the same one.
This patch solves a similar problem to the following patch
which was mentioned above:
commit 637c0a1521a03e3f65de85dcc5ffd478b37a5360
Author: Leah Rowe <leah@libreboot.org>
Date: Tue Nov 19 02:52:28 2024 +0000
trees: unset CROSS_COMPILE per target
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Since U-Boot must be inserted at a specific offset, it's
theoretically possible that other files might overlap, but
cbfstool will work around wherever U-Boot was inserted if
it was inserted first; we don't use specific offsets for
the other files.
This is technically a preventative bug fix, but it fixes
a bug that would probably never occur in practise.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
This is not a main script, and should not be treated as such;
it must never be directly executed by the user.
This script was only ever used inside other scripts, so the
shebang didn't seem to do much at all, but it shouldn't be
there anyway.
Remove it.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
dependency list' (#251) from mkukri/lbmk:master into master
Reviewed-on: https://codeberg.org/libreboot/lbmk/pulls/251
|
|
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>
|
|
Otherwise, you get "normal_normal" in the image name.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
The "normal" mode in lbmk is where no built-in GPU exists,
or no libgfxinit is used, and SeaBIOS is the first payload,
and SeaBIOS executes VGA ROMs (can't know if it'll start
in VESA or text mode).
U-Boot needs a VESA framebuffer or native coreboot
framebuffer to work correctly.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
U-Boot needs a VESA framebuffer or native coreboot
framebuffer to work properly.
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>
|
