Re: Emulate Rpi with QEMU fails

[Thomas Schneider <74cmonty@gmail.com>]

Hello,

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 \
   -drive 
"file=/.../2020-05-27-raspios-buster-lite-armhf.img,if=none,index=0,media=disk,format=raw,id=disk0" 
\
   -device 
"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' \
   -no-reboot

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?

THX


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
>>>> [url=1]this[/url]
>>>> 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:
>> https://lists.gnu.org/archive/html/qemu-discuss/2020-09/msg00023.html
>> 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 ' +
>                                 'dwc_otg.fiq_fsm_enable=0')
>
> It would be useful to fill the hole in the documentation so gently steer
> people away from these hybrid franken-machine approaches.
>
>> thanks
>> -- PMM
>