From: "Alex Bennée" <alex.bennee@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Thomas <74cmonty@gmail.com>, qemu-arm <qemu-arm@nongnu.org>,
"QEMU Developers" <qemu-devel@nongnu.org>,
"Andrew Baumann" <Andrew.Baumann@microsoft.com>,
"Philippe Mathieu-Daudé" <f4bug@amsat.org>
Subject: Re: Emulate Rpi with QEMU fails
Date: Mon, 05 Oct 2020 10:40:45 +0100 [thread overview]
Message-ID: <875z7p3t9e.fsf@linaro.org> (raw)
In-Reply-To: <CAFEAcA_ZMLV3DZ_R_SHvPLdEf=i-xpspD5itBmfYeqyMhgtLWQ@mail.gmail.com>
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
--
Alex Bennée
WARNING: multiple messages have this Message-ID (diff)
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-arm <qemu-arm@nongnu.org>,
"Andrew Baumann" <Andrew.Baumann@microsoft.com>,
"QEMU Developers" <qemu-devel@nongnu.org>,
Thomas <74cmonty@gmail.com>,
"Philippe Mathieu-Daudé" <f4bug@amsat.org>
Subject: Re: Emulate Rpi with QEMU fails
Date: Mon, 05 Oct 2020 10:40:45 +0100 [thread overview]
Message-ID: <875z7p3t9e.fsf@linaro.org> (raw)
In-Reply-To: <CAFEAcA_ZMLV3DZ_R_SHvPLdEf=i-xpspD5itBmfYeqyMhgtLWQ@mail.gmail.com>
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
--
Alex Bennée
next prev parent reply other threads:[~2020-10-05 9:40 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-03 11:45 Emulate Rpi with QEMU fails Thomas
2020-10-04 17:44 ` Alex Bennée
2020-10-04 17:44 ` Alex Bennée
2020-10-04 18:40 ` Peter Maydell
2020-10-04 18:40 ` Peter Maydell
2020-10-05 9:40 ` Alex Bennée [this message]
2020-10-05 9:40 ` Alex Bennée
2020-10-05 10:51 ` Thomas Schneider
2020-10-05 22:08 ` Paul Zimmerman
2020-10-05 22:08 ` Paul Zimmerman
2020-10-06 6:58 ` Thomas Schneider
2020-10-06 6:58 ` Thomas Schneider
2020-10-06 7:42 ` Paul Zimmerman
2020-10-06 7:42 ` Paul Zimmerman
2020-10-06 9:58 ` Alex Bennée
2020-10-06 9:58 ` Alex Bennée
2020-10-07 6:28 ` Thomas
2020-10-07 6:28 ` Thomas
2020-10-07 6:50 ` Paul Zimmerman
2020-10-07 6:50 ` Paul Zimmerman
2020-10-07 7:27 ` Thomas Schneider
2020-10-07 7:27 ` Thomas Schneider
2020-10-07 11:00 ` Alex Bennée
2020-10-07 11:00 ` Alex Bennée
2020-10-07 11:36 ` Thomas Schneider
2020-10-07 11:36 ` Thomas Schneider
2020-10-07 12:02 ` Alex Bennée
2020-10-07 12:02 ` Alex Bennée
2020-10-08 7:00 ` Thomas
2020-10-08 7:00 ` Thomas
2020-10-08 21:07 ` Paul Zimmerman
2020-10-08 21:07 ` Paul Zimmerman
2020-10-09 2:21 ` Paul Zimmerman
2020-10-09 2:21 ` Paul Zimmerman
2020-10-09 6:20 ` Alex Bennée
2020-10-09 6:20 ` Alex Bennée
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875z7p3t9e.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=74cmonty@gmail.com \
--cc=Andrew.Baumann@microsoft.com \
--cc=f4bug@amsat.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.