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 <ppisa4li...@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@rtems.org > http://www.rtems.org/mailman/listinfo/rtems-devel > _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
