rootfs.jffs2 files system won't fit in mtd3

Question

I have a files system that I am trying to put in flash memory mtd3 partition. I first boot using uboot and then do run sdboot to boot using SD card as shown below:

U-Boot-PetaLinux>
U-Boot-PetaLinux> printenv mtdparts
mtdparts=mtdparts=0:5M(boot),128K(bootenv),10752K(image),4M(spare)
U-Boot-PetaLinux>run sdboot

Now I have a running linux system.

.
.
.
.
root@Xilinx-ZC702-14_7:/mnt/flashboot# nandwrite -p /dev/mtd3 rootfs.jffs2
Image 3513340 bytes, NAND page 1 bytes, OOB area 0 bytes, device size 393216 bytes
nandwrite: error!: Input file does not fit into device
           error 0 (Success)
nandwrite: error!: Data was only partially written due to error
           error 0 (Success)

So why it shows:

nandwrite: error!: Input file does not fit into device

You can see my environmental variables in first line, I have given sufficient space of 4MB, so why an image of size 3513340 bytes (3.35 MB) won't fit in a device ? And from where this

device size 393216 bytes coming?

Additional info

#cat /proc/cmdline
console=ttyPS0,115200

mtdinfo:

Count of MTD devices:           4
Present MTD devices:            mtd0, mtd1, mtd2, mtd3
Sysfs interface supported:      yes

partitions

root@Xilinx-ZC702-14_7:/# cat /proc/mtd
dev: size erasesize name
mtd0: 00500000 00010000 "boot"
mtd1: 00020000 00010000 "bootenv"
mtd2: 00a80000 00010000 "image"
mtd3: 00060000 00010000 "spare"

also it can be seen that:

root@Xilinx-ZC702-14_7:/mnt/flash# mtdinfo /dev/mtd0
mtd0
Name:                           boot
Type:                           nor
Eraseblock size:                65536 bytes, 64.0 KiB
Amount of eraseblocks:          80 (5242880 bytes, 5.0 MiB)
Minimum input/output unit size: 1 byte
Sub-page size:                  1 byte
Character device major/minor:   90:0
Bad blocks are allowed:         false
Device is writable:             true

root@Xilinx-ZC702-14_7:/mnt/flash# mtdinfo /dev/mtd1
mtd1
Name:                           bootenv
Type:                           nor
Eraseblock size:                65536 bytes, 64.0 KiB
Amount of eraseblocks:          2 (131072 bytes, 128.0 KiB)
Minimum input/output unit size: 1 byte
Sub-page size:                  1 byte
Character device major/minor:   90:2
Bad blocks are allowed:         false
Device is writable:             true

root@Xilinx-ZC702-14_7:/mnt/flash# mtdinfo /dev/mtd2
mtd2
Name:                           image
Type:                           nor
Eraseblock size:                65536 bytes, 64.0 KiB
Amount of eraseblocks:          168 (11010048 bytes, 10.5 MiB)
Minimum input/output unit size: 1 byte
Sub-page size:                  1 byte
Character device major/minor:   90:4
Bad blocks are allowed:         false
Device is writable:             true

root@Xilinx-ZC702-14_7:/mnt/flash# mtdinfo /dev/mtd3
mtd3
Name:                           spare
Type:                           nor
Eraseblock size:                65536 bytes, 64.0 KiB
Amount of eraseblocks:          6 (393216 bytes, 384.0 KiB)
Minimum input/output unit size: 1 byte
Sub-page size:                  1 byte
Character device major/minor:   90:6
Bad blocks are allowed:         false
Device is writable:             true

System

petalinux running on ARM cortex A9

http://www.wiki.xilinx.com/Linux

https://github.com/Xilinx

Device Tree http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/plain/conf/machine/boards/zedboard/zedboard-zynq7-board.dtsi

Partition in Configuration Tool This is the tool for configuration I use prior to building image.ub. See the size of jffs2 which is greater than the actual size of rootfs.jffs2 file.

/sys/class/mtd

