Attention is currently required from: Angel Pons, Peter Farley. Nico Huber has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/63798 )
Change subject: ft2232_spi: Reduce read size for FT232H ......................................................................
Patch Set 1:
(1 comment)
Commit Message:
https://review.coreboot.org/c/flashrom/+/63798/comment/4fd25814_75c11597 PS1, Line 9: FT232H-based devices are unable to read over 256 bytes of flash in one Heh, didn't know Wireshark speaks FTDI/MPSSE :D
I'm also not an expert, but AFAICS the captures look good until the failure (Frame 90). And there seems to be no error cause reported, only the return value -ENOENT, which libusb often comments as "cancelled". I'm not familiar enough with Linux' USB stack to say this for sure, but it seems this is not a hardware failure.
One more general thought: Is there any other software running that might try to access the FT232H device? any kernel driver or anything using libusb should not cause any trouble, but who knows...
Even with the limited error information in the capture, there's something to see: The first 64K block was read successfully. For the second block, it received exactly 4*4096B or 32 packets (some of it is FTDI protocol so it's not aligned to any flash blocks). What would be interesting is if it always stops at that point or if always on a 4096B boundary. I guess it would suffice to re-run the capture and check if/how the number of frames changes. The 4096B these URBs request are probably the default read chunk size of libftdi. So lowering this (maybe to an odd multiple of 512, e.g. 1536) to see if it still fails after a full chunk might be interesting as well. If it does it would further increase my suspicion that it's a soft- ware issue.
Decreasing the read chunk size below 512 (if I have not also decreased the max_data_read) causes a segfault when writing to the output file. (I assume it's trying to read beyond the buffer size, but I haven't looked too deeply into it.)
The final buffer is independent from the read size, hmmm. This sounds more like a bug causing undefined behavior that is only visible much later. I wonder why libusb doesn't complain already (for me it did with an overflow error). It seems unrelated but if you want to investigate this further, please show the patch for your changes.
-
Nico Huber (Code Review)