efsl-devel — General mailing list for efsl development and questions/problems.

[Efsl-devel] license ammendment?

[Joel W. <jo...@in...>]

Hello,

Would you consider appending your license to incorporate an exception?
Something along the lines of what the eCos license states:

" As a special exception, if other files instantiate templates or use =
macros
 or inline functions from this file, or you compile this file and link =
it
 with other works to produce a work based on this file, this file does =
not
 by itself cause the resulting work to be covered by the GNU General =
Public
 License. However the source code for this file must still be made =
available
 in accordance with section (3) of the GNU General Public License."

http://ecos.sourceware.org/license-overview.html

For testing I ported 0.3.4 for use with IAR EWB-ARM 4.30A and Phillips
LPC214x.  All is working as advertised, with one minor bug fix.  I would
like to use the library in a commercial project and contribute my =
efforts,
but the current license is limiting this.  Would you consider revising =
your
LGPL license?  This change would make it much more popular with the =
embedded
community.


Regards,
Joel Winarske

Re: [Efsl-devel] Misc. questions

[Lennart Y. <le...@be...>]

On Sun, 20 Nov 2005, Bertrik Sikken wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi all,
>
> I just downloaded efsl and am looking if I can use it for my
> hobby project, a digital bat detector. In this application,
> ultrasonic audio is recorded at around 250 kS/s and written
> directly onto an SD/MMC flash disk. The recorded data can then
> be played back at 1/16th of the sampling rate (which makes the
> ultrasonics audible to humans) or be analysed later on a PC.
> (I have not actually written any code, still waiting for the
> hardware, a development kit with an LPC2148 / ARM7 core)

This should certainly be possible of you can get enough speed out of your
SPI bus.

>
> While skimming through the docs and the source I ran into the
> following questions:
>
> 1) The time functions are split up in several separate functions.
> I think this can be a risk and I don't see why there can't be
> a single call that gets all time properties (year, month, date,
> hour, min, sec) at once. The risk with getting them one-at-a-time
> is that you get an inconsistent set. Consider for example a time of
> 01:59:59. If you read the time while the time is changing to 02:00:00
> you may accidently read 02:59:59, which is wrong.
> AFAIK, many RTC implementations already allow for an atomic access.

This is a very correct point that has not been considered.
I'm going to consider the current implementation as a bug and correct it.
Although I'm not fond of the ideo of changing how something works in the 
stable branch, his point is very valid.

>
> 2) Currently the hardware interface (block device layer) can only
> write one block at a time. I think this can become very inefficient
> with some flash devices. For example, an SD card can do a multi-
> block write and take advantage of its internal cache to reduce write
> time and wear of the medium.
> Can the library be written such that (for example) the block write
> has an extra argument that indicates the number of contiguous
> blocks to write?
>

No longer true, I believe Gregory wrote a module that can handle this,
you should mail him and ask if you can get the source.
Gregory, if you are reading this, if you want mail us the source and 
we will include it in the library.

Even if that turns out to be a dead end, it is not difficult to make, and 
I was planning on writing an implmentation myself.

Don't overestimate the speed gain you will get from this though, it will 
be 10-20 percent ballpark.

> 3) I think it would be a nice feature to extend the block device
> layer a bit to make it possible to run an USB mass storage on top
> of it. To be used for applications where some data is written to a
> flash disk by an embedded device, then connected to a PC and read
> out through USB mass storage. USB mass storage uses a subset of
> the SCSI primary commands (version 2). As far as I can tell so far,
> the extra required functionality is:
> * getting the size of the disk (scsi READ CAPACITY command)
> * getting some identification (scsi INQUIRY command)

If you have been looking at the 0.2 branch, also take a look at 0.3 where 
device management is done completely different. If you feel up for it 
write a USB mass storage module (hardware independant, like the SD-SPI 
module) and a hardware interface to a USB client.

This would be a very interesting and wanted hardware endpoint.

Kind regards,

Lennart Yseboodt

>
> Kind regards,
> Bertrik Sikken
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFDgJp6ETD6mlrWxPURAjRwAKCQh27GdvGwxXAW5HrMDFPebjUeZACgr/y8
> lBB0ouMp5W1pqTdrolZQH6g=
> =b5vA
> -----END PGP SIGNATURE-----
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
> Register for a JBoss Training Course.  Free Certification Exam
> for All Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
> _______________________________________________
> Efsl-devel mailing list
> Efs...@li...
> https://lists.sourceforge.net/lists/listinfo/efsl-devel
>
>

[Efsl-devel] Misc. questions

[Bertrik S. <be...@zo...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

I just downloaded efsl and am looking if I can use it for my
hobby project, a digital bat detector. In this application,
ultrasonic audio is recorded at around 250 kS/s and written
directly onto an SD/MMC flash disk. The recorded data can then
be played back at 1/16th of the sampling rate (which makes the
ultrasonics audible to humans) or be analysed later on a PC.
(I have not actually written any code, still waiting for the
hardware, a development kit with an LPC2148 / ARM7 core)

While skimming through the docs and the source I ran into the
following questions:

1) The time functions are split up in several separate functions.
I think this can be a risk and I don't see why there can't be
a single call that gets all time properties (year, month, date,
hour, min, sec) at once. The risk with getting them one-at-a-time
is that you get an inconsistent set. Consider for example a time of
01:59:59. If you read the time while the time is changing to 02:00:00
you may accidently read 02:59:59, which is wrong.
AFAIK, many RTC implementations already allow for an atomic access.

2) Currently the hardware interface (block device layer) can only
write one block at a time. I think this can become very inefficient
with some flash devices. For example, an SD card can do a multi-
block write and take advantage of its internal cache to reduce write
time and wear of the medium.
Can the library be written such that (for example) the block write
has an extra argument that indicates the number of contiguous
blocks to write?

3) I think it would be a nice feature to extend the block device
layer a bit to make it possible to run an USB mass storage on top
of it. To be used for applications where some data is written to a
flash disk by an embedded device, then connected to a PC and read
out through USB mass storage. USB mass storage uses a subset of
the SCSI primary commands (version 2). As far as I can tell so far,
the extra required functionality is:
* getting the size of the disk (scsi READ CAPACITY command)
* getting some identification (scsi INQUIRY command)

Kind regards,
Bertrik Sikken
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDgJp6ETD6mlrWxPURAjRwAKCQh27GdvGwxXAW5HrMDFPebjUeZACgr/y8
lBB0ouMp5W1pqTdrolZQH6g=
=b5vA
-----END PGP SIGNATURE-----