root@Xilinx-ZC702-14_7:/sys/class/mtd# ls -ld *
lrwxrwxrwx    1 root     root             0 Jan  1 00:00 mtd0 -> ../../devices/amba.0/e000d000.ps7-qspi/spi_master/spi32766/spi32766.0/mtd/mtd0
lrwxrwxrwx    1 root     root             0 Jan  1 00:00 mtd0ro -> ../../devices/amba.0/e000d000.ps7-qspi/spi_master/spi32766/spi32766.0/mtd/mtd0ro
lrwxrwxrwx    1 root     root             0 Jan  1 00:00 mtd1 -> ../../devices/amba.0/e000d000.ps7-qspi/spi_master/spi32766/spi32766.0/mtd/mtd1
lrwxrwxrwx    1 root     root             0 Jan  1 00:00 mtd1ro -> ../../devices/amba.0/e000d000.ps7-qspi/spi_master/spi32766/spi32766.0/mtd/mtd1ro
lrwxrwxrwx    1 root     root             0 Jan  1 00:00 mtd2 -> ../../devices/amba.0/e000d000.ps7-qspi/spi_master/spi32766/spi32766.0/mtd/mtd2
lrwxrwxrwx    1 root     root             0 Jan  1 00:00 mtd2ro -> ../../devices/amba.0/e000d000.ps7-qspi/spi_master/spi32766/spi32766.0/mtd/mtd2ro
lrwxrwxrwx    1 root     root             0 Jan  1 00:00 mtd3 -> ../../devices/amba.0/e000d000.ps7-qspi/spi_master/spi32766/spi32766.0/mtd/mtd3
lrwxrwxrwx    1 root     root             0 Jan  1 00:00 mtd3ro -> ../../devices/amba.0/e000d000.ps7-qspi/spi_master/spi32766/spi32766.0/mtd/mtd3ro
root@Xilinx-ZC702-14_7:/sys/class/mtd#

Drivers

root@Xilinx-ZC702-14_7:~# ls /sys/bus/*/drivers

/sys/bus/amba/drivers:

/sys/bus/clocksource/drivers:

/sys/bus/cpu/drivers:

/sys/bus/hid/drivers:
hid-generic

/sys/bus/i2c/drivers:
at24     dummy    pca954x

/sys/bus/mdio_bus/drivers:
Generic PHY

/sys/bus/mmc/drivers:
mmcblk

/sys/bus/platform/drivers:
alarmtimer       vexpress-sysreg  xilinx-gpio      xusbps-dr
of-flash         xadcps           xilinx_emaclite  xusbps-ehci
physmap-flash    xdevcfg          xqspips          xusbps-otg
sdhci-zynq       xemacps          xslcr            xusbps-udc
uio_pdrv_genirq  xgpiops          xsmcps           xwdtps
vexpress-reset   xi2cps           xuartps          zynq_remoteproc

/sys/bus/rpmsg/drivers:
rpmsg_proto          rpmsg_server_sample

/sys/bus/scsi/drivers:
ch    osst  sd    sr    st

/sys/bus/sdio/drivers:

/sys/bus/serio/drivers:

/sys/bus/spi/drivers:
m25p80

/sys/bus/usb/drivers:
hub          usb          usb-storage  usbfs        usbhid

/sys/bus/virtio/drivers:
virtio_rpmsg_bus
root@Xilinx-ZC702-14_7:~#

mmc drivers

root@Xilinx-ZC702-14_7:/# cd /sys/bus/mmc/drivers/mmcblk/
root@Xilinx-ZC702-14_7:/sys/bus/mmc/drivers/mmcblk# ls
bind       mmc0:1234  uevent     unbind
root@Xilinx-ZC702-14_7:/sys/bus/mmc/drivers/mmcblk# cd mmc0\:1234/
root@Xilinx-ZC702-14_7:/sys/devices/amba.0/e0100000.ps7-sdio/mmc_host/mmc0/mmc0:1234# ls
cid                   hwrev                 scr
csd                   manfid                serial
date                  name                  subsystem
driver                oemid                 type
erase_size            power                 uevent
fwr

Solution

I solved it by using configuration tool , and by making the following selections which were unslected earlier.

File systems  ---> 
-*- Native language support  --->
    <*>   Codepage 437 (United States, Canada)
    ...
    <*>   NLS ISO 8859-1  (Latin 1; Western European Languages)
    ... 

Answer 1

First off, I don't think the mtdparts environmental variable conveys any meaningful information as to what the actual partition sizes are. mtdparts is supposed to be a kernel boot parameter, rather than an environmental variable. It may be that PetaLinux is putting these values in the environment during boot. However, even then it appears to be in the wrong format. To see the kernel boot parameters you can do cat /proc/cmdline.

To find out the partition sizes the kernel attempts to create, you can look under /proc/mtd as per your other question. To find out the size of the actual block device created (in bytes), you can do blockdev --getsize64 /dev/mtd3 (needs root privileges). All going well the two should match!

