Documentation #361
closedFeature #353: Release v1.3
Document realtek_mst_i2c_spi programmer
100%
Description
Man page entry done https://review.coreboot.org/c/flashrom/+/63103
We can also try to add more info for developers, see if code can be commented better?
Specific questions:
1) No probing, starts by toggling a GPIO. Are GPIO settings board specific?
2) Timeout checks seem to have regressed since original commit. Not documented?
3) Changes clock settings, is this board specific?
4) Implements spi_master with special cases in an opcode LUT, doesn't bail out on unknown codes.
5) Falls back on unaligned reads/writes, were these paths tested?
6) Fixups suggest that the original code wasn't properly tested, was it by now?
Updated by Peter Marheine over 2 years ago
No probing, starts by toggling a GPIO. Are GPIO settings board specific?
Probably not board-specific, because chip documentation describes that pin as the SPI write protect.
Changes clock settings, is this board specific?
No, it's controlling on-chip clocks to improve programmer performance. I think they get reset on chip reset (exiting ISP mode).
Falls back on unaligned reads/writes, were these paths tested?
Probably not; I've only ever used it for operating on big chunks of memory at a time.
Fixups suggest that the original code wasn't properly tested, was it by now?
It worked the last time I wanted to use it, but nothing uses this in production so it's not actively tested.
Updated by Anastasia Klimchuk over 2 years ago
An item from discussion:
TODO: update the comment on realtek_mst_i2c_spi_toggle_gpio_88_strap
Updated by Anastasia Klimchuk over 2 years ago
From the discussion: all open question resolved the last one left:
Test the programmer on the device and then we can close the ticket.
Updated by Peter Marheine over 2 years ago
- Status changed from New to Closed
I tested read write and verify successfully on the current version, so all seems well.
Updated by Felix Singer about 2 years ago
- Status changed from Closed to Resolved
Updated by Angel Pons about 2 years ago
Hi, sorry for the late reply. Some thoughts on this:
Peter Marheine wrote in #note-1:
No probing, starts by toggling a GPIO. Are GPIO settings board specific?
Probably not board-specific, because chip documentation describes that pin as the SPI write protect.
OK, if that pin is specifically meant to be used as SPI write protect, it should be safe. If we were to add any new options, a simple "use WP GPIO" option would do. Hard to say if it would be needed, though: Realtek design guides could state that everyone has to use the GPIO for WP, and their programs could make the same assumption.
Changes clock settings, is this board specific?
No, it's controlling on-chip clocks to improve programmer performance. I think they get reset on chip reset (exiting ISP mode).
Could higher clocks cause issues depending on board-specific things like routing? If so, making clock settings configurable would address the problem.
Falls back on unaligned reads/writes, were these paths tested?
Probably not; I've only ever used it for operating on big chunks of memory at a time.
Would be good to test, if possible. Is there a way (for anyone inside/outside Google) to obtain/borrow one of these things for testing?
Fixups suggest that the original code wasn't properly tested, was it by now?
It worked the last time I wanted to use it, but nothing uses this in production so it's not actively tested.
Hmmm, what do you mean with "nothing uses this in production"? Is it dead code, or is it only used in non-production (e.g. manufacturing) environments? It's probably the latter, but the original wording is very confusing...