[ECOS] How to incorporate a file system image when building eCos app

[ECOS] How to incorporate a file system image when building eCos app

[Michael Bergandi]

Hi all,

I did a bit of searching through the documentation and list archives,
but I haven't come across anything that addresses what I am trying to
do.

Presently, I am doing development of  a package on the Linux synthetic
target. Once I get things working fine there, I will build for my
target hardware. My package has a test program that requires loading
of data from two files. One file has data that will be processed and
afterward, it will be compared with the contents of the other for
verification.

My problem is that I don't know how to get my files into an
appropriate file system image and how to get it built into the eCos
image. If someone has a howto they can point me to or to some other
documentation, it would be greatly appreciated.

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

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

[Edgar Grimberg]

Hi,

On Fri, Feb 11, 2011 at 5:54 PM, Michael Bergandi <mbergandi@gmail.com> wrote:
> Hi all,
>
> I did a bit of searching through the documentation and list archives,
> but I haven't come across anything that addresses what I am trying to
> do.
>
> Presently, I am doing development of  a package on the Linux synthetic
> target. Once I get things working fine there, I will build for my
> target hardware. My package has a test program that requires loading
> of data from two files. One file has data that will be processed and
> afterward, it will be compared with the contents of the other for
> verification.
>
> My problem is that I don't know how to get my files into an
> appropriate file system image and how to get it built into the eCos
> image. If someone has a howto they can point me to or to some other
> documentation, it would be greatly appreciated.

You can mkfs.jffs2 the file system on the host computer:
http://linux.die.net/man/1/mkfs.jffs2
Then you can either copy separately the binary file of the file system
to the target, or you can transform it into a .h file and compile and
link it with your application (assuming the application is a ROM or a
ROMRAM application).

Regards,
Edgar


> 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
>
>

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

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

[Michael Bergandi]

Ok, made some progress.

>> My problem is that I don't know how to get my files into an
>> appropriate file system image and how to get it built into the eCos
>> image. If someone has a howto they can point me to or to some other
>> documentation, it would be greatly appreciated.
>
> You can mkfs.jffs2 the file system on the host computer:
> http://linux.die.net/man/1/mkfs.jffs2
> Then you can either copy separately the binary file of the file system
> to the target, or you can transform it into a .h file and compile and
> link it with your application (assuming the application is a ROM or a
> ROMRAM application).

I made the file system image with:

$ mkfs.jffs2 -r myfs -o myfs.jffs2

where the myfs directory contains the contents of my file system.

$ find myfs -iname "*"
myfs
myfs/test
myfs/test/file1.txt
myfs/test/file2.txt

So, the 'test' directory is at the root of the jffs2 fs image.
Confirmed this by mounting the image on my host.

Then, I converted the jffs2 image to a '.h' to be included in my test
app. I have file2c.tcl script for such purposes.

I build the Linux Synthetic target with the required supporting
packages. In my working directory, where the root of the ecos tree is,
I do the following:

$ mkdir synthbuild
$ cd synthbuild
$ ecosconfig new linux
$ ecosconfig add posix fileio net freebsd_net eth_drivers linux_compat
flash crc jffs2
$ ecosconfig tree
$ make

Everything builds without issue.

The last part is to get the file system image hooked into the test
app. In my test app, I try to make the linkage to the file system
with:

#  include "myfs_jffs2.h"
MTAB_ENTRY( myfs_mte1,
            "/",
            "jffs2",
            "",
            (CYG_ADDRWORD) &myfs_jffs2[0] );

The test builds without any problems. However, when I run it, I get a
'No such entity' error when trying to open the file.

error:02001002:system library:fopen:No such entity:fopen('/test/file1.txt','r')

Any idea what I seem to be missing?

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

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

[Sergei Gavrikov]

Hi Michael,

On Tue, 15 Feb 2011, Michael Bergandi wrote:

> Ok, made some progress.
...
> I made the file system image with:
> 
> $ mkfs.jffs2 -r myfs -o myfs.jffs2
> 
> where the myfs directory contains the contents of my file system.
...
> So, the 'test' directory is at the root of the jffs2 fs image.
> Confirmed this by mounting the image on my host.
> 
> Then, I converted the jffs2 image to a '.h' to be included in my test
> app. I have file2c.tcl script for such purposes.
 
This is trick. The eCos synthetic target provides FLASH I/O support
(see below).

> I build the Linux Synthetic target with the required supporting
> packages. In my working directory, where the root of the ecos tree is,
> I do the following:
> 
> $ mkdir synthbuild
> $ cd synthbuild
> $ ecosconfig new linux
> $ ecosconfig add posix fileio net freebsd_net eth_drivers linux_compat
> flash crc jffs2
  ^^^^^

As you added 'flash' package, the flash parts on the target will be
simulated via regular file (by default its name is 'synthv2.flash') In
fact you can create such file (=flash image) using mkfs.jffs2 with some
additional options (pad size, erase size, etc. for a reference look on
flash defaults in eCos config file).

> $ ecosconfig tree
> $ make
> 
> Everything builds without issue.

Ok, and what's about fs/jffs2 eCos tests?

make -C fs/jffs2/currents tests
./install/tests/fs/jffs2/current/tests/jffs2_1 -mw -io

etc.

Do jffs2 tests pass? If you can see 'synthv2.flash' creates itself on
the first test run. Look on the sources of tests and you will get a tip
how to manage your issue. In two words, Do not use file2c.tcl converter,
and use flash image file. When you port image to real target call about
an endianness.


Sergei

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

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

[Michael Bergandi]

Ok, I think I understand what needs to be done, but it is not working.

>> $ mkdir synthbuild
>> $ cd synthbuild
>> $ ecosconfig new linux
>> $ ecosconfig add posix fileio net freebsd_net eth_drivers linux_compat
>> flash crc jffs2
>  ^^^^^
>
> As you added 'flash' package, the flash parts on the target will be
> simulated via regular file (by default its name is 'synthv2.flash') In
> fact you can create such file (=flash image) using mkfs.jffs2 with some
> additional options (pad size, erase size, etc. for a reference look on
> flash defaults in eCos config file).

Yep, I found 'synthv2.flash' in the eCos config file (ecos.ecc). I
would like to believe that I could create that file on my host, but I
am yet to be successful.

According to the .ecc file:
CYGNUM_FLASH_SYNTH_V2_BLOCKSIZE=65536 (erase block size)
CYGNUM_FLASH_SYNTH_V2_NUMBLOCKS=15
CYGNUM_FLASH_SYNTH_V2_NUMBOOT_BLOCKS=8
CYGNUM_FLASH_SYNTH_V2_BOOT_BLOCKSIZE=8096
CYGNUM_FLASH_SYNTH_V2_BOOT_BLOCK_BOTTOM=1

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.

From the above .ecc options, it would seem that the first (64K) block
is subdivided into 8 smaller boot blocks. I have no way to recreate
that with mkfs.jffs2. I think that this also implies that when the
synthv2.flash created by eCos is mounted, that the first block is
probably not looked at on an fopen().

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

> Ok, and what's about fs/jffs2 eCos tests?
>
> make -C fs/jffs2/currents tests
> ./install/tests/fs/jffs2/current/tests/jffs2_1 -mw -io
>
> etc.
>
> Do jffs2 tests pass? If you can see 'synthv2.flash' creates itself on
> the first test run. Look on the sources of tests and you will get a tip
> how to manage your issue. In two words, Do not use file2c.tcl converter,
> and use flash image file. When you port image to real target call about
> an endianness.

jffs2_1 and jffs2_2 pass, but jffs2_3 fails (more like, blows up).
synthv2.flash does get created when I run jffs2_1.

Yes, I did look over the jffs2 tests. They did provide insight as to
what is going on. The test simply tries to mount the jffs2 file system
on JFFS2_TEST_DEV at "/". During the mount, jffs2 fs code looks for
synthv2.flash. If it is not found, the file is created. One thing that
really bugs me is the JFFS2_TEST_DEV use:

