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:45:46 +0200

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



reply via email to

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