Help needed with MTD on AT91SAM9263-EK please.

Hi All,

I get very little joy from the NAND flash on my AT91SAM9263-EK board. I have 2 partitions, one starts at 0x100000 and finishes at 0x04000000, then other starts from there and finishes at the end of the device at 256MB. E.g.

/*
* NAND flash
*/

static struct mtd_partition __initdata ek_nand_partition[] = {
        {
                .name   = "Partition 1",
                .offset = 0x100000,
                .size   = (64 * 1024 * 1024) - 0x100000,
        },
        {
                .name   = "Partition 2",
                .offset = 64 * 1024 * 1024,
                .size   = MTDPART_SIZ_FULL,
        },
};

The kernel seems happy with this:
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron NAND 256MiB 3,3V 8-bit)
AT91 NAND: 8-bit, Software ECC
Scanning device for bad blocks
Creating 2 MTD partitions on "at91_nand":
0x00100000-0x04000000 : "Partition 1" 0x04000000-0x10000000 : "Partition 2"

So I try running some diagnostics, such as;

root@at91sam9263ek:~/mtd-tools$ nandtest -p1 -o0 -l0x100000 /dev/mtd0
ECC corrections: 0
ECC failures   : 0
Bad blocks     : 0
BBT blocks     : 0
00000000: reading... 
ECC failed at 00000000
00000000: checking...
compare failed. seed 1804289383
Byte 0x7c40 is 0c should be ff
Byte 0xa58f is 0c should be ff
Byte 0xd354 is 0c should be 5c
Byte 0xd355 is 0c should be ff
Byte 0x108b4 is 0c should be a0
Byte 0x108b5 is 0c should be ff
Byte 0x108b8 is ff should be b6
Byte 0x108b9 is ff should be 2e
Byte 0x108bc is ff should be 4a

Always the same, and the same if I chose /dev/mtd1.

Also, this;

root@at91sam9263ek:~/mtd-tools$ ./flash_eraseall -j /dev/mtd0
Erasing 128 Kibyte @ 3ee0000 -- 99 % complete. Cleanmarker written at
3ee0000.
root@at91sam9263ek:~/mtd-tools$ ls /dev/mtd*
/dev/mtd0       /dev/mtd1       /dev/mtdblock0
/dev/mtd0ro     /dev/mtd1ro     /dev/mtdblock1
root@at91sam9263ek:~/mtd-tools$ nandwrite -a -p /dev/mtd0 /boot/uImage
Writing data to block 0
Writing data to block 20000
Writing data to block 40000
Writing data to block 60000
Writing data to block 80000
Writing data to block a0000
Writing data to block c0000
Writing data to block e0000
Writing data to block 100000
Writing data to block 120000
Writing data to block 140000
Writing data to block 160000
Writing data to block 180000
Writing data to block 1a0000
Writing data to block 1c0000
Writing data to block 1e0000
Writing data to block 200000
Writing data to block 220000
Writing data to block 240000
root@at91sam9263ek:~/mtd-tools$ nanddump -f text.out -l 0x260000 -s
0 /dev/mtd0
ECC failed: 3
ECC corrected: 0
Number of bad blocks: 0
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00260000...
ECC: 1 uncorrectable bitflip(s) at offset 0x00001000
ECC: 1 uncorrectable bitflip(s) at offset 0x00001800
ECC: 1 uncorrectable bitflip(s) at offset 0x00002000
ECC: 1 uncorrectable bitflip(s) at offset 0x00002800
ECC: 1 uncorrectable bitflip(s) at offset 0x00003000
ECC: 1 uncorrectable bitflip(s) at offset 0x00004800
ECC: 1 uncorrectable bitflip(s) at offset 0x00007000
ECC: 1 uncorrectable bitflip(s) at offset 0x0000c800
ECC: 1 uncorrectable bitflip(s) at offset 0x0000f000
ECC: 1 uncorrectable bitflip(s) at offset 0x00011000
ECC: 1 uncorrectable bitflip(s) at offset 0x00011800
ECC: 1 uncorrectable bitflip(s) at offset 0x00014000
ECC: 1 uncorrectable bitflip(s) at offset 0x00014800
ECC: 1 uncorrectable bitflip(s) at offset 0x00015000
ECC: 1 uncorrectable bitflip(s) at offset 0x00015800
ECC: 1 corrected bitflip(s) at offset 0x00016000
ECC: 1 uncorrectable bitflip(s) at offset 0x00017000
ECC: 1 uncorrectable bitflip(s) at offset 0x00019800
ECC: 1 uncorrectable bitflip(s) at offset 0x0001c000
ECC: 1 uncorrectable bitflip(s) at offset 0x0001f000
ECC: 1 uncorrectable bitflip(s) at offset 0x00024800
ECC: 1 uncorrectable bitflip(s) at offset 0x00025000
ECC: 1 uncorrectable bitflip(s) at offset 0x00025800
ECC: 1 uncorrectable bitflip(s) at offset 0x00026000
ECC: 1 uncorrectable bitflip(s) at offset 0x00027000
ECC: 1 uncorrectable bitflip(s) at offset 0x00027800
ECC: 1 uncorrectable bitflip(s) at offset 0x00028800
ECC: 1 uncorrectable bitflip(s) at offset 0x00029000
<snip>

