flash_lock issue for n25q 128mb spi nor part

John Garry john.garry at huawei.com
Thu Jan 9 02:36:11 PST 2020


On 17/12/2019 08:57, Vignesh Raghavendra wrote:
> Hi Tudor,
> 
> On 12/16/2019 11:39 PM, Tudor.Ambarus at microchip.com 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 at ubuntu:/home/john# sudo flash_lock -i /dev/mtd0
Device: /dev/mtd0
Start: 0
Len: 0x1000000
Lock status: locked
Return code: 1
root at 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 at 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 at ubuntu:/home/john# hexdump temp
0000000 ffff ffff ffff ffff ffff ffff ffff ffff
*
0001000
root at 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 at 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 at ubuntu:/home/john# diff temp dump4096
root at 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



More information about the linux-mtd mailing list