On Fri, 23 Jun 2023 at 20:33, Guenter Roeck <li...@roeck-us.net> wrote: > > On 6/23/23 10:44, Peter Maydell wrote: > > On Sat, 17 Jun 2023 at 17:29, Guenter Roeck <li...@roeck-us.net> wrote: > >> > >> Hi, > >> > >> On Tue, May 23, 2023 at 06:04:58PM +0800, qianfangui...@163.com wrote: > >>> From: qianfan Zhao <qianfangui...@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 <qianfangui...@163.com> > >>> Reviewed-by: Niek Linnenbank <nieklinnenb...@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. > A secondary problem may be that Linux thinks that the first > drive is not removable, even though it is a SD drive. I think > that is a problem with qemu, but I don't understand the qemu > code well enough to understand why. It seems that the mmc > capability register always has bit 8 set, even for the first > drive, but I don't know where/how that is set and how to > change it. SDHCI has the capareg property, but that isn't > used here (or I don't know how to use/set it). Yeah, this seems likely to be something we're getting wrong. I assume on other QEMU boards the SD card appears as removeable ? thanks -- PMM
