File system in battery backed SRAM - Embedded

This is a discussion on File system in battery backed SRAM - Embedded ; I have a system with a region of memory that is battery-backed. I'd like to use it as a file system - the idea is to make / read only and put files that need to be modified into the ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: File system in battery backed SRAM

  1. File system in battery backed SRAM

    I have a system with a region of memory that is battery-backed.

    I'd like to use it as a file system - the idea is to make / read only and
    put files that need to be modified into the battery backed file system....

    I've googled about but found nothing that would do this; just some vague
    references to ramdisks. But then I've found nothing that would let me pin
    a ramdisk into a specific region in memory and keep it there over reboots.

    So... Anyone know of any way to do this?

    Thanks...

  2. Re: File system in battery backed SRAM

    Wath about adding a hard disk, mmc or SD ?



  3. Re: File system in battery backed SRAM

    Captain Dondo wrote:

    > I have a system with a region of memory that is battery-backed.
    >
    > I'd like to use it as a file system - the idea is to make / read only and
    > put files that need to be modified into the battery backed file system....
    >
    > I've googled about but found nothing that would do this; just some vague
    > references to ramdisks. But then I've found nothing that would let me pin
    > a ramdisk into a specific region in memory and keep it there over reboots.
    >
    > So... Anyone know of any way to do this?
    >
    > Thanks...


    I've developed a little device block driver to do that.
    The way i do it is very simple:

    Look at some block devices, and choose one to use as a skeleton.
    The request function may be something like:


    #include

    // ....

    #define DEVICE_REQUEST do_rh_request

    static void
    do_rh_request( request_queue_t * q )
    {
    mm_segment_t fs;
    u_long start, len, addr, size;


    while ( TRUE )
    {
    INIT_REQUEST;

    minor = MINOR(CURRENT->rq_dev);

    start = CURRENT->sector << 9;
    len = CURRENT->current_nr_sectors << 9;
    size = YOUR_MEMORY_SIZE;

    if( (start + len) > size )
    {
    printk( KERN_ERR DEVICE_NAME ": bad access:
    block=%ld, count=%ld\n",
    CURRENT->sector,
    CURRENT->current_nr_sectors);
    end_request( FALSE );
    continue;
    }

    fs = get_fs();
    set_fs(KERNEL_DS);
    addr = YOUR_MEMORY_BASE_ADDRESS + start;

    if( ( CURRENT->cmd == READ ) )
    {
    // READ blocks
    copy_to_user ( CURRENT->buffer, (char *)addr, len );
    }
    else
    {
    // WRITE blocks
    copy_from_user ( (char*)addr, CURRENT->buffer,
    len );
    }

    set_fs(fs);
    end_request( TRUE );
    }
    }


    This code write or read directly to memory. Each 512 block will be saved in
    the SRAM. You may improve security by reserving one sector area and save in
    that point each sector before modify it.
    At system startup you may check the reserved area, and if it contains a
    stored record you may recover it (the system may be turned-off when writing
    to a sector).

    Then you may format your block device as you do for other disks, for example
    with minix, and mount it.

    Bye, Gabriele



+ Reply to Thread