On Sun, 20 Oct 2019 at 00:47, Philippe Mathieu-Daudé <address@hidden> wrote:
The abstract TYPE_BCM283X device provides a 'enabled-cpus' property
to restrict the number of cores powered on reset. This because on
real hardware the GPU is responsible of starting the cores and keep
them spinning until the Linux kernel is ready to use them.
When using the -kernel paramenter, QEMU does this by installing the
'raspi_smpboot' code when arm_boot_info::write_board_setup() is
called. This is a special feature to help the Linux kernel, and can
only be used with a Linux kernel.
Even if loaded with the -kernel option, U-boot is not Linux, thus
is not recognized as it and the raspi_smpboot code is not installed.
Upon introduction of this machine in commit 1df7d1f9303, the -smp <N>
option allowd to limit the number of cores powered on reset.
Unfortunately later commit 72649619341 added a check which made this
feature unusable:
$ qemu-system-aarch64 -M raspi3 -smp 1
qemu-system-aarch64: Invalid SMP CPUs 1. The min CPUs supported by machine
'raspi3' is 4
Fortunately, the -smp option allow various kind of CPU topology:
-smp
[cpus=]n[,maxcpus=cpus][,cores=cores][,threads=threads][,dies=dies][,sockets=sockets]
set the number of CPUs to 'n' [default=1]
maxcpus= maximum number of total cpus, including
offline CPUs for hotplug, etc
cores= number of CPU cores on one socket (for PC, it's on one die)
threads= number of threads on one CPU core
dies= number of CPU dies on one socket (for PC only)
sockets= number of discrete sockets in the system
Let's use the 'cores' argument to specify the number of cores powered
at reset to restore this feature, and allow to boot U-boot.
From the help message quoted, 'cores' is about NUMA topology,
it's nothing to do with "how many cores do we have powerd on
on reset". We should definitely not be borrowing it for
an unrelated purpose.
We can now run U-boot using:
$ qemu-system-aarch64 -M raspi3 -smp 4,cores=1 ...
Either:
(a) we need to support "act like the firmware/GPU" for
booting guest binaries on this board, in the same way that our PSCI
support is effectively emulating firmware-level facilities
(b) the u-boot binary should be provided to QEMU in the
right image format to use the kernel boot ABI
(c) u-boot could be wrapped in a small guest binary that
deals with handling all the secondary cores
I'm not really a huge fan of (a) because we already have a
huge pile of random weird ways of loading guest images
that are undocumented, behave differently from board to
board or architecture to architecture, etc. I'm not too
keen on making that swamp worse, even though there's an
argument that the right UI for a raspi board model is to
provide the same "load an ELF file" handling that the real
hardware does for ELF files via the GPU/firmware combo.