[PATCH 2/5] JFFS2: Import from eCos

Mon Sep 16 12:54:27 UTC 2013

Perhaps we should put an open project description together for
bringing some of this code together for an example / flash driver
framework.
-Gedare

On Mon, Sep 16, 2013 at 5:10 AM, Pavel Pisa <ppisa4lists at pikron.com> wrote:
> 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.
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
>