[Qemu-devel] RFC raspberry pi sd-card reset

[Qemu-devel] RFC raspberry pi sd-card reset

[Damien Hedde]

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

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

[Andrew Baumann via Qemu-devel]

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.hedde@greensocs.com>
Sent: Wednesday, July 31, 2019 7:21:02 AM
To: QEMU Developers <qemu-devel@nongnu.org>
Cc: Peter Maydell <peter.maydell@linaro.org>; Andrew Baumann <Andrew.Baumann@microsoft.com>; f4bug@amsat.org <f4bug@amsat.org>; qemu-arm <qemu-arm@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

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

[Philippe Mathieu-Daudé]

On 7/31/19 4:21 PM, Damien Hedde wrote:
> 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.

The machine cold reset implicitly cold resets the sd-card.

IIRC the sd-bus shouldn't (cold/warm)-reset the sd-card.

Only SDBusClass::set_inserted() can cold-reset the card.

> 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 ?

There is only 1 bus, the SDHCI bus lines are muxed with the GPIO ones.

bcm2835-sdhost-bus should not be child of bcm2835-sdhost, the sdbus
might be child of bcm2835-peripherals and shared by both sdhost and gpio
(as a link property?).

I tried to do that 2 years ago. I thought I posted the series and Peter
rejected it but can't find it, maybe we had an IRC chat. I won't have
time until next week to dig for it.

> 
> --
> Damien
> 

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

[Philippe Mathieu-Daudé]

On Wed, Jul 31, 2019 at 5:43 PM Philippe Mathieu-Daudé
<philmd@redhat.com> wrote:
> On 7/31/19 4:21 PM, Damien Hedde wrote:
> > 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.
>
> The machine cold reset implicitly cold resets the sd-card.
>
> IIRC the sd-bus shouldn't (cold/warm)-reset the sd-card.
>
> Only SDBusClass::set_inserted() can cold-reset the card.
>
> > 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 ?
>
> There is only 1 bus, the SDHCI bus lines are muxed with the GPIO ones.
>
> bcm2835-sdhost-bus should not be child of bcm2835-sdhost, the sdbus
> might be child of bcm2835-peripherals and shared by both sdhost and gpio
> (as a link property?).

There is a similar modelling issue with the AUX uart and SPI on this device.

> I tried to do that 2 years ago. I thought I posted the series and Peter
> rejected it but can't find it, maybe we had an IRC chat. I won't have
> time until next week to dig for it.
>
> >
> > --
> > Damien
> >

Re: [Qemu-devel] 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 <damien.hedde@greensocs.com>
> *Sent:* Wednesday, July 31, 2019 7:21:02 AM
> *To:* QEMU Developers <qemu-devel@nongnu.org>
> *Cc:* Peter Maydell <peter.maydell@linaro.org>; Andrew Baumann
> <Andrew.Baumann@microsoft.com>; f4bug@amsat.org <f4bug@amsat.org>;
> qemu-arm <qemu-arm@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

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

[Damien Hedde]

On 7/31/19 5:45 PM, Philippe Mathieu-Daudé wrote:
> On Wed, Jul 31, 2019 at 5:43 PM Philippe Mathieu-Daudé
> <philmd@redhat.com> wrote:
>> On 7/31/19 4:21 PM, Damien Hedde wrote:
>>> 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.
>>
>> The machine cold reset implicitly cold resets the sd-card.
>>
>> IIRC the sd-bus shouldn't (cold/warm)-reset the sd-card.
>>
>> Only SDBusClass::set_inserted() can cold-reset the card.

I agree but it's something we cannot address until the reset propagation
is hard-coded to be qdev/qbus based.

>>
>>> 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 ?
>>
>> There is only 1 bus, the SDHCI bus lines are muxed with the GPIO ones.
>>
>> bcm2835-sdhost-bus should not be child of bcm2835-sdhost, the sdbus
>> might be child of bcm2835-peripherals and shared by both sdhost and gpio
>> (as a link property?).
> 
> There is a similar modelling issue with the AUX uart and SPI on this device.
> 
>> I tried to do that 2 years ago. I thought I posted the series and Peter
>> rejected it but can't find it, maybe we had an IRC chat. I won't have
>> time until next week to dig for it.

I was thinking of doing a work-around by defining the raspi machine
reset to something like that.

static void raspi_reset(MachineState *machine)
{
    SDBus *sdhci, *sdhost, *sdbus;
    /*
     * anticipate following reset and ensure the sd-card at its
     * end-of-reset place
     */
    sdhci = object_resolve_path("/path/to/sdhci");
    sdhost = object_resolve_path("/path/to/sdhost");
    sdbus = object_resolve_path("/path/to/sdbus");
    sdbus_reparent_card(sdbus, sdhci); // no-op if card is not on sdbus
    sdbus_reparent_card(sdhost, sdhci); //no-op if card is not on sdhost

    /* standard reset */
    qemu_devices_reset();
}

Damien