Hi,
I am currently compiling yaffs2 for an older project on kernel 2.6.18 and ran into a few errors when compiling. Below are the issues I have found and how I have fixed some of them. For all of the following issues, I am using the multiple (old support), not single version of yaffs code. If anything doesn't make sense or you'd like more information, please let me know.
Issue 1 (w/ fix):
-------------------------------------------------------------------------------
My Compiler Errors:
fs/yaffs2/yaffs_vfs.c:823: error: static declaration of ‘zero_user_segment’ follows non-static declaration
fs/yaffs2/yaffs_vfs.c:427: error: previous implicit declaration of ‘zero_user_segment’ was here
In the file: yaffs_vfs.c, the function "zero_user_segment(...)" is declared below its usage in the function "yaffs_writepage(...)". The declaration of "zero_user_segment(...)" needs to be moved above where it is used in order for compilation to work. Doing this fixes the issue for me.
Issue 2 (w/ fix):
--------------------------------------------------------------------------------------
My Compiler Error: undefined reference to `__aeabi_uldivmod'.
The error is in the file: yaffs_vfs.c. From what I've gathered, this is due to improper division for my kernel. For compilation to work, I need to change the #if guard around the function declaration to allow my kernel to use the YCALCBLOCKS(...) function. Basically, I just change:
#if (LINUX_VERSION_CODE > KERNEL_VERSION(2, 6, 28))
static uint32_t YCALCBLOCKS(uint64_t partition_size, uint32_t block_size)
...
#endif
change to:
#if (LINUX_VERSION_CODE > KERNEL_VERSION(2, 6, 17))
static uint32_t YCALCBLOCKS(uint64_t partition_size, uint32_t block_size)
...
#endif
noting that the only difference made to this was lowering the kernel version in the #if statement. This might be something odd with my kernel and seems pretty minor, but I figured I'd bring it up in case other people were having this issue.
Issue 3 (w/ fix):
------------------------------------------------------------------------------------------------------
Menuconfig option of not doing ECC on tags functionality was broken or at least changed so that it wasn't working for me. For my kernel, I do a "make menuconfig" and I enable the disabling of doing ecc on tags: "[*] Disable yaffs from doing ECC on tags by default". I'm not exactly sure when this broke in code, but the previous version of yaffs that I was using was working and going forward, something broke.
Anyways, by broken, I mean that no matter what I set in the kernel's menuconfig, the software always has the tags being checked, even though I disabled this. In order to fix this, I have to add the following lines of code in, otherwise, the option from the menuconfig is ignored. Otherwise, if I do not do this, yaffs will assume that my filesystem does have ECC in the tags when it really doesn't, causing the filesystem to not scan and boot properly. I had to add the following code to yaffs_vfs.c, in function yaffs_internal_read_super(...), at line ~2770, just before options.tags_ecc_overridden is checked:
#ifdef CONFIG_YAFFS_DISABLE_TAGS_ECC
param->no_tags_ecc = 1;
printk("\n\n -----setting noTagsECC----- \n\n "); //just for debug to make sure this was getting hit...
#endif
Looking back at the last version of yaffs I was using (a really old version...), this code was still in the code base, but somewhere along the way was removed. Is there a reason for this or is there another way to set this option that I'm missing? How critical is it that ecc is done on the tags? I do not have yaffs doing ecc in my current implementation, that is done by the MTD layer so I figured this option would be unnecessary for me.
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.
Issue 5 (question w/ workaround)
------------------------------------------------------------------------------------------------
The last issue that I'm facing appears to be a "breaking change" - meaning that I cannot update my device's kernel without re-loading my device's filesystem too. The filesystem needs to be re-written by the new kernel with the inband tags option enabled, otherwise if the new kernel looks at an old filesystem without inband tags, and it fails to boot. The auto checking for inband tags feature was added June 26, 2013. Basically, if (mtd->oobavail == 1), then inband tags are set to be used, which on an existing filesystem that is not using inband tags, like mine, this causes the filesystem scan to fail and my device to not be bootable. If I remove the automatic checking for inband tags, then my device boots fine with a new kernel.
Is there some reason why this was added as an automated check when it can potentially cause the filesystem to not be bootable? Are inband tags adding some additional level of robustness that is worth switching to or would not using them be fine? I guess I can get kernel updates to work fine by disabling that autocheck, but it didn't seem right that I had to modify yaffs to do so.
-
Sean Seifert
EMBEDDED SOFTWARE ENGINEER
Appareo Systems, LLC
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.