Hi Robert,
Thanks for the reply. Here is the status of each of my issues. I think Issues 1,2,4 of mine are simple compilation issues that should still be fixed and for issues 3,5 I tried to explain them better to make sure wasn't doing anything wrong. 

For Issue 4: 
----------------------------
Thanks for finding that previous submission, I didn't see it was already posted. Looks like it is still unfixed - how/when will this be implemented? I'd like to fix this for others if possible. 

For Issue 1:
----------------------------
I don't think you have the compilation error for my "issue 1" regarding the zero_user_segment(...) function because of the "#if" before that checks the linux kernel version. Compilation for the zero_user_segment(...) only happens if the kernel version is less than version 2,6,25. My kernel is before this and yours is after that, which is why I see the issue and you don't. I'm guessing if you remove the #if around the zero_user_segment(...), your yaffs won't compile - just as a double check if you really wanted to.  Either way, the function zero_user_segment(...) should still be moved above where it is used in yaffs_vfs.c.

For Issue 2:
----------------------------
Similar to Issue #1, I don't think you saw this issue because of the "#if (LINUX_VERSION_CODE > KERNEL_VERSION(2, 6, 28))" surrounding the macro. Again, your linux kernel version is greater than the checked version, while mine is less. This is why lowering the Kernel Version check from 2,6,28 to 2,6,17 allows for my kernel version to compile, while yours and probably most every other user's kernel compiles fine. 

It looks like issues 1 and 2 for me are from using a really old kernel version that probably doesn't get tested much. I believe the version I'm using (2.6.18), should be supported right, or is there a minimum kernel version I am unaware of?

Issue 3:
-----------------------------
Thanks - I didn't see the mounting option for ecc tags that seems to work too. I was merely concerned that changing my menuconfig options didn't actually do anything regarding the no_tags_ecc. It was just really misleading to change an option in the menuconfig that doesn't actually do anything. If passing a flag in during mount is the standard way to do this, I'd like to see the "Disable yaffs from doing ECC on tags by default" kernel option removed from the menuconfig as it doesn't do anything (or at least it doesn't for me...). Otherwise, adding my fix allows for the menuconfig option to be checked and used. 

What happens if you don't use the mount option, then try and change the menuconfig option for Ecc on tags? I'd be curious to see if the value of your "param0>no_tags_ecc" properly changes with the menuconfig option. Adding a printk in yaffs_vfs.c in function yaffs_internal_read_super(...), on approx. line 2870, right above where the tags are checked: "if (options.tags_ecc_overridden)".

Issue 5: 
-----------------------------
I'll just disable this auto checking for my use - doesn't sound like this is an issue for other people. For updating my system, updating the kernel causes the FileSystem to become unbootable because yaffs code does an auto-check and says inband tags should be on, which is fine. The problem happens when the FileSystem that is currently installed on the device does not have inband tags, then on the next power-cycle yaffs assumes in-band tags should be on when they aren't. Then the format of the FileSystem is out of sync / wrong with the configuration. Hopefully that makes sense? This is just a problem from going from an old to new version of yaffs where the inband tags option changes. If I do a fresh install of the FileSystem, there is no issue as the FileSystem is written with the tags and is assumed to have them enabled too. 


-

Sean Seifert
EMBEDDED SOFTWARE ENGINEER

Appareo Systems, LLC
1810 NDSU Research Circle N
Fargo ND
58102

P: (701) 356-2200 Ext 349
F: (701) 356-3157
sseifert@appareo.com

NOTICE: This message {including attachments} is covered by the Electronic Communication Privacy Act, 18 U.S.C. sections 2510-2521, is confidential and may also be protected by attorney-client or other privilege. If you believe that it has been sent to you in error, do not read it. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error and then delete it.


On Tue, Oct 28, 2014 at 2:50 PM, Robert Calhoun <rcalhoun@shotspotter.com> wrote:
(My apologies if you receive this twice; I sent from the wrong account)

From: Sean Seifert <sseifert@appareo.com>
Date: 22 Oct 2014 6:26 PM
To: "yaffs@lists.aleph1.co.uk" <yaffs@lists.aleph1.co.uk>
Subject: [Yaffs] Current Yaffs2 Compilation Bugs with Some Fixes

(...)

