Hello, i am trying to add this chip (ID 0x62 0x15). It works so far, but erase function 1 is not working. The datasheet tells that it supports 2K small sector, 32K sector and chip erase. 2K Small Sector and chip erase works. But 32K not. And i don't know why. Please have a look: .vendor = "Sanyo", .name = "LE25FW106", .bustype = BUS_SPI, .manufacture_id = SANYO_ID, .model_id = SANYO_LE25FW106, .total_size = 128, .page_size = 256, .feature_bits = FEATURE_WRSR_WREN, .tested = TEST_OK_PREW, .probe = probe_spi_res2, .probe_timing = TIMING_ZERO, .block_erasers = { { // .eraseblocks = { {2 * 1024, 64} }, //ok // .block_erase = spi_block_erase_d7, // }, { .eraseblocks = { {32 * 1024, 4} }, //not ok .block_erase = spi_block_erase_d8, // }, { // .eraseblocks = { {128 * 1024, 1} }, //ok // .block_erase = spi_block_erase_c7, } }, .printlock = spi_prettyprint_status_register_plain, .unlock = spi_disable_blockprotect, .write = spi_chip_write_256, .read = spi_chip_read, .voltage = {2700, 3600},
I am also not sure if "FEATURE_WRSR_WREN" is correct. The code is taken from "LE25FW406A" chip and changed to fit the "LE25FW106".
This is the error: Found Sanyo flash chip "LE25FW106" (128 kB, SPI). Erasing and writing flash chip... Trying erase function 0... 0x000000-0x007fff:E, 0x008000-0x00ffff:EError: invalid response 0xAF from device spi_block_erase_d8 failed during command execution at address 0x8000 Looking for another erase function. No usable erase functions left. FAILED!
Attention: It tells function 0, but this is because i have removed the other functions for testing. ;-)
BTW: Chips was found an a 2.5" hitachi harddisk. Chip is a "T" model (MSOP8).
On Mon, 2 Jun 2014 08:27:51 +0200 The Raven originalraven@hotmail.com wrote:
Hello, i am trying to add this chip (ID 0x62 0x15). It works so far, but erase function 1 is not working. The datasheet tells that it supports 2K small sector, 32K sector and chip erase. 2K Small Sector and chip erase works. But 32K not. And i don't know why. Please have a look: .vendor = "Sanyo", .name = "LE25FW106", .bustype = BUS_SPI, .manufacture_id = SANYO_ID, .model_id = SANYO_LE25FW106, .total_size = 128, .page_size = 256, .feature_bits = FEATURE_WRSR_WREN, .tested = TEST_OK_PREW, .probe = probe_spi_res2, .probe_timing = TIMING_ZERO, .block_erasers = { { // .eraseblocks = { {2 * 1024, 64} }, //ok // .block_erase = spi_block_erase_d7, // }, { .eraseblocks = { {32 * 1024, 4} }, //not ok .block_erase = spi_block_erase_d8, // }, { // .eraseblocks = { {128 * 1024, 1} }, //ok // .block_erase = spi_block_erase_c7, } }, .printlock = spi_prettyprint_status_register_plain, .unlock = spi_disable_blockprotect, .write = spi_chip_write_256, .read = spi_chip_read, .voltage = {2700, 3600},
I am also not sure if "FEATURE_WRSR_WREN" is correct.
That defines how flashrom should make the status register write-enabled before issuing a WRSR (write status register) command. Either with WREN or with EWSR. Answer see section 3. Write Enable in the datasheet. (it is correct).
The code is taken from "LE25FW406A" chip and changed to fit the "LE25FW106".
This is the error: Found Sanyo flash chip "LE25FW106" (128 kB, SPI). Erasing and writing flash chip... Trying erase function 0... 0x000000-0x007fff:E, 0x008000-0x00ffff:EError: invalid response 0xAF from device
That's a bug in the serprog implementation (again... I think we saw that already in one of your logs a few weeks ago?). Is it perfectly reproducible?
Your chip definition looks good. I'd use another .printlock: spi_prettyprint_status_register_bp1_srwd with a fixme noting that the ERSER error flag is not implemented (yet) though. I am looking forward to a complete patch with sign-off this time? :)
The code is taken from "LE25FW406A" chip and changed to fit the "LE25FW106".
This is the error: Found Sanyo flash chip "LE25FW106" (128 kB, SPI). Erasing and writing flash chip... Trying erase function 0... 0x000000-0x007fff:E, 0x008000-0x00ffff:EError: invalid response 0xAF from device
That's a bug in the serprog implementation (again... I think we saw that already in one of your logs a few weeks ago?). Is it perfectly reproducible?
Your chip definition looks good. I'd use another .printlock: spi_prettyprint_status_register_bp1_srwd with a fixme noting that the ERSER error flag is not implemented (yet) though. I am looking forward to a complete patch with sign-off this time? :)
Few minutes after sending my mail i thought it could be the "bug" in serprog. I tested again and all is working, only erase function1 not. The response is not always the same (now it's 0xA5). I attached the patch for LE25FW106, you can commit it if you think it's ok. And you can find logs from all read, write and erase (function0, 1 and 2). For me all looks good, only "LE25FW106-Erase1.txt" not. But on "normal" operation it uses function0 and this works with serprog.
Greetings
On Tue, 3 Jun 2014 09:04:38 +0200 The Raven originalraven@hotmail.com wrote:
Few minutes after sending my mail i thought it could be the "bug" in serprog. I tested again and all is working, only erase function1 not. The response is not always the same (now it's 0xA5). I attached the patch for LE25FW106, you can commit it if you think it's ok. And you can find logs from all read, write and erase (function0, 1 and 2). For me all looks good, only "LE25FW106-Erase1.txt" not. But on "normal" operation it uses function0 and this works with serprog.
Hi,
I have talked to Denis Carikli (GNUtoo) about this. He has implemented the firmware for the Arduinos implementing serprog. IIRC you got an Arduino Uno which uses a second avr chip instead of an FTDI to connect the micorcontroller to the host. The standard firmware of that chip does not cope well with high bandwidths, i.e. it is buggy. Denis told me that reducing the baud rate supplied to serprog should help with that problem in general, so I would suggest that you try that.
In the long term we want to provide a fixed firmware for the communication Atmel processor. But he has no time and I am not too much interested into fixing foreign code... I'd rather work on my own serprog implementations :)
I will commit your patch (with my sign-off) soon, as it seems to be fine. Thank you very much.
Hi,
I have talked to Denis Carikli (GNUtoo) about this. He has implemented the firmware for the Arduinos implementing serprog. IIRC you got an Arduino Uno which uses a second avr chip instead of an FTDI to connect the micorcontroller to the host. The standard firmware of that chip does not cope well with high bandwidths, i.e. it is buggy. Denis told me that reducing the baud rate supplied to serprog should help with that problem in general, so I would suggest that you try that.
I tried that, but it does not work. 1500000 is the lowest rate which connects the arduino. All values less gave me: Initializing serprog programmer Baud rate is 1000000 now. serprog: connected - attempting to synchronize ........Error: cannot synchronize protocol - check communications and reset device? Error: Programmer initialization failed.
And with 1500000 i got the same error as with 2000000. The strange thing is why it happens only with function1 and not with the others?!
In the long term we want to provide a fixed firmware for the communication Atmel processor. But he has no time and I am not too much interested into fixing foreign code... I'd rather work on my own serprog implementations :)
I hope it works some day. The arduino is very cheap and perfectly to test/add new chips. Normal (commercial) programmers are very expensive. My dream is that some day some one build a parprog which can read and maybe write parallel flashs. :-) Of course, write is difficult, but i would be happy if only reading (dumping) would work. Should be possible with shift registers.
I will commit your patch (with my sign-off) soon, as it seems to be fine. Thank you very much.
Yes it should work. Tested a lot. Erase with function1 is the only negative thing i found.
Thank you for commit.
Greets
On Wed, 4 Jun 2014 16:55:13 +0200 The Raven originalraven@hotmail.com wrote:
Hi,
I have talked to Denis Carikli (GNUtoo) about this. He has implemented the firmware for the Arduinos implementing serprog. IIRC you got an Arduino Uno which uses a second avr chip instead of an FTDI to connect the micorcontroller to the host. The standard firmware of that chip does not cope well with high bandwidths, i.e. it is buggy. Denis told me that reducing the baud rate supplied to serprog should help with that problem in general, so I would suggest that you try that.
I tried that, but it does not work. 1500000 is the lowest rate which connects the arduino. All values less gave me: Initializing serprog programmer Baud rate is 1000000 now. serprog: connected - attempting to synchronize ........Error: cannot synchronize protocol - check communications and reset device? Error: Programmer initialization failed.
And with 1500000 i got the same error as with 2000000. The strange thing is why it happens only with function1 and not with the others?!
No idea, maybe it is a combination of multiple bugs. Thanks for testing that. Maybe I'll look into the details some day. Please keep that chip safe because it is apparently able to reproduce the bug consistently which makes testing easy.
In the long term we want to provide a fixed firmware for the communication Atmel processor. But he has no time and I am not too much interested into fixing foreign code... I'd rather work on my own serprog implementations :)
I hope it works some day. The arduino is very cheap and perfectly to test/add new chips. Normal (commercial) programmers are very expensive. My dream is that some day some one build a parprog which can read and maybe write parallel flashs. :-) Of course, write is difficult, but i would be happy if only reading (dumping) would work. Should be possible with shift registers.
Well, serprog was actually invented to do exactly that :) http://www.randomprojects.org/wiki/Prototype_RS232_AVR_parallel_flash_progra...
I will commit your patch (with my sign-off) soon, as it seems to be fine. Thank you very much.
Yes it should work. Tested a lot. Erase with function1 is the only negative thing i found.
Thank you for commit.
Committed in r1818. Please take better care of whitespace when you send patches in the future. Your patch contained spaces instead of tabs everywhere, and too few of them as well.
-
Stefan Tauner -
The Raven