QEMU patches for RPi emulation - Initial release

[Torlus]

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

Can you give the full command line you're using ?

[Neumaennl]

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

Can you give the full command line you're using ?

I did. It was in my initial post.
Here is my start script again: http://pastebin.com/vYXjS2GB
The log and other info is in my post.
If you need anything else just tell me.

[tavy]

Hi,
@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 ?
Greg

I'm trying to do the GPIO module based on your bcm2835_* files.
My idea is to make a host application (that uses a circuit simulator) that will be connected to the target raspberry machine.

What do you think about this idea?
I want to do this as a university project.

Thanks!

[tastenmonster]

Hi, I successfully compiled yout patches and I am able to run basic baremetal code on rpi emulation. Is the Arm timer emulation working? I can't get an interrupt from this?

[Torlus]

Hi,

Hi, I successfully compiled yout patches and I am able to run basic baremetal code on rpi emulation. Is the Arm timer emulation working? I can't get an interrupt from this?

Does it work on hardware (I guess it does...) ? Which timer are you using ? It might be an issue with timer resolution...

[tastenmonster]

Hi,

Hi, I successfully compiled yout patches and I am able to run basic baremetal code on rpi emulation. Is the Arm timer emulation working? I can't get an interrupt from this?

Does it work on hardware (I guess it does...) ? Which timer are you using ? It might be an issue with timer resolution...

The ARM side timer with baseaddress 0x2000B400 is used. I play around with the rtems bsp for rpi. see http://www.raspberrypi.org/phpBB3/viewt ... 72&t=38962 It would be great to use your emulation for debugging and testing.

[JonD]

Hi Torlus, ShiftPlusOne,
I have exactly the same problem as ShiftPlusOne during link when compiling under MinGW with io_control_width etc

I seem to be able to compile a freshly downloaded copy of vanilla Qemu 1.4.1
Was this issue resolved? If not, is there anywhere I could get a windows build of Torlus' RPI version?

Cheers
Jon

[Torlus]

Well, it's been a long time since I merged my changes with the QEmu trunk...
I'll try to do it asap, it might solve these issues.
Regards,
Greg

[tastenmonster]

Hi,

Hi, I successfully compiled yout patches and I am able to run basic baremetal code on rpi emulation. Is the Arm timer emulation working? I can't get an interrupt from this?

Does it work on hardware (I guess it does...) ? Which timer are you using ? It might be an issue with timer resolution...

The ARM side timer with baseaddress 0x2000B400 is used. I play around with the rtems bsp for rpi. see http://www.raspberrypi.org/phpBB3/viewt ... 72&t=38962 It would be great to use your emulation for debugging and testing.

I got it working! The

Code: Select all

#define APBCLOCK_FREQ (252000000)

has to be set to 250 Mhz. And the control word mask in bcm2835_timer_write(...) has to be

Code: Select all

s->control = value & 0x00ff03ae;

THe timer IRQ enalbe flag was just masked out.

[JonD]

Hi Torlus,
some progress... I can successfully compile your branch on Ubuntu with no problems. The problems seem related to building under MinGW, which is where I really want to be able to run.

However, although I can run Wheezey under your branch, when I try to boot RISCOS I get a large black screen:

[email protected]:~/qemu-rpi$ arm-softmmu/qemu-system-arm -kernel /mnt/riscos -initrd /mnt/riscos -cpu arm1176 -m 512 -M raspi -snapshot -sd /mnt/ro519-rc6-1876M.img -d guest_errors -serial stdio
HalStartup
HalQueryPl
=== PROPERTY MBOX PUSH BEGIN addr=00009080
Request:
[0000011c] [00000000] [00010003] [00000008] [00000000] [00000000] [00000000] [00010004]
[00000008] [00000000] [00000000] [00000000] [00010005] [00000008] [00000000] [00000000]
[00000000] [00010006] [00000008] [00000000] [00000000] [00000000] [00010001] [00000004]
[00000000] [00000000] [00010002] [00000004] [00000000] [00000000] [00060001] [00000004]
[00000000] [00000000] [00048003] [00000008] [00000008] [00000780] [00000438] [00048004]
[00000008] [00000008] [00000780] [00000438] [00048009] [00000008] [00000008] [00000000]
[00000000] [00048005] [00000004] [00000004] [00000020] [00048006] [00000004] [00000004]
[00000001] [00048007] [00000004] [00000004] [00000002] [00040008] [00000004] [00000000]
[00000000] [00040001] [00000008] [00000008] [00100000] [00000000] [00000000]
TAG [00010003]
TAG [00010004]
TAG [00010005]
TAG [00010006]
TAG [00010001]
TAG [00010002]
TAG [00060001]
TAG [00048003]
TAG [00048004]
TAG [00048009]
TAG [00048005]
TAG [00048006]
TAG [00048007]
TAG [00040008]
TAG [00040001]
TAG [00000000]
Response:
[0000011c] [80000000] [00010003] [00000008] [80000006] [b827ebd0] [eedf0000] [00010004]
[00000008] [80000008] [00000000] [00000000] [00010005] [00000008] [80000008] [00000000]
[1c000000] [00010006] [00000008] [80000008] [1c000000] [04000000] [00010001] [00000004]
[80000004] [00000000] [00010002] [00000004] [80000004] [00000000] [00060001] [00000004]
[80000004] [0000003c] [00048003] [00000008] [80000008] [00000780] [00000438] [00048004]
[00000008] [80000008] [00000780] [00000438] [00048009] [00000008] [80000008] [00000780]
[00000438] [00048005] [00000004] [80000004] [00000020] [00048006] [00000004] [80000004]
[00000001] [00048007] [00000004] [80000004] [00000002] [00040008] [00000004] [80000004]
[00001e00] [00040001] [00000008] [80000008] [1c100000] [007e9000] [00000000]
=== PROPERTY MBOX PUSH END
1C100000 007E9000 HalQueryPldone
1C100000 HalStartup2
00008000 00000000 1C000000 ROM start, RAM start, RAM size
ROM relocated
HalStartup3 .. rst rend
00000000 1BA00000 HalStart from OS
1C000000 04000000 F5000000 HAL Init completed
SD: CMD7 in a wrong state

Any thoughts?
I'm very much looking forward to running this! Thanks for your work on it.

Best regards
Jonathan

[JonD]

Hi Torlus, ShiftPlusOne,
Looks like I've found the compile issue. There were a couple of fixes for the Win32 build that went in just after torlus' last merge, on March 10th. Nothing more than a few ifdef __WIN32's

Now builds just fine under MinGW, but I still get the black screen, and Qemu shows as "stopped"

Best regards
Jonathan

[ShiftPlusOne]

Hi Torlus, ShiftPlusOne,
Looks like I've found the compile issue. There were a couple of fixes for the Win32 build that went in just after torlus' last merge, on March 10th. Nothing more than a few ifdef __WIN32's

Now builds just fine under MinGW, but I still get the black screen, and Qemu shows as "stopped"

Best regards
Jonathan

Thanks for looking into this. I've put qemu on the shelf for now, but it's nice to know that when I get back to it, that won't be an issue.

[Torlus]

I've just merged my changes with the "master" branch.
If anyone can give it a try (with MinGW)...
@JonD : RiscOS still hangs but displays something on startup (at least on Linux).

[JacobL]

Your ATAGs are loaded at the wrong address. You load them at 0x400, but they should really be at 0x100 (the value in r2 at boot). Also, it would be nice to get the memory size in ATAG_MEM calculated based on memory size. Here is a patch for that:

Code: Select all

diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
index 8f71a9e..2c16e07 100644
--- a/hw/arm/raspi.c
+++ b/hw/arm/raspi.c
@@ -47,7 +47,7 @@ const uint32_t bootloader_0[] = {
 0x00008000
 };
 
