Missing opcodes in auto-generated Modules.

[enjoy-digital]

The auto-generated modules seem to be missing some opcodes. When switch the different LiteX-Boards targets to LiteSPI, modifications have been made to be able to enable Quad SPI mode on some boards, for ex:

• 9884a7a
• a8babfe

So it seems the script generating the modules is not listing all supported the opcodes.

[enjoy-digital]

While looking at the IS25LP128 case, not sure the Linux kernel code source will be really usable to get the supported opcodes:

https://github.com/torvalds/linux/blob/4a0225c3d208cfa6e4550f2210ffd9114a952a81/drivers/mtd/spi-nor/issi.c#L45-L49

While it's clear the IS25LP128 supports SPI_NOR_QUAD_READ and is very similar to the IS25LP128:

https://www.issi.com/US/product-flash.shtml

So maybe we could find another "database" for the auto-generation of modules or do it manually.

[mithro]

@enjoy-digital - There are currently three sources of the module configuration;
(a) Linux Kernel source
(b) flashrom
(c) Custom local configurations

It should be noted that what a part "claims" to support and what it actually does can be quite different. Linux has pretty wide adoption so is useful for that type of information. flashrom is also popular and hence should be a good source to use.

If the upstream Linux source is wrong, we should fix that to everyone's benefit. We could also have a local override until that change is merged?

[enjoy-digital]

@mithro: I also think it would be nice to contribute the potential issues we can find in Linux/FlashRom (and potentially also contribute missing parts). It's just that when testing current generated modules on LiteX-Boards, I already noticed 2 issues when using ~10-20 SPI Flashes, so this could be useful to have someone closely reviewing the Linux/flashrom sources we are using and contribute fixes (and as you say have the patches in LiteSPI until fixes are accepted).

[tcal-x]

Thanks @enjoy-digital , this was very timely. Joey and I were just puzzling over a mystery. We realized that we had GD25Q16C parts on our Fomus, but we were accidentally using a READ_1_1_4 opcode with that part, which it's not reported to support. But it was working, and was giving better performance than READ_1_1_1.