dediprog: Set i/o lines with protocol v2+
When adding support for the v2 protocol, we left a FIXME open
instead of setting the i/o lines as before. Looking into the
`dpcmd` source code confirms that the i/o values are now set
in the lower bits of `wValue` of the USB request.
Traces of Dediprog's Windows application with an SF600Plus-G2
show that it first sends a request with `wValue = 0x8001` and
`wIndex = 0x0021` during initialization, then later `wValue =
0x0L09` by default (L being the LED setting).
In a ticket[1], test results showed that setting 0x09 fixes
spurious high-levels on the MISO line with newer SF100 ver-
sions and certain flash chips.
Tests with an SF600Plus-G2 confirmed that the magic 0x9 sets
CS2 and IO2 high. Adapters map IO2 to IO4 of an SF100 inter-
face, which again is expected to be high.
[1] https://ticket.coreboot.org/issues/609
Change-Id: Iba5e113adb607a92802cb93a121987920f507fad
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.sourcearcade.org/c/flashprog/+/349
diff --git a/dediprog.c b/dediprog.c
index 96fb3d5..d77cbfb 100644
--- a/dediprog.c
+++ b/dediprog.c
@@ -278,14 +278,13 @@
* bit 0 == 0: red light is on.
*
* Additionally, the command structure has changed with the "new" protocol.
- *
- * FIXME: take IO pins into account
*/
- int target_leds, ret;
+ int ret;
if (protocol(dp_data) >= PROTOCOL_V2) {
- target_leds = (leds ^ 7) << 8;
- ret = dediprog_write(dp_data->handle, CMD_SET_IO_LED, target_leds, 0, NULL, 0);
+ const unsigned int target_io_leds = (leds ^ 7) << 8 | 0x9;
+ ret = dediprog_write(dp_data->handle, CMD_SET_IO_LED, target_io_leds, 0, NULL, 0);
} else {
+ unsigned int target_leds;
if (dp_data->firmwareversion < FIRMWARE_VERSION(5, 0, 0)) {
target_leds = ((leds & LED_ERROR) >> 2) | ((leds & LED_PASS) << 2);
} else {