<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 17, 2016 at 6:32 PM, Hatim Kanchwala <span dir="ltr"><<a href="mailto:hatim@hatimak.me" target="_blank">hatim@hatimak.me</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Regarding block protection scheme, I am very glad to say I have had a breakthrough observation. After having sifted through around 90 datasheets, I was able to spot a pattern that majority of chips follow. GigaDevice and Winbond , along with some AMIC, Eon, Fudan and Macronix chips follow this pattern - around 50 in number. With this pattern, we can now dynamically generate the entire block protection ranges on-the-go. We don't need to hard-code the tables for these chips anymore and presence (or absence) of SEC, TB, or CMP bits is also handles generically! The exact algorithm is slightly convoluted, but I'll try my best to explain it. Feel free to skip past #5, you will have nothing much to lose. For all practical purposes, the BP4 and BP3 bits are identical to SEC and TB bits respectively. We'll call tuple of (BP3, BP2, BP1) as BP, and X is don't care.<br>
1. For BP=(0,0,0):<br>
No protection, SEC=X, TB=X<br>
<br>
2. For BP=(1,1,1):<br>
All protection, SEC=X, TB=X<br>
<br>
3. For (SEC,TB)=(0,0):<br>
We introduce a parameter f, such that f = chip_size(in kB) / 64 for chips_size < 4096 kB; and f = 64 for chips_size >= 4096 kB.<br>
3.1 For chip_size >= 4096 kB, we have the following correspondence of fraction of chip_size with BP:<br>
(0,0,1) - 1/64<br>
(0,1,0) - 1/32<br>
(0,1,1) - 1/16<br>
...<br>
(1,1,0) - 1/2<br>
3.2 For chip_size = 2048 kB, we have the following correspondence of fraction of chip_size with BP:<br>
(0,0,1) - 1/32<br>
(0,1,0) - 1/16<br>
(0,1,1) - 1/8<br>
...<br>
(1,1,0) - 1<br>
3.3 For chip_size = 1024 kB, we have the following correspondence of fraction of chip_size with BP:<br>
(0,0,1) - 1/16<br>
(0,1,0) - 1/8<br>
(0,1,1) - 1/4<br>
...<br>
(1,1,0) - 1<br>
3.4 For chip_size = 512 kB, we have the following correspondence of fraction of chip_size with BP:<br>
(0,0,1) - 1/8<br>
(0,1,0) - 1/4<br>
...<br>
(1,1,0) - 1<br>
3.5 For chip_size = 256 kB, we have the following correspondence of fraction of chip_size with BP:<br>
(0,0,1) - 1/4<br>
(0,1,0) - 1/2<br>
(0,1,1) - 1<br>
(1,0,0) - 0<br>
(1,0,1) - 1/4<br>
(1,1,0) - 1/2<br>
3.6 For chip_size = 128 kB, we have the following correspondence of fraction of chip_size with BP:<br>
(0,0,1) - 1/2<br>
(0,1,0) - 1<br>
(0,1,1) - 1<br>
(1,0,0) - 0<br>
(1,0,1) - 1/2<br>
(1,1,0) - 1<br>
(SEC,TB)=(0,0) represents the upper portion of the chip (which means range addresses always end at top boundary).<br>
E.g. For a 4096 kB chip, (0,1,0) 1/32 means upper 256 kB - 0x3fff00-0x3fffff<br>
<br>
4. For (SEC,TB)=(0,1):<br>
This represents the lower portion of the chip (which means range addresses always start at lower boundary). The same mapping defined earlier for fraction of chip_size holds.<br>
E.g. For a 512 kB chip, (0,1,0) means lower 128 kB - 0x000000-0x01ffff<br>
<br>
5. For (SEC,TB)=(1,X):<br>
(0,0,1) - 4 kB<br>
(0,1,0) - 8 kB<br>
(0,1,1) - 16 kB<br>
(1,0,0) - 32 kB<br>
(1,0,1) - 32 kB<br>
*(1,1,0) - 32 kB<br>
We have upper for TB=0, lower for TB=1<br>
E.g. For a 1024 kB chip TB=1, (1,0,0) means lower 32 kB - 0x000000-0x007fff<br>
*Some chips have 64 kB block instead of 32 kB.<br>
<br>
(You will not lose much if you skip up to here)<br>
<br>
6. For chips with CMP bit:<br>
For all chips that I have seen (and that is well over a 100 SPI chips), the block protection range either starts at lower boundary of chip or ends at upper boundary of chip. So, given the range and size of the chip, we can compute the complement range.<br>
<br>
Please find attached pattern.c. It is an excerpt from the unmerged code I am working on and contains the implementation of the discussed model (cf. sec_block_pattern_range_generic). There are other functions and structs to show the models impact on the infrastructure. IMO, this is an immense improvement from what we have in ChromiumOS fork and what we have been discussing. Here are the key takeaway points -<br>
- Having the status register layout member in struct flashchip is immensely beneficial. A lot of chips can be supported with the generic code, perhaps with only slight adaptation.<br>
- Based on David's suggestion, shifting to function pointers was a good choice - it allows flexibility.<br>
- Presence (or absence) of CMP, TB (BP3), SEC (BP4) bit is automatically taken of, and the corresponding range is also dynamically generated.<br>
- For chips whose ranges cannot be dynamically generated, we have the option of specifying range manually. I think it is best to stick to range for such representation, instead of range of sectors/blocks or portions of chip (as suggested by David in the previous mail). Sticking with range is safe because range is independent of sector/block and will yield the proper result.<br>
- Based on Stefan's suggestion some time ago, having pointers to struct status_register and struct wp will allow greater re-use (which is happening a lot!)<br></blockquote><div><br></div><div>Sounds pretty good so far. Indeed, many chips are very similar in their block protect schema so generating generic tables is a reasonable approach, provided we can override the generic method when an exception to the rule is encountered.</div><div><br></div><div>Most users will probably be satisfied using generated tables, even if chips support more combinations, for example due to "don't care" bits. So I imagine that although the generated tables might not be complete, they should be sufficient. The user needs to run "--wp-list" to know what ranges are supported, and if the generated tables are not adequate then they need to add a table and override it.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
Please have a look at the source file. The output of the source is here (<a href="http://paste.flashrom.org/view.php?id=2940" rel="noreferrer" target="_blank">http://paste.flashrom.org/view.php?id=2940</a>)<br></blockquote><div><br></div><div>Looks a lot better than before!</div><div><br></div><div>A few more suggestions:</div><div><ul><li> You should probably just add a num_ranges member to the wp struct rather than having LEN_RANGES. Large chips tend have many more supported ranges than smaller ones - A 128Mbit chip with 4 BP bits, TB, SEC, and CMP could exceed 100 possible ranges.<br></li><li>I don't see why we want get_cmp() and set_cmp() function pointers in the wp struct. It seems to be handled already after SEC and TB are processed in sec_block_pattern_range_generic()?</li><li>The computation, especially, sec_block_multiples, seems a bit awkward... Or maybe I just need time to study it more. I think it would be more straight-forward to describe this in terms of the minimum granularity (or "density" in some datasheets), for example, 64KB * 2^0 if BP3-0 is 0 0 0 1, 64KB * 2^1 if BP3-0 is 0 0 1 0, etc. So it works out to something like granularity * 2^(bp_val - 1).</li></ul></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Further work -<br>
- In the current implementation, for chips whose range is dynamically generated we have a pointer to the range and an ID variable to associate the range with the chip (this is so that range is computed once and reused for subsequent calls). If we have another chip then the ID and pointer gets overwritten (like is happening in main() in the source). So when we want to return to the previous chip, we have to again spend the computing cost. This can be enhanced if we use list data structures and append newly computed range tables. That way, we can always revisit a previously computed table at a nominal computing cost.<br></blockquote><div><br></div><div>I'm not sure if this is worth the effort, but if it's not too much extra work then perhaps it can be useful. I'm having difficulty thinking of use cases where we'll need a computed table to be used multiple times in a single invocation of flashrom.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
- The computation of BP bitfield from a given range can be enhanced if we factor in CMP bit (if present) - there could be a scenario where CMP=0 and the given range is not possible, but if CMP=1 the range could be possible.<br></blockquote><div><br></div><div>Yep.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
- Another way we could enhance it is through suggesting nearest neighbours to the range. (I find this idea theoretically interesting, but practically I cannot come up with use cases)<br></blockquote><div><br></div><div>Interesting, but as you point out this is probably unnecessary.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I hope you enjoyed going through the source. It took me a while to sift through so many datasheets and try out varying models, but I was elated with joy when the above algorithm was ready. I am looking forward to your feedback and comments on this.<div><div><br>
<br>
Thanks for your time and patience.<br>
<br>
Bye,<br>
Hatim<br>
<br>
</div></div></blockquote></div><br></div></div>