MTD Erase Block Size of zero for SRAM

Question

Refined Question

How do read and write text information from a MTD SRAM device with erase block size zero?

Notes:

I am using the 23K256 Driver
Attempts to use MTD-Util tools have failed because libmtd cannot handle a erase block size of zero
Attempts to artificially add an erase block size has also failed (see below)
Attempts to use echo > and cat to the mtdblock have only produced garbage

Original I am attempting to read and write to a SRAM chip connected to a ARM processor running Linux. I do not care if i interface with the SRAM like a file, serial device or memory partition. The existing device driver for the SRAM chip registers the device as a MTD. I verified this by checking /proc/mtd:

~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00000000 "spi1.0"

I found a tutorial to format the MTD using MTD utils. The problem I am experiencing is that I cannot interface with the SRAM/MTD device because all the user-space MTD/UBI/JFF2 tools crash when looking at this device, IE:

~# mtdinfo
Count of MTD devices:           1
Floating point exception (core dumped)

This exception appears to be occurring because all the MTD utilities use libmtd. The mtd_get_dev_info1 function in libmtd divides by the erase block size and in my case the erase block size is zero.

mtd->eb_cnt = mtd->size / mtd->eb_size;

Even though this chip has a MTD driver, i do not think write cycles are a concern and that is why the erase block is zero. so my questions are the following:

Should i modify the driver to give the chip an erase block size so the utilities work correctly? If so what size?
Should i modify libmtd to ignore the zero erase block size? If so what should i set the eb_cnt to?
Is there a better way to read and write data to the MTD device?

Additional Notes:

Stability is more important than optimal performance in my situation
I tried to do an echo test > /dev/mtdblock0 and cat /dev/mtdblock0 and got nothing but garbage

Update 10/20 Changed the erase block size to 1 in the driver (I desired to change it to 4000, but i was unsure about units). MTD Utils no longer throws the exception given before.

~# mtdinfo
Count of MTD devices:           1
Present MTD devices:            mtd0
Sysfs interface supported:      yes

However ubiformat does fail:

~# ubiformat /dev/mtd0
ubiformat: mtd0 (ram), size 131072 bytes (128.0 KiB), 131072 eraseblocks of 
1 bytes, min. I/O size 1 bytes
libscan: scanning eraseblock 0 --  0 % complete  libmtd: error!: bad offset 
0 or length 64, mtd0 eraseblock size is 1
ubiformat: error!: failed to scan mtd0 (/dev/mtd0)

Update #2 10/20 Unfortunately setting the erase block size to 4000 (actually 0x4000) cause the kernel to crash after running ubiformat

~# ubiformat /dev/mtd0
ubiformat: mtd0 (ram), size 131072 bytes (128.0 KiB), 8 eraseblocks of 16384 
bytes (16.0 KiB), min. I/O size 1 bytes
libscan: scanning erasebUnable to handle kernel NULL pointer dereference at 
virtual address 00000000
libscanpgd = 8cc6c000te
libscan: scanning eras[00000000] *pgd=8cbbb835, *pte=00000000, *ppte=00000000
libscan: scanning eInternal error: Oops: 80000007 [#1] PREEMPT SMP ARM

Update 10/23 I tried to format the drive normally with fdisk, but seem to be getting errors regarding the lack of cylinders:

:~# fdisk  /dev/mtdblock0
...
Command (m for help): p
Disk /dev/mtdblock0: 0 MB, 131072 bytes
255 heads, 63 sectors/track, 0 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
      Device Boot      Start         End      Blocks  Id System
Command (m for help): n
Unknown value(s) for: cylinders (settable in the extra functions menu)

Unless you're hoping for a special recognition of 0 as "does not apply" logically the actual erase size would be the memory's addressable width - on most architectures 1 byte. However, the SLRAM driver seems to use its block size which is 4k, probably following from an a MMU pagesize. — Chris Stratton
I'll modify the driver to set the erase block size to 4K and report back what happens. — Liam Kelly
+1 to @ChrisStratton idea, was about to write that 4K sounds plausible, though I’m not sure why it uses that kind of interface in the first place. — 0andriy
"The existing device driver for the SRAM chip registers the device as a MTD." -- That sounds misguided, i.e. the wrong approach. The last time I did a driver for (battery-backed) SRAM, I just wrote a simple ram-disk driver. — sawdust
@0andriy yeah it seems odd. The driver is in the Linux mainline (23K256) and the commit messages acknowledge that it should have an erase block size of zero. — Liam Kelly

Liam Kelly Liam Kelly · Accepted Answer · 2017-10-26T19:17:22

There was an underlying hardware problem that once fixed allowed for data to be written and read from the /dev/mtdblock0 device. This was verified by using echo TEST > /dev/mtdblock0 to write and cat /dev/mtdblock to read.

Here is a summary of the other bugs found while researching this problem

If the chip is malfunctioning the 23K256 driver will still produce the correct amount of output from a cat /dev/mtdblock0 call. The output will be all the same, while the actual uninitialized chip output will be random.
All applications using libmtd, including all of the mtd-utils, will error when dealing with a MTD devices with erase block size of zero.
Artificially setting the SRAM erase block size to 0x4000 in the driver may fix this problem. Erase size of 1 was unacceptable.
fdisk will error due to cylinder size being 0 (may be possible to get around using expert mode)

MTD Erase Block Size of zero for SRAM

1 Answers