[Qemu-devel] [PATCH 0/9] raspi3: various fixes for Linux booting

Peter Maydell posted 9 patches 6 years ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20180313153458.26822-1-peter.maydell@linaro.org
Test checkpatch passed
Test docker-build@min-glib passed
Test docker-mingw@fedora passed
Test docker-quick@centos6 passed
Test s390x passed
include/hw/arm/bcm2836.h | 31 ++++++++++++++----
hw/arm/bcm2836.c         | 81 +++++++++++++++++++++++++++++++++++-------------
hw/arm/boot.c            | 12 +++++++
hw/arm/raspi.c           | 77 ++++++++++++++++++++++++++++++++++++---------
4 files changed, 158 insertions(+), 43 deletions(-)
[Qemu-devel] [PATCH 0/9] raspi3: various fixes for Linux booting
Posted by Peter Maydell 6 years ago
I had a go at booting Debian's Linux kernel on our raspi3 model.
These patches fix a variety of bugs that were stopping that working:
 * the board was trying to boot in secure mode, which isn't
   right for AArch64 Linux kernels
 * the hw/arm/boot.c code didn't set SCR_EL3.HCE, which meant that
   the HVC instruction would UNDEF and the guest would panic trying
   to initialize KVM
 * BCM2837 uses different affinity (cluster ID) values than BCM2836;
   this really confused Linux since it didn't think the primary CPU
   existed and it ended up panicing in an obscure way.
   I opted to fix this one with a modest refactor of the bcm2836
   code into one device for each SoC, similar to how we handle the
   Aspeed SoCs.
 * the board was trying to use AArch32 code for the secondary
   CPU bootup, so secondaries just went into an infinite UNDEF
   exception loop. Using the correct instruction set and the right
   spintable protocol allows the kernel to detect all the secondaries.

Unfortunately this doesn't entirely suffice to boot, because there's
a problem with our bcm2835_sdhost device model. I've analysed the
problem, but am not sure how to fix it because as far as I can tell
there is no public documentation for this bit of the hardware :-(
Does anybody have a datasheet for it?

[Summary of the sdhost issue:

    The Linux bcm2835_sdhost driver doesn't work on QEMU, because
    our model raises spurious data interrupts. Our function
    bcm2835_sdhost_fifo_run() will flag an interrupt any time
    it is called with s->datacnt == 0, even if the host hasn't
    actually issued a data read or write command yet. This means
    that the driver gets a spurious data interrupt as soon as
    it enables IRQs and then does something else that causes
    us to call the fifo_run routine, like writing to SDHCFG.
    The driver's IRQ handler then spins forever complaining that
    there's no data and the SD controller isn't in a state where
    there's going to be any data:
    [   41.040738] sdhost-bcm2835 3f202000.mmc: fsm 1, hsts 00000000
    [   41.042059] sdhost-bcm2835 3f202000.mmc: fsm 1, hsts 00000000
    (continues forever).

    Without the h/w docs it's hard to know exactly when we are
    supposed to signal interrupts, though obviously what we do now
    is definitely wrong...
]

thanks
-- PMM


Peter Maydell (9):
  hw/arm/raspi: Don't do board-setup or secure-boot for raspi3
  hw/arm/boot: assert that secure_boot and secure_board_setup are false
    for AArch64
  hw/arm/boot: If booting a kernel in EL2, set SCR_EL3.HCE
  hw/arm/bcm2386: Fix parent type of bcm2386
  hw/arm/bcm2836: Rename bcm2836 type/struct to bcm283x
  hw/arm/bcm2836: Create proper bcm2837 device
  hw/arm/bcm2836: Use correct affinity values for BCM2837
  hw/arm/bcm2836: Hardcode correct CPU type
  hw/arm/raspi: Provide spin-loop code for AArch64 CPUs

 include/hw/arm/bcm2836.h | 31 ++++++++++++++----
 hw/arm/bcm2836.c         | 81 +++++++++++++++++++++++++++++++++++-------------
 hw/arm/boot.c            | 12 +++++++
 hw/arm/raspi.c           | 77 ++++++++++++++++++++++++++++++++++++---------
 4 files changed, 158 insertions(+), 43 deletions(-)

-- 
2.16.2