Possible incorrect byte-order for identity for cy15x104q SPI-FRAM
Joshua Scott
Joshua.Scott at alliedtelesis.co.nz
Thu Oct 17 21:59:55 PDT 2024
Hi,
We are using a 512 KB FRAM chip, the CY15B104Q. (cy15x104q)
It appears that the ID in the spansion_nor_parts array does not match what we're getting from the chip.
The datasheet shows a 9-byte ID: 7f7f7f7f7f7fc22c<xx>, with the last byte varying by package/voltage/temperature range.
Looking at the kernel (currently running 6.6 LTS, but the value appears the same in the latest version), I see:
{ "cy15x104q", INFO6(0x042cc2, 0x7f7f7f, 512 * 1024, 1)
FLAGS(SPI_NOR_NO_ERASE) },
However, the six bytes that are read from our chip are: 0x7f7f7f 0x7f7f7f
Locally, I've added an extra entry to the spansion_nor_parts[] list:
{ "cy15b104q", INFO6(0x7f7f7f, 0x7f7f7f, 512 * 1024, 1)
FLAGS(SPI_NOR_NO_ERASE) },
And with this entry, the chip is detected and functions correctly.
My question is: Does the existing entry in the kernel work for anybody, or is it untested?
(If it does work for somebody, I'd guess it may only work for the low-voltage 'V' version of the chip that's the only one with '04' listed as the final byte in the datasheet)
I see back in 2020 some discussion around the byte order of the identity was made, when the chip was first added to the kernel. However, the conversation seemed to drop off without a conclusion about which was correct.
I'm not sure what the best resolution to this would be.Is there a way to specify an 8-byte identity instead of the 6-byte identity that is currently used? (leaving off the 9th package/voltage/temperature dependent final byte)
Thank you,
Joshua
More information about the linux-mtd
mailing list