| Age | Commit message (Collapse) | Author |
|---|
|
x86 u-boot is a bit flaky and this board never builds.
re-add it ot a later date.
u-boot is only really used in arm machines,
for our purposes at least.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
See file:
resources/scripts/build/defconfig/for
It is based on:
resources/scripts/build/payload/u-boot
The u-boot payload script has been deleted, as has the
seabios payload script; the build/boot/roms logic has
been heavily simplified too, by removing the logic for
building of elf files based on defconfig.
SeaBIOS, U-Boot and coreboot all use defconfig-type
infrastructure for their build systems, and they are
fundamentally the *same* in how to compile each codebase,
at least in an lbmk context, regardless of actual (and
very huge) differences in these codebases.
Several hundred sources-lines of code have been eliminated
by this change, drastically simplifying everything; U-Boot
payload compiling also now errors out when a single build
fails, instead of continuing. Also: build/boot/roms no longer
re-compiles a coreboot target that was already compiled,
which is the same behaviour observed for payloads.
(this means you must now manually delete a target, when you
wish to re-build it; the build/boot/roms logic now more or
less just runs cbfstool; blobutil is handled from
build/defconfig/for)
ALSO: Since crossgcc is now handled by build/defconfig/for, not
build/boot/roms, standalone compiling of u-boot is now possible.
This has been tested. You compile it like so:
./build defconfig for u-boot
or specific trees, e.g.
./build defconfig for u-boot default
One other consequence of this patch is that re-building the same
ROM image is now much faster, because the same builds are re-used
unless deleted. This could be useful when testing grub.cfg changes,
for example, if that's all you change. With things like ccache used
(not yet used robustly in lbmk), this could speed things up more,
depending on the codebase.
This patch demonstrates the raw power of lbmk; it is a very
simple and highly efficient build system, and now much more so!
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
they are fundamentally the same, in an lbmk context.
they are downloaded in the same way, and compiled in
the same way!
(Kconfig infrastructure, board-specific code, the way
submodules are used in git, etc)
~200 sloc reduction in resources/scripts
the audit begins
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Debian's signed shim allocates too many EFI variables to fit in the EFI
variable memory buffer. Normally it would then try to continue booting
in non-secure-boot mode, but its error handling throws a synchronous
abort that reboots the board, making it impossible to boot into Debian
unless one manually loads GRUB instead of shim. Increase EFI variable
buffer size to avoid triggering the bug.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
not well-tested, and existing testing has revealed video
issues on some of them (or just no boot)
for now, retain only qemu and gru-* on arm
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
bl1 bootloader blobs needed, and lbmk doesn't currently
auto-download these for insertion, so their presence in
the build system is problematic because people might build
these and think they work - they don't, due to the lack of
those bl1 blobs
notes about this are included in lbwww, on the compatibility
list. these can be re-added and tested later, when lbmk handles
those bl1 bootloader blobs
|
|
u-boot is known broken on these, last revision
known working is 2021.01
can bisect and find the fix. i'm putting this on
the issue tracker (new one on codeberg)
|
|
U-Boot can be configured via environment variables which can be saved to
various storage devices. This usually defaults to MMC or SPI depending
on where it boots from, but assumes the device's layout is controlled by
U-Boot.
We should store the environment in SPI flash, but we also need to
configure coreboot FMAPs to reserve the area U-Boot would use as its
environment storage. For now, disable environment storage by setting
ENV_IS_NOWHERE=y to avoid overwriting random regions of SPI or MMC if
someone tries to save the variables.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
Set default U-Boot revision to v2023.01 and rebase patches on top of
that. Upstream kconfig status is a bit unstable, so updating configs
with `make oldconfig` would miss important upstream changes.
For each board, run `make savedefconfig` and `diffconfig -m` at the old
version to get a diff from upstream defconfigs. Fix those affected by
upstream changes, like SYS_TEXT_BASE being renamed to TEXT_BASE. Then
append those to the new version's defconfigs and run `make olddefconfig`
to get updated configs.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
|
|
The USB 2.0 ports on Exynos boards need the relevant driver enabled by
USB_EHCI_EXYNOS. This is enabled by default depending on USB_EHCI_HCD.
It's already enabled on snow and spring, but apparently not on peach
boards, as discovered from other people's attempts to enable it [1][2].
Enable it also on the peach_pi and peach_pit.
[1] https://gitlab.com/exynos5-mainline/u-boot/-/commit/8f12e43dbfdebbd29f49c2cb8bf6e9b6ea7e70c9
[2] https://gitlab.com/exynos5-mainline/u-boot/-/commit/11cacf55ad720dfca8799561a38b1da4732a3018
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
The display driver on the veyron boards needs reset drivers, more
specifically RESET_ROCKCHIP. This is enabled by default depending on
DM_RESET, which an upstream commit enables for veyron_jerry claiming it
fixes the display [1]. Enable it also in our configs, but for other
veyrons as well.
[1] https://lore.kernel.org/u-boot/20220928024046.2657593-1-sjg@chromium.org/
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
Add a U-Boot payload build for the QEMU AArch64 virtual machine. The
config is same as upstream "qemu-arm64" defconfig, but SYS_TEXT_BASE is
set to 0x50000000 so that it doesn't conflict with coreboot. QEMU
auto-generates and passes a device-tree file to U-Boot at runtime,
there's no compile-time canonical version, so there's no need to set
REMAKE_ELF or OF_EMBED.
It's not immediately obvious if QEMU-specific drivers are available to
support display output, but most coreboot integration is unavailable
(depends on x86) and entire video subsystem is disabled in the U-Boot
upstream defconfig.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
Add a U-Boot build for the qemu_x86_12mb board. The config is a copy of
the upstream "coreboot" defconfig, but with OF_EMBED=y.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
Add a series posted to upstream mailing lists that makes the GRUB
text-mode console faster by implementing video damage tracking [1].
Refresh the config files to include its new VIDEO_DAMAGE Kconfig.
Patch 7/7 upstream has a tiny conflict with "Improve UEFI experience"
series we already have, but it's only in the diff context. No changes
other than fixing that.
[1] https://lore.kernel.org/u-boot/20220609225921.62462-1-agraf@csgraf.de/
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
Set revision to the commit hash of the v2022.10 release, and run "make
olddefconfig" for all boards to refresh the configs.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
Merge all boards into a common "default" tree, currently for v2022.07.
This ends up applying the "Improve UEFI experience on DM_VIDEO" series
to everything, so refresh the configs for the new options.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
osboot is now part of libreboot, and will soon shut down.
libreboot now conforms to osboot policy.
|
|
This adds U-Boot configuration for the Samsung Chromebook 2 13", also
known as "peach-pi" in the U-Boot upstream defconfigs. It uses the
shared tree for the "peach" baseboard. The config is almost the same as
upstream defconfig, but with REMAKE_ELF and POSITION_INDEPENDENT
enabled.
Untested since I don't have the peach pi chromebook. Note the there
doesn't seem to be any coreboot support for this chromebook.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
This adds U-Boot configuration for the Samsung Chromebook 2 11", also
known as "peach-pit" in the U-Boot upstream defconfigs. Also adds a
shared "peach" board directory to share with others having the same
baseboard. The config is almost the same as upstream defconfig, but with
REMAKE_ELF and POSITION_INDEPENDENT enabled.
Untested since I don't have the peach pit chromebook.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
This adds U-Boot configuration for the HP Chromebook 11 G1, also known
as "spring" in the U-Boot upstream defconfigs. It uses the shared tree
for the "daisy" baseboard. The config is almost the same as upstream
defconfig, but with REMAKE_ELF and POSITION_INDEPENDENT enabled.
Untested since I don't have the spring chromebook.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
This adds U-Boot configuration for the Samsung Chromebook - XE303, also
known as "snow" in the U-Boot upstream defconfigs. Also adds a shared
"daisy" board directory to share with others having the same baseboard.
The config is almost the same as upstream defconfig, but with REMAKE_ELF
and POSITION_INDEPENDENT enabled.
Untested since I don't have the snow chromebook.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
This adds U-Boot configuration for the HP Chromebook 14 G3, also known
as "nyan-blaze" but not in the U-Boot upstream defconfigs. Apparently
the "nyan-big" defconfig can also work for this version. It uses the
shared tree for the "nyan" baseboard. The config is almost the same as
upstream defconfig, but with REMAKE_ELF and POSITION_INDEPENDENT
enabled.
Untested since I don't have the nyan blaze chromebook.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
This adds U-Boot configuration for the Acer Chromebook 13 (CB5-311,
C810), also known as "nyan_big" in the U-Boot upstream defconfigs. Also
adds a shared "nyan" board directory to share with others having the
same baseboard. The config is almost the same as upstream defconfig, but
with REMAKE_ELF and POSITION_INDEPENDENT enabled.
Untested since I don't have the nyan big chromebook.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
This adds U-Boot configuration for the ASUS Chromebit CS10, also known
as "chromebit_mickey" in the U-Boot upstream defconfigs. It uses the
shared tree for the "veyron" baseboard. The config is almost the same as
upstream defconfig, but with REMAKE_ELF and POSITION_INDEPENDENT
enabled.
Untested since I don't have the veyron mickey chromebit.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
This adds U-Boot configuration for a few white-label chromebooks, known
as "chromebook_jerry" in the U-Boot upstream defconfigs. It uses the
shared tree for the "veyron" baseboard. The config is almost the same as
upstream defconfig, but with REMAKE_ELF and POSITION_INDEPENDENT
enabled.
Untested since I don't have any of the veyron jerry chromebooks.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
This adds U-Boot configuration for the ASUS Chromebook Flip C100PA, also
known as "chromebook_minnie" in the U-Boot upstream defconfigs. It uses
the shared tree for the "veyron" baseboard. The config is almost the
same as upstream defconfig, but with REMAKE_ELF and POSITION_INDEPENDENT
enabled.
Untested since I don't have the veyron minnie chromebook.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
This adds U-Boot configuration for the ASUS Chromebook C201PA, also
known as "chromebook_speedy" in the U-Boot upstream defconfigs. Also
adds a shared "veyron" board directory to share with others having the
same baseboard. The config is almost the same as upstream defconfig, but
with REMAKE_ELF and POSITION_INDEPENDENT enabled.
Untested since I don't have the veyron speedy chromebook.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
This adds U-Boot configuration for the ASUS Chromebook Flip C101,
also known as "chromebook_bob" in the U-Boot upstream defconfigs. It
uses the shared tree for the "gru" baseboard.
The config has the following diffconfig from kevin:
# chromebook_bob instead of chromebook_kevin
DEFAULT_DEVICE_TREE "rk3399-gru-kevin" -> "rk3399-gru-bob"
DEFAULT_FDT_FILE "rockchip/rk3399-gru-kevin.dtb" -> "rockchip/rk3399-gru-bob.dtb"
OF_LIST "rk3399-gru-kevin" -> "rk3399-gru-bob"
SPL_OF_LIST "rk3399-gru-kevin" -> "rk3399-gru-bob"
TARGET_CHROMEBOOK_BOB n -> y
TARGET_CHROMEBOOK_KEVIN y -> n
# Display resolution is 1280x800, and no need for the big font
VIDEO_FONT_8X16 n -> y
VIDEO_FONT_TER16X32 y -> n
VIDEO_ROCKCHIP_MAX_XRES 2400 -> 1280
VIDEO_ROCKCHIP_MAX_YRES 1600 -> 800
Untested since I don't have the bob chromebook.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
This adds U-Boot configuration for the Samsung Chromebook Plus (v1),
also known as "chromebook_kevin" in the U-Boot upstream defconfigs. Also
adds a shared "gru" board directory to share with others having the same
baseboard.
It uses v2022.07 with some quality-of-life patches. The first one is a
clock adjustment to match coreboot clocks for the video output, the
second one is a series about text cursor support and larger fonts. These
are because the display has a high resolution of 2400x1600 at 12.3".
The config has the following diffconfig from the upstream defconfig for
this board:
# For chainloading from depthcharge like a payload (RW_LEGACY).
# Not everything might be necessary, but didn't test without these.
INIT_SP_RELATIVE n -> y
LNX_KRNL_IMG_TEXT_OFFSET_BASE 0x00200000 -> 0x18000000
POSITION_INDEPENDENT n -> y
SYS_TEXT_BASE 0x00200000 -> 0x18000000
+SYS_INIT_SP_BSS_OFFSET 524288
# Higher speeds for eMMC
MMC_HS200_SUPPORT n -> y
MMC_HS400_ES_SUPPORT n -> y
MMC_HS400_SUPPORT n -> y
MMC_IO_VOLTAGE n -> y
MMC_SDHCI_SDMA n -> y
MMC_SPEED_MODE_SET n -> y
+MMC_UHS_SUPPORT y
# Build the u-boot.elf to use as a payload
REMAKE_ELF n -> y
# Slightly faster video output
VIDEO_COPY n -> y
# Larger fonts per the applied series
VIDEO_FONT_8X16 y -> n
VIDEO_FONT_TER16X32 n -> y
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
Add a 'v2022.07' pseudo-board for the U-Boot download script with the
default blobs list, and mark the version as supported in u-boot-libre
release script.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
Boards may want to specify a board-specific U-Boot revision. At the very
least, pseudo-boards for u-boot-libre releases will need to specify their
U-Boot versions somehow.
Copy the existing mechanism from download/coreboot for specifying
build info with board.cfg files. Specify the commit hash for the
'v2021.07' pseudo-board, and 'master' as the default.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
The U-Boot download script is designed to help with releasing
u-boot-libre and it can only prepare a generic U-Boot v2021.07 tree.
However, we will need to build board-specific versions of U-Boot to be
able to use it as a coreboot payload effectively.
As a first step toward that, make the download script prepare per-board
copies of U-Boot v2021.07. Then, add a 'v2021.07' pseudo-board for the
u-boot-libre release script to work on.
The u-boot-libre deblob script hash ends up chaning due to copying my
author attribution from the download script, update its hash.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
|
|
This firmware lack corresponding source code.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
|
Once the tarball are released, it will enable distributions to use
these tarballs to produce deblobbed u-boot packages.
Note that the produced tarball is not reproducible yet. Because of
that it has to be trusted.
During a release, it's a good idea to sign the uncompressed tarball as
the various compression formats and associated tools make different
tradeoffs.
For instance with xz, xz -9e tends to compress really well with the
the most used xz[1] implementation, and most GNU/Linux users probably
already have it installed, but and the drawbacks is that the format is
very fragile[2].
The lzip format is more suited for long term archiving but its most
packaged implementation[3] is less likely to be already installed by
users than more well known formats like xz, bzip2 or gzip.
Being able to add more compression formats after the release is also
useful, for instance to accommodate different build systems or use
cases (like being able to build u-boot with less dependencies in
distributions like Guix, or building u-boot directly on devices which
don't have enough RAM for xz for instance).
[1]https://tukaani.org/xz/
[2]https://www.nongnu.org/lzip/xz_inadequate.html
[3]https://www.nongnu.org/lzip/
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
|
