getcwd syscall fails on 3rd subfolder

Chris Johns chrisj at rtems.org
Thu Apr 10 01:58:30 UTC 2014


On 9/04/2014 9:46 pm, Hoefle Marco wrote:
> Hello Chris,
> The root is IMFS and the FAT12 partition is mounted to /mnt
> Let me explain how the fatfs image is linked to the application:
>
> 1) a fat12 image is generated using:
>   /sbin/mkfs.vfat -F 12 -S 512 -s 1 -r 512 -f 1 -v fs_image
>

I assume this is some sort of Linux type command.

> 2) the image is initialized with default folders/files:
> mcopy -b/ -i fs_image) content/* ::/

Ok.

>
> 3) a C array is generated using:
> xxd -i fs_image > fs_image.c

Ok.

>
> 4) This large C file is compiled and linked into the RTEMS application.
>
> I wanted to use a FAT32 image first but that didn't work at all. RTEMS
> mount was successful but the mounted disk was empty.
> Could it be that the image generated with mkfs.vfat is not compatible
> with the RTEMS dosfs implementation?

It could be or it could a bug in RTEMS. It is hard to say. I do not have 
this kernel available to try and test with.

Are you in a position to the latest RTEMS kernel from git ?

Chris

>
>
>
> This is how the FAT12 disk is mounted:
>
>
> extern unsigned int fatfs_image_len;
> extern unsigned char fatfs_image[];
>
> /**
> * The RAM Disk configuration.
> */
> rtems_ramdisk_config rtems_ramdisk_configuration[] =
> {
> 		{
> 				.block_size = 512,
> 				.location = fatfs_image
> 		}
> };
>
>
> /**
> * The number of RAM Disk configurations.
> */
> size_t rtems_ramdisk_configuration_size = 1;
>
> /**
> * Create the RAM Disk Driver entry.
> */
> rtems_driver_address_table rtems_ramdisk_io_ops = {
> 		initialization_entry: ramdisk_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
> };
>
>
> static int setup_ramdisk (const char* mntpath)
> {
> 	rtems_device_major_number major;
> 	rtems_status_code sc;
>
> 	rtems_ramdisk_configuration[0].block_num =
> 			fatfs_image_len /
> rtems_ramdisk_configuration[0].block_size;
>
> 	sc = rtems_io_register_driver (
> 			RTEMS_DRIVER_AUTO_MAJOR,
> 			&rtems_ramdisk_io_ops,
> 			&major);
>
> 	if (sc != RTEMS_SUCCESSFUL) {
> 		nts_printf ("error: ramdisk driver not initialised:
> %s\n",
> 				rtems_status_text (sc));
>
> 		return NTS_FAILURE;
> 	}
>
> 	nts_printf ("RAM Disk registered\n");
>
> 	mkdir(mntpath, 0777);
>
> 	sc = mount("/dev/rda", mntpath, "dosfs",
> RTEMS_FILESYSTEM_READ_WRITE, NULL);
> 	nts_printf("mount return: %d\n", sc);
>
> 	nts_printf("ram disk addr: 0x%08x\n", (unsigned int)
> (rtems_ramdisk_configuration[0].location));
>
> 	return NTS_OK;
> }
>
>
>
>
>
> -----Original Message-----
> From: Chris Johns [mailto:chrisj at rtems.org]
> Sent: Mittwoch, 9. April 2014 03:06
> To: Hoefle Marco; rtems-users at rtems.org
> Subject: Re: getcwd syscall fails on 3rd subfolder
>
> On 8/04/2014 10:22 pm, Hoefle Marco wrote:
>>> Hello,
>>> we use the Gaisler RTEMS Kernel 4-10-1.2.14 on a GR712RC board.
>
>> I have not used their version or hardware.
>
>>> The following function is used to  determine the current working
>>> directory on a fatfs:
>>>
>>>
>>> static NtsError fs_pwd_do( int argc, char **argv)
>>> {
>>>           char *ret = getcwd(NULL, 0);
>>>           if(ret) {
>>>                   nts_printf("%s\n", ret);
>>>                   free(ret);
>>>                   return NTS_OK;
>>>           }
>>>
>>>           nts_printf("getcwd failed, errno: %d, MAXPATHLEN: %d\n",
> errno,
>>> MAXPATHLEN);
>>>           return NTS_FAILURE;
>>> }
>>>
>>>
>>> The fatfs was generated using:
>>>           @dd if=/dev/zero of=$(NAME) bs=256 count=1024 > /dev/null
>>           /sbin/mkfs.vfat -F 12 -S 512 -s 1 -r 512 -f 1 -v $(NAME)
>>
>>
>> This is what happens:
>>
>> cassis> fs mount
>> RAM Disk registered
>> mount return: 0
>> ram disk addr: 0x64000000
>
> This would seem to be a root disk. Is this an IMFS disk or a RAM disk ?
>
>> cassis> fs ls
>> 3920 dev
>> 16384 mnt
>> cassis> fs pwd
>> /
>> cassis> fs cwd mnt
>> changed to mnt
>> cassis> fs pwd
>> /mnt
>> cassis> fs ls
>> 512 template
>> cassis> fs cwd template
>> changed to template
>> cassis> fs pwd
>> /mnt/template
>> cassis>
>> cassis> fs ls
>> 512 .
>> 16384 ..
>> 512 param
>> 512 logs
>> cassis> fs cwd logs
>> changed to logs
>> cassis> fs pwd
>> getcwd failed, errno: 2, MAXPATHLEN: 1024
>
> The getcwd code looks up the path to the parent until the root to build
> the path. There maybe something wrong here if the root is not IMFS.
>
> Chris
>
>> cassis>
>>
>>
>> The folder logs is definitely existing:
>> cassis> fs dump /mnt/template/logs/housekeeping/log0
>> file size: 10
>> 64 61 63 30 3a 20 31 30 30 0a
>>
>> A non existing file leeds to:
>> cassis> fs dump /mnt/template/logs/housekeeping/log9
>> file size: 10
>> failure, ret: -1, errno: 2
>>
>> Has anybody an idea why getcwd() fails (errno 2 means not existent)?
>>
>> Cheers,
>> Marco
>>
>>
>>
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-users
>>
>
>
>



More information about the users mailing list