NAND flash mounting problem

NAND flash mounting problem

[doodiexx doodiexx]

Hi,

We are using Atmel's AT32AP7000 processor and ST 512Mbit NAND Flash
and having problems in creating a JFFS2 fs.

The mtd system detects the flash and I think everything is fine with
the kernel startup:

NAND device: Manufacturer ID: 0x20, Chip ID: 0x76 (ST Micro NAND 64MiB
3,3V 8-bit)
Scanning device for bad blocks
Bad eraseblock 2995 at 0x02ecc000
Bad eraseblock 4078 at 0x03fb8000
Creating 1 MTD partitions on "NAND 64MiB 3,3V 8-bit":
0x00000000-0x04000000 : "rootfs"

I try to flash_eraseall -j and it completes without any error, but
when I try to mount it I get :
# mount /dev/mtd1 /mnt/nand
mount: mounting /dev/mtd1 on /mnt/nand failed

nanddump gives:

# ./nanddump -l 512 -p /dev/mtd1
Block size 16384, page size 512, OOB size 16
Dumping data starting at 0x00000000 and ending at 0x00000200...
0x00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
<skipping.., all values are ff >
0x000001f0: 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 19 85 20 03 00 00 00 08

The 1985 and 2003 parts seem to be wrong endian ??

Any ideas to solve the problem ?

The processor is big endian,
kernel version 2.6.18
flash_eraseall is from the git repo at git.infradead.org/mtd-utils.git
busybox version is the latest (1.4.1)

BR,
J.Doo

Re: NAND flash mounting problem

[Indrek Kruusa]

Ühel kenal päeval (kolmapäev 28 veebruar 2007 9:52 am) kirjutas doodiexx 
doodiexx:
> Hi,
>
> We are using Atmel's AT32AP7000 processor and ST 512Mbit NAND Flash
> and having problems in creating a JFFS2 fs.
>
> The mtd system detects the flash and I think everything is fine with
> the kernel startup:
>
> NAND device: Manufacturer ID: 0x20, Chip ID: 0x76 (ST Micro NAND 64MiB
> 3,3V 8-bit)
> Scanning device for bad blocks
> Bad eraseblock 2995 at 0x02ecc000
> Bad eraseblock 4078 at 0x03fb8000
> Creating 1 MTD partitions on "NAND 64MiB 3,3V 8-bit":
> 0x00000000-0x04000000 : "rootfs"
>
> I try to flash_eraseall -j and it completes without any error, but
> when I try to mount it I get :
> # mount /dev/mtd1 /mnt/nand
> mount: mounting /dev/mtd1 on /mnt/nand failed

Is it busybox? The error message is not too verbose. I suppose you missed -t 
jffs2 here. This and other nice hints can be found:

http://linux-mtd.infradead.org/faq/jffs2.html

cheers,
Indrek



>
> nanddump gives:
>
> # ./nanddump -l 512 -p /dev/mtd1
> Block size 16384, page size 512, OOB size 16
> Dumping data starting at 0x00000000 and ending at 0x00000200...
> 0x00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> <skipping.., all values are ff >
> 0x000001f0: 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 19 85 20 03 00 00 00 08
>
> The 1985 and 2003 parts seem to be wrong endian ??
>
> Any ideas to solve the problem ?
>
> The processor is big endian,
> kernel version 2.6.18
> flash_eraseall is from the git repo at git.infradead.org/mtd-utils.git
> busybox version is the latest (1.4.1)
>
> BR,
> J.Doo
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: NAND flash mounting problem

[Haavard Skinnemoen]

On Wed, 28 Feb 2007 09:52:21 +0200
"doodiexx doodiexx" <doodiexx@gmail.com> wrote:

> Hi,
> 
> We are using Atmel's AT32AP7000 processor and ST 512Mbit NAND Flash
> and having problems in creating a JFFS2 fs.

Interesting :-)

> The mtd system detects the flash and I think everything is fine with
> the kernel startup:
> 
> NAND device: Manufacturer ID: 0x20, Chip ID: 0x76 (ST Micro NAND 64MiB
> 3,3V 8-bit)
> Scanning device for bad blocks
> Bad eraseblock 2995 at 0x02ecc000
> Bad eraseblock 4078 at 0x03fb8000
> Creating 1 MTD partitions on "NAND 64MiB 3,3V 8-bit":
> 0x00000000-0x04000000 : "rootfs"
> 
> I try to flash_eraseall -j and it completes without any error, but
> when I try to mount it I get :
> # mount /dev/mtd1 /mnt/nand
> mount: mounting /dev/mtd1 on /mnt/nand failed
> 
> nanddump gives:
> 
> # ./nanddump -l 512 -p /dev/mtd1
> Block size 16384, page size 512, OOB size 16
> Dumping data starting at 0x00000000 and ending at 0x00000200...
> 0x00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> <skipping.., all values are ff >
> 0x000001f0: 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 19 85 20 03 00 00 00 08
> 
> The 1985 and 2003 parts seem to be wrong endian ??

