[Yaffs] bootldr/yaffs2/samosa

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Nick Bane
Date:  
To: Balloon@Balloonboard.Org
CC: Aleph1. Co. Uk Yaffs@Stoneboat.
Subject: [Yaffs] bootldr/yaffs2/samosa
I just updated the bootldr34 source and binaries on the husaberg site for balloon to fix some yaffs2 problems (see below).
I also updated the subversion repository with the 2.4.25 kernel that does the same.
I am somewhat new to subversion and I think I have the structure set up unconventially.
What you need to do is svn co svn://husaberg.toby-churchill.com/linux-2.25/tags/vrs2-tcl1
You can also browse the repository on the web via a viwecvs link.

Charles/Thomas: I note that the latest mtd (a recent cvs snapshot for example) treats reads of the oob differently depending on whether one is reading it raw with nand_read_oob or via nand_read_ecc. This results in the auto placement shifting data around (by 16 bits for 64 byte oob nand chips) if one uses auto placement. As yaffs does a quick raw scan of the oob at boot, the values should not differ from the raw and ecc versions. I was expecting to be able to pass a nand_oobinfo structure to confound this in nand_read_ecc and nand_write_ecc but discover that either the placement is AUTOPLACE (in which case it ignores the rest of the oobinfo and fetches the nand-wide version instead) or is is PLACE in which case one gets a blind copy of eccsteps*sizeof(int) data items instead of eccsteps*3 bytes as I had expected or its a value that isn't used on reading ecc anyway.
The upshot of that previous tangle is that one must have the whole of a nand chip set to a non standard configuration (ie yaffs2) rather than on a per-partition basis. Alternatively I am not understanding it correctly.

Feedback requested.

Nick

-----------------------
Nick Bane

+44 (0)1954 719270
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.7 - Release Date: 09/05/2005