[Top][All Lists]

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

Re: Emulate Rpi with QEMU fails

From: Thomas Schneider
Subject: Re: Emulate Rpi with QEMU fails
Date: Tue, 6 Oct 2020 08:58:22 +0200
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1

Hello Paul,

many thanks for sharing this info.

Can you confirm that the emulated RPi with your command will use "internal QEMU" network, means the client cannot be accessed from any other device in LAN?
If yes, what is required to setup a TAP connected to host's network bridge?


Am 06.10.2020 um 00:08 schrieb Paul Zimmerman:
If you can upgrade to Qemu 5.1 or newer, you should be able to use the
builtin raspi2 or raspi3 emulation directly. Version 5.1 adds support for the
USB controller on the Pi.

There is no limitation on the amount of memory you can use with this
method, and the networking should work.

Here is the command line I use to run the Raspbian image
2019-09-26-raspbian-buster. I extracted bcm2709-rpi-2-b and
kernel7.img from the FAT partition inside the image file.

qemu-system-arm -M raspi2 -drive
file=bootpi/2019-09-26-raspbian-buster.img,format=raw,if=sd -dtb
bcm2709-rpi-2-b.dtb -kernel kernel7.img -append 'rw
earlycon=pl011,0x3f201000 console=ttyAMA0 loglevel=8
root=/dev/mmcblk0p2 fsck.repair=yes net.ifnames=0 rootwait memtest=1
dwc_otg.fiq_fsm_enable=0' -serial stdio -no-reboot -netdev
user,id=net0 -usb -device usb-kbd -device usb-tablet -device

Hope this helps.

On Mon, Oct 5, 2020 at 3:51 AM Thomas Schneider <74cmonty@gmail.com> wrote:

thanks for your replies.

I must admit that I don't fully understand your analysis.
However you made some conclusions that are correct.

In fact I have found a Github repo
<https://github.com/dhruvvyas90/qemu-rpi-kernel> where a specific kernel
and versatile-pb are provided + instructions for lauching the emulation
with the original RPi image file:
$ qemu-system-arm \
    -M versatilepb \
    -cpu arm1176 \
    -m 256 \
"virtio-blk-pci,drive=disk0,disable-modern=on,disable-legacy=off" \
    -net "user,hostfwd=tcp::5022-:22" \
    -dtb /.../versatile-pb-buster-5.4.51.dtb \
    -kernel /.../kernel-qemu-5.4.51-buster \
    -append 'root=/dev/vda2 panic=1' \

This means it is more recent than the Raspberry Pi Geek article, and the
emulation works.
But I'm not sure if this usable considering the added models -M raspi2
and -M raspi3.

Can you please advise how to proceed?

In addition I would like to know if there's a memory limitation using
models -M raspi2 and -M raspi3?
To my understanding there's a limitation to 256MB using -M versatilepb.
If yes, I consider to another raw image located on host's temporary
filesystem and use this a swap in the client.

And how can I make use of a client network device that is based on
host's tap device connected to a network bridge?


Am 05.10.2020 um 11:40 schrieb Alex Bennée:
Peter Maydell <peter.maydell@linaro.org> writes:

On Sun, 4 Oct 2020 at 18:44, Alex Bennée <alex.bennee@linaro.org> wrote:
Thomas <74cmonty@gmail.com> writes:
I'm trying to emulate Rpi with QEMU.
I found
arcticle in Raspberry Pi Geek documenting the steps including persistent
storage on host.

However when starting the emulation with command
qemu-system-arm -M versatilepb -cpu arm1176 -m 256 -serial stdio -hda
2020-08-20-raspios-buster-armhf-lite.img -net
"user,hostfwd=tcp::5022-:22" -dtb versatile-pb-buster.dtb -kernel
kernel-qemu-5.4.51-buster -append "root=/dev/sda2 rootfstype=ext4 rw
panic=1" -no-reboot
Let's start with the fact you are using a versatilepb machine type with
a versatilepb dtb and not the rasppi model.
Given the name of the kernel image, this probably actually *is*
built for versatilepb, or it wouldn't have got as far as failing
to mount the root partition. There seems to be a lot of confusion
in the raspberry pi community about the difference between
running the raspi userspace plus a for-versatilepb kernel
versus running a full raspi setup.
Ahh your German is considerably better than mine ;-) Looking more
closely at the blog it seems to be predicated on extracting a Raspbian
kernel which at least stands a fighting chance of being a multi_config
kernel - like the buster above.

I can see why these sorts of shenanigans used to be pulled when there
where no RaspPi models although if all you want to do is run an ARM user
space what's wrong with using linux-user for this sort of thing?

Anyway, failing to mount the rootfs and not listing any
sda devices is not a problem with the fstab, because the system
hasn't got as far as being able to mount the filesystem with a
fstab on it yet. One possibility is that the kernel is
missing the device drivers for either PCI or for the SCSI
controller that gets plugged in to versatilepb by default.

My guess at the cause is that you're trying to boot a Linux 5.something
kernel and you've run into the issue described in this thread:
where the Linux 5.x sym53c8xx scsi driver is not compatible with QEMU's
emulation of that device. If that's the case then you should see
earlier in the kernel boot log error messages similar to the ones
that Roger reported. The fix would be either to use an older
kernel, or to change the QEMU commandline to use a different
SCSI controller (or to use a virtio block device).
Do we have any documentation for the RaspPi models? The acceptance tests
look like they support the inbuilt MMC/SD controller device:

          kernel_command_line = (self.KERNEL_COMMON_COMMAND_LINE +
                                 serial_kernel_cmdline[uart_id] +
                                 ' root=/dev/mmcblk0p2 rootwait ' +

It would be useful to fill the hole in the documentation so gently steer
people away from these hybrid franken-machine approaches.

-- PMM

reply via email to

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