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

[Carl-Daniel Hailfinger]

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.

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.

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.

As such, I'd like to postpone merging this patch until we know enough
about the problem to make enlightened decisions.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/