qemu-maemo: beagle model hangs if kernel tries to access NAND via prefetch/dma

Paul Larson points out in bug 652544 that recent images (eg 20100930) now try to access the NAND on startup, so they hang. That makes this more urgent...

> recent images (eg 20100930) now try to access the NAND on startup, so they hang

Gone away again in recent images, I think (eg 20101005), so back down to lower priority.

> Gone away again in recent images, I think

Only true if you have a local hack to fix bug 638966 so we generate the same (working) image in linaro-media-create whether writing to mmc or not, rather than having a special case which writes a different boot command if writing to an image file.

is there a workaround to boot the existing 10.10 omap3 image in qemu-maemo by avoiding the NAND timeout error?

You might see if you can pass the kernel a command line argument to turn off prefetch and DMA for the NAND accesses.

As I say, last time I tried this with a linaro image it worked OK, so if you could provide some brief reproducer instructions for where to get the image you're using and how you're invoking qemu that would be useful.

This is the command I use
qemu-maemo-system-arm -M beagle -m 256 -sd ubuntu-netbook-10.10-preinstalled-netbook-armel+omap.img -serial stdio

Wehre the image is the official Ubuntu 10.10 OMAP3 one
http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/10.10/release/ubuntu-netbook-10.10-preinstalled-netbook-armel+omap.img.gz

OK, I have reproduced with that image. I've had a look at the OMAP3 TRM regarding the prefetch engine and I think this should not be impossibly difficult to implement, so I'm having a look at it now.

I've implemented some patches to fix this, which you can find in this git branch on gitorious:
http://meego.gitorious.org/~pmaydell/qemu-maemo/pmaydell-qemu-meego/commits/nand-prefetch

and submitted a merge request to upstream:
http://meego.gitorious.org/qemu-maemo/qemu/merge_requests/1

Some notes if you're testing with the Ubuntu image:
(1) you'll need to dd some extra space onto the end of the .img file, otherwise the filesystem can't be resized and lots of things will complain about having no disk space:
dd if=/dev/zero of=ubuntu-netbook-10.10-preinstalled-netbook-armel+omap.img oflag=append conv=notrunc bs=1048576 count=1024

(2) it's pretty slow in places (minutes!), especially initial filesystem resize and setting up swap

(3) I was able to get the image to do the initial boot and setup, then it did its automated reboot, and then failed to start X because python died with a glibc-detected double free or something similar. I haven't investigated this, but the NAND access is pretty clearly working so I think that's a separate issue.

I confirm NAND access works with the new patches from your branch and it no longer hangs there, but as you experienced as well it does not boot fully, I'll file different bugs for those.