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