On Sun, 18 Jan 2015 20:01:30 +0300 "Boris Baykov" dev@borisbaykov.com wrote:
I see two major problems with it though. First of all the divisor
problem has
to be investigated. I presume you have only tested with a single hardware setup, right? I'd like to see results from different dongles/setups...
and/or
conclusive theory why the problems happens at higher frequencies.
This is not exactly right. I've really tested it with a single hardware, however this hardware is a laptop and I tried to switch it to very Low-Power mode and run several videos simultaniously with Linux VM that is used to run flashrom. In the low-power mode with CPU freq 800 instead of 3200 I see no difference with SPI freq. It's still working excellent with 5 MHz on FTDI. So, I suppose that it's not an issue with CPU performance. I'll move this VM to another PCs soon and will check this patch there. Now I see the following, Flashrom is working correct all times on 5 MHz but on 6 MHz and higher on EVERY try I see many wrong bytes with FF or 00 in output file after read. I agree with your thought that this situation should be further investigated.
I was referring to the other part of the hardware setup: the dongle, the wiring to the chip and the flash chip itself. Testing different setups would hopefully give us more insight into what's the real problem. There must be something odd going on... because in general it should work AFAIK.
The other thing is the incompatibility of the chunk size... yes, a majority of chips support this, but flashrom prioritizes other things: stability and compatibility. I don't care for the slowness if that's the price for it to work universally with all chips in the wild.
I understand this too. I see and appreciate that you're thinking about stability and reliability. However it's not difficult to add max_read_chunk param to flashchips chips definitions. Also this data could be got by SFDP probably. So, there is no real issue to support 64k read with enough stability.
Not in general, no, it is certainly possible to support it correctly. Just not with this quick hack.
In serprog.c we already have 64k supported for all chips. I've added same support to ft2232_spi.c With this thing I can't see big issues comparing to unknown SPI freq problems above. 10 times speed gain isn't a bad thing ;-) So, imho, it's a good challenge to solve these small troubles and apply the patch at the end of investigation and development.
The loop in serprog is a bug not a feature. I have just not removed it because serprog is not used much by people not aware of the problem (or to be more precise... not by many people at all :) I certainly want to fix this in the future but not in the near future.