bzt
Posts: 206
Joined: Sat Oct 14, 2017 9:57 pm

Re: RPI3 QEMU

Wed Feb 07, 2018 2:01 pm

UPDATE: a good soul took my patch and picked up the fight with the qemu maintainers, so there's a new hope (sorry Lucas, I won't pay license fee for my words :-) ). Although he agrees with me that adding dummy device handlers is a total nonsense for a patch that only supposed to change the boot location and the cpu type, he did all the other modifications as they asked.

I hereby wish him good luck with successfully submitting the patch to the qemu mainline!

bzt

kete
Posts: 1
Joined: Fri Feb 09, 2018 6:07 pm

Re: RPI3 QEMU

Fri Feb 09, 2018 6:17 pm

Great work @bzt!

I work in the 64bit mode of RPi3 very much and I believe your project is very useful. I have these questions:

1. I applied your patch and built it for qemu 2.11. I should say that the latest git did not work because of another problem and 2.10 seems to lack some definitions like error: ‘MachineClass {aka struct MachineClass}’ has no member named ‘ignore_memory_transaction_failures’. However, when trying to load an image it seems that qemu hangs with around 90% cpu usage. I tested it with a 32bit kernel and it booted fine. Could you please give more insight on how to debug this? I suppose that we need a kernel that does not require a config.txt so I searched for one (mentioned in this thread), but it did not work either.

2. From the performance and convenience point of view, how does this patch compare with direct chrooting in arm64? Some programs cannot be compiled in that ways and they are a big pain. I wonder if everything will work using your solution or not.

bzt
Posts: 206
Joined: Sat Oct 14, 2017 9:57 pm

Re: RPI3 QEMU

Tue Feb 13, 2018 2:29 am

Hi kete,

Thank you! But this is not a big thing.

1. It seems qemu guys think it's funny to mess around a lot with the MachineClass interface :-) Here are the patches for specific qemu versions I've tested with. At 2.10.50 it was the min_cpus field that caused trouble for me, not the 'ignore...' one. I've tested with all kernels in my tutorials, and others had reported them working as well. Frankly I've never even tried linux because I was aware of the missing peripheral emulation. This patch (which only adds booting support) is just the first step on a long way to run an AArch64 linux kernel under qemu.

2. This patch only changes the firmware address and the cpu type, does nothing more. As such it should not have any performance impact at all, unless there's already a bug in Cortex-A53 emu code somewhere. I suggest to try adding '-d int' to qemu arguments. I've noticed that qemu does not handle exceptions in exception handlers well (there's no such thing on AArch64 like triple fault on x86). If the problem for example is exception handler code not being mapped properly, that would result in an endless Instruction Fetch Abort loop. That could lead to 90% cpu usage, but this is just a guess. My other guess would be the aforementioned peripheral emulation, namely the missing System Timer. As it's MMIO register reads as a constant zero, a naive delay() loop could end up in an infinite loop easily. See my delay tutorial on how to workaround this.

Hopefully Pekka will manage to submit the patch into mainline soon. If the qemu maintainers would have accepted my boot patch, I would have been working on the peripherals support by now. But no, instead they convinced me that I don't want to do anything with them any more. C'la vie!

Bests,
bzt

bzt
Posts: 206
Joined: Sat Oct 14, 2017 9:57 pm

Re: RPI3 QEMU

Fri Feb 16, 2018 7:22 pm

Good news Everyone! (TM) :-)

Thanks to Pekka, finally Peter has accepted 2 of the 3 patches required to boot 64 bit kernels in qemu on arm-next branch:
https://git.linaro.org/people/peter.may ... 00269d10eb

One more patch to go! Mainline raspi3 support in qemu may become reality sooner than I've hoped :-)

bzt

bzt
Posts: 206
Joined: Sat Oct 14, 2017 9:57 pm

Re: RPI3 QEMU

Sat Feb 24, 2018 10:59 pm