-const uint32_t bootloader_400[] = {
+uint32_t bootloader_100[] = {
 0x00000005,
 0x54410001,
 0x00000001,
@@ -55,7 +55,7 @@ const uint32_t bootloader_400[] = {
 0x00000000,
 0x00000004,
 0x54410002,
-0x08000000,
+0x08000000, /* This value will be overwritten by dynamically calculated memory size */
 0x00000000,
 0x00000000,
 0x00000000
@@ -110,6 +110,8 @@ static void raspi_init(QEMUMachineInitArgs *args)
     
     bcm2835_vcram_base = args->ram_size - VCRAM_SIZE;
     
+    bootloader_100[7] = bcm2835_vcram_base; /* Write real RAM size in ATAG structure */
+
     memory_region_init_ram(bcm2835_ram, "raspi.ram", bcm2835_vcram_base);
     vmstate_register_ram_global(bcm2835_ram);
 
@@ -326,8 +328,8 @@ static void raspi_init(QEMUMachineInitArgs *args)
         for(n = 0; n < ARRAY_SIZE(bootloader_0); n++) {
             stl_phys( (n << 2), bootloader_0[n]);
         }
-        for(n = 0; n < ARRAY_SIZE(bootloader_400); n++) {
-            stl_phys( 0x400 + (n << 2), bootloader_400[n]);
+        for(n = 0; n < ARRAY_SIZE(bootloader_100); n++) {
+            stl_phys( 0x100 + (n << 2), bootloader_100[n]);
         }
         load_image_targphys(args->initrd_filename,
                             0x8000,

ATAG_CMDLINE is still missing compared to the real hardware though.

[JacobL]

The documentation has a question regarding why the "rw" argument is necessary for booting Linux kernels. I think I can answer that: The ATAG_CORE has a read only flag, which gets set by QEMU ARM boot code, but I am pretty sure that the real rpi hardware has this cleared. This value is also set in your bootloader_400[2], but I suspect there is very little bare metal code that actually reads this (you will need my previous patch for that to actually work).

[Torlus]

@JacobL thanks for all these info.
I will perform the changes accordingly asap.
Regards,
Greg

[JacobL]

Has anyone taken a look at why we need to disable libcofi_rpi.so in 2013-02-09-wheezy-raspbian with Qemu? The code at https://github.com/simonjhall/copies-and-fills doesn't look like it has any exotic instructions, though I suppose the varied usage of conditionals might bring the Qemu instruction decoder into some untested corners.

Edit: Turns out this is most likely the implementation of memcmp, which is not on github. I tried to add some debug to the illegal instruction handler, and noticed that when libcofi_rpi is running, then an extra instruction gets added to the list: 0xF1010200, which is setend trying to set big endian mode. If I grep a hexdump of libcofi_rpi.so, then I find this instruction 0x638 bytes into the file. If I run readelf on the file, then I can see that the memcmp symbol starts at 0x634. The comment in Qemu says "Dynamic endianness switching not implemented", so I suppose this is on purpose. I guess to make it work, one would have to first make all load/store operations respect CPSR[9], the "E" bit, which should add big endian data support. Luckily, setend only affects data endianness, not instruction endianness (seems big-endian instructions is referred to as a legacy mode on ARMv6 in the ARM ARM).

[asb]

Edit: Turns out this is most likely the implementation of memcmp, which is not on github. I tried to add some debug to the illegal instruction handler, and noticed that when libcofi_rpi is running, then an extra instruction gets added to the list: 0xF1010200, which is setend trying to set big endian mode. If I grep a hexdump of libcofi_rpi.so, then I find this instruction 0x638 bytes into the file. If I run readelf on the file, then I can see that the memcmp symbol starts at 0x634. The comment in Qemu says "Dynamic endianness switching not implemented", so I suppose this is on purpose. I guess to make it work, one would have to first make all load/store operations respect CPSR[9], the "E" bit, which should add big endian data support. Luckily, setend only affects data endianness, not instruction endianness (seems big-endian instructions is referred to as a legacy mode on ARMv6 in the ARM ARM).

The code for the mem{cpy,cmp,set, move} replacements we're using are at https://github.com/bavison/arm-mem

[JacobL]

The code for the mem{cpy,cmp,set, move} replacements we're using are at https://github.com/bavison/arm-mem

Ahh. It moved. I did wonder why most recent commit was 10 months ago. Thanks.

And I can also confirm that second instruction in memcmp is a setend instruction, which is not supported in Qemu, and it will result in the "illegal instruction" triggering. If I get some time I might try to implement it.

[UncleVan]

I got kind of lost in git/configuration etc and things stoped working for me...

Someone be so nice to post anew (or point to) clean valid instruction for building the rpi fork on Linux ? (I found my old ones not working any more)

Like this:
1. git clone / checkout ...
2. ./configure
3. qemurpi command line to start

Does it matter which raspbian immage Im using ?

Great thanks in advance !

[JacobL]

Code: Select all

sudo apt-get install git zlib1g-dev libsdl1.2-dev libpixman-1-dev
git clone git://github.com/Torlus/qemu.git -b rpi
cd qemu
./configure --target-list="arm-softmmu arm-linux-user" --enable-sdl --prefix=/opt/qemu-rpi
make -j[number of threads supported by PC]
sudo make install

Now, mount your Raspbian image with kpartx:

Code: Select all

sudo kpartx -a [raspbian image]
sudo mount /dev/mapper/loop0p1 fat
sudo mount /dev/mapper/loop0p2 linux

Copy kernel.img from your fat mount so you can use it for starting Qemu. On your linux mount, edit etc/modules and remove/comment out the line for "snd-bcm2835". Also edit etc/ld.so.preload and remove/comment out the line for "/usr/lib/arm-linux-gnueabihf/libcofi_rpi.so".

Now, clean up from this:

Code: Select all

sudo umount linux
sudo umount fat
sudo kpartx -d [raspbian image]

You should now be able to boot raspbian under Qemu:

Code: Select all

/opt/qemu-rpi/bin/qemu-system-arm -kernel kernel.img -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 [raspbian image] -device usb-kbd -device usb-mouse -snapshot

These instructions will work on latest raspbian 2013-05-25.

[UncleVan]

Great - thank you Jacob ! - Now I have a decent working qemu-rpi :

Code: Select all

$ /opt/qemu-rpi/bin/qemu-system-arm -version
QEMU emulator version 1.4.93, Copyright (c) 2003-2008 Fabrice Bellard

Following issues (also @ Torlus):
1. The "2013-05-25-wheezy-raspbian.img" boots its own kernel but doesnt get into init and issues the ubiquitous "Unable to determine your tty name." It seems that /root gets not mount.
2. "2012-12-16-wheezy-raspbian.img" is booting and inits well, but hangs when trying to start X - not a great deal, but I do distinctly remember last time I build it (February 2013) I was able to start X with LXDE and lxsession. Maybe some missing "./configure" parameter ?
3. During qemu session the stdio gets messed up with messages iike:

Code: Select all

=== PROPERTY MBOX PUSH BEGIN addr=5ba6e000
Request:
[00000020] [00000000] [00030006] [00000008] [00000000] [00000000] [00000000] [00000000] 

TAG [00030006]
TAG [00000000]
Response:
[00000020] [80000000] [00030006] [00000008] [80000008] [00000000] [000061a8] [00000000] 

=== PROPERTY MBOX PUSH END
=== PROPERTY MBOX PUSH BEGIN addr=5ba6e000
Request:

etc
Is it possible to suppress them ? (2>/dev/null doesnt do it)

[jayachar]

This thread is very interesting, and lot of great work has been done by Torlus and JacobL. However looks like it went from a phase of greater success in running unmodified Qemu img earlier this year, to it's current form where it is somewhat less successful. Any updates that could be shared ? Of another place / thread where the progress can be tracked ?

[JacobL]

Not sure if I would call it unsuccessful. For my part, it does what I need it to do. It had some bugs that blocked me in the beginning, so I fixed them and sent a patch. Not much more to it really.

If you are referring to the missing support for the SETEND instruction in Qemu, then the progress is pretty much as can be seen here. I have not had time to look at it yet and I don't think I will anytime soon, so if you want to look into it, go right ahead. I did get time to look into endian handling in Qemu though, and it turned out that it was more complicated that it looked. Basically the optimized Qemu instruction decoding for every single load/store instruction will need to have some dynamic handling added that will inevitably lead to reduced overall performance in Qemu for ARM.

[tvoverbeek]

Compiled torlus rpi branch yesterday on my Mac (OSX 10.7).
Resulting qemu boots the latest raspbian (2013-07-26-wheezy-raspbian.img)
after applying the described fixes (disable sound and empty /etc/ld.so.preload) and extracting
kernel.img (used a VirtualBox Puppy Linux for this).
Also startx works. Can run Scratch etc.
A pity networking does not work yet. Tried with usb-net, but qemu aborts due to incomplete
usb emulation in bcm2835_usb.c (assert(0) on line 225).

If you want to get rid of all the MBOX messages comment out the "#define LOG_REG_ACCESS"
in qemu/hw/arm/bcm2835_property.c

Many thanks to everybody who got this working so far.

Ton van Overbeek