A new post titled "[GSoC] Multiple status registers, block protection and OTP support, week #3 and #4" has been published on the coreboot blog. Find the full post at http://blogs.coreboot.org/blog/2016/06/22/gsoc-multiple-status-registers-block-protection-and-otp-support-week-3-and-4/

<p>The most important accomplishment during these weeks was developing a generic algorithm which would generate the block protect range table for a given flash chip. This algorithm can be applied to a majority of chips.</p>
<p>The previous solution that I had developed was to have range tables stored in a struct and a pointer to it would be in <tt>struct flashchips</tt> for chips that share the range definition. This array of <tt>struct range</tt> would be indexed by block protect (BP) bitfield, so essesntially we could get the protected range for a chip given the bitfield in <tt>O(1)</tt> time. While it looked neat, it was only marginally an improvement over existing solution in ChromiumOS.</p>
<p>I really wanted to try to have a more elegant and robust solution. So after getting back some feedback from my mentor David, I decided to investigated further. I started with around 80 datasheets from AMIC, Eon, GigaDevice, Macronix, Winbond and others with objective to find whether a generic pattern could be observed such that given a chip and its properties can we compute its BP ranges. After a few attempts, I settled on a model that fits all GigaDevice and Winbond chips, and to some AMIC and Eon chips, which together account for around 50% of the chips I investigated. Having the layout of the status register as a member of <tt>struct flashchip</tt> came in very handy. For the algorithm itself and its demo, please have a look at <a href="https://www.flashrom.org/pipermail/flashrom/2016-June/014701.html">this</a> mail in the discussion thread on the mailing list. Once this was in place, I went through another iteration to allow the code to automatically handle presence (or absence) of <tt>SEC/TB/CMP</tt> bits.</p>
<p>One could wonder that since this model generates range tables automatically for only about half of the chips, what about the remaining ones? As I like to put it slightly dramatically, the <em>“grand”</em> design is very flexible. The <tt>struct wp</tt> has function pointers that can be assigned chip specific functions, but if they are unassigned then the code falls back to using the generic functions. Quite a few chips that are not included in the 50% collection above, have ranges that can be computed with slight modification after the generic pattern has been applied, allowing maximum re-use of code. This idea is also part of the mail and demo linked above.</p>
<p>The investigation and subsequent pattern deduction took a fair amount of effort. Although I was very happy with the results, nonetheless they were at a slight tangent to what I had planned. The last week had not been as productive as I would have it. So as it stands, I am slightly amiss from the pre-midterm timeline I had proposed. However, I have taken corrective measures, and will ensure that post-midterm timeline is not affected.</p>
<p>Currently I am finalising the OTP support model. The functionality for reading/writing multiple status registers and block protection are in place. Later this week I will work on CLI to expose this functionality and wire up existing flashrom code to make use of the new infrastructure. Following that, I will be testing the new infrastructure on a few GigaDevice chips that I have. I have also ordered some chips from a few other manufacturers so hopefully they should arrive in time by then.</p>
<p>Thanks for your time. In case you have any feedback, I’d love to hear. See you later!</p>