Re: [Qemu-arm] [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é
> <address@hidden> 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