Re: [Efsl-devel] Philips LPC ARM7TDMI interface

[Michael De N. <mi...@fl...>]

Hello Martin,

Martin Thomas wrote:

> Hi,
>
> couldn't reach Lennard (mail fails). I'm not subscribed so hopfully 
> this reaches the list...

It did :-)
Lennart's mail will be down for some more days prob, but I copy/pasted 
your mail through icq.

> I've uploaded a efsl 0.2.4-version with a LPC2000
> interface to
> http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/efsl_arm/
>
> Small readme in doc/.

Thanks, it looks really nice!

We'll put your updates into cvs and will make a new release containing 
the two new hardware endpoints (altera nios2 & arm) later this week.


Thanks,

Michael

[Efsl-devel] Philips LPC ARM7TDMI interface

[Martin T. <mt...@rh...>]

Hi,

couldn't reach Lennard (mail fails). 
I'm not subscribed so hopfully this reaches the list...

I've uploaded a efsl 0.2.4-version with a LPC2000
interface to
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/efsl_arm/

Small readme in doc/.

So far only tested with LPC2138.

Martin Thomas

[Efsl-devel] Re: Vragen over afgelopen jaar

[Michael De N. <mi...@fl...>]

buyskoen wrote:

>Dag Michael,
>  
>
Hi Koen,

I will answer this mail in English, since not all efsl-developers/users 
speak dutch ;-).

>Pelgrims wist me te vertellen dat jullie vorig jaar in C een file
>system op een SD card geschreven hebben. Nu ben ik hier ook wel in
>geinteresseerd. Zou je mij wat meer info kunnen geven hierover
>(schematics, code, databladen, ...) waar je mij mee verder zou kunnen
>helpen. Ik zou dit willen porten naar een ARM7 controller. 
>  
>

This project was indeed started as part of another project, but split 
off once we required to have it running on different hardware endpoints 
(at that time avr & ti dsp). The project was released under the 
LGPL-license and can now be found on http://sourceforge.net/projects/efsl.

It currently has support for reading & writing fat12/16/32 filesystems 
on different platforms (linux, avr, ti dsp's & altera), but is 
constructed so that new filesystems & hardware endpoints can be added 
easily. I think that someone was working on an ARM-port, but we haven't 
seen a patch yet. But if not there yet, you should be able to write it 
in a few days.

We are currently still working on the new development branch (0.3), 
which contains a new endpoint-structure in which you will only have to 
write a very small part of the code that handles the sending/receiving 
of the SPI-protocol (different on every platform). There is however 
still some work to be done, and documentation is outdated, so I would 
advice you to have a look at our stable branch (efsl-0.2), which 
contains up-to-date documentation on the whole project and an "howto 
write a new hardware endpoint".


Good luck,

Michael

Ps: If you want, you can subscribe to our mailing list on 
http://lists.sourceforge.net/lists/listinfo/efsl-devel, this is the 
place for questions & answers ;)

[Efsl-devel] Re: suggestions for efsl

[Lennart Y. <le...@be...>]

Hi Martin,

Thanks for your mail! I'm cc'ing this to the mailinglist, so your mail is 
not lost in my inbox :)

On Fri, 28 Oct 2005, Martin Thomas wrote:

> Hello,
>
> sorry for contacting you directly but so far I'm not subscribed to the
> sourceforge list.
>

No problem ;)

> First of all: thank you and the other developers of the library.
> Very useful.
>
> I've added a hardware endpoint for Philips LPC2000 ARM7 controllers
> and SD cards to the efsl 0.2.x branch and will try to contribute this code to
> your project. An endpoint for Atmel AT91SAM ARM7 controllers may
> follow soon.
>
> So far the code is not in a "library-state". I've just included all 
> efsl-source
> in a project and added the LPC2000 stuff.
>

This is not a problem, you can just 'dump' the code with us, I don't mind 
sorting it out and adding it to the library.

> Before I try to join my code to the 0.3-branch. I'd like to suggest
> some change in the debug output handling of the library . It may
> be enough to add a function efs_setoutput( int(*)(char) ) to the efsl-api
> and modify the outputs to use this function(-pointer). The user can
> pass a function-pointer of his application-specific "putchar" function.
>

Yes you are right on track here. Debugging was added in a later state
of the library, it has become a bit of a filthy macro hack.
Something like what you suggest will be implemented inevitably.

> This would reduce the device-specific code and increase the
> flexibility (i.e. the putchar could send a char to a sorftware-uart
> or to a LCD). Initialisation of the "output-stream" would be on the
> application-side and not on the library-side (no hard-coded baudrate,
> uart-number etc.). Passing a "NULL" to the "setoutput" would
> open the possibilty to disable the output of "DBG" temporarily
> even it the library has been complied with "define DEBUG".
>
> What do you think about this? Could you add the suggested
> changes to the 0.3-branch? I will than add the code for the
> LPC interface and send you a patch.
>

Patch is very welcome, although debugging is currently not really on the 
top of the priority list it will definately be implemented.
I am currently working on the fsutils, because 0.3 is currently 
untestable, and Michael is putting in a lot of time on getting SD card 
support working and increasing it's speed.

Thanks again for your mail, I eagerly await your patch ;)

> Regards,
> Martin Thomas
>
>
>
>
>
>

[Efsl-devel] Re: [efsl] speed optimization on 2.2

[Lennart Y. <le...@be...>]

Hi Alvaro,

What are you referring to ? Is the optimisation we did on the writing of the files ? If so -> no this optimisation was in the filesystem layer.

Regards,

Lennart

On Wed, 26 Oct 2005 10:50:26 -0300
Alvaro Aguirre <alv...@gm...> wrote:

> I have a question. what part of the code was touched for optimize the speed?
> the interfaces files?
> 


-- 
Psychoanalysis is that mental illness for which it regards itself a therapy.
		-- Karl Kraus

Re: [Efsl-devel] First tryout efsl 0.3.4

[Michael De N. <mi...@fl...>]

Arthur Ketels wrote:

