# 27th June 2024, 6:00-7:00 UTC+0
https://ticket.coreboot.org/issues/542 https://ticket.coreboot.org/issues/543 https://ticket.coreboot.org/issues/545
Attendees: Joursoir, Anastasia
## Agenda
* As the time goes, chip vendors are producing newer models, which sometimes re-use model IDs of old versions. Old versions are considered as "end of life", and replaced with newer models with more features. However flashchips.c accumulates everything and with time we get more and more duplicate model IDs. This makes adding new models harder, but also increases the chance users need to manually specify the chip model.
Question: How can we avoid old chip models dragging down adding new ones, without completely removing them from the database (some users might still be using end-of-life chips)?
* probably wasn't an issue 20 years ago when flashchips.c was designed, but now it is * have a flag "end of life" for chip definition? by default, given multiple definitions of the same model ID, the definition without a flag be selected? * vendors adding new model can mark old one end-of-life, in the same patch * [joursoir] It doesn't bother me. maybe it's not a big problem? but just having a flag "end-of-life" for information might be useful * need to be a good clear name, because flashrom still supports everything! * separate file flashchips_legacy.c for old chips? * bad: moving definitions from one file to another is pita * CONCLUSION: maybe we can add a flag to flashchip struct and no changes to probing logic yet. * ticket: [https://ticket.coreboot.org/issues/542%5D(https://ticket.coreboot.org/issues...)
* non-SPI chips are rarely used, and need special treatment in many places in the code. The code for non-SPI (flashchips definitions, parallel programmers, pieces of core logic) hasn't been updated or maintained for many years, So there are no new chips added or new features to the programmers. * maybe we can create a separate repo "flashrom-non-spi" with all the code. it will probably have 1 commit a year, or even less. The rest of code (SPI and PROG) will be simplified, better tested and can add new modern features * it will be too confusing for users, they might not know what they have, SPI or not * two binaries is confusing too * CONCLUSION: this idea is too wild, don't do this
* [joursoir] It would be nice to have a pretty table of supported chips (like we had on the old wiki) on our website. Right now, there's flashrom option that prints chips in html format, however we need to rewrite it to rst so sphinx can use it. are there any pitfalls? * we can do 2-step process: one step generates .rst file (logic can be based on print.c), second step is normal build with documentation, and sphinx will generate html file for the website. * we can generate and publish html page with supported devices for the latest release. * developers who are interested what is supported at head, can look into source code or run `flashrom -L` . no need to generate html between releases. * [joursoir] I will do it! * ticket: [https://ticket.coreboot.org/issues/543%5D(https://ticket.coreboot.org/issues...)
* How about, we split our large file flashchips.c into smaller files, per manufacturer? * seems like a good idea * smaller files can get different maintainers per file => easier to get attention to your patch for flashchip * less merge conflicts * easier to find chips, easier to maintain * for example,
const struct flashchip flashchips[] = { #include "chips/gigadevice.inc" #include "chips/macronix.inc" #include "chips/winbond.inc" }
.inc is not valid c file, just a piece of code (slice array)
another idea can be array of .c files
* ticket: [https://ticket.coreboot.org/issues/545%5D(https://ticket.coreboot.org/issues...)