QEMU patches for RPi emulation - Initial release

[Torlus]

Dang, no. I wasn't aware of these, otherwise I wouldn't have started from scratch
Thanks for pointing this out, I'll see what I can do about it.

[UncleVan]

Thank you for your effort.
I have 2 issues:
First, I can not manage the network to work - ifconfig only shows "lo" interface. I also manually insert smsc75xx module - to no help...
"smsc95xx.ko" isnt present anyway in 2012-12-16-wheezy-raspbian.img, so I removed "smsc95xx.macaddr=..." from kernel parameters. Im booting the original kernel from same .img
Is this a limitation or did I something wrong ?

Second one is pretty weird: In the emulation I set up a standard 105-Key keyboard with german layout. And just the key for the symbols "<>|" - "less then", "greater then" and "pipe" - doesnt work ! - so I can not recherche further. It is the one next to the left shift on german keyboards, showkeys calls it "keycode 86"

Also, I would like to help developing -could smbdy point me to some usable info about programming/extending QEMU ?

Thanks in advance - your UncleVan.

[Torlus]

First of all, it seems that USB emulation in QEMU is limited to USB 1.1.
The Ethernet module is a USB-attached one, and its QEMU driver is yet to be written... There's a "dev-network.c" source that may be a good starting point, though.
For the German layout issue, I have no idea...
About the QEMU development related documentation, well, I haven't found anything relevant, but the code is quite easy to read, and there's a large amount of already written devices, that you can use as examples (that's what I did, for the most).
Regards

[UncleVan]

Thanks for the response !
- No doubt: Great Work! Even the gpm works, so Im saved from keyboard issues...

I would tip for both on the USB/Keyboard implementation in Qemu. Note: it is not the keyboard layout - which is fully OK for the rest - , it is simply a missing key

When Im emulating "the easy way" - versatilepb, with qemu emulated kernel from some forum here (uname -r = 3.6.8) - there is some kind of obscure (smc91x) net card working well, and the keyboard also; which is not an USB then (see logs). Also, dmesg reports some usb activity when I insert smsc75xx module.

This is maybe a hint for you, as for me it would take time to dive in the QEMU code...

BTW: Why you use the "smsc95xx.macaddr=B8:27:EB:D0:EE:DF" option then ?

Your UncleVan.

PS: can not attach log, because "extension is not allowed".. but it is not so important

[cooky451]

Hi,

I'm trying to get a Raspberry Pi emulator running, and this qemu branch seems to be the best possibility so far. Thanks for your work Torlus. But I still have a few issues. I compiled qemu myself on windows with MinGW (took me 2 hours with all the dependencies. <.<), but hey, it finally worked. Now I copied the qemu-system-arm.exe, qemu-img.exe and qemu-io.exe together with all the needed .dlls and the pc-bios folder into a separate directory. First thing qemu told me is that it couldn't find the key-maps. Okay, so I just copied all the files from /pc-bios/keymaps into the directory where the qemu-system-arm.exe is. Now I tried to use the command-line arguments from https://github.com/Torlus/qemu-rpi, but qemu just didn't start at all. (Nothing happens when starting qemu. Not even a window shows up. No output on the console.) Then I tried
-kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -append "root=/dev/sda2" -hda 2012-07-15-wheezy-raspbian.img
which worked, surprisingly enough. It shows a few failures while booting (and ICMP doesn't work while TCP and DNS do apparently, no idea why.) but in the end it worked. Okay, now the thing is, I want to use the emulator to build my own kernel. If I start qemu with
-kernel my_kernel -cpu arm1176 -m 256 -M versatilepb
It "works", meaning that my code runs (I can watch the register values changing through the qemu monitor), but it seems like the peripherals don't get emulated. Specifically, I don't get any answer from the postman when requesting a frame buffer. (I just always get 0, basically nothing happens.)
If I start with
-kernel my_kernel -cpu arm1176 -m 256 -M raspi
qemu immediately crashes, even if the "my_kernel" does nothing else than while (true);

Any ideas?

[jnc100]

Due to a novelty in the way libsdl works on Windows you won't get any output on the console but instead it will create files stdout.txt and stderr.txt in the current directory - check for these.

If you find an error saying than the raspi board doesn't exist then you've probably checked out the wrong branch of Torlus' repository. As far as I can see the framebuffer, sd and timer functionality all work great.

Regards,
John.

[cooky451]

Thanks for the fast answer. The stderr.txt and stdout.txt are empty. (Using -kernel my_kernel -cpu arm1176 -m 512 -M raspi). I downloaded (and compiled) https://github.com/Torlus/qemu/tree/rpi
However, maybe I didn't configure it correctly? I just used
./configure --python=..
make
Without selecting any further options. Also, if the "board" isn't there, this probably means that this error could come up when qemu doesn't find a specific file. Which file would that be? Maybe I can find it and copy it to the qemu directory.

Edit: No, the .exe definitely seems to know raspi. If I give some random name for -M it shows the "Supported machines"-list in stdout.txt - Also, the program just closes, and I don't get an error.
raspi Raspberry Pi
Shows up in the list, but if I use -M raspi qemu just immediately crashes, as I already wrote.

Edit: If I use something else, e.g. realview-pbx-a9, qemu does not crash.

[Torlus]

Then I tried
-kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -append "root=/dev/sda2" -hda 2012-07-15-wheezy-raspbian.img

If I start with
-kernel my_kernel -cpu arm1176 -m 256 -M raspi
qemu immediately crashes, even if the "my_kernel" does nothing else than while (true);

You're trying to do very different thing here. Running with the "-M versatilepb" option emulates ARM's Versatile Platform Baseboard series' hardware. Using "-M raspi" option emulates the RasPi (badly) based on my patches.
I haven't tried to build it on Windows, but well, honestly, running a Linux VM with VirtualBox is easy, that's how I'm developing these patches (I use a 32-bit Ubuntu 12.04 LTS distro running in VirtualBox, on my Win7 setup). And if you're planning to create your own kernel/OS, using Linux as a host seems a reasonable way to go.

[cooky451]

So what you're saying is that qemu-rpi is probably not going to run on windows? Emulating a Linux system to emulate the rpi seems kinda annoying to me.

[ShiftPlusOne]

So what you're saying is that qemu-rpi is probably not going to run on windows? Emulating a Linux system to emulate the rpi seems kinda annoying to me.

Correct me if I am wrong, Torlus. It should be possible to compile qemu-rpi the same way you would compile regular qemu. I've compiled qemu for windows a few times, but it's certainly not worth the effort. I may give this a go if I get some free time, though I suspect someone else will beat me to it.

[Torlus]

So what you're saying is that qemu-rpi is probably not going to run on windows? Emulating a Linux system to emulate the rpi seems kinda annoying to me.

Correct me if I am wrong, Torlus. It should be possible to compile qemu-rpi the same way you would compile regular qemu. I've compiled qemu for windows a few times, but it's certainly not worth the effort. I may give this a go if I get some free time, though I suspect someone else will beat me to it.

Yes it should be possible After all, I don't see something in my code that could prevent doing so.
@cooky451 I was just suggesting that if your goal is to write your own OS, using Linux as a host seems better than using Windows, as the tools you'll end up using, such as MinGW, are ports of Unix tools... Why use ports when you can use the original set of tools in an environment they were designed to run on ?
@ShiftPlusOne if you can give it a try, that surely would help

[cooky451]

I installed a debian virtual machine and compiled qemu-rpi again. Now, starting with
-kernel test.bin -cpu arm1176 -m 512 -M raspi
I get an segmentation fault. Maybe it's not just Windows.

Edit: Thanks to Jester01 (who actually found the bug) I could get it running on both: Linux and Windows. In /qemu-rpi/hw/bcm2835_fb.c go to line 303, comment in the outcommented lines, and comment out lines 305 and 320. Done.
Also, the resolution of the window doesn't change accordingly on Windows when requesting a framebuffer bigger than the initial indow. So, that's still kinda a bug I guess, but at least it works. (Changing the initial resolution to 640x480 instead of 0xY could help as well.)

[Torlus]

Could you provide the full command line, and the test.bin you're using ? I'd like to give it a try. Does the resolution change issue only occur in Windows ?

[cooky451]

http://www73.zippyshare.com/v/57202367/file.html
There are 3 .bin files:
- test.bin only sets the first registers to 1, 2, 3, 4, 5, 666666
- rpi.bin does request a 1024x768 framebuffer and writes some colors in it once
- screen01.bin is the compiled version from http://www.cl.cam.ac.uk/freshers/raspbe ... een01.html - it gives a flashing screen.
The full command line is just
qemu-system-arm -kernel the_kernel.bin -cpu arm1176 -m 512 -M raspi
I'm only experimenting with the framebuffer at the moment, so I don't seem to need the rest.

The resolution issue seems only to occur on Windows I guess, on my virtual debian machine it works fine.

[Torlus]

Thanks for the files.
They work on my setup, without the suggested changes, which means in my opinion that the fix isn't as obvious as it seems. These differences in behaviours are probably due to the fact that display management is quite host-dependent, and that my code needs some rework...
It's probably due to a different scheduling of the callback functions, which my code doesn't handle properly.

[Torlus]

Just commited some files... Added a lock/unlock mechanism to avoid half-done parameters changes, in the hope it will fix these issues. If you can find some time to give it a try, I'd be glad.

[yepsar]

Hi,

First thanks a lot for your work. It saves me so much time plugging and removing the sd card

Just got a question though. It works great for my bare-metal OS, until I introduced some character strings and global arrays. After a lot of poking around (since there is no debugging tools that I know of; no printf, not even the LED on the real board; you got any special tools for qemu?), I found that when I dereference a pointer to a string or a global array, it always returns 0, no matter what the memory actually has.

I suspect my link script is buggy, or maybe your qemu code is more strict that the real hardware. By looking at the asm code and the output of objdump, I think the code is correct, and the data is where the code thinks it is. But "ldr" keeps returning 0.

Below is my link script. If you want anything, the kernel.img or my code, I'll mail it to you.

Code: Select all

ENTRY(_start)
MEMORY
{
	kernel : org = 0x8000, len = 1M
}
SECTIONS
{
	.text : { *(.text*) } >kernel
	.bss : { *(.bss) } >kernel
	.data : { *(.data) } >kernel
	.rodata : { *(.rodata) } >kernel
}

(I use the latest code from your github repo, HEAD 02bf596d944).

[Torlus]

Well, you have gdb support in QEMU, which should help.
For example on my setup, for debugging a Linux kernel (well it was for debugging my own code, but you get the idea) :

Code: Select all

~/rpi/usr/bin/qemu-system-arm -kernel zImage -cpu arm1176 -m 512 -M raspi -no-reboot -serial stdio -append "rw earlyprintk loglevel=8 panic=120 keep_bootcon rootwait dma.dmachans=0x7f35 bcm2708_fb.fbwidth=1024 bcm2708_fb.fbheight=768 bcm2708.boardrev=0xf bcm2708.serial=0xcad0eedf smsc95xx.macaddr=B8:27:EB:D0:EE:DF sdhci-bcm2708.emmc_clock_freq=100000000 vc_mem.mem_base=0x1c000000 vc_mem.mem_size=0x20000000  dwc_otg.lpm_enable=0 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait" -sd 2012-12-16-wheezy-raspbian.img -device usb-kbd -device usb-mouse -S -s -d guest_errors

The important options here are "-S -s" which tells QEMU to start the gdb agent, and wait for a connection.
Then you can run gdb :

Code: Select all

~/rpi/arm-2011.03/bin/arm-none-linux-gnueabi-gdb linux/vmlinux
GNU gdb (Sourcery G++ Lite 2011.03-41) 7.2.50.20100908-cvs
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-none-linux-gnueabi".
For bug reporting instructions, please see:
<https://support.codesourcery.com/GNUToolchain/>...
Reading symbols from /home/greg/rpi/linux/vmlinux...done.
(gdb) target remote:1234
Remote debugging using :1234
0x00000000 in ?? ()
(gdb) display/i $pc
1: x/i $pc
=> 0x0:	mov	r0, #0
(gdb) ni
0x00000004 in ?? ()
1: x/i $pc
=> 0x4:	ldr	r1, [pc, #4]	; 0x10
(gdb) 

Then, make sure you're running your own kernel like this :

Code: Select all

~/rpi/usr/bin/qemu-system-arm -M raspi -cpu arm1176 -kernel kernel.img -initrd kernel.img

Yes, that's an horrible hack to select either QEMU's specific Linux kernel booting stuff, or otherwise boot to 0x8000 (it works for alternate OSes like RiscOS or Plan9).
Hope this helps.

[Neumaennl]

Hi Torlus,

I just compiled your qemu branch and tried to run the latest raspbian with it, but I did not have any success.
qemu can start the kernel I extracted from the raspbian image, but I can't log in and I can't connect via vnc either.
start script
log
Here's how I compiled your qemu branch (on a recent 64bit Ubuntu):

Code: Select all

$ ./configure --prefix=/home/neumaennl/qemu-rpi
$ make all
$ make install

It didn't complain once.
I can also provide the output of configure and make if you need it.
I hope you can help me get this up and running.
Thanks for your work!

[yepsar]

Then, make sure you're running your own kernel like this :

Code: Select all

~/rpi/usr/bin/qemu-system-arm -M raspi -cpu arm1176 -kernel kernel.img -initrd kernel.img

Ah, that's it! Adding "-initrd kernel.img" makes it work. ISTR I saw that somewhere but didn't pay much attention.

Now I can continue coding without my rpi at hand.

[ShiftPlusOne]

Hm, I've spent some time fiddling around with compiling qemu in windows. Vanilla qemu builds fine, but ran into some trouble compiling your rpi branch.

Builds fine up until the linking stage.

LINK arm-softmmu/qemu-system-arm.exe
../qemu-char.o: In function `qemu_chr_open_udp':
f:\XEC\qemu/qemu-char.c:2300: undefined reference to `io_channel_from_socket'
../qemu-char.o: In function `udp_chr_update_read_handler':
f:\XEC\qemu/qemu-char.c:2266: undefined reference to `io_add_watch_poll'
../qemu-char.o: In function `tcp_chr_connect':
f:\XEC\qemu/qemu-char.c:2541: undefined reference to `io_add_watch_poll'
../qemu-char.o: In function `tcp_chr_add_client':
f:\XEC\qemu/qemu-char.c:2571: undefined reference to `io_channel_from_socket'
../qemu-char.o: In function `qemu_chr_open_socket_fd':
f:\XEC\qemu/qemu-char.c:2702: undefined reference to `io_channel_from_socket'
f:\XEC\qemu/qemu-char.c:2711: undefined reference to `io_channel_from_socket'
../qemu-char.o: In function `tcp_chr_write':
f:\XEC\qemu/qemu-char.c:2344: undefined reference to `io_channel_send_all'
collect2.exe: error: ld returned 1 exit status
make[1]: *** [qemu-system-arm.exe] Error 1
make: *** [subdir-arm-softmmu] Error 2

Anyone know what gives?

[tavy]

Hi,
I've been working for a few weeks on a QEMU backend for RPi emulation.
It's now advanced enough to boot an unmodified Linux kernel, along with its associated SD image.

Get it here : https://github.com/Torlus/qemu-rpi
Please read carefully the instructions.

It's far from being complete, but well, I'm releasing it anyway.
Hope it helps, and feel free to contribute.

Regards,
Greg

Hi Torlus, thanks for this great work, it works pretty good with 2013-02-09-wheezy-raspbian (after commenting out the contents of /etc/ld.so.preload).

Does GPIO emulation works? The /sys/class/gpio folder exists, but what happens if I write a value after exporting a pin?

[DavidS]

Even though I do not understand emulating a RPi:

If anyone is planning on actually adding EtherUSB support for the DWC network controller, you may like to know that it works well with USB 1.1 Full Speed 12Mb/s, I have found this while debuging my USB Stack for RISC OS, yesterday I had everything working with only USB1.1 support (actually seemed to work quite a bit better that way [though a bit slow with Mass Storage]).

[Torlus]

Hi,
Just a quick set of answers, I've been quite busy lately...
@Neumaennl : there is no network emulation yet, you use the console to log in.
@ShiftPlusOne : well, I try to keep up with the "master" branch on github, by merging often... Does the vanilla qemu "master" branch compile on windows ?
@tavy : GPIO isn't available yet, but shouldn't too hard to do... question is, why and what should it "connect" to at the host level ?
@DavidS : that's quite interesting, if you want to share what you've done, that would help.
Regards,
Greg

[Neumaennl]

Torlus: I did try to log in via the console, but couldn't...