JFFS2 with AM29LV256M

JFFS2 with AM29LV256M

[Manfred Gruber]

Hi MTD users !

I am a new in using flash chips under linux. So i have some questions.
I have a problem with MTD and jffs2 on a ARM920T with AMD AM29LV256M Chips.
With redboot i can erase and flash the chips without problems.
I patched my 2.6.8 kernel with a MTD snapshot from yesterday. 

I have two 16bit AM29LV256M chips on a 32bit bus.Each chip has a erase size of 
0x10000 so i think i have to generate my jffs image with erasesize of 
0x20000?
My opinion is that I have to do following settings in the kernel:

# Memory Technology Devices (MTD)
CONFIG_MTD=y
CONFIG_MTD_DEBUG=y
CONFIG_MTD_DEBUG_VERBOSE=0
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_CONCAT is not set
CONFIG_MTD_REDBOOT_PARTS=y
CONFIG_MTD_REDBOOT_PARTS_UNALLOCATED=y
CONFIG_MTD_REDBOOT_PARTS_READONLY=y
CONFIG_MTD_CMDLINE_PARTS=y

# User Modules And Translation Layers
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y

# RAM/ROM/Flash chip drivers
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
CONFIG_MTD_CFI_ADV_OPTIONS=y
CONFIG_MTD_CFI_NOSWAP=y
# CONFIG_MTD_CFI_BE_BYTE_SWAP is not set
# CONFIG_MTD_CFI_LE_BYTE_SWAP is not set
CONFIG_MTD_CFI_GEOMETRY=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
CONFIG_MTD_CFI_I2=y
CONFIG_MTD_CFI_AMDSTD=y
CONFIG_MTD_CFI_AMDSTD_RETRY=5
CONFIG_MTD_CFI_UTIL=y
CONFIG_MTD_RAM=y
CONFIG_MTD_ROM=y

# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
CONFIG_MTD_PHYSMAP=y
CONFIG_MTD_PHYSMAP_START=0x10000000
CONFIG_MTD_PHYSMAP_LEN=0x4000000
CONFIG_MTD_PHYSMAP_BANKWIDTH=4
and jffs2 is also set.

At boot I get following:
physmap flash device: 4000000 at 10000000
phys_mapped_flash: Found 2 x16 devices at 0x0 in 32-bit bank
 Amd/Fujitsu Extended Query Table at 0x0040
phys_mapped_flash: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
6 RedBoot partitions found on MTD device phys_mapped_flash
Creating 6 MTD partitions on "phys_mapped_flash":

until now is this correct, what does the Disabling erase-suspend-program due 
to code brokenness mean ?

then i make my jffs2 image on my host with:
mkfs.jffs2 -v -l -e0x20000 -d/tmp/testdir -o${VERZ}/rootfs.img

then i erase on flash partition with:
flash_eraseall /dev/mtd2
and copy the rootfs.img to the partition:
cp rootfs.img /dev/mtd2
mount it with:
mount -t jffs2 /dev/mtdblock2 /mnt

until now all worked, i think i have done the correct things... but:

when i now copy a file in the mounted jffs2-image dir i get alot of this 
messages:

MTD do_write_oneword(): WRITE 0x00286bc0(0x978d0902)
MTD do_write_oneword(): software timeout
MTD do_write_oneword(): software timeout
MTD do_write_oneword(): software timeout
MTD do_write_oneword(): software timeout
Write of 1887 bytes at 0x00046b7c failed. returned -5, retlen 1884
And the file isnt there ..

Doese someone have a sollution for this ?

Thanks, regards Manfred

Re: JFFS2 with AM29LV256M

[David Woodhouse]

On Thu, 2004-08-19 at 10:06 +0200, Manfred Gruber wrote:
> until now is this correct, what does the Disabling erase-suspend-program due 
> to code brokenness mean ?

Our code which should handle suspending erases to allow programming is
broken. So we disabled it -- you have to wait for erases to complete
before the code will write data to the flash instead.

> then i erase on flash partition with:
> flash_eraseall /dev/mtd2
> and copy the rootfs.img to the partition:
> cp rootfs.img /dev/mtd2
> mount it with:
> mount -t jffs2 /dev/mtdblock2 /mnt
> 
> until now all worked, i think i have done the correct things... but:
> 
> when i now copy a file in the mounted jffs2-image dir i get alot of this 
> messages:
> 
> MTD do_write_oneword(): WRITE 0x00286bc0(0x978d0902)
> MTD do_write_oneword(): software timeout
> MTD do_write_oneword(): software timeout
> MTD do_write_oneword(): software timeout
> MTD do_write_oneword(): software timeout
> Write of 1887 bytes at 0x00046b7c failed. returned -5, retlen 1884

That's odd. You have indeed done the correct things -- but writing to
the /dev/mtd2 device works, while jffs2 writes don't. I don't quite see
what's different. 

There have been some changes to the chip driver for AMD chips recently.
Out of interest, could you try an unpatched 2.6.8 kernel and see if that
behaves the same?

-- 
dwmw2

Re: JFFS2 with AM29LV256M

[Manfred Gruber]

Am Donnerstag, 19. August 2004 10:32 schrieben Sie:

> Our code which should handle suspending erases to allow programming is
> broken. So we disabled it -- you have to wait for erases to complete
> before the code will write data to the flash instead.

Then i have to change the do_write_oneword function to wait until erase is 
finshed ?

> That's odd. You have indeed done the correct things -- but writing to
> the /dev/mtd2 device works, while jffs2 writes don't. I don't quite see
> what's different.

the difference is: cp rootfs.img /dev/mtd only uses:

MTD_write
MTD_do_write_buffer
and so on ...

