[flashrom] Ideas for implementing support for 2nd status register

Hatim Kanchwala hatim at hatimak.me
Tue May 24 09:19:51 CEST 2016


The GSoC coding period has started and I have been working on my first 
sub-project, adding support for 2nd status register. Most supported 
chips that have multiple registers (around 80%) have opcode 0x35 for 
reading SR2 and, opcode 0x01 for writing SR2. I have developed 3 models 
and would like to have some feedback on them.

1. Integrate read/write SR2 with existing functions
- Define a feature bit FEATURE_SR2
- spi_read_status_register(), defined in spi25_statusreg.c, additionally 
reads second status register depending on FEATURE_SR2 bit for that flash
- Change return to uint16_t for spi_read_status_register()
- spi_write_status_register_flag(), defined in spi25_statusreg.c, 
considers higher byte of status to write to SR2, depending on 
FEATURE_SR2 bit for that flash.
- Fits in elegantly with existing implementation (IMO). Most code in 
flashrom stores status reads/writes in int, which can easily accommodate 
the 16 bits
- Very little hassle when editing struct flashchip in flashchips.c

- RDSR will take more time - will read SR2 even if not needed

2. Define separate functions to read/write SR2
- Define spi_read_status_register2() to read only SR2
- Define spi_write_status_register2_flag() and 
spi_write_status_register2() to write to SR2. This will read SR1 first, 
then (SR2 << 8 | SR1) will be written using WRSR

- Flexibility (as compared to 1.)

- Need to write more lines (compared to 1.) when dealing with struct 

3. struct status_register_layout
The ChromiumOS fork defines a struct status_register_layout in 
writeprotect.c, which contains only BP and SRP bits' information.
Do a similar flashrom-wide definition, which contains all status 
register bits' information.

- Very detailed representation of information

- Too much work when adding support for new chips
- Overhaul of existing infrastructure

IMHO, the first model is the best among these 3. I would like to know 
what you guys think about these, whether you have some new idea. Looking 
forward to your feedback. Thanks for your time.


More information about the flashrom mailing list