> Hi Lennart,
>
> I'm happy to say the new version compiles ok without any problems.
> However I have to nag again ;-) The speed improvements with
> ClusterCount have been undone again. And worst of all the universal
> interface works nice and is easy to setup but also dead-slow. The
> spi_send function takes over 30 cycles to complete one spi byte. That
> is even slower than my own software spi function!
>
> If you have a look at the ClusterCount optimizing I'll have go at the
> spi routines. I didn't do a speed comparison yet with the 0.2.2
> (didn't upgrade to 0.2.4 yet) version but I'm planning to make a quick
> test suite to do some speed measurements. Then every improvement shows
> up quickly without to much effort. I guess it is no use making a
> beautiful library (and I must say you have a nice coding style) when
> it is slow as snails.
>

Hi Arthur,

Thanks for your remarks!

My first goal was to get the sd-card working again, as soon as that goal
was reached, I released 0.3.4 (since we got a lot of people asking us
what happened to the sd-support in 0.3.3). No work has been done to
optimizing the library because a lot of work has still to be done in 0.3
before becoming 'stable' (as in can be used in real projects).

Because a lot of things still have to be done, it would be nice if you
or other people intrested in contributing to the library could help us a
bit.
Some subjects that still have to be tackled before 0.4:

    * optimization (make efsl faster)
    * cleaning (get the complete library cleaner, remove functions that
      are not used, make function variables more logic, rename functions
      to a clear name, ...)
    * wrapper (create a wrapper like efsl_init in 0.2, so that
      initializing the library & it's variables can be done in a few lines)
    * documentation (almost a complete rewrite of the documentation is
      needed for 0.3)
    * testing (testing on the different platforms)
    * add new hw/protocol-layers (for example sd-protocol, CF-support,
      IDE-support, ...)
    * add support for other compilers than avr-gcc & code-composer
    * ...


If you (or someone else) would be intrested, please let us know, so we
can create an account for you on the sourceforge cvs-servers, so you can
apply patches directly.


Greetings,

Michael

[Efsl-devel] First tryout efsl 0.3.4

[Arthur K. <art...@xs...>]

Hi Lennart,

I'm happy to say the new version compiles ok without any problems. 
However I have to nag again ;-) The speed improvements with ClusterCount 
have been undone again. And worst of all the universal interface works 
nice and is easy to setup but also dead-slow. The spi_send function 
takes over 30 cycles to complete one spi byte. That is even slower than 
my own software spi function!

If you have a look at the ClusterCount optimizing I'll have go at the 
spi routines. I didn't do a speed comparison yet with the 0.2.2 (didn't 
upgrade to 0.2.4 yet) version but I'm planning to make a quick test 
suite to do some speed measurements. Then every improvement shows up 
quickly without to much effort. I guess it is no use making a beautiful 
library (and I must say you have a nice coding style) when it is slow as 
snails.

Happy codings,
Arthur.

[Efsl-devel] Re: Example for EFSL-0.3.3

[Lennart Y. <le...@be...>]

Hi Gregory,

The 0.3 branch does not yet fully support SD cards, Michael is working on this,
as soon as it works for AVR (which we can test), I'll adapt the DSP driver.

This will probably be in a few days, when it's done we'le release a 0.3.4 version with
updated documentation.

Currently there is no advantage to using the 0.3 branch, but I as soon as the AVR stuff works
I'm very interested to hear if you can get it working on DSP too!

Regards,

Lennart

On Thu, 20 Oct 2005 15:54:51 +0200
"Gregory Pereira" <gpe...@gr...> wrote:

> Hi Lennard,
> 
> you haven't maybe got an example for the Texas using the new
> EFSL-0.3.3.
> 
> The documentation still shows the old one.
> 
> I see that with the avrtest.c that the sd.init isn't called.
> 
> What is the 
> EFSL_Storage_Config sconf;
> EFSL_Filesystem_Config fconf;
> EFSL_Storage storage;
> EFSL_Filesystem filesystem;
> 
> for?
> 
> Regards
> Greg
> 


-- 
BOFH Excuse #300:

Digital Manipulator exceeding velocity parameters

Re: [Efsl-devel] AVR makefile for 0.3.3

[Michael De N. <mi...@fl...>]

Arthur Ketels wrote:

> Hi Lennart,
>
> I had a quick look at the efsl 0.3.3. It looks nice :-) Now I 
> understand your pdf a lot better. I guess c-code is a lot easier to 
> understand than plain English. I want to try it out on my AVR system 
> but could not find the AVR makefiles. You have them available? It will 
> save me a lot of effort, because you changed a lot in the makefiles. 
> And I must confess I'm no hero at gcc make (got too lazy from nice 
> IDE's).

Hi Arthur,

The avr hardware layer is not yet in the new 0.3 system.
I am currently porting/testing the avr-part of the 0.2 code to the 0.3 
version.

Btw: Which compiler are you using? I assume only the hw-interface-part 
differs in most avr-compilers, so perhaps we could create an atmege-gcc, 
atmega-imagecraft, ...?

Greetings,

Michael

[Efsl-devel] AVR makefile for 0.3.3

[Arthur K. <art...@xs...>]

Hi Lennart,

I had a quick look at the efsl 0.3.3. It looks nice :-) Now I understand 
your pdf a lot better. I guess c-code is a lot easier to understand than 
plain English. I want to try it out on my AVR system but could not find 
the AVR makefiles. You have them available? It will save me a lot of 
effort, because you changed a lot in the makefiles. And I must confess 
I'm no hero at gcc make (got too lazy from nice IDE's).

How do you like my changes/additions  posted? Just email you?

Regards,
Arthur.

[Efsl-devel] Re: EFSL 0.2.2 speeding it up

[Arthur K. <art...@xs...>]

Hi Lennart and Gregory,

I hate to bring some bad news here. It is a nice idea however I don't 
think there will be much effective speed gain (I like to be proved wrong 
here). One thing is now that the speed of writing to to SD/MMC card is 
limited now by the atmega SPI interface. The card can run 20mhz and the 
new ones even 52mhz. The atmega is limited to clk/2 so 4mhz for a 8mhz 
processor. The card is much faster than the atmega ever can be. Using 
multiple 512 transfers is a bit faster than  writing single blocks 
because there is only one command setup and there will be no busy phase 
until all buffers are full. However the busy phase in single mode can be 
circumvented by using the busy time to calculate and setup a new buffer. 
This almost negates the advantage for multi block mode. A disadvantage 
in using a multi block mode is that the processor will be busy longer 
inside Efsl. This is not good for a multi tasking environment, here you 
want to keep the time spend in any library as short as possible.

