[Yaffs] Uboot not support "nand write.yaffs2" cause the linu…

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: BI Mingliang
Date:  
To: yaffs@lists.aleph1.co.uk
CC: Charles Manning
Subject: [Yaffs] Uboot not support "nand write.yaffs2" cause the linux FS booting failure "Failed to execute /linuxrc. Attempting defaults..."
Hello All,
My former discussion is a misleading in issue "Failed to execute /linuxrc.  Attempting defaults...".
I wrongly use "nand write.yaffs" to program yaffs2 image to 2K page NAND flash.
So, no matter how I change the settings in mkyaffs2image and kernel configuration, I always get the error during the last booting stage: yaffs2 mounting.
It's really a pity that the latest uboot still not support yaffs2 programming. 
We are really expecting some new commands, like "nand write.yaffs2",are added in the upcoming version :)
Best Regards,
Bi Mingliang 
-----Original Message-----
From: BI Mingliang 
Sent: 2012年3月31日 0:08
To: ''
Cc: 'Charles Manning'
Subject: RE: yaffs Digest, Vol 82, Issue 14

Hello All, Charles,
I have several puzzling points in mkyaffs2image.c, which lead its malfunction.
1.A wrong size parameter 0xFFFF is given to write_chunk() in function write_object_header
write_chunk(bytes,obj_id,0,0xffff);   
perhaps it should like this: write_chunk(bytes,obj_id,0,2048);  
 
2.According the following description, we clearly get the 64 bytes layout for yaffs2.
http://www.yaffs.net/yaffs-2-specification-and-development-notes
So, there seems some problems in definition for the following two structures.
1)    unsigned should be changed to a standard u32 in case of 64-bit machine. Although it’s unsigned is defined as u32, but it’s not throughly for a 64-bit machine.
2)    The sequence of seq_number, obj_id, chunk_id and n_bytes is not the same as the description in yaffs offcial link.
3)    n_bytes should be only two bytes before block_sequence, so u16 could be right.
struct yaffs_packed_tags2_tags_only {
    unsigned seq_number;
    unsigned obj_id;
    unsigned chunk_id;
    unsigned n_bytes;
};

3.And for struct yaffs_ecc_other, it seems the 3 bytes tagsECC,so: 
struct yaffs_ecc_other {
    unsigned char col_parity; 
    unsigned line_parity;    

>> unsigned char line_parity

    unsigned line_parity_prime;

>>unsigned char line_parity_prime

};

Offset    Content    Comment
0x00    Bad block marker    If any bit in this byte is zero, then this block is bad. This applies only to the first page in a block. In the remaining pages this byte is reserved
0x01    Reserved    Reserved
0x02-0x27    Autoplace 0 - 37     
0x28    ECC byte 0    Error correction code byte 0 of the first 256 Byte data in this page
0x29    ECC byte 1    Error correction code byte 1 of the first 256 Bytes of data in this page
0x2A    ECC byte 2    Error correction code byte 2 of the first 256 Bytes data in this page
0x2B    ECC byte 3    Error correction code byte 0 of the second 256 Bytes of data in this page
0x2C    ECC byte 4    Error correction code byte 1 of the second 256 Bytes of data in this page
0x2D    ECC byte 5    Error correction code byte 2 of the second 256 Bytes of data in this page
0x2E    ECC byte 6    Error correction code byte 0 of the third 256 Bytes of data in this page
0x2F    ECC byte 7    Error correction code byte 1 of the third 256 Bytes of data in this page
0x30    ECC byte 8    Error correction code byte 2 of the third 256 Bytes of data in this page
0x31    ECC byte 9    Error correction code byte 0 of the fourth 256 Bytes of data in this page
0x32    ECC byte 10    Error correction code byte 1 of the fourth 256 Bytes of data in this page
0x33    ECC byte 11    Error correction code byte 2 of the fourth 256 Bytes of data in this page
0x34    ECC byte 12    Error correction code byte 0 of the fifth 256 Bytes of data in this page
0x35    ECC byte 13    Error correction code byte 1 of the fifth 256 Bytes of data in this page
0x36    ECC byte 14    Error correction code byte 2 of the fifth 256 Bytes of data in this page
0x37    ECC byte 15    Error correction code byte 0 of the sixt 256 Bytes of data in this page
0x38    ECC byte 16    Error correction code byte 1 of the sixt 256 Bytes of data in this page
0x39    ECC byte 17    Error correction code byte 2 of the sixt 256 Bytes of data in this page
0x3A    ECC byte 18    Error correction code byte 0 of the seventh 256 Bytes of data in this page
0x3B    ECC byte 19    Error correction code byte 1 of the seventh 256 Bytes of data in this page
0x3C    ECC byte 20    Error correction code byte 2 of the seventh 256 Bytes of data in this page
0x3D    ECC byte 21    Error correction code byte 0 of the eigth 256 Bytes of data in this page
0x3E    ECC byte 22    Error correction code byte 1 of the eigth 256 Bytes of data in this page
0x3F    ECC byte 23    Error correction code byte 2 of the eigth 256 Bytes of data in this page

Best Regards,
Bi Mingliang 

-----Original Message-----
From:  [mailto:yaffs-bounces@lists.aleph1.co.uk] On Behalf Of 
Sent: 2012年3月30日 19:00
To: 
Subject: yaffs Digest, Vol 82, Issue 14

Send yaffs mailing list submissions to
    

To subscribe or unsubscribe via the World Wide Web, visit
    http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs
or, via email, send a message with subject or body 'help' to
    

You can reach the person managing the list at
    

When replying, please edit your Subject line so it is more specific
than "Re: Contents of yaffs digest..."


Today's Topics:

   1. Re: i've another question about yaffs2_scan_chunk?
      (Charles Manning)


----------------------------------------------------------------------

Message: 1
Date: Fri, 30 Mar 2012 06:55:03 +1300
From: Charles Manning <>
To: 
Subject: Re: [Yaffs] i've another question about yaffs2_scan_chunk?
Message-ID: <>
Content-Type: text/plain;  charset="utf-8"

On Thursday 29 March 2012 13:58:05 Ezio Zhang wrote:

> when start up,yaffs scan every chunk of a block that the summary not
> written.
> when it read the chunk's oob,if it is an empty chunk,the tags it read if
> full of 0xff,so the flag chunk_used should not be 0 and the judgement of
> "if (!tag.chunk_used)" should never enter, am i right?


Erased flash starts off 0xff and can then be changed by setting 1 bits to 0
bits.

If the tags are full of 0xff then chunk_used should be 0.

> so in my understanding ,the function dev->param.read_chunk_tags_fn shoud do
> something rather than copy data from flash?
>
> and when writing data to flash,i cannot skip one or more chunks then write
> another one?


I don't understand quite what you mean here can you give a slightly more
detailed descriprion.

> thansk very much.
> ----
> Regards,
> Ezio.






------------------------------

_______________________________________________
yaffs mailing list

http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs


End of yaffs Digest, Vol 82, Issue 14
*************************************