<div class="gmail_quote">Thanks for the quick response!</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Thu, May 13, 2010 at 2:25 PM, Carl-Daniel Hailfinger <span dir="ltr"><<a href="mailto:c-d.hailfinger.devel.2006@gmx.net" target="_blank">c-d.hailfinger.devel.2006@gmx.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 13.05.2010 22:38, David Hendricks wrote:<br>
> I'd like to know what people's thoughts are on setting the status register<br>
> for SPI flash memories using Flashrom. It seems like a good fit for Flashrom<br>
> and would go a long way in helping OEMs/ODMs migrate away from crappy DOS<br>
> utilities to using Flashrom for mass production. I've attached a very lame<br>
> patch that adds a command-line option (-s or --set-status) to do this for<br>
> SPI chips.<br>
><br>
<br>
</div>Interesting idea, but the integration into overall flashrom architecture<br>
needs to be discussed further, considering both the internal code<br>
interface as well as the user interface. Those interface problems are<br>
related, but need to be solved independently to ensure one interface<br>
doesn't enforce a suboptimal design of the other interface.<br></blockquote><div><br></div><div>Definitely, that's the whole point of the RFC after all :-) I definitely share a desire to avoid suboptimal interface design, but would also really, really like to use Flashrom's internals.</div>
<div><br></div><div>Maybe we could make a separate utility for this task and bundle it with Flashrom? Basically the utility would be a copy of flashrom.c, but gutted to only serve a few very specific tasks. Think of it as Flashrom for manufacturing rather than Flashrom for everyday development.</div>
<div><br></div><div>On Thu, May 13, 2010 at 2:25 PM, Carl-Daniel Hailfinger <span dir="ltr"><<a href="mailto:c-d.hailfinger.devel.2006@gmx.net" target="_blank">c-d.hailfinger.devel.2006@gmx.net</a>></span> wrote: </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You mentioned OEMs/ODMs. Could you elaborate on the exact use cases for<br>
this? A user interface needs to be usable and at least somewhat<br>
future-proof.<br></blockquote><div><br></div><div>At some point early in manufacturing processes, non-volatile memory/memories get set to desired values. The status register on SPI flash chips is one of many examples. Flashrom could easily handle both setting of the status reg and imaging of the production firmware image, which could make people very happy.</div>
<div><br></div><div>In any case the user-interface does not need to be particularly friendly. Flashrom could just a very abstraction layer for chip and host chipset details. Feeding raw values into Flashrom to set the value of these registers is perfectly fine.</div>
<div><br></div><div>To get a little more details, the usage case I have in mind is something like:</div><div>1) Run "flashrom" with no args and scrape output to obtain chip info.</div><div>2) Generate desired status register value based on the chip info.</div>
<div>3) Feed desired status reg. value into Flashrom.</div><div><br></div><div>Steps 1) and 2) are optional depending on how many possible combinations of flash chip the manufacturer wants to support.</div><div><br></div>
<div>On Thu, May 13, 2010 at 2:25 PM, Carl-Daniel Hailfinger <span dir="ltr"><<a href="mailto:c-d.hailfinger.devel.2006@gmx.net" target="_blank">c-d.hailfinger.devel.2006@gmx.net</a>></span> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If this is only about flash protection, an interface to set protection<br>
regions would be in order. That interface would provide the needed<br>
abstraction to handle non-SPI flash as well, and odd SPI flash with<br>
extra protection registers. We were already discussing an internal<br>
interface for this in the past, but the problem is fundamentally hard,<br>
and so we settled for a simple unlock-all function until we have the<br>
details sorted out. The user interface part hasn't even been started<br>
yet. Vendor input on the user interface design is really appreciated.<br>
<br>
However, if this SPI status register stuff is about more than just write<br>
protection, we ought to make sure we don't mix the interfaces for stuff<br>
that is conceptually independent but happens to be implemented in the<br>
same register. For example, some SPI chips support changing sector sizes<br>
by changing the status register. Others control AAI programming with<br>
that register.<br></blockquote><div><br></div><div>Yes -- There are many things one might wish to change in the status register and it would be very burdensome to try and present all this stuff in a nice manner. I'd like to keep whatever we come up with stupid simple and keep Flashrom's responsibilities limited to abstracting the host/chip interface from higher-level logic.</div>
<div><br></div></div>-- <br>David Hendricks (dhendrix)<br>Systems Software Engineer, Google Inc.<br>