[flashrom] [Patch] RFC: Set status register option

[David Hendricks]

Thanks for the quick response!

On Thu, May 13, 2010 at 2:25 PM, Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2006 at gmx.net> wrote:

> On 13.05.2010 22:38, David Hendricks wrote:
> > I'd like to know what people's thoughts are on setting the status
> register
> > for SPI flash memories using Flashrom. It seems like a good fit for
> Flashrom
> > and would go a long way in helping OEMs/ODMs migrate away from crappy DOS
> > utilities to using Flashrom for mass production. I've attached a very
> lame
> > patch that adds a command-line option (-s or --set-status) to do this for
> > SPI chips.
> >
>
> Interesting idea, but the integration into overall flashrom architecture
> needs to be discussed further, considering both the internal code
> interface as well as the user interface. Those interface problems are
> related, but need to be solved independently to ensure one interface
> doesn't enforce a suboptimal design of the other interface.
>

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.

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.

On Thu, May 13, 2010 at 2:25 PM, Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2006 at gmx.net> wrote:

> You mentioned OEMs/ODMs. Could you elaborate on the exact use cases for
> this? A user interface needs to be usable and at least somewhat
> future-proof.
>

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.

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.

To get a little more details, the usage case I have in mind is something
like:
1) Run "flashrom" with no args and scrape output to obtain chip info.
2) Generate desired status register value based on the chip info.
3) Feed desired status reg. value into Flashrom.

Steps 1) and 2) are optional depending on how many possible combinations of
flash chip the manufacturer wants to support.

On Thu, May 13, 2010 at 2:25 PM, Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2006 at gmx.net> wrote:

> If this is only about flash protection, an interface to set protection
> regions would be in order. That interface would provide the needed
> abstraction to handle non-SPI flash as well, and odd SPI flash with
> extra protection registers. We were already discussing an internal
> interface for this in the past, but the problem is fundamentally hard,
> and so we settled for a simple unlock-all function until we have the
> details sorted out. The user interface part hasn't even been started
> yet. Vendor input on the user interface design is really appreciated.
>
> However, if this SPI status register stuff is about more than just write
> protection, we ought to make sure we don't mix the interfaces for stuff
> that is conceptually independent but happens to be implemented in the
> same register. For example, some SPI chips support changing sector sizes
> by changing the status register. Others control AAI programming with
> that register.
>

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.

-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.flashrom.org/pipermail/flashrom/attachments/20100513/a4d6ae3c/attachment.html>