What are the expected values?

> Any ideas to solve the problem ?

I suspect there may be something funny going on with the avr32 I/O
accessors, although I don't know the mtd nand code well enough to know
more specifically what the problem might be in this case...

Did you write the NAND setup code yourself? If so, could you send me a
patch so that I know how things are set up?

> The processor is big endian,
> kernel version 2.6.18

Did you apply the Atmel BSP patches or something else? AVR32 isn't
supported in plain 2.6.18.

Haavard

Re: NAND flash mounting problem

[J. Doo]

> > I try to flash_eraseall -j and it completes without any error, but
> > when I try to mount it I get :
> > # mount /dev/mtd1 /mnt/nand
> > mount: mounting /dev/mtd1 on /mnt/nand failed
>
> Is it busybox? The error message is not too verbose. I suppose you missed -t
> jffs2 here. This and other nice hints can be found:
>
No, I've also tried that, but it doesn't make any difference.

BR,
J.Doo

Re: NAND flash mounting problem

[J. Doo]

> > # ./nanddump -l 512 -p /dev/mtd1
> > Block size 16384, page size 512, OOB size 16
> > Dumping data starting at 0x00000000 and ending at 0x00000200...
> > 0x00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > <skipping.., all values are ff >
> > 0x000001f0: 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 19 85 20 03 00 00 00 08
> >
> > The 1985 and 2003 parts seem to be wrong endian ??
>
> What are the expected values?

According to the second table in
http://www.linux-mtd.infradead.org/faq/nand.html#L_nand_bootloader
It should be 85 19 03 20 ...

> I suspect there may be something funny going on with the avr32 I/O
> accessors, although I don't know the mtd nand code well enough to know
> more specifically what the problem might be in this case...

I don't think it's because of avr32 i/o, because I have added some
printf's in flash_eraseall to see the buffer to be written to flash
and it's the same, i.e. wrong order.

So I just wanted to have people's opinion before digging the source code.

>
> Did you write the NAND setup code yourself? If so, could you send me a
> patch so that I know how things are set up?

I ported it based on the nand code for at91, it's very basic, just
handles the ALE and CLE lines and chip select...

I'll try to send you a patch later today.

>
> > The processor is big endian,
> > kernel version 2.6.18
>
> Did you apply the Atmel BSP patches or something else? AVR32 isn't
> supported in plain 2.6.18.

Using Atmel's BSP patches.

BR,
J.Doo

Re: NAND flash mounting problem

[J. Doo]

> Is it busybox? The error message is not too verbose. I suppose you missed -t
> jffs2 here. This and other nice hints can be found:

And forgot to answer your first question,
yes it's busybox 1.4.1

BR,
J.Doo

Re: NAND flash mounting problem

[Haavard Skinnemoen]

On Wed, 28 Feb 2007 17:17:18 +0200
"J. Doo" <doodiexx@gmail.com> wrote:

> > > # ./nanddump -l 512 -p /dev/mtd1
> > > Block size 16384, page size 512, OOB size 16
> > > Dumping data starting at 0x00000000 and ending at 0x00000200...
> > > 0x00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > > <skipping.., all values are ff >
> > > 0x000001f0: 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 19 85 20 03 00 00 00 08
> > >
> > > The 1985 and 2003 parts seem to be wrong endian ??
> >
> > What are the expected values?
> 
> According to the second table in
> http://www.linux-mtd.infradead.org/faq/nand.html#L_nand_bootloader
> It should be 85 19 03 20 ...

I had a look inside flash_eraseall, and it seems like it converts
the 16-bit magic values to target_endian, which is by default the CPU's
native endian. So 0x1985 becomes 0x19, 0x85 and 0x2003 becomes 0x20,
0x03 on a big endian CPU. The values you read are therefore correct as
far as I can tell, but of course, I could be missing something...

> > I suspect there may be something funny going on with the avr32 I/O
> > accessors, although I don't know the mtd nand code well enough to know
> > more specifically what the problem might be in this case...
> 
> I don't think it's because of avr32 i/o, because I have added some
> printf's in flash_eraseall to see the buffer to be written to flash
> and it's the same, i.e. wrong order.

Ok, the problems I suspect are related to some incorrect mangling of
the least significant address bits, but those aren't supposed to be
wired up to the NAND chip anyway. So I guess the I/O macros are fine.

> > Did you write the NAND setup code yourself? If so, could you send me a
> > patch so that I know how things are set up?
> 
> I ported it based on the nand code for at91, it's very basic, just
> handles the ALE and CLE lines and chip select...

Yeah, it should be fairly straightforward.

> I'll try to send you a patch later today.

Great. I'll have a look at it tomorrow to see if there are any obvious
problems. Please send me your .config too while you're at it.

