rtems_ramdisk_config on leon2
Aitor Viana
aitor.viana.sanchez at esa.int
Tue Jan 29 08:32:06 UTC 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://lists.rtems.org/pipermail/users/attachments/20080129/d82119b4/attachment-0001.html>
More information about the users
mailing list