AW: Re: Some thoughts about the flash device driver and the flashdisk block driver

[Astrid Hanssen]

Hi Chris, 

> > 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.

This is very fine as I used your mcf5235 implementation as a basis for
the mcf5208 :-)

> [shell, mounting, and scripting]

This looks nice. Is there any documentation about this yet?
I did not find enough info for feeling able to play with it.

> > After the flash driver will be thoroughly tested, I feel like
> > submitting it to libchip/flash.
> 
> Please do. The more drivers the better. :-)

Yes, and the mcf5208 BSP also.
But for the BSP I will probably need some help with committing.
I will have to ask Joel about this when time has come.

> /**
>   * 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;
> }

Thank you very much, this makes the idea more clear to me.
I will try it out.

I am still not sure whether it is recommended to include
these parts into bspstart.c, or whether they should reside
in the application. In the first thought, they belong to
the BSP because the hardware is well defined, and therefore
this driver can also be.

And why isn't rtems_flashdisk_io_ops contained in flashdisk.c?
I do not see any application or BSP dependencies.

Sorry for my newbie questions, just trying to understand RTEMS
and its concepts better.

Regards,
Astrid