Re: [Qemu-arm] RFC raspberry pi sd-card reset

[Damien Hedde]

On 7/31/19 5:28 PM, Andrew Baumann wrote:
> 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.

I understand that there is different sd controllers the guest can choose.
My concern is only about the reset, before any guest kicked in. During
reset the sd-card will always ends up at the same place (the sdhci-bus)
Right-now machine init put the sd-card at some place, and reset moves it.

> 
>  
> 
> Andrew
> 
>  
> 
> ------------------------------------------------------------------------
> *From:* Damien Hedde <address@hidden>
> *Sent:* Wednesday, July 31, 2019 7:21:02 AM
> *To:* QEMU Developers <address@hidden>
> *Cc:* Peter Maydell <address@hidden>; Andrew Baumann
> <address@hidden>; address@hidden <address@hidden>;
> qemu-arm <address@hidden>
> *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