Hi, I am Hatim Kanchwala (hatim on IRC) from India. I am the GSoC student working with flashrom this year. Stefan Tauner (stefanct) and David Hendricks (dhendrix) will be mentoring me this summer (thanks a lot for the opportunity). The pre-midterm phase of my project comprises three sub-projects – multiple status registers, block protection and OTP support. Each of these projects deals with SPI flashchips.
As of writing this post, flashrom supports around 300 SPI flashchips. Around 10% of these chips have multiple status registers – most have two but there is one with three. Almost all of these chips have some sort of block protection in place. Around 40% of these chips have some sort of OTP or security registers. A combination of BP (Block Protect, first status register) and SRP bits (usually first, but sometimes second status register as well) in the status register determine the range and type of protection in effect. A few chips have a TB bit (Top/Bottom) in addition to BP bits. Some chips also use a CMP bit (Complement Protect, second or third status register) to add more flexibility to range of protection available. A few exotic chips have a WPS bit (Write Protect Scheme, second or third status register) that define which scheme of access protection is in effect. Chips with security registers have corresponding LB bits (Lock Bits, second status register) which are one-time programmable and, when set, render the corresponding security register read-only. Chips with a separate OTP sector(s) have opcodes to enter/exit OTP mode and, within this mode, the usual read, page program and sector erase opcodes can be used.
Previously, flashrom could only read/write the first status register. For writes, all block protect bits were unset (this configuration corresponds to block protection), if the type of protection allowed it. Once unset, flashrom couldn’t revert the BP bit configuration. The ChromiumOS fork of flashrom has some support for locking/unlocking block access protection in place. A lot of the work is done around the Winbond chips, but they are moving towards generalising it. For chips with OTP support, flashrom simply printed a warning, and there was no differentiation between the several OTP models.
In these two weeks I sifted through around 5-6 dozen datasheets and developed models for multiple status registers, block protection and OTP/security registers. I discussed with mentors and the community over mailing list the infrastructural changes arising out of implementing these models and, the use cases corresponding to the models. To substantiate these ideas, I wrote separate prototype code. In the process, Stefan introduced me to a powerful tool, Coccinelle. This tool will make applying changes to the monstrously large struct flashchips easier while being safe. As a byproduct of studying existing flashrom infrastructure, I had the opportunity to explore the history of flashrom through git log. I read how and when flashrom evolved from its humble beginnings in coreboot/util to flash_and_burn to flash_rom to finally flashrom today!
My broad targets for the coming week(s) will be to finish up with the pending half a dozen or so datasheets, polish the models and start transforming the prototype code into merge-worthy code. Following the infrastructure changes, I will update existing chips to make use of the new infrastructure, add support for a bunch of new chips and finally test on actual hardware.
Thanks. See you later!