This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: How to incorporate a file system image when building eCos app


Ok, I think I found a bug in mkfs.jffs2.

>> I studied the mkfs.jffs2 documentation and came up with the closest
>> command line I could to achieve a flash image comparable to
>> synthv2.flash. From the above, I need to set the erase block size to
>> 64K and pad out the image to 1MB (total size of main and boot blocks).
>>
>> $ mkfs.jffs2 -r myfs -e 65536 -p 1048576 -o synthv2.flash
>>
>> The result is a synthv2.flash with a size of 65536... Umm, where is my
>> padding??? This essentially means I have a 1 block image.
>
> Hm, maybe mtd-tools version? ...or (I guess) its usage?
>
> % mkfs.jffs2 -V
> mkfs.jffs2: revision 1.60

Yep, I have the same version as you.

> % mkdir -p foo && touch foo/bar
> mkfs.jffs2 --faketime --squash --pad=0x100000 --eraseblock=0x10000 --root foo --output image.jffs2

I noticed here that you used the long version of the options and it
worked for you. My command line is essentially the same above, but I
used the short options. One would think that,

$ mkfs.jffs2 --pad=0x100000 --eraseblock=0x10000 --root foo --output image.jffs2

and

$ mkfs.jffs2 -p 0x100000 -e 0x10000 -r foo -o image.jffs2

would produce the same result. Unfortunatley, NOT. Feel free to confirm.

>> I think I will need to disable boot blocks in the config to get around
>> that part.
>
> Right.

Yes, that was key. After figuring out mkfs.jffs2 wasn't handling the
short options and making this change, I was able to successfully mount
the image and access my files.

>> > Ok, and what's about fs/jffs2 eCos tests?
>
> [snip]
>
>> jffs2_1 and jffs2_2 pass, but jffs2_3 fails (more like, blows up).
> ? ? ? ? ? ? ? ? ? ? ? ? ? ?^^^^^^^^^^^
> ? ? ? ? ? ? ? ? ? ? ? ? ? ?I think some things were misconfigured.

Probably right about the config. Not sure what might be misconfigured though.

>> JFFS2_TEST_DEV="/dev/flash/0/CYGNUM_FS_JFFS2_TEST_OFFSET,CYGNUM_FS_JFFS2_TEST_LENGTH"
>>
>> I verified it in gdb. CYGNUM_FS_JFFS2_TEST_OFFSET and
>> CYGNUM_FS_JFFS2_TEST_LENGTH are not defined _anywhere_ in the ecos
>> tree. Since the image gets mounted successfully in the test, I assume
>> that the offset and length are just ignored if they aren't numbers.
>
> Hm, in a fact default test values should be placed in a component
> CYGPKG_FS_JFFS2_TESTS (like CYGNUM_IO_FLASH_TEST_{OFFSET,LENGTH} are
> placed under CYGPKG_IO_FLASH_TESTS component), but, CYGPKG_FS_JFFS2_TESTS
> is just an option. It seems to me this should be fixed. ?Fortunately,
> it is not issue for the tests on the eCos synthetic target.

Yeah, I see what you mean. Are you interested in a patch?

>> Since the above was working for the test, I got rid of my MTAB_ENTRY
>> and went with using 'mount' EXACTLY as the test did. My image does get
>> mounted, but it complains about the size, since it doesn't match the
>> config parameters.
>
> Config/adjust/sync eCos synthv2 flash parameters via CDL (eCos app)
> and mkfs.jffs2 (host side).
>
>> Snip of error messages:
>>
>> <5>jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at
>> 0x00001838: 0x835a instead
>
> I cannot mount JFFS2 and see "Magic bitmask 0x1985 not found" messages
> ^^^^^^^^^^^^^^^^^^^^
> This is the famous Q (with answers!) from
> http://www.linux-mtd.infradead.org/faq/jffs2.html#L_mkfs_jffs2_comp

The jffs2 error above was because the synthv2.flash image the system
expected should have had a the first flash block reserved for boot
blocks. The image I created with mkfs.jffs2 was only 1 block, so of
course it isn't going to find what it expects at block 2.

>> I am going to try adjusting the config options for the synthetic flash
>> device to get them as close as I can to the output of what mkfs.jffs2
>> is generating, since I can't seem to make it do what it is supposed
>> to.
>>
>> ? ? - CYGNUM_FLASH_SYNTH_V2_NUMBLOCKS=1 (single block)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^^^^^^^^^^^^^^^^ Why ?!

Because I couldn't get mkfs.jffs2 to create an image larger than 1
block with the short options :).

> Just now I ran all 3 jffs2 tests on synthetic target with minimal import
>
> cdl_configuration eCos {
> ? ?template ? ?default ;
> ? ?package CYGPKG_IO_FLASH current ;
> ? ?package CYGPKG_IO_FILEIO current ;
> ? ?package CYGPKG_CRC current ;
> ? ?package CYGPKG_COMPRESS_ZLIB current ;
> ? ?package CYGPKG_LINUX_COMPAT current ;
> ? ?package CYGPKG_FS_JFFS2 current ;
> };
> cdl_option CYGNUM_FLASH_SYNTH_V2_NUMBLOCKS {
> ? ?user_value 256
> };
> cdl_option CYGNUM_FLASH_SYNTH_V2_NUMBOOT_BLOCKS {
> ? ?user_value 0
> };
>
> As you can see I used 10M "flash" without boot blocks.

Hmm, jffs2_3 is now working. I have boot blocks disabled now. That is
the only difference I can think of from my previous attempt.

>> Also, is the synthetic flash big endian or little endian? I haven't
>> seen that documented anywhere yet.
>
> The same as CPU (x86, x86-64 are yours, I hope), so it is little-endian.

Good to know, thanks.


-- 
Mike

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]