Flash disk RFS format errors, "no segment mapping"
Nick Withers
nick.withers at anu.edu.au
Tue Aug 20 04:03:03 UTC 2013
On Mon, 2013-08-12 at 18:37 +1000, Nick Withers wrote:
> Hullo all,
>
> I'm trying to get a flash disk (S29GLxxxN) going on ye olde MVME3100
> with RFS and'm having troubles...
FYI: I've reproduced what looks like exactly the same problem on 4.10.2
(and 4.11 Git master).
Does anyone know if some flashdisk parameters are hardware dependent
(e.g., block and/or sector size)?
Any suggestions appreciated :-)
> 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
More information about the users
mailing list