jffs2: Too few erase blocks (1)

Started by brmlst, June 14, 2015, 02:44:53 AM

Previous topic - Next topic

brmlst

Hello,
system boots only in overlayfs:/tmp/root mode, after reboot all configurations I did are lost.

What am I missing?

Thanks



Daniel

The same happens with my new RT5350F-OLinuXino-EVB. "jffs2: Too few erase blocks (1)" and after rebooting all the configuration is lost.

brmlst

Indeed the preloaded image is too large, it leaves no space enough for the jffs2 FS.

Building a new Image I had the overlay root mounted as expected, but the flash is really tiny for the current version of openwrt, and choosing which component could be removed without impairing the system effectiveness is not an easy task, still I'm testing different configurations in order to find a satisfactory one.

Sure a bigger flash would be really useful...

Daniel

Did you build the new firmware image without removing anything? I'm building a new image without any USB support. I hope it will be small enough to solve this problem.

brmlst

I kept the usb support (may be useful to move/expand root) but I removed the IPV6 stuff.

samuele

Hi,
I've also noticed this problem on the new RT5350F-OLinuXino-EVB board, but I'm really astonished that Olimex sells these boards that by default are unconfigurable/unusable because any configuration is lost at the next reboot...
Be forced to remove features of the system to be able to use the board is not a very graceful solution and limits the system capabilities.

samuele

Looking at the OLINUXINO-RT5350F.dts (located at openwrt/target/linux/ramips/dts/), why the "firmware" partition is defined of size 0x3b0000? Shouldn't it be 0x7b0000? The flash size of the OLINUXINO-RT5350F is 8MB...

JohnS

Quote from: samuele on June 30, 2015, 01:01:59 PM
Hi,
I've also noticed this problem on the new RT5350F-OLinuXino-EVB board, but I'm really astonished that Olimex sells these boards that by default are unconfigurable/unusable because any configuration is lost at the next reboot...
Be forced to remove features of the system to be able to use the board is not a very graceful solution and limits the system capabilities.
Are you not running a version of Linux?  If yes, it's up to you to change Linux things, isn't it?

John

Daniel

#8
Quote from: samuele on June 30, 2015, 05:37:12 PM
Looking at the OLINUXINO-RT5350F.dts (located at openwrt/target/linux/ramips/dts/), why the "firmware" partition is defined of size 0x3b0000? Shouldn't it be 0x7b0000? The flash size of the OLINUXINO-RT5350F is 8MB...

Samuele, you are right. The firmware partition should be 0x7b0000 and not 0x3b0000. That's the reason why there is not enough space left. I will try to change that.

brmlst

Quote from: Daniel on July 01, 2015, 07:52:44 PM
Quote from: samuele on June 30, 2015, 05:37:12 PM
Looking at the OLINUXINO-RT5350F.dts (located at openwrt/target/linux/ramips/dts/), why the "firmware" partition is defined of size 0x3b0000? Shouldn't it be 0x7b0000? The flash size of the OLINUXINO-RT5350F is 8MB...

Samuele, you are right. The firmware partition should be 0x7b0000 and not 0x3b0000. That's the reason why there is not enough space left. I will try to change that.

If you take a look at /proc/mtd you can see the size of the flash partitions, on my system the sum is approximately 8MB, so I don't expect there is a margin for more space.
Anyway if somebody is available to make a test compilation with firmware partition a 0x7b0000 I would like to know the result....

Daniel

#10
Compiled with the changed value from 0x3b0000 to 0x7b0000:

cat /proc/mtd

mtd0: 00030000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00010000 00010000 "factory"
mtd3: 007b0000 00010000 "firmware"
mtd4: 0010986c 00010000 "kernel"
mtd5: 006a6794 00010000 "rootfs"
mtd6: 003a0000 00010000 "rootfs_data"

df

Filesystem           1K-blocks      Used Available Use% Mounted on
rootfs                    3712       308      3404   8% /
/dev/root                 3072      3072         0 100% /rom
tmpfs                    14596      1108     13488   8% /tmp
/dev/mtdblock6            3712       308      3404   8% /overlay
overlayfs:/overlay        3712       308      3404   8% /
tmpfs                      512         0       512   0% /dev



samuele

Compiled changing from 0x3b0000 to 0x7b0000.

Looking at the kernel messages during boot, the flash size changed:


[BEFORE]
[    0.520000] Creating 4 MTD partitions on "spi32766.0":
[    0.520000] 0x000000000000-0x000000030000 : "u-boot"
[    0.540000] 0x000000030000-0x000000040000 : "u-boot-env"
[    0.540000] 0x000000040000-0x000000050000 : "factory"
[    0.560000] 0x000000050000-0x000000400000 : "firmware"

[AFTER]
[    0.700000] Creating 4 MTD partitions on "spi32766.0":
[    0.700000] 0x000000000000-0x000000030000 : "u-boot"
[    0.720000] 0x000000030000-0x000000040000 : "u-boot-env"
[    0.730000] 0x000000040000-0x000000050000 : "factory"
[    0.740000] 0x000000050000-0x000000800000 : "firmware"


root@RT5350F-OLinuXino:/# df -h
Filesystem                Size      Used Available Use% Mounted on
rootfs                    4.2M    276.0K      3.9M   6% /
/dev/root                 2.5M      2.5M         0 100% /rom
tmpfs                    14.3M     56.0K     14.2M   0% /tmp
/dev/mtdblock6            4.2M    276.0K      3.9M   6% /overlay
overlayfs:/overlay        4.2M    276.0K      3.9M   6% /
tmpfs                   512.0K         0    512.0K   0% /dev


root@RT5350F-OLinuXino:/# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00030000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00010000 00010000 "factory"
mtd3: 007b0000 00010000 "firmware"
mtd4: 00108891 00010000 "kernel"
mtd5: 006a776f 00010000 "rootfs"
mtd6: 00430000 00010000 "rootfs_data"


With the new image flashed on the board, I've tried to change some settings (like IP address, etc.) and now when rebooting the board the settings are not lost.

brmlst

I also successfully rebuilt my images; it works.

Looking at the OpenWrt documentation the firmware partition is the container of the data and kernel, and 0x7b0000 (or 0x3b0000) is not the partition address but the partition size, and this makes all clear...