qemu-maemo hangs when initializing omap2-nand driver

[Mounir Bsaibes]

The last output from the command: " sudo qemu-maemo-system-arm -M beagle -m 256 -sd ./beagle_sd8-25-0.img -clock unix -serial stdio" is the following line

[ 0.944580] omap2-nand driver initializing

it hangs after that. The qemu terminal is black and does not display anything.

The 20100803 build works fine.

I tired to go back to see which build broke, I could only go back to the 20100825 build. The daily build before 20100825 do not have tar files.
The 20100825 build is also broken.

So the error is somewhere between build 20100803 and 20100825 builds.

[Loïc Minier (lool)]

Peter, mind taking a look?

Perhaps the latest rebase on qemu-maemo upstream would fix this?

[Peter Maydell (pmaydell)]

I tried the rebased tree I have based on qemu-maemo's omap3-rebase branch, and also qemu-maemo's 'master' branch, but both of those hang at this point too... I'll have a look at what's actually happening tomorrow.

[Loïc Minier (lool)]

Mind preparing refreshed packages in the form of a git merge on gitorious? :-)

[Peter Maydell (pmaydell)]

In older omap kernels, the omap_nand_probe() function would exit early because it was passed a phys_base for the NAND of 0, which meant that request_mem_region() failed and we would never actually try to probe for the NAND. (Presumably this was a bug which has been fixed.) In any case, on the newer kernels we're passed a phys_base of 0x30000000, which we do attempt to probe. nand_command()'s NAND_CMD_RESET case successfully sends the commands to the GPMC but then this line:
  while (!(chip->read_byte(mtd) & NAND_STATUS_READY)) ;
(which is reading from physaddr 0x30000000) spins forever, because qemu doesn't map anything into the address space there, so you just get the default "reads-as-zero" behaviour.

qemu's omap_gpmc_cs_map() function only maps anything into the address space for NOR flash. I suspect this is simply missing functionality in qemu, although the OMAP35xx TRM is sufficiently large and confusing that I'm not sure exactly what we ought to be mapping into this space in the NAND case.

[Peter Maydell (pmaydell)]

On 3 September 2010 00:15, Loïc Minier <email address hidden> wrote:
> Mind preparing refreshed packages in the form of a git merge on
> gitorious?  :-)

Sure; any chance of some brief instructions on how to do that?
I have an account on gitorious, and I have a local git tree with
an 'ubuntu' branch into which I've done the rebasing -- how do
I get that usefully up onto gitorious?

thanks in advance
-- PMM

[Loïc Minier (lool)]

You could clone ubuntu-qemu-omap/qemu into a fork of yours on gitorious, and submit it for merging.

It's probably best that we go through a review process in the beginning, but could you provide me with your gitorious username so that I add you to the acl of ubuntu-qemu-omap/qemu as to allow you to merge changes from other folks, or your own trivial commits?

[Peter Maydell (pmaydell)]

I have a patch which fixes this bug; however it includes a dubious workaround for a clash between trying to map GPMC devices at address zero and omap3_boot wanting to map the boot ROM at address zero. I haven't yet been able to find out what the hardware does (ie the correct way to resolve this clash)...

[Peter Maydell (pmaydell)]

This should be fixed in qemu-maemo 0.0~20100921+871d996-0ubuntu1~linaro1 which is now in the linaro tools PPA https://launchpad.net/~linaro-maintainers/+archive/tools :

qemu-maemo (0.0~20100921+871d996-0ubuntu1~linaro1) maverick; urgency=low

  * New snapshot from meego/omap3-rebase branch; remaining changes:
    - Ignore writes of perf reg (cp15 with crm == 12)
  * Increase the address where we load the initrd on ARM so as
    to leave enough room for our piggish vmlinuz + its decompressed
    counterpart. (This is patch 'arm-higher-initrd-load-addr' from
    Ubuntu qemu-kvm, thanks to Jason Andrews, Loïc Minier.)
  * Fix ivshmem build on 32-bit hosts (cherry-pick of upstream qemu
    commit ad0a4ac1 from Avi Kivity <email address hidden>)
  * Map NAND devices into OMAP GPMC space; this fixes a failure
    to boot recent beagleboard kernels; LP: #628471
  * Fix an out-of-bounds array access causing a compile failure on
    ARM (cherry-pick of upstream qemu commit 2aa326be from
    Loïc Minier <email address hidden>)
 -- Peter Maydell <email address hidden> Tue, 21 Sep 2010 14:22:45 +0100

This uses the patch attached to this bug, so it includes the workaround of refusing to map NAND devices to address zero. Looking at whether that could be done more cleanly is on my todo list, but I think we can close this bug as the hang is fixed.