problems with RFS filesystem and mkdir
Matthew J Fletcher
amimjf at gmail.com
Mon Mar 18 18:35:55 UTC 2013
Hi,
Alas the mkdir() is the first filesystem operation i am doing. I am not
sure if i can send attachments to the list so i've cut and pasted the
relivant functions below. I guess the following would run on any BSP, its
just a 256k block of sram. If there is a BSP with enough memory the base
pointer for the filesystem could just be a big malloc().
------------------- snip -------------------------
#define CONFIGURE_IDLE_TASK_BODY rtems_idle
#define CONFIGURE_EXTRA_TASK_STACKS (CONFIGURE_MAXIMUM_TASKS *
RTEMS_MINIMUM_STACK_SIZE)
#define CONFIGURE_MAXIMUM_DRIVERS 6
/* NOTICE: the clock driver is explicitly disabled */
#define CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER
#define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
#define CONFIGURE_DISABLE_CLASSIC_API_NOTEPADS
#define CONFIGURE_MAXIMUM_TASKS 40 // TX MAX_THREAD
#define CONFIGURE_MAXIMUM_TIMERS 40 // TX MAX_TIMER
#define CONFIGURE_MAXIMUM_SEMAPHORES 40 // TX MAX_MUTEX
#define CONFIGURE_MAXIMUM_MESSAGE_QUEUES 40 // TX MAX_MSG_QUEUE
#define CONFIGURE_MAXIMUM_PARTITIONS 5
#define CONFIGURE_MAXIMUM_REGIONS 5
#define CONFIGURE_MAXIMUM_PORTS 0
#define CONFIGURE_MAXIMUM_PERIODS 0
#define CONFIGURE_MAXIMUM_BARRIERS 0
#define CONFIGURE_MICROSECONDS_PER_TICK 10000 /* 10 milliseconds */
#define CONFIGURE_TICKS_PER_TIMESLICE 50 /* 50 milliseconds */
#define CONFIGURE_APPLICATION_NEEDS_LIBBLOCK
#define CONFIGURE_BDBUF_MAX_READ_AHEAD_BLOCKS 2
#define CONFIGURE_BDBUF_MAX_WRITE_BLOCKS 8
#define CONFIGURE_SWAPOUT_TASK_PRIORITY 15
#define CONFIGURE_USE_IMFS_AS_BASE_FILESYSTEM
#define CONFIGURE_FILESYSTEM_RFS
#define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS 10
#define CONFIGURE_RTEMS_INIT_TASKS_TABLE
#define CONFIGURE_INIT
#include <rtems/confdefs.h>
uint32_t rtems_flashdisk_configuration_size =1;
const char* flash_driver = "/dev/fdda"; //
RTEMS_FLASHDISK_DEVICE_BASE_NAME, 1st device
const char* flash_path = "/flash";
uint32_t rtems_nvdisk_configuration_size =1;
const char* sram_driver = "/dev/nvda"; // RTEMS_NVDISK_DEVICE_BASE_NAME,
1st device
const char* sram_path = "/sram";
/**
* Let the IO system allocation the next available major number.
*/
#define RTEMS_DRIVER_AUTO_MAJOR (0)
#define FLASHDISK_SEGMENT_COUNT 8 /* 128*/ // Spansion S29GL128S,
128Mbit part
#define FLASHDISK_SEGMENT_SIZE (128 * 1024) // Spansion S29GL128S, 128k
sized sectors
#define FLASHDISK_BLOCK_SIZE 512
#define FLASHDISK_BLOCKS_PER_SEGMENT (FLASHDISK_SEGMENT_SIZE /
FLASHDISK_BLOCK_SIZE)
#define FLASHDISK_SIZE (FLASHDISK_SEGMENT_COUNT * FLASHDISK_SEGMENT_SIZE)
/**
* The SRAM Device setup
*/
rtems_nvdisk_device_desc rtems_sram_device_descriptor[] =
{
{
flags: 0,
base: 0,
size: 256 * 1024, // 256K (Adjust when ROM.ld, _IMFS_DiskSize is
changed)
nv_ops: &rtems_nvdisk_sram_handlers
}
};
const rtems_nvdisk_config rtems_nvdisk_configuration[] =
{
{
block_size: 512,
device_count: 1,
devices: &rtems_sram_device_descriptor[0],
flags: 0,
info_level: 0
}
};
/**
* Create the SRAM Disk Driver entry.
*/
rtems_driver_address_table rtems_sram_ops = {
initialization_entry: rtems_nvdisk_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
};
int setup_sram_disk (int cold_boot)
{
rtems_device_major_number major;
rtems_status_code sc;
// settings
rtems_sram_device_descriptor[0].base = (unsigned long)eTalus_IMFS_start;
if (cold_boot)
{
memset(rtems_sram_device_descriptor[0].base, 0xff,
rtems_sram_device_descriptor[0].size );
}
/*
* Register the NV Disk driver.
*/
sc = rtems_io_register_driver (RTEMS_DRIVER_AUTO_MAJOR,
&rtems_sram_ops, &major);
}
/*
*
* RFS on SRAM
*
*/
void mount_rfs_on_sram(int cold_boot)
{
rtems_rfs_format_config config;
setup_sram_disk (cold_boot);
// zero is a good set of defaults
memset (&config, 0, sizeof (rtems_rfs_format_config));
if (rtems_rfs_format (sram_driver, &config) < 0)
{
sprintf(inital_print_buffer,"error: format of %s failed: %s\n",
sram_driver, strerror (errno));
UART0_SendStr(inital_print_buffer);
}
if (mount_and_make_target_path(
sram_driver,
sram_path,
RTEMS_FILESYSTEM_TYPE_RFS,
RTEMS_FILESYSTEM_READ_WRITE,
NULL
) != 0)
{
sprintf(inital_print_buffer,"error: mount of %s to %s failed:
%s\n", sram_driver, sram_path, strerror (errno));
UART0_SendStr(inital_print_buffer);
}
rc = rtems_mkdir("sram/DB", S_IRWXU | S_IRGRP | S_IXGRP | S_IROTH |
S_IXOTH);
}
------------------- end ------------------------
On 18 March 2013 17:42, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:
> Is this reproducible with something you can share?
>
> Looking at the source, I think this case is that you
> filled the filesystem and there were no free blocks.
> But I am looking at the head and not that familiar
> with this filesystem.
>
> --joel
>
> On 3/18/2013 12:20 PM, Matthew J Fletcher wrote:
>
>> Hi,
>>
>> I have an RFS filesystem using the nvram device, its formatted ok and
>> mount_and_make_target_path() also worked ok. But attempting to mkdir()
>> causes a really lowlevel issue.
>>
>> The callstack;
>>
>> rtems_rfs_block_map_find() at rtems-rfs-block.c:246 0x81198bd8
>> rtems_rfs_block_map_next_**block() at rtems-rfs-block.c:353 0x81198d1e
>> rtems_rfs_dir_lookup_ino() at rtems-rfs-dir.c:204 0x8119951c
>> rtems_rfs_rtems_eval_for_make(**) at rtems-rfs-rtems.c:440 0x8118e142
>> IMFS_evaluate_for_make() at imfs_eval.c:435 0x81190718
>> mknod() at mknod.c:64 0x81183d5c
>> mkdir() at mkdir.c:29 0x81183cf0
>> build() at rtems_mkdir.c:101 0x811843a0
>> rtems_mkdir() at rtems_mkdir.c:136 0x811843a0
>>
>>
>> the rtems_rfs_block_pos_block_**past_end macro is failing and causing
>> the return of ENXIO.
>>
>> The two arguments to the macro are;
>>
>> bpos->bno = 1
>> bpos->boff = 0
>> bpos->block = 0
>>
>> map->size->count = 1
>> map->size->offset = 0
>>
>> Which seems to me the cause of ENXIO being returned, but i dont know how
>> my BSP could affect this.
>>
>> Do people use RFS in production systems ? i am using the 4.10.2 sources.
>>
>>
>> regards
>> ---
>> Matthew J Fletcher
>>
>>
>
> --
> Joel Sherrill, Ph.D. Director of Research & Development
> joel.sherrill at OARcorp.com On-Line Applications Research
> Ask me about RTEMS: a free RTOS Huntsville AL 35805
> Support Available (256) 722-9985
>
>
--
regards
---
Matthew J Fletcher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20130318/867d8c80/attachment-0001.html>
More information about the users
mailing list