[PATCH v3 00/12] Resolve issues with booting distros on x86
This little series reprises the EFI-video fix, fixes a USB problem and enables a boot script for coreboot.
It also moves to truetype fonts for coreboot and qemu-x86, since the menus look much better and there are no strong size constraints.
With these changes it is possible to boot a Linux distro automatically with U-Boot on x86, including when U-Boot is the second-stage bootloader.
Changes in v3: - Add new patch to refactor mmc prep to allow a different scan - Add missing word 'function' in the commit message - Clear the screen before booting - Add new patch to drop unnecessary truetype operations from SPL - Add new patch to enable truetype fonts in coreboot - Add new patch to enable truetype fonts in qemu-x86 and qemu-x86_64
Changes in v2: - Rebase to -next - Add some more comments to the header file - Add fixes tag - Add new patch to add a return code to bootflow menu - Add new patch to add a coreboot boot script - Add new patch to avoid unbinding devices in use by bootflows
Simon Glass (12): efi: Correct handling of frame buffer bootstd: Refactor mmc prep to allow a different scan bootstd: Add a return code to bootflow menu x86: coreboot: Add a boot script usb: Avoid unbinding devices in use by bootflows expo: Correct background colour video: Correct setting of cursor position video: Drop unnecessary truetype operations from SPL x86: Enable SSE in 64-bit mode x86: coreboot: Enable truetype fonts x86: qemu: Expand ROM size x86: qemu: Enable truetype fonts
arch/x86/config.mk | 1 - arch/x86/cpu/x86_64/cpu.c | 11 +++++ arch/x86/dts/coreboot.dts | 10 +++++ board/emulation/qemu-x86/Kconfig | 3 +- boot/bootm.c | 2 +- boot/expo.c | 4 +- cmd/bootflow.c | 53 ++++++++++++++++++------ common/usb.c | 7 +++- configs/coreboot64_defconfig | 4 +- configs/coreboot_defconfig | 4 +- configs/qemu-x86_64_defconfig | 7 ++-- configs/qemu-x86_defconfig | 1 + doc/usage/cmd/bootflow.rst | 67 +++++++++++++++++++++++++++++++ drivers/usb/host/usb-uclass.c | 14 ++++++- drivers/video/console_truetype.c | 10 +++++ drivers/video/vidconsole-uclass.c | 15 +++---- include/usb.h | 15 ++++++- include/video.h | 9 +++-- lib/efi_loader/efi_gop.c | 12 +++--- test/boot/bootflow.c | 64 ++++++++++++++++++++++++----- 20 files changed, 264 insertions(+), 49 deletions(-)
The efi_gop driver uses private fields from the video uclass to obtain a pointer to the frame buffer. Use the platform data instead.
Check the VIDEO_COPY setting to determine which frame buffer to use. Once the next stage is running (and making use of U-Boot's EFI boot services) U-Boot does not handle copying from priv->fb to the hardware framebuffer, so we must allow EFI to write directly to the hardware framebuffer.
We could provide a function to read this, but it seems better to just document how it works. The original change ignored an explicit comment in the video.h file ("Things that are private to the uclass: don't use these in the driver") which is why this was missed when the VIDEO_COPY feature was added.
Signed-off-by: Simon Glass sjg@chromium.org Fixes: 8f661a5b662 ("efi_loader: gop: Expose fb when 32bpp") ---
(no changes since v2)
Changes in v2: - Rebase to -next - Add some more comments to the header file - Add fixes tag
include/video.h | 9 ++++++--- lib/efi_loader/efi_gop.c | 12 +++++++----- 2 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/include/video.h b/include/video.h index 5048116a3d57..4d8df9baaada 100644 --- a/include/video.h +++ b/include/video.h @@ -21,9 +21,12 @@ struct udevice; * @align: Frame-buffer alignment, indicating the memory boundary the frame * buffer should start on. If 0, 1MB is assumed * @size: Frame-buffer size, in bytes - * @base: Base address of frame buffer, 0 if not yet known - * @copy_base: Base address of a hardware copy of the frame buffer. See - * CONFIG_VIDEO_COPY. + * @base: Base address of frame buffer, 0 if not yet known. If CONFIG_VIDEO_COPY + * is enabled, this is the software copy, so writes to this will not be + * visible until vidconsole_sync_copy() is called. If CONFIG_VIDEO_COPY is + * disabled, this is the hardware framebuffer. + * @copy_base: Base address of a hardware copy of the frame buffer. If + * CONFIG_VIDEO_COPY is disabled, this is not used. * @copy_size: Size of copy framebuffer, used if @size is 0 * @hide_logo: Hide the logo (used for testing) */ diff --git a/lib/efi_loader/efi_gop.c b/lib/efi_loader/efi_gop.c index 778b693f983a..a09db31eb465 100644 --- a/lib/efi_loader/efi_gop.c +++ b/lib/efi_loader/efi_gop.c @@ -10,6 +10,7 @@ #include <efi_loader.h> #include <log.h> #include <malloc.h> +#include <mapmem.h> #include <video.h> #include <asm/global_data.h>
@@ -467,10 +468,10 @@ efi_status_t efi_gop_register(void) struct efi_gop_obj *gopobj; u32 bpix, format, col, row; u64 fb_base, fb_size; - void *fb; efi_status_t ret; struct udevice *vdev; struct video_priv *priv; + struct video_uc_plat *plat;
/* We only support a single video output device for now */ if (uclass_first_device_err(UCLASS_VIDEO, &vdev)) { @@ -483,9 +484,10 @@ efi_status_t efi_gop_register(void) format = priv->format; col = video_get_xsize(vdev); row = video_get_ysize(vdev); - fb_base = (uintptr_t)priv->fb; - fb_size = priv->fb_size; - fb = priv->fb; + + plat = dev_get_uclass_plat(vdev); + fb_base = IS_ENABLED(CONFIG_VIDEO_COPY) ? plat->copy_base : plat->base; + fb_size = plat->size;
switch (bpix) { case VIDEO_BPP16: @@ -547,7 +549,7 @@ efi_status_t efi_gop_register(void) } gopobj->info.pixels_per_scanline = col; gopobj->bpix = bpix; - gopobj->fb = fb; + gopobj->fb = map_sysmem(fb_base, fb_size);
return EFI_SUCCESS; }
On Mon, Oct 2, 2023 at 10:23 AM Simon Glass sjg@chromium.org wrote:
The efi_gop driver uses private fields from the video uclass to obtain a pointer to the frame buffer. Use the platform data instead.
Check the VIDEO_COPY setting to determine which frame buffer to use. Once the next stage is running (and making use of U-Boot's EFI boot services) U-Boot does not handle copying from priv->fb to the hardware framebuffer, so we must allow EFI to write directly to the hardware framebuffer.
We could provide a function to read this, but it seems better to just document how it works. The original change ignored an explicit comment in the video.h file ("Things that are private to the uclass: don't use these in the driver") which is why this was missed when the VIDEO_COPY feature was added.
Signed-off-by: Simon Glass sjg@chromium.org Fixes: 8f661a5b662 ("efi_loader: gop: Expose fb when 32bpp")
(no changes since v2)
Changes in v2:
- Rebase to -next
- Add some more comments to the header file
- Add fixes tag
include/video.h | 9 ++++++--- lib/efi_loader/efi_gop.c | 12 +++++++----- 2 files changed, 13 insertions(+), 8 deletions(-)
Reviewed-by: Bin Meng bmeng.cn@gmail.com
On Mon, Oct 2, 2023 at 10:23 AM Simon Glass sjg@chromium.org wrote:
The efi_gop driver uses private fields from the video uclass to obtain a pointer to the frame buffer. Use the platform data instead.
Check the VIDEO_COPY setting to determine which frame buffer to use. Once the next stage is running (and making use of U-Boot's EFI boot services) U-Boot does not handle copying from priv->fb to the hardware framebuffer, so we must allow EFI to write directly to the hardware framebuffer.
We could provide a function to read this, but it seems better to just document how it works. The original change ignored an explicit comment in the video.h file ("Things that are private to the uclass: don't use these in the driver") which is why this was missed when the VIDEO_COPY feature was added.
Signed-off-by: Simon Glass sjg@chromium.org Fixes: 8f661a5b662 ("efi_loader: gop: Expose fb when 32bpp")
(no changes since v2)
Changes in v2:
- Rebase to -next
- Add some more comments to the header file
- Add fixes tag
include/video.h | 9 ++++++--- lib/efi_loader/efi_gop.c | 12 +++++++----- 2 files changed, 13 insertions(+), 8 deletions(-)
Reviewed-by: Bin Meng bmeng.cn@gmail.com
Applied to u-boot-dm, thanks!
Adjust scan_mmc4_bootdev() and related function so that the caller can do its own 'bootflow scan' command. This allows it to change the flags if needed.
Signed-off-by: Simon Glass sjg@chromium.org ---
Changes in v3: - Add new patch to refactor mmc prep to allow a different scan
test/boot/bootflow.c | 49 ++++++++++++++++++++++++++++++++++++-------- 1 file changed, 40 insertions(+), 9 deletions(-)
diff --git a/test/boot/bootflow.c b/test/boot/bootflow.c index f5b2059140ac..0a992e2bcc14 100644 --- a/test/boot/bootflow.c +++ b/test/boot/bootflow.c @@ -511,19 +511,27 @@ BOOTSTD_TEST(bootflow_cmd_boot, UT_TESTF_DM | UT_TESTF_SCAN_FDT); /** * prep_mmc_bootdev() - Set up an mmc bootdev so we can access other distros * + * After calling this function, set std->bootdev_order to *@old_orderp to + * restore normal operation of bootstd (i.e. with the original bootdev order) + * * @uts: Unit test state - * @mmc_dev: MMC device to use, e.g. "mmc4" + * @mmc_dev: MMC device to use, e.g. "mmc4". Note that this must remain valid + * in the caller until + * @bind_cros: true to bind the ChromiumOS bootmeth + * @old_orderp: Returns the original bootdev order, which must be restored * Returns 0 on success, -ve on failure */ static int prep_mmc_bootdev(struct unit_test_state *uts, const char *mmc_dev, - bool bind_cros) + bool bind_cros, const char ***old_orderp) { - const char *order[] = {"mmc2", "mmc1", mmc_dev, NULL}; + static const char *order[] = {"mmc2", "mmc1", NULL, NULL}; struct udevice *dev, *bootstd; struct bootstd_priv *std; const char **old_order; ofnode root, node;
+ order[2] = mmc_dev; + /* Enable the mmc4 node since we need a second bootflow */ root = oftree_root(oftree_default()); node = ofnode_find_subnode(root, mmc_dev); @@ -546,26 +554,49 @@ static int prep_mmc_bootdev(struct unit_test_state *uts, const char *mmc_dev, std = dev_get_priv(bootstd); old_order = std->bootdev_order; std->bootdev_order = order; + *old_orderp = old_order; + + return 0; +} + +/** + * scan_mmc_bootdev() - Set up an mmc bootdev so we can access other distros + * + * @uts: Unit test state + * @mmc_dev: MMC device to use, e.g. "mmc4" + * @bind_cros: true to bind the ChromiumOS bootmeth + * Returns 0 on success, -ve on failure + */ +static int scan_mmc_bootdev(struct unit_test_state *uts, const char *mmc_dev, + bool bind_cros) +{ + struct bootstd_priv *std; + struct udevice *bootstd; + const char **old_order; + + ut_assertok(prep_mmc_bootdev(uts, mmc_dev, bind_cros, &old_order));
console_record_reset_enable(); ut_assertok(run_command("bootflow scan", 0)); ut_assert_console_end();
/* Restore the order used by the device tree */ + ut_assertok(uclass_first_device_err(UCLASS_BOOTSTD, &bootstd)); + std = dev_get_priv(bootstd); std->bootdev_order = old_order;
return 0; }
/** - * prep_mmc4_bootdev() - Set up the mmc4 bootdev so we can access a fake Armbian + * scan_mmc4_bootdev() - Set up the mmc4 bootdev so we can access a fake Armbian * * @uts: Unit test state * Returns 0 on success, -ve on failure */ -static int prep_mmc4_bootdev(struct unit_test_state *uts) +static int scan_mmc4_bootdev(struct unit_test_state *uts) { - ut_assertok(prep_mmc_bootdev(uts, "mmc4", false)); + ut_assertok(scan_mmc_bootdev(uts, "mmc4", false));
return 0; } @@ -575,7 +606,7 @@ static int bootflow_cmd_menu(struct unit_test_state *uts) { char prev[3];
- ut_assertok(prep_mmc4_bootdev(uts)); + ut_assertok(scan_mmc4_bootdev(uts));
/* Add keypresses to move to and select the second one in the list */ prev[0] = CTL_CH('n'); @@ -681,7 +712,7 @@ static int bootflow_menu_theme(struct unit_test_state *uts) ofnode node; int i;
- ut_assertok(prep_mmc4_bootdev(uts)); + ut_assertok(scan_mmc4_bootdev(uts));
ut_assertok(bootflow_menu_new(&exp)); node = ofnode_path("/bootstd/theme"); @@ -976,7 +1007,7 @@ BOOTSTD_TEST(bootflow_cmdline, 0); /* Test ChromiumOS bootmeth */ static int bootflow_cros(struct unit_test_state *uts) { - ut_assertok(prep_mmc_bootdev(uts, "mmc5", true)); + ut_assertok(scan_mmc_bootdev(uts, "mmc5", true)); ut_assertok(run_command("bootflow list", 0));
ut_assert_nextlinen("Showing all");
Adjust scan_mmc4_bootdev() and related function so that the caller can do its own 'bootflow scan' command. This allows it to change the flags if needed.
Signed-off-by: Simon Glass sjg@chromium.org ---
Changes in v3: - Add new patch to refactor mmc prep to allow a different scan
test/boot/bootflow.c | 49 ++++++++++++++++++++++++++++++++++++-------- 1 file changed, 40 insertions(+), 9 deletions(-)
Applied to u-boot-dm, thanks!
Return an error when the user does not select an OS, so we know whether to boot or not.
Move calling of bootflow_menu_run() into a separate function so we can call it from other places.
Expand the test to cover these cases.
Add some documentation also, while we are here.
Signed-off-by: Simon Glass sjg@chromium.org ---
Changes in v3: - Add missing word 'function' in the commit message
Changes in v2: - Add new patch to add a return code to bootflow menu
cmd/bootflow.c | 53 +++++++++++++++++++++++------- doc/usage/cmd/bootflow.rst | 67 ++++++++++++++++++++++++++++++++++++++ test/boot/bootflow.c | 15 +++++++++ 3 files changed, 123 insertions(+), 12 deletions(-)
diff --git a/cmd/bootflow.c b/cmd/bootflow.c index 300ad3aaa760..1516f8a4193b 100644 --- a/cmd/bootflow.c +++ b/cmd/bootflow.c @@ -89,6 +89,44 @@ static void show_footer(int count, int num_valid) num_valid); }
+/** + * bootflow_handle_menu() - Handle running the menu and updating cur bootflow + * + * This shows the menu, allows the user to select something and then prints + * what happened + * + * @std: bootstd information + * @text_mode: true to run the menu in text mode + * @bflowp: Returns selected bootflow, on success + * Return: 0 on success (a bootflow was selected), -EAGAIN if nothing was + * chosen, other -ve value on other error + */ +__maybe_unused static int bootflow_handle_menu(struct bootstd_priv *std, + bool text_mode, + struct bootflow **bflowp) +{ + struct bootflow *bflow; + int ret; + + ret = bootflow_menu_run(std, text_mode, &bflow); + if (ret) { + if (ret == -EAGAIN) { + printf("Nothing chosen\n"); + std->cur_bootflow = NULL; + } else { + printf("Menu failed (err=%d)\n", ret); + } + + return ret; + } + + printf("Selected: %s\n", bflow->os_name ? bflow->os_name : bflow->name); + std->cur_bootflow = bflow; + *bflowp = bflow; + + return 0; +} + static int do_bootflow_scan(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]) { @@ -455,18 +493,9 @@ static int do_bootflow_menu(struct cmd_tbl *cmdtp, int flag, int argc, if (ret) return CMD_RET_FAILURE;
- ret = bootflow_menu_run(std, text_mode, &bflow); - if (ret) { - if (ret == -EAGAIN) - printf("Nothing chosen\n"); - else { - printf("Menu failed (err=%d)\n", ret); - return CMD_RET_FAILURE; - } - } - - printf("Selected: %s\n", bflow->os_name ? bflow->os_name : bflow->name); - std->cur_bootflow = bflow; + ret = bootflow_handle_menu(std, text_mode, &bflow); + if (ret) + return CMD_RET_FAILURE;
return 0; } diff --git a/doc/usage/cmd/bootflow.rst b/doc/usage/cmd/bootflow.rst index ead493d0aaf8..6a0645c28d07 100644 --- a/doc/usage/cmd/bootflow.rst +++ b/doc/usage/cmd/bootflow.rst @@ -15,6 +15,7 @@ Synopis bootflow read bootflow boot bootflow cmdline [set|get|clear|delete|auto] <param> [<value>] + bootfloe menu [-t]
Description ----------- @@ -24,6 +25,9 @@ locate bootflows, list them and boot them.
See :doc:`../../develop/bootstd` for more information.
+Note that `CONFIG_BOOTSTD_FULL` (which enables `CONFIG_CMD_BOOTFLOW_FULL) must +be enabled to obtain full functionality with this command. Otherwise, it only +supports `bootflow scan` which scans and boots the first available bootflow.
bootflow scan ~~~~~~~~~~~~~ @@ -247,6 +251,16 @@ can be used to set the early console (or console) to a suitable value so that output appears on the serial port. This is only supported by the 16550 serial driver so far.
+bootflow menu +~~~~~~~~~~~~~ + +This shows a menu with available bootflows. The user can select a particular +bootflow, which then becomes the current one. + +The `-t` flag requests a text menu. Otherwise, if a display is available, a +graphical menu is shown. + + Example -------
@@ -658,6 +672,56 @@ Now the buffer can be accessed:: 77b7e4e0: 320fc000 08e8ba0f c031300f b8d0000f ...2.....01..... 77b7e4f0: 00000020 6ad8000f 00858d10 50000002 ......j.......P
+This shows using a text menu to boot an OS:: + + => bootflow scan + => bootfl list + => bootfl menu -t + U-Boot : Boot Menu + + UP and DOWN to choose, ENTER to select + + > 0 mmc1 mmc1.bootdev.whole + 1 mmc1 Fedora-Workstation-armhfp-31-1.9 (5.3.7-301.fc31.armv7hl) + 2 mmc1 mmc1.bootdev.part_1 + 3 mmc4 mmc4.bootdev.whole + 4 mmc4 Armbian + 5 mmc4 mmc4.bootdev.part_1 + 6 mmc5 mmc5.bootdev.whole + 7 mmc5 ChromeOS + 8 mmc5 ChromeOS + U-Boot : Boot Menu + + UP and DOWN to choose, ENTER to select + + 0 mmc1 mmc1.bootdev.whole + > 1 mmc1 Fedora-Workstation-armhfp-31-1.9 (5.3.7-301.fc31.armv7hl) + 2 mmc1 mmc1.bootdev.part_1 + 3 mmc4 mmc4.bootdev.whole + 4 mmc4 Armbian + 5 mmc4 mmc4.bootdev.part_1 + 6 mmc5 mmc5.bootdev.whole + 7 mmc5 ChromeOS + 8 mmc5 ChromeOS + U-Boot : Boot Menu + + Selected: Fedora-Workstation-armhfp-31-1.9 (5.3.7-301.fc31.armv7hl) + => bootfl boot + ** Booting bootflow 'mmc1.bootdev.part_1' with extlinux + Ignoring unknown command: ui + Ignoring malformed menu command: autoboot + Ignoring malformed menu command: hidden + Ignoring unknown command: totaltimeout + Fedora-Workstation-armhfp-31-1.9 Boot Options. + 1: Fedora-Workstation-armhfp-31-1.9 (5.3.7-301.fc31.armv7hl) + Enter choice: 1 + 1: Fedora-Workstation-armhfp-31-1.9 (5.3.7-301.fc31.armv7hl) + Retrieving file: /vmlinuz-5.3.7-301.fc31.armv7hl + Retrieving file: /initramfs-5.3.7-301.fc31.armv7hl.img + append: ro root=UUID=9732b35b-4cd5-458b-9b91-80f7047e0b8a rhgb quiet LANG=en_US.UTF-8 cma=192MB cma=256MB + Retrieving file: /dtb-5.3.7-301.fc31.armv7hl/sandbox.dtb + ... +
Return value ------------ @@ -667,6 +731,9 @@ return to U-Boot. If something about the U-Boot processing fails, then the return value $? is 1. If the boot succeeds but for some reason the Operating System returns, then $? is 0, indicating success.
+For `bootflow menu` the return value is $? is 0 (true) if an option was choses, +else 1. + For other subcommands, the return value $? is always 0 (true).
diff --git a/test/boot/bootflow.c b/test/boot/bootflow.c index 0a992e2bcc14..04a5bd5d7a80 100644 --- a/test/boot/bootflow.c +++ b/test/boot/bootflow.c @@ -604,8 +604,12 @@ static int scan_mmc4_bootdev(struct unit_test_state *uts) /* Check 'bootflow menu' to select a bootflow */ static int bootflow_cmd_menu(struct unit_test_state *uts) { + struct bootstd_priv *std; char prev[3];
+ /* get access to the current bootflow */ + ut_assertok(bootstd_get_priv(&std)); + ut_assertok(scan_mmc4_bootdev(uts));
/* Add keypresses to move to and select the second one in the list */ @@ -616,6 +620,17 @@ static int bootflow_cmd_menu(struct unit_test_state *uts)
ut_assertok(run_command("bootflow menu", 0)); ut_assert_nextline("Selected: Armbian"); + ut_assertnonnull(std->cur_bootflow); + ut_assert_console_end(); + + /* Check not selecting anything */ + prev[0] = '\e'; + prev[1] = '\0'; + ut_asserteq(1, console_in_puts(prev)); + + ut_asserteq(1, run_command("bootflow menu", 0)); + ut_assertnull(std->cur_bootflow); + ut_assert_nextline("Nothing chosen"); ut_assert_console_end();
return 0;
Return an error when the user does not select an OS, so we know whether to boot or not.
Move calling of bootflow_menu_run() into a separate function so we can call it from other places.
Expand the test to cover these cases.
Add some documentation also, while we are here.
Signed-off-by: Simon Glass sjg@chromium.org ---
Changes in v3: - Add missing word 'function' in the commit message
Changes in v2: - Add new patch to add a return code to bootflow menu
cmd/bootflow.c | 53 +++++++++++++++++++++++------- doc/usage/cmd/bootflow.rst | 67 ++++++++++++++++++++++++++++++++++++++ test/boot/bootflow.c | 15 +++++++++ 3 files changed, 123 insertions(+), 12 deletions(-)
Applied to u-boot-dm, thanks!
Provide the user with a list of available boot options. Selecting one causes it to be booted. Pressing <ESC> causes U-Boot to return to the command-line prompt.
Signed-off-by: Simon Glass sjg@chromium.org ---
Changes in v3: - Clear the screen before booting
Changes in v2: - Add new patch to add a coreboot boot script
configs/coreboot64_defconfig | 1 + configs/coreboot_defconfig | 1 + 2 files changed, 2 insertions(+)
diff --git a/configs/coreboot64_defconfig b/configs/coreboot64_defconfig index 555d281ef3cf..1865f623f6e6 100644 --- a/configs/coreboot64_defconfig +++ b/configs/coreboot64_defconfig @@ -17,6 +17,7 @@ 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_BOOTCOMMAND="bootflow scan -l; if bootflow menu; then cls; bootflow boot; fi" CONFIG_PRE_CONSOLE_BUFFER=y CONFIG_SYS_CONSOLE_INFO_QUIET=y CONFIG_LOG=y diff --git a/configs/coreboot_defconfig b/configs/coreboot_defconfig index edc38f1f5923..f1728dbfb5c9 100644 --- a/configs/coreboot_defconfig +++ b/configs/coreboot_defconfig @@ -15,6 +15,7 @@ CONFIG_SYS_MONITOR_BASE=0x01110000 CONFIG_SHOW_BOOT_PROGRESS=y CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="root=/dev/sdb3 init=/sbin/init rootwait ro" +CONFIG_BOOTCOMMAND="bootflow scan -l; if bootflow menu; then cls; bootflow boot; fi" CONFIG_PRE_CONSOLE_BUFFER=y CONFIG_SYS_CONSOLE_INFO_QUIET=y CONFIG_LOG=y
On Mon, Oct 2, 2023 at 9:14 AM Simon Glass sjg@chromium.org wrote:
Provide the user with a list of available boot options. Selecting one causes it to be booted. Pressing <ESC> causes U-Boot to return to the command-line prompt.
Signed-off-by: Simon Glass sjg@chromium.org
Changes in v3:
- Clear the screen before booting
Changes in v2:
- Add new patch to add a coreboot boot script
configs/coreboot64_defconfig | 1 + configs/coreboot_defconfig | 1 + 2 files changed, 2 insertions(+)
Reviewed-by: Bin Meng bmeng.cn@gmail.com
When a USB device is unbound, it causes any bootflows attached to it to be removed, via a call to bootdev_clear_bootflows() from bootdev_pre_unbind(). This obviously makes it impossible to boot the bootflow.
However, when booting a bootflow that relies on USB, usb_stop() is called, which unbinds the device. For EFI, this happens in efi_exit_boot_services() which means that the bootflow disappears before it is finished with.
There is no need to unbind all the USB devices just to quiesce them. Add a new usb_pause() call which removes them but leaves them bound.
This resolves a hang on x86 when booting a distro from USB. This was found using a device with 4 bootflows, the last of which was USB.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v2)
Changes in v2: - Add new patch to avoid unbinding devices in use by bootflows
boot/bootm.c | 2 +- common/usb.c | 7 ++++++- drivers/usb/host/usb-uclass.c | 14 ++++++++++++-- include/usb.h | 15 ++++++++++++++- 4 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/boot/bootm.c b/boot/bootm.c index b1c3afe0a3ad..5c9ba083e64c 100644 --- a/boot/bootm.c +++ b/boot/bootm.c @@ -501,7 +501,7 @@ ulong bootm_disable_interrupts(void) * updated every 1 ms within the HCCA structure in SDRAM! For more * details see the OpenHCI specification. */ - usb_stop(); + usb_pause(); #endif return iflag; } diff --git a/common/usb.c b/common/usb.c index 836506dcd9e9..4d6ac69111e7 100644 --- a/common/usb.c +++ b/common/usb.c @@ -126,7 +126,7 @@ int usb_init(void) /****************************************************************************** * Stop USB this stops the LowLevel Part and deregisters USB devices. */ -int usb_stop(void) +int usb_pause(void) { int i;
@@ -144,6 +144,11 @@ int usb_stop(void) return 0; }
+int usb_stop(void) +{ + return usb_pause(); +} + /****************************************************************************** * Detect if a USB device has been plugged or unplugged. */ diff --git a/drivers/usb/host/usb-uclass.c b/drivers/usb/host/usb-uclass.c index a1cd0ad2d669..c26c65d7986b 100644 --- a/drivers/usb/host/usb-uclass.c +++ b/drivers/usb/host/usb-uclass.c @@ -173,7 +173,7 @@ int usb_get_max_xfer_size(struct usb_device *udev, size_t *size) return ops->get_max_xfer_size(bus, size); }
-int usb_stop(void) +static int usb_finish(bool unbind_all) { struct udevice *bus; struct udevice *rh; @@ -195,7 +195,7 @@ int usb_stop(void)
/* Locate root hub device */ device_find_first_child(bus, &rh); - if (rh) { + if (rh && unbind_all) { /* * All USB devices are children of root hub. * Unbinding root hub will unbind all of its children. @@ -222,6 +222,16 @@ int usb_stop(void) return err; }
+int usb_stop(void) +{ + return usb_finish(true); +} + +int usb_pause(void) +{ + return usb_finish(false); +} + static void usb_scan_bus(struct udevice *bus, bool recurse) { struct usb_bus_priv *priv; diff --git a/include/usb.h b/include/usb.h index 09e3f0cb309c..ad39b09a6e45 100644 --- a/include/usb.h +++ b/include/usb.h @@ -265,7 +265,20 @@ int usb_kbd_deregister(int force); */ int usb_init(void);
-int usb_stop(void); /* stop the USB Controller */ +/** + * usb_stop() - stop the USB Controller and unbind all USB controllers/devices + * + * Return: 0 if OK, -ve on error + */ +int usb_stop(void); + +/** + * usb_pause() - stop the USB Controller DMA, etc. + * + * Return: 0 if OK, -ve on error + */ +int usb_pause(void); + int usb_detect_change(void); /* detect if a USB device has been (un)plugged */
Use the correct background colour when using white-on-black.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
boot/expo.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/boot/expo.c b/boot/expo.c index 139d684f8e6e..cadb6a0ad6e3 100644 --- a/boot/expo.c +++ b/boot/expo.c @@ -190,10 +190,12 @@ int expo_render(struct expo *exp) struct udevice *dev = exp->display; struct video_priv *vid_priv = dev_get_uclass_priv(dev); struct scene *scn = NULL; + enum colour_idx back; u32 colour; int ret;
- colour = video_index_to_colour(vid_priv, VID_WHITE); + back = CONFIG_IS_ENABLED(SYS_WHITE_ON_BLACK) ? VID_BLACK : VID_WHITE; + colour = video_index_to_colour(vid_priv, back); ret = video_fill(dev, colour); if (ret) return log_msg_ret("fill", ret);
On Mon, Oct 2, 2023 at 9:30 AM Simon Glass sjg@chromium.org wrote:
Use the correct background colour when using white-on-black.
Signed-off-by: Simon Glass sjg@chromium.org
(no changes since v1)
boot/expo.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
Reviewed-by: Bin Meng bmeng.cn@gmail.com
On Mon, Oct 2, 2023 at 9:30 AM Simon Glass sjg@chromium.org wrote:
Use the correct background colour when using white-on-black.
Signed-off-by: Simon Glass sjg@chromium.org
(no changes since v1)
boot/expo.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
Reviewed-by: Bin Meng bmeng.cn@gmail.com
Applied to u-boot-dm, thanks!
The ANSI codes are not correctly handled at present, in that the requested X position is added to the current one.
Correct this and also call vidconsole_entry_start() to start a new text line.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
drivers/video/vidconsole-uclass.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/video/vidconsole-uclass.c b/drivers/video/vidconsole-uclass.c index 22d55df71f63..a312a1985242 100644 --- a/drivers/video/vidconsole-uclass.c +++ b/drivers/video/vidconsole-uclass.c @@ -125,6 +125,7 @@ void vidconsole_set_cursor_pos(struct udevice *dev, int x, int y) priv->xcur_frac = VID_TO_POS(x); priv->xstart_frac = priv->xcur_frac; priv->ycur = y; + vidconsole_entry_start(dev); }
/** @@ -134,8 +135,10 @@ void vidconsole_set_cursor_pos(struct udevice *dev, int x, int y) * @row: new row * @col: new column */ -static void set_cursor_position(struct vidconsole_priv *priv, int row, int col) +static void set_cursor_position(struct udevice *dev, int row, int col) { + struct vidconsole_priv *priv = dev_get_uclass_priv(dev); + /* * Ensure we stay in the bounds of the screen. */ @@ -144,9 +147,7 @@ static void set_cursor_position(struct vidconsole_priv *priv, int row, int col) if (col >= priv->cols) col = priv->cols - 1;
- priv->ycur = row * priv->y_charsize; - priv->xcur_frac = priv->xstart_frac + - VID_TO_POS(col * priv->x_charsize); + vidconsole_position_cursor(dev, col, row); }
/** @@ -193,7 +194,7 @@ static void vidconsole_escape_char(struct udevice *dev, char ch) int row = priv->row_saved; int col = priv->col_saved;
- set_cursor_position(priv, row, col); + set_cursor_position(dev, row, col); priv->escape = 0; return; } @@ -255,7 +256,7 @@ static void vidconsole_escape_char(struct udevice *dev, char ch) if (row < 0) row = 0; /* Right and bottom overflows are handled in the callee. */ - set_cursor_position(priv, row, col); + set_cursor_position(dev, row, col); break; } case 'H': @@ -279,7 +280,7 @@ static void vidconsole_escape_char(struct udevice *dev, char ch) if (col) --col;
- set_cursor_position(priv, row, col); + set_cursor_position(dev, row, col);
break; }
Hi Anatolij,
On Sun, 1 Oct 2023 at 19:15, Simon Glass sjg@chromium.org wrote:
The ANSI codes are not correctly handled at present, in that the requested X position is added to the current one.
Correct this and also call vidconsole_entry_start() to start a new text line.
Signed-off-by: Simon Glass sjg@chromium.org
(no changes since v1)
drivers/video/vidconsole-uclass.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/video/vidconsole-uclass.c b/drivers/video/vidconsole-uclass.c index 22d55df71f63..a312a1985242 100644 --- a/drivers/video/vidconsole-uclass.c +++ b/drivers/video/vidconsole-uclass.c @@ -125,6 +125,7 @@ void vidconsole_set_cursor_pos(struct udevice *dev, int x, int y) priv->xcur_frac = VID_TO_POS(x); priv->xstart_frac = priv->xcur_frac; priv->ycur = y;
vidconsole_entry_start(dev);}
/** @@ -134,8 +135,10 @@ void vidconsole_set_cursor_pos(struct udevice *dev, int x, int y)
- @row: new row
- @col: new column
*/ -static void set_cursor_position(struct vidconsole_priv *priv, int row, int col) +static void set_cursor_position(struct udevice *dev, int row, int col) {
struct vidconsole_priv *priv = dev_get_uclass_priv(dev);/* * Ensure we stay in the bounds of the screen. */@@ -144,9 +147,7 @@ static void set_cursor_position(struct vidconsole_priv *priv, int row, int col) if (col >= priv->cols) col = priv->cols - 1;
priv->ycur = row * priv->y_charsize;priv->xcur_frac = priv->xstart_frac +VID_TO_POS(col * priv->x_charsize);
vidconsole_position_cursor(dev, col, row);}
/** @@ -193,7 +194,7 @@ static void vidconsole_escape_char(struct udevice *dev, char ch) int row = priv->row_saved; int col = priv->col_saved;
set_cursor_position(priv, row, col);
set_cursor_position(dev, row, col); priv->escape = 0; return; }@@ -255,7 +256,7 @@ static void vidconsole_escape_char(struct udevice *dev, char ch) if (row < 0) row = 0; /* Right and bottom overflows are handled in the callee. */
set_cursor_position(priv, row, col);
set_cursor_position(dev, row, col); break; } case 'H':@@ -279,7 +280,7 @@ static void vidconsole_escape_char(struct udevice *dev, char ch) if (col) --col;
set_cursor_position(priv, row, col);
set_cursor_position(dev, row, col); break; }-- 2.42.0.582.g8ccd20d70d-goog
Any thoughts on this patch, please?
Regards, Simon
On Sun, 1 Oct 2023 19:14:42 -0600 Simon Glass sjg@chromium.org wrote:
The ANSI codes are not correctly handled at present, in that the requested X position is added to the current one.
Correct this and also call vidconsole_entry_start() to start a new text line.
Signed-off-by: Simon Glass sjg@chromium.org
(no changes since v1)
drivers/video/vidconsole-uclass.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-)
Reviewed-by: Anatolij Gustschin agust@denx.de
Saving and restoring entries is used for expo and for the command line, which we don't use in SPL. Drop these methods.
Signed-off-by: Simon Glass sjg@chromium.org ---
Changes in v3: - Add new patch to drop unnecessary truetype operations from SPL
drivers/video/console_truetype.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/drivers/video/console_truetype.c b/drivers/video/console_truetype.c index 14fb81e9563c..602133575f8c 100644 --- a/drivers/video/console_truetype.c +++ b/drivers/video/console_truetype.c @@ -8,6 +8,7 @@ #include <dm.h> #include <log.h> #include <malloc.h> +#include <spl.h> #include <video.h> #include <video_console.h>
@@ -799,6 +800,9 @@ static int truetype_entry_save(struct udevice *dev, struct abuf *buf) struct console_tt_store store; const uint size = sizeof(store);
+ if (spl_phase() <= PHASE_SPL) + return -ENOSYS; + /* * store the whole priv structure as it is simpler that picking out * what we need @@ -820,6 +824,9 @@ static int truetype_entry_restore(struct udevice *dev, struct abuf *buf) struct console_tt_priv *priv = dev_get_priv(dev); struct console_tt_store store;
+ if (spl_phase() <= PHASE_SPL) + return -ENOSYS; + memcpy(&store, abuf_data(buf), sizeof(store));
vc_priv->xcur_frac = store.cur.xpos_frac; @@ -844,6 +851,9 @@ static int truetype_set_cursor_visible(struct udevice *dev, bool visible, uint out, val; int ret;
+ if (spl_phase() <= PHASE_SPL) + return -ENOSYS; + if (!visible) return 0;
On Mon, Oct 2, 2023 at 11:32 AM Simon Glass sjg@chromium.org wrote:
Saving and restoring entries is used for expo and for the command line, which we don't use in SPL. Drop these methods.
Signed-off-by: Simon Glass sjg@chromium.org
Changes in v3:
- Add new patch to drop unnecessary truetype operations from SPL
drivers/video/console_truetype.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
Reviewed-by: Bin Meng bmeng.cn@gmail.com
This is needed to support Truetype fonts. In any case, the compiler expects SSE to be available in 64-bit mode. Enable it.
Signed-off-by: Simon Glass sjg@chromium.org Suggested-by: Bin Meng bmeng.cn@gmail.com ---
(no changes since v1)
arch/x86/config.mk | 1 - arch/x86/cpu/x86_64/cpu.c | 11 +++++++++++ 2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/x86/config.mk b/arch/x86/config.mk index 26ec1af2f0b0..b038b132985a 100644 --- a/arch/x86/config.mk +++ b/arch/x86/config.mk @@ -27,7 +27,6 @@ ifeq ($(IS_32BIT),y) PLATFORM_CPPFLAGS += -march=i386 -m32 else PLATFORM_CPPFLAGS += $(if $(CONFIG_SPL_BUILD),,-fpic) -fno-common -march=core2 -m64 -PLATFORM_CPPFLAGS += -mno-mmx -mno-sse endif
PLATFORM_RELFLAGS += -fdata-sections -ffunction-sections -fvisibility=hidden diff --git a/arch/x86/cpu/x86_64/cpu.c b/arch/x86/cpu/x86_64/cpu.c index 2647bff891f8..54dc31bf6b71 100644 --- a/arch/x86/cpu/x86_64/cpu.c +++ b/arch/x86/cpu/x86_64/cpu.c @@ -10,6 +10,7 @@ #include <init.h> #include <asm/cpu.h> #include <asm/global_data.h> +#include <asm/processor-flags.h>
DECLARE_GLOBAL_DATA_PTR;
@@ -39,11 +40,21 @@ int x86_mp_init(void) return 0; }
+/* enable SSE features */ +static void setup_cpu_features(void) +{ + asm ("mov %%cr4, %%rax\n" \ + "or %0, %%rax\n" \ + "mov %%rax, %%cr4\n" \ + : : "i" (X86_CR4_OSFXSR | X86_CR4_OSXMMEXCPT) : "eax"); +} + 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; + setup_cpu_features();
return 0; }
Hi Simon,
On Mon, Oct 2, 2023 at 9:15 AM Simon Glass sjg@chromium.org wrote:
This is needed to support Truetype fonts. In any case, the compiler expects SSE to be available in 64-bit mode. Enable it.
Signed-off-by: Simon Glass sjg@chromium.org Suggested-by: Bin Meng bmeng.cn@gmail.com
(no changes since v1)
arch/x86/config.mk | 1 - arch/x86/cpu/x86_64/cpu.c | 11 +++++++++++ 2 files changed, 11 insertions(+), 1 deletion(-)
I didn't suggest we enable SSE for x86. This is the wrong approach.
We should rewrite the Truetype support codes to avoid using float/double types.
This way the Truetype codes can be used on any other architectures without the need for the compiler to emit explicit floating instructions.
Regards, Bin
Hi Bin,
On Sun, 5 Nov 2023 at 14:05, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Mon, Oct 2, 2023 at 9:15 AM Simon Glass sjg@chromium.org wrote:
This is needed to support Truetype fonts. In any case, the compiler expects SSE to be available in 64-bit mode. Enable it.
Signed-off-by: Simon Glass sjg@chromium.org Suggested-by: Bin Meng bmeng.cn@gmail.com
(no changes since v1)
arch/x86/config.mk | 1 - arch/x86/cpu/x86_64/cpu.c | 11 +++++++++++ 2 files changed, 11 insertions(+), 1 deletion(-)
I didn't suggest we enable SSE for x86. This is the wrong approach.
We should rewrite the Truetype support codes to avoid using float/double types.
This way the Truetype codes can be used on any other architectures without the need for the compiler to emit explicit floating instructions.
I am not aware of any such library. At present, enabling truetype on coreboot64 causes a hang.
Regards, Simon
+ Tom,
Hi Simon,
On Mon, Nov 6, 2023 at 12:29 AM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Sun, 5 Nov 2023 at 14:05, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Mon, Oct 2, 2023 at 9:15 AM Simon Glass sjg@chromium.org wrote:
This is needed to support Truetype fonts. In any case, the compiler expects SSE to be available in 64-bit mode. Enable it.
Signed-off-by: Simon Glass sjg@chromium.org Suggested-by: Bin Meng bmeng.cn@gmail.com
(no changes since v1)
arch/x86/config.mk | 1 - arch/x86/cpu/x86_64/cpu.c | 11 +++++++++++ 2 files changed, 11 insertions(+), 1 deletion(-)
I didn't suggest we enable SSE for x86. This is the wrong approach.
We should rewrite the Truetype support codes to avoid using float/double types.
This way the Truetype codes can be used on any other architectures without the need for the compiler to emit explicit floating instructions.
I am not aware of any such library. At present, enabling truetype on coreboot64 causes a hang.
If that's the case, we will have to either:
- Switch all U-Boot builds' to use software float (e.g. -msoft-float) which unfortunately depends on the compiler runtime intrinsics. - Introduce a Kconfig option for hard float enabling and let each architecture to decide whether it implements it or not, and update Truetype to depend on the hard float.
Regards, Bin
On Mon, Nov 06, 2023 at 06:26:15PM +0800, Bin Meng wrote:
- Tom,
Hi Simon,
On Mon, Nov 6, 2023 at 12:29 AM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Sun, 5 Nov 2023 at 14:05, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Mon, Oct 2, 2023 at 9:15 AM Simon Glass sjg@chromium.org wrote:
This is needed to support Truetype fonts. In any case, the compiler expects SSE to be available in 64-bit mode. Enable it.
Signed-off-by: Simon Glass sjg@chromium.org Suggested-by: Bin Meng bmeng.cn@gmail.com
(no changes since v1)
arch/x86/config.mk | 1 - arch/x86/cpu/x86_64/cpu.c | 11 +++++++++++ 2 files changed, 11 insertions(+), 1 deletion(-)
I didn't suggest we enable SSE for x86. This is the wrong approach.
We should rewrite the Truetype support codes to avoid using float/double types.
This way the Truetype codes can be used on any other architectures without the need for the compiler to emit explicit floating instructions.
I am not aware of any such library. At present, enabling truetype on coreboot64 causes a hang.
If that's the case, we will have to either:
- Switch all U-Boot builds' to use software float (e.g. -msoft-float)
which unfortunately depends on the compiler runtime intrinsics.
- Introduce a Kconfig option for hard float enabling and let each
architecture to decide whether it implements it or not, and update Truetype to depend on the hard float.
We generally do -msoft-float already, so introducing that for x86, and some Kconfig logic to ensure that no one else steps on this particular bug sounds reasonable.
Hi Bin,
On Mon, 6 Nov 2023 at 08:36, Tom Rini trini@konsulko.com wrote:
On Mon, Nov 06, 2023 at 06:26:15PM +0800, Bin Meng wrote:
- Tom,
Hi Simon,
On Mon, Nov 6, 2023 at 12:29 AM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Sun, 5 Nov 2023 at 14:05, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Mon, Oct 2, 2023 at 9:15 AM Simon Glass sjg@chromium.org wrote:
This is needed to support Truetype fonts. In any case, the compiler expects SSE to be available in 64-bit mode. Enable it.
Signed-off-by: Simon Glass sjg@chromium.org Suggested-by: Bin Meng bmeng.cn@gmail.com
(no changes since v1)
arch/x86/config.mk | 1 - arch/x86/cpu/x86_64/cpu.c | 11 +++++++++++ 2 files changed, 11 insertions(+), 1 deletion(-)
I didn't suggest we enable SSE for x86. This is the wrong approach.
We should rewrite the Truetype support codes to avoid using float/double types.
This way the Truetype codes can be used on any other architectures without the need for the compiler to emit explicit floating instructions.
I am not aware of any such library. At present, enabling truetype on coreboot64 causes a hang.
If that's the case, we will have to either:
- Switch all U-Boot builds' to use software float (e.g. -msoft-float)
which unfortunately depends on the compiler runtime intrinsics.
- Introduce a Kconfig option for hard float enabling and let each
architecture to decide whether it implements it or not, and update Truetype to depend on the hard float.
We generally do -msoft-float already, so introducing that for x86, and some Kconfig logic to ensure that no one else steps on this particular bug sounds reasonable.
Yes soft float seems to be not-much-used on x86. For 64-bit chips the compiler seems to assume that hardfp is available.
So perhaps the best thing is to introduce a HARDFP option to x86 only.
Regards, Simon
Hi Simon,
On Mon, Nov 13, 2023 at 4:02 AM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Mon, 6 Nov 2023 at 08:36, Tom Rini trini@konsulko.com wrote:
On Mon, Nov 06, 2023 at 06:26:15PM +0800, Bin Meng wrote:
- Tom,
Hi Simon,
On Mon, Nov 6, 2023 at 12:29 AM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Sun, 5 Nov 2023 at 14:05, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Mon, Oct 2, 2023 at 9:15 AM Simon Glass sjg@chromium.org wrote:
This is needed to support Truetype fonts. In any case, the compiler expects SSE to be available in 64-bit mode. Enable it.
Signed-off-by: Simon Glass sjg@chromium.org Suggested-by: Bin Meng bmeng.cn@gmail.com
(no changes since v1)
arch/x86/config.mk | 1 - arch/x86/cpu/x86_64/cpu.c | 11 +++++++++++ 2 files changed, 11 insertions(+), 1 deletion(-)
I didn't suggest we enable SSE for x86. This is the wrong approach.
We should rewrite the Truetype support codes to avoid using float/double types.
This way the Truetype codes can be used on any other architectures without the need for the compiler to emit explicit floating instructions.
I am not aware of any such library. At present, enabling truetype on coreboot64 causes a hang.
If that's the case, we will have to either:
- Switch all U-Boot builds' to use software float (e.g. -msoft-float)
which unfortunately depends on the compiler runtime intrinsics.
- Introduce a Kconfig option for hard float enabling and let each
architecture to decide whether it implements it or not, and update Truetype to depend on the hard float.
We generally do -msoft-float already, so introducing that for x86, and some Kconfig logic to ensure that no one else steps on this particular bug sounds reasonable.
Yes soft float seems to be not-much-used on x86. For 64-bit chips the compiler seems to assume that hardfp is available.
We have compiler flags to ensure the compiler does not generate SSE instructions. Yes, I know SSE is in almost every x86 processor we see nowadays.
So perhaps the best thing is to introduce a HARDFP option to x86 only.
This option should be global as some other arches also don't have hardware fp, like RISC-V whose fp extension is optional.
Regards, Bin
Hi Bin,
On Mon, 13 Nov 2023 at 06:01, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Mon, Nov 13, 2023 at 4:02 AM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Mon, 6 Nov 2023 at 08:36, Tom Rini trini@konsulko.com wrote:
On Mon, Nov 06, 2023 at 06:26:15PM +0800, Bin Meng wrote:
- Tom,
Hi Simon,
On Mon, Nov 6, 2023 at 12:29 AM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Sun, 5 Nov 2023 at 14:05, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Mon, Oct 2, 2023 at 9:15 AM Simon Glass sjg@chromium.org wrote: > > This is needed to support Truetype fonts. In any case, the compiler > expects SSE to be available in 64-bit mode. Enable it. > > Signed-off-by: Simon Glass sjg@chromium.org > Suggested-by: Bin Meng bmeng.cn@gmail.com > --- > > (no changes since v1) > > arch/x86/config.mk | 1 - > arch/x86/cpu/x86_64/cpu.c | 11 +++++++++++ > 2 files changed, 11 insertions(+), 1 deletion(-) >
I didn't suggest we enable SSE for x86. This is the wrong approach.
We should rewrite the Truetype support codes to avoid using float/double types.
This way the Truetype codes can be used on any other architectures without the need for the compiler to emit explicit floating instructions.
I am not aware of any such library. At present, enabling truetype on coreboot64 causes a hang.
If that's the case, we will have to either:
- Switch all U-Boot builds' to use software float (e.g. -msoft-float)
which unfortunately depends on the compiler runtime intrinsics.
- Introduce a Kconfig option for hard float enabling and let each
architecture to decide whether it implements it or not, and update Truetype to depend on the hard float.
We generally do -msoft-float already, so introducing that for x86, and some Kconfig logic to ensure that no one else steps on this particular bug sounds reasonable.
Yes soft float seems to be not-much-used on x86. For 64-bit chips the compiler seems to assume that hardfp is available.
We have compiler flags to ensure the compiler does not generate SSE instructions. Yes, I know SSE is in almost every x86 processor we see nowadays.
So perhaps the best thing is to introduce a HARDFP option to x86 only.
This option should be global as some other arches also don't have hardware fp, like RISC-V whose fp extension is optional.
Here is the patch I have:
https://patchwork.ozlabs.org/project/uboot/patch/20231112200255.172351-5-sjg...
So perhaps move it to arch/Kconfig , rename it to HARDFP and update the help to be more generic?
Regards, Simon
On Mon, Nov 13, 2023 at 09:01:02PM +0800, Bin Meng wrote:
Hi Simon,
On Mon, Nov 13, 2023 at 4:02 AM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Mon, 6 Nov 2023 at 08:36, Tom Rini trini@konsulko.com wrote:
On Mon, Nov 06, 2023 at 06:26:15PM +0800, Bin Meng wrote:
- Tom,
Hi Simon,
On Mon, Nov 6, 2023 at 12:29 AM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Sun, 5 Nov 2023 at 14:05, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Mon, Oct 2, 2023 at 9:15 AM Simon Glass sjg@chromium.org wrote: > > This is needed to support Truetype fonts. In any case, the compiler > expects SSE to be available in 64-bit mode. Enable it. > > Signed-off-by: Simon Glass sjg@chromium.org > Suggested-by: Bin Meng bmeng.cn@gmail.com > --- > > (no changes since v1) > > arch/x86/config.mk | 1 - > arch/x86/cpu/x86_64/cpu.c | 11 +++++++++++ > 2 files changed, 11 insertions(+), 1 deletion(-) >
I didn't suggest we enable SSE for x86. This is the wrong approach.
We should rewrite the Truetype support codes to avoid using float/double types.
This way the Truetype codes can be used on any other architectures without the need for the compiler to emit explicit floating instructions.
I am not aware of any such library. At present, enabling truetype on coreboot64 causes a hang.
If that's the case, we will have to either:
- Switch all U-Boot builds' to use software float (e.g. -msoft-float)
which unfortunately depends on the compiler runtime intrinsics.
- Introduce a Kconfig option for hard float enabling and let each
architecture to decide whether it implements it or not, and update Truetype to depend on the hard float.
We generally do -msoft-float already, so introducing that for x86, and some Kconfig logic to ensure that no one else steps on this particular bug sounds reasonable.
Yes soft float seems to be not-much-used on x86. For 64-bit chips the compiler seems to assume that hardfp is available.
We have compiler flags to ensure the compiler does not generate SSE instructions. Yes, I know SSE is in almost every x86 processor we see nowadays.
So perhaps the best thing is to introduce a HARDFP option to x86 only.
This option should be global as some other arches also don't have hardware fp, like RISC-V whose fp extension is optional.
RISC-V should take the ARM approach (and what I was suggesting for x86) and enforce soft-float for everyone.
Hi Tom,
On Mon, 13 Nov 2023 at 07:06, Tom Rini trini@konsulko.com wrote:
On Mon, Nov 13, 2023 at 09:01:02PM +0800, Bin Meng wrote:
Hi Simon,
On Mon, Nov 13, 2023 at 4:02 AM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Mon, 6 Nov 2023 at 08:36, Tom Rini trini@konsulko.com wrote:
On Mon, Nov 06, 2023 at 06:26:15PM +0800, Bin Meng wrote:
- Tom,
Hi Simon,
On Mon, Nov 6, 2023 at 12:29 AM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On Sun, 5 Nov 2023 at 14:05, Bin Meng bmeng.cn@gmail.com wrote: > > Hi Simon, > > On Mon, Oct 2, 2023 at 9:15 AM Simon Glass sjg@chromium.org wrote: > > > > This is needed to support Truetype fonts. In any case, the compiler > > expects SSE to be available in 64-bit mode. Enable it. > > > > Signed-off-by: Simon Glass sjg@chromium.org > > Suggested-by: Bin Meng bmeng.cn@gmail.com > > --- > > > > (no changes since v1) > > > > arch/x86/config.mk | 1 - > > arch/x86/cpu/x86_64/cpu.c | 11 +++++++++++ > > 2 files changed, 11 insertions(+), 1 deletion(-) > > > > I didn't suggest we enable SSE for x86. This is the wrong approach. > > We should rewrite the Truetype support codes to avoid using float/double types. > > This way the Truetype codes can be used on any other architectures > without the need for the compiler to emit explicit floating > instructions.
I am not aware of any such library. At present, enabling truetype on coreboot64 causes a hang.
If that's the case, we will have to either:
- Switch all U-Boot builds' to use software float (e.g. -msoft-float)
which unfortunately depends on the compiler runtime intrinsics.
- Introduce a Kconfig option for hard float enabling and let each
architecture to decide whether it implements it or not, and update Truetype to depend on the hard float.
We generally do -msoft-float already, so introducing that for x86, and some Kconfig logic to ensure that no one else steps on this particular bug sounds reasonable.
Yes soft float seems to be not-much-used on x86. For 64-bit chips the compiler seems to assume that hardfp is available.
We have compiler flags to ensure the compiler does not generate SSE instructions. Yes, I know SSE is in almost every x86 processor we see nowadays.
So perhaps the best thing is to introduce a HARDFP option to x86 only.
This option should be global as some other arches also don't have hardware fp, like RISC-V whose fp extension is optional.
RISC-V should take the ARM approach (and what I was suggesting for x86) and enforce soft-float for everyone.
But see my comment above...I'm just not sure softfp is widely used on x86. It also is a bit silly, since 64-bit CPUs have hardfp and it is trivial to enable (in fact we have to disable it if we don;t want it).
Bin, please let me know what you think.
Regards, Simon
Truetype fonts look better in the menu, so enable them.
Signed-off-by: Simon Glass sjg@chromium.org ---
Changes in v3: - Add new patch to enable truetype fonts in coreboot
arch/x86/dts/coreboot.dts | 10 ++++++++++ configs/coreboot64_defconfig | 3 ++- configs/coreboot_defconfig | 3 ++- 3 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/x86/dts/coreboot.dts b/arch/x86/dts/coreboot.dts index 0eb31cae42c1..83beb82f37c7 100644 --- a/arch/x86/dts/coreboot.dts +++ b/arch/x86/dts/coreboot.dts @@ -45,4 +45,14 @@ bootph-some-ram; compatible = "coreboot-fb"; }; + + bootstd { + compatible = "u-boot,boot-std"; + + theme { + font-size = <30>; + menu-inset = <3>; + menuitem-gap-y = <1>; + }; + }; }; diff --git a/configs/coreboot64_defconfig b/configs/coreboot64_defconfig index 1865f623f6e6..42b46ba0d9b9 100644 --- a/configs/coreboot64_defconfig +++ b/configs/coreboot64_defconfig @@ -9,11 +9,11 @@ CONFIG_PRE_CON_BUF_ADDR=0x100000 CONFIG_X86_RUN_64BIT=y CONFIG_VENDOR_COREBOOT=y CONFIG_TARGET_COREBOOT=y +CONFIG_SYS_MONITOR_BASE=0x01120000 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" @@ -61,6 +61,7 @@ CONFIG_SYS_NS16550_MEM32=y CONFIG_SOUND=y CONFIG_SOUND_I8254=y CONFIG_VIDEO_COPY=y +CONFIG_CONSOLE_TRUETYPE=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 f1728dbfb5c9..7d744e9962ae 100644 --- a/configs/coreboot_defconfig +++ b/configs/coreboot_defconfig @@ -7,11 +7,11 @@ CONFIG_DEFAULT_DEVICE_TREE="coreboot" CONFIG_PRE_CON_BUF_ADDR=0x100000 CONFIG_VENDOR_COREBOOT=y CONFIG_TARGET_COREBOOT=y +CONFIG_SYS_MONITOR_BASE=0x01110000 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 CONFIG_BOOTARGS="root=/dev/sdb3 init=/sbin/init rootwait ro" @@ -55,6 +55,7 @@ CONFIG_SYS_NS16550_MEM32=y CONFIG_SOUND=y CONFIG_SOUND_I8254=y CONFIG_VIDEO_COPY=y +CONFIG_CONSOLE_TRUETYPE=y CONFIG_CONSOLE_SCROLL_LINES=5 CONFIG_CMD_DHRYSTONE=y # CONFIG_GZIP is not set
Expand the ROM for x86_64 to 2MB to make space for the font, as it is already on the edge.
Signed-off-by: Simon Glass sjg@chromium.org ---
(no changes since v1)
board/emulation/qemu-x86/Kconfig | 3 ++- configs/qemu-x86_64_defconfig | 6 +++--- 2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/board/emulation/qemu-x86/Kconfig b/board/emulation/qemu-x86/Kconfig index 787751abba4f..04b7a8aff89e 100644 --- a/board/emulation/qemu-x86/Kconfig +++ b/board/emulation/qemu-x86/Kconfig @@ -21,7 +21,8 @@ config BOARD_SPECIFIC_OPTIONS # dummy select X86_RESET_VECTOR select QEMU select QFW_PIO - select BOARD_ROMSIZE_KB_1024 + select BOARD_ROMSIZE_KB_1024 if TARGET_QEMU_X86 + select BOARD_ROMSIZE_KB_2048 if TARGET_QEMU_X86_64 imply VIRTIO_PCI imply VIRTIO_NET imply VIRTIO_BLK diff --git a/configs/qemu-x86_64_defconfig b/configs/qemu-x86_64_defconfig index 165f0b512c8b..6de3da2d8269 100644 --- a/configs/qemu-x86_64_defconfig +++ b/configs/qemu-x86_64_defconfig @@ -6,7 +6,7 @@ CONFIG_ENV_SIZE=0x40000 CONFIG_MAX_CPUS=2 CONFIG_SPL_DM_SPI=y CONFIG_DEFAULT_DEVICE_TREE="qemu-x86_i440fx" -CONFIG_SPL_TEXT_BASE=0xfffd8000 +CONFIG_SPL_TEXT_BASE=0xfffd4000 CONFIG_SPL_SYS_MALLOC_F_LEN=0x2000 CONFIG_DEBUG_UART_BASE=0x3f8 CONFIG_DEBUG_UART_CLOCK=1843200 @@ -17,12 +17,12 @@ CONFIG_DEBUG_UART=y CONFIG_SMP=y CONFIG_GENERATE_PIRQ_TABLE=y CONFIG_GENERATE_MP_TABLE=y -CONFIG_X86_OFFSET_U_BOOT=0xfff00000 +CONFIG_X86_OFFSET_U_BOOT=0xffe00000 +CONFIG_SYS_MONITOR_BASE=0x01110000 CONFIG_FIT=y CONFIG_SPL_LOAD_FIT=y CONFIG_BOOTSTD_FULL=y CONFIG_BOOTSTD_DEFAULTS=y -CONFIG_SYS_MONITOR_BASE=0x01110000 CONFIG_BOOTSTAGE=y CONFIG_BOOTSTAGE_REPORT=y CONFIG_SHOW_BOOT_PROGRESS=y
Enable this feature to provide a larger font choice and more attractive menus. Expand the ROM for x86_64 to 2MB to make space for the font.
Signed-off-by: Simon Glass sjg@chromium.org ---
Changes in v3: - Add new patch to enable truetype fonts in qemu-x86 and qemu-x86_64
configs/qemu-x86_64_defconfig | 1 + configs/qemu-x86_defconfig | 1 + 2 files changed, 2 insertions(+)
diff --git a/configs/qemu-x86_64_defconfig b/configs/qemu-x86_64_defconfig index 6de3da2d8269..c73d3f96e53d 100644 --- a/configs/qemu-x86_64_defconfig +++ b/configs/qemu-x86_64_defconfig @@ -83,6 +83,7 @@ CONFIG_SPL_DM_RTC=y CONFIG_SYS_NS16550_PORT_MAPPED=y CONFIG_SPI=y CONFIG_USB_KEYBOARD=y +CONFIG_CONSOLE_TRUETYPE=y CONFIG_FRAMEBUFFER_SET_VESA_MODE=y CONFIG_FRAMEBUFFER_VESA_MODE_USER=y CONFIG_FRAMEBUFFER_VESA_MODE=0x144 diff --git a/configs/qemu-x86_defconfig b/configs/qemu-x86_defconfig index 4b2787d4aaef..123d5ad63e53 100644 --- a/configs/qemu-x86_defconfig +++ b/configs/qemu-x86_defconfig @@ -60,6 +60,7 @@ CONFIG_NVME_PCI=y CONFIG_SYS_NS16550_PORT_MAPPED=y CONFIG_SPI=y CONFIG_USB_KEYBOARD=y +CONFIG_CONSOLE_TRUETYPE=y CONFIG_FRAMEBUFFER_SET_VESA_MODE=y CONFIG_FRAMEBUFFER_VESA_MODE_USER=y CONFIG_FRAMEBUFFER_VESA_MODE=0x144
participants (4)
-
Anatolij Gustschin -
Bin Meng -
Simon Glass -
Tom Rini