Is it possible to overwrite the backup boot partition in gs1900-8? I would like to use the backup partition flash mem to get more under
The gs1900-8 has ~16mb of flash mem. I was hoping it would be enough to install a couple small packages but upon getting the device I found out that I could not install one package with the default openwrt 21.02.1 release.
root@OpenWrt:~# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 2.5M 2.5M 0 100% /rom
tmpfs 60.4M 876.0K 59.5M 1% /tmp
/dev/mtdblock8 1.7M 1.6M 92.0K 95% /overlay
overlayfs:/overlay 1.7M 1.6M 92.0K 95% /
tmpfs 512.0K 0 512.0K 0% /dev
root@OpenWrt:~# df -m
Filesystem 1M-blocks Used Available Use% Mounted on
/dev/root 3 3 0 100% /rom
tmpfs 60 1 60 1% /tmp
/dev/mtdblock8 2 2 0 95% /overlay
overlayfs:/overlay 2 2 0 95% /
tmpfs 1 0 1 0% /dev
I think it is allocating 8mb/16mb per boot partition. (between primary & backup) So I was hoping to have around 4-5mb of flash mem but really only have 1.7mb for use available. I am going to try to custom compile openwrt without things like luci and see where that gets me, but it would be great to use the backup boot partition
Not without quite invasive source changes, this is the vendor's flash partitioning (almost set in stone by the OEM bootloader) which OpenWrt images adhere to.
Ok thanks. So referencing your post " The biggest quirk for the ZyXEL gs1900 family is the flash size (IMAGE_SIZE := 6976k for kernel+rootfs)"
IMAGE_SIZE and building will not work?
Does this mean its pretty near impossible to edit the flash partitions for any device in OpenWrt?
Technically speaking you could change (or totally remove)
IMAGE_SIZE and build arbitrarily large images (gigabytes, if you'd like), 'just' trying to flash these to your hardware would a) fail and b) brick your device. You can't overcome hardware limits in software or closing your eyes (yes, bootloader imposed limits aren't strictly speaking hardware limits, but darn close unless you're in a position to modify the bootloader (the source is there, not trivial, very high risk, if you have to ask, don't)).
Kind of. You can to some extent but it's all hard-coded so it's not convenient to change (you need to do a little dts patch and recompile everything from source) and there are limitations and caveats.
You can define a partition that joins adjacent flash partitions, or use
mtd-concat to join distant partitions. See Can I stack on a second overlayfs from RAM to temporarily install more packages? - #13 by bobafetthotmail
The caveat is that this new partition table (or the use of mtd-concat driver) happens ONLY inside OpenWrt while the bootloader (and stock firmware) are unaware of this. So you can usually commandeer more space for your rootfs partiton, but not change the kernel partition size/space.
That is because the bootloader expects the kernel in the same place and same partition as stock firmware, while the rootfs is a thing that is detected and mounted by the kernel later in the boot process, and OpenWrt kernel will have the altered partition table (and mtd-concat) to do what you want.
For what you want to do, it should theoretically work, since you would be just taking over two rootfs partitions (or whatever that is) while leaving at least one of the original kernel partitions so the bootloader can read and boot your Openwrt kernel
Before you try hacking the source to do this, please see if you can just use the imagebuilder https://openwrt.org/docs/guide-user/additional-software/imagebuilder to make an image with all packages you need. Images created like that will put all packages you selected in the high-compression read-only squashfs partition and that will shrink them significantly so maybe they can just fit as-is.
Note that this is not just a "openwrt limitation", most embedded devices work like this with hardcoded partition table in boot loader and Linux firmware. (Because quite frankly nobody expects the end user to change this).
As you saw above, OpenWrt does have some custom drivers to help people work around it a bit.
Form what I saw in the mtd table, We need to re-partition the SPI NOR flash to allow us access the rest of the flash memory space. I know this is not everybody's cup of tea, but we have the space but the software limits us. From the Macronix MX25L12835F datasheet, I can see that there are 3 modes of operation of this NOR Flash. Currently, as we see 8 MiB - that means it is in 67,108,864 x 2 bits structure mode.
cat /proc/mtd - output
root@OpenWrt:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00040000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00010000 00010000 "u-boot-env2"
mtd3: 00100000 00010000 "jffs"
mtd4: 00100000 00010000 "jffs2"
mtd5: 006d0000 00010000 "firmware"
mtd6: 00310000 00010000 "kernel"
mtd7: 003c0000 00010000 "rootfs"
mtd8: 000e0000 00010000 "rootfs_data"
mtd9: 006d0000 00010000 "runtime2"
I did not get much time to dig further into the datasheet, but if we can set the mode to 134,217,728 x 1 bit structure, we can use the full 16 MiB. But we need to make OpenWRT and other components aware of this. And we need to make sure we have all the partitions in the right place for the CPU to read from.
I am new to OpenWRT and I love it. I never want to switch back to the crappy stock web UI.
I am not sure where to begin with while having tons of super useful guides and information, Any direction suggestion would be helpful. Thanks
Your 'problem' is not how the flash is accessed, but how it is partitioned - and you won't change the later by changing the access mode (which wouldn't do you any good anyways).
If you want to use the full flash, you'd have to change the partitioning and do away with the secondary partition of its dual-firmware setup - the only way to accomplish that, is by first replacing the dual-firmware capable vendor u-boot with a modified single-firmware bootloader. Doing that is possible, but risky business - once that is done, the OpenWrt specific changes would be trivial in comparison (be aware that there are pending efforts to bring real alternating sysupgrades for realtek to OpenWrt, so your changes would clash with that).