I think it's worth noting that this isn't actually emulating a Raspberry Pi. The option "-M versatilepb" to QEMU tells it to emulate a VersatilePB, which is an Arm development board that's now a decade or more old. It happens that this can be set up to use an ARM1176 CPU, which is the same as the one in the RPi. So you can run a kernel built for the VersatilePB on a VersatilePB model, and use the same userspace/filesystem as the RPi, provided that your userspace doesn't rely on any particular characteristics of the rpi hardware beyond the CPU type. Luckily for most uses that's close enough...
Also (and I know you know this, pm215) you can actually emulate a Raspberry Pi 2 machine (i.e. the bcm2836 SoC) in recent versions of QEMU with the "raspi2" machine type. There are instructions that worked for me here:
Last I checked, QEMU does not run multiple cores concurrently. Similar to Python, it has a big lock that serializes execution (known as the "Big QEMU Lock", or BQL). So you should not expect speedups...
Yeah, that has hit upstream now. It needs support in both the frontend and the backend so only some host/guest combos will enable it, but arm-on-x86 should now multithread by default for smp guests.
Do you know which RPis used this CPU? Just the original? I'm looking for a way of emulating a RPi2/3 so I can run the arm version of Ubuntu Mate. Any idea if a method like this will work for me?
On Linux, it's even easier (lol, who would have guessed?).
I recently had the need to compile quite a bit of software to run on the Pi zero, and the ability to be able to "chroot" to the Pi on my PC has made the experience so much more pleasant. Everything compiles ten times faster!
I also noticed that none of the available guides work well with Ubuntu 17.04 (and possibly newer/older), so I put together a simple script to do that on Ubuntu for anyone who is interested. It will always work when you chroot on the sdcard:
You can theoretically chroot into the image directly, but the resizing the partitions operation is unreliable on the host for some reason, and it might cause the image to not be bootable. I've found myself better off booting the sd card once with the vanilla image on the Pi first so it resizes itself before chrooting into the SD card.
I had this problem with my similar script until I added 'sync; sleep 1; partprobe' after the writing the new partition information (before running e2fsck).
Good observation :) it's the raspbian arm build -- you are chroot-ing into the exact SD card that you put into the Pi.
I don't know how exactly this sorcery works either. But I think chroot just "knows" that it needs to invoke qemu when it sees the binfmt of /bin/bash being arm.
If you read the script, it copies the relevant qemu binary on line 52 to the chroot's /usr/bin/.
What's happening here is binfmt-support on the host has a path registered for arm binaries as the file you just copied to /usr/bin - whenever the chroot tries to run anything, the host directs it to this bianry which is your arm emulator :).
That's an awesome explanation - thanks! I just copied and pasted from other people's code and prettified it a bit so it's easier to use, but I didn't really understand why it worked. Now I do a bit better.
