| Message ID | 20230814173944.288356-5-alpernebiyasak@gmail.com |
|---|---|
| State | Accepted |
| Commit | 8def269365c81e548c4df3e594cb23aa088b6b21 |
| Delegated to: | Tom Rini |
| Headers | show |
| Series | arm: qemu: Enable Bochs, console buffering, USB keyboard | expand |
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
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?
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
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?
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...
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...
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
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
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 ----------------------
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(+)