'[coreboot] New on blogs.coreboot.org: [GSoC] Multiple status registers, block protection and OTP sup'

[prev in list] [next in list] [prev in thread] [next in thread] 

List: linuxbios
Subject: [coreboot] New on blogs.coreboot.org: [GSoC] Multiple status registers, block protection and OTP sup
From: WordPress <wordpress () blogs ! coreboot ! org>
Date: 2016-06-22 14:59:04
Message-ID: 22a67e97928d335f1675bffe6b7f1472 () blogs ! coreboot ! org
[Download RAW message or body]

[Attachment #2 (text/html)]

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/

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. 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. 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. 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 \
&#8220;grand&#8221; 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. 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. 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. Thanks for your time. In case you have any feedback, I&#8217;d \
love to hear. See you later!

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[prev in list] [next in list] [prev in thread] [next in thread] 