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 <manningc2@actrix.gen.nz>
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
*************************************
(text/plain)