it's green there. different colour scheme apparently.
still works on x86. alper said his kevin chromebook was green!
was green on the libreboot one, which should be purple.
i don't know how can-u-boot green would show up. would be
funny if it turned out purple
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>
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>
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>
It wasn't being included, because we remove these files
in Canoeboot's version of U-Boot.
However, rules for including them was still in the U-Boot
build logic, leading to build issues such as:
arch/x86/dts/.cherryhill.dtb.pre.tmp:206:10: fatal error: microcode/m01406c2220.dtsi: No such file or directory
206 | #include "microcode/m01406c2220.dtsi"
This happened when building x86 U-Boot payloads. This patch
fixes the issue.
Signed-off-by: Leah Rowe <info@minifree.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>
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>
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>
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 Canoeboot.
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>
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>
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 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>
When building a coreboot image, if they enable the
x86 U-Boot payloads, sometimes what happens is you
have CROSS_COMPILE set, for i386-elf, but then it's
still set to that when later building 64-bit U-Boot,
which needs x86_64-elf.
We currently rely on hostcc to build U-Boot.
To mitigate this, unset CROSS_COMPILE in the main
loop of the trees script, for building project targets.
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>
This version simply updates the revision, whereas
the corresponding lbmk patch was more invasive:
commit 9abddb82b9228be738382ddc178a9562926404b3
Author: Leah Rowe <leah@libreboot.org>
Date: Wed Nov 6 22:28:45 2024 +0000
Bump coreboot/next and merge coreboot/dell7
Canoeboot must be in sync with Libreboot at all times.
Well, the Libreboot patch also merges another tree
that Canoeboot doesn't have, containing the Dell OptiPlex
3050 Micro port, because Canoeboot can't support the
OptiPlek 3050 Micro.
So the Libreboot patch rebased many patches. This one
simply updates the revision.
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 cbmk 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>
same revision, but re-do the patches again.
i wasn't quite as thorough with some of it yesterday.
for example, i included the ifdtool nuke patch yesterday,
which is not actually required in cbmk
Signed-off-by: Leah Rowe <info@minifree.org>
Since the E6400 was made into a variant for the E4300 dir,
the VBT file is now located in the e6400 variant directory,
instead of the main directory for the port, the latter of
which now accounts for both mainboards.
Signed-off-by: Leah Rowe <info@minifree.org>
This is based on the same change recently made in
lbmk. A lot of unnecessary patches, and I want to
clean them all up.
Also, cbmk's /default didn't actually build, whereas
lbmk did, which is the primary motive for this rebase.
With this change, it should build again.
Signed-off-by: Leah Rowe <info@minifree.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>
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>
GRUB-as-primary was temporarily allowed in lbmk, because of
a temporary SeaBIOS bug on a machine that canoeboot doesn't
actually support yet, namely the 3050 Micro.
This same diff was also applied to lbmk, but lbmk also applied
changes to a coreboot config for the aforementioned mainboard.
Signed-off-by: Leah Rowe <leah@libreboot.org>
- Update the MEC5035 S3 patches to the versions that were sent upstream
to prevent conflicts with subsequent patches for that EC.
- Update the patch that enables the S3 SMI handler in mainboard code so
that all Latitudes use the handler.
- Add a new patch that tells the EC to route power button events to the
host so that the OS can decide what to do. Without it, the EC powers
off the system without letting the OS cleanly shut down.
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
the .git directory never exists anyway, when doing a release,
so the purpose this is intended is defeated by lbmk's design.
individual headers say "pcsx-redux team" as copyright anyway,
and the code for generating that COPYING file, with MIT license
and correct years (matching the entire source code for the
open bios) remains correct.
a mitigation instead of this patch might be to maintain a hardcoded
list of authors, and manually update it over time, but this is not
required. however, it may be good practise for upstream to maintain
such a file. perhaps i should contact them?
Signed-off-by: Leah Rowe <leah@libreboot.org>
