On 1/14/21 4:08 PM, Bin Meng wrote: > From: Bin Meng <bin.m...@windriver.com> > > The m25p80 model uses s->needed_bytes to indicate how many follow-up > bytes are expected to be received after it receives a command. For > example, depending on the address mode, either 3-byte address or > 4-byte address is needed. > > For fast read family commands, some dummy cycles are required after > sending the address bytes, and the dummy cycles need to be counted > in s->needed_bytes. This is where the mess began. > > As the variable name (needed_bytes) indicates, the unit is in byte. > It is not in bit, or cycle. However for some reason the model has > been using the number of dummy cycles for s->needed_bytes. The right > approach is to convert the number of dummy cycles to bytes based on > the SPI protocol, for example, 6 dummy cycles for the Fast Read Quad > I/O (EBh) should be converted to 3 bytes per the formula (6 * 4 / 8). > > Things get complicated when interacting with different SPI or QSPI > flash controllers. There are major two cases: > > - Dummy bytes prepared by drivers, and wrote to the controller fifo. > For such case, driver will calculate the correct number of dummy > bytes and write them into the tx fifo. Fixing the m25p80 model will > fix flashes working with such controllers. > - Dummy bytes not prepared by drivers. Drivers just tell the hardware > the dummy cycle configuration via some registers, and hardware will > automatically generate dummy cycles for us. Fixing the m25p80 model > is not enough, and we will need to fix the SPI/QSPI models for such > controllers. > > This series fixes the mess in the m25p80 from the flash side first, > followed by fixes to 3 known SPI controller models that fall into > the 2nd case above. > > Please note, I have no way to verify patch 7/8/9 because: > > * There is no public datasheet available for the SoC / SPI controller > * There is no QEMU docs, or details that tell people how to boot either > U-Boot or Linux kernel to verify the functionality
The Linux drivers are available in mainline but these branches are more up to date since not everything is merged : https://github.com/openbmc/linux u-boot : https://github.com/openbmc/u-boot/tree/v2016.07-aspeed-openbmc (ast2400/ast2500) https://github.com/openbmc/u-boot/tree/v2019.04-aspeed-openbmc (ast2600) A quick intro : https://www.qemu.org/docs/master/system/arm/aspeed.html > > These 3 patches are very likely to be wrong. Hence I would like to ask > help from the original author who wrote these SPI controller models > to help testing, or completely rewrite these 3 patches to fix things. > Thanks! A quick test shows that all Aspeed machines are broken with this patchset. Please try these command lines : wget https://openpower.xyz/job/openbmc-build/lastSuccessfulBuild/distro=ubuntu,label=builder,target=palmetto/artifact/deploy/images/palmetto/flash-palmetto wget https://openpower.xyz/job/openbmc-build/lastSuccessfulBuild/distro=ubuntu,label=builder,target=romulus/artifact/deploy/images/romulus/flash-romulus wget https://openpower.xyz/job/openbmc-build/lastSuccessfulBuild/distro=ubuntu,label=builder,target=witherspoon/artifact/deploy/images/witherspoon/obmc-phosphor-image-witherspoon.ubi.mtd qemu-system-arm -M witherspoon-bmc -nic user -drive file=obmc-phosphor-image-witherspoon.ubi.mtd,format=raw,if=mtd -nographic qemu-system-arm -M romulus-bmc -nic user -drive file=flash-romulus,format=raw,if=mtd -nographic qemu-system-arm -M palmetto-bmc -nic user -drive file=flash-palmetto,format=raw,if=mtd -nographic The Aspeed SMC model has traces to help you in the task. Thanks, C. > Patch 6 is unvalidated with QEMU, mainly because there is no doc to > tell people how to boot anything to test. But I have some confidence > based on my read of the ZynqMP manual, as well as some experimental > testing on a real ZCU102 board. > > Other flash patches can be tested with the SiFive SPI series: > http://patchwork.ozlabs.org/project/qemu-devel/list/?series=222391 > > Cherry-pick patch 16 and 17 from the series above, and switch to > different flash model to test with the following command: > > $ qemu-system-riscv64 -nographic -M sifive_u -m 2G -smp 5 -kernel u-boot > > I've picked up two for testing: > > QEMU flash: "sst25vf032b" > > U-Boot 2020.10 (Jan 14 2021 - 21:55:59 +0800) > > CPU: rv64imafdcsu > Model: SiFive HiFive Unleashed A00 > DRAM: 2 GiB > MMC: > Loading Environment from SPIFlash... SF: Detected sst25vf032b with page > size 256 Bytes, erase size 4 KiB, total 4 MiB > *** Warning - bad CRC, using default environment > > In: serial@10010000 > Out: serial@10010000 > Err: serial@10010000 > Net: failed to get gemgxl_reset reset > > Warning: ethernet@10090000 MAC addresses don't match: > Address in DT is 52:54:00:12:34:56 > Address in environment is 70:b3:d5:92:f0:01 > eth0: ethernet@10090000 > Hit any key to stop autoboot: 0 > => sf probe > SF: Detected sst25vf032b with page size 256 Bytes, erase size 4 KiB, > total 4 MiB > => sf test 1ff000 1000 > SPI flash test: > 0 erase: 0 ticks, 4096000 KiB/s 32768.000 Mbps > 1 check: 10 ticks, 400 KiB/s 3.200 Mbps > 2 write: 170 ticks, 23 KiB/s 0.184 Mbps > 3 read: 9 ticks, 444 KiB/s 3.552 Mbps > Test passed > 0 erase: 0 ticks, 4096000 KiB/s 32768.000 Mbps > 1 check: 10 ticks, 400 KiB/s 3.200 Mbps > 2 write: 170 ticks, 23 KiB/s 0.184 Mbps > 3 read: 9 ticks, 444 KiB/s 3.552 Mbps > > QEMU flash: "mx66u51235f" > > U-Boot 2020.10 (Jan 14 2021 - 21:55:59 +0800) > > CPU: rv64imafdcsu > Model: SiFive HiFive Unleashed A00 > DRAM: 2 GiB > MMC: > Loading Environment from SPIFlash... SF: Detected mx66u51235f with page > size 256 Bytes, erase size 4 KiB, total 64 MiB > *** Warning - bad CRC, using default environment > > In: serial@10010000 > Out: serial@10010000 > Err: serial@10010000 > Net: failed to get gemgxl_reset reset > > Warning: ethernet@10090000 MAC addresses don't match: > Address in DT is 52:54:00:12:34:56 > Address in environment is 70:b3:d5:92:f0:01 > eth0: ethernet@10090000 > Hit any key to stop autoboot: 0 > => sf probe > SF: Detected mx66u51235f with page size 256 Bytes, erase size 4 KiB, total > 64 MiB > => sf test 0 8000 > SPI flash test: > 0 erase: 1 ticks, 32000 KiB/s 256.000 Mbps > 1 check: 80 ticks, 400 KiB/s 3.200 Mbps > 2 write: 83 ticks, 385 KiB/s 3.080 Mbps > 3 read: 79 ticks, 405 KiB/s 3.240 Mbps > Test passed > 0 erase: 1 ticks, 32000 KiB/s 256.000 Mbps > 1 check: 80 ticks, 400 KiB/s 3.200 Mbps > 2 write: 83 ticks, 385 KiB/s 3.080 Mbps > 3 read: 79 ticks, 405 KiB/s 3.240 Mbps > > I am sure there will be bugs, and I have not tested all flashes affected. > But I want to send out this series for an early discussion and comments. > I will continue my testing. > > > Bin Meng (9): > hw/block: m25p80: Fix the number of dummy bytes needed for Windbond > flashes > hw/block: m25p80: Fix the number of dummy bytes needed for > Numonyx/Micron flashes > hw/block: m25p80: Fix the number of dummy bytes needed for Macronix > flashes > hw/block: m25p80: Fix the number of dummy bytes needed for Spansion > flashes > hw/block: m25p80: Support fast read for SST flashes > hw/ssi: xilinx_spips: Fix generic fifo dummy cycle handling > Revert "aspeed/smc: Fix number of dummy cycles for FAST_READ_4 > command" > Revert "aspeed/smc: snoop SPI transfers to fake dummy cycles" > hw/ssi: npcm7xx_fiu: Correct the dummy cycle emulation logic > > include/hw/ssi/aspeed_smc.h | 3 - > hw/block/m25p80.c | 153 ++++++++++++++++++++++++++++-------- > hw/ssi/aspeed_smc.c | 116 +-------------------------- > hw/ssi/npcm7xx_fiu.c | 8 +- > hw/ssi/xilinx_spips.c | 29 ++++++- > 5 files changed, 153 insertions(+), 156 deletions(-) >
