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...