qemu-arm
[Top][All Lists]
Advanced

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

Re: [PATCH v5 01/11] hw: arm: Add bananapi M2-Ultra and allwinner-r40 su


From: Peter Maydell
Subject: Re: [PATCH v5 01/11] hw: arm: Add bananapi M2-Ultra and allwinner-r40 support
Date: Tue, 1 Aug 2023 17:01:03 +0100

On Sat, 24 Jun 2023 at 16:02, Guenter Roeck <linux@roeck-us.net> wrote:
>
> On 6/24/23 07:23, Guenter Roeck wrote:
> > On 6/24/23 03:40, Peter Maydell wrote:
> >> On Fri, 23 Jun 2023 at 20:33, Guenter Roeck <linux@roeck-us.net> wrote:
> >>>
> >>> On 6/23/23 10:44, Peter Maydell wrote:
> >>>> On Sat, 17 Jun 2023 at 17:29, Guenter Roeck <linux@roeck-us.net> wrote:
> >>>>> Main problem is that the SD card gets instantiated randomly to
> >>>>> mmc0, mmc1, or mmc2, making it all but impossible to specify a
> >>>>> root file system device. The non-instantiated cards are always
> >>>>> reported as non-removable, including mmc0. Example:
> >>>>>
> >>>>> mmc0: Failed to initialize a non-removable card
> >>>>
> >>>> Do you mean that QEMU randomly connects the SD card to
> >>>> a different MMC controller each time, or that Linux is
> >>>> randomly assigning mmc0 to a different MMC controller each
> >>>> time ?
> >>>>
> >>>
> >>> Good question. Given the workaround (fix ?) I suggested is
> >>> in the devicetree file, I would assume it is the latter. I suspect
> >>> that Linux assigns drive names based on hardware detection order,
> >>> and that this is not deterministic for some reason. It is odd
> >>> because I have never experienced that with any other emulation.
> >>
> >> Yeah, I don't really understand why it would be non-deterministic.
> >> But it does make it sound like the right thing is for the
> >> device tree file to explicitly say which MMC controller is
> >> which -- presumably you might get unlucky with the timing
> >> on real hardware too.
> >>
> >
> > Agreed, only someone with real hardware would have to confirm
> > that this is the case.
> >
>
> Actually, the reason is quite simple. In the Linux kernel:
>
> static struct platform_driver sunxi_mmc_driver = {
>          .driver = {
>                  .name   = "sunxi-mmc",
>                  .probe_type = PROBE_PREFER_ASYNCHRONOUS,
>                                ^^^^^^^^^^^^^^^^^^^^^^^^^
>                  .of_match_table = sunxi_mmc_of_match,
>                  .pm = &sunxi_mmc_pm_ops,
>          },
>          .probe          = sunxi_mmc_probe,
>          .remove         = sunxi_mmc_remove,
> };
>
> All mmc devices instantiate at the same time, thus the
> device name association is random. If I drop the probe_type
> assignment, it becomes deterministic.
>
> On top of that, Linux does know which drives are removable
> from the devicetree file. However, since probe order is
> random, the assignment of the one removable drive to device
> names is random. Sometimes mmc0 shows up as removable,
> sometimes it is mmc1 or mmc2.
>
> So my conclusion is that qemu isn't doing anything wrong,
> it is all happening in the Linux kernel.

Hi Guenter -- do you know if this "random MMC controller"
issue has been fixed in Linux ? If so, we might be able
to update our test case image to avoid the slightly ugly
"root=b300" workaround at some point.

thanks
-- PMM



reply via email to

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