qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Philippe Mathieu-Daudé
Subject: Re: [Qemu-arm] [Qemu-devel] RFC raspberry pi sd-card reset
Date: Wed, 31 Jul 2019 17:43:34 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0

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
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]