TP-Link RE355 v1 and RE450 v1/v2 moved to Tiny Builds

For Developers
1

imagen
imagen669×1018 26.3 KB

Hello everyone,

I’ve seen over the years how the community has been pushing to make the TP-Link RE355 v1 and RE450 v1/v2 work with their limited partitioning scheme. Those devices can allocate only 5.7 MB of firmware size.

Multiple challenges have affected the firmware size, but two of them are key:

  • Migration from ar71xx to ath79: Older drivers with many workarounds had excellent performance but were hard to maintain.

  • The need for WPA3 with strong encryption: This makes it necessary to use an encryption backend like OpenSSL or WolfSSL. Recently, it has become impossible to fit everything into such minimal sizes, so the firmware builder stopped generating new releases until the v23 release candidates.

That is going to change — partially.

I made a minimal PR months ago trying to move to the OpenWrt tiny variant. This variant doesn’t have LuCI but can be perfectly used with UCI and SSH command line. Everything was fine until the maintainers told me that my builds would be considerably smaller than the official ones. This is because the firmware builder creates the Linux kernel with all the standard modules. As a result, the firmware will not return to the Firmware Selector but instead can be built from source code to generate a SNAPSHOT release or any recent one like the 24.xx variants.

Why this is important?

In the forums, there are contributors who in good faith have made their own builds and shared binaries. Although we can assume people don’t intend to harm or get harmed, supply chain attacks are becoming more common, and there will always be malicious actors trying to make your device part of a botnet.
Getting an official way to build a variant guarantees trust and lets you safely build the firmware yourself.

Status:

As of Oct ’25, you may need to Git cherry-pick the PR commit in order to build OpenWrt with the latest stable release (24.xx). My expectation is that it will be promoted into the next stable release, as the code has already been merged.

Known Issues:

People moving from 19.x releases (ar71xx) to 20.x and newer have noticed a performance regression. A device capable of providing 600 Mbps up/down can now provide only 200/400 Mbps up/down. It’s known that this is part of the migration to ath79, and no tested workaround has solved it.

TODO:

In the PR, several contributors have asked about the possibility of gaining more space without bricking any device. People are welcome to suggest and test, but I only own a single RE450 v2 and can’t risk bricking it after others have also failed.

Thanks

I want to give special thanks to everyone who helped me to promote this code and to all the contributors who are still trying to keep these devices alive.
Your time, feedback, and testing have made a real difference for the community. Even with limited hardware, your effort proves that collaboration and persistence can keep these projects moving forward.

6 Likes
2

Hi @ivanddiaz ,

Thank you for looking into this and sorry to hear that moving it to tiny is not sufficient to get images build.

I looked a bit into mtd-concat [1] and it does not look that complicated.

I also dumped the config partion on my RE450v1 and it looks like, it just contains 0xFF after 0x10420. If config partition would be shrink to 0x20000 (which anyway seems to be already the case on RE450v2 [2]), that would give us 0x1a0000 (1664 KiB) of extra space.

As you recently interacted with maintainers, maybe you can give me some explanations:

  1. why is firmware selector building always a bigger kernel, with modules which are not needed. Would not it make sense, to make fix it, to build more size optimized kernels.

  2. would such re-partioning be merged by maintainers? (I am aware of this discussions regarding repratitioning [3], but I am hoping if mtd-concat would be used, instead of just deleting everything in between, that could be acceptable).

I still have UART adapter connected to my RE450v1 from times I worked on initial re450 support [4] almost a decade ago - just before I start spending my time on this, I wanted to check, if this makes even sense to do.

[1] https://github.com/openwrt/openwrt/commit/ebd5e5fb5359d5afb9b0cbda8727830592615a81

[2] https://github.com/openwrt/openwrt/blob/main/target/linux/ath79/dts/qca9563_tplink_re450-v2.dts#L53

[3] Support for TP-Link RE450 v1/v2 for 22.X/23.X/24.X releases (Change of partition layout)

