mbox series

[00/13] bootstd: Update ARM QEMU for standard boot and environment

Message ID 20230128220028.53575-1-sjg@chromium.org
Headers show
Series bootstd: Update ARM QEMU for standard boot and environment | expand

Message

Simon Glass Jan. 28, 2023, 10 p.m. UTC 
This series fixes a few reported problems with virtio block-device
handling.

It also moves QEMU over to use standard boot on ARM, by adding a suitable
bootdev and bootmeth for qfw.

Finally, it moves the boards to use a text-based environment. The only
remaining item in the config.h header file is CFG_SYS_SDRAM_BASE so it
would be nice to move that to Kconfig, if possible.


Simon Glass (13):
  log: Add a category for filesystems
  virtio: Add some debugging
  bootstd: Allow enabling BOOTSTD_FULL without needing EXPO
  bootstd: Probe the block device before use
  bootstd: Correct virtio block-device handling
  bootstd: Add some default filesystems and commands
  qemu: Update qfw command to use addresses
  qemu: Move qfw kernel setup into a common file
  qemu: Add a bootdev for qfw
  qemu: Add a bootmeth for qfw
  arm: qemu: Switch to standard boot
  arm: qemu: Switch to a text environment
  arm: qemu: Move GUIDs to the C file

 board/emulation/qemu-arm/qemu-arm.c   |  10 +++
 board/emulation/qemu-arm/qemu-arm.env |  12 +++
 boot/Kconfig                          |  28 +++++++
 boot/Makefile                         |   5 +-
 boot/bootdev-uclass.c                 |   3 +
 boot/bootflow.c                       |   6 +-
 boot/bootmeth_qfw.c                   | 102 ++++++++++++++++++++++++++
 cmd/bootflow.c                        |  21 ++++--
 cmd/qfw.c                             |  89 +++-------------------
 common/log.c                          |   1 +
 common/qfw.c                          |  66 ++++++++++++++++-
 configs/qemu_arm64_defconfig          |   5 +-
 configs/qemu_arm_defconfig            |   5 +-
 configs/tools-only_defconfig          |   1 +
 doc/develop/bootstd.rst               |   4 +
 drivers/misc/qfw.c                    |  87 ++++++++++++++++++++++
 drivers/virtio/virtio-uclass.c        |   8 +-
 drivers/virtio/virtio_blk.c           |   7 ++
 fs/fat/fat_write.c                    |   2 +
 include/configs/qemu-arm.h            |  75 -------------------
 include/log.h                         |   2 +
 include/qfw.h                         |  13 ++++
 test/boot/bootdev.c                   |  25 ++++---
 test/boot/bootstd_common.h            |   2 +-
 24 files changed, 398 insertions(+), 181 deletions(-)
 create mode 100644 board/emulation/qemu-arm/qemu-arm.env
 create mode 100644 boot/bootmeth_qfw.c

Comments

Tom Rini Jan. 30, 2023, 5:19 p.m. UTC | #1 
On Sat, Jan 28, 2023 at 03:00:15PM -0700, Simon Glass wrote:
> This series fixes a few reported problems with virtio block-device
> handling.
> 
> It also moves QEMU over to use standard boot on ARM, by adding a suitable
> bootdev and bootmeth for qfw.
> 
> Finally, it moves the boards to use a text-based environment. The only
> remaining item in the config.h header file is CFG_SYS_SDRAM_BASE so it
> would be nice to move that to Kconfig, if possible.

Figuring out what to do about CFG_SYS_SDRAM_BASE is a good question. For
this series, have you been able to perform other tests on top of it,
such as verifying off the shelf distributions still boot / install as
expected?
Simon Glass Jan. 31, 2023, 2:16 p.m. UTC | #2 
Hi Tom,

On Mon, 30 Jan 2023 at 10:20, Tom Rini <trini@konsulko.com> wrote:
>
> On Sat, Jan 28, 2023 at 03:00:15PM -0700, Simon Glass wrote:
> > This series fixes a few reported problems with virtio block-device
> > handling.
> >
> > It also moves QEMU over to use standard boot on ARM, by adding a suitable
> > bootdev and bootmeth for qfw.
> >
> > Finally, it moves the boards to use a text-based environment. The only
> > remaining item in the config.h header file is CFG_SYS_SDRAM_BASE so it
> > would be nice to move that to Kconfig, if possible.
>
> Figuring out what to do about CFG_SYS_SDRAM_BASE is a good question. For
> this series, have you been able to perform other tests on top of it,
> such as verifying off the shelf distributions still boot / install as
> expected?

I did not do a new install, but did check that it booting Debian OK.
Should we try to get some of this into CI or would it be too painful?

I have done a lot of checking with RockPro64 which of course uses the
same logic (except for qfw which is new and which I manually tested).
Of course we also have a lot of unit tests for bootstd, to prevent
regressionsl,

Regards,
Simon