Erasing NOR flash: ioctl (MEMUNLOCK) return status?

Question

I am trying to erase NOR flash memory using the MTD Linux driver in C ...

I am confused about the return status from the ioctl(MEMUNLOCK) call, which returns an error even if ioctl(MEMERASE) after it.

The following code displays a warning message, but it works (i.e. the Flash block has been deleted):

 int erase_MTD_Pages(int fd, size_t size, off_t offset) { mtd_info_t mtd_info; erase_info_t ei; ioctl(fd, MEMGETINFO, &mtd_info); ei.length = mtd_info.erasesize; for(ei.start = offset; ei.start < (offset+size); ei.start += mtd_info.erasesize) { if(ioctl(fd, MEMUNLOCK, &ei) < 0) { // logPrintf(FAILURE, "[Flash] Can not unlock MTD (MEMUNLOCK, errno=%d)!\n", errno); // return RETURN_FILE_ERROR; logPrintf(WARNING, "[Flash] Can not unlock MTD (MEMUNLOCK, errno=%d)!\n", errno); } if(ioctl(fd, MEMERASE, &ei) < 0) { logPrintf(FAILURE, "[Flash] Can not erase MTD (MEMERASE, errno=%d)!\n", errno); return RETURN_FILE_ERROR; } } return RETURN_SUCCESS; } 

When I look at some C codes on the network, the return status from MEMUNLOCK is not always checked (for example, from mtc.c ):

 ioctl(fd, MEMUNLOCK, &mtdEraseInfo); if(ioctl(fd, MEMERASE, &mtdEraseInfo)) { fprintf(stderr, "Could not erase MTD device: %s\n", mtd); close(fd); exit(1); } 

flash_unlock also returns an error:

 root $ cat /proc/mtd dev: size erasesize name mtd0: 00020000 00020000 "X-Loader-NOR" mtd1: 000a0000 00020000 "U-Boot-NOR" mtd2: 00040000 00020000 "Boot Env-NOR" mtd3: 00400000 00020000 "Kernel-NOR" mtd4: 03b00000 00020000 "File System-NOR" root $ mtd_debug info /dev/mtd3 mtd.type = MTD_NORFLASH mtd.flags = MTD_CAP_NORFLASH mtd.size = 4194304 (4M) mtd.erasesize = 131072 (128K) mtd.writesize = 1 mtd.oobsize = 0 regions = 0 root $ flash_unlock /dev/mtd3 Could not unlock MTD device: /dev/mtd3 

Am I missing something? Is it normal to get an error from MEMUNLOCK with some configurations?

Notes / Environment:

• The read-only flag (MTD_WRITEABLE) in not set in the mtd3 section (only on mtd0 and mtd1 ).
• flash_lock also returns the same error.
• TI AM3505 (ARM Cortex A8, OMAP34).
• Linux 2.6.37.
• Flash NOR Spansion S29GL512S12DHIV1.

Kernel Log:

 mtdoops: mtd device (mtddev=name/number) must be supplied physmap platform flash device: 08000000 at 08000000 physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x000001 Chip ID 0x002301 Amd/Fujitsu Extended Query Table at 0x0040 Amd/Fujitsu Extended Query version 1.5. Silicon revision: 14 Address sensitive unlock: Required Erase Suspend: Read/write Block protection: 1 sectors per group Temporary block unprotect: Not supported Block protect/unprotect scheme: 8 Number of simultaneous operations: 0 Burst mode: Not supported Page mode: 12 word page Vpp Supply Minimum Program/Erase Voltage: 0.0 V Vpp Supply Maximum Program/Erase Voltage: 0.0 V Top/Bottom Boot Block: Uniform, Top WP number of CFI chips: 1 RedBoot partition parsing not available Using physmap partition information Creating 5 MTD partitions on "physmap-flash.0": 0x000000000000-0x000000020000 : "X-Loader-NOR" 0x000000020000-0x0000000c0000 : "U-Boot-NOR" 0x0000000c0000-0x000000100000 : "Boot Env-NOR" 0x000000100000-0x000000500000 : "Kernel-NOR" 0x000000500000-0x000004000000 : "File System-NOR" 

Answer 1

For the flash chip I was working on (drivers / mtd / devices / m25p80.c), I found that UNLOCK was not implemented. The ioctl (UNLOCK) driver returned -EOPNOTSUPP = 95. And checking the code showed that the return status of mtd_unlock fell to the floor, as you already found.

This implies the assumptions in the m25p80 driver that the flash memory will never be locked, and in the mtd drivers it is normal for the device driver to lower UNLOCK. On the board I was working on, the flash blocked u-boot after each write, so erasing and reprogramming from linux did not work at all. I looked at the u-boot driver and the technical description of the device, got the code for implementing m25p80_lock and m25p80_unlock, it was not too difficult after I realized what it was. I did not climb up it.

It seems that the defect for chip drivers is not implemented.

By the way, Mousstix, a very good job, providing complete information in this matter.