I don't know for the SD specification but for MMC and MMC+ cards the 
buffers are not directly available in SPI mode (bummer...). This doesn't 
mean there will be no buffers used inside the card, they are just 
transparent for the SPI bus. If a multiple write is not linear it will 
have to be split up anyway (however a cluster is always linear in itself 
). An other approach is to use the spec for new cards and emulate the 
MMCplus  mode for 8bits parallel transfer. Even a software interface 
will improve the transfer speed a lot in respect to the current SPI 
hardware interface. I estimate a 3 to 4-fold increase. The disadvantage 
is it will use up more IOpins on the microprocessor. I'm not quite sure 
about the native MMC and SD modes with 4bit serial transfer. I guess I 
have to try sometime, there is a SWAP assy instruction that will 
optimize nibble operations.

Regards,
Arthur.

>Yes you are Gregory,
>
>That's the correct place to implement such a thing :)
>You can send the changes to me or the mailinglist, in one of
>the next releases your code will be incorporated and your name added to the credits ;)
>
>Regards,
>
>Lennart
>
>On Tue, 11 Oct 2005 12:20:03 +0200
>"Gregory Pereira" <gpe...@gr...> wrote:
>
>  
>
>>Hi,
>>
>>i see that if_writeBuf calls the sd_writeSector with a buffer.
>>
>>As i see it the sd_writeSector function will have to change in order to
>>do the buffering.
>>
>>Currently i sends a write command for every 512 bytes. With buffering
>>it will send a command for a larger buffer than 512 (a few blocks).
>>
>>Am i heading in the right direction?
>>
>>Greg 
>>    
>>
>  
>

[Efsl-devel] Devel branch 0.3 status update

[Lennart Y. <le...@be...>]

Hay,

Today was quite a productive day. I've put efsl in a completely new directory
structure, and moved all code that was conflicting to the proper files.

I've converted the protocol handler (sdspi) to the new system, untested.
Tomorrow Michael and I will test it on real hardware.

I've made new Makefiles for all components. Still quite a bit of
works is to be done like getting the testing programs back online,
and the linuxutils, but we're seeing some real progress here.

In perhaps as little as a week we will have a .3 release that actually
compiles on other boxen than mine.

People who are actively working with the library and have some spare time can try it out,
a lot of advantages await. If you make improvements to the hardware drivers they won't be 'lost' anymore they will actually be incorporated :)

Regards,

Lennart

-- 
Got a complaint about the Internal Revenue Service?  
Call the convenient toll-free "IRS Taxpayer Complaint Hot Line Number":

	1-800-AUDITME

[Efsl-devel] Re: EFSL 0.2.2 speeding it up

[Lennart Y. <le...@be...>]

Yes you are Gregory,

That's the correct place to implement such a thing :)
You can send the changes to me or the mailinglist, in one of
the next releases your code will be incorporated and your name added to the credits ;)

Regards,

Lennart

On Tue, 11 Oct 2005 12:20:03 +0200
"Gregory Pereira" <gpe...@gr...> wrote:

> Hi,
> 
> i see that if_writeBuf calls the sd_writeSector with a buffer.
> 
> As i see it the sd_writeSector function will have to change in order to
> do the buffering.
> 
> Currently i sends a write command for every 512 bytes. With buffering
> it will send a command for a larger buffer than 512 (a few blocks).
> 
> Am i heading in the right direction?
> 
> Greg 
> 
> >>> Lennart Yseboodt <le...@be...> 2005/10/11 11:51:09 AM >>>
> On Tue, 11 Oct 2005, Gregory Pereira wrote:
> 
> > Hi Lennard,
> >
> > i tested your code and it works fine.
> >
> > Currently i am getting max 100KBytes per second with cache on and
> other
> > optimisations.
> >
> > I read in the datasheets that the SD card has got its own buffering
> > mechanism.
> >
> > How easy will it be to implement this on the EFSL?
> 
> A write back cache implemented at the if_interface level will
> take care of that. You can do that in a couple of hours :)
> 
> >
> > Regards
> > Greg
> >
> >
> >
> 


-- 
You know that feeling when you're leaning back on a stool and it starts to tip 
over?  Well, that's how I feel all the time.
-- Steven Wright

[Efsl-devel] Re: EFSL 0.2.2 speeding it up

[Lennart Y. <le...@be...>]

On Tue, 11 Oct 2005, Gregory Pereira wrote:

> Hi Lennard,
>
> i tested your code and it works fine.
>
> Currently i am getting max 100KBytes per second with cache on and other
> optimisations.
>
> I read in the datasheets that the SD card has got its own buffering
> mechanism.
>
> How easy will it be to implement this on the EFSL?

A write back cache implemented at the if_interface level will
take care of that. You can do that in a couple of hours :)

>
> Regards
> Greg
>
>
>

Re: [Efsl-devel] Regarding proposal for hardware interfacing

[Lennart Y. <le...@be...>]

Arthur,

The document I sent to the mailinglist was limited in it's information, it is impressive how much you have been able to extrapolate with that limited data.
Your opinion is important to us, so let me fill you in where I see gaps.
I'll be typing within the reply, bad habit sorry ;)

> ---------- Forwarded message ----------
> Date: Fri, 07 Oct 2005 21:45:06 +0200
> From: Arthur Ketels <art...@xs...>
> Reply-To: efs...@li...
> To: efs...@li...
> Subject: [Efsl-devel] Regarding proposal for hardware interfacing
> 
> Lennart,
> 
> With much interest I've been reading your proposal for a new structure 
> regarding the hardware interface layer of Efsl. It seems a sound approach to 
> me, however I also have some remarks and suggestions that could possibly of 
> help.
> 
> I don't see there is a need to switch between two different kinds of processor 
> implementations. There will be only one processor running the code. I have no 
> problem whatsoever to compile for different platforms. So to hard code at 
> compile time is fine with me (with a config file or otherwise). However I could 
> very well imagine applications where it would be nice to be able to run more 
> than one sd card. For example to copy something from one card to the other. Or 
> to have a sd card and a compactflash at the same time. Right now I have a 
> project where I'm thinking to run Efsl with a rs323/rs485 hardware endpoint.

The first thing you talk about is that there would be code for, say, a DSP lying
dormant and wasting memory on (example) an AVR. This is not the case, it is not so
in the 0.1/0.2 branch nor will it be in 0.3/0.4.
In 0.2 only *one* endpoint can be compiled, this limits the library to one endpoint
per project, the code for the other endpoints is not compiled in. Even if you did, the
linker would throw it right out as you did final linking.

