FAQ: [#6852] Flash (m25p80) block erase failure(2011)

[#6852] Flash (m25p80) block erase failure

Submitted By: Zoltan Ger

Open Date

2011-10-27 08:28:23 Close Date

2011-11-09 21:32:36

Priority:

Medium Assignee:

Aaron Wu

Status:

Closed Fixed In Release:

N/A

Found In Release:

2010R1-RC5 Release:

2010R1-RC4

Category:

Drivers Board:

N/A

Processor:

BF537 Silicon Revision:

0.3

Is this bug repeatable?:

Yes Resolution:

Rejected

Uboot version or rev.:

2009R1 Toolchain version or rev.:

gcc version 4.3.5 (ADI-2010R1-

App binary format:

N/A

Summary: Flash (m25p80) block erase failure

Details:

This is an issue which worked in release 2009R1.1-RC4 but does not work any more in release 2010R1-RC4.

Setup: A BF537 DSP and a M25P80 NOR flash connected via SPI

User-Application: See flash.c

Driver-Code: see mtdchar.c and m25p80.c (both contian additional debug output)

Problem:

1. Application output:

erase /dev/mtd4 0x0 8 0

open /dev/mtd4.

fd after open() = 4

erase

Erase Total 8 Units

Performing Flash Erase of length 32768 at offset 0x0

non_region_erase: Fd = 4, start = 0, numSec = 8, unlock = 0

Performing Flash Erase of length 32768 at offset 0x8000

non_region_erase: Fd = 4, start = 0, numSec = 8, unlock = 0

Performing Flash Erase of length 32768 at offset 0x10000

non_region_erase: Fd = 4, start = 0, numSec = 8, unlock = 0

MTD Erase failure: Invalid argument

lseek 0.

write 65536 bytes at 0x0...-1 bytes written.

write 65536 bytes at 0x10000...-1 bytes written.

....

2. Driver output:

MTD_open

MTD_ioctl

MEMERASE

spi0.3: m25p80_erase at 0x0, len 32768

Sanity check

Sanity check passed

Mutex lock

spi0.3: erase_sector 32KiB at 0x00000000

after wait_till_ready()

after write_enable()

SPI_write spi0.3

...finished

OK, Done

MTD_ioctl

MEMERASE

spi0.3: m25p80_erase at 0x8000, len 32768

Sanity check

Sanity check passed

Mutex lock

spi0.3: erase_sector 32KiB at 0x00008000

after wait_till_ready()

after write_enable()

SPI_write spi0.3

...finished

OK, Done

MTD_ioctl

MEMERASE

MTD_close

spi_release: close() return

mtdblock: write on "ROMfs" at 0x7800, size 0x200

mtdblock: write on "ROMfs" at 0x7a00, size 0x200

mtdblock: write on "ROMfs" at 0x7000, size 0x200

mtdblock: write on "ROMfs" at 0x7200, size 0x200

mtdblock: write on "ROMfs" at 0x4800, size 0x200

As you can see, erasing the third sector fails, cause the erase() function in line 572 in mtdchar.c does not call m25p80_erase() in m25p80.c any more. It seems that another thread interrupts the erase procedure and demages the mtd_info object.

Is this probabaly a knon issue? I could not find any related bugs.

Thanks in advance.

Follow-ups

--- Zoltan Ger 2011-10-27 08:53:04

The FIXME statement in mtdchar.c says:

FIXME: Allow INTERRUPTIBLE. Which means

not having the wait_queue head on the stack.

If the wq_head is on the stack, and we

leave because we got interrupted, then the

wq_head is no longer there when the

callback routine tries to wake us up.

This statement is present in release 2009R1.1-RC4 as well. Could this be the

reason for the problem if there is a thread in release 2010R1-RC4 which

interrupts the erase procedure ?

--- Zoltan Ger 2011-10-27 09:23:28

root:/> version

kernel: Linux release 2.6.34.7-ADI-2010R1-g7583325, build #1 Thu Jun 23

11:20:50 CEST 2011

toolchain: bfin-uclinux-gcc release gcc version 4.3.5 (ADI-2010R1-RC4)

user-dist: release 2010R1, build #1 Thu Jun 23 11:32:57 CEST 2011

--- Aaron Wu 2011-11-01 04:10:55

I don't have a SPI Flash on bf537 board. With a BF548 board with SPI Flash on it

I can erase it with mtd-utils:

flash_eraseall /dev/mtd4

Erasing 64 Kibyte @ 180000 -- 100 % complete.

For Parallel Flash on this 548 board erase also works:

flash_eraseall /dev/mtd2

Erasing 128 Kibyte @ b80000 -- 100 % complete.

Note mtd2 is the last partition for Parallel Flash and mtd4 is the last one for

SPI Flash.

--- Zoltan Ger 2011-11-01 06:29:50

Does your test call the m25p80 driver from mtdchar.c ? If yes, please attach the

MTD debug messages. OR if you can, take my attached mtdchar & m25p80 files

an build the kernel with these files and make the test again.

Thanks in advance.

--- Zoltan Ger 2011-11-01 09:06:16

Attached the output of our use-case (flash_erase 0 8) and the result: see

flash_erase.txt

--- Zoltan Ger 2011-11-01 09:24:35

The error occured always after trying to erase the third sector at 0x10000. I

tried to erase beginning at 0x10000 (flash_erase /dev/mtd4 0x10000 6) -->

failed, same for 0x20000, 0x30000, 0x40000 and so on... . It means, only the two

first sectors can be erased successfully with 2010R1-RC4. With 2009R1.1-RC4, all

sectors can be erased successfully.

--- Zoltan Ger 2011-11-01 11:46:33

OK, I tried flash_eraseall as well and it deletes only 2 sectors and returns

successfull --> the device probe procedure seems not to work correctly, de

sector counter contains a wrong value. It seems, that the device will not be

detected correctly. Can you reproduce such an issue as well? Do you have any

suggestions how to debug device probing?

Thanks in advance.

--- Aaron Wu 2011-11-02 03:43:56

Your output says "Invalid argument", have you checked this? Do you

really have up to 8 unit for your mtd4 partition?

--- Zoltan Ger 2011-11-02 04:43:41

Yes, that's what I wrote im my comment above: "sector counter contains a

wrong value". I checked the output during bootup:

m25p80 spi0.3: found m25p05-nonjedec, expected m25p80

m25p80 spi0.3: m25p05-nonjedec (64 Kbytes)

This means, the device will not be detected correctly. I'll analyze this in

details today.

--- Aaron Wu 2011-11-02 04:58:49

Right I think you should check that, You detected a m25p05, which is actally 64K

by the datasheet. Please check the chip you mount on your board. On my bf548

board with m25p80 on it I get it detected correctly:

m25p80 spi0.1: m25p16 (2048 Kbytes)

Creating 2 MTD partitions on "m25p80":

0x000000000000-0x000000080000 : "bootloader(spi)"

0x000000080000-0x000000200000 : "linux kernel(spi)"

--- Zoltan Ger 2011-11-09 10:30:10

I think we can close this issue, we checked the devices and we figured out that

we received some boards with non-jedec flash devices, therefore the m25p80 will

not be detected correctly during bootup.

Thanks for your help !

Files

Changes

Commits

Dependencies

Duplicates

Associations