and cp a file on the mounted image uses:

MTD do_write_buffer(): WRITE 0x0028641c(0xe0011985)
MTD do_write_oneword(): WRITE 0x0028641c(0xd5997a45)
MTD do_write_oneword(): software timeout
MTD do_write_oneword(): software timeout
MTD do_write_oneword(): software timeout
MTD do_write_oneword(): software timeout
Write of 45 bytes at 0x0004641c failed. returned -5, retlen 36

> There have been some changes to the chip driver for AMD chips recently.
> Out of interest, could you try an unpatched 2.6.8 kernel and see if that
> behaves the same?

I have done this with a 2.6.8-rc3 there was the same problem, because of that 
i haved used the snapshot of yesterday.

thanks regards manfred

Re: JFFS2 with AM29LV256M

[David Woodhouse]

On Thu, 2004-08-19 at 11:40 +0200, Manfred Gruber wrote:
> Am Donnerstag, 19. August 2004 10:32 schrieben Sie:
> 
> > Our code which should handle suspending erases to allow programming is
> > broken. So we disabled it -- you have to wait for erases to complete
> > before the code will write data to the flash instead.
> 
> Then i have to change the do_write_oneword function to wait until erase is 
> finshed ?

No, we did that already. And we put that printk in to remind us to fix
it properly some time soon.
> the difference is: cp rootfs.img /dev/mtd only uses:
> 
> MTD_write
> MTD_do_write_buffer
> and so on ...
> 
> and cp a file on the mounted image uses:
> 
> MTD do_write_buffer(): WRITE 0x0028641c(0xe0011985)
> MTD do_write_oneword(): WRITE 0x0028641c(0xd5997a45)
> MTD do_write_oneword(): software timeout

Hmmm ok, so it's do_write_oneword() which is broken.

-- 
dwmw2

Re: JFFS2 with AM29LV256M

[Eric W. Biederman]

David Woodhouse <dwmw2@infradead.org> writes:

> On Thu, 2004-08-19 at 11:40 +0200, Manfred Gruber wrote:
> > Am Donnerstag, 19. August 2004 10:32 schrieben Sie:
> > 
> > > Our code which should handle suspending erases to allow programming is
> > > broken. So we disabled it -- you have to wait for erases to complete
> > > before the code will write data to the flash instead.
> > 
> > Then i have to change the do_write_oneword function to wait until erase is 
> > finshed ?
> 
> No, we did that already. And we put that printk in to remind us to fix
> it properly some time soon.

When you get to that please make certain the code is disabled for
chips coming from jedec_probe as by and large they don't support erase 
suspend.  I was wondering why there was a print statement in there with
no code connected to it. 

> > the difference is: cp rootfs.img /dev/mtd only uses:
> > 
> > MTD_write
> > MTD_do_write_buffer
> > and so on ...
> > 
> > and cp a file on the mounted image uses:
> > 
> > MTD do_write_buffer(): WRITE 0x0028641c(0xe0011985)
> > MTD do_write_oneword(): WRITE 0x0028641c(0xd5997a45)
> > MTD do_write_oneword(): software timeout
> 
> Hmmm ok, so it's do_write_oneword() which is broken.

Possibly it still could be the chip. do_write_oneword since it
is read the data back anyway confirms that the data read back is
what was written.  I don't believe the write_buffer code path
does any but the most rudimentary sanity checks.

Eric

Re: JFFS2 with AM29LV256M

[Manfred Gruber]

Hi !

Am Donnerstag, 19. August 2004 12:45 schrieben Sie:
> > Hmmm ok, so it's do_write_oneword() which is broken.
>
> Possibly it still could be the chip. do_write_oneword since it
> is read the data back anyway confirms that the data read back is
> what was written.  I don't believe the write_buffer code path
> does any but the most rudimentary sanity checks.

This is correct. read_oneword does a check but also with paching this out the 
problem is there.

I found out that the first write one block works the secound not, any idea ?
copy a file first come in the write one block function: 

MTD do_write_buffer(): WRITE 0x0028e9c0(0x00000069)
MTD do_write_oneword(): WRITE 0x0028e9d8(0x6161616a)
MTD do_write_oneword(): WRITE addr 0x0028e9d8
MTD do_write_oneword(): WRITE oldd 0x6161616a curd (0x6161616a)
MTD do_write_oneword(): WRITE oldd 0x6161616a curd (0x6161616a)
MTD do_write_oneword(): WRITE 0x0028e9dc(0xffffff61)
MTD do_write_oneword(): WRITE addr 0x0028e9dc
MTD do_write_oneword(): WRITE oldd 0xffffff61 curd (0xffffff61)
MTD do_write_oneword(): WRITE oldd 0xffffff61 curd (0xffffff61)

secound come in the write one block function:

MTD do_write_buffer(): WRITE 0x0028e9e0(0xe0021985)
MTD do_write_buffer(): WRITE 0x0028f0c0(0x728ea668)
MTD do_write_buffer(): WRITE 0x0028f100(0xbc68ad56)
MTD do_write_oneword(): WRITE 0x0028ea24(0x978d0902)
MTD do_write_oneword(): WRITE addr 0x0028ea24
MTD do_write_oneword(): WRITE oldd 0xff640800 curd (0xff240800)
MTD do_write_oneword(): software timeout
MTD do_write_oneword(): WRITE addr 0x0028ea24
MTD do_write_oneword(): WRITE oldd 0xff640800 curd (0xff240800)
MTD do_write_oneword(): software timeout
MTD do_write_oneword(): WRITE addr 0x0028ea24
MTD do_write_oneword(): WRITE oldd 0xff640800 curd (0xff240800)

Any idea ?

Thanks,regards