Re: flash_lock issue for n25q 128mb spi nor part

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 17/12/2019 08:57, Vignesh Raghavendra wrote:
Hi Tudor,

On 12/16/2019 11:39 PM, Tudor.Ambarus@xxxxxxxxxxxxx wrote:
[...]


But, as you may see, it seems that my change to spi_nor_write() is still
required to stop the first unlock failure message, but it needs to be
relocated to after write_err label, as we now jump there for
spi_nor_wait_till_ready() failure. I guess the equivalent relocation is
also required for spi_nor_erase().

Or maybe spi_nor_wait_till_ready() should clear this flag always.

I reproduced this on a n25q256a, with both erase and write. Did a lock,
an erase or write, and then the unlock raises an error on the read back test:
it receives 0x02 to write (the prev operation let the SR.WE set to 1),
and after write, it reads back 0x00 (which is correct, WE is de-asserted).

What is pretty strange is that Micron says about erase or program operations
that: "When the operation is in progress, the write in progress bit is set
to 1. The write enable latch bit is cleared to 0, whether the operation is
successful or not".

So what I guess it happens, is that when an erase/write command tries to
modify a software protected area, the flash completely ignores the command,
so no Write In Progress, and no clearing of the WE.



From PROGRAM Operations section of mt25q datasheet:

" When a command is applied to a protected sector, the command is not
executed, the write enable latch bit remains set to 1, and flag status
register bits 1 and 4 are set."

So, Data sheet is quite clear about this and SW would need to clear WEL
(if required) after write failure.


Hi guys,

Apart from this issue, on another topic, is there any special reason which we don't support status register.BP3? Is it that it is not adjacent to BP2 in the register, so makes handling trickier?

I ran these commands, which show how this is broken:

root@ubuntu:/home/john# sudo flash_lock -i /dev/mtd0
Device: /dev/mtd0
Start: 0
Len: 0x1000000
Lock status: locked
Return code: 1
root@ubuntu:/home/john# sudo mtd_debug write /dev/mtd0 0xf80000 4096 dump4096
[ 134.573819] spi-nor spi-PRP0001:00: Program operation failed.
[ 134.579567] spi-nor spi-PRP0001:00: Attempted to modify a protected sector.
file_to_flash: write, size 0x1000, n 0x1000
write(): Input/output error
root@ubuntu:/home/john# sudo mtd_debug read /dev/mtd0 0x100000 4096 temp
[ 105.657411] spi-nor spi-PRP0001:00: from 0x00100000, len 4096
Copied 4096 bytes from address 0x00100000 in flash to temp
root@ubuntu:/home/john# hexdump temp
0000000 ffff ffff ffff ffff ffff ffff ffff ffff
*
0001000
root@ubuntu:/home/john# sudo mtd_debug write /dev/mtd0 0x100000 4096 dump4096
[ 140.161265] spi-nor spi-PRP0001:00: to 0x00100000, len 4096
Copied 4096 bytes from dump4096 to address 0x00100000 in flash
root@ubuntu:/home/john# sudo mtd_debug read /dev/mtd0 0x100000 4096 temp
[ 150.697181] spi-nor spi-PRP0001:00: from 0x00100000, len 4096
Copied 4096 bytes from address 0x00100000 in flash to temp
root@ubuntu:/home/john# diff temp dump4096
root@ubuntu:/home/john#

Here is are told that all sectors for the chip are locked, which is untrue, and we could execute the write command successfully on the bottom half.

Thanks,
John

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux