[PATCH v5 00/20] x86: efi: Fixes and improvements for coreboot
This little series fixes various bugs and annoyances in coreboot and coreboot64.
With this both coreboot and coreboot64 start up and work reasonably well on Brya (x86 Chromebook) and U-Boot can boot common Linux distros.
- Make coreboot64 debug UART start reliably - Avoid the long USB-init delay on startup - Correct the timer speed on coreboo64 - Fix a bootstd cros bug (will likely be squashed into another patch) - Fix the terribly slow console scrolling
With v2 I have also brought in some lost x86 patches so they are all in one series.
Changes in v5: - Use 'lzma' instead of 'LZMA' - Drop unwanted space - Correct 'teechnique' typo in commit message - Make use of the uSE_PREBOOT mechanism
Changes in v4: - Fix arm and riscv - Rewrite this to use events instead
Changes in v3: - Allow SMBIOS if EFI_LOADER is enabled - Reword the help - Use log_debug() to show the message - Squash in the next patch
Changes in v2: - Update the malloc size too - Add new patch - Add new patch - Add new patch - Add new patch - Add new patch - Add new patch - Add new patch - Add new patch - Add new patch
Simon Glass (20): x86: coreboot: Add IDE and SATA x86: coreboot: Enable standard boot x86: coreboot: Rearrange arch_cpu_init() x86: Set the CPU vendor in SPL x86: Allow APCI in SPL x86: coreboot: Look for DBG2 UART in SPL too x86: coreboot: Enable CONFIG_SYS_NS16550_MEM32 x86: coreboot: Drop USB init on startup x86: coreboot: Align options between coreboot and coreboot64 x86: coreboot: Enable VIDEO_COPY efi: x86: Correct the condition for installing ACPI tables x86: smbios: Add a Kconfig indicating SMBIOS-table presence bootstd: Keep track of use of usb stop Record the position of the SMBIOS tables efi: Use the installed SMBIOS tables x86: coreboot: Record the position of the SMBIOS tables x86: doc: Move into its own directory x86: doc: Update summaries and add links x86: doc: Split out manual booting into its own file x86: doc: coreboot: Mention 64-bit Linux distros
arch/arm/include/asm/global_data.h | 3 + arch/riscv/include/asm/global_data.h | 3 + arch/sandbox/include/asm/global_data.h | 1 + arch/x86/cpu/coreboot/Kconfig | 1 + arch/x86/cpu/coreboot/coreboot.c | 16 +- arch/x86/cpu/x86_64/cpu.c | 7 + arch/x86/dts/coreboot.dts | 1 + arch/x86/include/asm/global_data.h | 1 + arch/x86/lib/coreboot/cb_sysinfo.c | 1 + arch/x86/lib/tables.c | 3 + boot/bootdev-uclass.c | 27 +++ configs/coreboot64_defconfig | 25 ++- configs/coreboot_defconfig | 21 +- doc/arch/index.rst | 2 +- doc/arch/x86/index.rst | 12 + doc/arch/x86/manual_boot.rst | 276 +++++++++++++++++++++++ doc/arch/{ => x86}/x86.rst | 295 ++----------------------- doc/board/coreboot/coreboot.rst | 38 +++- drivers/serial/Kconfig | 2 +- drivers/usb/host/usb-uclass.c | 8 + drivers/video/coreboot.c | 12 + include/asm-generic/global_data.h | 8 + include/bootdev.h | 9 + lib/Kconfig | 24 +- lib/efi_loader/Makefile | 4 +- lib/efi_loader/efi_setup.c | 20 +- lib/efi_loader/efi_smbios.c | 72 +++--- test/py/tests/test_event_dump.py | 1 + 28 files changed, 543 insertions(+), 350 deletions(-) create mode 100644 doc/arch/x86/index.rst create mode 100644 doc/arch/x86/manual_boot.rst rename doc/arch/{ => x86}/x86.rst (64%)
Add these options to permit access to more disk types.
Add some documentation as well.
Signed-off-by: Simon Glass sjg@chromium.org Reviewed-by: Bin Meng bmeng.cn@gmail.com ---
(no changes since v1)
configs/coreboot64_defconfig | 1 + configs/coreboot_defconfig | 9 +++++++++ doc/board/coreboot/coreboot.rst | 20 ++++++++++++++++++++ 3 files changed, 30 insertions(+)
diff --git a/configs/coreboot64_defconfig b/configs/coreboot64_defconfig index 2793e2c0b9d1..a456547a25d4 100644 --- a/configs/coreboot64_defconfig +++ b/configs/coreboot64_defconfig @@ -25,6 +25,7 @@ CONFIG_SYS_PBSIZE=532 CONFIG_CMD_IDE=y CONFIG_CMD_MMC=y CONFIG_CMD_PART=y +CONFIG_CMD_SATA=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_DHCP=y diff --git a/configs/coreboot_defconfig b/configs/coreboot_defconfig index f196ed776d0b..aedad4c93c30 100644 --- a/configs/coreboot_defconfig +++ b/configs/coreboot_defconfig @@ -21,8 +21,10 @@ CONFIG_LOGF_LINE=y CONFIG_LOGF_FUNC=y CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_PCI_INIT_R=y +CONFIG_CMD_IDE=y CONFIG_CMD_MMC=y CONFIG_CMD_PART=y +CONFIG_CMD_SATA=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_DHCP=y @@ -47,6 +49,13 @@ CONFIG_USE_ROOTPATH=y CONFIG_REGMAP=y CONFIG_SYSCON=y # CONFIG_ACPIGEN is not set +CONFIG_SYS_IDE_MAXDEVICE=4 +CONFIG_SYS_ATA_DATA_OFFSET=0 +CONFIG_SYS_ATA_REG_OFFSET=0 +CONFIG_SYS_ATA_ALT_OFFSET=0 +CONFIG_ATAPI=y +CONFIG_LBA48=y +CONFIG_SYS_64BIT_LBA=y CONFIG_NVME_PCI=y # CONFIG_PCI_PNP is not set CONFIG_SOUND=y diff --git a/doc/board/coreboot/coreboot.rst b/doc/board/coreboot/coreboot.rst index d660a223d9c8..be5b0de5495e 100644 --- a/doc/board/coreboot/coreboot.rst +++ b/doc/board/coreboot/coreboot.rst @@ -41,6 +41,26 @@ At present it seems that for Minnowboard Max, coreboot does not pass through the video information correctly (it always says the resolution is 0x0). This works correctly for link though.
+You can run via QEMU using:: + + qemu-system-x86_64 -bios build/coreboot.rom -serial mon:stdio + +The `-serial mon:stdio` part shows both output in the display and on the +console. It is optional. You can add `nographic` as well to *only* get console +output. + +To run with a SATA drive called `$DISK`:: + + qemu-system-x86_64 -bios build/coreboot.rom -serial mon:stdio \ + -drive id=disk,file=$DISK,if=none \ + -device ahci,id=ahci \ + -device ide-hd,drive=disk,bus=ahci.0 + +Then you can scan it with `scsi scan` and access it normally. + +To use 4GB of memory, typically necessary for booting Linux distros, add +`-m 4GB`. + 64-bit U-Boot -------------
Enable bootstd options and provide instructions on how to boot a linux distro using coreboot.
Signed-off-by: Simon Glass sjg@chromium.org Reviewed-by: Bin Meng bmeng.cn@gmail.com ---
Changes in v5: - Use 'lzma' instead of 'LZMA'
configs/coreboot64_defconfig | 14 ++------------ configs/coreboot_defconfig | 1 + doc/board/coreboot/coreboot.rst | 16 ++++++++++++++-- 3 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/configs/coreboot64_defconfig b/configs/coreboot64_defconfig index a456547a25d4..5623197f6be2 100644 --- a/configs/coreboot64_defconfig +++ b/configs/coreboot64_defconfig @@ -10,39 +10,29 @@ CONFIG_VENDOR_COREBOOT=y CONFIG_TARGET_COREBOOT=y CONFIG_FIT=y CONFIG_FIT_SIGNATURE=y +CONFIG_BOOTSTD_FULL=y +CONFIG_BOOTSTD_DEFAULTS=y CONFIG_SYS_MONITOR_BASE=0x01120000 CONFIG_SHOW_BOOT_PROGRESS=y CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="root=/dev/sdb3 init=/sbin/init rootwait ro" -CONFIG_USE_BOOTCOMMAND=y -CONFIG_BOOTCOMMAND="ext2load scsi 0:3 01000000 /boot/vmlinuz; zboot 01000000" CONFIG_PRE_CONSOLE_BUFFER=y CONFIG_SYS_CONSOLE_INFO_QUIET=y CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_SPL_NO_BSS_LIMIT=y -CONFIG_HUSH_PARSER=y CONFIG_SYS_PBSIZE=532 CONFIG_CMD_IDE=y CONFIG_CMD_MMC=y -CONFIG_CMD_PART=y CONFIG_CMD_SATA=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set -CONFIG_CMD_DHCP=y CONFIG_BOOTP_BOOTFILESIZE=y -CONFIG_CMD_PING=y CONFIG_CMD_TIME=y CONFIG_CMD_SOUND=y -CONFIG_CMD_EXT2=y -CONFIG_CMD_EXT4=y CONFIG_CMD_EXT4_WRITE=y -CONFIG_CMD_FAT=y -CONFIG_CMD_FS_GENERIC=y CONFIG_MAC_PARTITION=y # CONFIG_SPL_MAC_PARTITION is not set # CONFIG_SPL_DOS_PARTITION is not set -CONFIG_ISO_PARTITION=y -CONFIG_EFI_PARTITION=y # CONFIG_SPL_EFI_PARTITION is not set CONFIG_ENV_OVERWRITE=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y diff --git a/configs/coreboot_defconfig b/configs/coreboot_defconfig index aedad4c93c30..311ca6672cbd 100644 --- a/configs/coreboot_defconfig +++ b/configs/coreboot_defconfig @@ -10,6 +10,7 @@ CONFIG_TARGET_COREBOOT=y CONFIG_FIT=y CONFIG_FIT_SIGNATURE=y CONFIG_BOOTSTD_FULL=y +CONFIG_BOOTSTD_DEFAULTS=y CONFIG_SYS_MONITOR_BASE=0x01110000 CONFIG_SHOW_BOOT_PROGRESS=y CONFIG_USE_BOOTARGS=y diff --git a/doc/board/coreboot/coreboot.rst b/doc/board/coreboot/coreboot.rst index be5b0de5495e..3ef563b71dc9 100644 --- a/doc/board/coreboot/coreboot.rst +++ b/doc/board/coreboot/coreboot.rst @@ -67,9 +67,21 @@ To use 4GB of memory, typically necessary for booting Linux distros, add In addition to the 32-bit 'coreboot' build there is a 'coreboot64' build. This produces an image which can be booted from coreboot (32-bit). Internally it works by using a 32-bit SPL binary to switch to 64-bit for running U-Boot. It -can be useful for running UEFI applications, for example. +can be useful for running UEFI applications, for example with the coreboot +build in `$CBDIR`:: + + DISK=ubuntu-23.04-desktop-amd64.iso + CBDIR=~/coreboot/build + + cp $CBDIR/coreboot.rom.in coreboot.rom + cbfstool coreboot.rom add-flat-binary -f u-boot-x86-with-spl.bin \ + -n fallback/payload -c lzma -l 0x1110000 -e 0x1110000 + + qemu-system-x86_64 -m 2G -smp 4 -bios coreboot.rom \ + -drive id=disk,file=$DISK,if=none \ + -device ahci,id=ahci \ + -device ide-hd,drive=disk,bus=ahci.0 \
-This has only been lightly tested.
CBFS access -----------
Init errors in SPL are currently ignored by this function.
Change the code to init the CPU, reporting an error if something is wrong. After that, look for the coreboot table.
Signed-off-by: Simon Glass sjg@chromium.org Reviewed-by: Bin Meng bmeng.cn@gmail.com ---
Changes in v5: - Drop unwanted space
arch/x86/cpu/coreboot/coreboot.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/x86/cpu/coreboot/coreboot.c b/arch/x86/cpu/coreboot/coreboot.c index 835b2c777462..da43d66e95d7 100644 --- a/arch/x86/cpu/coreboot/coreboot.c +++ b/arch/x86/cpu/coreboot/coreboot.c @@ -21,7 +21,14 @@
int arch_cpu_init(void) { - int ret = get_coreboot_info(&lib_sysinfo); + int ret; + + ret = IS_ENABLED(CONFIG_X86_RUN_64BIT) ? x86_cpu_reinit_f() : + x86_cpu_init_f(); + if (ret) + return ret; + + ret = get_coreboot_info(&lib_sysinfo); if (ret != 0) { printf("Failed to parse coreboot tables.\n"); return ret; @@ -29,8 +36,7 @@ int arch_cpu_init(void)
timestamp_init();
- return IS_ENABLED(CONFIG_X86_RUN_64BIT) ? x86_cpu_reinit_f() : - x86_cpu_init_f(); + return 0; }
int checkcpu(void)
We don't read this information in 64-bit mode, since we don't have the macros for doing it. Set it to Intel by default. This allows the TSC timer to work correctly.
Signed-off-by: Simon Glass sjg@chromium.org Reviewed-by: Bin Meng bmeng.cn@gmail.com ---
(no changes since v1)
arch/x86/cpu/x86_64/cpu.c | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/arch/x86/cpu/x86_64/cpu.c b/arch/x86/cpu/x86_64/cpu.c index d1c3873dd6a7..2647bff891f8 100644 --- a/arch/x86/cpu/x86_64/cpu.c +++ b/arch/x86/cpu/x86_64/cpu.c @@ -8,8 +8,11 @@ #include <cpu_func.h> #include <debug_uart.h> #include <init.h> +#include <asm/cpu.h> #include <asm/global_data.h>
+DECLARE_GLOBAL_DATA_PTR; + int cpu_has_64bit(void) { return true; @@ -38,6 +41,10 @@ int x86_mp_init(void)
int x86_cpu_reinit_f(void) { + /* set the vendor to Intel so that native_calibrate_tsc() works */ + gd->arch.x86_vendor = X86_VENDOR_INTEL; + gd->arch.has_mtrr = true; + return 0; }
This is needed so we can find the DBG2 table provided by coreboot. Add a Kconfig so it can be enabled.
Signed-off-by: Simon Glass sjg@chromium.org Reviewed-by: Bin Meng bmeng.cn@gmail.com ---
(no changes since v1)
lib/Kconfig | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/lib/Kconfig b/lib/Kconfig index eb2b10161824..7edaeebfdaf5 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -289,6 +289,14 @@ config ACPI not necessarily include generation of tables (see GENERATE_ACPI_TABLE), but allows for tables to be located.
+config SPL_ACPI + bool "Enable support for ACPI libraries in SPL" + depends on SPL && SUPPORT_ACPI + help + Provides library functions for dealing with ACPI tables in SPL. This + does not necessarily include generation of tables + (see GENERATE_ACPI_TABLE), but allows for tables to be located. + config GENERATE_ACPI_TABLE bool "Generate an ACPI (Advanced Configuration and Power Interface) table" depends on ACPI
If coreboot does not set up sysinfo for the UART, SPL currently hangs. Use the DBG2 technique there as well. This allows coreboot64 to boot from coreboot even if the console info is missing from sysinfo
Signed-off-by: Simon Glass sjg@chromium.org Reviewed-by: Bin Meng bmeng.cn@gmail.com ---
Changes in v5: - Correct 'teechnique' typo in commit message
configs/coreboot64_defconfig | 1 + drivers/serial/Kconfig | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/configs/coreboot64_defconfig b/configs/coreboot64_defconfig index 5623197f6be2..e8165961c199 100644 --- a/configs/coreboot64_defconfig +++ b/configs/coreboot64_defconfig @@ -54,4 +54,5 @@ CONFIG_SYS_64BIT_LBA=y CONFIG_SOUND=y CONFIG_SOUND_I8254=y CONFIG_CONSOLE_SCROLL_LINES=5 +CONFIG_SPL_ACPI=y # CONFIG_GZIP is not set diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig index 7ca42df6a7e2..27b4b9d96507 100644 --- a/drivers/serial/Kconfig +++ b/drivers/serial/Kconfig @@ -672,7 +672,7 @@ config COREBOOT_SERIAL config COREBOOT_SERIAL_FROM_DBG2 bool "Obtain UART from ACPI tables" depends on COREBOOT_SERIAL - default y if !SPL + default y help Select this to try to find a DBG2 record in the ACPI tables, in the event that coreboot does not provide information about the UART in the
The debug UART on modern machines uses a 32-bit wide transfer. Without this, setting debug output causes a hang or no output. It is not obvious (when enabling CONFIG_DEBUG_UART) that this is needed.
Enable 32-bit access to avoid this trap.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
configs/coreboot64_defconfig | 1 + configs/coreboot_defconfig | 1 + 2 files changed, 2 insertions(+)
diff --git a/configs/coreboot64_defconfig b/configs/coreboot64_defconfig index e8165961c199..c04056339462 100644 --- a/configs/coreboot64_defconfig +++ b/configs/coreboot64_defconfig @@ -51,6 +51,7 @@ CONFIG_ATAPI=y CONFIG_LBA48=y CONFIG_SYS_64BIT_LBA=y # CONFIG_PCI_PNP is not set +CONFIG_SYS_NS16550_MEM32=y CONFIG_SOUND=y CONFIG_SOUND_I8254=y CONFIG_CONSOLE_SCROLL_LINES=5 diff --git a/configs/coreboot_defconfig b/configs/coreboot_defconfig index 311ca6672cbd..e7e45c2b0a9b 100644 --- a/configs/coreboot_defconfig +++ b/configs/coreboot_defconfig @@ -59,6 +59,7 @@ CONFIG_LBA48=y CONFIG_SYS_64BIT_LBA=y CONFIG_NVME_PCI=y # CONFIG_PCI_PNP is not set +CONFIG_SYS_NS16550_MEM32=y CONFIG_SOUND=y CONFIG_SOUND_I8254=y CONFIG_CONSOLE_SCROLL_LINES=5
On Wed, Sep 20, 2023 at 11:00 AM Simon Glass sjg@chromium.org wrote:
The debug UART on modern machines uses a 32-bit wide transfer. Without this, setting debug output causes a hang or no output. It is not obvious (when enabling CONFIG_DEBUG_UART) that this is needed.
Enable 32-bit access to avoid this trap.
Signed-off-by: Simon Glass sjg@chromium.org
(no changes since v1)
configs/coreboot64_defconfig | 1 + configs/coreboot_defconfig | 1 + 2 files changed, 2 insertions(+)
Reviewed-by: Bin Meng bmeng.cn@gmail.com
This is very annoying as it is quite slow on many machines. Also, U-Boot has an existing 'preboot' mechanism to enable this feature if desired.
Drop this code so that it is possible to choose whether to init USB or not.
Use the existing USE_PREBOOT mechanism instead.
Signed-off-by: Simon Glass sjg@chromium.org ---
Changes in v5: - Make use of the uSE_PREBOOT mechanism
arch/x86/cpu/coreboot/Kconfig | 1 + arch/x86/cpu/coreboot/coreboot.c | 4 ---- 2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/x86/cpu/coreboot/Kconfig b/arch/x86/cpu/coreboot/Kconfig index b97c27790419..178f8ad18162 100644 --- a/arch/x86/cpu/coreboot/Kconfig +++ b/arch/x86/cpu/coreboot/Kconfig @@ -25,6 +25,7 @@ config SYS_COREBOOT imply FS_CBFS imply CBMEM_CONSOLE imply X86_TSC_READ_BASE + imply USE_PREBOOT select BINMAN if X86_64
endif diff --git a/arch/x86/cpu/coreboot/coreboot.c b/arch/x86/cpu/coreboot/coreboot.c index da43d66e95d7..82fe4c71cd27 100644 --- a/arch/x86/cpu/coreboot/coreboot.c +++ b/arch/x86/cpu/coreboot/coreboot.c @@ -86,10 +86,6 @@ static int last_stage_init(void) if (IS_ENABLED(CONFIG_SPL_BUILD)) return 0;
- /* start usb so that usb keyboard can be used as input device */ - if (IS_ENABLED(CONFIG_USB_KEYBOARD)) - usb_init(); - board_final_init();
return 0;
On 9/20/23 05:00, Simon Glass wrote:
This is very annoying as it is quite slow on many machines. Also, U-Boot has an existing 'preboot' mechanism to enable this feature if desired.
Drop this code so that it is possible to choose whether to init USB or not.
Use the existing USE_PREBOOT mechanism instead.
Signed-off-by: Simon Glass sjg@chromium.org
Changes in v5:
Make use of the uSE_PREBOOT mechanism
arch/x86/cpu/coreboot/Kconfig | 1 + arch/x86/cpu/coreboot/coreboot.c | 4 ---- 2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/x86/cpu/coreboot/Kconfig b/arch/x86/cpu/coreboot/Kconfig index b97c27790419..178f8ad18162 100644 --- a/arch/x86/cpu/coreboot/Kconfig +++ b/arch/x86/cpu/coreboot/Kconfig @@ -25,6 +25,7 @@ config SYS_COREBOOT imply FS_CBFS imply CBMEM_CONSOLE imply X86_TSC_READ_BASE
- imply USE_PREBOOT
For automatic initialization of the PCI bus we have CONFIG_PCI_INIT_R. Wouldn't it be preferable to also have a CONFIG_USB_INIT_R instead of relying on console commands in CONFIG_PREBOOT?
Best regards
Heinrich
select BINMAN if X86_64
endif diff --git a/arch/x86/cpu/coreboot/coreboot.c b/arch/x86/cpu/coreboot/coreboot.c index da43d66e95d7..82fe4c71cd27 100644 --- a/arch/x86/cpu/coreboot/coreboot.c +++ b/arch/x86/cpu/coreboot/coreboot.c @@ -86,10 +86,6 @@ static int last_stage_init(void) if (IS_ENABLED(CONFIG_SPL_BUILD)) return 0;
/* start usb so that usb keyboard can be used as input device */
if (IS_ENABLED(CONFIG_USB_KEYBOARD))
usb_init();board_final_init();
return 0;
On 9/20/23 09:19, Heinrich Schuchardt wrote:
On 9/20/23 05:00, Simon Glass wrote:
This is very annoying as it is quite slow on many machines. Also, U-Boot has an existing 'preboot' mechanism to enable this feature if desired.
Drop this code so that it is possible to choose whether to init USB or not.
Use the existing USE_PREBOOT mechanism instead.
Signed-off-by: Simon Glass sjg@chromium.org
Changes in v5:
- Make use of the uSE_PREBOOT mechanism
arch/x86/cpu/coreboot/Kconfig | 1 + arch/x86/cpu/coreboot/coreboot.c | 4 ---- 2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/x86/cpu/coreboot/Kconfig b/arch/x86/cpu/coreboot/Kconfig index b97c27790419..178f8ad18162 100644 --- a/arch/x86/cpu/coreboot/Kconfig +++ b/arch/x86/cpu/coreboot/Kconfig @@ -25,6 +25,7 @@ config SYS_COREBOOT imply FS_CBFS imply CBMEM_CONSOLE imply X86_TSC_READ_BASE + imply USE_PREBOOT
For automatic initialization of the PCI bus we have CONFIG_PCI_INIT_R. Wouldn't it be preferable to also have a CONFIG_USB_INIT_R instead of relying on console commands in CONFIG_PREBOOT?
I'd much prefer 'preboot=usb init' or whatever console command, since this is not hard-coded into the U-Boot binary and can be overridden by user if the 'usb init' is inconvenient/unnecessary/... without replacing and/or rebuilding the U-Boot binary.
On 20.09.23 13:50, Marek Vasut wrote:
On 9/20/23 09:19, Heinrich Schuchardt wrote:
On 9/20/23 05:00, Simon Glass wrote:
This is very annoying as it is quite slow on many machines. Also, U-Boot has an existing 'preboot' mechanism to enable this feature if desired.
Drop this code so that it is possible to choose whether to init USB or not.
Use the existing USE_PREBOOT mechanism instead.
Signed-off-by: Simon Glass sjg@chromium.org
Changes in v5:
- Make use of the uSE_PREBOOT mechanism
arch/x86/cpu/coreboot/Kconfig | 1 + arch/x86/cpu/coreboot/coreboot.c | 4 ---- 2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/x86/cpu/coreboot/Kconfig b/arch/x86/cpu/coreboot/Kconfig index b97c27790419..178f8ad18162 100644 --- a/arch/x86/cpu/coreboot/Kconfig +++ b/arch/x86/cpu/coreboot/Kconfig @@ -25,6 +25,7 @@ config SYS_COREBOOT imply FS_CBFS imply CBMEM_CONSOLE imply X86_TSC_READ_BASE + imply USE_PREBOOT
For automatic initialization of the PCI bus we have CONFIG_PCI_INIT_R. Wouldn't it be preferable to also have a CONFIG_USB_INIT_R instead of relying on console commands in CONFIG_PREBOOT?
I'd much prefer 'preboot=usb init' or whatever console command, since this is not hard-coded into the U-Boot binary and can be overridden by user if the 'usb init' is inconvenient/unnecessary/... without replacing and/or rebuilding the U-Boot binary.
Just for the record this means using CONFIG_PREBOOT:
include/env_default.h:
#ifdef CONFIG_PREBOOT_DEFINED "preboot=" CONFIG_PREBOOT "\0" #endif
Thank you for the clarification.
Best regards
Heinrich
Hi Simon,
On Wed, Sep 20, 2023 at 9:37 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 20.09.23 13:50, Marek Vasut wrote:
On 9/20/23 09:19, Heinrich Schuchardt wrote:
On 9/20/23 05:00, Simon Glass wrote:
This is very annoying as it is quite slow on many machines. Also, U-Boot has an existing 'preboot' mechanism to enable this feature if desired.
Drop this code so that it is possible to choose whether to init USB or not.
Use the existing USE_PREBOOT mechanism instead.
Signed-off-by: Simon Glass sjg@chromium.org
Changes in v5:
Make use of the uSE_PREBOOT mechanism
arch/x86/cpu/coreboot/Kconfig | 1 + arch/x86/cpu/coreboot/coreboot.c | 4 ---- 2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/x86/cpu/coreboot/Kconfig b/arch/x86/cpu/coreboot/Kconfig index b97c27790419..178f8ad18162 100644 --- a/arch/x86/cpu/coreboot/Kconfig +++ b/arch/x86/cpu/coreboot/Kconfig @@ -25,6 +25,7 @@ config SYS_COREBOOT imply FS_CBFS imply CBMEM_CONSOLE imply X86_TSC_READ_BASE
- imply USE_PREBOOT
For automatic initialization of the PCI bus we have CONFIG_PCI_INIT_R. Wouldn't it be preferable to also have a CONFIG_USB_INIT_R instead of relying on console commands in CONFIG_PREBOOT?
I'd much prefer 'preboot=usb init' or whatever console command, since this is not hard-coded into the U-Boot binary and can be overridden by user if the 'usb init' is inconvenient/unnecessary/... without replacing and/or rebuilding the U-Boot binary.
Just for the record this means using CONFIG_PREBOOT:
include/env_default.h:
#ifdef CONFIG_PREBOOT_DEFINED "preboot=" CONFIG_PREBOOT "\0" #endif
Thank you for the clarification.
Will you update the coreboot documentation to mention the PREBOOT mechanism to initialize USB so that a USB keyboard can be used as the input for the U-Boot console?
Regards, Bin
These two builds are similar but have some different options for not good reason. Line them up to be as similar as possible.
Signed-off-by: Simon Glass sjg@chromium.org Reviewed-by: Bin Meng bmeng.cn@gmail.com ---
(no changes since v2)
Changes in v2: - Update the malloc size too
configs/coreboot64_defconfig | 7 +++++++ configs/coreboot_defconfig | 9 --------- 2 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/configs/coreboot64_defconfig b/configs/coreboot64_defconfig index c04056339462..dc3548aa736c 100644 --- a/configs/coreboot64_defconfig +++ b/configs/coreboot64_defconfig @@ -1,5 +1,6 @@ CONFIG_X86=y CONFIG_TEXT_BASE=0x1120000 +CONFIG_SYS_MALLOC_LEN=0x2000000 CONFIG_NR_DRAM_BANKS=8 CONFIG_ENV_SIZE=0x1000 CONFIG_DEFAULT_DEVICE_TREE="coreboot" @@ -18,6 +19,9 @@ CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="root=/dev/sdb3 init=/sbin/init rootwait ro" CONFIG_PRE_CONSOLE_BUFFER=y CONFIG_SYS_CONSOLE_INFO_QUIET=y +CONFIG_LOG=y +CONFIG_LOGF_LINE=y +CONFIG_LOGF_FUNC=y CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_SPL_NO_BSS_LIMIT=y CONFIG_SYS_PBSIZE=532 @@ -50,10 +54,13 @@ CONFIG_SYS_ATA_ALT_OFFSET=0 CONFIG_ATAPI=y CONFIG_LBA48=y CONFIG_SYS_64BIT_LBA=y +CONFIG_NVME_PCI=y # CONFIG_PCI_PNP is not set CONFIG_SYS_NS16550_MEM32=y CONFIG_SOUND=y CONFIG_SOUND_I8254=y CONFIG_CONSOLE_SCROLL_LINES=5 CONFIG_SPL_ACPI=y +CONFIG_CMD_DHRYSTONE=y # CONFIG_GZIP is not set +CONFIG_SMBIOS_PARSER=y diff --git a/configs/coreboot_defconfig b/configs/coreboot_defconfig index e7e45c2b0a9b..630eb9aa384c 100644 --- a/configs/coreboot_defconfig +++ b/configs/coreboot_defconfig @@ -24,23 +24,14 @@ CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_PCI_INIT_R=y CONFIG_CMD_IDE=y CONFIG_CMD_MMC=y -CONFIG_CMD_PART=y CONFIG_CMD_SATA=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set -CONFIG_CMD_DHCP=y CONFIG_BOOTP_BOOTFILESIZE=y -CONFIG_CMD_PING=y CONFIG_CMD_TIME=y CONFIG_CMD_SOUND=y -CONFIG_CMD_EXT2=y -CONFIG_CMD_EXT4=y CONFIG_CMD_EXT4_WRITE=y -CONFIG_CMD_FAT=y -CONFIG_CMD_FS_GENERIC=y CONFIG_MAC_PARTITION=y -CONFIG_ISO_PARTITION=y -CONFIG_EFI_PARTITION=y CONFIG_ENV_OVERWRITE=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_USE_BOOTFILE=y
At least on modern machines the write-back mechanism for the frame buffer is quite slow when scrolling, since it must read the entire frame buffer and write it back.
Enable the VIDEO_COPY feature to resolve this problem.
Signed-off-by: Simon Glass sjg@chromium.org Reviewed-by: Bin Meng bmeng.cn@gmail.com ---
(no changes since v1)
arch/x86/dts/coreboot.dts | 1 + configs/coreboot64_defconfig | 1 + configs/coreboot_defconfig | 1 + drivers/video/coreboot.c | 12 ++++++++++++ 4 files changed, 15 insertions(+)
diff --git a/arch/x86/dts/coreboot.dts b/arch/x86/dts/coreboot.dts index f9ff5346a79b..0eb31cae42c1 100644 --- a/arch/x86/dts/coreboot.dts +++ b/arch/x86/dts/coreboot.dts @@ -42,6 +42,7 @@ };
coreboot-fb { + bootph-some-ram; compatible = "coreboot-fb"; }; }; diff --git a/configs/coreboot64_defconfig b/configs/coreboot64_defconfig index dc3548aa736c..555d281ef3cf 100644 --- a/configs/coreboot64_defconfig +++ b/configs/coreboot64_defconfig @@ -59,6 +59,7 @@ CONFIG_NVME_PCI=y CONFIG_SYS_NS16550_MEM32=y CONFIG_SOUND=y CONFIG_SOUND_I8254=y +CONFIG_VIDEO_COPY=y CONFIG_CONSOLE_SCROLL_LINES=5 CONFIG_SPL_ACPI=y CONFIG_CMD_DHRYSTONE=y diff --git a/configs/coreboot_defconfig b/configs/coreboot_defconfig index 630eb9aa384c..edc38f1f5923 100644 --- a/configs/coreboot_defconfig +++ b/configs/coreboot_defconfig @@ -53,6 +53,7 @@ CONFIG_NVME_PCI=y CONFIG_SYS_NS16550_MEM32=y CONFIG_SOUND=y CONFIG_SOUND_I8254=y +CONFIG_VIDEO_COPY=y CONFIG_CONSOLE_SCROLL_LINES=5 CONFIG_CMD_DHRYSTONE=y # CONFIG_GZIP is not set diff --git a/drivers/video/coreboot.c b/drivers/video/coreboot.c index c586475e41ed..5b718ae3e5a5 100644 --- a/drivers/video/coreboot.c +++ b/drivers/video/coreboot.c @@ -73,6 +73,17 @@ err: return ret; }
+static int coreboot_video_bind(struct udevice *dev) +{ + struct video_uc_plat *uc_plat = dev_get_uclass_plat(dev); + + /* Set the maximum supported resolution */ + uc_plat->size = 4096 * 2160 * 4; + log_debug("%s: Frame buffer size %x\n", __func__, uc_plat->size); + + return 0; +} + static const struct udevice_id coreboot_video_ids[] = { { .compatible = "coreboot-fb" }, { } @@ -82,5 +93,6 @@ U_BOOT_DRIVER(coreboot_video) = { .name = "coreboot_video", .id = UCLASS_VIDEO, .of_match = coreboot_video_ids, + .bind = coreboot_video_bind, .probe = coreboot_video_probe, };
It is not always the case that U-Boot builds the ACPI tables itself. For example, when booting from coreboot, the ACPI tables are built by coreboot.
Correct the Makefile condition so that U-Boot can pass on tables built by a previous firmware stage.
Tidy up the installation-condition code while we are here.
Signed-off-by: Simon Glass sjg@chromium.org Reviewed-by: Ilias Apalodimas ilias.apalodimas@linaro.org Reviewed-by: Bin Meng bmeng.cn@gmail.com ---
(no changes since v2)
Changes in v2: - Add new patch
lib/efi_loader/Makefile | 2 +- lib/efi_loader/efi_setup.c | 10 +++++----- 2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile index 1a8c8d7cab5c..0eb748ff1a59 100644 --- a/lib/efi_loader/Makefile +++ b/lib/efi_loader/Makefile @@ -78,7 +78,7 @@ obj-$(CONFIG_EFI_ESRT) += efi_esrt.o obj-$(CONFIG_VIDEO) += efi_gop.o obj-$(CONFIG_BLK) += efi_disk.o obj-$(CONFIG_NETDEVICES) += efi_net.o -obj-$(CONFIG_GENERATE_ACPI_TABLE) += efi_acpi.o +obj-$(CONFIG_ACPI) += efi_acpi.o obj-$(CONFIG_GENERATE_SMBIOS_TABLE) += efi_smbios.o obj-$(CONFIG_EFI_RNG_PROTOCOL) += efi_rng.o obj-$(CONFIG_EFI_TCG2_PROTOCOL) += efi_tcg2.o diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c index 58d4e1340233..ad719afd6328 100644 --- a/lib/efi_loader/efi_setup.c +++ b/lib/efi_loader/efi_setup.c @@ -321,11 +321,11 @@ efi_status_t efi_init_obj_list(void) if (ret != EFI_SUCCESS) goto out; #endif -#ifdef CONFIG_GENERATE_ACPI_TABLE - ret = efi_acpi_register(); - if (ret != EFI_SUCCESS) - goto out; -#endif + if (IS_ENABLED(CONFIG_ACPI)) { + ret = efi_acpi_register(); + if (ret != EFI_SUCCESS) + goto out; + } #ifdef CONFIG_GENERATE_SMBIOS_TABLE ret = efi_smbios_register(); if (ret != EFI_SUCCESS)
On 9/20/23 05:00, Simon Glass wrote:
It is not always the case that U-Boot builds the ACPI tables itself. For example, when booting from coreboot, the ACPI tables are built by coreboot.
Correct the Makefile condition so that U-Boot can pass on tables built by a previous firmware stage.
Tidy up the installation-condition code while we are here.
Signed-off-by: Simon Glass sjg@chromium.org Reviewed-by: Ilias Apalodimas ilias.apalodimas@linaro.org Reviewed-by: Bin Meng bmeng.cn@gmail.com
(no changes since v2)
Changes in v2:
Add new patch
lib/efi_loader/Makefile | 2 +- lib/efi_loader/efi_setup.c | 10 +++++----- 2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile index 1a8c8d7cab5c..0eb748ff1a59 100644 --- a/lib/efi_loader/Makefile +++ b/lib/efi_loader/Makefile @@ -78,7 +78,7 @@ obj-$(CONFIG_EFI_ESRT) += efi_esrt.o obj-$(CONFIG_VIDEO) += efi_gop.o obj-$(CONFIG_BLK) += efi_disk.o obj-$(CONFIG_NETDEVICES) += efi_net.o -obj-$(CONFIG_GENERATE_ACPI_TABLE) += efi_acpi.o +obj-$(CONFIG_ACPI) += efi_acpi.o
This change merged as 53e8e6f98679 ("efi: x86: Correct the condition for installing ACPI tables") looks wrong:
For QEMU with CONFIG_ACPI=y and CONFIG_GENERATE_ACPI=n I get
EFI using ACPI tables at 0 Error: Cannot initialize UEFI sub-system, r = 14
Device-trees are only suppressed in the bootefi command if CONFIG_GENERATE_ACPI=y.
Currently CONFIG_ACPI=y only indicates that ACPI libraries are built. It does not indicate that ACPI tables exist on the platform.
Best regards
Heinrich
obj-$(CONFIG_GENERATE_SMBIOS_TABLE) += efi_smbios.o obj-$(CONFIG_EFI_RNG_PROTOCOL) += efi_rng.o obj-$(CONFIG_EFI_TCG2_PROTOCOL) += efi_tcg2.o diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c index 58d4e1340233..ad719afd6328 100644 --- a/lib/efi_loader/efi_setup.c +++ b/lib/efi_loader/efi_setup.c @@ -321,11 +321,11 @@ efi_status_t efi_init_obj_list(void) if (ret != EFI_SUCCESS) goto out; #endif -#ifdef CONFIG_GENERATE_ACPI_TABLE
- ret = efi_acpi_register();
- if (ret != EFI_SUCCESS)
goto out;-#endif
- if (IS_ENABLED(CONFIG_ACPI)) {
ret = efi_acpi_register();if (ret != EFI_SUCCESS)goto out;- } #ifdef CONFIG_GENERATE_SMBIOS_TABLE ret = efi_smbios_register(); if (ret != EFI_SUCCESS)
Hi Heinrich,
On Wed, 15 Nov 2023 at 04:09, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 9/20/23 05:00, Simon Glass wrote:
It is not always the case that U-Boot builds the ACPI tables itself. For example, when booting from coreboot, the ACPI tables are built by coreboot.
Correct the Makefile condition so that U-Boot can pass on tables built by a previous firmware stage.
Tidy up the installation-condition code while we are here.
Signed-off-by: Simon Glass sjg@chromium.org Reviewed-by: Ilias Apalodimas ilias.apalodimas@linaro.org Reviewed-by: Bin Meng bmeng.cn@gmail.com
(no changes since v2)
Changes in v2:
Add new patch
lib/efi_loader/Makefile | 2 +- lib/efi_loader/efi_setup.c | 10 +++++----- 2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile index 1a8c8d7cab5c..0eb748ff1a59 100644 --- a/lib/efi_loader/Makefile +++ b/lib/efi_loader/Makefile @@ -78,7 +78,7 @@ obj-$(CONFIG_EFI_ESRT) += efi_esrt.o obj-$(CONFIG_VIDEO) += efi_gop.o obj-$(CONFIG_BLK) += efi_disk.o obj-$(CONFIG_NETDEVICES) += efi_net.o -obj-$(CONFIG_GENERATE_ACPI_TABLE) += efi_acpi.o +obj-$(CONFIG_ACPI) += efi_acpi.o
This change merged as 53e8e6f98679 ("efi: x86: Correct the condition for installing ACPI tables") looks wrong:
For QEMU with CONFIG_ACPI=y and CONFIG_GENERATE_ACPI=n I get
EFI using ACPI tables at 0 Error: Cannot initialize UEFI sub-system, r = 14Device-trees are only suppressed in the bootefi command if CONFIG_GENERATE_ACPI=y.
Currently CONFIG_ACPI=y only indicates that ACPI libraries are built. It does not indicate that ACPI tables exist on the platform.
Similarly, neither does GENERATE_ACPI
Perhaps we should also check for tables being present?
if (IS_ENABLED(CONFIG_ACPI) && gd_acpi_start()) {
?
Best regards
Heinrich
obj-$(CONFIG_GENERATE_SMBIOS_TABLE) += efi_smbios.o obj-$(CONFIG_EFI_RNG_PROTOCOL) += efi_rng.o obj-$(CONFIG_EFI_TCG2_PROTOCOL) += efi_tcg2.o diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c index 58d4e1340233..ad719afd6328 100644 --- a/lib/efi_loader/efi_setup.c +++ b/lib/efi_loader/efi_setup.c @@ -321,11 +321,11 @@ efi_status_t efi_init_obj_list(void) if (ret != EFI_SUCCESS) goto out; #endif -#ifdef CONFIG_GENERATE_ACPI_TABLE
ret = efi_acpi_register();if (ret != EFI_SUCCESS)goto out;-#endif
if (IS_ENABLED(CONFIG_ACPI)) {ret = efi_acpi_register();if (ret != EFI_SUCCESS)goto out;}
Regards, Simon
When booted from coreboot, U-Boot does not build the SMBIOS tables, but it should still pass them on to the OS. Add a new option which indicates whether SMBIOS tables are present, however they were built.
Flip the ordering so that the dependency is listed first, which is less confusing.
Adjust GENERATE_SMBIOS_TABLE to depend on this new symbol.
Signed-off-by: Simon Glass sjg@chromium.org Reviewed-by: Heinrich Schuchardt xypron.glpk@gmx.de Reviewed-by: Bin Meng bmeng.cn@gmail.com ---
(no changes since v3)
Changes in v3: - Allow SMBIOS if EFI_LOADER is enabled - Reword the help
Changes in v2: - Add new patch
lib/Kconfig | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/lib/Kconfig b/lib/Kconfig index 7edaeebfdaf5..6b5389f3a87d 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -975,8 +975,8 @@ config BLOBLIST_TABLES
config GENERATE_SMBIOS_TABLE bool "Generate an SMBIOS (System Management BIOS) table" + depends on SMBIOS default y - depends on X86 || EFI_LOADER help The System Management BIOS (SMBIOS) specification addresses how motherboard and system vendors present management information about @@ -1045,6 +1045,19 @@ config SPL_OID_REGISTRY unambiguous persistent name (https://en.wikipedia.org/wiki/Object_identifier). Enable fast lookup object identifier registry in the SPL.
+config SMBIOS + bool "SMBIOS support" + depends on X86 || EFI_LOADER + default y + help + Indicates that this platform can support System Management BIOS + (SMBIOS) tables. These provide various pieces of information about + the board, such as the manufacturer and the model name. + + See GENERATE_SMBIOS_TABLE which controls whether U-Boot actually + creates these tables, rather than them coming from a previous firmware + stage. + config SMBIOS_PARSER bool "SMBIOS parser" help
When 'usb stop' is run, doing 'bootflow scan' does not run the USB hunter again so does not see any devices. Fix this by telling bootstd about the state of USB.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
boot/bootdev-uclass.c | 27 +++++++++++++++++++++++++++ drivers/usb/host/usb-uclass.c | 8 ++++++++ include/bootdev.h | 9 +++++++++ 3 files changed, 44 insertions(+)
diff --git a/boot/bootdev-uclass.c b/boot/bootdev-uclass.c index 69506e3865fc..974ddee5d2fa 100644 --- a/boot/bootdev-uclass.c +++ b/boot/bootdev-uclass.c @@ -830,6 +830,33 @@ int bootdev_hunt(const char *spec, bool show) return result; }
+int bootdev_unhunt(enum uclass_id id) +{ + struct bootdev_hunter *start; + int n_ent, i; + + start = ll_entry_start(struct bootdev_hunter, bootdev_hunter); + n_ent = ll_entry_count(struct bootdev_hunter, bootdev_hunter); + for (i = 0; i < n_ent; i++) { + struct bootdev_hunter *info = start + i; + + if (info->uclass == id) { + struct bootstd_priv *std; + int ret; + + ret = bootstd_get_priv(&std); + if (ret) + return log_msg_ret("std", ret); + if (!(std->hunters_used & BIT(i))) + return -EALREADY; + std->hunters_used &= ~BIT(i); + return 0; + } + } + + return -ENOENT; +} + int bootdev_hunt_prio(enum bootdev_prio_t prio, bool show) { struct bootdev_hunter *start; diff --git a/drivers/usb/host/usb-uclass.c b/drivers/usb/host/usb-uclass.c index e5fe949f254c..27e172a4fe5b 100644 --- a/drivers/usb/host/usb-uclass.c +++ b/drivers/usb/host/usb-uclass.c @@ -9,6 +9,7 @@ #define LOG_CATEGORY UCLASS_USB
#include <common.h> +#include <bootdev.h> #include <dm.h> #include <errno.h> #include <log.h> @@ -208,6 +209,13 @@ int usb_stop(void) #ifdef CONFIG_USB_STORAGE usb_stor_reset(); #endif + if (IS_ENABLED(CONFIG_BOOTSTD)) { + int ret; + + ret = bootdev_unhunt(UCLASS_USB); + if (IS_ENABLED(CONFIG_BOOTSTD_FULL) && ret && ret != -EALREADY) + printf("failed to unhunt USB (err=%dE)\n", ret); + } uc_priv->companion_device_count = 0; usb_started = 0;
diff --git a/include/bootdev.h b/include/bootdev.h index 848233187f87..b079a91b5b7f 100644 --- a/include/bootdev.h +++ b/include/bootdev.h @@ -320,6 +320,15 @@ int bootdev_hunt(const char *spec, bool show); */ int bootdev_hunt_prio(enum bootdev_prio_t prio, bool show);
+/** + * bootdev_unhunt() - Mark a device as needing to be hunted again + * + * @id: uclass ID to update + * Return: 0 if done, -EALREADY if already in this state, -ENOENT if no hunter + * found for that uclass + */ +int bootdev_unhunt(enum uclass_id id); + /** * bootdev_hunt_and_find_by_label() - Hunt for bootdevs by label *
Remember where these end up so that we can pass this information on to the EFI layer.
Signed-off-by: Simon Glass sjg@chromium.org Reviewed-by: Bin Meng bmeng.cn@gmail.com ---
(no changes since v4)
Changes in v4: - Fix arm and riscv
Changes in v2: - Add new patch
arch/arm/include/asm/global_data.h | 3 +++ arch/riscv/include/asm/global_data.h | 3 +++ arch/sandbox/include/asm/global_data.h | 1 + arch/x86/include/asm/global_data.h | 1 + arch/x86/lib/tables.c | 3 +++ include/asm-generic/global_data.h | 8 ++++++++ 6 files changed, 19 insertions(+)
diff --git a/arch/arm/include/asm/global_data.h b/arch/arm/include/asm/global_data.h index 2a222c53882a..b385bae02669 100644 --- a/arch/arm/include/asm/global_data.h +++ b/arch/arm/include/asm/global_data.h @@ -102,6 +102,9 @@ struct arch_global_data { #ifdef CONFIG_ARCH_IMX8ULP bool m33_handshake_done; #endif +#ifdef CONFIG_SMBIOS + ulong smbios_start; /* Start address of SMBIOS table */ +#endif };
#include <asm-generic/global_data.h> diff --git a/arch/riscv/include/asm/global_data.h b/arch/riscv/include/asm/global_data.h index 9d97517e124c..937fa4d15446 100644 --- a/arch/riscv/include/asm/global_data.h +++ b/arch/riscv/include/asm/global_data.h @@ -32,6 +32,9 @@ struct arch_global_data { ulong available_harts; #endif #endif +#ifdef CONFIG_SMBIOS + ulong smbios_start; /* Start address of SMBIOS table */ +#endif };
#include <asm-generic/global_data.h> diff --git a/arch/sandbox/include/asm/global_data.h b/arch/sandbox/include/asm/global_data.h index f0ab3ba5c146..c6977735029d 100644 --- a/arch/sandbox/include/asm/global_data.h +++ b/arch/sandbox/include/asm/global_data.h @@ -17,6 +17,7 @@ struct arch_global_data { ulong table_end; /* End address of x86 tables */ ulong table_start_high; /* Start address of high x86 tables */ ulong table_end_high; /* End address of high x86 tables */ + ulong smbios_start; /* Start address of SMBIOS table */ };
#include <asm-generic/global_data.h> diff --git a/arch/x86/include/asm/global_data.h b/arch/x86/include/asm/global_data.h index ea58259ad774..6f4a7130f1da 100644 --- a/arch/x86/include/asm/global_data.h +++ b/arch/x86/include/asm/global_data.h @@ -127,6 +127,7 @@ struct arch_global_data { ulong table_end; /* End address of x86 tables */ ulong table_start_high; /* Start address of high x86 tables */ ulong table_end_high; /* End address of high x86 tables */ + ulong smbios_start; /* Start address of SMBIOS table */ };
#endif diff --git a/arch/x86/lib/tables.c b/arch/x86/lib/tables.c index 67bc0a72aebc..5b5070f7ca57 100644 --- a/arch/x86/lib/tables.c +++ b/arch/x86/lib/tables.c @@ -97,6 +97,9 @@ int write_tables(void) int size = table->size ? : CONFIG_ROM_TABLE_SIZE; u32 rom_table_end;
+ if (!strcmp("smbios", table->name)) + gd->arch.smbios_start = rom_addr; + if (IS_ENABLED(CONFIG_BLOBLIST_TABLES) && table->tag) { if (!gd->arch.table_end) gd->arch.table_end = rom_addr; diff --git a/include/asm-generic/global_data.h b/include/asm-generic/global_data.h index 8fc205ded1a3..3421daea3632 100644 --- a/include/asm-generic/global_data.h +++ b/include/asm-generic/global_data.h @@ -552,6 +552,14 @@ static_assert(sizeof(struct global_data) == GD_SIZE); #define gd_set_acpi_start(addr) #endif
+#ifdef CONFIG_SMBIOS +#define gd_smbios_start() gd->smbios_start +#define gd_set_smbios_start(addr) gd->arch.smbios_start = addr +#else +#define gd_smbios_start() 0UL +#define gd_set_smbios_start(addr) +#endif + #if CONFIG_IS_ENABLED(MULTI_DTB_FIT) #define gd_multi_dtb_fit() gd->multi_dtb_fit #define gd_set_multi_dtb_fit(_dtb) gd->multi_dtb_fit = _dtb
U-Boot should set up the SMBIOS tables during startup, as it does on x86. Ensure that it does this correctly on non-x86 machines too, by creating an event spy for last-stage init.
Tidy up the installation-condition code while we are here.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v4)
Changes in v4: - Rewrite this to use events instead
Changes in v3: - Use log_debug() to show the message - Squash in the next patch
Changes in v2: - Add new patch
lib/Kconfig | 1 + lib/efi_loader/Makefile | 2 +- lib/efi_loader/efi_setup.c | 10 ++--- lib/efi_loader/efi_smbios.c | 72 ++++++++++++++++++++------------ test/py/tests/test_event_dump.py | 1 + 5 files changed, 54 insertions(+), 32 deletions(-)
diff --git a/lib/Kconfig b/lib/Kconfig index 6b5389f3a87d..79cf9ef0fa31 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -1049,6 +1049,7 @@ config SMBIOS bool "SMBIOS support" depends on X86 || EFI_LOADER default y + select LAST_STAGE_INIT help Indicates that this platform can support System Management BIOS (SMBIOS) tables. These provide various pieces of information about diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile index 0eb748ff1a59..8d31fc61c601 100644 --- a/lib/efi_loader/Makefile +++ b/lib/efi_loader/Makefile @@ -79,7 +79,7 @@ obj-$(CONFIG_VIDEO) += efi_gop.o obj-$(CONFIG_BLK) += efi_disk.o obj-$(CONFIG_NETDEVICES) += efi_net.o obj-$(CONFIG_ACPI) += efi_acpi.o -obj-$(CONFIG_GENERATE_SMBIOS_TABLE) += efi_smbios.o +obj-$(CONFIG_SMBIOS) += efi_smbios.o obj-$(CONFIG_EFI_RNG_PROTOCOL) += efi_rng.o obj-$(CONFIG_EFI_TCG2_PROTOCOL) += efi_tcg2.o obj-$(CONFIG_EFI_RISCV_BOOT_PROTOCOL) += efi_riscv.o diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c index ad719afd6328..e6de685e8795 100644 --- a/lib/efi_loader/efi_setup.c +++ b/lib/efi_loader/efi_setup.c @@ -326,11 +326,11 @@ efi_status_t efi_init_obj_list(void) if (ret != EFI_SUCCESS) goto out; } -#ifdef CONFIG_GENERATE_SMBIOS_TABLE - ret = efi_smbios_register(); - if (ret != EFI_SUCCESS) - goto out; -#endif + if (IS_ENABLED(CONFIG_SMBIOS)) { + ret = efi_smbios_register(); + if (ret != EFI_SUCCESS) + goto out; + } ret = efi_watchdog_register(); if (ret != EFI_SUCCESS) goto out; diff --git a/lib/efi_loader/efi_smbios.c b/lib/efi_loader/efi_smbios.c index 306c0bc54f90..48446f654d9b 100644 --- a/lib/efi_loader/efi_smbios.c +++ b/lib/efi_loader/efi_smbios.c @@ -10,8 +10,14 @@ #include <common.h> #include <efi_loader.h> #include <log.h> +#include <malloc.h> #include <mapmem.h> #include <smbios.h> +#include <linux/sizes.h> + +enum { + TABLE_SIZE = SZ_4K, +};
/* * Install the SMBIOS table as a configuration table. @@ -20,36 +26,50 @@ */ efi_status_t efi_smbios_register(void) { - /* Map within the low 32 bits, to allow for 32bit SMBIOS tables */ - u64 dmi_addr = U32_MAX; + ulong addr; efi_status_t ret; - void *dmi;
- /* Reserve 4kiB page for SMBIOS */ - ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS, - EFI_RUNTIME_SERVICES_DATA, 1, &dmi_addr); + addr = gd->arch.smbios_start; + if (!addr) { + log_err("No SMBIOS tables to install\n"); + return EFI_NOT_FOUND; + } + + /* Mark space used for tables */ + ret = efi_add_memory_map(addr, TABLE_SIZE, EFI_RUNTIME_SERVICES_DATA); + if (ret) + return ret; + + log_debug("EFI using SMBIOS tables at %lx\n", addr); + + /* Install SMBIOS information as configuration table */ + return efi_install_configuration_table(&smbios_guid, + map_sysmem(addr, 0)); +} + +static int install_smbios_table(void) +{ + ulong addr; + void *buf;
- if (ret != EFI_SUCCESS) { - /* Could not find space in lowmem, use highmem instead */ - ret = efi_allocate_pages(EFI_ALLOCATE_ANY_PAGES, - EFI_RUNTIME_SERVICES_DATA, 1, - &dmi_addr); + if (!IS_ENABLED(CONFIG_GENERATE_SMBIOS_TABLE) || IS_ENABLED(CONFIG_X86)) + return 0;
- if (ret != EFI_SUCCESS) - return ret; + /* Align the table to a 4KB boundary to keep EFI happy */ + buf = memalign(SZ_4K, TABLE_SIZE); + if (!buf) + return log_msg_ret("mem", -ENOMEM); + + addr = map_to_sysmem(buf); + if (!write_smbios_table(addr)) { + log_err("Failed to write SMBIOS table\n"); + return log_msg_ret("smbios", -EINVAL); }
- /* - * Generate SMBIOS tables - we know that efi_allocate_pages() returns - * a 4k-aligned address, so it is safe to assume that - * write_smbios_table() will write the table at that address. - */ - assert(!(dmi_addr & 0xf)); - dmi = (void *)(uintptr_t)dmi_addr; - if (write_smbios_table(map_to_sysmem(dmi))) - /* Install SMBIOS information as configuration table */ - return efi_install_configuration_table(&smbios_guid, dmi); - efi_free_pages(dmi_addr, 1); - log_err("Cannot create SMBIOS table\n"); - return EFI_SUCCESS; + /* Make a note of where we put it */ + log_debug("SMBIOS tables written to %lx\n", addr); + gd->arch.smbios_start = addr; + + return 0; } +EVENT_SPY_SIMPLE(EVT_LAST_STAGE_INIT, install_smbios_table); diff --git a/test/py/tests/test_event_dump.py b/test/py/tests/test_event_dump.py index a6df9e10e54e..e282c67335cd 100644 --- a/test/py/tests/test_event_dump.py +++ b/test/py/tests/test_event_dump.py @@ -18,6 +18,7 @@ def test_event_dump(u_boot_console): -------------------- ------------------------------ ------------------------------ EVT_FT_FIXUP bootmeth_vbe_ft_fixup .*boot/vbe_request.c:.* EVT_FT_FIXUP bootmeth_vbe_simple_ft_fixup .*boot/vbe_simple_os.c:.* +EVT_LAST_STAGE_INIT install_smbios_table .*lib/efi_loader/efi_smbios.c:.* EVT_MISC_INIT_F sandbox_early_getopt_check .*arch/sandbox/cpu/start.c:.* EVT_TEST h_adder_simple .*test/common/event.c:''' assert re.match(expect, out, re.MULTILINE) is not None
Make a note of where coreboot installed the SMBIOS tables so that we can pass this on to EFI.
Signed-off-by: Simon Glass sjg@chromium.org Reviewed-by: Bin Meng bmeng.cn@gmail.com ---
(no changes since v2)
Changes in v2: - Add new patch
arch/x86/lib/coreboot/cb_sysinfo.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/arch/x86/lib/coreboot/cb_sysinfo.c b/arch/x86/lib/coreboot/cb_sysinfo.c index dfbc80c430e1..f7fd9ea5bcbb 100644 --- a/arch/x86/lib/coreboot/cb_sysinfo.c +++ b/arch/x86/lib/coreboot/cb_sysinfo.c @@ -471,6 +471,7 @@ int get_coreboot_info(struct sysinfo_t *info) return -ENOENT; gd->arch.coreboot_table = addr; gd_set_acpi_start(map_to_sysmem(info->rsdp)); + gd_set_smbios_start(info->smbios_start); gd->flags |= GD_FLG_SKIP_LL_INIT;
return 0;
There is enough material that it makes sense to split this up into several files. Create an x86/ directory for this purpose.
Signed-off-by: Simon Glass sjg@chromium.org Reviewed-by: Bin Meng bmeng.cn@gmail.com ---
(no changes since v2)
Changes in v2: - Add new patch
doc/arch/index.rst | 2 +- doc/arch/x86/index.rst | 11 +++++++++++ doc/arch/{ => x86}/x86.rst | 6 +++--- 3 files changed, 15 insertions(+), 4 deletions(-) create mode 100644 doc/arch/x86/index.rst rename doc/arch/{ => x86}/x86.rst (99%)
diff --git a/doc/arch/index.rst b/doc/arch/index.rst index 2f916f4026c5..60c93b3b6640 100644 --- a/doc/arch/index.rst +++ b/doc/arch/index.rst @@ -15,5 +15,5 @@ Architecture-specific doc riscv sandbox/index sh - x86 + x86/index xtensa diff --git a/doc/arch/x86/index.rst b/doc/arch/x86/index.rst new file mode 100644 index 000000000000..3dc19d603d4c --- /dev/null +++ b/doc/arch/x86/index.rst @@ -0,0 +1,11 @@ +.. SPDX-License-Identifier: GPL-2.0+ */ +.. Copyright 2023 Google LLC +.. sectionauthor:: Simon Glass sjg@chromium.org + +x86 +=== + +.. toctree:: + :maxdepth: 2 + + x86 diff --git a/doc/arch/x86.rst b/doc/arch/x86/x86.rst similarity index 99% rename from doc/arch/x86.rst rename to doc/arch/x86/x86.rst index 725a1ae58639..ef6970b88a59 100644 --- a/doc/arch/x86.rst +++ b/doc/arch/x86/x86.rst @@ -695,8 +695,8 @@ to load a 'u-boot-payload.efi', see below test logs on QEMU. No controllers found Hit any key to stop autoboot: 0
-See :doc:`../develop/uefi/u-boot_on_efi` and :doc:`../develop/uefi/uefi` for -details of EFI support in U-Boot. +See :doc:`../../develop/uefi/u-boot_on_efi` and :doc:`../../develop/uefi/uefi` +for details of EFI support in U-Boot.
Chain-loading ------------- @@ -732,7 +732,7 @@ SMBIOS tables To generate SMBIOS tables in U-Boot, for use by the OS, enable the CONFIG_GENERATE_SMBIOS_TABLE option. The easiest way to provide the values to use is via the device tree. For details see -:download:`smbios.txt <../device-tree-bindings/sysinfo/smbios.txt>`. +:download:`smbios.txt <../../device-tree-bindings/sysinfo/smbios.txt>`.
TODO List ---------
Refresh the summary information so it is more up-to-date. Add links to the coreboot and slimbootloader docs.
Signed-off-by: Simon Glass sjg@chromium.org Reviewed-by: Bin Meng bmeng.cn@gmail.com ---
(no changes since v2)
Changes in v2: - Add new patch
doc/arch/x86/x86.rst | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/doc/arch/x86/x86.rst b/doc/arch/x86/x86.rst index ef6970b88a59..e75b5a73ffc0 100644 --- a/doc/arch/x86/x86.rst +++ b/doc/arch/x86/x86.rst @@ -11,9 +11,9 @@ including supported boards, build instructions, todo list, etc. Status ------ U-Boot supports running as a `coreboot`_ payload on x86. So far only Link -(Chromebook Pixel) and `QEMU`_ x86 targets have been tested, but it should -work with minimal adjustments on other x86 boards since coreboot deals with -most of the low-level details. +(Chromebook Pixel), Brya (Alder Lake Chromebook) and `QEMU`_ x86 targets have +been tested, but it should work with minimal adjustments on other x86 boards +since coreboot deals with most of the low-level details.
U-Boot is a main bootloader on Intel Edison board.
@@ -31,12 +31,14 @@ are supported: - Link (Chromebook Pixel) - Minnowboard MAX - Samus (Chromebook Pixel 2015) + - Coral (Apollo Lake Chromebooks circa 2017) - QEMU x86 (32-bit & 64-bit)
As for loading an OS, U-Boot supports directly booting a 32-bit or 64-bit Linux kernel as part of a FIT image. It also supports a compressed zImage. U-Boot supports loading an x86 VxWorks kernel. Please check README.vxworks -for more details. +for more details. Finally, U-Boot can boot Linux distributions with a UEFI +interface.
Build Instructions for U-Boot as BIOS replacement (bare mode) ------------------------------------------------------------- @@ -700,9 +702,10 @@ for details of EFI support in U-Boot.
Chain-loading ------------- -U-Boot can be chain-loaded from another bootloader, such as coreboot or -Slim Bootloader. Typically this is done by building for targets 'coreboot' or -'slimbootloader'. +U-Boot can be chain-loaded from another bootloader, such as +:doc:`../../board/coreboot/index` coreboot or +:doc:`../../board/intel/slimbootloader`. Typically this is done by building for +targets 'coreboot' or 'slimbootloader'.
For example, at present we have a 'coreboot' target but this runs very different code from the bare-metal targets, such as coral. There is very little
Move this out of the main file since for simple users it is easier to rely on standard boot.
Signed-off-by: Simon Glass sjg@chromium.org Reviewed-by: Bin Meng bmeng.cn@gmail.com ---
(no changes since v2)
Changes in v2: - Add new patch
doc/arch/x86/index.rst | 1 + doc/arch/x86/manual_boot.rst | 276 +++++++++++++++++++++++++++++++++++ doc/arch/x86/x86.rst | 272 +--------------------------------- 3 files changed, 280 insertions(+), 269 deletions(-) create mode 100644 doc/arch/x86/manual_boot.rst
diff --git a/doc/arch/x86/index.rst b/doc/arch/x86/index.rst index 3dc19d603d4c..69db0a5d6489 100644 --- a/doc/arch/x86/index.rst +++ b/doc/arch/x86/index.rst @@ -9,3 +9,4 @@ x86 :maxdepth: 2
x86 + manual_boot diff --git a/doc/arch/x86/manual_boot.rst b/doc/arch/x86/manual_boot.rst new file mode 100644 index 000000000000..ec069f2c3972 --- /dev/null +++ b/doc/arch/x86/manual_boot.rst @@ -0,0 +1,276 @@ +Booting Ubuntu Manually +----------------------- + +This shows a manual approach to booting Ubuntu without standard boot or the EFI +interface. + +As an example of how to set up your boot flow with U-Boot, here are +instructions for starting Ubuntu from U-Boot. These instructions have been +tested on Minnowboard MAX with a SATA drive but are equally applicable on +other platforms and other media. There are really only four steps and it's a +very simple script, but a more detailed explanation is provided here for +completeness. + +Note: It is possible to set up U-Boot to boot automatically using syslinux. +It could also use the grub.cfg file (/efi/ubuntu/grub.cfg) to obtain the +GUID. If you figure these out, please post patches to this README. + +Firstly, you will need Ubuntu installed on an available disk. It should be +possible to make U-Boot start a USB start-up disk but for now let's assume +that you used another boot loader to install Ubuntu. + +Use the U-Boot command line to find the UUID of the partition you want to +boot. For example our disk is SCSI device 0:: + + => part list scsi 0 + + Partition Map for SCSI device 0 -- Partition Type: EFI + + Part Start LBA End LBA Name + Attributes + Type GUID + Partition GUID + 1 0x00000800 0x001007ff "" + attrs: 0x0000000000000000 + type: c12a7328-f81f-11d2-ba4b-00a0c93ec93b + guid: 9d02e8e4-4d59-408f-a9b0-fd497bc9291c + 2 0x00100800 0x037d8fff "" + attrs: 0x0000000000000000 + type: 0fc63daf-8483-4772-8e79-3d69d8477de4 + guid: 965c59ee-1822-4326-90d2-b02446050059 + 3 0x037d9000 0x03ba27ff "" + attrs: 0x0000000000000000 + type: 0657fd6d-a4ab-43c4-84e5-0933c84b4f4f + guid: 2c4282bd-1e82-4bcf-a5ff-51dedbf39f17 + => + +This shows that your SCSI disk has three partitions. The really long hex +strings are called Globally Unique Identifiers (GUIDs). You can look up the +'type' ones `here`_. On this disk the first partition is for EFI and is in +VFAT format (DOS/Windows):: + + => fatls scsi 0:1 + efi/ + + 0 file(s), 1 dir(s) + + +Partition 2 is 'Linux filesystem data' so that will be our root disk. It is +in ext2 format:: + + => ext2ls scsi 0:2 + <DIR> 4096 . + <DIR> 4096 .. + <DIR> 16384 lost+found + <DIR> 4096 boot + <DIR> 12288 etc + <DIR> 4096 media + <DIR> 4096 bin + <DIR> 4096 dev + <DIR> 4096 home + <DIR> 4096 lib + <DIR> 4096 lib64 + <DIR> 4096 mnt + <DIR> 4096 opt + <DIR> 4096 proc + <DIR> 4096 root + <DIR> 4096 run + <DIR> 12288 sbin + <DIR> 4096 srv + <DIR> 4096 sys + <DIR> 4096 tmp + <DIR> 4096 usr + <DIR> 4096 var + <SYM> 33 initrd.img + <SYM> 30 vmlinuz + <DIR> 4096 cdrom + <SYM> 33 initrd.img.old + => + +and if you look in the /boot directory you will see the kernel:: + + => ext2ls scsi 0:2 /boot + <DIR> 4096 . + <DIR> 4096 .. + <DIR> 4096 efi + <DIR> 4096 grub + 3381262 System.map-3.13.0-32-generic + 1162712 abi-3.13.0-32-generic + 165611 config-3.13.0-32-generic + 176500 memtest86+.bin + 178176 memtest86+.elf + 178680 memtest86+_multiboot.bin + 5798112 vmlinuz-3.13.0-32-generic + 165762 config-3.13.0-58-generic + 1165129 abi-3.13.0-58-generic + 5823136 vmlinuz-3.13.0-58-generic + 19215259 initrd.img-3.13.0-58-generic + 3391763 System.map-3.13.0-58-generic + 5825048 vmlinuz-3.13.0-58-generic.efi.signed + 28304443 initrd.img-3.13.0-32-generic + => + +The 'vmlinuz' files contain a packaged Linux kernel. The format is a kind of +self-extracting compressed file mixed with some 'setup' configuration data. +Despite its size (uncompressed it is >10MB) this only includes a basic set of +device drivers, enough to boot on most hardware types. + +The 'initrd' files contain a RAM disk. This is something that can be loaded +into RAM and will appear to Linux like a disk. Ubuntu uses this to hold lots +of drivers for whatever hardware you might have. It is loaded before the +real root disk is accessed. + +The numbers after the end of each file are the version. Here it is Linux +version 3.13. You can find the source code for this in the Linux tree with +the tag v3.13. The '.0' allows for additional Linux releases to fix problems, +but normally this is not needed. The '-58' is used by Ubuntu. Each time they +release a new kernel they increment this number. New Ubuntu versions might +include kernel patches to fix reported bugs. Stable kernels can exist for +some years so this number can get quite high. + +The '.efi.signed' kernel is signed for EFI's secure boot. U-Boot has its own +secure boot mechanism - see `this`_ & `that`_. It cannot read .efi files +at present. + +To boot Ubuntu from U-Boot the steps are as follows: + +1. Set up the boot arguments. Use the GUID for the partition you want to boot:: + + => setenv bootargs root=/dev/disk/by-partuuid/965c59ee-1822-4326-90d2-b02446050059 ro + +Here root= tells Linux the location of its root disk. The disk is specified +by its GUID, using '/dev/disk/by-partuuid/', a Linux path to a 'directory' +containing all the GUIDs Linux has found. When it starts up, there will be a +file in that directory with this name in it. It is also possible to use a +device name here, see later. + +2. Load the kernel. Since it is an ext2/4 filesystem we can do:: + + => ext2load scsi 0:2 03000000 /boot/vmlinuz-3.13.0-58-generic + +The address 30000000 is arbitrary, but there seem to be problems with using +small addresses (sometimes Linux cannot find the ramdisk). This is 48MB into +the start of RAM (which is at 0 on x86). + +3. Load the ramdisk (to 64MB):: + + => ext2load scsi 0:2 04000000 /boot/initrd.img-3.13.0-58-generic + +4. Start up the kernel. We need to know the size of the ramdisk, but can use + a variable for that. U-Boot sets 'filesize' to the size of the last file it + loaded:: + + => zboot 03000000 0 04000000 ${filesize} + +Type 'help zboot' if you want to see what the arguments are. U-Boot on x86 is +quite verbose when it boots a kernel. You should see these messages from +U-Boot:: + + Valid Boot Flag + Setup Size = 0x00004400 + Magic signature found + Using boot protocol version 2.0c + Linux kernel version 3.13.0-58-generic (buildd@allspice) #97-Ubuntu SMP Wed Jul 8 02:56:15 UTC 2015 + Building boot_params at 0x00090000 + Loading bzImage at address 100000 (5805728 bytes) + Magic signature found + Initial RAM disk at linear address 0x04000000, size 19215259 bytes + Kernel command line: "root=/dev/disk/by-partuuid/965c59ee-1822-4326-90d2-b02446050059 ro" + + Starting kernel ... + +U-Boot prints out some bootstage timing. This is more useful if you put the +above commands into a script since then it will be faster:: + + Timer summary in microseconds: + Mark Elapsed Stage + 0 0 reset + 241,535 241,535 board_init_r + 2,421,611 2,180,076 id=64 + 2,421,790 179 id=65 + 2,428,215 6,425 main_loop + 48,860,584 46,432,369 start_kernel + + Accumulated time: + 240,329 ahci + 1,422,704 vesa display + +Now the kernel actually starts (if you want to examine kernel boot up message on +the serial console, append "console=ttyS0,115200" to the kernel command line):: + + [ 0.000000] Initializing cgroup subsys cpuset + [ 0.000000] Initializing cgroup subsys cpu + [ 0.000000] Initializing cgroup subsys cpuacct + [ 0.000000] Linux version 3.13.0-58-generic (buildd@allspice) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #97-Ubuntu SMP Wed Jul 8 02:56:15 UTC 2015 (Ubuntu 3.13.0-58.97-generic 3.13.11-ckt22) + [ 0.000000] Command line: root=/dev/disk/by-partuuid/965c59ee-1822-4326-90d2-b02446050059 ro console=ttyS0,115200 + +It continues for a long time. Along the way you will see it pick up your +ramdisk:: + + [ 0.000000] RAMDISK: [mem 0x04000000-0x05253fff] + ... + [ 0.788540] Trying to unpack rootfs image as initramfs... + [ 1.540111] Freeing initrd memory: 18768K (ffff880004000000 - ffff880005254000) + ... + +Later it actually starts using it:: + + Begin: Running /scripts/local-premount ... done. + +You should also see your boot disk turn up:: + + [ 4.357243] scsi 1:0:0:0: Direct-Access ATA ADATA SP310 5.2 PQ: 0 ANSI: 5 + [ 4.366860] sd 1:0:0:0: [sda] 62533296 512-byte logical blocks: (32.0 GB/29.8 GiB) + [ 4.375677] sd 1:0:0:0: Attached scsi generic sg0 type 0 + [ 4.381859] sd 1:0:0:0: [sda] Write Protect is off + [ 4.387452] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA + [ 4.399535] sda: sda1 sda2 sda3 + +Linux has found the three partitions (sda1-3). Mercifully it doesn't print out +the GUIDs. In step 1 above we could have used:: + + setenv bootargs root=/dev/sda2 ro + +instead of the GUID. However if you add another drive to your board the +numbering may change whereas the GUIDs will not. So if your boot partition +becomes sdb2, it will still boot. For embedded systems where you just want to +boot the first disk, you have that option. + +The last thing you will see on the console is mention of plymouth (which +displays the Ubuntu start-up screen) and a lot of 'Starting' messages:: + + * Starting Mount filesystems on boot [ OK ] + +After a pause you should see a login screen on your display and you are done. + +If you want to put this in a script you can use something like this:: + + setenv bootargs root=UUID=b2aaf743-0418-4d90-94cc-3e6108d7d968 ro + setenv boot zboot 03000000 0 04000000 ${filesize} + setenv bootcmd "ext2load scsi 0:2 03000000 /boot/vmlinuz-3.13.0-58-generic; ext2load scsi 0:2 04000000 /boot/initrd.img-3.13.0-58-generic; run boot" + saveenv + +The \ is to tell the shell not to evaluate ${filesize} as part of the setenv +command. + +You can also bake this behaviour into your build by hard-coding the +environment variables if you add this to minnowmax.h: + +.. code-block:: c + + #undef CONFIG_BOOTCOMMAND + #define CONFIG_BOOTCOMMAND \ + "ext2load scsi 0:2 03000000 /boot/vmlinuz-3.13.0-58-generic; " \ + "ext2load scsi 0:2 04000000 /boot/initrd.img-3.13.0-58-generic; " \ + "run boot" + + #undef CFG_EXTRA_ENV_SETTINGS + #define CFG_EXTRA_ENV_SETTINGS "boot=zboot 03000000 0 04000000 ${filesize}" + +and change CONFIG_BOOTARGS value in configs/minnowmax_defconfig to:: + + CONFIG_BOOTARGS="root=/dev/sda2 ro" + +.. _here: https://en.wikipedia.org/wiki/GUID_Partition_Table +.. _this: http://events.linuxfoundation.org/sites/events/files/slides/chromeos_and_diy... +.. _that: http://events.linuxfoundation.org/sites/events/files/slides/elce-2014.pdf diff --git a/doc/arch/x86/x86.rst b/doc/arch/x86/x86.rst index e75b5a73ffc0..c435225da4eb 100644 --- a/doc/arch/x86/x86.rst +++ b/doc/arch/x86/x86.rst @@ -97,272 +97,9 @@ mtrr
Booting Ubuntu -------------- -As an example of how to set up your boot flow with U-Boot, here are -instructions for starting Ubuntu from U-Boot. These instructions have been -tested on Minnowboard MAX with a SATA drive but are equally applicable on -other platforms and other media. There are really only four steps and it's a -very simple script, but a more detailed explanation is provided here for -completeness. - -Note: It is possible to set up U-Boot to boot automatically using syslinux. -It could also use the grub.cfg file (/efi/ubuntu/grub.cfg) to obtain the -GUID. If you figure these out, please post patches to this README. - -Firstly, you will need Ubuntu installed on an available disk. It should be -possible to make U-Boot start a USB start-up disk but for now let's assume -that you used another boot loader to install Ubuntu. - -Use the U-Boot command line to find the UUID of the partition you want to -boot. For example our disk is SCSI device 0:: - - => part list scsi 0 - - Partition Map for SCSI device 0 -- Partition Type: EFI - - Part Start LBA End LBA Name - Attributes - Type GUID - Partition GUID - 1 0x00000800 0x001007ff "" - attrs: 0x0000000000000000 - type: c12a7328-f81f-11d2-ba4b-00a0c93ec93b - guid: 9d02e8e4-4d59-408f-a9b0-fd497bc9291c - 2 0x00100800 0x037d8fff "" - attrs: 0x0000000000000000 - type: 0fc63daf-8483-4772-8e79-3d69d8477de4 - guid: 965c59ee-1822-4326-90d2-b02446050059 - 3 0x037d9000 0x03ba27ff "" - attrs: 0x0000000000000000 - type: 0657fd6d-a4ab-43c4-84e5-0933c84b4f4f - guid: 2c4282bd-1e82-4bcf-a5ff-51dedbf39f17 - => - -This shows that your SCSI disk has three partitions. The really long hex -strings are called Globally Unique Identifiers (GUIDs). You can look up the -'type' ones `here`_. On this disk the first partition is for EFI and is in -VFAT format (DOS/Windows):: - - => fatls scsi 0:1 - efi/ - - 0 file(s), 1 dir(s) - - -Partition 2 is 'Linux filesystem data' so that will be our root disk. It is -in ext2 format:: - - => ext2ls scsi 0:2 - <DIR> 4096 . - <DIR> 4096 .. - <DIR> 16384 lost+found - <DIR> 4096 boot - <DIR> 12288 etc - <DIR> 4096 media - <DIR> 4096 bin - <DIR> 4096 dev - <DIR> 4096 home - <DIR> 4096 lib - <DIR> 4096 lib64 - <DIR> 4096 mnt - <DIR> 4096 opt - <DIR> 4096 proc - <DIR> 4096 root - <DIR> 4096 run - <DIR> 12288 sbin - <DIR> 4096 srv - <DIR> 4096 sys - <DIR> 4096 tmp - <DIR> 4096 usr - <DIR> 4096 var - <SYM> 33 initrd.img - <SYM> 30 vmlinuz - <DIR> 4096 cdrom - <SYM> 33 initrd.img.old - => - -and if you look in the /boot directory you will see the kernel:: - - => ext2ls scsi 0:2 /boot - <DIR> 4096 . - <DIR> 4096 .. - <DIR> 4096 efi - <DIR> 4096 grub - 3381262 System.map-3.13.0-32-generic - 1162712 abi-3.13.0-32-generic - 165611 config-3.13.0-32-generic - 176500 memtest86+.bin - 178176 memtest86+.elf - 178680 memtest86+_multiboot.bin - 5798112 vmlinuz-3.13.0-32-generic - 165762 config-3.13.0-58-generic - 1165129 abi-3.13.0-58-generic - 5823136 vmlinuz-3.13.0-58-generic - 19215259 initrd.img-3.13.0-58-generic - 3391763 System.map-3.13.0-58-generic - 5825048 vmlinuz-3.13.0-58-generic.efi.signed - 28304443 initrd.img-3.13.0-32-generic - => - -The 'vmlinuz' files contain a packaged Linux kernel. The format is a kind of -self-extracting compressed file mixed with some 'setup' configuration data. -Despite its size (uncompressed it is >10MB) this only includes a basic set of -device drivers, enough to boot on most hardware types. - -The 'initrd' files contain a RAM disk. This is something that can be loaded -into RAM and will appear to Linux like a disk. Ubuntu uses this to hold lots -of drivers for whatever hardware you might have. It is loaded before the -real root disk is accessed. - -The numbers after the end of each file are the version. Here it is Linux -version 3.13. You can find the source code for this in the Linux tree with -the tag v3.13. The '.0' allows for additional Linux releases to fix problems, -but normally this is not needed. The '-58' is used by Ubuntu. Each time they -release a new kernel they increment this number. New Ubuntu versions might -include kernel patches to fix reported bugs. Stable kernels can exist for -some years so this number can get quite high. - -The '.efi.signed' kernel is signed for EFI's secure boot. U-Boot has its own -secure boot mechanism - see `this`_ & `that`_. It cannot read .efi files -at present. - -To boot Ubuntu from U-Boot the steps are as follows: - -1. Set up the boot arguments. Use the GUID for the partition you want to boot:: - - => setenv bootargs root=/dev/disk/by-partuuid/965c59ee-1822-4326-90d2-b02446050059 ro - -Here root= tells Linux the location of its root disk. The disk is specified -by its GUID, using '/dev/disk/by-partuuid/', a Linux path to a 'directory' -containing all the GUIDs Linux has found. When it starts up, there will be a -file in that directory with this name in it. It is also possible to use a -device name here, see later. - -2. Load the kernel. Since it is an ext2/4 filesystem we can do:: - - => ext2load scsi 0:2 03000000 /boot/vmlinuz-3.13.0-58-generic - -The address 30000000 is arbitrary, but there seem to be problems with using -small addresses (sometimes Linux cannot find the ramdisk). This is 48MB into -the start of RAM (which is at 0 on x86). - -3. Load the ramdisk (to 64MB):: - - => ext2load scsi 0:2 04000000 /boot/initrd.img-3.13.0-58-generic - -4. Start up the kernel. We need to know the size of the ramdisk, but can use - a variable for that. U-Boot sets 'filesize' to the size of the last file it - loaded:: - - => zboot 03000000 0 04000000 ${filesize} - -Type 'help zboot' if you want to see what the arguments are. U-Boot on x86 is -quite verbose when it boots a kernel. You should see these messages from -U-Boot:: - - Valid Boot Flag - Setup Size = 0x00004400 - Magic signature found - Using boot protocol version 2.0c - Linux kernel version 3.13.0-58-generic (buildd@allspice) #97-Ubuntu SMP Wed Jul 8 02:56:15 UTC 2015 - Building boot_params at 0x00090000 - Loading bzImage at address 100000 (5805728 bytes) - Magic signature found - Initial RAM disk at linear address 0x04000000, size 19215259 bytes - Kernel command line: "root=/dev/disk/by-partuuid/965c59ee-1822-4326-90d2-b02446050059 ro" - - Starting kernel ... - -U-Boot prints out some bootstage timing. This is more useful if you put the -above commands into a script since then it will be faster:: - - Timer summary in microseconds: - Mark Elapsed Stage - 0 0 reset - 241,535 241,535 board_init_r - 2,421,611 2,180,076 id=64 - 2,421,790 179 id=65 - 2,428,215 6,425 main_loop - 48,860,584 46,432,369 start_kernel - - Accumulated time: - 240,329 ahci - 1,422,704 vesa display - -Now the kernel actually starts (if you want to examine kernel boot up message on -the serial console, append "console=ttyS0,115200" to the kernel command line):: - - [ 0.000000] Initializing cgroup subsys cpuset - [ 0.000000] Initializing cgroup subsys cpu - [ 0.000000] Initializing cgroup subsys cpuacct - [ 0.000000] Linux version 3.13.0-58-generic (buildd@allspice) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #97-Ubuntu SMP Wed Jul 8 02:56:15 UTC 2015 (Ubuntu 3.13.0-58.97-generic 3.13.11-ckt22) - [ 0.000000] Command line: root=/dev/disk/by-partuuid/965c59ee-1822-4326-90d2-b02446050059 ro console=ttyS0,115200 - -It continues for a long time. Along the way you will see it pick up your -ramdisk:: - - [ 0.000000] RAMDISK: [mem 0x04000000-0x05253fff] - ... - [ 0.788540] Trying to unpack rootfs image as initramfs... - [ 1.540111] Freeing initrd memory: 18768K (ffff880004000000 - ffff880005254000) - ... - -Later it actually starts using it:: - - Begin: Running /scripts/local-premount ... done. - -You should also see your boot disk turn up:: - - [ 4.357243] scsi 1:0:0:0: Direct-Access ATA ADATA SP310 5.2 PQ: 0 ANSI: 5 - [ 4.366860] sd 1:0:0:0: [sda] 62533296 512-byte logical blocks: (32.0 GB/29.8 GiB) - [ 4.375677] sd 1:0:0:0: Attached scsi generic sg0 type 0 - [ 4.381859] sd 1:0:0:0: [sda] Write Protect is off - [ 4.387452] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA - [ 4.399535] sda: sda1 sda2 sda3 - -Linux has found the three partitions (sda1-3). Mercifully it doesn't print out -the GUIDs. In step 1 above we could have used:: - - setenv bootargs root=/dev/sda2 ro - -instead of the GUID. However if you add another drive to your board the -numbering may change whereas the GUIDs will not. So if your boot partition -becomes sdb2, it will still boot. For embedded systems where you just want to -boot the first disk, you have that option. - -The last thing you will see on the console is mention of plymouth (which -displays the Ubuntu start-up screen) and a lot of 'Starting' messages:: - - * Starting Mount filesystems on boot [ OK ] - -After a pause you should see a login screen on your display and you are done. - -If you want to put this in a script you can use something like this:: - - setenv bootargs root=UUID=b2aaf743-0418-4d90-94cc-3e6108d7d968 ro - setenv boot zboot 03000000 0 04000000 ${filesize} - setenv bootcmd "ext2load scsi 0:2 03000000 /boot/vmlinuz-3.13.0-58-generic; ext2load scsi 0:2 04000000 /boot/initrd.img-3.13.0-58-generic; run boot" - saveenv - -The \ is to tell the shell not to evaluate ${filesize} as part of the setenv -command. - -You can also bake this behaviour into your build by hard-coding the -environment variables if you add this to minnowmax.h: - -.. code-block:: c - - #undef CONFIG_BOOTCOMMAND - #define CONFIG_BOOTCOMMAND \ - "ext2load scsi 0:2 03000000 /boot/vmlinuz-3.13.0-58-generic; " \ - "ext2load scsi 0:2 04000000 /boot/initrd.img-3.13.0-58-generic; " \ - "run boot" - - #undef CFG_EXTRA_ENV_SETTINGS - #define CFG_EXTRA_ENV_SETTINGS "boot=zboot 03000000 0 04000000 ${filesize}" - -and change CONFIG_BOOTARGS value in configs/minnowmax_defconfig to:: - - CONFIG_BOOTARGS="root=/dev/sda2 ro" +Typically U-Boot boots distributions automatically so long an `CONFIG_BOOTSTD`, +`CONFIG_BOOTSTD_DEFAULTS` and `CONFIG_EFI_LOADER` are enabled. See +:doc:`manual_boot` for how to do this manually.
Test with SeaBIOS ----------------- @@ -747,8 +484,5 @@ TODO List .. _microcode: http://en.wikipedia.org/wiki/Microcode .. _SFI: http://simplefirmware.org .. _MP: http://www.intel.com/design/archives/processors/pro/docs/242016.htm -.. _here: https://en.wikipedia.org/wiki/GUID_Partition_Table -.. _this: http://events.linuxfoundation.org/sites/events/files/slides/chromeos_and_diy... -.. _that: http://events.linuxfoundation.org/sites/events/files/slides/elce-2014.pdf .. _SeaBIOS: http://www.seabios.org/SeaBIOS .. _ACPI: http://www.acpi.info
Add a little more detail as to why coreboot64 is preferred for booting Linux distros.
Signed-off-by: Simon Glass sjg@chromium.org Reviewed-by: Bin Meng bmeng.cn@gmail.com ---
(no changes since v2)
Changes in v2: - Add new patch
doc/board/coreboot/coreboot.rst | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/doc/board/coreboot/coreboot.rst b/doc/board/coreboot/coreboot.rst index 3ef563b71dc9..10ef78bb5ada 100644 --- a/doc/board/coreboot/coreboot.rst +++ b/doc/board/coreboot/coreboot.rst @@ -82,6 +82,8 @@ build in `$CBDIR`:: -device ahci,id=ahci \ -device ide-hd,drive=disk,bus=ahci.0 \
+This allows booting and installing various distros, many of which are +64-bit-only, so cannot work with the 32-bit 'coreboot' build.
CBFS access -----------
Hi Simon,
On Wed, Sep 20, 2023 at 11:00 AM Simon Glass sjg@chromium.org wrote:
This little series fixes various bugs and annoyances in coreboot and coreboot64.
With this both coreboot and coreboot64 start up and work reasonably well on Brya (x86 Chromebook) and U-Boot can boot common Linux distros.
- Make coreboot64 debug UART start reliably
- Avoid the long USB-init delay on startup
- Correct the timer speed on coreboo64
- Fix a bootstd cros bug (will likely be squashed into another patch)
- Fix the terribly slow console scrolling
With v2 I have also brought in some lost x86 patches so they are all in one series.
Changes in v5:
- Use 'lzma' instead of 'LZMA'
- Drop unwanted space
- Correct 'teechnique' typo in commit message
- Make use of the uSE_PREBOOT mechanism
Changes in v4:
- Fix arm and riscv
- Rewrite this to use events instead
Changes in v3:
- Allow SMBIOS if EFI_LOADER is enabled
- Reword the help
- Use log_debug() to show the message
- Squash in the next patch
Changes in v2:
- Update the malloc size too
- Add new patch
- Add new patch
- Add new patch
- Add new patch
- Add new patch
- Add new patch
- Add new patch
- Add new patch
- Add new patch
Simon Glass (20): x86: coreboot: Add IDE and SATA x86: coreboot: Enable standard boot x86: coreboot: Rearrange arch_cpu_init() x86: Set the CPU vendor in SPL x86: Allow APCI in SPL x86: coreboot: Look for DBG2 UART in SPL too x86: coreboot: Enable CONFIG_SYS_NS16550_MEM32 x86: coreboot: Drop USB init on startup x86: coreboot: Align options between coreboot and coreboot64 x86: coreboot: Enable VIDEO_COPY efi: x86: Correct the condition for installing ACPI tables x86: smbios: Add a Kconfig indicating SMBIOS-table presence bootstd: Keep track of use of usb stop Record the position of the SMBIOS tables efi: Use the installed SMBIOS tables x86: coreboot: Record the position of the SMBIOS tables x86: doc: Move into its own directory x86: doc: Update summaries and add links x86: doc: Split out manual booting into its own file x86: doc: coreboot: Mention 64-bit Linux distros
Patch #8 needs to respin to address PREBOOT comment Path#18 does not apply.
Patch#13, 15 v6 version are applied.
Reset patches in this series are applied to u-boot-x86/next, thanks!
The reset
Regards, Bin
Hi Simon,
On Thu, Sep 21, 2023 at 1:27 PM Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Wed, Sep 20, 2023 at 11:00 AM Simon Glass sjg@chromium.org wrote:
This little series fixes various bugs and annoyances in coreboot and coreboot64.
With this both coreboot and coreboot64 start up and work reasonably well on Brya (x86 Chromebook) and U-Boot can boot common Linux distros.
- Make coreboot64 debug UART start reliably
- Avoid the long USB-init delay on startup
- Correct the timer speed on coreboo64
- Fix a bootstd cros bug (will likely be squashed into another patch)
- Fix the terribly slow console scrolling
With v2 I have also brought in some lost x86 patches so they are all in one series.
Changes in v5:
- Use 'lzma' instead of 'LZMA'
- Drop unwanted space
- Correct 'teechnique' typo in commit message
- Make use of the uSE_PREBOOT mechanism
Changes in v4:
- Fix arm and riscv
- Rewrite this to use events instead
Changes in v3:
- Allow SMBIOS if EFI_LOADER is enabled
- Reword the help
- Use log_debug() to show the message
- Squash in the next patch
Changes in v2:
- Update the malloc size too
- Add new patch
- Add new patch
- Add new patch
- Add new patch
- Add new patch
- Add new patch
- Add new patch
- Add new patch
- Add new patch
Simon Glass (20): x86: coreboot: Add IDE and SATA x86: coreboot: Enable standard boot x86: coreboot: Rearrange arch_cpu_init() x86: Set the CPU vendor in SPL x86: Allow APCI in SPL x86: coreboot: Look for DBG2 UART in SPL too x86: coreboot: Enable CONFIG_SYS_NS16550_MEM32 x86: coreboot: Drop USB init on startup x86: coreboot: Align options between coreboot and coreboot64 x86: coreboot: Enable VIDEO_COPY efi: x86: Correct the condition for installing ACPI tables x86: smbios: Add a Kconfig indicating SMBIOS-table presence bootstd: Keep track of use of usb stop Record the position of the SMBIOS tables efi: Use the installed SMBIOS tables x86: coreboot: Record the position of the SMBIOS tables x86: doc: Move into its own directory x86: doc: Update summaries and add links x86: doc: Split out manual booting into its own file x86: doc: coreboot: Mention 64-bit Linux distros
Patch #8 needs to respin to address PREBOOT comment Path#18 does not apply.
Patch#13, 15 v6 version are applied.
Reset patches in this series are applied to u-boot-x86/next, thanks!
The CI still fails on u-boot-x86/next which is already rebased on origin/next. https://source.denx.de/u-boot/custodians/u-boot-x86/-/pipelines/17784
Regards, Bin
Hi Bin,
On Thu, 21 Sept 2023 at 00:31, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Thu, Sep 21, 2023 at 1:27 PM Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Wed, Sep 20, 2023 at 11:00 AM Simon Glass sjg@chromium.org wrote:
This little series fixes various bugs and annoyances in coreboot and coreboot64.
With this both coreboot and coreboot64 start up and work reasonably well on Brya (x86 Chromebook) and U-Boot can boot common Linux distros.
- Make coreboot64 debug UART start reliably
- Avoid the long USB-init delay on startup
- Correct the timer speed on coreboo64
- Fix a bootstd cros bug (will likely be squashed into another patch)
- Fix the terribly slow console scrolling
With v2 I have also brought in some lost x86 patches so they are all in one series.
Changes in v5:
- Use 'lzma' instead of 'LZMA'
- Drop unwanted space
- Correct 'teechnique' typo in commit message
- Make use of the uSE_PREBOOT mechanism
Changes in v4:
- Fix arm and riscv
- Rewrite this to use events instead
Changes in v3:
- Allow SMBIOS if EFI_LOADER is enabled
- Reword the help
- Use log_debug() to show the message
- Squash in the next patch
Changes in v2:
- Update the malloc size too
- Add new patch
- Add new patch
- Add new patch
- Add new patch
- Add new patch
- Add new patch
- Add new patch
- Add new patch
- Add new patch
Simon Glass (20): x86: coreboot: Add IDE and SATA x86: coreboot: Enable standard boot x86: coreboot: Rearrange arch_cpu_init() x86: Set the CPU vendor in SPL x86: Allow APCI in SPL x86: coreboot: Look for DBG2 UART in SPL too x86: coreboot: Enable CONFIG_SYS_NS16550_MEM32 x86: coreboot: Drop USB init on startup x86: coreboot: Align options between coreboot and coreboot64 x86: coreboot: Enable VIDEO_COPY efi: x86: Correct the condition for installing ACPI tables x86: smbios: Add a Kconfig indicating SMBIOS-table presence bootstd: Keep track of use of usb stop Record the position of the SMBIOS tables efi: Use the installed SMBIOS tables x86: coreboot: Record the position of the SMBIOS tables x86: doc: Move into its own directory x86: doc: Update summaries and add links x86: doc: Split out manual booting into its own file x86: doc: coreboot: Mention 64-bit Linux distros
Patch #8 needs to respin to address PREBOOT comment Path#18 does not apply.
Patch#13, 15 v6 version are applied.
Reset patches in this series are applied to u-boot-x86/next, thanks!
The CI still fails on u-boot-x86/next which is already rebased on origin/next. https://source.denx.de/u-boot/custodians/u-boot-x86/-/pipelines/17784
OK, I found the problem. I will include a fixup patch in v7.
Regards, Simon
participants (4)
-
Bin Meng -
Heinrich Schuchardt -
Marek Vasut -
Simon Glass