And finally made it through: https://git.qemu.org/?p=qemu.git;a=comm ... b9040f3504

Raspberry Pi3 boot is in the mainline qemu! I'd like to say thanks to Pekka Enberg for making this possible!

Cheers,
bzt

bzt
Posts: 206
Joined: Sat Oct 14, 2017 9:57 pm

Re: RPI3 QEMU

Mon Apr 30, 2018 11:19 pm

timanu90 wrote:
Tue Oct 17, 2017 11:01 am
Hi guys, seems that some people could run aarch64 rpi3 code in qemu. Anyone can tell me the version of qemu needed and what command you use to launch the session?
I can finally answer that question :-)
qemu 2.12 now has inital Raspberry PI 3 support! See change log.

The command to use it:

Code: Select all

qemu -M raspi3
Cheers
bzt

timanu90
Posts: 63
Joined: Sat Dec 24, 2016 11:54 am

Re: RPI3 QEMU

Fri May 04, 2018 12:27 pm

Hello bzt, very good news.

I have been busy, but I will try this soon.

Congratulations and thank you for your work.

Cheers
Tiago

gilius
Posts: 57
Joined: Sun Apr 08, 2018 1:12 pm

Re: RPI3 QEMU

Sat May 19, 2018 2:34 pm

Can somebody please give a tutorial on how to get anything to boot up at all with a display!?

qemu-system-aarch64 -M raspi3 -m 1G -kernel kernel8.img

I created a new disk image 100 MB FAT32 with some RPi3 boot files on it, but nothing displays - no rainbow screen - nothing.

adrien-lessard
Posts: 1
Joined: Mon Oct 29, 2018 7:39 pm

Re: RPI3 QEMU

Mon Oct 29, 2018 7:44 pm

I'm having the same issue as gilius here. I run

Code: Select all

qemu-system-aarch64 -M raspi3 -m 1G -kernel kernel8.img
and get a black window with nothing happening.

Could someone point out what I'm missing?

Note: qemu version is 3.0.0

bzt
Posts: 206
Joined: Sat Oct 14, 2017 9:57 pm

Re: RPI3 QEMU

Wed Oct 31, 2018 11:57 pm

It's a bit more complicated than that, but I'll try to explain it for you in short.

When you emulate x86, then you emulate everything for the main processor (including the BIOS reading the boot sector from the provided disk image). For ARM (and specially with "-M raspi3"), this isn't the case.

On the Raspberry Pi board, ARM CPU is not the main processor, the VC GPU is. The files on the SD card (bootcode.bin, start.elf etc.) are compiled for the GPU and contain code to initialize the hardware (like the HDMI connection and the framebuffer with the rainbow splash). Start.elf parses config.txt and loads the kernel8.img from the SD card, finally enables the CPU by making it to execute that freshly loaded kernel image (which the GPU can't interpret btw).

Qemu on the other hand (being an ARM CPU emulator) does not emulate the VC GPU. Because the emulation starts at the ARM startup phase, bootcode.bin, start.elf and the others are NOT USED at all. Therefore there's no rainbow splash, neither is the kernel8.img loaded from the provided SD card image file (hence the need to pass the kernel directly with the "-kernel" argument). Although qemu does not emulate the VC, it does emulate the MailBox interface, so you can set screen resolution and get a framebuffer. You can draw on that buffer just like on a real hardware (but this time the framebuffer will not be read and displayed by the VC, but an X11 or SDL routine in qemu, unimportant detail from the ARM CPU's perspective).

What the "-M raspi3" does inside qemu is, that it tells qemu where to load the user provided kernel image in the emulated memory (to match the address that start.elf uses), and sets up some device emulation of the BCM2837 SoC, so that it seems to the emulated ARM CPU it's running on a Raspberry Pi board. Qemu is not a real, fully featured Raspberry Pi hardware emulator, just an ARM emulator.

Hopefully this makes now sense to you,
bzt

Return to “Bare metal, Assembly language”