Here's an example flow (with my hack to stop using 16b SR method):
root@ubuntu:/home/john# flash_lock -l /dev/mtd0
root@ubuntu:/home/john# mtd_debug erase /dev/mtd0 0xe00000 4096
[ 69.650642] spi-nor spi-PRP0001:00: at 0xe00000, len 4096
Erased 4096 bytes from address 0x00e00000 in flash
root@ubuntu:/home/john# mtd_debug write /dev/mtd0 0xe00000 4096 dump4096
[ 77.093755] spi-nor spi-PRP0001:00: to 0x00e00000, len 4096
Copied 4096 bytes from dump4096 to address 0x00e00000 in flash
root@ubuntu:/home/john# mtd_debug read /dev/mtd0 0xe00000 4096 temp
[ 82.162445] spi-nor spi-PRP0001:00: from 0x00e00000, len 4096
Copied 4096 bytes from address 0x00e00000 in flash to temp
root@ubuntu:/home/john# flash_lock -u /dev/mtd0
[ 87.558435] spi-nor spi-PRP0001:00: SR1: read back test failed
flash_lock: error!: could not unlock device: /dev/mtd0
error 5 (Input/output error)
root@ubuntu:/home/john#
Unlock reports an error as the the read back test in
spi_nor_write_sr1_and_check() fails as the SR.WEL has never been cleared.
Interesting.
I note that spi_nor_erase() exits with a call to
spi_nor_write_disable(), yet spi_nor_write() doesn't - maybe we should
add a similar call there.
Does the following do the trick?
- { "n25q128a11", INFO(0x20bb18, 0, 64 * 1024, 256, SECT_4K |
SPI_NOR_QUAD_READ) },
+ { "n25q128a11", INFO(0x20bb18, 0, 64 * 1024, 256, SECT_4K | USE_FSR |
+ SPI_NOR_QUAD_READ) },
I'll give it a spin - along with your SR lock fix - when I get back on
the HW again.
This can of course be extended to all micron flashes, if all support FSR, but
some documentation work has to be made.
I'm just saying this while it's fresh in my head - I don't want to seem
pushy :)
No worries, this is a good initiative, thanks.
Much appreciated,
John
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