In 0.3 it (is/will be) possible to not only have multiple instances of the same endpoint, 
(which is possible in 0.2 as well if you hack it up properly), but to have completely
different endpoints running concurrently. You could have 2 CD cards on the SPI bus and
a harddisk on another bus. This code exists today, and I think it's pretty good.
Please note that no unsused code will be present, linkers take care of that.

What we don't have yet is a means to re-use (example) the SPI component. The solution
we came up with is in the document. So about the hardware part we're pretty safe,
everything is possible, no code wasted, so I think we're pretty good!

> 
> In a multitasking environment (as is mostly the case in embedded applications) 
> it is mandatory to have your libraries reentrant in nature. If you interrupt 
> Efsl while it is reading something from card a it is nice to be able to start 
> writing an other file on card b without messing things up for card a. Therefore 
> all data, structures and flags need to be stored in their own memory space and 
> referenced only by pointer in Efsl. It is logical to do the same for your 
> hardware interface pointers. I suggest to do it right at the beginning in 
> efs_init. The fs structure (or one of its dependents) is the right point to 
> store all data concerning the hardware endpoint for that specific filesystem. 
> The init, writesector and readsector routines can jump to the designated 
> hardware routines specified in the fs structure tree. Now I think of it, a 
> shutdown routine would be nice also (even if it will be empty most of the 
> time). The efs_init would look like efs_init(fs pointer, options , protocol, 
> hardware port).

Alright, part of what you say here has been possible since the very conception of the
library. EFSL is very cleanly object oriented, you can have multiple files, filesystems, 
partitions, discs, etc hooked up any way you like (IOMan is limited to 1 device, but it
will only take me a few hours to make it multiple device ready).
So in terms of OO we're at level excellent.

Then you mention re-entrancy. Now there's a thing I don't see happen for quite a while if
at all. I'm not an expert at the finer points of filesystem locking, but from the scenario's
in my mind I can tell it is not so easy. First of all the code would increase in size a lot,
and I think it is very bug prone work.

For now, re-entrancy, or even thread-safeness is not an issue, since it would make EFSL so
much heavier that it would lose support for the AVR family.

Now, I can't be certain, but I think EFSL 0.4 will be a lot more memory friendly than 0.2,
despite the many additional features. In the 0.2 structures an enourmous amount of useless
data is stored, like whole partition tables, and direntry structures.

You must understand, this library was developed for a TMS6713, with 16 Mb of RAM, the portability
to lesser controllers was an afterthought. This will be fixed in 0.4, memory footprint will be
greatly reduced.

> 
> Example two sd-cards one on spi1 and one on spi2
> result=efs_init(&efs1,0,PR_SD,SPI1);
> result=efs_init(&efs2,0,PR_SD,SPI2);
> error=file_fopen(&filer,&efs1.myFs,fname,'r');
> error=file_fopen(&filew,&efs2.myFs,fname,'w');
> 
> Or one sd-card on spi1 and one compactflash at port x
> result=efs_init(&efs1,0,PR_SD,SPI1);
> result=efs_init(&efs2,0,PR_CF,PORTX);
> error=file_fopen(&filer,&efs1.myFs,fname,'r');
> error=file_fopen(&filew,&efs2.myFs,fname,'w');

This is, as mentioned before, possible even now, although not with the efs_* functions.

> 
> The routines for each hardware port are hardcoded to optimize speed. The little 
> extra code duplication I take happily.
> 
> For speed reasons I would suggest not only to implement one byte read and write 
> routines but also a sector read and write. I changed the 0.2 code to do just 
> that and it gave me a huge speed jump. The small pieces of code can be hand 
> optimized or in assembly code. Keep in mind that using the same spi hardware 
> and different select lines to use multiple sd cards will need some clever 
> flagging to insure reentrancy. Especially if one chooses to use different spi 
> clock rates. A software spi port could be implemented also. I use some assembly 
> code in a application that runs approx. 2mhz on a 8mhz atmega128.
> 
> Concerning cache. The cache structure should be independent of the fs structure 
> used. That means one common cache for multiple instances of Efsl. Memory 
> constrains demand this I think. For fast writing I used an other approach. 
> Below a small piece of an email I send to an other Efsl user.

Japs, things like that are already there or under way...

> 
> ....One change I implemented is in the writebuffer routine where I don't wait 
> at the end of the block transfer until the card is ready again. I assume a lot 
> of other code will/can be executed in that time. It is more efficient to set a 
> busy flag and then at the sdcommand routine check if the card is ready. Most of 
> the time it is, so no time gets waisted. Also I changed the writing cache 
> principle. Instead of calling Efsl for writing buffers smaller than 512 bytes I 
> implemented two 512 byte buffers (called a and b). All writes to an open file 
> get dumped in buffer a when it spills over I change to buffer b and give a 
> write command to flush buffer a into Efsl. The same is repeated the other way 
> around. That way I only use full 512 byte writes (a lot quicker). The buffers 
> for Efsl I set to 1 (makes almost no difference to set it higher). In ioman.c I 
> also commented out the part where a write command could get copied into the 
> cache. In effect I circumvent the whole Efsl cache system for file writes (I do 
> use it for directories, fat and reads).....

A very very true point, IOMan does miracles for caching reads (I'm auite proud of
it actually), but it does absolutely nothing for writes. An idea for improving that
I already have.

So as you know, for writes you get nothing from IOMan, it just delays them. Now, if
you do many small writes (keeping a log example), you will not speedup the writes,
but reduce their number, so their is benefit.

Now to get the speed crancked up, I propose a write-back buffer. This will be
implemented at the hardware interface level. When if_writeBuf is called, the data 
presented will be copied into a stacking buffer. When this buffer is full, you can
benefit from the fast_write method the SD cards offer.

Similar techniques exist for harddrives probably. 

> 
> Of course it would be much better if the Efsl cache is optimized for writes. A 
> direct pointer to the buffers would be demanded here. The first reason to 
> change to the above mentioned solution was primarily for interrupt reasons and 
> only secondly for speed. In this application the buffers get filled in an 
> interrupt routine and Efsl runs at the main routine in a permanent loop (lowest 
> priority).
> 
> These are some first ideas, perhaps I can think up some more later.
> Lets communicate and exchange ideas...
> 
> Arthur Ketels.
> 

I've said a lot, maybe not everything clear, but I hope you have a better understanding
now of where our cencerns lie, that's not so much in hardware interface land, but further up.

What we're planning is to make a virtual filesystem layer, so that you can transparantly use
multiple kinds of filesystems on any kind of hardware in an easy, portable, and clean way.

If we succeed in this, EFSL will be the very first filesystem library of it's class, I have seen
no free, nor any commercial solution offer this. At that point EFSL will become the market leader
in embedded filesystems, if we can implement everything said here cleanly, and it doesn't run block.

I'm still thinking about the VFS thing, not everything's figured out there. What would be *great* if you
we're willing to assist in converting the existing driverbase into the 0.3 model, and perhaps provide
the drivers for the hardware you write.

As soon as 0.3 hardware side begins to get stable, this task could be started. Michael will also be working
on this, since he maintains the AVR/DSP SPI_SD port.

I really think we can make this fly, and if and when it does we might start seeing EFSL in bigger projects.
God knows, maybe your Nikon Coolpix will one day run EFSL ;)

So the things to do look like this

	* Implement hardware layer changes (easy, couple of days)
	* Convert existing drivers to new model (easy, couple of hours)
	* Convert protocol drivers like SPI to new model (moderate, 1 day perhaps)
	* IOMan updates (pretty easy, not critical)
	* Re organise dir structure (sucks)
	* Think-out upper VFS layer (I'm almost there...)
	* Clean up library, function names etc (*brrr*)

But most valuable help comes from people like you reporting/fixing bugs, and using the library
on devices and storage media not previously done.

Regards,

Lennart Yseboodt

[Efsl-devel] Regarding proposal for hardware interfacing

[Arthur K. <art...@xs...>]

Lennart,

With much interest I've been reading your proposal for a new structure 
regarding the hardware interface layer of Efsl. It seems a sound 
approach to me, however I also have some remarks and suggestions that 
could possibly of help.

I don't see there is a need to switch between two different kinds of 
processor implementations. There will be only one processor running the 
code. I have no problem whatsoever to compile for different platforms. 
So to hard code at compile time is fine with me (with a config file or 
otherwise). However I could very well imagine applications where it 
would be nice to be able to run more than one sd card. For example to 
copy something from one card to the other. Or to have a sd card and a 
compactflash at the same time. Right now I have a project where I'm 
thinking to run Efsl with a rs323/rs485 hardware endpoint.

In a multitasking environment (as is mostly the case in embedded 
applications) it is mandatory to have your libraries reentrant in 
nature. If you interrupt Efsl while it is reading something from card a 
it is nice to be able to start writing an other file on card b without 
messing things up for card a. Therefore all data, structures and flags 
need to be stored in their own memory space and referenced only by 
pointer in Efsl. It is logical to do the same for your hardware 
interface pointers. I suggest to do it right at the beginning in 
efs_init. The fs structure (or one of its dependents) is the right point 
to store all data concerning the hardware endpoint for that specific 
filesystem. The init, writesector and readsector routines can jump to 
the designated hardware routines specified in the fs structure tree. Now 
I think of it, a shutdown routine would be nice also (even if it will be 
empty most of the time). The efs_init would look like efs_init(fs 
pointer, options , protocol, hardware port).

Example two sd-cards one on spi1 and one on spi2
result=efs_init(&efs1,0,PR_SD,SPI1);
result=efs_init(&efs2,0,PR_SD,SPI2);
error=file_fopen(&filer,&efs1.myFs,fname,'r');
error=file_fopen(&filew,&efs2.myFs,fname,'w');

Or one sd-card on spi1 and one compactflash at port x
result=efs_init(&efs1,0,PR_SD,SPI1);
result=efs_init(&efs2,0,PR_CF,PORTX);
error=file_fopen(&filer,&efs1.myFs,fname,'r');
error=file_fopen(&filew,&efs2.myFs,fname,'w');

The routines for each hardware port are hardcoded to optimize speed. The 
little extra code duplication I take happily.

For speed reasons I would suggest not only to implement one byte read 
and write routines but also a sector read and write. I changed the 0.2 
code to do just that and it gave me a huge speed jump. The small pieces 
of code can be hand optimized or in assembly code. Keep in mind that 
using the same spi hardware and different select lines to use multiple 
sd cards will need some clever flagging to insure reentrancy. Especially 
if one chooses to use different spi clock rates. A software spi port 
could be implemented also. I use some assembly code in a application 
that runs approx. 2mhz on a 8mhz atmega128.

Concerning cache. The cache structure should be independent of the fs 
structure used. That means one common cache for multiple instances of 
Efsl. Memory constrains demand this I think. For fast writing I used an 
other approach. Below a small piece of an email I send to an other Efsl 
user.

....One change I implemented is in the writebuffer routine where I don't 
wait at the end of the block transfer until the card is ready again. I 
assume a lot of other code will/can be executed in that time. It is more 
efficient to set a busy flag and then at the sdcommand routine check if 
the card is ready. Most of the time it is, so no time gets waisted. Also 
I changed the writing cache principle. Instead of calling Efsl for 
writing buffers smaller than 512 bytes I implemented two 512 byte 
buffers (called a and b). All writes to an open file get dumped in 
buffer a when it spills over I change to buffer b and give a write 
command to flush buffer a into Efsl. The same is repeated the other way 
around. That way I only use full 512 byte writes (a lot quicker). The 
buffers for Efsl I set to 1 (makes almost no difference to set it 
higher). In ioman.c I also commented out the part where a write command 
could get copied into the cache. In effect I circumvent the whole Efsl 
cache system for file writes (I do use it for directories, fat and 
reads).....

Of course it would be much better if the Efsl cache is optimized for 
writes. A direct pointer to the buffers would be demanded here. The 
first reason to change to the above mentioned solution was primarily for 
interrupt reasons and only secondly for speed. In this application the 
buffers get filled in an interrupt routine and Efsl runs at the main 
routine in a permanent loop (lowest priority).

These are some first ideas, perhaps I can think up some more later.
Lets communicate and exchange ideas...

Arthur Ketels.

[Efsl-devel] Proposal about hardware interface

[Lennart Y. <le...@be...>]

Comments are welcome!

-- 
Experience teaches you that the man who looks you straight in the eye,
particularly if he adds a firm handshake, is hiding something.
		-- Clifton Fadiman, "Enter Conversing"

[Efsl-devel] Re: [efsl] Hi

[Lennart Y. <le...@be...>]

Hi Alvaro

I closed the bug because I am unable to reproduce it, and
nobody else has reported problems.

Can you give me a showcase of the problem ? (small program that shows it) 
?

Regards,

Lennart

On Thu, 29 Sep 2005, Alvaro Aguirre wrote:

> Why you close the open bug in efsl? do you have any answers about the
> problem? did you create the test scenario? what do you find?
>

[Efsl-devel] Re: EFSL for Texas c6000

[Lennart Y. <le...@be...>]

Hey Gregory,

Most importantly, we fixed the rmfile bug(), and perhaps some little 
quirks here and there.

Lennart

On Thu, 29 Sep 2005, Gregory Pereira wrote:

> Hopefully the last question for today.
>
> What has changed from efsl0.2.0 to efsl0.2.1
>
> Regards
> Greg
>
>>>> Lennart Yseboodt <le...@be...> 2005/09/29 02:58:28 PM >>>
> Hi,
>
> These values are not populated in any ioman functions.
> Can you step through the verifySanity function and see where it bails
> out
> ?
>
> Basically, what verifySanity does is make some calculations on the data
>
> that's loaded from the first sector from the filesystem.
>
> What can cause this to fail is
>  	* Filesystem corrupt
>  	* Reading from an empty partition
>  	* Reading from the wrong partition
>  	* Data corruption on your SPI lines.
>
> When the filesystem initialises, halt the program after the first
> sector
> is loaded, and look at the values, then compare them with a hexdump of
> the
> card to see if you can read the sectors correctly.
>
> Mail if you need more help!
>
> Lennart
>
> On Thu, 29 Sep 2005, Gregory Pereira wrote:
>
>> Hi Lennart,
>>
>> i got the code compiled and the DSP is comunicating to the SD Card.
>> I looks like the Card is initialising but there seems to be a
> problem
>> with the ioman.
>>
>> I used the exact same code as the AVR which worked.
>>
>> I tested the signals going to the SD card and made them nearly
> exactly
>> as the AVR128 timing.
>> The if_initInterface function return a zero which shows that it
>> initialised.
>> When the fs_initFs function is called it fails because
> fs_verifySanity
>> fails.
>> fs->volumeId.SectorsPerCluster = 0
>> fs->volumeId.BytesPerSector = 0
>> fs->volumeId.FatSectorCount32 = 0
>> Where do these values get populated?
>> Is it in the ioman.c file functions.
>> How must the ioman be set up for the Config file?
>> It is currently set up as
>> #define HW_ENDPOINT_DSP_TI6713_SD
>> #define BYTE_ALIGNMENT
>> #define IOMAN_NUMBUFFER 1
>> #define IOMAN_NUMITERATIONS 3
>> #define IOMAN_DO_MEMALLOC
>>
>> #define CLUSTER_PREALLOC_FILE 0
>> #define CLUSTER_PREALLOC_DIRECTORY 0
>> #define LITTLE_ENDIAN
>> #define FULL_ERROR_SUPPORT
>> #define LIST_MAXLENFILENAME 12
>> #define DEBUG
>> #define BAUDRATE	9600
>> Attached is the file that i used to test and set up the Synchronous
>> serial Port (SPI).
>>
>> Regards
>> Greg
>>
>>
>>>>> Lennart Yseboodt <le...@be...> 2005/09/08 08:46:55 PM >>>
>> Hi Greg,
>>
>> I used a TMS 6713 DSP when we developed the library. If I recall, we
>> integrated the CSL into the hardware interface, so you'll be needing
>> those
>> header files.
>>
>> That would be csl.h and csl_mcbsp.h
>>
>> Try including those in your project, mail us if it doesn't work :)
>>
>> Regards,
>>
>> Lennart
>>
>> On Thu, 8 Sep 2005, Gregory Pereira wrote:
>>
>>> Hi,
>>>
>>> i am trying to compile for the Texas c6000 processor.
>>>
>>> It first looked for the mcbsp.h file. I then included it from the
>>> c:\c6xtools\INCLUDE\ directory.
>>>
>>> It seems that it doesn't like this header file because the compiler
>>> says it doesn't find BspPort (identifier "BspPort" is undefined).
>>>
>>>> From where should i include this header file mcbsp.h.
>>>
>>> Have you got an unique one?
>>>
>>> I also uncommented the define HW_ENDPOINT_DSP_TI6713_SD.
>>>
>>> Should i change anything else in the config file?
>>>
>>> Regards
>>> Greg
>>>
>>>
>>
>
>

[Efsl-devel] Re: EFSL for Texas c6000

[Lennart Y. <le...@be...>]

Hi,

These values are not populated in any ioman functions.
Can you step through the verifySanity function and see where it bails out 
?

Basically, what verifySanity does is make some calculations on the data 
that's loaded from the first sector from the filesystem.

What can cause this to fail is
  	* Filesystem corrupt
  	* Reading from an empty partition
  	* Reading from the wrong partition
  	* Data corruption on your SPI lines.

When the filesystem initialises, halt the program after the first sector 
is loaded, and look at the values, then compare them with a hexdump of the
card to see if you can read the sectors correctly.

Mail if you need more help!

Lennart

On Thu, 29 Sep 2005, Gregory Pereira wrote:

> Hi Lennart,
>
> i got the code compiled and the DSP is comunicating to the SD Card.
> I looks like the Card is initialising but there seems to be a problem
> with the ioman.
>
> I used the exact same code as the AVR which worked.
>
> I tested the signals going to the SD card and made them nearly exactly
> as the AVR128 timing.
> The if_initInterface function return a zero which shows that it
> initialised.
> When the fs_initFs function is called it fails because fs_verifySanity
> fails.
> fs->volumeId.SectorsPerCluster = 0
> fs->volumeId.BytesPerSector = 0
> fs->volumeId.FatSectorCount32 = 0
> Where do these values get populated?
> Is it in the ioman.c file functions.
> How must the ioman be set up for the Config file?
> It is currently set up as
> #define HW_ENDPOINT_DSP_TI6713_SD
> #define BYTE_ALIGNMENT
> #define IOMAN_NUMBUFFER 1
> #define IOMAN_NUMITERATIONS 3
> #define IOMAN_DO_MEMALLOC
>
> #define CLUSTER_PREALLOC_FILE 0
> #define CLUSTER_PREALLOC_DIRECTORY 0
> #define LITTLE_ENDIAN
> #define FULL_ERROR_SUPPORT
> #define LIST_MAXLENFILENAME 12
> #define DEBUG
> #define BAUDRATE	9600
> Attached is the file that i used to test and set up the Synchronous
> serial Port (SPI).
>
> Regards
> Greg
>
>
>>>> Lennart Yseboodt <le...@be...> 2005/09/08 08:46:55 PM >>>
> Hi Greg,
>
> I used a TMS 6713 DSP when we developed the library. If I recall, we
> integrated the CSL into the hardware interface, so you'll be needing
> those
> header files.
>
> That would be csl.h and csl_mcbsp.h
>
> Try including those in your project, mail us if it doesn't work :)
>
> Regards,
>
> Lennart
>
> On Thu, 8 Sep 2005, Gregory Pereira wrote:
>
>> Hi,
>>
>> i am trying to compile for the Texas c6000 processor.
>>
>> It first looked for the mcbsp.h file. I then included it from the
>> c:\c6xtools\INCLUDE\ directory.
>>
>> It seems that it doesn't like this header file because the compiler
>> says it doesn't find BspPort (identifier "BspPort" is undefined).
>>
>>> From where should i include this header file mcbsp.h.
>>
>> Have you got an unique one?
>>
>> I also uncommented the define HW_ENDPOINT_DSP_TI6713_SD.
>>
>> Should i change anything else in the config file?
>>
>> Regards
>> Greg
>>
>>
>

[Efsl-devel] Issue and Patch for the big endian machines

[michael.waeber <mic...@hu...>]

Hello
I'am porting the EFSL to a m86k platform (big endian, memory can't
accessed byte oriented). I have found the following issue (and provide
a patch too):

Issue: In the configfile config.h there is a macro called LITTLE_ENDIAN.
In the file extract.h and extract.c the conditional compilation is based
on the macro BIG_ENDIAN which is never defined. So the macro LITTLE_ENDIAN
has no effect at all and all platforms are treated as little endian machines.
        
Patch: In the file extract.h the macro BIG_ENDIAN is set depending on
LITTLE_ENDIAN. Maybe we should use only one macro or define/undefine
both in the config.h.

------------------------------------------------------------------------------
Affected files ...


extract.c#2 edit
extract.h#2 edit

Differences ...


==== //...extract.c#2 (text) ====


@@ -77,27 +77,38 @@
 
 euint16 ex_getb16(euint8* buf,euint32 offset)
 {
-       return(ltb_end16(((*(buf+offset+1))<<8) + ((*(buf+offset+0))<<0)));
+#ifdef BIG_ENDIAN
+       return ((*(buf+offset+1))<<8) + *(buf+offset+0);
+#else
+       return ((*(buf+offset+0))<<8) + *(buf+offset+1);
+#endif
 }
 /*****************************************************************************/
 
 euint32 ex_getb32(euint8* buf,euint32 offset)
 {
-       return(ltb_end32(((euint32)buf[offset+3]<<24)+
-             ((euint32)buf[offset+2]<<16)+
-             ((euint32)buf[offset+1]<<8)+
-             ((euint32)buf[offset+0]<<0)));
+#ifdef BIG_ENDIAN
+    return ((*(buf+offset+3))<<24) +
+           ((*(buf+offset+2))<<16) +
+           ((*(buf+offset+1))<<8) +
+           (*(buf+offset+0));
+#else
+    return ((*(buf+offset+0))<<24) +
+           ((*(buf+offset+1))<<16) +
+           ((*(buf+offset+2))<<8) +
+           (*(buf+offset+3));
+#endif
 }
 /*****************************************************************************/
 
 void ex_setb16(euint8* buf,euint32 offset,euint16 data)
 {
 #ifdef BIG_ENDIAN
+       *(buf+offset+0) = data>>0;
+       *(buf+offset+1) = data>>8;
+#else
        *(buf+offset+1) = data>>0;
        *(buf+offset+0) = data>>8;
-#else
-       *(buf+offset+0) = data>>0;
-       *(buf+offset+1) = data>>8;
 #endif
 }
 /*****************************************************************************/
@@ -105,15 +116,15 @@
 void ex_setb32(euint8* buf,euint32 offset,euint32 data)
 {
 #ifdef BIG_ENDIAN
+       *(buf+offset+0) = data>> 0;
+       *(buf+offset+1) = data>> 8;
+       *(buf+offset+2) = data>>16;
+       *(buf+offset+3) = data>>24;
+#else
        *(buf+offset+3) = data>> 0;
        *(buf+offset+2) = data>> 8;
        *(buf+offset+1) = data>>16;
        *(buf+offset+0) = data>>24;
-#else
-       *(buf+offset+0) = data>> 0;
-       *(buf+offset+1) = data>> 8;
-       *(buf+offset+2) = data>>16;
-       *(buf+offset+3) = data>>24;
 #endif
 }
 /*****************************************************************************/



==== //....extract.h#2 (text) ====


@@ -27,6 +27,11 @@
 #include "disc.h"
 #include "types.h"
 /*****************************************************************************/
+#ifdef LITTLE_ENDIAN
+#undef BIG_ENDIAN
+#else
+#define BIG_ENDIAN
+#endif
 
 #ifdef BIG_ENDIAN

------------------------------------------------------------------------------

Greetings, Michael

Re: [Efsl-devel] Re: EFSL: Question about the regressiontest

[Michael De N. <mi...@fl...>]

michael.waeber wrote:

>Hello Michael
>
>On Wed, 07 Sep 2005 19:21:28 +0200, Michael De Nil wrote:
>
>
>MDN> In doregtest2 however, different filesystems are generated (fat12/16/32) 
>MDN> and each filesystem is tested with with different efsl configs (efsl 
>MDN> will be compiled each time with random config changes to ioman & 
>MDN> prealloc) for reading / writing.
>Where can I find the doregtest2? The tarballs contains only doregtest.
>  
>
Oops, my fault :-)
I will put it in our release-script and attach it for now to this mail.

We are also in the progress of putting our cvs on sourceforge. It is 
currently on a private server, so we're waiting for the admin to send us 
our cvs-tree.

>MDN> Ps: Please join our mailing list at
>MDN> https://lists.sourceforge.net/lists/listinfo/efsl-devel
>MDN> Ps2: What platform / device are you porting efsl to? :-)
>The CPU is a Motorola 68332 (m68k). There is a special portability
>layer (Hardware abstraction layer). We use SD cards.
>  
>
Sounds interesting, if you make any changes to efsl (improvements, bug 
fixes, new hardware support, ...) please let us know, so we can add 
these patches to our cvs-branch :-)


Thanks,

Michael