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

[Guenter Roeck]

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:
> > > > > Hi,
> > > > >
> > > > > On Tue, May 23, 2023 at 06:04:58PM +0800, qianfanguijin@163.com wrote:
> > > > > > From: qianfan Zhao <qianfanguijin@163.com>
> > > > > >
> > > > > > Allwinner R40 (sun8i) SoC features a Quad-Core Cortex-A7 ARM CPU,
> > > > > > and a Mali400 MP2 GPU from ARM. It's also known as the Allwinner T3
> > > > > > for In-Car Entertainment usage, A40i and A40pro are variants that
> > > > > > differ in applicable temperatures range (industrial and military).
> > > > > >
> > > > > > Signed-off-by: qianfan Zhao <qianfanguijin@163.com>
> > > > > > Reviewed-by: Niek Linnenbank <nieklinnenbank@gmail.com>
> > > > >
> > > > > I tried this in mainline linux with the following command.
> > > > >
> > > > > qemu-system-arm -M bpim2u \
> > > > >           -kernel arch/arm/boot/zImage -no-reboot \
> > > > >           -snapshot -drive file=rootfs-armv7a.ext2,format=raw,if=sd \
> > > > >           -nic user \
> > > > >           --append "root=/dev/mmcblk0 rootwait console=ttyS0,115200" \
> > > > >           -dtb arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dtb \
> > > > >           -nographic -monitor null -serial stdio
> > > > >
> > > > > 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.

Thanks, and sorry for the noise.

Guenter