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] 8f12e43dbf
[2] 11cacf55ad
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>
By making lbmk fully POSIX-compliant, it will be easier to port lbmk to
other systems implementing POSIX such as Alpine Linux and FreeBSD.
Signed-off-by: Ferass 'Vitali64' EL HAFIDI <vitali64pmemail@protonmail.com>
The configs were enabling SeaBIOS payload, but this is to be
handled by lbmk, not coreboot.
Further, they were enabling VGA ROM execution in coreboot, but
this should be handled by SeaBIOS.
This board should not have a GRUB payload enabled either; this
will be checked and fixed if necessary in the next commit.
Add U-Boot to the source release script's modules list so that it is
included in source release tarballs. Don't include the unused upstream
source and .git directories.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Copy the resources/scripts/build/clean/crossgcc script and adapt it to
run "make distclean" on U-Boot build trees. Some build artifacts persist
after the run, so also run "git clean -fdx" if we can.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
U-Boot build dependencies are listed on their online documentation [1],
but the listed Debian packages also include test-only dependencies.
While installing dependencies, install the packages necessary to build
U-Boot, except for the test-only ones I could identify.
[1] https://u-boot.readthedocs.io/en/latest/build/gcc.html
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Add a build for QEMU AArch64 virtual machine using U-Boot as payload.
Coreboot config is based on the following defconfig:
CONFIG_CBFS_SIZE=0x00c00000
CONFIG_BOARD_EMULATION_QEMU_AARCH64=y
CONFIG_CONSOLE_CBMEM_BUFFER_SIZE=0x20000
CONFIG_COREBOOT_ROMSIZE_KB_12288=y
CONFIG_UART_PCI_ADDR=0x0
The resulting ROM can be booted with a command line like:
qemu-system-aarch64 \
-machine virt,secure=on,virtualization=on \
-cpu cortex-a53 -m 1G \
-vga none -display none -serial stdio \
-bios bin/qemu_arm64_12mb/uboot_*.rom
However, this is little more than a proof of concept because U-Boot
upstream is missing coreboot integration on non-x86 boards, which could
have been useful for e.g. a framebuffer.
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>
U-Boot runtime configuration is done with a device-tree file, which is
built alongside the executable in the upstream build system, and must be
available to U-Boot at runtime.
This device-tree is normally not linked into the default "u-boot" ELF
file. So far we have been handling it by re-creating a "u-boot.elf" from
the raw binary parts by setting REMAKE_ELF, and using that as the
coreboot payload. Unfortunately, that fails to build for x86 boards,
more specificly the "coreboot" boards upstream.
It's also possible (but discouraged) to set OF_EMBED to embed the
device-tree file into the U-Boot itself, in which case we could use the
"u-boot" file as the payload on the "coreboot" boards. Add support for
using the "u-boot" file as the payload if "u-boot.elf" doesn't exist.
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>
The roms_helper script skips building crossgcc-i386 if its target
directory exists. Skip it for other architectures as well.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Add the coreboot-built cross-architecture toolchains to the PATH so that
modules and payloads can use them. When building for a foreign-arch
board, also export CROSS_COMPILE pointing to the appropriate prefix.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
This re-applies commit a69855f7e4 ("Build 32-bit crossgcc for AArch64
as well") which was inexplicably reverted along with unrelated changes.
Mention in a comment that building crossgcc-arm is necessary for
AArch64.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
When overriding which payloads will be built with the -p command line
argument, the roms_helper script builds the Memtest86+ payload before
checking if it should be disabled. Move the build command after the
command line override.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
When overriding which payloads will be built with the -p command line
argument, the roms_helper script doesn't disable the U-Boot payload.
Disable it in this case.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
The U-Boot download script does its work from the repository root
instead going into the newly created dirs, unlike the coreboot
counterpart. It should run the board-specific extra.sh files with the
downloaded paths as their working directory. Do so by a subshell.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
The no-argument form of the U-Boot download script prepare trees for all
boards when run with no arguments, like the corresponding script for
coreboot. The usage text for this case was removed without any changes
to the corresponding code, assume it was by mistake and add it back.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Removing the git dirs was part of deblobbing, which Libreboot no longer
cares about. The variable that triggers it is no more. Remove the dead
code.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
this is a hangover from pre-osboot-merge libreboot. the idea
was to distribute fsdg uboot archives
lbmk has uboot support, and releases will simply
include uboot in the main src archive like with everything else
the --nuke option in ifdtool will be used instead, to nuke
the ME regions in specific rom sets (and cbfstool will be
used to delete mrc.bin files from rom sets)
the new method being implemented is heavier on disk io, but
simplifies lbmk, and disk io could still be optimised in
the following ways:
* when copying roms from boards with ME in them, use
ifdtool --nuke to get filename.rom.new, and *move* (not copy)
filename.rom.new to the new destination (for use with tar)
* possibly modify ifdtool to make efficient use of mmap for
disk i/o; it currently loads entire roms into an allocated
buffer in memory
New x230edp_12mb target uses the
https://review.coreboot.org/c/coreboot/+/28950 patchset to add an
X230_EDP target to the default coreboot branch.
Consequently the "fhd" coreboot branch is no longer needed and has
been safely removed.
the intended use-case scenario was one in which vga rom initialisation
would be used, on desktop configurations, but without coreboot itself
handling vga rom initialisation, instead leaving that task to seabios
it was assumed that grub, when running on the bare metal with
build option "--with-platform=coreboot" would be able to display
like this, but it is not so when tested
in such setups (add-on gpu with grub payload), it is necessary to
extract the video bios and insert it into the coreboot rom, having
coreboot handle such execution. this is beyond the scope of lbmk,
in context of automated building, because we cannot reliably predict
things such as PCI IDs
do away with this build option entirely, for it does not serve the
intended purpose. it will be necessary to run PC GRUB instead (build
option --with-platform=i386-pc). PC GRUB can still read from CBFS,
and you could provide it as a floppy image file inside CBFS for
SeaBIOS to execute. in this setup, GRUB would function as originally
intended by the seabios_withgrub option; such a configuration is
referred to as "SeaGRUB" by the libreboot project, and experimentation
was done with it in the past, to no avail
it's better to keep things simple, in the libreboot project. simpler
for users, that is
buggy, buggy, buggy, buggy, buggy, buggy, buggy
full of bugs, these boards never worked properly. i got ripped
off with these.
now i'm ripping off the band aid
use dasharo if you want d16 stuff. i'm done with it.
python2 is eol and the only thing that needed it was build scripts
inside tianocore, back in osbmk days when tianocore was supported
in the (osboot) build system. nothing else requires it, so chuck it
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 coreboot configuration for the Samsung Chromebook 2 11", which
is based on the "google/peach_pit" mainboard in upstream coreboot. Also
adds a shared "peach" board directory to share with others having the
same baseboard.
The config is based on the following defconfig:
CONFIG_VENDOR_GOOGLE=y
CONFIG_CBFS_SIZE=0x00400000
CONFIG_UART_FOR_CONSOLE=3
CONFIG_BOARD_GOOGLE_PEACH_PIT=y
CONFIG_CONSOLE_CBMEM_BUFFER_SIZE=0x20000
CONFIG_UART_PCI_ADDR=0x0
CONFIG_I2C_TRANSFER_TIMEOUT_US=500000
Untested since I don't have the peach pit chromebook. This also fails
without a non-free 3rdparty/blobs/cpu/samsung/exynos5420/bl1.bin blob.
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 coreboot configuration for the HP Chromebook 11 G1, which is
part of the "google/daisy" mainboard in upstream coreboot. It uses the
shared tree for the "daisy" baseboard.
The config is based on the following defconfig:
CONFIG_VENDOR_GOOGLE=y
CONFIG_CBFS_SIZE=0x00400000
CONFIG_UART_FOR_CONSOLE=3
CONFIG_BOARD_GOOGLE_DAISY=y
CONFIG_CONSOLE_CBMEM_BUFFER_SIZE=0x20000
CONFIG_EC_GOOGLE_CHROMEEC_I2C_BUS=0x4
CONFIG_UART_PCI_ADDR=0x0
CONFIG_I2C_TRANSFER_TIMEOUT_US=500000
Untested since I don't have the spring chromebook. This also fails
without a non-free 3rdparty/blobs/cpu/samsung/exynos5250/bl1.bin blob.
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 coreboot configuration for the Samsung Chromebook - XE303,
which is based on the "google/daisy" mainboard in upstream coreboot.
Also adds a shared "daisy" board directory to share with others having
the same baseboard.
The config is based on the following defconfig:
CONFIG_VENDOR_GOOGLE=y
CONFIG_CBFS_SIZE=0x00400000
CONFIG_UART_FOR_CONSOLE=3
CONFIG_BOARD_GOOGLE_DAISY=y
CONFIG_CONSOLE_CBMEM_BUFFER_SIZE=0x20000
CONFIG_EC_GOOGLE_CHROMEEC_I2C_BUS=0x4
CONFIG_UART_PCI_ADDR=0x0
CONFIG_I2C_TRANSFER_TIMEOUT_US=500000
Untested since I don't have the snow chromebook. This also fails without
a non-free 3rdparty/blobs/cpu/samsung/exynos5250/bl1.bin blob.
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 coreboot configuration for the HP Chromebook 14 G3, which is
based on the "google/nyan_blaze" mainboard in upstream coreboot. It uses
the shared tree for the "nyan" baseboard.
The config is based on the following defconfig:
# CONFIG_USE_BLOBS is not set
CONFIG_VENDOR_GOOGLE=y
CONFIG_CBFS_SIZE=0x400000
CONFIG_BOOT_DEVICE_SPI_FLASH_BUS=4
CONFIG_BOARD_GOOGLE_NYAN_BLAZE=y
CONFIG_CONSOLE_CBMEM_BUFFER_SIZE=0x20000
CONFIG_DRIVERS_AS3722_RTC_BUS=4
CONFIG_DRIVERS_AS3722_RTC_ADDR=0x40
CONFIG_UART_PCI_ADDR=0x0
CONFIG_I2C_TRANSFER_TIMEOUT_US=500000
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 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 coreboot configuration for the Acer Chromebook 13 (CB5-311,
C810), which is based on the "google/nyan_big" mainboard in upstream
coreboot. Also adds a shared "nyan" board directory to share with
others having the same baseboard.
The config is based on the following defconfig:
# CONFIG_USE_BLOBS is not set
CONFIG_VENDOR_GOOGLE=y
CONFIG_CBFS_SIZE=0x400000
CONFIG_BOOT_DEVICE_SPI_FLASH_BUS=4
CONFIG_BOARD_GOOGLE_NYAN_BIG=y
CONFIG_CONSOLE_CBMEM_BUFFER_SIZE=0x20000
CONFIG_DRIVERS_AS3722_RTC_BUS=4
CONFIG_DRIVERS_AS3722_RTC_ADDR=0x40
CONFIG_UART_PCI_ADDR=0x0
CONFIG_I2C_TRANSFER_TIMEOUT_US=500000
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 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 coreboot configuration for the ASUS Chromebit CS10, which is
based on the "google/veyron_mickey" mainboard in upstream coreboot. It
uses the shared tree for the "veyron" baseboard.
The config is based on the following defconfig:
# CONFIG_USE_BLOBS is not set
CONFIG_VENDOR_GOOGLE=y
CONFIG_CBFS_SIZE=0x400000
CONFIG_BOARD_GOOGLE_VEYRON_MICKEY=y
CONFIG_CONSOLE_CBMEM_BUFFER_SIZE=0x20000
CONFIG_UART_PCI_ADDR=0x0
CONFIG_I2C_TRANSFER_TIMEOUT_US=500000
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 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 coreboot configuration for a few white-label chromebooks which
are based on the "google/veyron" mainboard in upstream coreboot. It uses
the shared tree for the "veyron" baseboard.
The config is based on the following defconfig:
# CONFIG_USE_BLOBS is not set
CONFIG_VENDOR_GOOGLE=y
CONFIG_CBFS_SIZE=0x400000
CONFIG_BOARD_GOOGLE_VEYRON_JERRY=y
CONFIG_CONSOLE_CBMEM_BUFFER_SIZE=0x20000
CONFIG_UART_PCI_ADDR=0x0
CONFIG_I2C_TRANSFER_TIMEOUT_US=500000
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 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 coreboot configuration for the ASUS Chromebook Flip C100PA,
which is based on the "google/veyron" mainboard in upstream coreboot. It
uses the shared tree for the "veyron" baseboard.
The config is based on the following defconfig:
# CONFIG_USE_BLOBS is not set
CONFIG_VENDOR_GOOGLE=y
CONFIG_CBFS_SIZE=0x400000
CONFIG_BOARD_GOOGLE_VEYRON_MINNIE=y
CONFIG_CONSOLE_CBMEM_BUFFER_SIZE=0x20000
CONFIG_UART_PCI_ADDR=0x0
CONFIG_I2C_TRANSFER_TIMEOUT_US=500000
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 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 coreboot configuration for the ASUS Chromebook C201PA, which
is based on the "google/veyron" mainboard in upstream coreboot. Also
adds a shared "veyron" board directory to share with others having the
same baseboard.
The config is based on the following defconfig:
# CONFIG_USE_BLOBS is not set
CONFIG_VENDOR_GOOGLE=y
CONFIG_CBFS_SIZE=0x400000
CONFIG_BOARD_GOOGLE_VEYRON_SPEEDY=y
CONFIG_CONSOLE_CBMEM_BUFFER_SIZE=0x20000
CONFIG_UART_PCI_ADDR=0x0
CONFIG_I2C_TRANSFER_TIMEOUT_US=500000
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 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 coreboot configuration for the ASUS Chromebook Flip C101,
which is based on the "google/gru" mainboard in upstream coreboot. It
uses the shared tree for the "gru" baseboard.
The config is based on the following defconfig:
# CONFIG_USE_BLOBS is not set
CONFIG_VENDOR_GOOGLE=y
CONFIG_CBFS_SIZE=0x00800000
CONFIG_BOARD_GOOGLE_BOB=y
CONFIG_DRIVER_TPM_SPI_BUS=0x0
CONFIG_CONSOLE_CBMEM_BUFFER_SIZE=0x20000
CONFIG_UART_PCI_ADDR=0x0
CONFIG_I2C_TRANSFER_TIMEOUT_US=500000
CONFIG_PAYLOAD_FIT_SUPPORT=y
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 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 coreboot configuration for the Samsung Chromebook Plus (v1),
which is based on the "google/gru" mainboard in upstream coreboot. Also
adds a shared "gru" board directory to share with others having the same
baseboard.
The config is based on the following defconfig:
# CONFIG_USE_BLOBS is not set
CONFIG_VENDOR_GOOGLE=y
CONFIG_CBFS_SIZE=0x00800000
CONFIG_BOARD_GOOGLE_KEVIN=y
CONFIG_CONSOLE_CBMEM_BUFFER_SIZE=0x20000
CONFIG_UART_PCI_ADDR=0x0
CONFIG_I2C_TRANSFER_TIMEOUT_US=500000
CONFIG_PAYLOAD_FIT_SUPPORT=y
Most things work, but one significant problem is that the board can't power
off properly. It also happens with my manual U-Boot-only builds, but not
when I manually build coreboot with a U-Boot payload. Not sure why it is
happening here as well.
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>
In recent coreboot versions, running distclean started to erase the
cbfstool binary we built earlier in the util/cbfstool dir via the
cbutils build script call. The coreboot build puts it in a different
directory, and the roms build script can't find it when trying to add
payloads to the roms. This doesn't make the script fail (because set -e
is stupid like that), and the build appears to succeed if you don't look
close enough to see the "cbfsutil not found" error.
Build the coreboot utils we want at the places we want them after
calling distclean, so that we can actually use cbfsutil and avoid
silently-broken roms with newer coreboot versions.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
This enables embedding U-Boot into the coreboot roms as the payload. For
now, the ELF file generated by enabling CONFIG_REMAKE_ELF is used, which
includes the U-Boot binary and the board-specific device-tree file. It
might be better to use the FIT payload support for U-Boot, but that was
reportedly broken and is not tested yet.
Coreboot boards can specify payload_uboot="y" in their board.cfg to
enable building a rom with U-Boot as the payload, which is built from
the U-Boot board with the same name. Boards can further specify a
uboot_config option, to choose which board-specific config file U-Boot
should be built with.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
The 32-bit ARM cross compiler toolchain is used to build parts of
arm-trusted-firmware needed by AArch64 boards, compile the toolchain for
those boards as well.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
The code that compiles coreboot crossgcc changes the working directory
to the coreboot directory, and the following code cannot find the lbmk
scripts that it needs to run. Compile ARMv7 and AArch64 cross compilers
in a subshell like in the x86 case so the rest of the script can work.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
These are almost verbatim copies of coreboot versions, but using
'u-boot' instead of 'coreboot' and 'ub*' instead of 'cb*'.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
This enables building U-Boot for boards which have config files in
resources/u-boot, and copying built files that could be usable to make
coreboot payloads. Right now, there is no such board in this repo.
The most important file here is "u-boot.elf", which is a combination of
the U-Boot binary and the appropriate device-tree file for the board.
Building this needs CONFIG_REMAKE_ELF=y on the U-Boot part, and using
this with CONFIG_PAYLOAD_ELF=y on the coreboot build works fine.
Note that this isn't enough to make U-Boot-only releases, since
low-level prerequisites like arm-trusted-firmware aren't passed in to
the U-Boot build system. Coreboot builds its own copy of TF-A and sets
it up on the board, so using these U-Boot builds as payloads should
still work.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Downloading coreboot and U-Boot takes quite the disk space and bandwith.
We don't need to download entire repos, only the revisions that we are
interested in.
Use the --depth=1 option to only download the files we need. Since the
initial clones may not have our target revision, always try to fetch it.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Keeping the git repositories is useful while development, e.g. to avoid
git cloning repositories over and over again while debugging download
scripts. Setting the NODELETE environment variable keeps the blobs and
the git repositories. Allow a slightly finer-tuned version of this where
we can keep only the git-related files by setting the variable to "git".
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>
The coreboot download removes .git folders as they still contain the
removed blobs, remove those in the U-Boot version as well.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Although it's unlikely, boards might want to run extra commands after
the board-specific U-Boot directories are prepared. Copy the existing
mechanism for that from the coreboot download script to the U-Boot one.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Boards may need different sets of patches to be applied to their U-Boot
builds, copy the existing mechanism from the coreboot download script to
the U-Boot download script.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
The coreboot download script tries to update submodules, since coreboot
does use git submodules to retrieve and compile the projects it depends
on. Although U-Boot doesn't use submodules, try to update them anyway to
match the coreboot download script.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
The coreboot download script uses GitHub as a fallback if the upstream
coreboot is unavailable, use a similar fallback for U-Boot as well.
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>
The u-boot-libre tarball contents' mtimes are an unconventional value
due to timezone confusion. For reproducibility, timestamps like these
are usually set by a SOURCE_DATE_EPOCH which is respected by both
coreboot and U-Boot. Use it in the u-boot-libre release script as well,
and properly set the mtimes to the Unix epoch when it's not defined.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
The u-boot-libre release script copies the blobs list into the release
as the deblob script, presumably due to a copy-paste error. Fix it to
correctly copy the generated deblob script.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
The checksums in tests/u-boot-libre.sha512 do not match the tarballs
generated by this script when ran on a different timezone, e.g. UTC+3.
Explicitly specify a timezone for the tar command that makes the
tarballs match the checksums.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
with this change, it's unlikely we'll hit errors again. previously,
some projects used were calling "python" which in context was
python3, but on some setups, the user only has python2 and python3
but no symlink for "python" (which if exists, we assumed linked to
python3)
now it's unambiguous. docs/build/ can probably be updated now, as
a result of this change, to remove the advice about that
I was running into a race condition when rebuilding seabios with a high cpu count,
resulting in failure with this error message:
cc1: fatal error: can't open 'out/src/asm-offsets.s' for writing: No such file or directory
Performing the silentoldconfig step before the full make step seems to resolve the failure.
When running ./download all, we have the following error:
resources/scripts/download/coreboot: Line 52: $1 is not set.
The ./download all command was broken by the following commit:
2bb805e2e0 (download: Add --help in the
individual download scripts).
Reported-by: madbehaviorus[m] on #libreboot on liberachat
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Without that fix we have the following warning during the download:
Cloning into 'u-boot/u-boot'...
warning: redirecting to https://source.denx.de/u-boot/u-boot.git/
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
This should enable various distributions and build system to reuse
the generated script to deblob u-boot releases themselves.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
This should enable various distributions and build system to reuse
that blob to deblob u-boot releases themselves.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
The tar options come from the tutorial to remove archives metadata at
reproducible-builds.org[1].
[1]https://reproducible-builds.org/docs/archives/
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
This doesn't change the existing usage of the scripts:
- For the Coreboot script, before this change, all arguments that were
passed were considered as board to download the Coreboot source code
for.
Here we added the '--help' and '--list-boards' arguments, so it
should not be an issue as it is extremely unlikely that a board
would be called '--help' or '--list-boards'.
- All the other scripts don't use any arguments so passing --help
should not conflict with the existing usage.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
If the script is named u-boot-stable-src-release and that users see an
u-boot-libre tarball they will not make the link between both unless
we rename the script.
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Many people using FSDG compliant distributions or wanting to use one
are already familiar with linux-libre. This change renames the
resulting tarball to u-boot-libre to make it easier for people to
understand the goal of this tarball.
In addition we also rename the version from v2021.07 (which is the git
tag corresponding to the release) to 2021.07 as u-boot upstream
tarballs use that.
The revision wasn't bumped as we didn't have any releases of
u-boot-libre yet.
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>
hardcode everything. in practise, the new logic will work just the same in
almost all cases, for most people, but it works around performance issues in
grub. cleanup of grub.cfg will be done in the next commit
On many boards, grub takes a very long time to
search for a grub.cfg file on the disk.
The problem is the search_grub function which
takes a long time to complete.
I (vitali64) studied the grub.cfg from 2016 and
the grub.cfg from 2021 and optimized the
grub.cfg. It should be faster now.
Coreboot is enabling PECI on these CPUs which, according to Intel erratum, must
only be done after loading microcode updates, otherwise the CPUID feature set
becomes corrupted. That's my understanding, and I think this is why SpeedStep
is broken. To be specific, it could but but operating systems no longer detect
that the feature is supported. In any case, belgin on IRC found the commit in
coreboot, after a bisect, enabling PECI. This commit in Libreboot adds a patch,
reverting coreboot's PECI patch.
tianocore is a liability for the libreboot project. it's a bloated mess, and
unreliable, broken on many boards, and basically impossible to audit.
i don't trust tianocore, so i'm removing it.
4mb and 8mb users can just pad their roms to 16mb, using the instructions on
<https://libreboot.org/faq.html#how-do-i-pad-a-rom-before-flashing>
maintaining them in lbmk is a waste of time, and also a hazard because it's a
lot of duplicated labour when making any changes, which could result in awful
mistakes being made
There is already a separate menuentry for USB, and most people don't boot their
installed system from USB anyway. This will result in faster boot speeds.
mitigate missing characters in unifont for border/arrow characters. this saves
space because now it is no longer necessary to add a custom font
the background added has the libreboot logo on it, and it's 10kb in size unlike
the old gnulove background that was hundreds of KB
These option ROMs are known to cause a system hang. If you insert an empty
option ROM into CBFS, it disables any option ROM loading for those devices
when using SeaBIOS.
this is a compromise. i was going to do 30 for desktops, 1 for laptops.
however, some laptop users complain about the 1 second timeout being too fast.
10 seconds should just about please everyone.
This fixes issue 3:
https://notabug.org/libreboot/lbmk/issues/3
In this issue, GM45 laptops such as X200/T400 will hang on reboot (normal boot
works, and shutting down works too).
2MiB and 16MiB were the only flash sizes supported. 4 and 8MiB have been
added.
Now there are only libgfxinit_txtmode configs.
Use seabios_withgrub or seabios_grubfirst ROMs if you wish to use an add-on
GPU.
this is forked from the "libre" branch in osboot, which is itself a libre,
deblobbed fork of osboot, a blobbed up fork of libreboot
libreboot needed to be purged clean. this is the new libreboot development
repository. the old one has been abandoned
Alper Nebi Yasak
Wei Mingzhi