Pandora Pandora/angstrom Running In Qemu (Incomplete Wip!)


Archaemic

Still Fresh
Joined
Apr 3, 2009
Messages
53
Age
34
Website
Visit site
First off: this doesn't fully work yet, so don't get your hopes up. I'm not sure if it can be made to fully work--I'm still poking at it to try and get it to work.

A bit curious to see if it had been done, I poked around a bit to see if the Pandora had been run in QEMU before. I recently started using QEMU for a school project, so I decided to try and set it up on my own. My first attempt (using stock QEMU) failed miserably, so I decided to dig a little deeper. This is as far as I got:

pandora-qemu-bootloader.png
(Click for full)


I can't get past the bootloader, however. It doesn't seem to accept my keypresses (I tried page down to emulate the X button, but nothing).

So here's what I did!
(This was tested on Mac OS X--Linux probably works too, but Windows is unlikely without some sort of Unix environment, as bash, du, awk, dd, etc, are needed)

The stock QEMU only supports up to OMAP2, so the first step was getting a QEMU that worked with OMAP3. Fortunately, the hard part had been done for me by some nice people in Finland. So the first step was to clone the git repositories and build gles-libs and a QEMU that supports OMAP3. The instructions provided in the respective repositories were sufficient for getting it to compile on my Mac, although I encountered a bit of trouble trying to get it to compile on Linux (but I didn't look too hard into fixing it--YMMV).

The next step is to generate a NAND image for the Pandora. If I could get a proper dump of a Pandora NAND, it might just work--I don't know. But I don't have a Pandora (yet), so I had to synthesize my own NAND. I found a handy tool called bb_nandflash that is used for making BeagleBoard NAND images, so I downloaded it and tweaked it a bit to get it working for the Pandora. I have put the modified version here. You'll also need the ECC checksum generator which can be found in the same repository. You'll need to build this manually. You'll also need to point it to the directory that has qemu-common.h, which should be path/to/qemu/include (where you built qemu). Do something like "cc -I../qemu/include -o ecc bb_nandflash_ecc.c" to build it (as "ecc" in this example).

At this point, you'll need to get x-loader and u-boot builds. It would probably be a good idea to compile them from the official Pandora repository, but I didn't have a cross-compiler set up at the time, so I nabbed x-loader from BeagleBoard again. The u-boot build can be gotten from the Pandora firmware image.

Speaking of which, you will also need a firmware image for the Pandora. I downloaded Zaxxon + Hotfix 5 for this. Extract it, and also extract the bootf.tgz that comes with it. Now you have all the files you'll need to synthesize the NAND image. To do this, you'll use the tweaked bb_nandflash.sh/pandora_nandflash.sh (which I'll abbreviate to nandflash) to set up the image. Your directory structure looks something like this (you might have to consolidate some files):
Code:
./
    ecc
    nandflash
    rootfs.img
    u-boot.bin
    uImage
    x-load.bin.ift

...and some other files we don't care about right now. These are the files we need to toss together to make the NAND image. Let's say we want to call the image nand.bin. Then, you have to run these commands:
Code:
./nandflash x-load.bin.ift nand.bin x-loader
./nandflash u-boot.bin nand.bin u-boot
./nandflash uImage nand.bin kernel
./nandflash rootfs.img nand.bin rootfs
./ecc nand.bin 0x0 0xe80000

Installing the rootfs will take several minutes (or more), as it's copying 320MB into the image at a rate of 2kB per dd invocation (roughly 50kB/s when I did it, IIRC). The last line signs part of the binary, but I don't know exactly what it does because I sort of hobbled this together from bits I found on the internet.

So now we have a NAND image. Optionally, we can now construct a "restore" SD card, like the ones used for reinstalling the firmware on the Pandora. I did this, but it didn't help me much. I'll call the image sd.img, but we don't need it (right now). I'll put up instructions for constructing such an image later, if anyone wants it.

The last step is to boot it. Seeing as we installed QEMU first, this step is fairly painless. If you follow the instructions given with QEMU for installing it, you'll notice that we need to use something like LD_LIBRARY_PATH or DYLD_LIBRARY_PATH to tell qemu where to launch. I'll be using the OS X version in my example. All we need for this is the nand.bin file we generated earlier, and, if you generated it, the sd.img. This is the command you now run (in the same directory as the images, omitting the -sd sd.img bit if you didn't generate the SD card image):

DYLD_LIBRARY_PATH=/opt/dgles2/lib /opt/dgles2/bin/qemu-system-arm -M beagle -sd sd.img -mtdblock nand.bin -serial stdio -clock unix

You'll notice that I specified -M beagle, which tells QEMU that we want to use the BeagleBoard QEMU system specification. There isn't a specific system profile for the Pandora (yet?), so we'll have to make due with this. If all goes well, you should be greeted with a picture of the Pandora logo and some text for the boot menu.

Unfortunately, that's as far as I could get! I can't get the system to do anything with the boot menu, much less actually try to boot the system. It seems that either the NAND doesn't have the OS properly installed (quite likely), or something stranger is happening. If anyone knows more about this than I do, I am open to suggestions and corrections! It'd be cool if we could actually get Pandora/Angstrom running in QEMU, but this is about all I can do on my own.
 
here might be somthing of your interest:

http://openpandora.org/firmware/

But great progress so far :)
 
I'm pretty sure now that the reason that the bootloader wasn't responding to keyboard input is because the beagleboard configuration doesn't actually have a keyboard configured. Or much of anything, really. So I started writing a custom Pandora board configuration. I don't know much about the internals of QEMU, but it doesn't seem to do anything differently than the beagleboard one does, unfortunately. I also found a way to get the bootloader to drop me into a serial u-boot console, but I can't figure out much of what to do while I'm in that console. The custom Pandora board configuration, incomplete as it is, is available, if people want to hack it up better than I did.

E] So I managed to get the kernel to boot, using some trickery (I still can't get it to boot off of the NAND, even though the image in NAND is identical to the one on the SD card), but it can't seem to mount the rootfs in the NAND, and I don't think I can get it to boot off of the SD card unless I make the SD card an image of an ext2 volume. I can't do that until I get access to a Linux machine again, so it might be a few days before I can make any more progress.

E2] I sshed into one of my remote machines and managed make an ext2 volume, but even mounting that as the SD card didn't help:
[ 176.283325] VFS: Cannot open root device "mmcblk0p1" or unknown-block(2,0)
[ 176.283843] Please append a correct "root=" boot option; here are the available partitions:
[ 176.285003] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)

Wish I could figure out how to make it give me a list of devices it can see. I know my device emulation code is pretty bad, but I don't know enough about QEMU to fix it.

E3] Well, I just figured out that I can't get the NAND the right size without either hacking up QEMU a lot or X-Loader a bit. I don't really want to do either, though--I wanted it to run vanilla X-Loader, but QEMU doesn't expose the OMAP3530 right to X-Loader...

So I kind of give up :(
 
Back
Top