* [PATCH v2 1/4] arm: qemu: Enable Bochs video support
2023-08-14 17:39 [PATCH v2 0/4] arm: qemu: Enable Bochs, console buffering, USB keyboard Alper Nebi Yasak
@ 2023-08-14 17:39 ` Alper Nebi Yasak
2023-08-14 17:39 ` [PATCH v2 2/4] arm: qemu: Enable PRE_CONSOLE_BUFFER Alper Nebi Yasak
` (3 subsequent siblings)
4 siblings, 0 replies; 14+ messages in thread
From: Alper Nebi Yasak @ 2023-08-14 17:39 UTC (permalink / raw)
To: u-boot
Cc: Simon Glass, Michal Simek, Tom Rini, Bin Meng, Tuomas Tynkkynen,
Bharat Gooty, Stefan Roese, Qu Wenruo, Rayagonda Kokatanur,
Bin Meng, Ilias Apalodimas, Neil Armstrong, Alper Nebi Yasak
Commit 716161663ec49 ("riscv: qemu: Enable Bochs video support") enables
a video console for QEMU RISC-V virtual machines using an emulated Bochs
VGA card. Similarly, enable it for ARM virtual machines as well.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Bin Meng <bmeng@tinylab.org>
---
Changes in v2:
- Add tag: "Reviewed-by: Bin Meng <bmeng@tinylab.org>"
arch/arm/Kconfig | 4 ++++
board/emulation/qemu-arm/qemu-arm.env | 3 +++
doc/board/emulation/qemu-arm.rst | 4 ++++
3 files changed, 11 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 97c25b4f146d..0d4654fb9dfc 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1036,6 +1036,10 @@ config ARCH_QEMU
imply DM_RTC
imply RTC_PL031
imply OF_HAS_PRIOR_STAGE
+ imply VIDEO
+ imply VIDEO_BOCHS
+ imply SYS_WHITE_ON_BLACK
+ imply SYS_CONSOLE_IS_IN_ENV
config ARCH_RMOBILE
bool "Renesas ARM SoCs"
diff --git a/board/emulation/qemu-arm/qemu-arm.env b/board/emulation/qemu-arm/qemu-arm.env
index e658d5ee7d63..86a99a2e8713 100644
--- a/board/emulation/qemu-arm/qemu-arm.env
+++ b/board/emulation/qemu-arm/qemu-arm.env
@@ -2,6 +2,9 @@
/* environment for qemu-arm and qemu-arm64 */
+stdin=serial
+stdout=serial,vidconsole
+stderr=serial,vidconsole
fdt_high=0xffffffff
initrd_high=0xffffffff
fdt_addr=0x40000000
diff --git a/doc/board/emulation/qemu-arm.rst b/doc/board/emulation/qemu-arm.rst
index b42d924cc66a..1108fe5f8184 100644
--- a/doc/board/emulation/qemu-arm.rst
+++ b/doc/board/emulation/qemu-arm.rst
@@ -67,6 +67,10 @@ Additional persistent U-Boot environment support can be added as follows:
Additional peripherals that have been tested to work in both U-Boot and Linux
can be enabled with the following command line parameters:
+- To add a video console, remove "-nographic" and add e.g.::
+
+ -serial stdio -device VGA
+
- To add a Serial ATA disk via an Intel ICH9 AHCI controller, pass e.g.::
-drive if=none,file=disk.img,format=raw,id=mydisk \
--
2.40.1
^ permalink raw reply related [flat|nested] 14+ messages in thread* [PATCH v2 2/4] arm: qemu: Enable PRE_CONSOLE_BUFFER
2023-08-14 17:39 [PATCH v2 0/4] arm: qemu: Enable Bochs, console buffering, USB keyboard Alper Nebi Yasak
2023-08-14 17:39 ` [PATCH v2 1/4] arm: qemu: Enable Bochs video support Alper Nebi Yasak
@ 2023-08-14 17:39 ` Alper Nebi Yasak
2023-08-14 17:39 ` [PATCH v2 3/4] arm: qemu: Enable usb keyboard as an input device Alper Nebi Yasak
` (2 subsequent siblings)
4 siblings, 0 replies; 14+ messages in thread
From: Alper Nebi Yasak @ 2023-08-14 17:39 UTC (permalink / raw)
To: u-boot
Cc: Simon Glass, Michal Simek, Tom Rini, Bin Meng, Tuomas Tynkkynen,
Bharat Gooty, Stefan Roese, Qu Wenruo, Rayagonda Kokatanur,
Bin Meng, Ilias Apalodimas, Neil Armstrong, Alper Nebi Yasak
Commit 608b80b5b855 ("riscv: qemu: Enable PRE_CONSOLE_BUFFER") enables
buffering console messages for QEMU RISC-V virtual machines so those
printed before the video console is available will still show up on the
display. Similarly, enable it for ARM virtual machines as well.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng@tinylab.org>
---
Here are select values from bdinfo and env:
DRAM bank = 0x0000000000000000
-> start = 0x0000000040000000
-> size = 0x0000000008000000
relocaddr = 0x00000000476d6000
fdt_blob = 0x0000000046595d90
lmb_dump_all:
memory.cnt = 0x1 / max = 0x10
memory[0] [0x40000000-0x47ffffff], 0x08000000 bytes flags: 0
reserved.cnt = 0x2 / max = 0x10
reserved[0] [0x45591000-0x47ffffff], 0x02a6f000 bytes flags: 0
reserved[1] [0x46591760-0x47ffffff], 0x01a6e8a0 bytes flags: 0
TLB addr = 0x0000000047fe0000
irq_sp = 0x0000000046595d80
sp start = 0x0000000046595d80
fdt_addr = 0x40000000
scriptaddr = 0x40200000
loadaddr = 0x40200000
pxefile_addr_r = 0x40300000
kernel_addr_r = 0x40400000
ramdisk_addr_r = 0x44000000
fdtcontroladdr = 465e5ea0
Changes in v2:
- Add tag: "Reviewed-by: Simon Glass <sjg@chromium.org>"
- Add tag: "Reviewed-by: Bin Meng <bmeng@tinylab.org>"
arch/arm/Kconfig | 1 +
board/emulation/qemu-arm/Kconfig | 4 ++++
2 files changed, 5 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0d4654fb9dfc..89b978797720 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1040,6 +1040,7 @@ config ARCH_QEMU
imply VIDEO_BOCHS
imply SYS_WHITE_ON_BLACK
imply SYS_CONSOLE_IS_IN_ENV
+ imply PRE_CONSOLE_BUFFER
config ARCH_RMOBILE
bool "Renesas ARM SoCs"
diff --git a/board/emulation/qemu-arm/Kconfig b/board/emulation/qemu-arm/Kconfig
index ed9949651c4b..09c95413a541 100644
--- a/board/emulation/qemu-arm/Kconfig
+++ b/board/emulation/qemu-arm/Kconfig
@@ -12,6 +12,10 @@ config BOARD_SPECIFIC_OPTIONS # dummy
imply VIRTIO_NET
imply VIRTIO_BLK
+config PRE_CON_BUF_ADDR
+ hex
+ default 0x40100000
+
endif
if TARGET_QEMU_ARM_64BIT && !TFABOOT
--
2.40.1
^ permalink raw reply related [flat|nested] 14+ messages in thread* [PATCH v2 3/4] arm: qemu: Enable usb keyboard as an input device
2023-08-14 17:39 [PATCH v2 0/4] arm: qemu: Enable Bochs, console buffering, USB keyboard Alper Nebi Yasak
2023-08-14 17:39 ` [PATCH v2 1/4] arm: qemu: Enable Bochs video support Alper Nebi Yasak
2023-08-14 17:39 ` [PATCH v2 2/4] arm: qemu: Enable PRE_CONSOLE_BUFFER Alper Nebi Yasak
@ 2023-08-14 17:39 ` Alper Nebi Yasak
2023-08-14 17:39 ` [PATCH v2 4/4] doc: qemu: arm: Add a section on booting Linux distros Alper Nebi Yasak
2023-08-24 21:44 ` [PATCH v2 0/4] arm: qemu: Enable Bochs, console buffering, USB keyboard Tom Rini
4 siblings, 0 replies; 14+ messages in thread
From: Alper Nebi Yasak @ 2023-08-14 17:39 UTC (permalink / raw)
To: u-boot
Cc: Simon Glass, Michal Simek, Tom Rini, Bin Meng, Tuomas Tynkkynen,
Bharat Gooty, Stefan Roese, Qu Wenruo, Rayagonda Kokatanur,
Bin Meng, Ilias Apalodimas, Neil Armstrong, Alper Nebi Yasak
Commit 02be57caf730 ("riscv: qemu: Enable usb keyboard as an input
device") adds PCI xHCI support to QEMU RISC-V virtual machines and
enables using a USB keyboard as one of the input devices. Similarly,
enable those for ARM virtual machines as well.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng@tinylab.org>
---
Changes in v2:
- Add tag: "Reviewed-by: Simon Glass <sjg@chromium.org>"
- Add tag: "Reviewed-by: Bin Meng <bmeng@tinylab.org>"
arch/arm/Kconfig | 5 +++++
board/emulation/qemu-arm/qemu-arm.c | 5 +++++
board/emulation/qemu-arm/qemu-arm.env | 2 +-
configs/qemu_arm64_defconfig | 2 --
configs/qemu_arm_defconfig | 2 --
doc/board/emulation/qemu-arm.rst | 4 ++++
6 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 89b978797720..1fd3ccd1607f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1041,6 +1041,11 @@ config ARCH_QEMU
imply SYS_WHITE_ON_BLACK
imply SYS_CONSOLE_IS_IN_ENV
imply PRE_CONSOLE_BUFFER
+ imply USB
+ imply USB_XHCI_HCD
+ imply USB_XHCI_PCI
+ imply USB_KEYBOARD
+ imply CMD_USB
config ARCH_RMOBILE
bool "Renesas ARM SoCs"
diff --git a/board/emulation/qemu-arm/qemu-arm.c b/board/emulation/qemu-arm/qemu-arm.c
index dfea0d92a3c8..942f1fff5717 100644
--- a/board/emulation/qemu-arm/qemu-arm.c
+++ b/board/emulation/qemu-arm/qemu-arm.c
@@ -11,6 +11,7 @@
#include <fdtdec.h>
#include <init.h>
#include <log.h>
+#include <usb.h>
#include <virtio_types.h>
#include <virtio.h>
@@ -114,6 +115,10 @@ int board_late_init(void)
*/
virtio_init();
+ /* start usb so that usb keyboard can be used as input device */
+ if (CONFIG_IS_ENABLED(USB_KEYBOARD))
+ usb_init();
+
return 0;
}
diff --git a/board/emulation/qemu-arm/qemu-arm.env b/board/emulation/qemu-arm/qemu-arm.env
index 86a99a2e8713..fb4adef281ed 100644
--- a/board/emulation/qemu-arm/qemu-arm.env
+++ b/board/emulation/qemu-arm/qemu-arm.env
@@ -2,7 +2,7 @@
/* environment for qemu-arm and qemu-arm64 */
-stdin=serial
+stdin=serial,usbkbd
stdout=serial,vidconsole
stderr=serial,vidconsole
fdt_high=0xffffffff
diff --git a/configs/qemu_arm64_defconfig b/configs/qemu_arm64_defconfig
index 94bd96678443..f6b8ae530a4a 100644
--- a/configs/qemu_arm64_defconfig
+++ b/configs/qemu_arm64_defconfig
@@ -35,7 +35,6 @@ CONFIG_CMD_NVEDIT_EFI=y
CONFIG_CMD_DFU=y
CONFIG_CMD_MTD=y
CONFIG_CMD_PCI=y
-CONFIG_CMD_USB=y
CONFIG_CMD_TPM=y
CONFIG_CMD_MTDPARTS=y
CONFIG_ENV_IS_IN_FLASH=y
@@ -68,7 +67,6 @@ CONFIG_SYSRESET=y
CONFIG_SYSRESET_CMD_POWEROFF=y
CONFIG_SYSRESET_PSCI=y
CONFIG_TPM2_MMIO=y
-CONFIG_USB=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_PCI=y
CONFIG_TPM=y
diff --git a/configs/qemu_arm_defconfig b/configs/qemu_arm_defconfig
index 7cb1e9f037ff..1347b86f34b1 100644
--- a/configs/qemu_arm_defconfig
+++ b/configs/qemu_arm_defconfig
@@ -36,7 +36,6 @@ CONFIG_CMD_NVEDIT_EFI=y
CONFIG_CMD_DFU=y
CONFIG_CMD_MTD=y
CONFIG_CMD_PCI=y
-CONFIG_CMD_USB=y
CONFIG_CMD_TPM=y
CONFIG_CMD_MTDPARTS=y
CONFIG_ENV_IS_IN_FLASH=y
@@ -69,7 +68,6 @@ CONFIG_SYSRESET=y
CONFIG_SYSRESET_CMD_POWEROFF=y
CONFIG_SYSRESET_PSCI=y
CONFIG_TPM2_MMIO=y
-CONFIG_USB=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_PCI=y
CONFIG_TPM=y
diff --git a/doc/board/emulation/qemu-arm.rst b/doc/board/emulation/qemu-arm.rst
index 1108fe5f8184..8ec5349fc9ea 100644
--- a/doc/board/emulation/qemu-arm.rst
+++ b/doc/board/emulation/qemu-arm.rst
@@ -84,6 +84,10 @@ can be enabled with the following command line parameters:
-device usb-ehci,id=ehci
+- To add a USB keyboard attached to an emulated xHCI controller, pass e.g.::
+
+ -device qemu-xhci,id=xhci -device usb-kbd,bus=xhci.0
+
- To add an NVMe disk, pass e.g.::
-drive if=none,file=disk.img,id=mydisk -device nvme,drive=mydisk,serial=foo
--
2.40.1
^ permalink raw reply related [flat|nested] 14+ messages in thread* [PATCH v2 4/4] doc: qemu: arm: Add a section on booting Linux distros
2023-08-14 17:39 [PATCH v2 0/4] arm: qemu: Enable Bochs, console buffering, USB keyboard Alper Nebi Yasak
` (2 preceding siblings ...)
2023-08-14 17:39 ` [PATCH v2 3/4] arm: qemu: Enable usb keyboard as an input device Alper Nebi Yasak
@ 2023-08-14 17:39 ` Alper Nebi Yasak
2023-08-14 22:43 ` Simon Glass
2023-08-24 21:44 ` [PATCH v2 0/4] arm: qemu: Enable Bochs, console buffering, USB keyboard Tom Rini
4 siblings, 1 reply; 14+ messages in thread
From: Alper Nebi Yasak @ 2023-08-14 17:39 UTC (permalink / raw)
To: u-boot
Cc: Simon Glass, Michal Simek, Tom Rini, Bin Meng, Tuomas Tynkkynen,
Bharat Gooty, Stefan Roese, Qu Wenruo, Rayagonda Kokatanur,
Bin Meng, Ilias Apalodimas, Neil Armstrong, Alper Nebi Yasak
Add an example qemu-system-aarch64 command that can make U-Boot on QEMU
boot into the Debian Installer, along with resulting console messages
from U-Boot, based on the existing documentation section for the x86
version.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
---
I actually want to put the root.img device first so that the VM can boot
into the installed system when it reboots, but U-Boot can't find the
bootflow on the second drive. I tried e.g. `bootdev list -p; bootflow
scan -lab`, but it seems to only ever search the first virtio-blk.
However, `eficonfig; bootefi bootmgr` makes it boot somehow.
Changes in v2:
- Add new patch for doc section on booting Linux distros
doc/board/emulation/qemu-arm.rst | 68 ++++++++++++++++++++++++++++++++
1 file changed, 68 insertions(+)
diff --git a/doc/board/emulation/qemu-arm.rst b/doc/board/emulation/qemu-arm.rst
index 8ec5349fc9ea..78bcc3ee44c0 100644
--- a/doc/board/emulation/qemu-arm.rst
+++ b/doc/board/emulation/qemu-arm.rst
@@ -98,6 +98,74 @@ can be enabled with the following command line parameters:
These have been tested in QEMU 2.9.0 but should work in at least 2.5.0 as well.
+Booting distros
+---------------
+
+It is possible to install and boot a standard Linux distribution using
+qemu_arm64 by setting up a root disk::
+
+ qemu-img create root.img 20G
+
+then using the installer to install. For example, with Debian 12::
+
+ qemu-system-aarch64 \
+ -machine virt -cpu cortex-a53 -m 4G -smp 4 \
+ -bios u-boot.bin \
+ -serial stdio -device VGA \
+ -nic user,model=virtio-net-pci \
+ -device virtio-rng-pci \
+ -device qemu-xhci,id=xhci \
+ -device usb-kbd -device usb-tablet \
+ -drive if=virtio,file=debian-12.0.0-arm64-netinst.iso,format=raw,readonly=on,media=cdrom \
+ -drive if=virtio,file=root.img,format=raw,media=disk
+
+The output will be something like this::
+
+ U-Boot 2023.10-rc2-00075-gbe8fbe718e35 (Aug 11 2023 - 08:38:49 +0000)
+
+ DRAM: 4 GiB
+ Core: 51 devices, 14 uclasses, devicetree: board
+ Flash: 64 MiB
+ Loading Environment from Flash... *** Warning - bad CRC, using default environment
+
+ In: serial,usbkbd
+ Out: serial,vidconsole
+ Err: serial,vidconsole
+ Bus xhci_pci: Register 8001040 NbrPorts 8
+ Starting the controller
+ USB XHCI 1.00
+ scanning bus xhci_pci for devices... 3 USB Device(s) found
+ Net: eth0: virtio-net#32
+ Hit any key to stop autoboot: 0
+ Scanning for bootflows in all bootdevs
+ Seq Method State Uclass Part Name Filename
+ --- ----------- ------ -------- ---- ------------------------ ----------------
+ Scanning global bootmeth 'efi_mgr':
+ Scanning bootdev 'fw-cfg@9020000.bootdev':
+ fatal: no kernel available
+ scanning bus for devices...
+ Scanning bootdev 'virtio-blk#34.bootdev':
+ 0 efi ready virtio 2 virtio-blk#34.bootdev.par efi/boot/bootaa64.efi
+ ** Booting bootflow 'virtio-blk#34.bootdev.part_2' with efi
+ Using prior-stage device tree
+ Failed to load EFI variables
+ Error: writing contents
+ ** Unable to write file ubootefi.var **
+ Failed to persist EFI variables
+ Missing TPMv2 device for EFI_TCG_PROTOCOL
+ Booting /efi\boot\bootaa64.efi
+ Error: writing contents
+ ** Unable to write file ubootefi.var **
+ Failed to persist EFI variables
+ Welcome to GRUB!
+
+Standard boot looks through various available devices and finds the virtio
+disks, then boots from the first one. After a second or so the grub menu appears
+and you can work through the installer flow normally.
+
+After the installation, you can boot into the installed system by running QEMU
+again without the drive argument corresponding to the installer CD image.
+
Enabling TPMv2 support
----------------------
--
2.40.1
^ permalink raw reply related [flat|nested] 14+ messages in thread* Re: [PATCH v2 4/4] doc: qemu: arm: Add a section on booting Linux distros
2023-08-14 17:39 ` [PATCH v2 4/4] doc: qemu: arm: Add a section on booting Linux distros Alper Nebi Yasak
@ 2023-08-14 22:43 ` Simon Glass
2023-08-27 15:49 ` Alper Nebi Yasak
0 siblings, 1 reply; 14+ messages in thread
From: Simon Glass @ 2023-08-14 22:43 UTC (permalink / raw)
To: Alper Nebi Yasak
Cc: u-boot, Michal Simek, Tom Rini, Bin Meng, Tuomas Tynkkynen,
Bharat Gooty, Stefan Roese, Qu Wenruo, Rayagonda Kokatanur,
Bin Meng, Ilias Apalodimas, Neil Armstrong
Hi Alper,
On Mon, 14 Aug 2023 at 11:40, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
>
> Add an example qemu-system-aarch64 command that can make U-Boot on QEMU
> boot into the Debian Installer, along with resulting console messages
> from U-Boot, based on the existing documentation section for the x86
> version.
>
> Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
> ---
> I actually want to put the root.img device first so that the VM can boot
> into the installed system when it reboots, but U-Boot can't find the
> bootflow on the second drive. I tried e.g. `bootdev list -p; bootflow
> scan -lab`, but it seems to only ever search the first virtio-blk.
> However, `eficonfig; bootefi bootmgr` makes it boot somehow.
Yes, this is annoying.
The problem is that the scanning is getting so complicated. The
boot_targets var lists things which can either be a uclass, or a
uclass with a device number. The currently implementation sees
"virtio" and moves on to the next thing in boot_targets once it has
processed one virtio device. That is obviously not correct, but...
Would it be possible to just drop the 'boot_targets' var? That is what
is stuffing it up, but we don't actually need it now. The defaults end
up doing the same thing, apart (perhaps) from the strangeness of
virtio which can be both a network and a blk device.
I believe it is possible to do the right thing, but I'll need to
create a better test mechanism to handle all the cases.
>
> Changes in v2:
> - Add new patch for doc section on booting Linux distros
>
> doc/board/emulation/qemu-arm.rst | 68 ++++++++++++++++++++++++++++++++
> 1 file changed, 68 insertions(+)
>
Regards,
Simon
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2 4/4] doc: qemu: arm: Add a section on booting Linux distros
2023-08-14 22:43 ` Simon Glass
@ 2023-08-27 15:49 ` Alper Nebi Yasak
2023-08-28 17:54 ` Simon Glass
2023-08-30 7:33 ` Ilias Apalodimas
0 siblings, 2 replies; 14+ messages in thread
From: Alper Nebi Yasak @ 2023-08-27 15:49 UTC (permalink / raw)
To: Simon Glass
Cc: u-boot, Michal Simek, Tom Rini, Bin Meng, Tuomas Tynkkynen,
Bharat Gooty, Stefan Roese, Qu Wenruo, Rayagonda Kokatanur,
Bin Meng, Ilias Apalodimas, Neil Armstrong
On 2023-08-15 01:43 +03:00, Simon Glass wrote:
> Hi Alper,
>
> On Mon, 14 Aug 2023 at 11:40, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
>> I actually want to put the root.img device first so that the VM can boot
>> into the installed system when it reboots, but U-Boot can't find the
>> bootflow on the second drive. I tried e.g. `bootdev list -p; bootflow
>> scan -lab`, but it seems to only ever search the first virtio-blk.
>> However, `eficonfig; bootefi bootmgr` makes it boot somehow.
>
> Yes, this is annoying.
>
> The problem is that the scanning is getting so complicated. The
> boot_targets var lists things which can either be a uclass, or a
> uclass with a device number. The currently implementation sees
> "virtio" and moves on to the next thing in boot_targets once it has
> processed one virtio device. That is obviously not correct, but...
>
> Would it be possible to just drop the 'boot_targets' var? That is what
> is stuffing it up, but we don't actually need it now. The defaults end
> up doing the same thing, apart (perhaps) from the strangeness of
> virtio which can be both a network and a blk device.
>
> I believe it is possible to do the right thing, but I'll need to
> create a better test mechanism to handle all the cases.
I think some kind of a "priority score" could help -- iterate over
boot_targets first just to generate bootdev priorities, then carry them
over as bootflows are discovered (adjusted for bootmeth order), then use
those scores as the order to boot / to show a sorted menu / to test?
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2 4/4] doc: qemu: arm: Add a section on booting Linux distros
2023-08-27 15:49 ` Alper Nebi Yasak
@ 2023-08-28 17:54 ` Simon Glass
2023-08-31 9:57 ` Alper Nebi Yasak
2023-08-30 7:33 ` Ilias Apalodimas
1 sibling, 1 reply; 14+ messages in thread
From: Simon Glass @ 2023-08-28 17:54 UTC (permalink / raw)
To: Alper Nebi Yasak
Cc: u-boot, Michal Simek, Tom Rini, Bin Meng, Tuomas Tynkkynen,
Bharat Gooty, Stefan Roese, Qu Wenruo, Rayagonda Kokatanur,
Bin Meng, Ilias Apalodimas, Neil Armstrong
Hi Alper,
On Sun, 27 Aug 2023 at 09:49, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
>
> On 2023-08-15 01:43 +03:00, Simon Glass wrote:
> > Hi Alper,
> >
> > On Mon, 14 Aug 2023 at 11:40, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
> >> I actually want to put the root.img device first so that the VM can boot
> >> into the installed system when it reboots, but U-Boot can't find the
> >> bootflow on the second drive. I tried e.g. `bootdev list -p; bootflow
> >> scan -lab`, but it seems to only ever search the first virtio-blk.
> >> However, `eficonfig; bootefi bootmgr` makes it boot somehow.
> >
> > Yes, this is annoying.
> >
> > The problem is that the scanning is getting so complicated. The
> > boot_targets var lists things which can either be a uclass, or a
> > uclass with a device number. The currently implementation sees
> > "virtio" and moves on to the next thing in boot_targets once it has
> > processed one virtio device. That is obviously not correct, but...
> >
> > Would it be possible to just drop the 'boot_targets' var? That is what
> > is stuffing it up, but we don't actually need it now. The defaults end
> > up doing the same thing, apart (perhaps) from the strangeness of
> > virtio which can be both a network and a blk device.
> >
> > I believe it is possible to do the right thing, but I'll need to
> > create a better test mechanism to handle all the cases.
>
> I think some kind of a "priority score" could help -- iterate over
> boot_targets first just to generate bootdev priorities, then carry them
> over as bootflows are discovered (adjusted for bootmeth order), then use
> those scores as the order to boot / to show a sorted menu / to test?
We sort-of have that, in that bootdevs have a priority. We could add
something to struct bootflow which takes that but adds more
fine-grained information, e.g. based on some sort of filter function
that can decide?
Bear in mind that we normally want to boot the first thing we find,
and we also want to use lazy init (so no USB unless we need it). But
yes for the case where we display a menu I think we could make more of
the priority feature. What are you thinking of?
BTW, even for the menu, my original vision was that the menu would
display immediately, with new bootflows appearing as they are
discovered.
Regards,
Simon
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2 4/4] doc: qemu: arm: Add a section on booting Linux distros
2023-08-28 17:54 ` Simon Glass
@ 2023-08-31 9:57 ` Alper Nebi Yasak
2023-08-31 19:01 ` Simon Glass
0 siblings, 1 reply; 14+ messages in thread
From: Alper Nebi Yasak @ 2023-08-31 9:57 UTC (permalink / raw)
To: Simon Glass
Cc: u-boot, Michal Simek, Tom Rini, Bin Meng, Tuomas Tynkkynen,
Bharat Gooty, Stefan Roese, Qu Wenruo, Rayagonda Kokatanur,
Bin Meng, Ilias Apalodimas, Neil Armstrong
On 2023-08-28 20:54 +03:00, Simon Glass wrote:
> Hi Alper,
>
> On Sun, 27 Aug 2023 at 09:49, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
>>
>> On 2023-08-15 01:43 +03:00, Simon Glass wrote:
>>> Hi Alper,
>>>
>>> On Mon, 14 Aug 2023 at 11:40, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
>>>> I actually want to put the root.img device first so that the VM can boot
>>>> into the installed system when it reboots, but U-Boot can't find the
>>>> bootflow on the second drive. I tried e.g. `bootdev list -p; bootflow
>>>> scan -lab`, but it seems to only ever search the first virtio-blk.
>>>> However, `eficonfig; bootefi bootmgr` makes it boot somehow.
>>>
>>> Yes, this is annoying.
>>>
>>> The problem is that the scanning is getting so complicated. The
>>> boot_targets var lists things which can either be a uclass, or a
>>> uclass with a device number. The currently implementation sees
>>> "virtio" and moves on to the next thing in boot_targets once it has
>>> processed one virtio device. That is obviously not correct, but...
>>>
>>> Would it be possible to just drop the 'boot_targets' var? That is what
>>> is stuffing it up, but we don't actually need it now. The defaults end
>>> up doing the same thing, apart (perhaps) from the strangeness of
>>> virtio which can be both a network and a blk device.
>>>
>>> I believe it is possible to do the right thing, but I'll need to
>>> create a better test mechanism to handle all the cases.
>>
>> I think some kind of a "priority score" could help -- iterate over
>> boot_targets first just to generate bootdev priorities, then carry them
>> over as bootflows are discovered (adjusted for bootmeth order), then use
>> those scores as the order to boot / to show a sorted menu / to test?
>
> We sort-of have that, in that bootdevs have a priority. We could add
> something to struct bootflow which takes that but adds more
> fine-grained information, e.g. based on some sort of filter function
> that can decide?
>
> Bear in mind that we normally want to boot the first thing we find,
> and we also want to use lazy init (so no USB unless we need it). But
> yes for the case where we display a menu I think we could make more of
> the priority feature. What are you thinking of?
For the priorities, I'm thinking of ChromiumOS boot flow where there is
an in-method order that's different from the order we encounter things
in. And I'm also thinking of customizing boot order for same-uclass
device (I guess boot_targets="usb1 usb0" works?). And a bit worried
about if we would want to mix and match orders. If we say methA > methB
and dev0 > dev1, do we say methA-on-dev1 > methB-on-dev0 or the other
way? Not sure if I make sense here at all, need to think more on it.
In general, what I want is a graphical boot menu like rEFInd [1], but
more specifically with a better theme more like [2]. Or, at least to
support rEFInd better. (More bugs here, upstream builds don't start at
all with U-Boot, Debian builds boot on arm64 but not x86).
Regarding lazy init. If we don't init USB, rEFInd can't search USB
drives to boot things from it. Not sure if that's a fundamental problem
or there's some way for EFI apps to tell firmware to init USB etc.
[1] https://www.rodsbooks.com/refind/
[2] https://github.com/bobafetthotmail/refind-theme-regular
> BTW, even for the menu, my original vision was that the menu would
> display immediately, with new bootflows appearing as they are
> discovered.
Shifting list elements around while people are choosing from the list is
definitely not good, only way that could be OK is if the list was
append-only and not centered-in-append-direction.
We should be displaying a priority-sorted list, I'm not sure we can
guarantee we will add things in priority order, and I would like things
centered as personal preference...
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2 4/4] doc: qemu: arm: Add a section on booting Linux distros
2023-08-31 9:57 ` Alper Nebi Yasak
@ 2023-08-31 19:01 ` Simon Glass
0 siblings, 0 replies; 14+ messages in thread
From: Simon Glass @ 2023-08-31 19:01 UTC (permalink / raw)
To: Alper Nebi Yasak
Cc: u-boot, Michal Simek, Tom Rini, Bin Meng, Tuomas Tynkkynen,
Bharat Gooty, Stefan Roese, Qu Wenruo, Rayagonda Kokatanur,
Bin Meng, Ilias Apalodimas, Neil Armstrong
Hi Alper,
On Thu, 31 Aug 2023 at 03:57, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
>
> On 2023-08-28 20:54 +03:00, Simon Glass wrote:
> > Hi Alper,
> >
> > On Sun, 27 Aug 2023 at 09:49, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
> >>
> >> On 2023-08-15 01:43 +03:00, Simon Glass wrote:
> >>> Hi Alper,
> >>>
> >>> On Mon, 14 Aug 2023 at 11:40, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
> >>>> I actually want to put the root.img device first so that the VM can boot
> >>>> into the installed system when it reboots, but U-Boot can't find the
> >>>> bootflow on the second drive. I tried e.g. `bootdev list -p; bootflow
> >>>> scan -lab`, but it seems to only ever search the first virtio-blk.
> >>>> However, `eficonfig; bootefi bootmgr` makes it boot somehow.
> >>>
> >>> Yes, this is annoying.
> >>>
> >>> The problem is that the scanning is getting so complicated. The
> >>> boot_targets var lists things which can either be a uclass, or a
> >>> uclass with a device number. The currently implementation sees
> >>> "virtio" and moves on to the next thing in boot_targets once it has
> >>> processed one virtio device. That is obviously not correct, but...
> >>>
> >>> Would it be possible to just drop the 'boot_targets' var? That is what
> >>> is stuffing it up, but we don't actually need it now. The defaults end
> >>> up doing the same thing, apart (perhaps) from the strangeness of
> >>> virtio which can be both a network and a blk device.
> >>>
> >>> I believe it is possible to do the right thing, but I'll need to
> >>> create a better test mechanism to handle all the cases.
> >>
> >> I think some kind of a "priority score" could help -- iterate over
> >> boot_targets first just to generate bootdev priorities, then carry them
> >> over as bootflows are discovered (adjusted for bootmeth order), then use
> >> those scores as the order to boot / to show a sorted menu / to test?
> >
> > We sort-of have that, in that bootdevs have a priority. We could add
> > something to struct bootflow which takes that but adds more
> > fine-grained information, e.g. based on some sort of filter function
> > that can decide?
> >
> > Bear in mind that we normally want to boot the first thing we find,
> > and we also want to use lazy init (so no USB unless we need it). But
> > yes for the case where we display a menu I think we could make more of
> > the priority feature. What are you thinking of?
>
> For the priorities, I'm thinking of ChromiumOS boot flow where there is
> an in-method order that's different from the order we encounter things
> in. And I'm also thinking of customizing boot order for same-uclass
> device (I guess boot_targets="usb1 usb0" works?). And a bit worried
Yes
> about if we would want to mix and match orders. If we say methA > methB
> and dev0 > dev1, do we say methA-on-dev1 > methB-on-dev0 or the other
> way? Not sure if I make sense here at all, need to think more on it.
I hope not, but at least we have the data structures now and can do
these sorts of things.
>
> In general, what I want is a graphical boot menu like rEFInd [1], but
> more specifically with a better theme more like [2]. Or, at least to
> support rEFInd better. (More bugs here, upstream builds don't start at
> all with U-Boot, Debian builds boot on arm64 but not x86).
Could you implement that as a theme on the existing 'bootflow menu'?
It looks like you might be able to.
>
> Regarding lazy init. If we don't init USB, rEFInd can't search USB
> drives to boot things from it. Not sure if that's a fundamental problem
> or there's some way for EFI apps to tell firmware to init USB etc.
EFI sort-of has a fundamental problem here, I believe.
>
> [1] https://www.rodsbooks.com/refind/
> [2] https://github.com/bobafetthotmail/refind-theme-regular
>
> > BTW, even for the menu, my original vision was that the menu would
> > display immediately, with new bootflows appearing as they are
> > discovered.
>
> Shifting list elements around while people are choosing from the list is
> definitely not good, only way that could be OK is if the list was
> append-only and not centered-in-append-direction.
>
> We should be displaying a priority-sorted list, I'm not sure we can
> guarantee we will add things in priority order, and I would like things
> centered as personal preference...
Yes that is annoying, but all UIs do it these days. It is better to
display something, even if you have to move an existing thing. Two
other points:
1. The good news is that you are almost always adding at the end
2. This is often using the keyboard, so you can move the highlight
when you insert an earlier item
Regards,
Simon
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2 4/4] doc: qemu: arm: Add a section on booting Linux distros
2023-08-27 15:49 ` Alper Nebi Yasak
2023-08-28 17:54 ` Simon Glass
@ 2023-08-30 7:33 ` Ilias Apalodimas
2023-08-31 9:25 ` Alper Nebi Yasak
1 sibling, 1 reply; 14+ messages in thread
From: Ilias Apalodimas @ 2023-08-30 7:33 UTC (permalink / raw)
To: Alper Nebi Yasak
Cc: Simon Glass, u-boot, Michal Simek, Tom Rini, Bin Meng,
Tuomas Tynkkynen, Bharat Gooty, Stefan Roese, Qu Wenruo,
Rayagonda Kokatanur, Bin Meng, Neil Armstrong
Hi Alper,
On Sun, 27 Aug 2023 at 18:49, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
>
> On 2023-08-15 01:43 +03:00, Simon Glass wrote:
> > Hi Alper,
> >
> > On Mon, 14 Aug 2023 at 11:40, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
> >> I actually want to put the root.img device first so that the VM can boot
> >> into the installed system when it reboots, but U-Boot can't find the
> >> bootflow on the second drive. I tried e.g. `bootdev list -p; bootflow
> >> scan -lab`, but it seems to only ever search the first virtio-blk.
> >> However, `eficonfig; bootefi bootmgr` makes it boot somehow.
eficonfig, apart from displaying the boot options on a menu scans all
media that have a simple filesystem protocol installed and configures
the efi boot options. That's why bootefi bootmgr boots properly
afterwards. You can probably boot even without eficonfig, but only
bootXXX.efi files will be accounted for and no boot options will be
added.
The EFI spec describes the bootmgr functionality in detail. Back when
the bootmeth patches were added, I suggested we shouldn't deal with
EFI at all simply because it all already works and is backed by a
spec. Instead, we should just have a boot option in the methods that
spells "EFI" and let the bootmanager deal with the details. But
honestly, I've lost track of those patches.
Thanks
/Ilias
> >
> > Yes, this is annoying.
> >
> > The problem is that the scanning is getting so complicated. The
> > boot_targets var lists things which can either be a uclass, or a
> > uclass with a device number. The currently implementation sees
> > "virtio" and moves on to the next thing in boot_targets once it has
> > processed one virtio device. That is obviously not correct, but...
> >
> > Would it be possible to just drop the 'boot_targets' var? That is what
> > is stuffing it up, but we don't actually need it now. The defaults end
> > up doing the same thing, apart (perhaps) from the strangeness of
> > virtio which can be both a network and a blk device.
> >
> > I believe it is possible to do the right thing, but I'll need to
> > create a better test mechanism to handle all the cases.
>
> I think some kind of a "priority score" could help -- iterate over
> boot_targets first just to generate bootdev priorities, then carry them
> over as bootflows are discovered (adjusted for bootmeth order), then use
> those scores as the order to boot / to show a sorted menu / to test?
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2 4/4] doc: qemu: arm: Add a section on booting Linux distros
2023-08-30 7:33 ` Ilias Apalodimas
@ 2023-08-31 9:25 ` Alper Nebi Yasak
2023-09-01 8:08 ` Ilias Apalodimas
0 siblings, 1 reply; 14+ messages in thread
From: Alper Nebi Yasak @ 2023-08-31 9:25 UTC (permalink / raw)
To: Ilias Apalodimas
Cc: Simon Glass, u-boot, Michal Simek, Tom Rini, Bin Meng,
Tuomas Tynkkynen, Bharat Gooty, Stefan Roese, Qu Wenruo,
Rayagonda Kokatanur, Bin Meng, Neil Armstrong
On 2023-08-30 10:33 +03:00, Ilias Apalodimas wrote:
> Hi Alper,
>
> On Sun, 27 Aug 2023 at 18:49, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
>>
>> On 2023-08-15 01:43 +03:00, Simon Glass wrote:
>>> Hi Alper,
>>>
>>> On Mon, 14 Aug 2023 at 11:40, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
>>>> I actually want to put the root.img device first so that the VM can boot
>>>> into the installed system when it reboots, but U-Boot can't find the
>>>> bootflow on the second drive. I tried e.g. `bootdev list -p; bootflow
>>>> scan -lab`, but it seems to only ever search the first virtio-blk.
>>>> However, `eficonfig; bootefi bootmgr` makes it boot somehow.
>
> eficonfig, apart from displaying the boot options on a menu scans all
> media that have a simple filesystem protocol installed and configures
> the efi boot options. That's why bootefi bootmgr boots properly
> afterwards. You can probably boot even without eficonfig, but only
> bootXXX.efi files will be accounted for and no boot options will be
> added.
>
> The EFI spec describes the bootmgr functionality in detail. Back when
> the bootmeth patches were added, I suggested we shouldn't deal with
> EFI at all simply because it all already works and is backed by a
> spec. Instead, we should just have a boot option in the methods that
> spells "EFI" and let the bootmanager deal with the details. But
> honestly, I've lost track of those patches.
I think bootflow and EFI should be different views on top of a single
"what can we do now that we are in U-Boot" model. IIUIC it's possible
for e.g. UEFI Shell to be built-in boot entries, so we could expose
bootflow entries (and more) similar to those? And EFI-based secondary
bootloaders like rEFInd could let us choose them in a graphical menu,
efibootmgr could change their order or reboot into a non-EFI flow...
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2 4/4] doc: qemu: arm: Add a section on booting Linux distros
2023-08-31 9:25 ` Alper Nebi Yasak
@ 2023-09-01 8:08 ` Ilias Apalodimas
0 siblings, 0 replies; 14+ messages in thread
From: Ilias Apalodimas @ 2023-09-01 8:08 UTC (permalink / raw)
To: Alper Nebi Yasak
Cc: Simon Glass, u-boot, Michal Simek, Tom Rini, Bin Meng,
Tuomas Tynkkynen, Bharat Gooty, Stefan Roese, Qu Wenruo,
Rayagonda Kokatanur, Bin Meng, Neil Armstrong
On Thu, 31 Aug 2023 at 12:25, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
>
>
>
> On 2023-08-30 10:33 +03:00, Ilias Apalodimas wrote:
> > Hi Alper,
> >
> > On Sun, 27 Aug 2023 at 18:49, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
> >>
> >> On 2023-08-15 01:43 +03:00, Simon Glass wrote:
> >>> Hi Alper,
> >>>
> >>> On Mon, 14 Aug 2023 at 11:40, Alper Nebi Yasak <alpernebiyasak@gmail.com> wrote:
> >>>> I actually want to put the root.img device first so that the VM can boot
> >>>> into the installed system when it reboots, but U-Boot can't find the
> >>>> bootflow on the second drive. I tried e.g. `bootdev list -p; bootflow
> >>>> scan -lab`, but it seems to only ever search the first virtio-blk.
> >>>> However, `eficonfig; bootefi bootmgr` makes it boot somehow.
> >
> > eficonfig, apart from displaying the boot options on a menu scans all
> > media that have a simple filesystem protocol installed and configures
> > the efi boot options. That's why bootefi bootmgr boots properly
> > afterwards. You can probably boot even without eficonfig, but only
> > bootXXX.efi files will be accounted for and no boot options will be
> > added.
> >
> > The EFI spec describes the bootmgr functionality in detail. Back when
> > the bootmeth patches were added, I suggested we shouldn't deal with
> > EFI at all simply because it all already works and is backed by a
> > spec. Instead, we should just have a boot option in the methods that
> > spells "EFI" and let the bootmanager deal with the details. But
> > honestly, I've lost track of those patches.
>
> I think bootflow and EFI should be different views on top of a single
> "what can we do now that we are in U-Boot" model. IIUIC it's possible
> for e.g. UEFI Shell to be built-in boot entries, so we could expose
> bootflow entries (and more) similar to those?
I am not sure I am following you here. The EfiShell is an
application. You can use 'eficonfig' to add/delete boot entries for
EFI, which will appear on a menu.
> And EFI-based secondary
> bootloaders like rEFInd could let us choose them in a graphical menu,
> efibootmgr could change their order or reboot into a non-EFI flow...
I'll have to check rEFInd, but I think it looks for PE/COFF binaries?
Thanks
/Ilias
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2 0/4] arm: qemu: Enable Bochs, console buffering, USB keyboard
2023-08-14 17:39 [PATCH v2 0/4] arm: qemu: Enable Bochs, console buffering, USB keyboard Alper Nebi Yasak
` (3 preceding siblings ...)
2023-08-14 17:39 ` [PATCH v2 4/4] doc: qemu: arm: Add a section on booting Linux distros Alper Nebi Yasak
@ 2023-08-24 21:44 ` Tom Rini
4 siblings, 0 replies; 14+ messages in thread
From: Tom Rini @ 2023-08-24 21:44 UTC (permalink / raw)
To: Alper Nebi Yasak
Cc: u-boot, Simon Glass, Michal Simek, Bin Meng, Tuomas Tynkkynen,
Bharat Gooty, Stefan Roese, Qu Wenruo, Rayagonda Kokatanur,
Bin Meng, Ilias Apalodimas, Neil Armstrong
[-- Attachment #1: Type: text/plain, Size: 1819 bytes --]
On Mon, Aug 14, 2023 at 08:39:40PM +0300, Alper Nebi Yasak wrote:
> Now that the driver for the Bochs VGA card emulated by QEMU is no longer
> limited to x86 architectures [1], this series enables it on arm and
> arm64 virtual machines to provide a graphical interface. In line with
> that series this also enables console buffering and USB keyboard.
>
> Tested with the Debian 12 installer using GRUB EFI:
>
> $ tools/buildman/buildman -o build/qemu_arm64 --boards=qemu_arm64 -w
> $ cd build/qemu_arm64
> $ curl -L -o debian.img \
> https://cdimage.debian.org/debian-cd/current/arm64/iso-cd/debian-12.0.0-arm64-netinst.iso
> $ qemu-system-aarch64 \
> -machine virt -cpu cortex-a53 -m 4G -smp 4 \
> -bios u-boot.bin \
> -serial stdio -device VGA \
> -nic user,model=virtio-net-pci \
> -device virtio-rng-pci \
> -device qemu-xhci,id=xhci -device usb-kbd -device usb-tablet \
> -drive if=virtio,file=debian.img,format=raw,readonly=on,media=cdrom
>
> And with one using extlinux.conf:
>
> $ [...]
> $ curl -L -o head.img.gz \
> https://deb.debian.org/debian/dists/bookworm/main/installer-arm64/current/images/netboot/SD-card-images/gtk/firmware.none.img.gz
> $ curl -L -o partition.img.gz \
> https://deb.debian.org/debian/dists/bookworm/main/installer-arm64/current/images/netboot/SD-card-images/gtk/partition.img.gz
> $ zcat head.img.gz partition.img.gz >debian.img
> $ [...]
>
> Both can get to a graphical installer just fine, in addition to U-Boot
> video console showing up in a GTK window.
>
> [1] video: bochs: Remove the x86 limitation
> https://lore.kernel.org/u-boot/20230723044041.1089804-1-bmeng@tinylab.org/
For the series, applied to u-boot/next, thanks!
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread