Re: [Yaffs] function nandmtd1_ReadChunkWithTagsFromNAND in y…

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Ian McDonnell
Date:  
To: embedded technology
CC: yaffs
Subject: Re: [Yaffs] function nandmtd1_ReadChunkWithTagsFromNAND in yaffs_mtdif1.c can't recognise the bad block?
On Tuesday 25 September 2007 14:09, wrote:
>     Thank you! What I change is same to you, but now still has
> some questions, look below:

>
> ---
> /work/embedded_book_source/Development/yaffs2/yaffs_mtdif1.c  
>      2007-07-24 03:14:04.000000000 +0800 +++ yaffs_mtdif1.c   
>   2007-09-25 05:59:29.000000000 +0800 @@ -208,6 +208,9 @@
>         switch (retval) {
>         case 0:
>                 /* no error */
> +               etags->blockBad = (mtd->block_isbad)(mtd,
> addr); +               if (etags->blockBad)
> +                       return YAFFS_FAIL;
>                 break;


No, don't add it to the read function, it will slow down every
read of every page. The test is only needed for each block
during the initial scan. I added the call to the Query function
which is used during the scan.

>     Another question:

>
>         linux 2.6.22.6,
>         yaffs_mtdif1.c's version is : "$Id: yaffs_mtdif1.c,v 1.2
> 2007/07/23 19:14:04 imcd Exp $" Flash Type: 512Byte/Page

>
>     Even for yaffs1, the default nand_ecclayout of yaffs_mtdif1.c
> is: static struct nand_ecclayout nand_oob_16 = {
>                 .eccbytes = 6,
>               .eccpos = {0, 1, 2, 3, 6, 7},
>               .oobfree = {
>                 { .offset = 8,
>                   . length = 8}}
>           };

>
>     But the nand_ecclayout of utils/mkyaffsimage.c is:
>          static struct nand_ecclayout nand_oob_16 = {
>              .eccbytes = 6,
>              .eccpos = { 8, 9, 10, 13, 14, 15 },
>              .oobavail = 9,
>              .oobfree = { { 0, 4 }, { 6, 2 }, { 11, 2 }, { 4, 1 } }
>          };

>
>     They are diffrent, this is the reason my yaffs partition
> can be mount, but can't work: in
> nandmtd1_ReadChunkWithTagsFromNAND, 'retval =
> yaffs_CheckECCOnTags((yaffs_Tags *)&pt1)' is -1, so all blocks
> are treated as 'Empty'.


Yes, MTD changed the built-in/default layout policy between
2.6.17 and 2.6.18. If you want backward compatibility you'll
have to change the layout -- and if you do, try adding it
to the platform NAND mapping code. You will probably find you
also need to replace the call to nand_scan() with two calls:
nand_scan_ident(), then, after you override the default layout
(eg: chip->ecclayout = chip->ecc.layout = &my_nand_layout) call
nand_scan_tail() to finish off.


>     I use the second nand_oob_16 above, configure
> CONFIG_YAFFS_9BYTE_TAGS. And then the system can boot, the
> content in the yaffs root filesystem can be seen.

>
>     The question is: it can't boot next time. After the first
> booting, I do nothing but run 'reset'.


You need to untangle the layout issues. MTD can only really
do one policy for the whole chip - to boot images, bootloaders,
yaffs etc., all have to agree as to the format/layout of
oob/spare.

>     The kernel log at the second booting is:
> VFS: Mounted root (yaffs filesystem).
> Freeing init memory: 124K
> Kernel panic - not syncing: No init found.  Try passing init=
> option to kernel.

>
>     By the way, change the nand_ecclayout seem to be ugly, there
> is another partions on the nand flash, the ECC layout should
> be consistent to another tools, such as U-Boot. Do you have
> some idea? Thank you.


It's a big mess. The user-space tools have a very poor idea of
MTD policies. We need new tools and a better design.

-imcd