[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] RFC raspberry pi sd-card reset
From: |
Philippe Mathieu-Daudé |
Subject: |
Re: [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
> >