[4] https://github.com/openwrt/openwrt/commit/3561d89ad696db7edf14a9e53c3f4c08a506cd2a

Cheers,
Radek

3

Hi @ivanddiaz ,

I really got motivated and it was easier than expected. Do you mind checking https://github.com/openwrt/openwrt/pull/20709

Thanks,
Radek

4

Hi @radek.dostal,

  1. why is firmware selector building always a bigger kernel, with modules which are not needed. Would not it make sense, to make fix it, to build more size optimized kernels.

The Firmware Selector is mainly a frontend that asks a build service to make images. The build service uses the target’s normal kernel config and standard kmod packages so images work on many boards. The “tiny” variant removes userspace packages (like LuCI) but usually keeps the same kernel config, so the kernel still contains many modules. Making a much smaller kernel requires changing the kernel defconfig or making a special build profile, that is extra work and maintenance for the project. Also, modern OpenWrt releases recommend ~16MB/128MB hardware, so small devices are treated as best-effort.

  1. would such re-partioning be merged by maintainers? (I am aware of this discussions regarding repratitioning [3], but I am hoping if mtd-concat would be used, instead of just deleting everything in between, that could be acceptable).

I think the main reason the project avoids repartitioning is to keep the option to roll back to stock firmware and also to avoid breaking upgrades from old OpenWrt releases.

For these devices it’s a bit different: TP-Link stopped support years ago and the stock firmware tools no longer work well. Even if you keep the same partition layout, flashing stock image often bricks the device. So the “rollback” argument is not very strong anymore.

Still, maintainers prefer safe migration. Using mtd-concat may be acceptable if the change includes proper upgrade scripts and testing, but there is no guarantee they will merge it.

5

I agree with your idea and will test your PR tonight on my RE450 v2. Wish me luck!

6

Hi @ivanddiaz

The Firmware Selector is mainly a frontend that asks a build service to make images. The build service uses the target’s normal kernel config and standard kmod packages so images work on many boards. The “tiny” variant removes userspace packages (like LuCI) but usually keeps the same kernel config, so the kernel still contains many modules. Making a much smaller kernel requires changing the kernel defconfig or making a special build profile, that is extra work and maintenance for the project.

interesting - I am coming more from Yocto world, where you can have one defconfig, which builds you many modules, but than you can easily chose which modules you pull into your image.

Also, modern OpenWrt releases recommend ~16MB/128MB hardware, so small devices are treated as best-effort.

This actually got me thinking even more. I noticed following u-boot output on UART of my module:

U-Boot 1.1.4 (May 30 2016 - 13:58:13)

ap135 - Scorpion 1.0

DRAM:  128 MB
Top of RAM usable for U-Boot at: 88000000
Reserving 133k for U-Boot at: 87fdc000
Reserving 192k for malloc() at: 87fac000
Reserving 44 Bytes for Board Info at: 87fabfd4
Reserving 36 Bytes for Global Data at: 87fabfb0
Reserving 128k for boot params() at: 87f8bfb0
Stack Pointer at: 87f8bf98
Now running in RAM - U-Boot at: 87fdc000
Flash Manuf Id 0xef, DeviceId0 0x40, DeviceId1 0x17
flash size 16MB, sector count = 256
Flash: 16 MB

and it says 16MB. Could it be, that some of the units were actually stuffed with 16 MB of flash and it was just no used? Sorry after finding extra 1.6MiB of unused flash, it would not surprise me, if I would find extra 8 MiB too :slight_smile:

Still, maintainers prefer safe migration. Using mtd-concat may be acceptable if the change includes proper upgrade scripts and testing, but there is no guarantee they will merge it.

understand. For me the upgrade was very straight forward. I just run sysupgrade and it worked, but that was mainly because I used the custom build which was just 5697 KiB. The sysupgrade will probably not work with the official build, because that one will be over 6016 KiB. It will be necessary to flash one unofficial build in between or load the official build using TFTP and flash from there.

I agree with your idea and will test your PR tonight on my RE450 v2. Wish me luck!

good luck, if you build locally and your build will be smaller than 6016 KiB, I am pretty sure, it will work out of the box (just use -F).

Cheers,
Radek

1 Like
7

imagen
imagen816×1038 22.9 KB

Hi @radek.dostal, I’ve tested in my 450v2, no issues. Now we’ve 1.8 MB more space to “theorically” accomodate LuCI or whatever there. Thanks so much for this. Hope to see this merged!

8

@radek.dostal,

9

Hi @samoth

Here is the temporary link (will be deleted after +/- 6 months) to my local RE450v1 build. It is a small build, so it can be flashed easily just with sysupgrade -F

Thanks,
Radek

10

Hi @radek.dostal

thank you very much worked on four devices without issues :slight_smile:

Thanks Samoth

11

Hi @samoth ,

thank you very much worked on four devices without issues :slight_smile:

happy to hear that.

  1. Can you please also provide this information on the github pullrequest https://github.com/openwrt/openwrt/pull/20709 - the discussion there is a bit quiet and hopefully this will help more maintainers to feel confident about the merge.

  2. Can you provide me with your name and e-mail address. If it is ok with you and @ivanddiaz - I will add “Tested-by” into the commit message. That is also usually appreciated by maintainers.

Thanks,
Radek

12

Hi @radek.dostal

I commented on github :slight_smile:

Thanks Samoth

1 Like
13

Hello @ivanddiaz and @samoth ,

So good news is that my merge request got merged. The bad news is, that builds are not available at https://mirror-03.infra.openwrt.org/snapshots/targets/ath79/tiny/

I investigated the issue a bit. The tiny build do not need to take advantage of mtd-concat to fit, but firmware selector builds are bigger => they need this.

To reproduce the issue, I tried to increase size of image a little bit by adding few more packages. Please see following diffconfig for details

CONFIG_TARGET_ath79=y
CONFIG_TARGET_ath79_tiny=y
CONFIG_TARGET_ath79_tiny_DEVICE_tplink_re450-v1=y
CONFIG_PACKAGE_diffutils=y
CONFIG_PACKAGE_make=y
CONFIG_PACKAGE_patch=y

which should increase openwrt-ath79-tiny-tplink_re450-v1-squashfs-sysupgrade.bin from 5899122 to 6095730, but instead it prints following warning and no sysupgrade file is produced.

 make[2] package/install
 make[2] target/install
 make[3] -C target/linux install
    WARNING: Image file /home/rdostal/git/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_tiny/tmp/openwrt-ath79-tiny-tplink_re450-v1-squashfs-sysupgrade.bin is too big:  > 7864320
 make[2] package/index
 make[2] json_overview_image_info
 make[2] checksum

Notice that there is no number before > - the reason likely is the file is actually missing!

I can make the build pass by adding following two lines which I did not take from my inspiration commit https://github.com/openwrt/openwrt/commit/ebd5e5fb5359d5afb9b0cbda8727830592615a81

diff --git a/target/linux/ath79/image/tiny-tp-link.mk b/target/linux/ath79/image/tiny-tp-link.mk
index 7e61eb96af..eede20e6cf 100644
--- a/target/linux/ath79/image/tiny-tp-link.mk
+++ b/target/linux/ath79/image/tiny-tp-link.mk
@@ -9,6 +9,8 @@ define Device/tplink_rex5x-v1
   DEVICE_COMPAT_VERSION := 2.0
   DEVICE_COMPAT_MESSAGE := Partition layout has changed compared to older versions by utilizing unused flash. \
     Upgrade via sysupgrade mechanism (-F) will only work if flashed image still fits to the size of old partition (6016 KiB).
+  IMAGES := sysupgrade.bin
+  IMAGE/sysupgrade.bin := append-kernel | append-rootfs | pad-rootfs | check-size | append-metadata
 endef
 
 define Device/tplink_re355-v1

I did not take these lines originally because

  1. it looked that it works without them (now I know it works only for small size)
  2. I did not understand what are they doing, and I do not want to be sending something I do not understand to maintainers.

