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. :/
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. 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...
I forgot to attach the patch that actually worked on the board. Here it is.
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
-
Carl-Daniel Hailfinger -
Stefan Tauner