qemu-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-discuss] Moving backend file position of MTD when reading from the


From: Sydpy
Subject: [Qemu-discuss] Moving backend file position of MTD when reading from them
Date: Tue, 17 Sep 2019 07:34:42 +0000

Hi !

I'm trying to use a SPI-NOR with an ARM machine but QEMU seems to act strangely 
with such a device.

So I have a raw image of the content of my SPI-NOR :

```bash
    $ 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:

```bash
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 :

```bash
/ # dmesg
...
[    3.680073] Creating 1 MTD partitions on "spi0.0":
[    3.681949] 0x000000000000-0x000000001000 : "somedata"
...
```

Great ! Now the strange part (still in the guest) :

```bash
$ 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) :
```bash
$ 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 and how can I fix this ?

Thanks in advance !

reply via email to

[Prev in Thread] Current Thread [Next in Thread]