I see from openwrt wiki page that the deivce has 128MB and the space used for dual (primary and alternative kernel partition) is 80MB combined.
and is that page it says that "kernel" partition is 40MiB each, and then it shows a 6MiB actual kernel and 34MiB for the rootfs.
now my question is this:
my actual free space that I see with df as "/" is the rootfs ,right?
I use images built from imagebuilder from release version.
my sysupgrade image is usually 17MiB and factory.img is 22 MiB.
so now that I see 12384 1K-blocks for overlayfs:/overlay and /dev/ubi0_1 (which are the same?) that means that my kernel plus squashfs rootfs(readonly) are occupying the rest of 40MiB?
Often, on NAND-based devices, the combined ROM and overlay are on one UBI container. The ROM is squashfs riding on top of a ubiblock (emulation) device, often as ubi0_0, and the overlay is a native UBI volume, often as ubi0_1.
Given that illustration above, you have 34 MB for the total of the compressed ROM and the overlay.
ubinfo -a
will let you see how that is split up, for the firmware you flashed.
can you explain from this my device?
so the Size: 280 LEBs (35553280 bytes, 33.9 MiB) is the mt5 or mt7 ,right?
or are ubi1 and ubi0 are inside each other?
I think ubi1 is the alternative partition? or not?
because in picture it shows ubi for mt5 and the size is 34MiB
but none the (Total amount of logical eraseblocks) are 34MiB
one is 35.8 MiB and one is 32.9 MiB
Try the preformatted-text button </> Markdown uses the # character to define header levels
A UBI container can hold several volumes.
ubi0 is the container that is associated with mtd5 (or mtd7, if running off the "alternate" firmware)
ubi0_0 is a volume that then gets wrapped with a ubiblock device, that lets the r/o, squashfs ROM think it's running off a "normal" block device. Since NAND usually has bad blocks (typically 20/1024 reserved on the SPI NAND I've been working with, ~1%), the UBI layer handles the remapping required.
ubi0_1 is a UBI file system that is used for the overlay (r/w)
ubi1 is another container, probably backed by mtd8
ubi1_0 looks to be the single sysfs partition. I don't recall just what was in it for the EA8300 I work with, but it might contain device-specific information, such as MAC addresses. It might also just be a "scratch" partition used by the OEM firmware.
It's not at all straightforward to "swallow" that "extra" 38 MB into the two firmware partitions. Moving the kernel would require changes to the kernel, U-Boot environment, and some "fancy dancing" in getting it to work. "Return to OEM" would then likely require serial access to U-Boot.
I am still a bit confused but let me ask something simple and if you know the answer ,write in reply.
when I boot in on partition then this command and the other commands on running kernel have no access to the alternative partition? except mtd commnads ( I dont know what they are) for upgrading?
so this way you can be sure that ubi1 is NOT the alternative one and is the mtd8 one?
because the
I think you misunderstood me.
I dont want to use the "Free space of other mtd units.
I am asking about the simple partition that I am using.
is it 40MiB for the current running OS and another 40MiB for the alternative one and after booting to one then there is 40MiB that get divided between the readonly kernel data (applications) and r/w data which I can write too, correct?
so when I install the sysugrade (or factory.img) that is about 17MiB then it installs in in the 40MiB space so I what I get with df is the remainder?
You have already used 6.7 MB of the 13.1 MB of your overlay, and have 5.7 MB free space on the device
The "missing" 34 MB - 14 MB - 13 MB = 7 MB is probably due to the overhead of UBI itself, the file system directories and the like, as well as reservations for bad-black reallocation.
Edit
Logical eraseblock size: 126976 bytes, 124.0 KiB
Total amount of logical eraseblocks: 272 (34537472 bytes, 32.9 MiB)
Amount of available logical eraseblocks: 0 (0 bytes)
Maximum count of volumes 128
Count of bad physical eraseblocks: 0
Count of reserved physical eraseblocks: 20
20 * 124 KB ~ 2.4 MB for about 30.5 MB remaining
Volume ID: 0 (on ubi0)
Type: dynamic
Alignment: 1
Size: 115 LEBs (14602240 bytes, 13.9 MiB)
State: OK
Name: rootfs
Character device major/minor: 250:1
-----------------------------------
Volume ID: 1 (on ubi0)
Type: dynamic
Alignment: 1
Size: 133 LEBs (16887808 bytes, 16.1 MiB)
State: OK
Name: rootfs_data
Character device major/minor: 250:2
"The "missing" 34 MB - 14 MB - 13 MB = 7 MB is probably due to the overhead of UBI itself, the file system directories and the like, as well as reservations for bad-black reallocation."
what is this ?
wasted space?
I think a 7MiB cant ne overhead anymore.
No, you need a bad-block reservation when working with NAND.
File systems also have all the directory information, as well as redundancy associated with the data storage. A 1 GB disk can never store 1 GB of files.
I understand that.
but even on my linux ext4 I still dont have 7over40 ratio for "stuff".
but I will take your word for it.
so I have about 14MiB in ROM format (readonly) then how is it that my sys-upgrade image that I build is 16MiB?
can you in one simple answer give me a overall available space that includes the image I install?
I want to know how my space I can get with changing my image and also how high I can go?
right now it is 27MiB? (13+14) from initial 40MiB?
also the 14 is near that 13.9M rootfs so the rootfs is the kernel plus apps part?
then shouldn't 16M of rootfs_data be available and not 13M.
sorry if I come across as dumb, it is because I am not a computer expert.
No problem! The only reason I know about how this all works is from porting devices.
For most NAND-based devices, an OpenWrt image is a tar file that contains both the kernel (up to 6 MB for your device) and the UBI image for the file systems.
In the case you describe, you've got a 16 MB upgrade image with a 14 MB ROM, so the kernel is probably about 2 MB.
When the sysupgrade image is written, it writes a combined UBI image including the ROM and the header for another empty, auto-resizing UBI FS for the overlay. The "split" between the two is something of an illusion as what is written are the bits that describe both, all in one shot. If you are preserving settings, it also writes the tar file containing the settings to the soon-to-be overlay file system.
Logical eraseblock size: 126976 bytes, 124.0 KiB
Total amount of logical eraseblocks: 272 (34537472 bytes, 32.9 MiB)
Amount of available logical eraseblocks: 0 (0 bytes)
Maximum count of volumes 128
Count of bad physical eraseblocks: 0
Count of reserved physical eraseblocks: 20
says that you've got 252 logical erase blocks available for ROM and overlay. At 124 kB per block, that's about 30.5 MB total. 13.9 + 16.1 MB = 30 MB, which seems to be what you've got available for the combination of your ROM and your overlay file system.
a very good answer.
but at the end you still did this: 13.9 + 16.1 MB = 30 MB
did you say that my 16MB image (that you described as kernel plus ROM ,so ROM doesnt have the kernel ) put the a 14MB ROM and a 2MB kernel in two different places?
as in, a 2MB kernel in the 6MB reserved for kernel?
then why at the end you still used the 16MB instead of 14?
I am talking about the last part of you answer which is about the ubi.
that ubi doesnt include kernel right?
so my upgrade image that you say is the 14M-ROM plus 2M-kernel writes only the ROM part to this ubi which is 14M.
btw why you seperate ROM and kernel in you description (I dont mean the actual procedure of install).
because whenever I heard ROM in openwrt resources it meant all the image
