[flashrom] [PATCH] Dediprog SF100 support

[Carl-Daniel Hailfinger]

On 19.01.2010 12:43, Stefan Reinauer wrote:
> On 1/19/10 12:36 PM, Carl-Daniel Hailfinger wrote:
>   
>> Hm. To be honest, reading is something I could not find in the logs.
>>   
>>     
> I can provide a reading only log if that helps?
>   

Unfortunately that won't help. Reading uses USB bulk transfers without
opcodes. This may sound strange, but the SF100 firmware seems to have a
builtin mode where it issues the SPI READ opcode (or the FAST_READ
opcode, no idea without a SPI sniffer log) if you send a special request
without any opcode. As long as I have no idea about how to use this for
partial reads, we can't use that mode.


>> Then again, maybe some diagnostics in SPEW mode could help. Please run
>>
>> flashrom -p dediprog -VV -r testimage.rom
>>
>> with the following debug patch (you need to run "make distclean" before
>> compiling it)
>>
>>
>> Mark 4 byte RDID as supported by Dediprog.
>> Really abort if any unhandled command sizes are run.
>> Add some debugging at SPEW level.
>>
>> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
>>     
>
> /flashrom -p dediprog -VV -r testimage.rom
> flashrom v0.9.1-r869
> dediprog_init
> Found USB device (0483:dada).
> Found a SF100   V:3.1.8
> Setting SPI voltage to 3.500 V
> [...]
> Probing for Atmel AT25DF021, 256 KB: dediprog_spi_send_command,
> writecnt=1, readcnt=3
> RDID returned 0x20 0x20 0x16. probe_spi_rdid_generic: id1 0x20, id2 0x2016
> [...]
> Probing for AMIC A25L40PT, 512 KB: dediprog_spi_send_command,
> writecnt=1, readcnt=4
> RDID returned 0x20 0x20 0x16 0x10. probe_spi_rdid_generic: id1 0x20, id2
> 0x2016
> [...]
> Probing for ST M25P32, 4096 KB: dediprog_spi_send_command, writecnt=1,
> readcnt=3
> RDID returned 0x20 0x20 0x16. probe_spi_rdid_generic: id1 0x20, id2 0x2016
> dediprog_spi_send_command, writecnt=1, readcnt=2
> Chip status register is 00
> Chip status register: Status Register Write Disable (SRWD) is not set
> Chip status register: Bit 6 is not set
> Chip status register: Bit 5 / Block Protect 3 (BP3) is not set
> Chip status register: Bit 4 / Block Protect 2 (BP2) is not set
> Chip status register: Bit 3 / Block Protect 1 (BP1) is not set
> Chip status register: Bit 2 / Block Protect 0 (BP0) is not set
> Chip status register: Write Enable Latch (WEL) is not set
> Chip status register: Write In Progress (WIP/BUSY) is not set
> Found chip "ST M25P32" (4096 KB, SPI) at physical address 0xffc00000.
> [...]
> Reading flash... dediprog_spi_read, start=0x0, len=0x400000
> dediprog_spi_send_command, writecnt=4, readcnt=4
> dediprog_spi_send_command, writecnt=4, readcnt=4
> dediprog_spi_send_command, writecnt=4, readcnt=4
> dediprog_spi_send_command, writecnt=4, readcnt=4
> dediprog_spi_send_command, writecnt=4, readcnt=4
> dediprog_spi_send_command, writecnt=4, readcnt=4
> dediprog_spi_send_command, writecnt=4, readcnt=4
> dediprog_spi_send_command, writecnt=4, readcnt=4
> dediprog_spi_send_command, writecnt=4, readcnt=4
> dediprog_spi_send_command, writecnt=4, readcnt=4
> dediprog_spi_send_command, writecnt=4, readcnt=4
> dediprog_spi_send_command, writecnt=4, readcnt=4
> dediprog_spi_send_command, writecnt=4, readcnt=4
> dediprog_spi_send_command, writecnt=4, readcnt=4
> dediprog_spi_send_command, writecnt=4, readcnt=4
> dediprog_spi_send_command, writecnt=4, readcnt=4
> dediprog_spi_send_command, writecnt=4, readcnt=4
> dediprog_spi_send_command, writecnt=4, readcnt=4
> dediprog_spi_send_command, writecnt=4, readcnt=4
> dediprog_spi_send_command, writecnt=4, readcnt=4
> dediprog_spi_send_command, writecnt=4, readcnt=4
> dediprog_spi_send_command, writecnt=4, readcnt=4
> dediprog_spi_send_command, writecnt=4, readcnt=4
> dediprog_spi_send_command, writecnt=4, readcnt=4
> [...]
>   

Good news: My patch works as designed. Read seems to work as well. Ack
please?
Bad news: The dediprog is dog slow. And with dog slow, I mean unbearably
sloooooooow. Reading works, but for a 4 MByte chip it may take up to 35
minutes AFAICS, maybe more. The file specified by -r will only be filled
with contents after the read is complete.

I see a speedup by a factor of 4 on the horizon, but I will implement
that only after I get confirmation that read works correctly (would be
pointless otherwise).

Regards,
Carl-Daniel

-- 
Developer quote of the year:
"We are juggling too many chainsaws and flaming arrows and tigers."