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
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.
(text/plain)