It's a bit strange that you don't get any error messages from the
kernel before the mount fails though. Enabling MTD debugging might help
of course. Btw, did you check dmesg? If the loglevel is set too low,
you might not see the error messages on the console.

Haavard

Re: NAND flash mounting problem

[J. Doo]

> > According to the second table in
> > http://www.linux-mtd.infradead.org/faq/nand.html#L_nand_bootloader
> > It should be 85 19 03 20 ...
>
> I had a look inside flash_eraseall, and it seems like it converts
> the 16-bit magic values to target_endian, which is by default the CPU's
> native endian. So 0x1985 becomes 0x19, 0x85 and 0x2003 becomes 0x20,
> 0x03 on a big endian CPU. The values you read are therefore correct as
> far as I can tell, but of course, I could be missing something...

In include/mtd/jffs2-user.h, cpu_to_je16 swaps bytes if target_endian
is not equal to __BYTE_ORDER. But this is always false since it's
value is set to __BYTE_ORDER in flash_eraseall. Does that make sense ?


> It's a bit strange that you don't get any error messages from the
> kernel before the mount fails though. Enabling MTD debugging might help
> of course. Btw, did you check dmesg? If the loglevel is set too low,
> you might not see the error messages on the console.

I thought I checked that, but now I see a message in dmesg when I try to mount:

jffs2_get_sb(): dev_name "/dev/mtd1"
jffs2_get_sb(): path_lookup() returned 0, inode 93db1254

mtd debug level is at max (3), jffs2 debug is also set to max (2), but
that's all I see.

I've read somewhere that mount complains if the magic number were
wrong, but I don't see that either.

Anyone, any ideas ?

BR,
J.Doo

Re: NAND flash mounting problem

[Indrek Kruusa]

Ühel kenal päeval (kolmapäev 28 veebruar 2007 5:18 pm) kirjutas J. Doo:
> > Is it busybox? The error message is not too verbose. I suppose you missed
> > -t jffs2 here. This and other nice hints can be found:
>
> And forgot to answer your first question,
> yes it's busybox 1.4.1

My bad - it was explained already in your first post.

Have you tried with "normal" mount binary?

cheers,
Indrek



>
> BR,
> J.Doo
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: NAND flash mounting problem

[Haavard Skinnemoen]

On Wed, 28 Feb 2007 18:24:31 +0200
"J. Doo" <doodiexx@gmail.com> wrote:

> > > According to the second table in
> > > http://www.linux-mtd.infradead.org/faq/nand.html#L_nand_bootloader
> > > It should be 85 19 03 20 ...
> >
> > I had a look inside flash_eraseall, and it seems like it converts
> > the 16-bit magic values to target_endian, which is by default the CPU's
> > native endian. So 0x1985 becomes 0x19, 0x85 and 0x2003 becomes 0x20,
> > 0x03 on a big endian CPU. The values you read are therefore correct as
> > far as I can tell, but of course, I could be missing something...
> 
> In include/mtd/jffs2-user.h, cpu_to_je16 swaps bytes if target_endian
> is not equal to __BYTE_ORDER. But this is always false since it's
> value is set to __BYTE_ORDER in flash_eraseall. Does that make sense ?

Yes. 0x1985 is stored as 0x19, 0x85 on a big endian CPU. Since
cpu_to_je16 doesn't swap the bytes, this is how it will end up being
stored on the flash.

> > It's a bit strange that you don't get any error messages from the
> > kernel before the mount fails though. Enabling MTD debugging might help
> > of course. Btw, did you check dmesg? If the loglevel is set too low,
> > you might not see the error messages on the console.
> 
> I thought I checked that, but now I see a message in dmesg when I try to mount:
> 
> jffs2_get_sb(): dev_name "/dev/mtd1"

Ah, this should be /dev/mtdblock1, not /dev/mtd1. JFFS2 actually checks
if the device is a block device before continuing.

So I suggest you try this command:

mount -tjffs2 /dev/mtdblock1 /mnt/nand

Or, I guess the new way of doing things is either

mount -tjffs2 mtd1 /mnt/nand
or
mount -tjffs2 mtd:rootfs /mnt/nand

Although I've never actually tried that, so I could be wrong.

> jffs2_get_sb(): path_lookup() returned 0, inode 93db1254
> 
> mtd debug level is at max (3), jffs2 debug is also set to max (2), but
> that's all I see.
> 
> I've read somewhere that mount complains if the magic number were
> wrong, but I don't see that either.

I think it gives up very early, so it won't even attempt to read the
flash.

Haavard

Re: NAND flash mounting problem

[J. Doo]

> > jffs2_get_sb(): dev_name "/dev/mtd1"
>
> Ah, this should be /dev/mtdblock1, not /dev/mtd1. JFFS2 actually checks

Yep, that was the problem.
Supplying /dev/mtdblock1 solved it.

I had a few crashes with JFFS2, but it seems working. I have to do
some more tests.

Thanks,