[coreboot] [RFC]flashrom: improve basic design

[FENG Yu Ning]

On Jan 5, 2009, Carl-Daniel Hailfinger wrote:
> thanks for yor design proposal.
Thanks for reading and commenting.

Having thought more, I realized the merit of the original design, and
I also realized what drives me eager to change it.

In the original design, every flash chip model could be specified its
own operation drivers. It is a good design providing mechanism.

However, too much code reuse keeps us from obtaining benefit from the
design. Most SPI flash chips have the same wrapper functions
probe_spi_rdid, spi_chip_write and spi_chip_read as their operation
drivers. Those drivers have to satisfy many flash chip. It is (too)
difficult.

We should limit how much we reuse operation drivers. My opinion is,
for read, erase and write, only the flash chip models in the same
series share drivers, and every model has its own probe driver. Thus,
we will never need IDs or page_size in struct flashchip, and will not
be bothered by related problems, such as grouping probe functions and
IDs, paged write, etc..

There would be code redundancy. We have to choose one to suffer from.

> Unfortunately, other parts of the proposed abstraction level will make
> it harder to understand chip drivers, especially for people who just
> want to contribute support for one of their own chips.

Yes.

Deeper thoughts make me realize that I am defining a
language/code (the specification), and trying to implement a built-in
compiler/virtual_machine (the chipset driver has to be intelligent).
It would be too complex.

> I believe that it is fundamentally wrong to differentiate between
> preopcodes and opcodes.

Agreed.

> I'll probably have to send a patch to kill all this preopcode/opcode stuff.

hmm.. for ICH7 like chipsets, we just cannot send a WREN like other
commands if SPI opmenu is locked.

BTW, do you have some comment on this issue?
http://www.coreboot.org/pipermail/coreboot/2008-December/043704.html

As you have said, it hurts.


yu ning