On Thu, May 13, 2010 at 2:25 PM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006@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.
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.
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.