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

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Charles Manning
Date:  
To: yaffs
Subject: Re: [Yaffs] Uboot not support "nand write.yaffs2" cause the linux FS booting failure "Failed to execute /linuxrc. Attempting defaults..."
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: ''
> 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
> *************************************
> _______________________________________________
> yaffs mailing list
>
> http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs