My router has 8M flash and 128M RAM
I have attempted to upgrade to a W25Q128JV chip based on this post:
I've got a TL-MR-3040, which is nice, but it has a tiny 4 MB flash. I'd also like to upgrade a "Alfa Hornet UB" (from 8 to 16 MB).
I have a W25Q128FV (that was on a Carambola 2).
Can you outline the steps to replace the flash chip ?
I have a SOIC clip and I've used "flashrom". I know I have to save and restore the "ART" partition.
Do I need to build a new "uboot" or just change the "mtdparts" environment variable ?
Thanks
But I found that the partitioning is hard coded and even though UBOOT recognizes the 16M chip the kernel allocates everything as if it was 8M (moving ART partition to the end has no effect). So everything works, but half the chip is unused.
I am looking for help with modifying the OpenWRT image (or compiling my own). Based on what I read it has something to do with "DTS modification", but I have no idea how to do it.
Flash partitioning and RAM size are hardcoded in the DTS, the image recipes and tplinksafeloader, all of these need adapting - forever.
The bootloader may- or may not need patching/ rebuilding, impossible to say from the outside.
I'd be with you, if we were talking about mt7621a and 'only' replacing the flash with a 16 MB chip - but mt7620a and the RAM are beyond what I'd be willing to do.
Any help would be appreciated.
brada4
January 20, 2025, 3:18pm
2
You have to modify DTS to match your flash layout. Yes, making copy of caldata was a good iedea to start with.
2 Likes
I found another post mentioning the exact same router, but there is no confirmation if DTS modification worked.
I think my image format is diffrent from yours.
my Kernel Image has lzma compression and header format is different from what mkimage command make
can you take a look to wdr4300 openwrt image format if it's possible ?
Hostle
January 20, 2025, 4:27pm
4
dtb is a (compiled) dts. In the post above it is suggested to replace the dtb with a modified one, indicating the dts has been altered.
if you have terminal access you can unpack the dtb using the dtc.
if dtc is installed you can unpacked like
dtc -I fs -O dts /sys/firmware/devicetree/base
if no dtc , try to install it
opkg install dtc
or backup contents of /sys/firmware/devicetree/base, and transfer it to a linux machine and run dtc from a terminal there.
As far as the modification,I believe its pretty straight forward. You need to increase the rootfs partition to utilize the extra space
ie
partition@800000 {
label = "rootfs";
reg = <0x00800000 0x7800000>; <--- =+/-7000000 hex
};
to
partition@800000 {
label = "rootfs";
reg = <0x00800000 0xF000000>; <--- +/-E800000 hex (double sized)
};
keep in mind this is an example, the idea is you increase the original offset (0x7800000 in this case) to suite your needs. Depending on the layout and where the roofs partition is located, it may be necessary to adjust each partition after the rootfs partition to reflect the changes. In the example case, its very easy because rootfs is the last partition, so increasing the size doesn't affect any other partition.
Thanks for the detailed steps, I will try that soon.
1 Like
OK, this was pretty simple
extracted it
partition@20000 {
compatible = "tplink,firmware";
label = "firmware";
reg = <0x20000 0x7d0000>;
};
partition@7f0000 {
compatible = "nvmem-cells";
read-only;
#address-cells = <0x01>;
label = "art";
#size-cells = <0x01>;
reg = <0x7f0000 0x10000>;
firmware partition: increase size by 8M
0x7D0000 + 0x800000 = 0xED0000
ART partition moves to the last 64K
from 0x7F0000 to 0xFF0000 (size stays the same)
So the new partitions section looks like this:
partitions {
compatible = "fixed-partitions";
#address-cells = <0x01>;
#size-cells = <0x01>;
partition@0 {
compatible = "nvmem-cells";
read-only;
#address-cells = <0x01>;
label = "u-boot";
#size-cells = <0x01>;
reg = <0x00 0x20000>;
macaddr@1fc00 {
phandle = <0x07>;
reg = <0x1fc00 0x06>;
};
};
partition@20000 {
compatible = "tplink,firmware";
label = "firmware";
reg = <0x20000 0xad0000>;
};
partition@ff0000 {
compatible = "nvmem-cells";
read-only;
#address-cells = <0x01>;
label = "art";
#size-cells = <0x01>;
reg = <0xff0000 0x10000>;
cal@5000 {
phandle = <0x0f>;
reg = <0x5000 0x440>;
};
cal@1000 {
phandle = <0x0c>;
reg = <0x1000 0x440>;
};
};
};
I hope this is correct
Now how is this going to help me get a custom firmware image? I have been looking at the imagebuilder docs in the meantime and it seems to have way too many options.
https://openwrt.org/docs/guide-user/additional-software/imagebuilder
I just want to build the same image as the OpenWRT release, no fancy addons or minimal image without LUCI.
There's a thread here somewhere, about modifying an existing image by hacking the content, to match a replaced (larger) flash chip.
1 Like
Hostle
January 20, 2025, 6:10pm
8
I would suspect that this is a necessary step to complete the mod.
I think it was without changing anything pre-build, but I might be wrong...
I think you are referring to this method:
I think my image format is diffrent from yours.
my Kernel Image has lzma compression and header format is different from what mkimage command make
can you take a look to wdr4300 openwrt image format if it's possible ?
and it does not work for WDR4300
Hostle
January 20, 2025, 6:16pm
11
interesting, you would think bootloader would need to be aware of the change. paint me curious
In case you are curious this is what I got when I changed to 16M
[ 0.382890] spi-nor spi0.0: w25q128 (16384 Kbytes)
[ 0.387891] 3 fixed-partitions partitions found on MTD device spi0.0
[ 0.394411] OF: Bad cell count for /ahb/spi@1f000000/flash@0/partitions
[ 0.401173] OF: Bad cell count for /ahb/spi@1f000000/flash@0/partitions
[ 0.408668] OF: Bad cell count for /ahb/spi@1f000000/flash@0/partitions
[ 0.415489] OF: Bad cell count for /ahb/spi@1f000000/flash@0/partitions
[ 0.422541] OF: Bad cell count for /ahb/spi@1f000000/flash@0/partitions
[ 0.429352] OF: Bad cell count for /ahb/spi@1f000000/flash@0/partitions
[ 0.436579] Creating 3 MTD partitions on "spi0.0":
[ 0.441462] 0x000000000000-0x000000020000 : "u-boot"
[ 0.453899] 0x000000020000-0x0000007f0000 : "firmware"
[ 0.460546] 2 tplink-fw partitions found on MTD device firmware
[ 0.466635] Creating 2 MTD partitions on "firmware":
[ 0.471680] 0x000000000000-0x00000023af86 : "kernel"
[ 0.476741] mtd: partition "kernel" doesn't end on an erase/write block -- force read-only
[ 0.488044] 0x00000023af88-0x0000007d0000 : "rootfs"
[ 0.493162] mtd: partition "rootfs" doesn't start on an erase/write block boundary -- force read-only
[ 0.503708] mtd: setting mtd3 (rootfs) as root device
[ 0.509819] 1 squashfs-split partitions found on MTD device rootfs
[ 0.516177] 0x0000005d0000-0x0000007d0000 : "rootfs_data"
[ 0.522805] 0x0000007f0000-0x000000800000 : "art"
Hostle
January 20, 2025, 8:46pm
13
I assume this is with the dts mod as the size is correct +/- . seems like an alignment issue. I did a similar mod eons ago ... I do distinctively remember much tinkering with it to get it working properly. I likely still have the notes on an old drive, but this would've been pre dts era so it likely not to be of much help anyway.
That log is in fact stock openWRT moved to a 16M chip. It does not have any modifications.
I did this a while ago, then gave up because of the DTS stuff being too complicated, but I just saved the logs for a time like this.
Hostle
January 20, 2025, 11:28pm
15
Have you tried with your dts mod ? you can repack to dtb format using dtc, I can't recall the exact cmd from memory , a dtc -h it should help.
EDIT
this might come in handy to fix alignment...
-p, --pad <arg>
Add padding to the blob of <bytes> long (extra space)
How can I check if my modified dts is included in the generated factory/sysupgrade image?
I currently have a modified image-ar9344_tplink_tl-wdr4300-v1.dtb in build_dir/target-mips_24kc_musl/linux-ath79_generic where I have overwritten the partition reg entry.
I have checked it with dtc -I dtb -O dts image-ar9344_tplink_tl-wdr4300-v1.dtb and it looks correct, but I don't know if the imagebuilder even uses that file. I have no way to check if my changes make it to the generated image.
use binwalk and dd extract dtb from image. then use dtc to convert it into .dts
reg = <0x20000 0xfd0000>;
math behind it 0xff0000 - 0x20000 =0xfd0000
Custom DTB + imagebuilder can be good solution for this problem
yes, thank you. unfortunately I can no longer edit that message
I am currently trying the suggestion from this post:
Generating a "official" kernel image with modded dtb is key.
I met the same problem as reported in this thread on my wdr4900v2 modded with a 16MiB rom, and I managed to achieve above goal by making use of both image builder and the source tree:
Modify the dts file for the target. (It had better be made a local commit in its own branch, as it can be cherry-picked upon future revisions)
Build a minimalist custom build for the target (which is unlikely to fail, as it is minimalist), to build all…
I have successfully compiled a modified image from source (not tested yet).
I modified 2 files:
openwrt/target/linux/ath79/dts/ar9344_tplink_tl-wdrxxxx.dtsi (modify the partitions)openwrt/target/linux/ath79/image/generic-tp-link.mk (change $(Device/tplink-8mlzma) to $(Device/tplink-16mlzma) under define Device/tplink_tl-wdr4300-v1)
I checked the dtb:
openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic$ dtc -I dtb -O dts image-ar9344_tplink_tl-wdr4300-v1.dtb
output has the desired outcome:
partitions {
compatible = "fixed-partitions";
#address-cells = <0x01>;
#size-cells = <0x01>;
partition@0 {
label = "u-boot";
reg = <0x00 0x20000>;
read-only;
compatible = "nvmem-cells";
#address-cells = <0x01>;
#size-cells = <0x01>;
macaddr@1fc00 {
reg = <0x1fc00 0x06>;
phandle = <0x07>;
};
};
partition@20000 {
compatible = "tplink,firmware";
label = "firmware";
reg = <0x20000 0xfd0000>;
};
partition@ff0000 {
label = "art";
reg = <0xff0000 0x10000>;
read-only;
compatible = "nvmem-cells";
#address-cells = <0x01>;
#size-cells = <0x01>;
cal@1000 {
reg = <0x1000 0x440>;
phandle = <0x0c>;
};
cal@5000 {
reg = <0x5000 0x440>;
phandle = <0x0f>;
};
};
};
so my partition changes are included by the build process. Now I just need to test it on the hardware.
