This section allows you to view all Messages made by this member. Note that you can only see Messages made in areas you currently have access to.
Messages - pgeorgi
Runs with 2MHz or less give correct results on "unpatched" 5.7 firmware (I tested that faster reads give wrong results)
The really weird other measurement is that <=2MHz is much faster than >2MHz: (512k read)
Found chip "Winbond W25x40" (512 KB, SPI) at physical address 0xfff80000
I'll do a test with unpatched firmware and 2MHz later tonight.
The result: slow read occasionally returns 0xff where it shouldn't, fast read with the experimental firmware posted by ian gave me a correct image.
However, a new difference to the image I got using the slow read appeared: some 0xff of the slow read are replaced by other values (with no positional pattern I could discern).
Either slow read also has a bug, or the new values are crap. I guess I'll have to send a couple of test images into the chip to figure out what's going on.
I'll try with the test firmware tonight and report back.
A crude workaround might be to read in large chunks and then "fix up" 0xff in the first byte by doing a slow single-byte read ;-)
With bp_chunksize = 1024, I still get corruption at 0x100, 0x300, 0xa00, 0xd00, 0xe00, ...
There goes my theory...
Unfortunately, there's a bug, and it seems that it's in the BP firmware.
The first byte of large transfers is sometimes 0xff instead of the actual value. So far, I could narrow it down with some observations:
- It's always the first byte of a transfer. Other bytes aren't shifted one byte to the right or otherwise invalid, they are just fine
- Block size doesn't matter (256b and 128b transfers were tried)
- It only affects the byte if it's >=0x80 (none of the corrupted bytes was <0x80 originally)
- It doesn't affect all first bytes that are >=0x80 (some came through correctly)
My theory (not knowing the BP firmware code much) is that the BP sometimes stumbles if the first bit is set - maybe some timing issue while reading?
I attach a current flashrom build for win32 with the patch for the new transfer mode (http://patchwork.coreboot.org/patch/1986/) applied.
WARNING: This will read corrupted data!
With 12byte chunks, writing should be quite a bit faster, as overhead is reduced. Any further improvements (there are some ideas, already outlined by biosflasher in this forum) require some changes in the buspirate firmware.
Upload special routines at the beginning, which handle large transfers (ideally we'd need a way to buffer 300 bytes) and allow the buspirate to poll for the chip to become un-busy without having to interact with the host all the time, use those routines to do the flashing, discard on exit.
It is not scheduler dependent The usb does transfer only 64 bytes/ms (-2bytes FTDI status info)
While the packet size is 64bytes, USB is not limited to one packet per frame. Otherwise USB1.x would be limited to 64000 bytes/second (1000 frames with 64b each), whereas it can achieve close to 1MB/second.
Most notable (for Win32 users): It opens files with "rb" or "wb" for read or write, so Windows doesn't try to convert newlines. This is in upstream for quite a while already, but it seems I forgot to post a new binary.
Thanks to Danny Grander who reminded me about this.
just fyi, if you run into such a situation again. I think I'll add specific support for that notation (so COMx will be translated to \.COMx internally) to flashrom.
Thanks for the report with the multidigit COM ports.
It might be a problem in the FTDI Serial driver - at least I had the same issue with another FTDI-based device, with a totally different application.
The parser in flashrom has no assumption on the length of that value. On Linux, the device name is usually much longer.
I wrote a support request to FTDI, after all, it's their driver that seems to misbehave. Let's see if they react.