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