Hello If there is a deficiency in u-bot then I suggest discussing this on the u-boot list. The Good News for yaffs u-boot users is that I have a new yaffs2 package - better than the old one - for integrating yaffs2 into u-boot. It is currently under test and is doing all the thinks it should. I expect tomake this available within a week. -- Charles On Wednesday 04 April 2012 21:20:34 BI Mingliang wrote: > 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: 'yaffs@lists.aleph1.co.uk' > 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: yaffs-bounces@lists.aleph1.co.uk > [mailto:yaffs-bounces@lists.aleph1.co.uk] On Behalf Of > yaffs-request@lists.aleph1.co.uk Sent: 2012年3月30日 19:00 > To: yaffs@lists.aleph1.co.uk > Subject: yaffs Digest, Vol 82, Issue 14 > > Send yaffs mailing list submissions to > yaffs@lists.aleph1.co.uk > > 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 > yaffs-request@lists.aleph1.co.uk > > You can reach the person managing the list at > yaffs-owner@lists.aleph1.co.uk > > 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: yaffs@lists.aleph1.co.uk > Subject: Re: [Yaffs] i've another question about yaffs2_scan_chunk? > Message-ID: <201203300655.03863.manningc2@actrix.gen.nz> > 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 > yaffs@lists.aleph1.co.uk > http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs > > > End of yaffs Digest, Vol 82, Issue 14 > ************************************* > _______________________________________________ > yaffs mailing list > yaffs@lists.aleph1.co.uk > http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs