Re: Emulate Rpi with QEMU fails

[Thomas Schneider]

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