On 6/24/23 03:40, Peter Maydell wrote:
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.
Agreed, only someone with real hardware would have to confirm
that this is the case.
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 ?
Yes. With some added debugging, sabrelite, and no drive provided
in the qemu command:
mmc0: SDHCI controller on 2198000.mmc [2198000.mmc] using ADMA
############# mmc0: No card inserted, removable=1
mmc1: SDHCI controller on 219c000.mmc [219c000.mmc] using ADMA
############# mmc1: No card inserted, removable=1
Thanks,
Guenter