Now, assuming that the partition size is too small, you will want to increase the size of the partition (this is what the other question asks!). Specifying the mtdparts parameter at boot time is the correct way to do this. From drivers/mtd/cmdlinepart.c in the kernel source code (note this offers slightly more information than the almost identical snippet from drivers/mtd/Kconfig that was used previously), this is the correct format specification:

 * The format for the command line is as follows:
 *
 * mtdparts=<mtddef>[;<mtddef]
 * <mtddef>  := <mtd-id>:<partdef>[,<partdef>]
 * <partdef> := <size>[@<offset>][<name>][ro][lk]
 * <mtd-id>  := unique name used in mapping driver/device (mtd->name)
 * <size>    := standard linux memsize OR "-" to denote all remaining space
 *              size is automatically truncated at end of device
 *              if specified or trucated size is 0 the part is skipped
 * <offset>  := standard linux memsize
 *              if omitted the part will immediately follow the previous part
 *              or 0 if the first part
 * <name>    := '(' NAME ')'
 *              NAME will appear in /proc/mtd
 *
 * <size> and <offset> can be specified such that the parts are out of order
 * in physical memory and may even overlap.
 *
 * The parts are assigned MTD numbers in the order they are specified in the
 * command line regardless of their order in physical memory.
 *
 * Examples:
 *
 * 1 NOR Flash, with 1 single writable partition:
 * edb7312-nor:-
 *
 * 1 NOR Flash with 2 partitions, 1 NAND with one
 * edb7312-nor:256k(ARMboot)ro,-(root);edb7312-nand:-(home)

What exactly is meant by standard linux memsize isn't clear. Documentation/kernel-parameters.txt give the following paragraph:

Finally, the [KMG] suffix is commonly described after a number of kernel
parameter values. These 'K', 'M', and 'G' letters represent the _binary_
multipliers 'Kilo', 'Mega', and 'Giga', equalling 2^10, 2^20, and 2^30
bytes respectively. Such letter suffixes can also be entirely omitted.

This the the expected use uppercase letters, but whether the lowercase k used in the example specifies the same or different power as K is not mentioned (best to ignore this and use uppercase by the looks of things).

From you question the mtdparts=mtdparts= part seems to be wrong. Normally for an environmental variable the name of the variable isn't part of the value of the variable at all. Also 0 doesn't seem like a valid mtd-id.

Everything else for your given mtdparts seems fine. The size of partition should be carefully chosen to be the same size as erase blocks, but this seems to be the case given the erase block size of 64KiB in /proc/mtd for your other question.

Finding the correct mtd-id

There appears to be no method of determining this on a running system. Atlhough various information about mtd devices can be found under /sys/class/mtd, this information is currently unavailable. The mtdinfo command doesn't seem to do anything other than read and format this information, so that isn't much use either

However, given the driver being used, it should be possible to find this out by looking at the kernel source code. To get this, you can checkout the latest stable source tree with:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

Or you may prefer to use the code from your distro for the kernel version used. Note that there likely won't be enough room on the device itself for the ~1.4 GB download. From within the root of the source tree, the following command reveals a good chunk of the places where an mtd->name value is set (note that the code doesn't have to use the name mtd for the structure, but usually will):

grep -rE 'mtd(\.|->|-)name[[:space:]]*='

In most cases it is either hard coded in the driver or the information is in a .dts file. It also shows that the driver we are looking for is likely to be under drivers/mtd. Digging around further, using commands like this:

for drv in a bunch of drivers; do
  find . -iname "*$drv*"
done | grep mtd

shows that the mtd driver is m25p80. This is for various flash devices that communicate via SPI (this explains why looking for PCI related stuff wasn't helpful). Looking at the source file drivers/mtd/devices/m25p80.c, we see mtd->name is set in the following snippet:

  if (data && data->name)
    flash->mtd.name = data->name;
  else
    flash->mtd.name = dev_name(&spi->dev);

Unfortunately there is not a single specific name used by this driver, rather the names are defined elsewhere and depend on the hardware used. Digging further, we see that data is a flash_platform_data structure. Looking for its definition, we get this comment in include/linux/spi/flash.h:

 * struct flash_platform_data: board-specific flash data
 * @name: optional flash device name (eg, as used with mtdparts=)
 * @parts: optional array of mtd_partitions for static partitioning
 * @nr_parts: number of mtd_partitions for static partitoning
 * @type: optional flash device type (e.g. m25p80 vs m25p64), for use
 *  with chips that can't be queried for JEDEC or other IDs
 *
 * Board init code (in arch/.../mach-xxx/board-yyy.c files) can
 * provide information about SPI flash parts (such as DataFlash) to
 * help set up the device and its appropriate default partitioning.
 *
 * Note that for DataFlash, sizes for pages, blocks, and sectors are
 * rarely powers of two; and partitions should be sector-aligned.

It seems that the mtd-id is specific to the board rather than the flash memory itself. The gives usages of this structure, the -A 2 prints 2 lines after the match and shows most of the names used:

grep -rA 2 '[[:space:]]flash_platform_data'

The filenames also reflect the names of the boards, so hopefully yours is there. Quite a lot just use m25p80 as the mtd-id, so this is probably it.

Failing this the other branch of the code snippet traces back to the init_name of the device, although I don't know how to find this (dmesg?).

Assuming m25p80 is the mtd-id, the kernel parameter should be:

mtdparts=m25p80:5M(boot),128K(bootenv),10752K(image),4M(spare)

All that should remain is to reconfigure U Boot with this added to the bootargs parameter. Reboot and hopefully you should have the partition sizes you need.