[PATCH v3 00/12] Resolve issues with booting distros on x86

[PATCH v3 00/12] Resolve issues with booting distros on x86

[Simon Glass]

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

-- 
2.42.0.582.g8ccd20d70d-goog

[PATCH v3 01/12] efi: Correct handling of frame buffer

[Simon Glass]

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;
 }
-- 
2.42.0.582.g8ccd20d70d-goog

Re: [PATCH v3 01/12] efi: Correct handling of frame buffer

[Bin Meng]

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>

Re: [PATCH v3 01/12] efi: Correct handling of frame buffer

[Simon Glass]

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!

[PATCH v3 02/12] bootstd: Refactor mmc prep to allow a different scan

[Simon Glass]

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");
-- 
2.42.0.582.g8ccd20d70d-goog

[PATCH v3 03/12] bootstd: Add a return code to bootflow menu

[Simon Glass]

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;
-- 
2.42.0.582.g8ccd20d70d-goog

[PATCH v3 04/12] x86: coreboot: Add a boot script

[Simon Glass]

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
-- 
2.42.0.582.g8ccd20d70d-goog

Re: [PATCH v3 04/12] x86: coreboot: Add a boot script

[Bin Meng]

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>

[PATCH v3 05/12] usb: Avoid unbinding devices in use by bootflows

[Simon Glass]

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 */
 
 
-- 
2.42.0.582.g8ccd20d70d-goog

[PATCH v3 06/12] expo: Correct background colour

[Simon Glass]

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);
-- 
2.42.0.582.g8ccd20d70d-goog

Re: [PATCH v3 06/12] expo: Correct background colour

[Bin Meng]

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>

Re: [PATCH v3 06/12] expo: Correct background colour

[Simon Glass]

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!

[PATCH v3 07/12] video: Correct setting of cursor position

[Simon Glass]

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

Re: [PATCH v3 07/12] video: Correct setting of cursor position

[Simon Glass]

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

Re: [PATCH v3 07/12] video: Correct setting of cursor position

[Anatolij Gustschin]

Hi Simon,

On Sun, 12 Nov 2023 13:01:11 -0700
Simon Glass sjg@chromium.org wrote:
...  
> 
> Any thoughts on this patch, please?

looks good to me, thanks.

--
Anatolij

Re: [PATCH v3 07/12] video: Correct setting of cursor position

[Anatolij Gustschin]

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>

[PATCH v3 08/12] video: Drop unnecessary truetype operations from SPL

[Simon Glass]

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;
 
-- 
2.42.0.582.g8ccd20d70d-goog

Re: [PATCH v3 08/12] video: Drop unnecessary truetype operations from SPL

[Bin Meng]

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>

[PATCH v3 09/12] x86: Enable SSE in 64-bit mode

[Simon Glass]

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;
 }
-- 
2.42.0.582.g8ccd20d70d-goog

Re: [PATCH v3 09/12] x86: Enable SSE in 64-bit mode

[Bin Meng]

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

Re: [PATCH v3 09/12] x86: Enable SSE in 64-bit mode

[Simon Glass]

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

Re: [PATCH v3 09/12] x86: Enable SSE in 64-bit mode

[Bin Meng]

+ 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

Re: [PATCH v3 09/12] x86: Enable SSE in 64-bit mode

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1878 bytes --]

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.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH v3 09/12] x86: Enable SSE in 64-bit mode

[Simon Glass]

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

Re: [PATCH v3 09/12] x86: Enable SSE in 64-bit mode

[Bin Meng]

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

Re: [PATCH v3 09/12] x86: Enable SSE in 64-bit mode

[Simon Glass]

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@chromium.org/

So perhaps move it to arch/Kconfig , rename it to HARDFP and update
the help to be more generic?

Regards,
Simon

Re: [PATCH v3 09/12] x86: Enable SSE in 64-bit mode

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3065 bytes --]

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.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH v3 09/12] x86: Enable SSE in 64-bit mode

[Simon Glass]

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

[PATCH v3 10/12] x86: coreboot: Enable truetype fonts

[Simon Glass]

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
-- 
2.42.0.582.g8ccd20d70d-goog

[PATCH v3 11/12] x86: qemu: Expand ROM size

[Simon Glass]

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
-- 
2.42.0.582.g8ccd20d70d-goog

[PATCH v3 12/12] x86: qemu: Enable truetype fonts

[Simon Glass]

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
-- 
2.42.0.582.g8ccd20d70d-goog

Re: [PATCH v3 03/12] bootstd: Add a return code to bootflow menu

[Simon Glass]

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!

Re: [PATCH v3 02/12] bootstd: Refactor mmc prep to allow a different scan

[Simon Glass]

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!