You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
testing with buspirate firmware at commit 4bd112bfefbc6ec07e56b944bd2753801ffb558e, trying to program a winbond 32Mb flash chip.
The flashrom utility hangs when sending this command sequence to the buspirate:
0x4 0x0 0x1 0x0 0x0 0x6
This is a buspirate read/write command writing a single byte to the chip over the spi bus, specifically the write enable command (0x6). buspirate_sendrecv indicates we are writing 6 bytes and receiving 1 (which is more than is the command string due to the +1 in the call made from buspirate_spi_send_command_v2 in flashrom
I think I know whats going on, but was hoping someone else could take a closer look.
Flashrom sends the above command string to indicate that the spi bus should send back 0 bytes to the buspirate, but it adds one to the receive count because it expects the bus pirate to send back a success/failure code (0 or 1), in flashrom, this addition of a single byte to read outside the command string, causes it to sit on a read call for the serial port
meanwhile in the latest buspirate firmware, in spi_read_write_io, we fetch the bytes_to_read from the command string (which is 0). As such, at the bottom of this function, we have this code:
if (bytes_to_read > 0) {
spi_read_to_uart(bytes_to_read);
}
so spi_read_write_io is expecting the status byte to be included in the read count, whereas buspirate_spi_send_command_v2 is not.
I think the right solution is to modify buspirate_spi_send_command_v2 so that readcnt is incremented in the command strings to include the status byte, which triggers the latest buspirate firmware to send said status byte, but I wanted to check here first, as I wasn't sure if there were any other repercussions to making that change.
The text was updated successfully, but these errors were encountered:
I've moved away from this, but FWIW, modifying buspirate_spi_send_command_v2 as I described above got me working again. Just wasn't sure if it was the right fix or not
testing with buspirate firmware at commit 4bd112bfefbc6ec07e56b944bd2753801ffb558e, trying to program a winbond 32Mb flash chip.
The flashrom utility hangs when sending this command sequence to the buspirate:
0x4 0x0 0x1 0x0 0x0 0x6
This is a buspirate read/write command writing a single byte to the chip over the spi bus, specifically the write enable command (0x6). buspirate_sendrecv indicates we are writing 6 bytes and receiving 1 (which is more than is the command string due to the +1 in the call made from buspirate_spi_send_command_v2 in flashrom
I think I know whats going on, but was hoping someone else could take a closer look.
Flashrom sends the above command string to indicate that the spi bus should send back 0 bytes to the buspirate, but it adds one to the receive count because it expects the bus pirate to send back a success/failure code (0 or 1), in flashrom, this addition of a single byte to read outside the command string, causes it to sit on a read call for the serial port
meanwhile in the latest buspirate firmware, in spi_read_write_io, we fetch the bytes_to_read from the command string (which is 0). As such, at the bottom of this function, we have this code:
if (bytes_to_read > 0) {
spi_read_to_uart(bytes_to_read);
}
so spi_read_write_io is expecting the status byte to be included in the read count, whereas buspirate_spi_send_command_v2 is not.
I think the right solution is to modify buspirate_spi_send_command_v2 so that readcnt is incremented in the command strings to include the status byte, which triggers the latest buspirate firmware to send said status byte, but I wanted to check here first, as I wasn't sure if there were any other repercussions to making that change.
The text was updated successfully, but these errors were encountered: