[PATCH dev-5.0 0/4] spi-nor: aspeed: add support for the 4B opcodes

[Cédric Le Goater]

On 4/19/19 12:41 AM, Milton Miller II wrote:
> About  04/17/2019 08:55AM in some timezone, Cédric Le Goater wrote:
> 
> 
>>Here is a little series providing cleanups on the Aspeed SMC
>>Controller
>>driver and adding support for the 4B opcodes which were recently
>>added
>>to the Linux kernels 5.0.x.
>>
>>The use of the 4B opcodes was breaking the read of the golden buffer
>>done at slow speed in the optimization read sequence. The code
>>assumed
>>that the chip was in 4B address mode, as if a EN4B opcode had been
>>sent, but this is not the case anymore with 4B opcodes. The golden
>>buffer is now read with a SPINOR_OP_READ_4B (0x13) when the chip
>>supports 4B opcodes.
>>
>>It should fix accesses to the palmetto PNOR and the Witherspoon BMC
>>flash modules.
>>
>>
>>*Please test !*
> 
> 
> Cedric,
> 
> did you notice that spi_nor_read_sfdp is now calling the nor->read method?

yes. 

> Since the read method is hard-coding the opcode, this means that we are
> returning random flash contents instead of the flash parameter block, which
> probably confuses the kernel.

I see your point. but, at the time of the sfdp read, the controller settings 
are very basic :

  [    7.537426] aspeed-smc 1e630000.spi: default control register: 00000300

and the sfdp values are fine. 

Here is what we get for sfdp on a palmetto PNOR "mx25l25635e" :

  w5:fffffffe w6:ff00ffff w7:eb44ffff w8:520f200c w9:ff00d810 w10:00000000

This looks consistent with the mx25l25635f specs and with the test being
done in Linux in mx25l25635_post_bfpt_fixups().


This driver needs a rewrite because the SPI-NOR layer has been changing 
a lot. I have started a new one on top of spi-mem but the core layer 
misses support for link training. So this is still work in progress.
Help welcomed. The initial target should be *mainline*.


Also,


If someone had some time to model SFDP in QEMU, it would really help. 
We would have caught this regression earlier. 

One way to reproduce the problem in QEMU is to force 4B opcode in Linux 
but that's only useful when one knows about the problem already. useful 
to work on the fix but not to track regressions.


Thanks,


C. 


> 
> milton
> 
>