<<fs/jffs2/current/tests/jffs2_1.c>>
# define JFFS2_TEST_DEV "/dev/flash/0/"
stringify(CYGNUM_FS_JFFS2_TEST_OFFSET) ","
stringify(CYGNUM_FS_JFFS2_TEST_LENGTH)

That define evaluates to:

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.

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.

Snip of error messages:

<4>Node at 0x00001830 with length 0x000008f5 would run over the end of
the erase block
<4>Perhaps the file system was created with the wrong erase size?
<5>jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at
0x00001834: 0x08f5 instead
<5>jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at
0x00001838: 0x835a instead

My current state is that I am unable to get the mkfs.jffs2 to produce
an image that jffs2 in eCos will work with.

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)
    - CYGNUM_FLASH_SYNTH_V2_NUMBOOT_BLOCKS=0 (disable boot blocks)

Also, is the synthetic flash big endian or little endian? I haven't
seen that documented anywhere yet.

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

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

[Sergei Gavrikov]

On Wed, 16 Feb 2011, Michael Bergandi wrote:

> Ok, I think I understand what needs to be done, but it is not working.

[snip]

> 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

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

% dd if=image.jffs2 of=/dev/null
2048+0 records in
2048+0 records out
1048576 bytes (1.0 MB) copied, 0.00294158 s, 356 MB/s
^^^^^^^^^^^^^^^^^^^^^
                    | what you wanted

Well, '--faketime' && '--squash' are optional.

TIP: Sometime, I do not use any compression if I use jffs2 on the slow
targets, adding '--compression-mode=none' or '-m none' to command-line,
but this should be no issue for synthetic target.

[snip]

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

Right.

> > 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.

> synthv2.flash does get created when I run jffs2_1.

> Yes, I did look over the jffs2 tests. They did provide insight as to
> what is going on. The test simply tries to mount the jffs2 file system
> on JFFS2_TEST_DEV at "/". During the mount, jffs2 fs code looks for
> synthv2.flash. If it is not found, the file is created. One thing that
> really bugs me is the JFFS2_TEST_DEV use:
> 
> <<fs/jffs2/current/tests/jffs2_1.c>>
> # define JFFS2_TEST_DEV "/dev/flash/0/"
> stringify(CYGNUM_FS_JFFS2_TEST_OFFSET) ","
> stringify(CYGNUM_FS_JFFS2_TEST_LENGTH)
> 
> That define evaluates to:
> 
> 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.

> 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

> My current state is that I am unable to get the mkfs.jffs2 to produce
> an image that jffs2 in eCos will work with.

Try my options (see above).

> 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 ?!

>     - CYGNUM_FLASH_SYNTH_V2_NUMBOOT_BLOCKS=0 (disable boot blocks)
                                               ^^^^^^^^^^^^^^^^^^^^ OK


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.

> 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.

HTH

Sergei

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

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

[Michael Bergandi]

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

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

[Sergei Gavrikov]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1285 bytes --]

Hi Michael,

Michael Bergandi writes:
> Sergei Garikov wrote:
... 
> 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.

Confirm. But, this one (if you like unix way)

% mkfs.jffs2 -lfq -p0x100000 -e0x10000 -mnone -rfoo -oimage.jffs2
                   ^^         ^^
                   no ws      no ws

will create the same 1M image.  No spaces there is not big surprise
for me.

...
> > 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?

If you can, please, submit it to eCos Bugzilla.
http://bugs.ecos.sourceware.org/

Thanks,
Sergei


[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

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

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

[Michael Bergandi]

> Confirm. But, this one (if you like unix way)
>
> % mkfs.jffs2 -lfq -p0x100000 -e0x10000 -mnone -rfoo -oimage.jffs2
>                   ^^         ^^
>                   no ws      no ws
>
> will create the same 1M image.  No spaces there is not big surprise
> for me.

Damn, yeah, I forgot about that.

>> > 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?
>
> If you can, please, submit it to eCos Bugzilla.
> http://bugs.ecos.sourceware.org/

Done.

Bug 1001157 - Addition of JFFS2 flash test offset and length options to cdl

Thanks again for the assistance.

-- 
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