Skip to main content

Messages

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

2
Flashrom / Re: Issue with new flashrom transfer mode
Sorry, took me a while longer to do the speed tests:
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)
MHz   time
8   01:31,80
8   01:30,20
8   01:30,60
8   01:30,70

4   02:04,70
4   02:03,80

2,6   02:37,90

2   00:59,80
2   01:00,30

1   01:01,30

0,25   01:13,90
3
Flashrom / Re: Issue with new flashrom transfer mode
The chip in use is (posting flashrom output):
Found chip "Winbond W25x40" (512 KB, SPI) at physical address 0xfff80000

I'll do a test with unpatched firmware and 2MHz later tonight.
4
Flashrom / Re: Issue with new flashrom transfer mode
I managed to validate a file embedded in the firmware that was affected by the corruption. I extracted it (a jpeg file) and looked which version is correct.
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.
5
Flashrom / Re: Issue with new flashrom transfer mode
Tried the timeout firmware. The 0xff values at block starts are gone.
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.
6
Flashrom / Re: Issue with new flashrom transfer mode
Okay, with _real_ 1k transfers, the error only appears in the first byte of each 1k transfer (and only if the original value is >=0x80)
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 ;-)
7
Flashrom / Re: Issue with new flashrom transfer mode
[quote author="biosflasher"]pgeorgi, could you test reading with flashrom bp_chunksize = 1024 instead of 256? In theory, the corruption location should be at a multiple of 1024 bytes with that setting. Please don't try to write with that chunksize on AT45 chips (all other chips are fine).[/quote]
With bp_chunksize = 1024, I still get corruption at 0x100, 0x300, 0xa00, 0xd00, 0xe00, ...

There goes my theory...
8
Flashrom / Issue with new flashrom transfer mode
Thanks for adding the new transfer mode - it greatly speeds up FlashROM: less than 2 minutes for reading 512kbyte of flash, instead of more than 12!

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!
9
Bus Pirate Support / Re: Spi flash ISP support?
Totally untested (not even basic function tests, as I'm still missing some equipment), but this is a modified flashrom that _might_ write in 12byte chunks. patch is included in the zip file.

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.
10
Bus Pirate Development / Re: new branch in the svn (newterm)
Depending on how large the code can be, and how large the variable space is, this might be very useful to flashrom:
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.
11
Bus Pirate Support / Re: Spi flash ISP support?
[quote author="robots"]
It is not scheduler dependent :) The usb does transfer only 64 bytes/ms (-2bytes FTDI status info)
[/quote]
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.
12
Flashrom / Re: Adding Bus Pirate support to flashrom?
New release: flashrom r905 (with no local changes)

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.
13
Flashrom / Re: Adding Bus Pirate support to flashrom?
Attached flashrom, which is upstream version r883 without local changes, fixes the COM10 issue by rewriting the device to UNC if it starts with COM (case insensitive).
15
Flashrom / Re: Adding Bus Pirate support to flashrom?
Was reading the chip successful, too?

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.