NAND flash mounting problem

Haavard Skinnemoen hskinnemoen at atmel.com
Wed Feb 28 11:06:48 EST 2007


On Wed, 28 Feb 2007 17:17:18 +0200
"J. Doo" <doodiexx at 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




More information about the linux-mtd mailing list