QEMU is open source machine emulator and virtualizer, which I used in the past at a time when Arm boards were more expensive or hard to get than today, and more recently I tested RISC-V Linux using QEMU (fork).
QEMU 2.12 has now been released with some interesting new features including RISC-V support, and initial support for Raspberry Pi 3 machine model.
The Changelog is rather long, but some other notable changes include:
- Cortex-M33 Armv8-M emulation, used by the new mps2-an505 board.
- Support for various AArch64 v8.1/v8.2/v8.3 extensions.
- Initial support for Raspberry Pi 3 machine model
- i.MX7 SoC and i.MX7 Sabre board emulation.
- Spectre/Meltdown mitigation support for x86/pseries/s390 guest
- Intel IOMMU support for 48-bit addresses
- Many SD card emulation cleanups and bugfixes.
- Etc..
You can get the source code and build instructions in the download page. If you are interested in running Debian on RPI 3 model, or/and want to find out more about RISC-V support, you may want to read the blog posts here and there respectively.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
Raspberry Pi 3 support? As far as I understood none of the VC4 stuff is implemented, also not bringing up the primary operating system that usually runs on these devices (ThreadX, the closed source RTOS euphemistically called ‘firmware’ fully controlling the hardware) Also: ‘We don’t have an emulation of the BCM2835 USB controller. This means that there is no networking support, because on the raspi devices the ethernet hangs off the USB controller.’ So a secondary OS for example based on Linux can be brought up emulating the ARM cores while not a single feature that would justify using a… Read more »
I suppose the authors saw some sense in doing so… I’m pretty sure they could do worse things with their lives/spare time than implementing raspi in qemu. 😉
> I suppose the authors saw some sense in doing so… Maybe just to end up where Kristina Brooks, the lady who tried to replace the proprietary closed source ThreadX stuff with an open source bootloader bringing up the ARM cores, ended up already? https://irclog.whitequark.org/linux-sunxi/2017-04-02#19158422; But still: For the vast majority of RPi users this board is of no use anyway if the VC4 stuff doesn’t work. So still scratching my head what the purpose of such an emulation attempt is ignoring the main CPU and the primary OS running there and focusing only on the ARM cores (that are… Read more »
That’s what “initial support” always look like 😉
> “initial support” How should this ever evolve? And why? If there’s any SBC that does not need emulation then it’s the Pi since readily available almost everywhere. And if you want to emulate this platform for whatever reason you need to have in mind how this platform works. This is *not* an ARM board with integrated MCU as so many think but this is something totally different: VideoCore IV as main CPU running a proprietary RTOS called ThreadX that brings up and controls the hardware with some crappily integrated ARM cores added. Clocks, caches, $whatever is sometimes controlled by… Read more »
I can imagine a use case in fact. There are many people who do native builds of their software, but the RPi is extremely slow. I wouldn’t be surprised if running an RPi under an emulator on a fast PC would be faster than a native one for such a use case. Then it would be the first step to try to convince such people to use cross-compilation instead 🙂
Hmm… when people want to do native ARM builds why would they choose a slow SBC? Fast ones do exist too: MiQi, Tinkerboard, ODROID-HC1, NanoPi Fire3 all come to my mind within a specific price range (BTW: how does the Fire3 with its 8 A53 compete against RK3288?)
And if they already have a PC then of course cross-compiling is the weapon of choice. Still no idea why emulating an incomplete RPi 3 would make any sense.
Hey Thomas, I’m trying to figure some rare use cases, not why people would do that. 🙂 After all, those who have an RPi are unlikely to have another board and to still want to work on the RPi. Thus I’m assuming that most people who build for RPi either do it on the RPi itself or cross-compile. If they don’t know how to cross-compile (we’ve all been in that scary situation a long time ago), building on the same image running under QEMU still remains an attractive option.
It might still be useful if somebody wants to work on the go (can’t take board), and without networking connectivity (so no remote access) for things that can be done headless, or if you just want to quickly test something, and don’t have a board on hand.
Reminds me of this guy I know who was working on his arduino in the train, with other voyagers worried about what he was trying to do with these hanging wires!
“Raspberry Pi 3 support” basically means that the firmware base address was updated and a Cortex-A53 can be used in addition to the Cortex-A7:
https://github.com/qemu/qemu/commit/bade58166f4466546600d824a2695a00269d10eb
https://github.com/qemu/qemu/commit/1c3db49d39d66646ff546ec26f36e3b9040f3504
The VC4 is NOT emulated. Only a very basic set of peripherals are available:
https://github.com/qemu/qemu/blob/b8846a4d6352b2a1d2012f8b3b9115640524aeda/hw/arm/bcm2835_peripherals.c#L43-L119
/* Interrupt Controller */
/* UART0 */
/* AUX / UART1 */
/* Mailboxes */
/* Framebuffer */
/* Property channel */
/* Random Number Generator */
/* Extended Mass Media Controller */
/* SDHOST */
/* DMA Channels */
/* GPIO */
One more time about the Raspberry Pi’s USB controller that is not emulated: ‘We don’t have an emulation of the BCM2835 USB controller. This means that there is no networking support, because on the raspi devices the ethernet hangs off the USB controller.’
This is how the ‘Principal Software Engineer at Raspberry Pi (Trading) Ltd.’ talks about the VC4’s USB controller: ‘The SoC has a inbuilt USB device, which sadly is a bit crap but we cannot do anything about that, but with the ARM FiQ we have made it work pretty well.’ — quoted from https://github.com/raspberrypi/linux/issues/2512#issuecomment-384561940