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 <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.
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
