[PATCH v2 00/20] x86: efi: Fixes and improvements for coreboot

Simon Glass

18 Aug 2023 18 Aug '23

2:26 a.m.

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 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 - 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 x86: Record the position of the SMBIOS tables efi: x86: Use the installed SMBIOS tables efi: x86: Install the SMBIOS tables if present 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/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 + 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/video/coreboot.c | 12 ++ include/asm-generic/global_data.h | 8 + lib/Kconfig | 20 +- lib/efi_loader/Makefile | 4 +- lib/efi_loader/efi_setup.c | 20 +- lib/efi_loader/efi_smbios.c | 37 +--- 20 files changed, 447 insertions(+), 354 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%)

-- 2.42.0.rc1.204.g551eb34607-goog

Show replies by date

Simon Glass

18 Aug 18 Aug

2:26 a.m.

New subject: [PATCH v2 01/20] x86: coreboot: Add IDE and SATA

Add these options to permit access to more disk types.

Add some documentation as well.

Signed-off-by: Simon Glass sjg@chromium.org ---

(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 8aadaa68c279..ded0e6f2422d 100644 --- a/configs/coreboot64_defconfig +++ b/configs/coreboot64_defconfig @@ -26,6 +26,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 8e11de663819..56cc542df6c6 100644 --- a/configs/coreboot_defconfig +++ b/configs/coreboot_defconfig @@ -22,8 +22,10 @@ CONFIG_LOGF_FUNC=y CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_LAST_STAGE_INIT=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 @@ -48,6 +50,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 -------------

-- 2.42.0.rc1.204.g551eb34607-goog

Simon Glass

2:26 a.m.

New subject: [PATCH v2 02/20] x86: coreboot: Enable standard boot

Enable bootstd options and provide instructions on how to boot a linux distro using coreboot.

Signed-off-by: Simon Glass sjg@chromium.org ---

(no changes since v1)

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 ded0e6f2422d..602465175d20 100644 --- a/configs/coreboot64_defconfig +++ b/configs/coreboot64_defconfig @@ -10,40 +10,30 @@ 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_LAST_STAGE_INIT=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 56cc542df6c6..735cd6eb4c22 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..88437c27740e 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 -----------

-- 2.42.0.rc1.204.g551eb34607-goog

Simon Glass

2:26 a.m.

New subject: [PATCH v2 03/20] x86: coreboot: Rearrange arch_cpu_init()

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 ---

(no changes since v1)

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 d7eedbd7436e..a0c62cce2293 100644 --- a/arch/x86/cpu/coreboot/coreboot.c +++ b/arch/x86/cpu/coreboot/coreboot.c @@ -20,7 +20,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; @@ -28,8 +35,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)

-- 2.42.0.rc1.204.g551eb34607-goog

Simon Glass

2:26 a.m.

New subject: [PATCH v2 04/20] x86: Set the CPU vendor in SPL

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 ---

(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; }

-- 2.42.0.rc1.204.g551eb34607-goog

Simon Glass

2:26 a.m.

New subject: [PATCH v2 05/20] x86: Allow APCI in SPL

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 ---

(no changes since v1)

lib/Kconfig | 8 ++++++++ 1 file changed, 8 insertions(+)

diff --git a/lib/Kconfig b/lib/Kconfig index 07e61de5b641..a9dca5f52b5a 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

-- 2.42.0.rc1.204.g551eb34607-goog

Simon Glass

2:26 a.m.

New subject: [PATCH v2 06/20] x86: coreboot: Look for DBG2 UART in SPL too

If coreboot does not set up sysinfo for the UART, SPL currently hangs. Use the DBG2 teechnique 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 ---

(no changes since v1)

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 602465175d20..a094a7c24234 100644 --- a/configs/coreboot64_defconfig +++ b/configs/coreboot64_defconfig @@ -55,4 +55,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 a1e089962a91..01100b6d93f3 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

-- 2.42.0.rc1.204.g551eb34607-goog

Simon Glass

2:26 a.m.

New subject: [PATCH v2 07/20] x86: coreboot: Enable CONFIG_SYS_NS16550_MEM32

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 a094a7c24234..29b68d6929c7 100644 --- a/configs/coreboot64_defconfig +++ b/configs/coreboot64_defconfig @@ -52,6 +52,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 735cd6eb4c22..2961908f29cd 100644 --- a/configs/coreboot_defconfig +++ b/configs/coreboot_defconfig @@ -60,6 +60,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

-- 2.42.0.rc1.204.g551eb34607-goog

Simon Glass

2:26 a.m.

New subject: [PATCH v2 08/20] x86: coreboot: Drop USB init on startup

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.

Signed-off-by: Simon Glass sjg@chromium.org ---

(no changes since v1)

arch/x86/cpu/coreboot/coreboot.c | 4 ---- 1 file changed, 4 deletions(-)

diff --git a/arch/x86/cpu/coreboot/coreboot.c b/arch/x86/cpu/coreboot/coreboot.c index a0c62cce2293..fa3daeff8229 100644 --- a/arch/x86/cpu/coreboot/coreboot.c +++ b/arch/x86/cpu/coreboot/coreboot.c @@ -82,10 +82,6 @@ static void board_final_init(void)

int last_stage_init(void) { - /* 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;

-- 2.42.0.rc1.204.g551eb34607-goog

Simon Glass

2:26 a.m.

New subject: [PATCH v2 09/20] x86: coreboot: Align options between coreboot and coreboot64

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 ---

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 29b68d6929c7..2263554a47ce 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_LAST_STAGE_INIT=y CONFIG_SPL_NO_BSS_LIMIT=y @@ -51,10 +55,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 2961908f29cd..790b84a87bc7 100644 --- a/configs/coreboot_defconfig +++ b/configs/coreboot_defconfig @@ -25,23 +25,14 @@ CONFIG_LAST_STAGE_INIT=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

-- 2.42.0.rc1.204.g551eb34607-goog

Simon Glass

2:26 a.m.

New subject: [PATCH v2 10/20] x86: coreboot: Enable VIDEO_COPY

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 ---

(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 2263554a47ce..e5546dadcb0a 100644 --- a/configs/coreboot64_defconfig +++ b/configs/coreboot64_defconfig @@ -60,6 +60,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 790b84a87bc7..78694d635532 100644 --- a/configs/coreboot_defconfig +++ b/configs/coreboot_defconfig @@ -54,6 +54,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, };

-- 2.42.0.rc1.204.g551eb34607-goog

Simon Glass

2:26 a.m.

New subject: [PATCH v2 11/20] efi: x86: Correct the condition for installing ACPI tables

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 ---

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)

-- 2.42.0.rc1.204.g551eb34607-goog

Heinrich Schuchardt

3:35 a.m.

New subject: [PATCH v2 11/20] efi: x86: Correct the condition for installing ACPI tables

Am 18. August 2023 02:26:50 MESZ schrieb Simon Glass sjg@chromium.org:

...

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

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

Shouldn't this become CONFIG_SMBIOS?

It would help my review work if you would stop suppressing half of your patch series when sending mails.

Best regards

Heinrich

...

ret = efi_smbios_register(); if (ret != EFI_SUCCESS)

Ilias Apalodimas

8:49 a.m.

New subject: [PATCH v2 11/20] efi: x86: Correct the condition for installing ACPI tables

On Fri, 18 Aug 2023 at 04:40, Heinrich Schuchardt xypron.glpk@gmx.de wrote:

...

Am 18. August 2023 02:26:50 MESZ schrieb Simon Glass sjg@chromium.org:

...
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

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
Shouldn't this become CONFIG_SMBIOS?

This is renamed on a later patch

Reviewed-by: Ilias Apalodimas ilias.apalodimas@linaro.org

...

It would help my review work if you would stop suppressing half of your patch series when sending mails.

Best regards

Heinrich

...
  ret = efi_smbios_register();
  if (ret != EFI_SUCCESS)

Simon Glass

4:55 p.m.

New subject: [PATCH v2 11/20] efi: x86: Correct the condition for installing ACPI tables

Hi Heinrich,

On Thu, 17 Aug 2023 at 19:35, Heinrich Schuchardt xypron.glpk@gmx.de wrote:

...

Am 18. August 2023 02:26:50 MESZ schrieb Simon Glass sjg@chromium.org:

...
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

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
Shouldn't this become CONFIG_SMBIOS?

It would help my review work if you would stop suppressing half of your patch series when sending mails.

Do you mean you only receive some of the emails? If so, the whole series was emailed to you. I checked my 'sent' box and see you in each one.

If you mean something else, please let me know.

Regards, Simon

Simon Glass

2:26 a.m.

New subject: [PATCH v2 12/20] x86: smbios: Add a Kconfig indicating SMBIOS-table presence

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.

Signed-off-by: Simon Glass sjg@chromium.org ---

Changes in v2: - Add new patch

lib/Kconfig | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/lib/Kconfig b/lib/Kconfig index a9dca5f52b5a..b7bbf3f81c56 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -984,8 +984,9 @@ config BLOBLIST_TABLES

config GENERATE_SMBIOS_TABLE bool "Generate an SMBIOS (System Management BIOS) table" - default y depends on X86 || EFI_LOADER + default y + imply SMBIOS help The System Management BIOS (SMBIOS) specification addresses how motherboard and system vendors present management information about @@ -1054,6 +1055,15 @@ 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 + default y + help + Indicates that this platform can create System Management BIOS + (SMBIOS) tables. These provide various pieces of information about + the board, such as the manufacturer and the model name. + config SMBIOS_PARSER bool "SMBIOS parser" help

-- 2.42.0.rc1.204.g551eb34607-goog

Heinrich Schuchardt

3:25 a.m.

New subject: [PATCH v2 12/20] x86: smbios: Add a Kconfig indicating SMBIOS-table presence

Am 18. August 2023 02:26:51 MESZ schrieb Simon Glass sjg@chromium.org:

...

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.

Signed-off-by: Simon Glass sjg@chromium.org

Changes in v2:

Add new patch

lib/Kconfig | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/lib/Kconfig b/lib/Kconfig index a9dca5f52b5a..b7bbf3f81c56 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -984,8 +984,9 @@ config BLOBLIST_TABLES

config GENERATE_SMBIOS_TABLE bool "Generate an SMBIOS (System Management BIOS) table"

default y depends on X86 || EFI_LOADER

default y

imply SMBIOS

Is there any use case for GENERATE_SMBIOD_TABLE=y and SMBIOS=n? I would have expected 'depends on SMBIOS' here.

...

help The System Management BIOS (SMBIOS) specification addresses how motherboard and system vendors present management information about @@ -1054,6 +1055,15 @@ 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

We need SMBIOS tables on all EFI architectures.

...

default y
help

 Indicates that this platform can create System Management BIOS

This is very confusing: create and generate are just synonyms. Given this description I would not know what is the difference between the symbols.

Best regards

Heinrich

...

 (SMBIOS) tables. These provide various pieces of information about

 the board, such as the manufacturer and the model name.

config SMBIOS_PARSER bool "SMBIOS parser" help

Simon Glass

2:26 a.m.

New subject: [PATCH v2 13/20] x86: Record the position of the SMBIOS tables

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 ---

Changes in v2: - Add new patch

arch/x86/include/asm/global_data.h | 1 + arch/x86/lib/tables.c | 3 +++ include/asm-generic/global_data.h | 8 ++++++++ 3 files changed, 12 insertions(+)

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

-- 2.42.0.rc1.204.g551eb34607-goog

Simon Glass

2:26 a.m.

New subject: [PATCH v2 14/20] efi: x86: Use the installed SMBIOS tables

U-Boot sets up the SMBIOS tables during startup. Rather than creating a new set, install the existing ones. Rely on the ACPI table's memory-map record to cover the tables.

Tidy up the installation-condition code while we are here.

Signed-off-by: Simon Glass sjg@chromium.org ---

Changes in v2: - Add new patch

lib/efi_loader/efi_setup.c | 10 +++++----- lib/efi_loader/efi_smbios.c | 37 +++++++------------------------------ 2 files changed, 12 insertions(+), 35 deletions(-)

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..0e6454a8fe0b 100644 --- a/lib/efi_loader/efi_smbios.c +++ b/lib/efi_loader/efi_smbios.c @@ -20,36 +20,13 @@ */ efi_status_t efi_smbios_register(void) { - /* Map within the low 32 bits, to allow for 32bit SMBIOS tables */ - u64 dmi_addr = U32_MAX; - efi_status_t ret; - void *dmi; + ulong addr;

- /* Reserve 4kiB page for SMBIOS */ - ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS, - EFI_RUNTIME_SERVICES_DATA, 1, &dmi_addr); + /* space for all tables is marked in efi_acpi_register() */ + addr = gd->arch.smbios_start; + printf("EFI using SMBIOS tables at %lx\n", addr);

- 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 (ret != EFI_SUCCESS) - return ret; - } - - /* - * 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; + /* Install SMBIOS information as configuration table */ + return efi_install_configuration_table(&smbios_guid, + map_sysmem(addr, 0)); }

