rtems_ramdisk_config on leon2

Aitor Viana aitor.viana.sanchez at esa.int
Tue Jan 29 02:32:06 CST 2008


Hi Alan,

yes, of course, I will send you my RTEMS implementation by today. Let me
just clean it up a little bit ;)

But the question is still open, Can be modified at execution time the
rtems_ramdisk_configuration RTEMS structure? Or is needed to get it defined
already at compilation time.

Best regards,

Aitor


On Jan 28, 2008 7:15 PM, Alan Cudmore <Alan.P.Cudmore at nasa.gov> wrote:

> Hi Aitor,
> You are a little ahead of us with using the OSAL to format and mount
> filesystems on RTEMS :) I can try to run this on my Coldfire/RTEMS
> system, but I might need to get your RTEMS implementation to try it out.
>
>
> For everyone else, I can provide a little background on what we are
> trying to do :
> We use the OSAL to run our generic software on a wide range of
> operating systems. When it comes to file systems we want to do the
> following things:
> 1. Keep consistent path names in our software. For example we have
> the following pathname in the OSAL: "/ramdisk/apps/myfile.dat"
> Using the OSAL it might map to the following on different systems:
> Windows : "F:\apps\myfile.dat"
> Linux:        "/home/alan/embedded/ramdisk/apps/myfile.dat"
> vxWorks:   "RAM:0:/apps/myfile.dat"
> RTEMS:    "/ramdisk/apps/myfile.dat"  ( as you can see a system like
> RTEMS might not really need this )
>
> 2. Use the same API to format and mount different volumes. The format
> is mostly used to create RAM disks on systems such as vxWorks or
> RTEMS . Then the mount command can be used to either mount the file
> system, or in the case of running the application on a desktop
> system, it can just set up the path mapping ( would not want the
> application to start making filesystems on someones desktop Windows
> or Linux system )
>
> So the generic OSAL application might look like:
>
> OS_mkfs ( ... )
> OS_mount ( ... )
> OS_open ( "/ramdisk/apps/myfile.dat", ... )
>
> And it can run on multiple platforms without changing this code.
>
> Now in practice, this file system layer has worked, but it has proven
> to be one of the more confusing aspects of the OSAL. Many of our apps
> now just have the BSP setup all of the filesystems we need using the
> native calls and use the OSAL to simply provide the filename/path
> translation. If it is used this way, it can probably be greatly
> simplified and even have it's mapping information read from a text
> file, rather than being compiled in.
> The only drawback would be the inability to create new RAM disks on
> the fly.
> I'm interested in opinions on how useful this type of path
> translation is.
>
> Alan
>
>
> On Jan 28, 2008, at 10:53 AM, Aitor Viana wrote:
>
> > Hi all,
> >
> > I am trying to set up the filesystem capabilities under the OSAL
> > layer over RTEMS. Basically implementing mount, unmount and mkfs
> > routines.
> > I want to have capabilities to mount external RAM disk filesystems,
> > mapped out from the kernel space, in an SDRAM memory placed from
> > 0x60000000 on for instance.
> >
> > The OSAL layer gets this volume table structure:
> >
> > OS_VolumeInfo_t OS_VolumeTable [NUM_TABLE_ENTRIES] =
> > {
> >     /* Dev Name  Phys Dev  Vol Type        Volatile?  Free?
> > IsMounted? Volname  MountPt BlockSz */
> >     {"unused",   "unused", FS_BASED,        TRUE,      TRUE,
> > FALSE,     " ",      " ",     0        },
> >     {"unused",   "unused", FS_BASED,        TRUE,      TRUE,
> > FALSE,     " ",      " ",     0        },
> >     {"unused",   "unused", FS_BASED,        TRUE,      TRUE,
> > FALSE,     " ",      " ",     0        },
> >     {"unused",   "unused", FS_BASED,        TRUE,      TRUE,
> > FALSE,     " ",      " ",     0        }
> > };
> >
> >
> > and I already performed a sort of translation to RTEMS declaring
> > this structure hereafter:
> > fstab_t OS_MountTable[NUM_TABLE_ENTRIES] =
> > {
> >     {OS_VolumeTable[0].DeviceName, OS_VolumeTable[0].MountPoint,
> > &msdos_ops, RTEMS_FILESYSTEM_READ_WRITE, FSMOUNT_MNT_OK |
> > FSMOUNT_MNTPNT_CRTERR | FSMOUNT_MNT_FAILED, 0 },
> >     {OS_VolumeTable[1].DeviceName, OS_VolumeTable[1].MountPoint,
> > &msdos_ops, RTEMS_FILESYSTEM_READ_WRITE, FSMOUNT_MNT_OK |
> > FSMOUNT_MNTPNT_CRTERR | FSMOUNT_MNT_FAILED, 0 },
> >     {OS_VolumeTable[2].DeviceName, OS_VolumeTable[2].MountPoint,
> > &msdos_ops, RTEMS_FILESYSTEM_READ_WRITE, FSMOUNT_MNT_OK |
> > FSMOUNT_MNTPNT_CRTERR | FSMOUNT_MNT_FAILED, 0 },
> >     {OS_VolumeTable[3].DeviceName, OS_VolumeTable[3].MountPoint,
> > &msdos_ops, RTEMS_FILESYSTEM_READ_WRITE, FSMOUNT_MNT_OK |
> > FSMOUNT_MNTPNT_CRTERR | FSMOUNT_MNT_FAILED, 0 }
> > };
> >
> >
> > The other thing we need is the rtems_bdbuf_configure structure, is
> > defined as:
> > rtems_bdbuf_config rtems_bdbuf_configuration[] = {
> >     //  BlockSize BlockNum    Address
> >     {512,         1024,          NULL}
> > };
> >
> > and the rtems_ramdisk_configuration structure, this is the funny
> > one. Later I'll detail the definition of this structure. But I
> > would to define it like:
> >
> > rtems_ramdisk_config rtems_ramdisk_configuration[NUM_TABLE_ENTRIES]
> > = {
> >     //  BlockSize BlockNum    Address
> >     {0,         0,          0x0},
> >     {0,         0,          0x0},
> >     {0,         0,          0x0},
> >     {0,         0,          0x0},
> > };
> >
> >
> > The functions to perform the mkfs and mount actions are:
> >
> > int32 OS_mkfs (char *address, char *devname,char * volname, uint32
> > blocksize,
> >                uint32 numblocks)
> > {
> >     msdos_format_request_param_t rqdata;
> >     int i = 0;
> >
> >
> >     // find a FREE entry in the OS_VolumeTable structure
> >     for ( i = 0; i < NUM_TABLE_ENTRIES; i++)
> >     {
> >         if ( OS_VolumeTable[i].FreeFlag == TRUE )
> >             break;
> >     }
> >
> >     // There is no entry available in the OS_VolumeTable structure
> >     if ( i >= NUM_TABLE_ENTRIES )
> >         return OS_FS_ERROR;
> >
> >     // Fill up the OS_VolumeTable entry
> >     strcpy(OS_VolumeTable[i].DeviceName, devname);
> >     strcpy(OS_VolumeTable[i].VolumeName, volname);
> >     strcpy(OS_VolumeTable[i].PhysDevName, "");
> >     rtems_ramdisk_configuration[i].block_size = blocksize;
> >     rtems_ramdisk_configuration[i].block_num = numblocks;
> >     rtems_ramdisk_configuration[i].location = (void*)address;
> >
> >     // We need to format the filesystem as well
> >     memset(&rqdata, 0, sizeof(rqdata));
> >     rqdata.OEMName = "RTEMS";
> >     rqdata.VolLabel = volname;
> >     rqdata.fattype = MSDOS_FMT_FATANY;
> >     rqdata.quick_format = TRUE;
> >     if( msdos_format(OS_VolumeTable[i].DeviceName, &rqdata) < 0 )
> >     {
> >         OS_MSG_DBG("Error formating the new filesystem %s(%d) at 0x%
> > x", OS_VolumeTable[i].DeviceName, i, rtems_ramdisk_configuration
> > [i].location);
> >         return OS_FS_ERROR;
> >     }
> >
> >     // Modify the Free flag in order to avoid future problems
> >     OS_VolumeTable[i].FreeFlag = FALSE;
> >
> >     OS_MSG_DBG("New filesystem %s(%d) created at 0x%x",
> > OS_VolumeTable[i].DeviceName, i, rtems_ramdisk_configuration
> > [i].location);
> >     return OS_FS_SUCCESS;
> >
> > }
> >
> > int32 OS_mount (const char *devname, char* mountpoint)
> > {
> >     rtems_status_code rtems_status;
> >     int i;
> >
> >     for ( i = 0; i < NUM_TABLE_ENTRIES; ++i)
> >     {
> >         if ( (strcmp(devname, OS_VolumeTable[i].DeviceName) == 0) &&
> >              (OS_VolumeTable[i].FreeFlag == FALSE) )
> >             break;
> >     }
> >
> >     if ( i >= NUM_TABLE_ENTRIES )
> >         return OS_FS_ERROR;
> >
> >     // Fill up the mount point
> >     strcpy(OS_VolumeTable[i].MountPoint, mountpoint);
> >
> >     // now we need to create a mount point. The hook to the ramdis
> > filesystem.
> >     rtems_status = (rtems_status_code)rtems_fsmount(OS_MountTable,
> >             sizeof(OS_MountTable)/sizeof(OS_MountTable[i]), NULL );
> >
> >     if ( rtems_status == RTEMS_SUCCESSFUL )
> >         return OS_FS_SUCCESS;
> >     else
> >         return OS_FS_ERROR;
> > }
> >
> > In the OS_mkfs function, everything is filled and set up correctly,
> > just to leave the file-system ready to get mounted. The mount
> > function, performs the mounting of the file-system.
> >
> > The problem is that, if I define the rtems_ramdisk_configuration
> > like is stated before (all the fields to 0 value), I got an error
> > trying to format the filesystem (in the msdos_format function),
> > but, if I define the rtems_ramdisk_configuration like this:
> >
> >     //  BlockSize BlockNum    Address
> >     {512,       2048,       0x62000000},
> >     {0,         0,          0x0},
> >     {0,         0,          0x0},
> >     {0,         0,          0x0},
> >
> > with the first entry already filled, everything goes perfect. For
> > me looks like RTEMS assumes that this rtems_ramdisk_configuration
> > structure is statically configured, and no dynamic modification can
> > be performed. Am I doing something wrong, or it is true that it is
> > not possible to modify the rtems_ramdisk_configuration structure at
> > execution time.
> >
> >
> > I don't know whether my explanation was clear enough...
> >
> > Thanks in advance,
> >
> > cheers,
> >
> > Aitor
> >
> > _______________________________________________
> > rtems-users mailing list
> > rtems-users at rtems.com
> > http://rtems.rtems.org/mailman/listinfo/rtems-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rtems.org/pipermail/rtems-users/attachments/20080129/d82119b4/attachment.html>


More information about the rtems-users mailing list