| Message ID | 20180319161556.16446-1-peter.maydell@linaro.org |
|---|---|
| Headers | show |
| Series | bcm2835_sdhost: fix interrupt handling | expand |
Ping for code review, please? It would be nice if our 'raspi3' model for 2.12 was one we could say actually booted a known Linux image... thanks -- PMM On 19 March 2018 at 16:15, Peter Maydell <peter.maydell@linaro.org> wrote: > This patchset fixes the code in the bcm2835_sdhost device > so that it raises interrupts in more plausible places. > > The Linux bcm2835_sdhost driver doesn't work on QEMU at the moment, > 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, and before it does the write to SDCMD to issue the > read. 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). > > Move the interrupt flag setting to more plausible places: > * for BUSY, raise this as soon as a BUSYWAIT command has executed > * for DATA, raise this when the FIFO has any space free (for a write) > or any data in it (for a read) > * for BLOCK, raise this when the data count is 0 and we've > actually done some reading or writing > > This is pure guesswork since the documentation for this hardware is > not public, but it is sufficient to get the Linux bcm2835_sdhost > driver to work. > > If anybody has other OSes than Linux that use the sdhost SD > controller (not the 'Arasan' one, which is a different bit of > the SoC) testing with those would be appreciated. If anybody > has documentation for this hardware that would be even better. > > With these patches plus the previous set, I can get the Debian > raspi3 image to boot (though there are a lot of warnings relating > to the pl011 UART for some reason). > > thanks > -- PMM > > Peter Maydell (2): > hw/sd/bcm2835_sdhost: Add tracepoints > hw/sd/bcm2835_sdhost: Don't raise spurious interrupts > > hw/sd/bcm2835_sdhost.c | 51 +++++++++++++++++++++++++++++++------------------- > hw/sd/trace-events | 6 ++++++ > 2 files changed, 38 insertions(+), 19 deletions(-) > > -- > 2.16.2
On Wed, Apr 04, 2018 at 11:18:23AM +0100, Peter Maydell wrote: > Ping for code review, please? It would be nice if our 'raspi3' > model for 2.12 was one we could say actually booted a known > Linux image... The Fedora 27 image kernel (aarch64, 4.13) boots and mounts the root filesystem. This is an improvement, so: Tested-by: Gerd Hoffmann <kraxel@redhat.com> It doesn't finish boot though, at some point the kernel starts to complain about timeouts and xfs throws io errors, so things are not perfect yet. raspi2 doesn't boot the fedora 27 armhfp kernel. Looks unrelated though, it fails with "Division by zero in kernel" before even loading the sdhost driver. I suspect the kernel tries to access some hardware not emulated by qemu ... Trying to run u-boot as boot-loader (so I don't have to copy the kernel from the image) doesn't work too. cheers, Gerd
On 4 April 2018 at 15:25, Gerd Hoffmann <kraxel@redhat.com> wrote: > On Wed, Apr 04, 2018 at 11:18:23AM +0100, Peter Maydell wrote: >> Ping for code review, please? It would be nice if our 'raspi3' >> model for 2.12 was one we could say actually booted a known >> Linux image... > > The Fedora 27 image kernel (aarch64, 4.13) boots and mounts the root > filesystem. This is an improvement, so: > > Tested-by: Gerd Hoffmann <kraxel@redhat.com> > > It doesn't finish boot though, at some point the kernel starts to > complain about timeouts and xfs throws io errors, so things are not > perfect yet. > > raspi2 doesn't boot the fedora 27 armhfp kernel. Looks unrelated > though, it fails with "Division by zero in kernel" before even loading > the sdhost driver. I suspect the kernel tries to access some hardware > not emulated by qemu ... > > Trying to run u-boot as boot-loader (so I don't have to copy the kernel > from the image) doesn't work too. Thanks for the testing. I've applied this series to target-arm.next for 2.12 (with minor tweaks as per code review). I have a blog post pending which describes how to boot a Debian image on the raspi3 model, which I'll publish once this hits master. thanks -- PMM
This patchset fixes the code in the bcm2835_sdhost device so that it raises interrupts in more plausible places. The Linux bcm2835_sdhost driver doesn't work on QEMU at the moment, 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, and before it does the write to SDCMD to issue the read. 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). Move the interrupt flag setting to more plausible places: * for BUSY, raise this as soon as a BUSYWAIT command has executed * for DATA, raise this when the FIFO has any space free (for a write) or any data in it (for a read) * for BLOCK, raise this when the data count is 0 and we've actually done some reading or writing This is pure guesswork since the documentation for this hardware is not public, but it is sufficient to get the Linux bcm2835_sdhost driver to work. If anybody has other OSes than Linux that use the sdhost SD controller (not the 'Arasan' one, which is a different bit of the SoC) testing with those would be appreciated. If anybody has documentation for this hardware that would be even better. With these patches plus the previous set, I can get the Debian raspi3 image to boot (though there are a lot of warnings relating to the pl011 UART for some reason). thanks -- PMM Peter Maydell (2): hw/sd/bcm2835_sdhost: Add tracepoints hw/sd/bcm2835_sdhost: Don't raise spurious interrupts hw/sd/bcm2835_sdhost.c | 51 +++++++++++++++++++++++++++++++------------------- hw/sd/trace-events | 6 ++++++ 2 files changed, 38 insertions(+), 19 deletions(-) -- 2.16.2