Now I kind of understand what line “IMAGES := sysupgrade.bin” does. It says that only sysupgrade image should be build and not the factory image. That is logical, as factory image can not be increased. Still I do not understand, what is the second line and that puzzles me.

If any of you have any hints, suggestion, explanation, … , so I can submit corrective pull request so we get the firmware selector working again, that would be really great.

Thanks,
Radek

14

Did you try e.g. perplexity with the following input:

IMAGES := sysupgrade.bin
IMAGE/sysupgrade.bin := append-kernel | append-rootfs | pad-rootfs | check-size | append-metadata

Best regards, samoth

15

Hi @radek.dostal,

First of all, thank you for this amazing work!

I think the problem might be this line:

KERNEL_SIZE := 6016k

in openwrt/target/linux/ath79/image/tiny-tp-link.mk.

The devices tplink_rex5x-v1 and tplink_re450-v2 have a hard limit with KERNEL_SIZE := 6016k.

At that time I did not changed something that was already working. But if we compare with the generic builds (RE450-v3 or RE455), this kernel limit does not exist.

Can you test your build after removing these lines? I think this limit is not needed anymore.

16

Hi @samoth and @ivanddiaz ,

Did you try e.g. perplexity with the following input:

I do not have experience with perplexity, just tried it with ChatGPT and it provided me a lot of text which was generally correct, but did not really answered the question. If you have perplexity access, do you mind giving it a try. I have one possible explanations, so if it says the same, it could be the correct. But to be honest, I bit doubt it will help.

I think the problem might be this line:

KERNEL_SIZE := 6016k

in openwrt/target/linux/ath79/image/tiny-tp-link.mk.

The devices tplink_rex5x-v1 and tplink_re450-v2 have a hard limit with KERNEL_SIZE := 6016k.

At that time I did not changed something that was already working. But if we compare with the generic builds (RE450-v3 or RE455), this kernel limit does not exist.

Can you test your build after removing these lines? I think this limit is not needed anymore.

I am 99% sure that this line is correct. Compare to OpenWRT buildsystem, embedded Linux is my daily bread and butter. With mtd-concat the whole kernel/rootfs is split across two locations of the flash, but only kernel is aware of this (via device tree changes) as we did not do any changes to the bootloader (u-boot).

Based on above I am pretty sure, that this line (KERNEL_SIZE := 6016k) is specifying that Linux kernel, which is loaded by u-boot needs to fit into first part of mtd_concat, because u-boot is not aware that we extended the place for rootfs by unused space. The kernel should be fitting into this limit without any problem as it seems to be bit less than 2MB (mtd8: 001d809d 00001000 "kernel").

The reason why this limit does not exist on RE450-v3 or RE455 is, that there partition layout is different and there is no need to use mtd-concat on them.

Thanks,
Radek

17

Hi Radek,

could it be that the parameter check-size needs a parameter against it should be checked see

Best regards, samoth

18

Hi Samoth,

it works even without any parameter - just the way I wrote it, but I do not know why it is needed at all and that puzzles me.

If nobody knows, I will probably try to open another merge request and ask maintainers for help. They will know for sure, but usually it is easier to get merged something what you are sure why it works.

Thanks,
Radek

19

Hi @radek.dostal,

I’m seeing tiny builds in https://mirror-03.infra.openwrt.org/snapshots/targets/ath79/tiny/

Right now the official firmware builder at https://firmware-selector.openwrt.org succeeds or fails depending on the number of packages. I will spend some time to check how that works. Maybe the default package list needs to be changed, or different limits should be set there.

I would also like to ask for permissions to edit the wiki. I think we need to guide users through the upgrade process. For example: start with 22.04, then build a snapshot with a minimal set of packages (no SSL/WiFi), and then build the bigger firmware image. What do you think?

20

You are right the Kernel_Size needs to be updated to the new values see

KERNEL_SIZE should be 6016k + 1664k = 7680k

Best regards, Samoth