P30 flash left in read status mode after a write
Jon Ringle
jon at ringle.org
Wed Feb 14 13:52:31 EST 2007
Hi,
We have a hardware architecture with a IXP455 processor that allows read
access to a P30 flash attached to the IXP's expansion bus from a Pentium
M that does it's access via the PCI bus. The flash has 4 partitions:
Redboot, jffs2, fconfig, fis. I am running Linux 2.6.16.29 and I've
found that whenever a write is done to the jffs2 filesystem that flash
is left in read status mode and anything trying to do a read of flash
directly reads only 0x0080. Reading from an mtd device seems to fix the
problem. I modified the mapper utility from LDD3 so I could read flash
directly from linux which illustrates the problem:
[root at rsc4 ~]# mapper /dev/mem 0x51fa0000 0x100 1|hexdump -C
mapped "/dev/mem" from 1375338496 (0x51fa0000) to 1375338752 (0x51fa0100)
00000000 00 00 10 00 0b ad fa ce 01 0c 01 00 62 6f 6f 74
|............boot|
00000010 5f 73 63 72 69 70 74 00 00 00 00 01 04 11 01 0c
|_script.........|
00000020 62 6f 6f 74 5f 73 63 72 69 70 74 5f 64 61 74 61
|boot_script_data|
00000030 00 62 6f 6f 74 5f 73 63 72 69 70 74 00 25 7b 73
|.boot_script.%{s|
00000040 6e 69 66 66 7d 0a 25 7b 67 6f 7d 0a 25 7b 66 69
|niff}.%{go}.%{fi|
00000050 78 5f 7a 49 6d 61 67 65 7d 0a 00 00 00 00 00 00
|x_zImage}.......|
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|................|
*
00000100
[root at rsc4 ~]# touch xyz
[root at rsc4 ~]# mapper /dev/mem 0x51fa0000 0x100 1|hexdump -C
mapped "/dev/mem" from 1375338496 (0x51fa0000) to 1375338752 (0x51fa0100)
00000000 00 80 00 80 00 80 00 80 00 80 00 80 00 80 00 80
|................|
*
00000100
[root at rsc4 ~]# cat /dev/mtd2 > /dev/null
[root at rsc4 ~]# mapper /dev/mem 0x51fa0000 0x100 1|hexdump -C
mapped "/dev/mem" from 1375338496 (0x51fa0000) to 1375338752 (0x51fa0100)
00000000 00 00 10 00 0b ad fa ce 01 0c 01 00 62 6f 6f 74
|............boot|
00000010 5f 73 63 72 69 70 74 00 00 00 00 01 04 11 01 0c
|_script.........|
00000020 62 6f 6f 74 5f 73 63 72 69 70 74 5f 64 61 74 61
|boot_script_data|
00000030 00 62 6f 6f 74 5f 73 63 72 69 70 74 00 25 7b 73
|.boot_script.%{s|
00000040 6e 69 66 66 7d 0a 25 7b 67 6f 7d 0a 25 7b 66 69
|niff}.%{go}.%{fi|
00000050 78 5f 7a 49 6d 61 67 65 7d 0a 00 00 00 00 00 00
|x_zImage}.......|
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|................|
*
00000100
It appears that the MTD_XIP code has what I need to get flash out of
read status mode after a write, however, since I'm not actually doing
execute in place, it's overkill for my purposes. It seems that writing a
xip_enable() function that puts flash in ready mode and leaving the
other xip_* functions defined as nothing was a quick way to fix the
problem in my case:
static void __xipram xip_enable(struct map_info *map, struct flchip *chip,
unsigned long adr)
{
struct cfi_private *cfi = map->fldrv_priv;
if (chip->state != FL_POINT && chip->state != FL_READY) {
map_write(map, CMD(0xff), adr);
chip->state = FL_READY;
}
(void) map_read(map, adr);
}
This did indeed seem to fix the problem, but I'm not sure if I might
inadvertently be causing some side effect. I believe that I might be
taking a slight performance hit to consecutive jffs2 write operations
because now each write operation will need to spend more cycles putting
the flash in to a write mode.
Any advice would be appreciated.
Thanks,
Jon
More information about the linux-mtd
mailing list