emulateing raspberry pi 1 with qemu

Define "doesn't work".

What version of qemu are you using and where are you getting it from?

Theo

In windows 10 that works fine:

--
aen

"doesn't work" means there is no response (boot messages) besides heavy host cpu consumption. qemu window remains black.

I tried the latest windows installer from

"qemu-w64- setup-20171108.exe" which installs qemu v2.10.90. That again seems to come from

This version has a promising machine option "-M raspi" instead of the afore mentioned "-M raspi2". Sadly this version stops with the Error "ERROR:/home/stefan/src/qemu/repo.or.cz/qemu/ar7/qom/ object.c:176:type_get_parent: assertionfailed: (type->parent_type != NULL).

I also tried the master branch (qemu 2.11.0-rc1) from git.qemu.org/ qemu.git on archlinux. This version has the option "-M raspi2" only which "doesn't work" for raspi1 images (black screen, no response, no "decrompressing initrd/kernel image").

With the raspi2 image devuan_jessie_1.0.0_armhl_raspi2.img and corresponding "kernel7.img" qemu shows some boot messages (until init is killed) using qemu command line option "-dtb bcm2709-rpi-2-b.dtb" instead of "-dtb bcm2708-rpi-b.dtb"

qemu/hw/arm/raspi.c from git.qemu.org/qemu.git seems to differentiate between raspi 1 and 2 though:

static const int raspi_boardid[] = {[1] = 0xc42, [2] = 0xc43};

This master branch from git.qemu.org/qemu.git has a function "raspi2_machine_init" in hw/arm/raspi.c but lacks a "raspi_machine_init" as in

My hope was that it is simply a question of finding the right command line options. But the code suggests it is not (yet/anymore) implemented.

OK, so you're doing sensible things compiling the head of upstream sources, rather than running old versions which you might be if you downloaded qemu from somewhere random.

Though maybe the Pi stuff is on a branch somewhere?

It may be the relevant machine isn't compiled in.

That's promising. I'm puzzled why Pi 1 images don't work though - qemu should support them.

Try bog standard Raspbian?

I think this board ID is the some jumpers which are hardwired on the PCB. I think it's mostly used by things like wiringPi to name the GPIOs appropriately on different boards. I don't know if there's anything in the kernel that uses it.

My guess would be that qemu emulates the GPU firmware, it doesn't emulate the whole SoC. So it could be that they have iterated the firmware and qemu has not kept up. A bit of a wild stab in the dark though.

Can you find a version of the kernel that qemu has been tested with?

Theo