Some thoughts about the flash device driver and the flashdisk block driver

[Chris Johns]

Astrid Hanssen wrote:
> 
> I am happy to find there was a new concept invented recently, the
> libchip/flash device driver(s) and a flashdisk block driver.
> Because I believe this to be a very nice thing and opens the door
> to many new applications, I immediately decided to integrate this
> to the BSP I am working on.

Excellent. I have it here on a mcf5235 board and it is working well.

I can mount a nfs file system and can copy data to the flash disk. The shell 
now has mount command support plus a BSD copy (cp) command. I added scripting 
to the shell as well so I have an init script of:

  mkdir /work
  mount -t nfs kiwi:/opt/work /work
  mkdir /fd
  mount -t msdos /dev/flashdisk0 /fd

The shell also has a msdosfmt command you can use with:

  msdosfmt /dev/flashdisk0

To erase the flash disk you the ioctl call as shown in the flashdisk.h header 
file.

> 
> Its the Coldfire MCF5208 evaluation board, which contains an AMD
> AM29BDD160G 16/32-bit flash device.
> Although I already started writing my own flash chip driver, now
> I like to switch over to the chip driver format defined by
> flashdisk.h and the example that can be found in libchip/flash.
> After the flash driver will be thoroughly tested, I feel like
> submitting it to libchip/flash.

Please do. The more drivers the better. :-)

> However, not the whole area of the flash chip shall be available
> to the libblock flashdisk block driver. The device will also have
> to contain the RTEMS software itself as well as some type of an
> optimized flash parameter storage system.
> The latter may also use the flash device driver, but not the
> flashdisk block driver.
> 
> What I was now looking for is a way to let the flashdisk driver
> know which area of the device(s) it may use and which not.
> Unfortunately I found nothing like that yet.
> As this might going to be a very common case (BSPs that contain a
> flash chip tend to have their RTEMS software booting from it)
> perhaps there should be a method to manage this.
> Maybe I missed something.
> Otherwise, a solution might become necessary.

You are only missing the documentation I am yet to write on how to handle just 
this case.

The flash device interface allows you to define any part of the device or all 
of the device. You can have more than one device and each device can define 
only the parts you want.

The driver in libchip/flash defines all the segments as a default but you do 
not need to use the segment description. On the mcf5235 I have the dbug boot 
monitor in the lower part of the flash so have a similar situation. I have a 
device based at 0xFFE00000 in the address space and only want to use the last 
26 segments of the flash at an offset in the device of 0x00050000. The set up is:

/**
  * The Flash Device Driver configuration.
  */
const rtems_am29lv160_config rtems_am29lv160_configuration[] =
{
   {
     bus_8bit: 0,
     base:     (void*) 0xFFE00000
   }
};

/**
  * The number of AM29LV160 configurations.
  */
uint32_t rtems_am29lv160_configuration_size = 1;

/**
  * The Flash Segment descriptor. The mcf5235 board uses the
  * bottom part of the flash for the dBug monitor.
  */
const rtems_fdisk_segment_desc rtems_mcf5235_segment_descriptor[] =
{
   {
     count:   26,
     segment: 0,
     offset:  0x00050000,
     size:    RTEMS_FDISK_KBYTES (64)
   }
};

/**
  * The Flash Device descriptor.
  */
const rtems_fdisk_device_desc rtems_mcf5235_device_descriptor[] =
{
   {
     segment_count: 1,
     segments:      &rtems_mcf5235_segment_descriptor[0],
     flash_ops:     &rtems_am29lv160_handlers
   }
};

/**
  * The Flash Disk configuration.
  */
const rtems_flashdisk_config rtems_flashdisk_configuration[] =
{
   {
     block_size:         512,
     device_count:       1,
     devices:            &rtems_mcf5235_device_descriptor[0],
     flags:              RTEMS_FDISK_BLANK_CHECK_BEFORE_WRITE,
     unavail_blocks:     256,
     compact_segs:       100,
     avail_compact_segs: 100,
     info_level:         0
   }
};

/**
  * The number of Flash Disk configurations.
  */
size_t rtems_flashdisk_configuration_size = 1;

/**
  * Create the Flash Disk Driver entry.
  */
rtems_driver_address_table rtems_flashdisk_io_ops = {
   initialization_entry: rtems_fdisk_initialize,
   open_entry:           rtems_blkdev_generic_open,
   close_entry:          rtems_blkdev_generic_close,
   read_entry:           rtems_blkdev_generic_read,
   write_entry:          rtems_blkdev_generic_write,
   control_entry:        rtems_blkdev_generic_ioctl
};

int
setup_flashdisk (const char* mntpath)
{
   rtems_device_major_number major;
   rtems_status_code         sc;

   /*
    * Register the Flash Disk driver.
    */
   printf ("Register Flash Disk Driver: ");
   sc = rtems_io_register_driver (RTEMS_DRIVER_AUTO_MAJOR,
                                  &rtems_flashdisk_io_ops,
                                  &major);
   if (sc != RTEMS_SUCCESSFUL)
   {
     printf ("error: flashdisk driver not initialised: %s\n",
             rtems_status_text (sc));
     return 1;
   }

   printf ("successful\n");

   return 0;
}

> A quick hack will be to define a board-specific chip driver that
> contains only the segments the flashdisk shall have access to.

Yes coping the driver would be a hack.

> But I would prefer a general-purpose chip library and handle such
> area definitions in the rtems_flashdisk_config structure.

This is what happens above with the example I posted.

> Another useful idea might be to separate the libchip flash device
> handlers definition from the libblock flashdisk to have it more
> generally available, but to include it and use it in flashdisk.

The handlers can be generic. The segment descriptors are what you play with.

> I am wondering what you are thinking about this, or what I have
> missed.

I think the segment descriptors is what you need rather than the handlers.

Regards
Chris