-- 2.42.0.rc1.204.g551eb34607-goog

Heinrich Schuchardt

3:14 a.m.

New subject: [PATCH v2 14/20] efi: x86: Use the installed SMBIOS tables

Am 18. August 2023 02:26:53 MESZ schrieb Simon Glass sjg@chromium.org:

...

U-Boot sets up the SMBIOS tables during startup. Rather than creating a new set, install the existing ones. Rely on the ACPI table's memory-map record to cover the tables.

Tidy up the installation-condition code while we are here.

Signed-off-by: Simon Glass sjg@chromium.org

Changes in v2:

Add new patch

lib/efi_loader/efi_setup.c | 10 +++++----- lib/efi_loader/efi_smbios.c | 37 +++++++------------------------------ 2 files changed, 12 insertions(+), 35 deletions(-)

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..0e6454a8fe0b 100644 --- a/lib/efi_loader/efi_smbios.c +++ b/lib/efi_loader/efi_smbios.c @@ -20,36 +20,13 @@ */ efi_status_t efi_smbios_register(void) {

/* Map within the low 32 bits, to allow for 32bit SMBIOS tables */

u64 dmi_addr = U32_MAX;

efi_status_t ret;

void *dmi;

ulong addr;
/* Reserve 4kiB page for SMBIOS */

ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
		 EFI_RUNTIME_SERVICES_DATA, 1, &dmi_addr);
