Block device read operation misses one byte(8 bit) per chip per SPI transaction
m1shaikh opened this issue · comments
Description
Block device Micron m25qu02gcbb (hw/block/m25p80.c) is emulated by the two -drive files. For block device read operation, device driver from Windriver vxWorks issues SPI commands. For read SPI command( 0x6b ) from device driver, there is a data length to be read is specified. For each SPI command call, m25p80_transfer8(SSISlave *ss, uint32_t tx) from hw/block/m25p80.c is called and read byte is returned to guest OS. It is observed that for more than one sequential SPI read commands, first byte from the next read block is not returned back to guest OS. Traces within m25p80.c shows that all the data bytes are read however, first byte from the next read block is missing at guest OS.
drive file content: 0x0 0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x8 SPI read command is set to read 4 bytes in one transaction, two transactions are needed from guest OS to read the entire data. trace_m25p80_read_byte() shows that all bytes are read at m25p80_transfer8() call. At guest OS following is received: 0x0 0x1 0x2 0x3 0x5 0x6 0x7 0x8 (Missing first byte of the second transaction, 0x4)
Windriver is a proprietary OS so I can't attach the .bin files. However, any other guest OS should be able to demostrate this behavior. guest OS device driver is reading without errors on an actual Micron QSPI device.
Host environment
Operating system: RHEL7
OS/kernel version: Linux 3.10.0-1160.92.1.el7.x86_64
Architecture: x86
QEMU flavor: qemu-system-aarch64
QEMU version: 5.0.50
QEMU command line: ./qemu-system-aarch64 -M arm-generic-fdt -drive file=qspi_high.bin,if=mtd,format=raw,index=3 -drive file=qspi_low.bin,if=mtd,format=raw,index=0 -boot mode=2
Emulated/Virtualized environment
- Operating system: Windriver vxWorks
- OS/kernel version: 7
- Architecture: ARM
Hi @m1shaikh ,
We have tested the model with plm, u-boot and Linux. Which didn't show above issue.
Can you test the use case over u-boot ?
Also, can you mention which qemu dtb are you using for emulation here?
Did you have more than one Read SPI transaction requests coming in? The issue is only seen if there is more than one SPI transaction for read request.
From code inspection at m25p80_transfer8() of hw/block/m25p80.c, once the state machine is in STATE_READ state, there is no transition to accept new command coming in. This has two effects, first, once the state machine is in STATE_READ state it stays in there indefinitely and second, for the second READ command, first read byte is not returned, resulting in missing byte.
@m1shaikh In case of a dual parallel configuration, both flashes get read command.
It would be helpful in debug, if you mention your complete command line,and which dtb are you using here.