When trying to install Samba on my Hnet HW-C108 travel router with OpenWRT 19.07.2 I unexpectedly ran out of space. It seems to me the device does not contain as much flash memory as claimed. I'm trying to understand the way the memory is used.
The device page claims the router comes with 16MB of flash memory. This is what I find in the kernel log at boot time:
[ 0.611747] spi spi0.0: force spi mode3
[ 0.625219] m25p80 spi0.0: s25fl064k (8192 Kbytes)
[ 0.630159] 4 fixed-partitions partitions found on MTD device spi0.0
[ 0.636667] Creating 4 MTD partitions on "spi0.0":
[ 0.641583] 0x000000000000-0x000000030000 : "u-boot"
[ 0.647561] 0x000000030000-0x000000040000 : "u-boot-env"
[ 0.653878] 0x000000040000-0x000000050000 : "factory"
[ 0.659822] 0x000000050000-0x000001000000 : "firmware"
[ 0.665140] mtd: partition "firmware" extends beyond the end of device "spi0.0" -- size truncated to 0x7b0000
[ 0.678996] 2 uimage-fw partitions found on MTD device firmware
[ 0.685113] Creating 2 MTD partitions on "firmware":
[ 0.690190] 0x000000000000-0x00000017df95 : "kernel"
[ 0.696115] 0x00000017df95-0x0000007b0000 : "rootfs"
[ 0.702024] mtd: device 5 (rootfs) set to be root filesystem
[ 0.709353] 1 squashfs-split partitions found on MTD device rootfs
[ 0.715749] 0x0000003e3000-0x0000007b0000 : "rootfs_data"
The sizes derived from the address ranges match the sizes of the MTDblock devices, with the peculiarity that the "firmware" partition seems to be sized for a 16MB device, but gets truncated according to a total 8MB device (note the kernel message):
196608 mtdblock0 "u-boot"
65536 mtdblock1 "u-boot-env"
65536 mtdblock2 "factory"
8060928 mtdblock3 "firmware"
1564160 mtdblock4 |-> "kernel"
6496256 mtdblock5 |-> "rootfs"
3985408 mtdblock6 |->"rootfs_data"
The arrows denote a "comprises" relationship.
It seems there is only 4MB space rather than 12MB in the overlay filesystem ("rootfs_data"), which matches the output of df:
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 2560 2560 0 100% /rom
tmpfs 30012 924 29088 3% /tmp
/dev/mtdblock6 3892 1800 2092 46% /overlay
overlayfs:/overlay 3892 1800 2092 46% /
tmpfs 512 0 512 0% /dev
/dev/mmcblk0p1 62342144 60384 62281760 0% /storage
Is there a way I could have misinterpreted this? Should I correct the value on the device page?
The output of df shows I have plenty of space on my SD card. I'm thinking of utilising some of it to make room on the overlay filesystem. What's the smartest way of doing that? Right now it's an exfat filesystem. I have refrained from converting it to ext2/3/4, as the required kernel driver and required utilities are MASSIVE: together they get close to 1MB.
But there is only a single spi nor flash with 8mb detected.
I think there is a mistake in the wiki and in the initial device support commit message.
0x1000000 are also defined in the device tree if you sum up all partitions and this are exactly 8mb.
I beg to differ. In my world, 0x1000000 is 16MB.
The firmware partition size in the current (trunk/master) device tree is correct!
I think you have to open up your device and determine the real flash chip type.
Are you saying this may be a device tree bug, and if the device indeed has 16MB flash memory, fixing it would give me another 8MB?
Now that would be a reason to open it
PS.: In the meantime I checked the OpenWRT image that I flashed. It is indeed just 8MB in size.
No, the compatible "jedec,spi-nor" instructs the kernel to auto detect the spi nor flash according to the jedec standard.
As your flash chip is detected as "s25fl064k" instead of "en25q128" there are three reasons for your missing space.
- Your device has really this detected spi nor type
- The magic for your real flash chip does conflict with the one of "s25fl064k"
- The magic for "s25fl064k" are wrong
The image hasn´t to be the same size as the space on the flash chip!
I know. But it is one of many hints that the 16MB was some initial mistake that never got corrected. After all, 8MB is also more than the actual data inside.
This brings me to another question: The kernel provides device nodes to access the flash memory. There are (# for some decimal digits) /dev/mtd#, /dev/mtd#ro (both major number 90), and /dev/mtdblock# (major number 31), which for the same decimal digit (0 ... 6 in this device) refer to the same memory. The file 'device.txt' from the linux source describes very shortly the devices. The major number 90 ("Memory Technology Devices") is straightforward: mtd# is read/write, mtd#ro is read-only access. The description for major number 31 confuses me:
31 block ROM/flash memory card
0 = /dev/rom0 First ROM card (rw)
7 = /dev/rom7 Eighth ROM card (rw)
8 = /dev/rrom0 First ROM card (ro)
15 = /dev/rrom7 Eighth ROM card (ro)
16 = /dev/flash0 First flash memory card (rw)
23 = /dev/flash7 Eighth flash memory card (rw)
24 = /dev/rflash0 First flash memory card (ro)
31 = /dev/rflash7 Eighth flash memory card (ro)
The read-write (rw) devices support back-caching
written data in RAM, as well as writing to flash RAM
devices. The read-only devices (ro) support reading
Now, what is a ROM with read/write access?
I was looking for a tool that can backup the entire configuration, i.e. including software (installed packages). Basically what I want is a flash memory dump. Is there a special tool for backup/restore?
If not: Dumping via dd is easy, but the data may not be in a consistent state such that when restoring the router can boot again. For that I imagine I'd need to remount the overlay filesystem into ro mode. Is that sufficient for what I have in mind? Then, before restoring, I'd do the same (remount ro), then dd to the rw device, and reboot. Are there any obvious roadblocks to this approach?
Probably this is something for you:
LuCI does also allow you to download tbe mtd partition contents.
If im right under System -> Backup / Restore
From my point of view yes.
Thanks, looks like exactly what I was looking for. I will study it carefully.
Aha, in fact I had not noticed it before. However, it says:
NOTE: THIS FEATURE IS FOR PROFESSIONALS!
I take that to mean that there are caveats involved that the user needs to be aware of, and the user should know exactly what LuCI is doing there in the background. Do you know of any docs related to this? An immediate question is, whether I get a pure image, or one that is tagged with info which block is backed up? I can check the size of course. But there is no specific option to restore an image, but only the sysupgrade option. How do I make a backup image
sysupgrade-compatible (as the GUI calls it), such that sysupgrade knows which mtdblock to restore?
Maybe those questions are addressed in the document that you pointed me to. I will read that first.
So these backup scripts do not remount the overlay ro. Seems they rely on the fact that all normal system activity happens in RAM filesystems, and only the user would initiate write activities (via LuCI/uCI, or calling opkg). Still the filesystem is mounted rw, and most filesystems modify it anyway even if nothing writes to it, if for simply flagging it for non-proper unmounting after power failure.
Also the scripts assume nor flash. In an earlier message you called my device's flash nor-flash as well:
How can you be sure? Is that coded in the line
[ 0.625219] m25p80 spi0.0: s25fl064k (8192 Kbytes)