How to Emulate a Raspberry Pi (Raspbian Jessie) on Mac OS X | Hacker News Reader

How to Emulate a Raspberry Pi (Raspbian Jessie) on Mac OS X

gist.github.com

128 pointshfreire22 comments

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:

https://raspberrypi.stackexchange.com/a/71172

Any idea of a raspi3 machine type in the works? or where to contribute to one?

It has a BCM2837, which has a 64-bit ARM CPU Core, and 400MHz VideoCore IV versus 250MHz in the raspi2.

A comparison table can be found by searching "What is new" in https://media.digikey.com/pdf/Data%20Sheets/Seeed%20Technolo...

I don't know, but a quick google search finds:

https://github.com/bztsrc/qemu-raspi3

I never got this working myself, do you get 4 cores that run the native cores ?

Running raspbian in Qemu seems slower than running on a real Pi, multicore would definitely help.

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...

However, there is an effort to change this:

https://lwn.net/Articles/697265/

But I don't know if it has been merged yet.

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?

Only the original, and the Zero(W). RPi2/3 use ARMv7 and ARMv8 cores, much more mainstream so easier to simulate.

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:

https://gist.github.com/htruong/7df502fb60268eeee5bca21ef3e4...

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.

Am I misreading or are you chrooting to an x86 build of Raspbian?

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.

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).

Great, I will check it out :)

Thank you! I'm developing a project involving rpi0 now; this will simplify things so much!

As mentioned below newer versions of QEMU can emulate the CPUs in newer Pis.

The main thing missing is proprietary graphics API "dispmanx".

I didn't try and emulate the GPIO, but assume that is also not possible ?

I've looked in to this before to build rPi binaries on a more powerful x86 machine, but i've never been able to get Jenkins/Java running under QEMU

Why do you need Jenkins running in QEMU? Just use this: https://hub.docker.com/r/sdthirlwall/raspberry-pi-cross-comp...

why this old version of raspbian? https://downloads.raspberrypi.org/raspbian/images/

From what I see from the script, the version of the raspbian distro shouldn't matter that much. The kernel should be compatible.

Reply on news.ycombinator.com