/* space for all tables is marked in efi_acpi_register() */

addr = gd->arch.smbios_start;

printf("EFI using SMBIOS tables at %lx\n", addr);

This is should be log_debug() as typically only developers will ever need this address.

Best regards

Heinrich

...

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 (ret != EFI_SUCCESS)
	return ret;
}

/*
* 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;
/* Install SMBIOS information as configuration table */

return efi_install_configuration_table(&smbios_guid,
			       map_sysmem(addr, 0));
}

Ilias Apalodimas

8:50 a.m.

New subject: [PATCH v2 14/20] efi: x86: Use the installed SMBIOS tables

On Fri, 18 Aug 2023 at 04:19, Heinrich Schuchardt xypron.glpk@gmx.de wrote:

...

Am 18. August 2023 02:26:53 MESZ schrieb Simon Glass sjg@chromium.org:

...
U-Boot sets up the SMBIOS tables during startup. Rather than creating a new set, install the existing ones. Rely on the ACPI table's memory-map record to cover the tables.

Tidy up the installation-condition code while we are here.

Signed-off-by: Simon Glass sjg@chromium.org

Changes in v2:

Add new patch

In the ACPI changes, the makefile and code changes are in a single patch which makes more sense. Can you squash #15 in this one as well?

Thanks /Ilias

...

lib/efi_loader/efi_setup.c | 10 +++++----- lib/efi_loader/efi_smbios.c | 37 +++++++------------------------------ 2 files changed, 12 insertions(+), 35 deletions(-)

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..0e6454a8fe0b 100644 --- a/lib/efi_loader/efi_smbios.c +++ b/lib/efi_loader/efi_smbios.c @@ -20,36 +20,13 @@ */ efi_status_t efi_smbios_register(void) {
 /* Map within the low 32 bits, to allow for 32bit SMBIOS tables */
 u64 dmi_addr = U32_MAX;
 efi_status_t ret;
 void *dmi;
 ulong addr;
 /* Reserve 4kiB page for SMBIOS */
 ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
                          EFI_RUNTIME_SERVICES_DATA, 1, &dmi_addr);
 /* space for all tables is marked in efi_acpi_register() */
 addr = gd->arch.smbios_start;
 printf("EFI using SMBIOS tables at %lx\n", addr);

This is should be log_debug() as typically only developers will ever need this address.

Best regards

Heinrich

...

```
 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 (ret != EFI_SUCCESS)
```
```
                 return ret;
```
```
 }
```
```
 /*
```

  * 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;
```

 /* Install SMBIOS information as configuration table */

 return efi_install_configuration_table(&smbios_guid,

                                        map_sysmem(addr, 0));

}

Simon Glass

2:26 a.m.

New subject: [PATCH v2 15/20] efi: x86: Install the SMBIOS tables if present

When these are available in memory, whether generated by U-Boot or by an earlier firmware stage, install them.

Signed-off-by: Simon Glass sjg@chromium.org ---

Changes in v2: - Add new patch

lib/efi_loader/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

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

-- 2.42.0.rc1.204.g551eb34607-goog

Simon Glass

2:26 a.m.

New subject: [PATCH v2 16/20] x86: coreboot: Record the position of the SMBIOS tables

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 ---

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;

-- 2.42.0.rc1.204.g551eb34607-goog

Simon Glass

2:26 a.m.

New subject: [PATCH v2 17/20] x86: doc: Move into its own directory

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 ---

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 ---------

-- 2.42.0.rc1.204.g551eb34607-goog

Simon Glass

2:26 a.m.

New subject: [PATCH v2 18/20] x86: doc: Update summaries and add links

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 ---

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

-- 2.42.0.rc1.204.g551eb34607-goog

Simon Glass

2:26 a.m.

New subject: [PATCH v2 19/20] x86: doc: Split out manual booting into its own file

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 ---

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

-- 2.42.0.rc1.204.g551eb34607-goog

Simon Glass

2:26 a.m.

New subject: [PATCH v2 20/20] x86: doc: coreboot: Mention 64-bit Linux distros

Add a little more detail as to why coreboot64 is preferred for booting Linux distros.

Signed-off-by: Simon Glass sjg@chromium.org ---

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 88437c27740e..a32c3a864f90 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 -----------

-- 2.42.0.rc1.204.g551eb34607-goog

635

Age (days ago)

635

Last active (days ago)

List overview

Download

26 comments

3 participants

tags (0)

participants (3)

Heinrich Schuchardt
Ilias Apalodimas
Simon Glass