Flash disk RFS format errors, "no segment mapping"

Matthew J Fletcher amimjf at gmail.com
Mon Aug 12 17:58:57 UTC 2013


Nick,

See my posted example
http://www.rtems.com/ml/rtems-users/2013/march/msg00156.html

This formatted ok for a few people on the list. I had problems with
operations like mkdir afterwards, but it was fine for others on other
platforms.




On 12 August 2013 09:37, Nick Withers <nick.withers at anu.edu.au> wrote:

> Hullo all,
>
> I'm trying to get a flash disk (S29GLxxxN) going on ye olde MVME3100
> with RFS and'm having troubles...
>
> Here's some console output:
> ____
>
> Registering /dev/console as minor 0 (==/dev/ttyS0)
> init.c:89: init(): Started
> fs.c:42: fs_init(): Extracting file-system tar...
> fs.c:47: fs_init(): File-system tar extracted
> fdisk:read-block:0
> fdisk:read-block: no segment mapping: 0
> flash.c:203: flash_disk_mount(): Failed to mount flash device "/dev/fdda"
> to "/etc/daq". Error: "I/O error"
> flash.c:155: flash_disk_init(): Failed to mount flash file-system. Error:
> "I/O error"
> fdisk:erase-disk
> fdisk: erase-flash:00
> fdisk: device-erase: 00
> fdisk:recover-block-mappings:00-000
> fdisk:  seg-read: 00-000: o=00000000 s=2048
> fdisk:  seg-blank: 00-000: o=00000800 s=512
> fdisk:  seg-blank: 00-000: o=00000a00 s=512
>
> (snip)
>
> fdisk:  seg-blank: 00-003: o=0001fa00 s=512
> fdisk:  seg-blank: 00-003: o=0001fc00 s=512
> fdisk:  seg-blank: 00-003: o=0001fe00 s=512
> fdisk: queue-seg:00-003: p=252 a=0 u=0 b=0 f=no n=null
> rtems-rfs: format: /dev/fdda
> rtems-rfs: format: media size = 499712
> rtems-rfs: format: media blocks = 976
> rtems-rfs: format: media block size = 512
> rtems-rfs: format: size = 499712
> rtems-rfs: format: blocks = 976
> rtems-rfs: format: block size = 512
> rtems-rfs: format: bits per block = 4096
> rtems-rfs: format: inode size = 56
> rtems-rfs: format: inodes = 81 (1.0%)
> rtems-rfs: format: groups = 1
> rtems-rfs: format: group blocks = 4096
> rtems-rfs: format: group inodes = 81
> rtems-rfs: format: group   0: base = 1, size = 975,
> blocksfdisk:read-block:1
> fdisk:read-block: no segment mapping: 1
> , inodesfdisk:read-block:2
> fdisk:read-block: no segment mapping: 2
>
> fdisk:write-block:0
> fdisk: write:0=>00-000: queue check: ----
> fdisk: write:0=>00-000-000: write: p=252 a=0 u=0 b=0 n=null: f=fffe c=f0b7
> b=0
> fdisk:  seg-write: 00-000: o=00000800 s=512
> fdisk:write-block:00-000-000: write page failed: I/O error (5)
> fdisk: queue-seg:00-000: p=252 a=0 u=0 b=0 f=FAILED n=null
> fdisk:read-block:0
> fdisk: read:0=>00-000-000: p=252 a=0 u=0 b=0 n=null: f=fffe c=f0b7 b=0
> fdisk:  seg-read: 00-000: o=00000800 s=512
> fdisk:error:read-block: crc failure: 0: buffer:5bcd page:f0b7
> rtems-rfs: format: file system open failed: 5: I/O error
> rtems-rfs: format: writing root dir failed: 5: I/O error
> flash.c:137: flash_disk_format(): Failed to format flash file-system.
> Error: "I/O error"
> ____
>
> The "no segment mapping" bit seems to suggest I've stuffed up with the
> initialisation structures...? I *think* I'm defining 4 segments. Here're
> (hopefully!) the pertinent bits:
> ____
>
> #define CONFIGURE_APPLICATION_NEEDS_LIBBLOCK
>
> #define FLASH_DISK_DRIVER { \
>         .initialization_entry = rtems_fdisk_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 \
> }
>
> #define CONFIGURE_APPLICATION_EXTRA_DRIVERS FLASH_DISK_DRIVER
> #define CONFIGURE_FILESYSTEM_RFS
>
> #define CONFIGURE_INIT
> #include <rtems/confdefs.h>
>
>
> #include <rtems/flashdisk.h>
> #include <rtems/libio.h>
> #include <rtems/rtems-rfs.h>
> #include <rtems/rtems-rfs-format.h>
> #include <bsp/flashPgm.h>
> #include <libchip/am29lv160.h>
>
>
> uint32_t rtems_am29lv160_configuration_size = 1;
>
> const rtems_am29lv160_config rtems_am29lv160_configuration[] =
> {
>         {
>                 .bus_8bit = 0,
>                 //! \todo I believe this can change between MVME3100
> boards. Read the configuration out of the VPD EEPROM at run-time?
>                 .base     = (void *) 0xFC000000 // Obtained from MOTLoad,
> using the "flashShow" command
>         }
> };
>
> static const rtems_fdisk_segment_desc flash_disk_segment_desc =
> {
>         .count   = 4, // "Number of segments of this type in a row"
>         .segment = 0, // "The base segment number"
>         .offset  = 0, // "Address offset of base segment in device"
>         .size    = 128 * 1024 // "Size of [each of count] segment[s] in
> bytes" - hardware dependent?
> };
>
> static const rtems_fdisk_device_desc flash_disk_device =
> {
>         .segment_count = 1,
>         .segments      = &flash_disk_segment_desc,
>         .flash_ops     = &rtems_am29lv160_handlers
> };
>
> uint32_t rtems_flashdisk_configuration_size = 1;
>
> const rtems_flashdisk_config rtems_flashdisk_configuration[] =
> {
>         {
>                 .block_size         = 512,
>                 .device_count       = 1,
>                 .devices            = &flash_disk_device,
> //              .flags              = RTEMS_FDISK_CHECK_PAGES |
> RTEMS_FDISK_BLANK_CHECK_BEFORE_WRITE,
>                 .flags              = RTEMS_FDISK_CHECK_PAGES,
>                 .unavail_blocks     = 32, // Are we marking the first
> segment as unavailable so it can be used for compaction?
>                 .compact_segs       = 2,
>                 .avail_compact_segs = 1,
>                 .info_level         = 3
>         }
> };
>
>
> static int flash_disk_format(const char *device)
> {
>         rtems_rfs_format_config config;
>         int                     device_fd;
>
>
>         BSP_flashWriteEnable(0);
>
>
>         if ((device_fd = open(device, O_WRONLY, 0))
>         {
>                 rtems_error(0, "%s:%u: %s(): Failed to open flash device
> \"%s\". Error: \"%s\"", __FILE__, __LINE__, __func__, device,
> strerror(errno));
>
>                 return (-1);
>         }
>
>         if (ioctl(device_fd, RTEMS_FDISK_IOCTL_ERASE_DISK) == -1)
>         {
>                 rtems_error(0, "%s:%u: %s(): Failed to erase flash device
> \"%s\". Error: \"%s\"", __FILE__, __LINE__, __func__, device,
> strerror(errno));
>
>                 return (-1);
>         }
>
>
>         memset(&config, 0, sizeof (rtems_rfs_format_config));
>
>         config.verbose = true;
>
>         if (rtems_rfs_format(device, &config) != 0)
>         {
>                 BSP_flashWriteDisable(0);
>
>
>                 rtems_error(0, "%s:%u: %s(): Failed to format flash
> file-system. Error: \"%s\"", __FILE__, __LINE__, __func__, strerror(errno));
>
>                 return (-1);
>         }
>
>
>         BSP_flashWriteDisable(0);
>
>
>         return (0);
> }
> ____
>
> I've noticed that there's a
> c/src/lib/libbsp/powerpc/shared/flash/spansionFlash.c, but that looks
> like it's for flash programming? Perhaps this chip isn't supported for
> flashdisk usage?
> --
> Nick Withers
>
> Embedded Systems Programmer
> Room 2.26, Building 57
> Department of Nuclear Physics
> Research School of Physics and Engineering
> The Australian National University (CRICOS: 00120C)
>
> eMail: nick.withers at anu.edu.au
> Phone: +61 2 6125 2091
> Mobile: +61 414 397 446
>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>



-- 

regards
---
Matthew J Fletcher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20130812/ab2af27c/attachment-0001.html>


More information about the users mailing list