Hi Boris,
On 04/24/2016 10:14 AM, Boris Brezillon wrote:
[ ... ]
In qemu, it looks like gpmc bit 0 is considered to be the NAND chip select,
which is distinctly different to a chip ready pin.
Well, if you look at the GPIO controller implementation, you'll see
that gpichip->get() is adding 8 to the GPIO index, so the
implementation is actually testing bit 8 and not bit 0. Maybe this is
not emulated properly in qemu though...
That helps. The QEMU emulation always returns 0x0001 when reading gpmc register
0x54, which suggests that WAIT0STATUS reports as 0.
Guess I would have to try
finding a chip datasheet to figure out what this pin is supposed to do, and
what is wrong. Since it is somewhat unlikely that I'll find the time to do that,
I just disabled MTD_NAND_OMAP2 in my qemu tests instead. Not an ideal solution,
of course, but the alternative would be to drop the beagle qemu tests entirely.
Long time I haven't looked at qemu code, but IIRC there were no proper
support for the NAND layer (maybe this has changed since then though).
And the R/B pin status emulation is probably much more complicated to
implement than just returning a valid STATUS byte in a generic NAND chip
emulation layer (you have to emulate the GPMC block and all its
external interfaces like the R/B IOs as well as the R/B pin
emulation at the NAND chip emulation level)...
Well enough for it to at least find the NAND chip.
So the qemu "fix" was to return 0x0101 instead of 0x0001 when reading gpmc
register 0x54.
Now I get "INFO: suspicious RCU usage" on reboot, but that is a separate issue.
Thanks a lot for the hints!
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
