Hi,
(Sorry for top-posting, just wanted to give you some quick context.)
The Pi-specific quirk here is that there are two different SD controllers on
the board, both accessing the same card, where only one can be used at a time.
IIRC Clement Deschamps added this reparenting logic to accomplish that when he
implemented the second SD controller. I can’t give you a concrete suggestion,
but “initialize the platform with the sd-card at the right initial place” is
not really viable given that the right place changes depending on GPIO
programming by the guest.
Andrew
________________________________
From: Damien Hedde <damien.he...@greensocs.com>
Sent: Wednesday, July 31, 2019 7:21:02 AM
To: QEMU Developers <qemu-devel@nongnu.org>
Cc: Peter Maydell <peter.mayd...@linaro.org>; Andrew Baumann
<andrew.baum...@microsoft.com>; f4...@amsat.org <f4...@amsat.org>; qemu-arm
<qemu-...@nongnu.org>
Subject: RFC raspberry pi sd-card reset
Hi,
Concerning the reset on the raspi2/3 machine, I ran into an issue with
the sd-card.
Here follows a subset of the qbus/qdev tree of the raspi2&3 machine as
it is initialized:
+ System
* bcm2835_gpio
+ sd-bus
* sd-card
* bcm2835-sdhost
+ bcm2835-sdhost-bus
* generic-sdhci
+ sdhci-bus
raspi_init does 2 things:
+ it creates the soc
+ then it explicitly creates the sd-card on the bcm2835_gpio's sd-bus
As it happens, the reset moves the sd-card on another bus: the
sdhci-bus. More precisely the bcm2835_gpio reset method does it (the
sd-card can be mapped on bcm2835-sdhost-bus or sdhci-bus depending on
bcm2835_gpio registers, reset configuration corresponds to the sdhci-bus).
Reset call order is the following (it follows children-before-parent order):
1 sd-card
2 sd-bus
3 bcm2835_gpio -> move the sd-card
4 bcm2835-sdhost-bus
5 bcm2835-sdhost
6 sd-card (again)
7 sdhci-bus
8 generic-sdhci
In the end, the sd-card is reset twice, which is no big-deal in itself.
But it only depends on the bcm2835_gpio tree being reset before the
generic-sdhci (probably depends on the machine creation code).
I checked and it seems this is the only platform where such things
happen during master reset.
IMO this is a bit hazardous because reset is based on the qdev/qbus
tree (and with the multi-phase I'm working on, even if it still works,
it's worse).
I'm not sure what we should do to avoid this (and if there's is
something to be done).
The easiest solution would be to initialize the platform with the
sd-card at the right initial place (I do not really understand why it is
created in the bcm2835_gpio in the first place since we move it just
after). But it won't solve the issue if a reset is done afterwards.
Or maybe we could move the sd-card on the proper bus in a machine
reset code so that it's on the right place when we do the sysbus tree
reset just after.
What do you think ?
--
Damien
