Different space consumed in /overlay?

Hi there,
I have a router with tiny 8MB ROM and managed to compiled and installed openwrt on it.

Current space on /overlay is:

df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 4.5M      4.5M         0 100% /rom
tmpfs                    58.9M    412.0K     58.5M   1% /tmp
/dev/mtdblock6          768.0K    352.0K    416.0K  46% /overlay
overlayfs:/overlay      768.0K    352.0K    416.0K  46% /
tmpfs                   512.0K         0    512.0K   0% /dev

overlayfs:/overlay 768.0K 352.0K 416.0K 46% /

I understand this means I used 352K on overlay. But

 du -sh /overlay
46.0K   /overlay

So my overlay only has a size of 46K for config files, where did (352-46)=306K go??? I manually copied all contents of /overlay to my PC and the result is the same, it only occupies 46K of space.

Anyone here for helping a confused soul? :thinking:

Pure guess, but overlay needs some 4 erase blocks as working space, initial directory structure etc.. That would be 256 k (with 64 kB blocks). Not sure if that is reported as used space, but might be an explanation.

Other similar thing might be erase marks for files "deleted" from rom. As rom is not changed, those files have erase marks in /overlay, but they are not real files accounted by du.

1 Like

Thanks for the info, but in my build .config the default setting is:

CONFIG_TARGET_SQUASHFS_BLOCK_SIZE=128

If op reserves 3 blocks then it should be 128*3=384kb no?
If I adjust block size to 64kb, will it free some extra space consumed in this scenario?
As this is a pretty restict setup, I did not install or remove any packages after first boot.

The block size is about physical flash writing logic. Flash is always written in whole blocks, typically 64 or 128 kB, depending on the chip.
You can't just change it.

OK, my spi nor flash spec is Winbond 25Q64JVS10 (confirmed by tearing down the router)
But in syslog it is recognized as

 spi-nor spi0.0: s25fl064k (8192 Kbytes)

A Spansion conterpart. In spansion.c and winbond.c I found they have the same spec:

	{ "s25fl064k",  INFO(0xef4017,      0,  64 * 1024, 128,
			     SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
	{ "w25q64", INFO(0xef4017, 0, 64 * 1024, 128,
			 SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },

So does this mean the block size should be 64k instead of 128k when compiling? But I indeed used the default 128k block sized to compile the firmware and it is running normally. Sorry I'm very new to this. Any side effects?

The DTS file is generated using similar spec from other models:

#include "mt7621.dtsi"

#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>

/ {
     compatible = "mercury,d21g", "mediatek,mt7621-soc";
     model = "Mercury D21G";

     aliases {
         led-boot = &led_status;
         led-failsafe = &led_status;
         led-running = &led_status;
         led-upgrade = &led_status;
		 label-mac-device = &gmac0;
     };

     chosen {
         bootargs = "console=ttyS0,57600";
     };

     leds {
         compatible = "gpio-leds";

         led_status: status {
             label = "d21g:white:status";
             gpios = <&gpio 3 GPIO_ACTIVE_LOW>;
         };

     };

     keys {
         compatible = "gpio-keys";

         reset {
             label = "reset";
             gpios = <&gpio 8 GPIO_ACTIVE_LOW>;
             linux,code = <KEY_RESTART>;
         };
     };

};


&spi0 {
        status = "okay";

        flash@0 {
                compatible = "jedec,spi-nor";
                reg = <0>;
                spi-max-frequency = <10000000>;

                partitions {
                        compatible = "fixed-partitions";
                        #address-cells = <1>;
                        #size-cells = <1>;

                        partition@0 {
                                label = "u-boot";
                                reg = <0x0 0x20000>;
                                read-only;
                        };

                        partition@20000 {
                                label = "u-boot-env";
                                reg = <0x20000 0x10000>;
                                read-only;
                        };

                        factory: partition@30000 {
                                label = "factory";
                                reg = <0x30000 0x10000>;
								read-only;
                        };

                        partition@40000 {
                                compatible = "denx,uimage";
                                label = "firmware";
                                reg = <0x40000 0x7c0000>;
                        };
                };
        };
};

&gmac0 {
	nvmem-cells = <&macaddr_factory_e000>;
	nvmem-cell-names = "mac-address";
};

&switch0 {
        ports {
                port@0 {
                        status = "okay";
                        label = "wan";
						nvmem-cells = <&macaddr_factory_e000>;
						nvmem-cell-names = "mac-address";
                        mac-address-increment = <1>;
                };

                port@1 {
                        status = "okay";
                        label = "lan1";
                };

                port@2 {
                        status = "okay";
                        label = "lan2";
                };

                port@3 {
                        status = "okay";
                        label = "lan3";
                };
        };
};

&state_default {
     gpio {
         groups = "jtag", "uart2", "uart3", "wdt";
         function = "gpio";
     };
};

&pcie {
     status = "okay";
};


&pcie0 {
     mt76@0,0 {
         reg = <0x0000 0 0 0 0>;
         mediatek,mtd-eeprom = <&factory 0x0000>;
         ieee80211-freq-limit = <2400000 2500000>;
     };
};


&pcie1 {
     mt76@0,0 {
         reg = <0x0000 0 0 0 0>;
         mediatek,mtd-eeprom = <&factory 0x8000>;
         ieee80211-freq-limit = <5000000 6000000>;
     };
};

&factory {
	compatible = "nvmem-cells";
	#address-cells = <1>;
	#size-cells = <1>;

	macaddr_factory_e000: macaddr@e000 {
		reg = <0xe000 0x6>;
	};
};

Are you trying to port OpenWrt support for your device? It is not yet supported?
Because normally we don't need to touch the flash block size selections once they have been initially defined when the router support has been originally created. (Just wondering because this started as file system disk space question, and now it sounds like hardware support creation)

A quick glance to the Linux source makes me to think that your chip might not yet be in the databas of supported chips, and it gets misdetectec.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/mtd/spi-nor/winbond.c?h=v5.15.74

Based on that file it seems to be that it might have 64kB erase blocks, but I am no chip specialist. Looking at the OpenWrt source base shows two ramips routers with that same chip.

Ps.
One additional thought: the squashfs is used for the rom part, not the overlay. Overlay has usually jffs2 (older routers with nor flash) and ubi based fs in hand flash routers.

Yep, this is a Mercury D21G with MT7621+MT7603(2.4G wifi)+MT7611EN(OEM MT7615, 5G wifi) and 8MiB ROM +128MiB RAM. No support yet as it is sold only in China and not that popular as TPlink or Xiaomi conterparts.
Anyway, I have it up and running for more than a year with this DTB, so I guess some misunderstood of SPI ROM spec is not that important.
I will try to change the block size to 64kb and see what happens, thank you sir.