rtems_ramdisk_config on leon2
Alan Cudmore
Alan.P.Cudmore at nasa.gov
Mon Jan 28 18:15:32 UTC 2008
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
More information about the users
mailing list