| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
It's a new experimental payload in Libreboot, so we may aswell
start with the very latest release of U-Boot.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
it's important that we maintain realistic expectations.
x86 u-boot is not yet fully stable, so mark it as such.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Currently seems to stall when booted from the GRUB
payload, but works when booted from the SeaBIOS menu.
I also tested it as a standalone payload and it seems
to boot. Will test on hardware next, and start adding
it to more mainboards.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
also bring the coreboot/next modules in line with
the recent merge that did away with coreboot/dell7
the submodules for coreboot/haswell were still there,
and have now been deleted; the haswell tree was used
for the NRI patches, which were moved to /default some
time ago
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
coreboot/dell7 is now part of coreboot/next, which in turn
has been updated, to accomodate 3050 micro patchset 18:
https://review.coreboot.org/c/coreboot/+/82053/18
It incorporates my Verb/VBT patches, which are therefore
no longer included separately.
Mate has fixed the USB config; see diff for details.
The configuration of USB ports was wrong, before.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
payload_uboot_i386 must be defined here, or the
build will fail for coreboot targets
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
The fsp module is unnecessary on coreboot/default, and
therefore constitutes a waste of disk space.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
NOTE: Support added for xarch target x86_64-elf,
but U-Boot failed to build with this error:
OBJCOPY lib/efi_loader/helloworld.efi
x86_64-elf-objcopy: lib/efi_loader/helloworld_efi.so: invalid bfd target
make[2]: *** [scripts/Makefile.lib:476: lib/efi_loader/helloworld.efi] Error 1
Since I'm building U-Boot for x86_64 *on* an x86-64
host, and since that is currently the recommended type
of machine to use for lbmk development, and since the
other x86 payloads currently don't cross compile anyway,
this is an acceptable compromise for now. This is because
at present, I'm not making U-Boot the primary payload on x86,
instead preferring to chain it from GRUB and SeaBIOS.
The target.cfg file for x86 u-boot shows xarch/xtree commented.
Uncomment these to compile on crossgcc instead of hostcc.
I mention 64-bit because I initially did this first, but decided
to do 32-bit first. I'll work on the 64-bit one next (SPL).
It's only enabled in QEMU for now.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
There were a lot of unnecessary patches, such as the VRAM
patches; as Nicholas Chin has explained to me, the drivers
for these machines will just allocate what RAM they want
anyway, so in a lot of cases the extra allocated Video RAM
simply reduces the total amount of memory for other uses.
In general, we have a lot of patches that have existed for
years. A much more aggressive sweep will be done in the next
major audit, especially when the revisions are updated again.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Thanks go to Nicholas Chin and Lorenzo Aloe for working on
and testing this code. Based on the 780 MT port.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
pin mod needed (soldering) but according to mate, you
can use some coffeelake CPUs on these machines, despite
them being intel 7th gen. this includes 8-core chips.
this patch enables the software configuration in coreboot.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Thanks go to Lorenzo Aloe and Nicholas Chin for working on
and testing this code.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
This is for blanking the ME region on release builds.
This is required for lbmk when doing Libreboot releases,
on images that use an Intel ME region.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
I reset it temporarily back to 1.16.3 when testing the
SeaBIOS hanging bug on 3050 micro, but the revision had
no effect; the bug was caused by a bad coreboot config
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