There were no bad blocks reported on the device as new.

Is anyone able to use the NAND flash on one of these boards? If so, with what kernel version, and in what manner (r/w JFFS2, ro CRAMFS, etc).

Any other details of what/how I might get this to work, or where the trouble is likely to be, would be much appreciated.

Sincerely,
James.

2008/5/22 James <[email protected]>:

Hi !
I didn't have those kind of problems with the sam9263-ek have you tried to erase the device, mount it with jffs2 or yaffs2, write a file, unmount, mount and read back the file ?

richard.

Hi Richard,

Yup. I have used the examples from linux4sam.org, which use a jffs2 file system.

The NAND flash was erased and root jffs2 image written using the SAM-BA utility, then boot the kernel to use this as its rootfs. It mounts ok to begin with, then I get heaps of jffs2 warnings and finally a kernel bug, I think at fs/jffs2/file.c:251 (I don't have the system here at home.)

What version of kernel, patches and compiler are you using?

I did try briefly with yaffs2, but I don't think the problem is in the file system, more the underlying access to the NAND flash. Maybe in the chip timing, or something. I haven't yet investigated that properly.

Regards,
James.

Hi

How do you create the jffs2 image. Which parameters use with the mtd-utils?
Did you try to start from a ramdisk, erase all, and mount it?

I'm using an at91san9260 board without any problems.

Regards Michael

Hi Michael,

I was using the one supplied from ftp://www.linux4sam.org/pub/oe/deploy/glibc/images/at91sam9263ek/Angstrom-x11-image-demo-glibc.rootfs.jffs2

I built the Angstrom minimal system and tried the resulting jffs2 file system from that too. Same problem.

I did try mkfs.jffs2 on the root file system produced in the Angstrom minimal system build, but the result was the same. I don't recall the precise command line args I used now.

At the moment I've got a USB stick as root, with an ext3 fs on it, and noatime/nodiratime options. At one stage I did erase the whole thing and mount -tjffs2 /dev/mtdblock0 /mnt, writing and reading files died there soon too.

What kernel, patches and tool chain are you using?

Regards,
James.

Hi,

2.6.24.4 + preempt_rt patch
A number recent fix of jffs2 layer and same personal drivers. The gcc version is (generated with build root)

./arm-linux-gcc -v
Using built-in specs.
Target: arm-linux-uclibc
Configured with: /home/michael/buildroot/toolchain_build_arm/gcc-4.2.1/configure --prefix=/usr --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu --target=arm-linux-uclibc --enable-languages=c --with-sysroot=/home/michael/buildroot/build_arm/staging_dir --with-build-time-tools=/home/michael/buildroot/build_arm/staging_dir/usr/arm-linux-uclibc/bin --disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --enable-shared --with-gmp=/home/michael/buildroot/toolchain_build_arm/gmp --with-mpfr=/home/michael/buildroot/toolchain_build_arm/mpfr --disable-nls --enable-threads --disable-multilib --with-tune=arm9tdmi --disable-largefile : (reconfigured) /home/michael/buildroot/toolchain_build_arm/gcc-4.2.1/configure --prefix=/usr --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu --target=arm-linux-uclibc --enable-languages=c --with-sysroot=/opt/crosstools --with-build-time-tools=/opt/crosstools/usr/arm-linux-uclibc/bin --disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --enable-shared --with-gmp=/home/michael/buildroot/toolchain_build_arm/gmp --with-mpfr=/home/michael/buildroot/toolchain_build_arm/mpfr --disable-nls --enable-threads --disable-multilib --with-tune=arm9tdmi --disable-largefile Thread model: posix
gcc version 4.2.1

Michael

Hi,

2.6.24.4 + preempt_rt patch
A number recent fix of jffs2 layer and same personal drivers. The gcc version is (generated with build root)

./arm-linux-gcc -v
Using built-in specs.
Target: arm-linux-uclibc
Configured with: /home/michael/buildroot/toolchain_build_arm/gcc-4.2.1/configure --prefix=/usr --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu --target=arm-linux-uclibc --enable-languages=c --with-sysroot=/home/michael/buildroot/build_arm/staging_dir --with-build-time-tools=/home/michael/buildroot/build_arm/staging_dir/usr/arm-linux-uclibc/bin --disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --enable-shared --with-gmp=/home/michael/buildroot/toolchain_build_arm/gmp --with-mpfr=/home/michael/buildroot/toolchain_build_arm/mpfr --disable-nls --enable-threads --disable-multilib --with-tune=arm9tdmi --disable-largefile : (reconfigured) /home/michael/buildroot/toolchain_build_arm/gcc-4.2.1/configure --prefix=/usr --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu --target=arm-linux-uclibc --enable-languages=c --with-sysroot=/opt/crosstools --with-build-time-tools=/opt/crosstools/usr/arm-linux-uclibc/bin --disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --enable-shared --with-gmp=/home/michael/buildroot/toolchain_build_arm/gmp --with-mpfr=/home/michael/buildroot/toolchain_build_arm/mpfr --disable-nls --enable-threads --disable-multilib --with-tune=arm9tdmi --disable-largefile Thread model: posix
gcc version 4.2.1

Michael

Hi,

2.6.24.4 + preempt_rt patch
A number recent fix of jffs2 layer and same personal drivers. The gcc version is (generated with build root)

./arm-linux-gcc -v
Using built-in specs.
Target: arm-linux-uclibc
Configured with: /home/michael/buildroot/toolchain_build_arm/gcc-4.2.1/configure --prefix=/usr --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu --target=arm-linux-uclibc --enable-languages=c --with-sysroot=/home/michael/buildroot/build_arm/staging_dir --with-build-time-tools=/home/michael/buildroot/build_arm/staging_dir/usr/arm-linux-uclibc/bin --disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --enable-shared --with-gmp=/home/michael/buildroot/toolchain_build_arm/gmp --with-mpfr=/home/michael/buildroot/toolchain_build_arm/mpfr --disable-nls --enable-threads --disable-multilib --with-tune=arm9tdmi --disable-largefile : (reconfigured) /home/michael/buildroot/toolchain_build_arm/gcc-4.2.1/configure --prefix=/usr --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu --target=arm-linux-uclibc --enable-languages=c --with-sysroot=/opt/crosstools --with-build-time-tools=/opt/crosstools/usr/arm-linux-uclibc/bin --disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --enable-shared --with-gmp=/home/michael/buildroot/toolchain_build_arm/gmp --with-mpfr=/home/michael/buildroot/toolchain_build_arm/mpfr --disable-nls --enable-threads --disable-multilib --with-tune=arm9tdmi --disable-largefile Thread model: posix
gcc version 4.2.1

Michael

http://www.codesourcery.com/public/gnu_toolchain/arm-none-linux-gnueabi/arm-2007q1-10-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

is what I'm using, again recommended by linux4sam.org. It is GCC 4.2 based, for glibc. I would have guess this to be fine.

James.

2008/5/23 James <[email protected]>:

ok, so, that's weird...

it was 2.6.24 with at91 patchset (
http://maxim.org.za/AT91RM9200/2.6/2.6.24-at91.patch.gz ) (beware to choose software ECC in at91 nand ecc kernel option if you want to be sam-ba compatible)

Tell me about it. It's driving me nuts.

Ok. I'm on 2.6.24 + patches from linux4sam.org.

Yep, and U-boot is soft ECC too.

What tool chain are you using?

Regards,
James.

2008/5/23 James <[email protected]>:

i think it was buildroot + gcc3.4.6 and glib2.3.2, but i'm not sure.

I agree with Alessandro, don't rely to much on sam-ba for nand writing. That's why I asked you to do the test from linux (erase/mount/write/read)

Ok. Thanks. I'll try again on Monday, method as you suggest. Although this doesn't explain why the tests (flasherase/nandtest/flasherase/nandwrite/nanddump) failed. I'm not very sure of the test applications use though.

Regards,
James.

Hi,

I'm agree too, but my customers use sam-ba to write (linux, u-boot and jffs2 filesystem) without problems.

Regards
Michael

root@at91sam9263ek:~/mtd-tools$ ./flash_eraseall -j /dev/mtd0
Erasing 128 Kibyte @ 3ee0000 -- 99 % complete. Cleanmarker written at
3ee0000.
root@at91sam9263ek:~/mtd-tools$ mount -t
jffs2 /dev/mtdblock0  /mnt/nand/
mtd->read(0x400 bytes from 0xa00000) returned ECC error
mtd->read(0x400 bytes from 0xdc0000) returned ECC error
mtd->read(0x400 bytes from 0xfa0000) returned ECC error
mtd->read(0x400 bytes from 0x13e0000) returned ECC error
mtd->read(0x400 bytes from 0x2000000) returned ECC error
mtd->read(0x400 bytes from 0x20e0000) returned ECC error
mtd->read(0x400 bytes from 0x2680000) returned ECC error
mtd->read(0x400 bytes from 0x2fc0000) returned ECC error
mtd->read(0x400 bytes from 0x3540000) returned ECC error
mtd->read(0x400 bytes from 0x3820000) returned ECC error
root@at91sam9263ek:~/mtd-tools$ umount /mnt/nand/

Then I tried this;

root@at91sam9263ek:~/mtd-tools$ ./nandwrite -a /dev/mtd0 ./fs.jffs2 
Writing data to block 0
Writing data to block 20000
Writing data to block 40000
<snip>
root@at91sam9263ek:~/mtd-tools$ mount -t
jffs2 /dev/mtdblock0  /mnt/nand/
mtd->read(0x1fc0c bytes from 0x3f4) returned ECC error
mtd->read(0x800 bytes from 0x3f800) returned ECC error
mtd->read(0x1f6d4 bytes from 0x2092c) returned ECC error
mtd->read(0x1f7dc bytes from 0x40824) returned ECC error
jffs2_scan_inode_node(): CRC failed on node at 0x0005b020: Read
0x31199cbf, calculated 0x81b0002e
mtd->read(0x1fbf0 bytes from 0x60410) returned ECC error
jffs2_scan_inode_node(): CRC failed on node at 0x00060a4c: Read
0x2072000c, calculated 0x207200ff
mtd->read(0x1f6d8 bytes from 0x80928) returned ECC error
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00094c88:
0x578a instead

<big snip - lots more>

Hardware failures? Or have I not used the tools correctly?

Regards,
James.

well, I would say hardware failure, as far as we all used this board without any problem.
Maybe a last test to be sure :
flash_eraseall /dev/mtd0
dd if=/dev/zero bs=2K count=1 of=/dev/mtd0
nanddump -p -l2048 /dev/mtd0

(try to write a page and read it back).

if you can post this dump, I'm curious...

richard.

Hi Richard,

It's good to know the problem is (hopefully) isolated. After the test below, I feel it might be more than just a hardware failure though.

root@at91sam9263ek:~/mtd-tools$ ./flash_eraseall /dev/mtd0
Erasing 128 Kibyte @ 3ee0000 -- 99 % complete.
root@at91sam9263ek:~/mtd-tools$ dd if=/dev/zero bs=2k count=1
of=/dev/mtd0
1+0 records in
1+0 records out
root@at91sam9263ek:~/mtd-tools$ ./nanddump -p -l2048 /dev/mtd0
ECC failed: 0
ECC corrected: 0
Number of bad blocks: 0
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00000800...
0x00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
<skip all zeros>
0x000007e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000007f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
  OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
  OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
  OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

Hmm. So I tried a block that previously had problems with mount.

root@at91sam9263ek:~/mtd-tools$ dd if=/dev/zero bs=2k count=1 seek=5120
of=/dev/mtd0    
1+0 records in
1+0 records out
root@at91sam9263ek:~/mtd-tools$ ./nanddump -p -l2048
-s0xa00000 /dev/mtd0
ECC failed: 0
ECC corrected: 0
Number of bad blocks: 0
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00a00000 and ending at 0x00a00800...
0x00a00000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00a00010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00a00020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
<snip all zeros>
0x00a007e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00a007f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
  OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
  OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
  OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

And an unwritten to page...

root@at91sam9263ek:~/mtd-tools$ ./nanddump -p -l2048
-s0xdc0000 /dev/mtd0
ECC failed: 0
ECC corrected: 0
Number of bad blocks: 0
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00dc0000 and ending at 0x00dc0800...
0x00dc0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00dc0010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00dc0020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
<snip all 0xff>

So, a page at a time seems ok?

I wonder, what markings are on your CPU and NAND flash? I have; AT91SAM9263 CU-ES 0747 8 QH59R.07
0742 29F2G08AAC WP C LJK6

I assume some of this will be a batch code, but I wonder if there's been a die shrink that's caused some marginal timing issue?

Regards,
James.

yes, all those writings are ok, maybe you can try with if=/dev/urandom, just to see if the OOB region is updated

well, I don't know I haven't got the board any more.

root@at91sam9263ek:~/mtd-tools$ ./flash_eraseall /dev/mtd0
Erasing 128 Kibyte @ 3ee0000 -- 99 % complete.
root@at91sam9263ek:~/mtd-tools$ dd if=/dev/urandom bs=2k count=1
of=/dev/mtd0
1+0 records in
1+0 records out
root@at91sam9263ek:~/mtd-tools$ nanddump -p -l2048 /dev/mtd0
ECC failed: 0
ECC corrected: 0
Number of bad blocks: 0
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00000800...
0x00000000: b6 3c bb 90 16 c3 16 63 ab 8a b4 9f f3 bb 22 49
0x00000010: 42 9d 48 09 4c 35 f1 51 ec 3d e6 cd 3c f0 c7 87
<snip>
0x000007e0: 9f e4 a6 a7 47 35 5b be 12 3e 36 f6 f5 ef e5 5a
0x000007f0: 5b 3e bd 51 27 37 18 cc ab d8 e3 f7 36 09 c2 31
  OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
  OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
  OOB Data: ff ff ff ff ff ff ff ff 0c 0f 0f ff cf 0f ff 30
  OOB Data: 0f 95 aa 97 c0 c0 ff 59 69 ab 3f 0c cf 65 9a a7

So some OOB data is written.

I don't know what to expect really. I have soft ECC enabled, and after reading a bit of the kernel mtdnand documentation, this appears normal.

So, do you think this is a hardware timing issue? Maybe back to back writes/reads?

Regards,
James.

Just out of interest, I did the same over 10 pages.

$ ./flash_eraseall /dev/mtd0
$ dd if=/dev/urandom bs=2k count=10 of=/dev/mtd0
$ nanddump -p -l20480 /dev/mtd0 1> /dev/null
ECC failed: 3
ECC corrected: 0
Number of bad blocks: 0
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00005000...
ECC: 1 uncorrectable bitflip(s) at offset 0x00003800

Foobar!

Regards,
James.

ok, so this must be a hardware problem...

richard.

I've emailed Atmel. I suspect a chip has undergone a dies shrink and now there's a timing spec that's violated, unless I've got 2-3 boards all with the same hardware problem.

I'll look through the EBI timing setup and the chip requirements when I get another moment.

Thanks for your help in the diagnosis. It was good just to know that others are using this without such problems.

Regards,
James.

No response yet from Atmel.

I made the chip timing excessively long/slow and the problems seem to have disappeared!

At the moment I have..
(arch/arm/mach-at91/at91sam9263_devices.c)

        /* set the bus interface characteristics */
        at91_sys_write(AT91_SMC_SETUP(3),
                        AT91_SMC_NWESETUP_(0x1f)
                        | AT91_SMC_NCS_WRSETUP_(0x10)
                        | AT91_SMC_NRDSETUP_(0x1f)
                        | AT91_SMC_NCS_RDSETUP_(0x10));

        at91_sys_write(AT91_SMC_PULSE(3),
                        AT91_SMC_NWEPULSE_(0x1f)
                        | AT91_SMC_NCS_WRPULSE_(0x3f)
                        | AT91_SMC_NRDPULSE_(0x1f)
                        | AT91_SMC_NCS_RDPULSE_(0x3f));

        at91_sys_write(AT91_SMC_CYCLE(3),
                        AT91_SMC_NWECYCLE_(0x7f)
                        | AT91_SMC_NRDCYCLE_(0x7f));

        if (data->bus_width_16)
                mode = AT91_SMC_DBW_16;
        else
                mode = AT91_SMC_DBW_8;

        at91_sys_write(AT91_SMC_MODE(3),
                        mode | AT91_SMC_READMODE
                        | AT91_SMC_WRITEMODE
                        | AT91_SMC_EXNWMODE_DISABLE
                        | AT91_SMC_TDF_(15));

which makes access times pretty slow - but seems reliable. I'll need to learn more about the NAND chip timing requirements before refining these to something more sensible.

Regards,
James.

This is likely the source of problems. The crc layout used by sam-ba may well be different from what mtd uses.

I had tons of problems with the 9260 when programming the nand flash from sam-ba, and I only programmed u-boot (writing all the rest from u-boot or linux). I never had problem with 9263-ek, as long as I didn't write linux stuff from sam-ba.

So you should only write the boot code with sam-ba, and write your kernel and filesystem from either u-boot or linux. You'll probably want to erase and re-program the boot loader from itself, to get rid of remaining wrong sam-ba bits.

hope this helps
/alessandro

Hi Alessandro,

I can try this again on Monday, but I did try erasing the NAND and mounting it as jffs2 under linux, and it still went belly up after a short while. This was with an ext3 root fs on a USB stick.

Regards,
James.

Oh, and what tool chain are you using?

Regards,
James.

eldk-4.1-arm-glibc . the kernel is 2.6.24 like Richard Genoud uses, and 2.6.21 (with maxim.org.za patches) in an older project.

I suspect you have hardware problems on the device, like the nand chip has some bad contacs. I would refresh them with a soldering iron, just to be sure, despite the size.

/alessandro

Hmm - no one seems to use the codesourcery tools.

Can do on Monday. Thanks.

Regards,
James.