[flashrom] Broken OPMENUs

[Carl-Daniel Hailfinger]

Am 08.08.2013 16:03 schrieb Stefan Tauner:
> We could get this to work eventually today:
> http://paste.flashrom.org/view.php?id=1747
>
> But coincidentally this was the second occurrence of a very broken
> OPMENU in a just a few days and I like to evaluate our options here.
>
> There are two problems with board above. The first one is the
> configuration of the OPMENU register which specifies the RDID probe
> command to be opcode + address bytes although RDID does not require an
> address (and flashrom naturally does not send dummy bytes by default):
>         OP        Type      Pre-OP
> op[0]: 0x9f, read  w/  addr, none
>
> I could fix this with an ugly hack that is not mergeable as is and is
> not easy to refine to something beautiful either I think: I have
> enlarged the write buffer of the RDID command to 4 Bytes and use its
> content as dummy bytes for the address the chipset wanted. Together with
> my check_trans patch we may be able to design something generic that is
> somewhat sane and mergeable. Alternatively we could handle some of the
> problems inside ichspi.c by rewriting the read and write arrays: if we
> want to write 1, 2 or 3 bytes we just need to create a new buffer and
> copy the contents over. We "just" need to make sure the flash chip
> happily ignores the (well chosen) dummy bytes and the read back values
> get repeated in the right rhythm... the more I think about it the less
> probable a mergeable solution seems possible, it rather worked for RDID
> just by accident and not many other opcodes would work. :/

Yes. It doesn't even work reliably for RDID, you were just lucky that
the given chip had repeating RDID output.


> The second problem with the board is related to the above. AAI on
> ichspi does not work as can be seen here:
> http://paste.flashrom.org/view.php?id=1746
> After fixing the probing we ran into the problem that AAI transactions
> are not compatible with the current state of flashrom.

Not quite. AAI transactions are fundamentally incompatible with a locked
down OPMENU on ICH. With some care, AAI transactions might work on
unlocked ICH. AFAICS all other SPI masters can cope with AAI just fine
(not sure if wbsio_spi can cope).


> I need to look
> into this (and AAI) in more detail, but my guess is that a similar
> approach as outlined above could solve this too...

Allocating a new buffer isn't going to cut it here. AAI is special in
that it only needs an address for the first AAI command, but not for
subsequent commands. This means the ICH "design" of classifying opcodes
into with-address and without-address is a mismatch. The classification
needs to be done per-command-execution instead of per-opcode. You can
hack around this by adding special rules for some opcodes (e.g. AAI)
depending on their writecount, but the already complicated ICH SPI code
isn't going to be easier to read afterwards.
There also is another problem for AAI on chipsets with a restricted
opcode list and/or broken opcode readcnt/writecnt settings: You have to
check for the availability (and corrent readcnt/writecnt) of WRDI before
you start AAI or you may not be able to exit AAI mode. We don't check
for that at all right now. This would be the prime example of a use case
for a command submission test function.

Regards,
Carl-Daniel

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