0
1
I'm trying to use a SPI-NOR with a QEMU ARM machine. A problem I have is that QEMU acts strangely with such a device.
So I have a raw image of the content of my SPI-NOR :
$ hexdump -C dummy-spinor.img
00000000 41 41 41 41 42 42 42 42 43 43 43 43 44 44 44 44 |AAAABBBBCCCCDDDD|
00000010 45 45 45 45 46 46 46 46 47 47 47 47 48 48 48 48 |EEEEFFFFGGGGHHHH|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
01000000
I'm then starting my machine using the following args:
qemu-system-arm \
...
-drive file=dummy-spinor.img,format=raw,id=spinor,if=mtd \
-append "... mtdparts=spi0.0:0x1000(somedata)"
In the guest, I can see that my MTD partition is recognized :
/ # dmesg
...
[ 3.680073] Creating 1 MTD partitions on "spi0.0":
[ 3.681949] 0x000000000000-0x000000001000 : "somedata"
...
Great ! Now the strange part (still in the guest) :
$ dd bs=16 count=1 if=/dev/mtd0 2>/dev/null | hexdump -C
00000000 41 41 41 41 42 42 42 42 43 43 43 43 44 44 44 44 |AAAABBBBCCCCDDDD|
00000010
$ dd bs=16 count=1 if=/dev/mtd0 2>/dev/null | hexdump -C
00000000 46 46 46 46 47 47 47 47 48 48 48 48 00 00 00 00 |FFFFGGGGHHHH....|
00000010
$ dd bs=16 count=1 if=/dev/mtd0 2>/dev/null | hexdump -C
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000010
$ dd bs=16 count=1 if=/dev/mtd0 2>/dev/null | hexdump -C
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000010
As you can see, reads on the MTD partition seem to be moving the file position pointer of the underlying file handle of my raw image. Also, 4 bytes disappeared (the bytes at offset 0x00000010 : EEEE).
Such behavior is not happening on real hardware, nor with other devices. For example, on the QEMU guest, the following command will always start reading at the offset 0 of the device (also bound to a raw file image as a backend) :
$ dd bs=16 count=1 if=/dev/mmcblk2p1 2>/dev/null | hexdump -C
It doesn't seem to depend on the m25p80 device I'm using, I tried several of them. I also tried using the QCOW2 image format, this behavior persists.
So what is happening here ? How do I fix this ?
If that's a limitation of QEMU, I'm willing to patch/recompile it if necessary.