Issue 4 (w/ fix):
------------------------------------------------------------------------------------------------------
Compilation broke on commit: 30f956c32c235e6b5fa77fb29965ababbd497561, Jul 22, 2014. Not all functions were updated for the new discard parameter. Here are the following that have been missed that discard parameter:
fs/yaffs2/yaffs_vfs.c:2205: error: too few arguments to function ‘yaffs_flush_whole_cache’
fs/yaffs2/yaffs_vfs.c:751: error: too few arguments to function ‘yaffs_flush_file’
fs/yaffs2/yaffs_vfs.c:781: error: too few arguments to function ‘yaffs_flush_file’
fs/yaffs2/yaffs_vfs.c:2192: error: too few arguments to function ‘yaffs_flush_file’

Simply adding the extra discard parameter to these functions makes compilation work. What is the proper number to pass to each? I added a "1" to each for the sake of getting this compiling in my code, but want to make sure that the correct parameter gets passed into the functions. 
(...)


I can reproduce Sean Seifert's issue #4, also reported by wikimfw@lotte.net in September.

I am also compiling an updated version of yaffs on an older kernel (2.6.34) following our discovery of very severe data corruption issues traced to the obsolete version of yaffs we were using (99c62e39578113a798483b5dc6c13a80737163f1 on branch yaffs2, from March 2010.) Thank you to William Juul for his help in diagnosing this!

Like Sean Seifert I could not get yaffs master HEAD to compile due the inconsistent definitions of yaffs_flush_file() in yaffs_guts and yaffs_vfs.

Rather than modify the source I rolled back to the commit before the new cache policy changes (to 4e188b08c5531f99f73383a85251e03a1e667b26, "Update to support Linux 3.14/3.15") and was able to successfully build using that tree. We are now testing that build for deployment.


Question for Charles Manning/branch maintainers: Is there some release branch we should be using in lieu of integrating branch master at an arbitrary commit? Master seems like a work in progress at the moment.


re: Sean Seifert's issues 1 and 2:
I did not encounter these with kernel 2.6.34 and an (old-ish) version of gcc (4.4.7).

re: Sean Seifert's issues 3 and 5:
Sean, if I read your email correctly you have a yaffs2 system with out-of-band tags and no yaffs ECC on those tags.

Our defconfig (old and new) use the default (do not disable tag ECC) i.e.
  # CONFIG_YAFFS_DISABLE_TAGS_ECC is not set
so we did not encounter this problem.

The Kconfig documentation says "This behavior can also be overridden with tags_ecc_on and tags_ecc_off mount options" so you may be able to compile with ECC tags on but then disable tag ECC at runtime with your kernel command line mount argument and still mount your filesystem.

Based on /proc/yaffs we are using out-of-band area for tags. It is probably desirable to to have YAFFS do ECC on the tags, because in many flash devices the OOB area is not entirely protected by ECC. For example we use Micron MT29F2G16ABBEAHC, which I believe is a typical SLC NAND device. It has 16 OOB bytes (2 bytes bad block marker, 8 bytes ECC parity, 6 bytes "user data") for each 512 byte partial page, so a full 2048-byte page has 6 * 4 = 24 user bytes, which are not fully protected by ECC using either the on-chip correction or (SoC controller + MTD driver). I assume this is why YAFFS does tag ECC by default on OOB tags even when the user data is protected at the MTD layer and below.

I find the whole use of OOB a bit difficult to follow. yaffs_packed_tags2 seems to comprise (4 x uint32) of tag data plus (uint8, uint32, unit32) of ECC data for a total of 25 bytes, one byte more than space available for user data. Clearly there is something I am not understanding here.

Anyway, we are using the following defconfig:

CONFIG_YAFFS_FS=y
CONFIG_YAFFS_YAFFS1=y
# CONFIG_YAFFS_9BYTE_TAGS is not set
# CONFIG_YAFFS_DOES_ECC is not set
CONFIG_YAFFS_YAFFS2=y
CONFIG_YAFFS_AUTO_YAFFS2=y
# CONFIG_YAFFS_DISABLE_TAGS_ECC is not set
CONFIG_YAFFS_ALWAYS_CHECK_CHUNK_ERASED=y
# CONFIG_YAFFS_EMPTY_LOST_AND_FOUND is not set
# CONFIG_YAFFS_DISABLE_BLOCK_REFRESHING is not set
# CONFIG_YAFFS_DISABLE_BACKGROUND is not set
# CONFIG_YAFFS_DISABLE_BAD_BLOCK_MARKING is not set
CONFIG_YAFFS_XATTR=y

and are able to read our existing filesystem without issues. These are all defaults set by patch-ker.sh for 2.6.34 except for CONFIG_YAFFS_ALWAYS_CHECK_CHUNK_ERASED, which I carried forward from our old defconfig.


-Rob Calhoun


_______________________________________________
yaffs mailing list
yaffs@lists.aleph1.co.uk
http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs