[PATCH 2/5] JFFS2: Import from eCos

[Pavel Pisa]

Hello Sebastian,

I have used successfully NOR Flash with RTEMS for many years.
Code is based on our NOR code used on MC683xx PXMC/MARS 8
on board code and in 683xx BDM  flasher

  http://sourceforge.net/p/bdm/code/ci/master/tree/m683xx/bdm-load/

There is included support for original 29xx Flash chips.
We use same infrastructure on RTEMS PiMX1/CSB336 based system
with StrataFlash (NOR) memory. The definition of the commands for StrataFlash
and may it be some lines of the code are taken from eCOS StrataFlash
driver. But algorithms infrastructure is from our plugable system.

Flash storage is accessed from single thread, so there is no support
for locking. We use same code in application/RTEMS loader without
OS as well. Code is attached in flashlib.tar.gz. It uses OMK,
so it can be directly compiled if RTEMS OMK template is used

http://rtime.felk.cvut.cz/gitweb/rtems-devel.git/tree/HEAD:/rtems-omk-template

The archive flashlib-no-os.targ.gz holds variant to be used without
OS which is extended to support both uniform and bottom-bootblock
variants of the StrataFlash. There is even code to allow self
relocation when code is run from Flash.

I am sending even some code of upperlayer libraries above our Flash
support. The KeyVal(ue) library is our mechanism to store critical
configuration data. It uses two independently erasable Flash regions
and stores uint32_t addressed blobs there. Allocation is quite simple,
it starts from bottom and fills fields up. It requires ability
to reprogram some unit size from ones to zero at start of each
data item. Entry can be invalidated that way and placed on the end
of the area. When area is full, there is garbage collection pass
which erases one area, compacts data from the other to that area
and erases the first area. Both areas keep copy of all data
and there is checksum on the end of each area. It is invalidated
(zeroed) before each write and then updated value is stored
at the address before original one. Two storages and this algorithm
ensures data integrity for interruption of any operation at any time.
Flash wearing is minimized that way as well. Code works from 8051
derivate, with LPC21xx, 17xx and under RTEMS.
It is not good for any large size data. Checksums are computed
each time over whole area etc. But for boot configuration data
and some runtime data it works quite well.

This example of flashlib use is in keyval.tar.gz. This is RTEMS
version and depends on some other our helper libraries.
I have not put time to pick up dependencies. But another fully
working version with all dependencies is part of uLAN SysLess
project

  http://sourceforge.net/p/ulan/sysless/ci/master/tree/libs4c/keyval/

All above code should already use RTEMS compatible license.

Other source of inspiration or even actually usable code
is Chris's code from 68xx BDM

  http://sourceforge.net/p/bdm/code/ci/master/tree/m68k/flashlib/

Other Flash/MTD infrastructure implementation with support of NAND's
as well can be found in Linux kernel, U-boot or in Pengutronix's BareBox

  http://git.pengutronix.de/?p=barebox.git;a=tree;f=drivers/mtd;hb=HEAD

But all that code is tightly related/copied from Linux so
license with RTEMS exception would be a problem.

Best wishes,

             Pavel


On Monday 16 of September 2013 09:17:38 Sebastian Huber wrote:
> On 2013-09-15 04:12, Chris Johns wrote:
> > Sebastian Huber wrote:
> >> On 2013-09-14 00:54, Chris Johns wrote:
> >>> Where is the device support ?
> >>
> >> I didn't import the flash device drivers from eCos. See <rtems/jffs2.h>
> >> in the RTEMS support patch for the device support. The application has
> >> to provide the flash access operations.
> >
> > Would it make sense to have drivers added to libchip for commonly used
> > devices ?
>
> Yes, a flash driver frame work is definitely something we need in RTEMS. 
> We have one for NAND flashes which uses a similar structure than Linux MTD.
>  We may also contribute this in the future, but currently I have no time
> for this.
>
> For the NOR flashes there is some support in the eCos code base, so we
> should consider to make use of it.
>
> > Where can we find a real driver for a real device ? I feel we need real
> > drivers as examples in RTEMS.
>
> The file system tests work with a RAM based NOR simulator.  If you have a
> flash driver, then its pretty easy to provide the interface for JFFS2.
>
> > I do not like the "application" needing to handle this. I think BSPs
> > should provide drivers and not applications. The device is specific to a
> > board and it is the role of the BSP to handle this sort of thing. If I
> > use a BSP that has suitable flash devices I would expect the BSP to
> > contain the support. It may be the application that enables and
> > configures the support given a correctly working and mapped set of
> > drivers from the BSP.
>
> Using the current approach with a function pointer based interface is
> flexible (e.g. you can use whatever you want) and makes it possible to
> provide the JFFS2 support without a flash driver framework.  I currently
> don't have the resources for a flash driver framework for RTEMS.  This
> might be also something for the next GSoC.
>
> > I regretted not providing a real driver interface to the flash memory in
> > the flashdisk block device. Having a real device interface means it can
> > be opened and managed without the file system, for example erasing or
> > testing the devices.
> >
> >>> Clause 2 concerns me.
>
> This is a standard 2-clause BSD license.
>
> >>> Is mixing GPLv2+exception and a BSD type license like this ok ?
> >
> > ??
>
> Yes, the original red-black tree implementation is under BSD license.  The
> later contributions are under GPLv2+exception.
>
> >> This LICENSE file is part of the Linux import patch.
> >
> > Found it. Thanks.
> >
> > Do any of the files that contain the reference to the LICENSE file get
> > installed ?
> >
> > Chris
>
> What do you mean with installed?
>
> The only header file visible to applications is the <rtems/jffs2.h> file
> which is under the RTEMS license.  Everything else is only required to
> produce the JFFS2 object files.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: flashlib.tar.gz
Type: application/x-tgz
Size: 3228 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20130916/fbfbaa91/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: keyval.tar.gz
Type: application/x-tgz
Size: 21098 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20130916/fbfbaa91/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: flashlib-no-os.tar.gz
Type: application/x-tgz
Size: 5162 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20130916/fbfbaa91/attachment-0005.bin>