Tl-wr 841nd v8 16M flash sysupgrade

I am trying to upgrade 18.06 to either 21.02 or 22.03 with sysupgrade of the compiled 16M lzma image. First time I have upgraded to 21.02 the router has stuck in the jfss error, saying mask bit on the xxx sector. Then I did factory flash from the httpd bootloader on 21.02 - same thing error on jfss system. I recovered then back to 18.06 and flashed pre-compiled image of 22.03 with sysupgrade. The device is now in a boot loop. Before I start digging with serial again, has anyone done a succesful upgrade to 21.02 or 22.03 openwrt on the Tplink Tl-wr841nd router with upgraded flash?

you need to modify dts of 841v8 to 16mb flash https://github.com/openwrt/openwrt/blob/1722e23ffcf9038114142a2129c29eb3cdec8ff9/target/linux/ath79/dts/ar9341_tplink_tl-wr841-v8.dts#L55 and recompile openwrt

1 Like

Aside from that, 16 MB flash on a 32 MB RAM device is excessive - this image must fit into RAM during a sysupgrade, but it won't (no way to retain 16 MB free RAM).

The Ram upgrade was done to 64MB. I am going to try the DTS modification and report back.

you could try Increasing flash size without build my own firmware

1 Like

I can now provide more insight into this bootloop

[    7.371979] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00220014: 0x3d8b instead
[    7.381809] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00220018: 0x72eb instead
[    7.391630] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0022001c: 0xf633 instead
[    7.401448] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00220020: 0x4ab8 instead
[    7.411266] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00220024: 0x8863 instead
[    7.421071] jffs2: Further such events for this erase block will not be printed
[    7.474253] jffs2: Cowardly refusing to erase blocks on filesystem with no valid JFFS2 nodes
[    7.483008] jffs2: empty_blocks 0, bad_blocks 0, c->nr_blocks 35
[    7.489330] VFS: Cannot open root device "(null)" or unknown-block(31,3): error -5
[    7.497151] Please append a correct "root=" boot option; here are the available partitions:
[    7.505811] 1f00             128 mtdblock0
[    7.505817]  (driver?)
[    7.512601] 1f01            3904 mtdblock1
[    7.512607]  (driver?)
[    7.519380] 1f02            1611 mtdblock2
[    7.519386]  (driver?)
[    7.526145] 1f03            2292 mtdblock3
[    7.526151]  (driver?)
[    7.532929] 1f04              64 mtdblock4
[    7.532934]  (driver?)
[    7.539707] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,3)
[    7.548340] Rebooting in 1 seconds..

That looks like unsupported flash chip -- it refuses to read or write it because the JEDEC numbers are not in the driver. Earlier in the log you should see that.

Quite strange, because the compiled 18.06 works. The only difference is that it was compiled from openwrt source two years ago.
I have just found this thread How to add support for SPI NOR Flash for a single build - #3 by mpratt14 .
Did the spi source changed between 18.06 and 21.02?

The flash type is w25q128fvsig, but it is quite strange that kernel 4.9 runs without problems, whereas kernel 5.10 refuses to boot. Any info on that, when was this regression introduced in the kernel?

put your whole kernel log

Here it is: Kernel.log

I was also following this guide on changing the 16M flash chip two - three years ago: https://www.youtube.com/watch?v=l6rw1zo4A2c

The compilation for 22.03 is not that straightforward as for the 18.06.

For generating the 16M factory image for boot flashing I just had to change the 4mlzma to 16mlzma, but unluckily the flash layout does not match the previously flashed 18.06, even not working with sysupgrade, making the same boot loop in 22.03.

ar71xx has a model-specific C routine for automatic flash partitioning. New kernel standards prohibit such things. In ath79, the partitions now must be defined in the dts.

The problem with your boot is it is still partitioned for 4M, so there is no available flash for the complete rootfs and overlay.

The 18.06 has following partitions:


mtd0: 00020000 00010000 "u-boot"
mtd1: 00128160 00010000 "kernel"
mtd2: 00ea7ea0 00010000 "rootfs"
mtd3: 00c30000 00010000 "rootfs_data"
mtd4: 00010000 00010000 "art"
mtd5: 00fd0000 00010000 "firmware"

I was able to dump all of them,


  131072 szept 23 22:17 mtd0.hex    - size  0x0020000, offset 0x000000
 1212768 szept 23 22:19 mtd1.hex    - size 0x00128160, offset 0x0020000
15367840 szept 23 22:21 mtd2.hex    - size 0x00ea7ea0, offset  0x148160 ?
12779520 szept 23 22:22 mtd3.hex
   65536 szept 23 22:23 mtd4.hex    - size  00010000,  offset 0xFF0000 ?
16580608 szept 23 22:24 mtd5.hex

When my dump is correct, then the running 18.06 uses full flash 0xFFFFFF, so the partitioning should follow:

- size  0x0020000, offset 0x000000 for uboot
- size 0x00128160, offset 0x0020000 for kernel
- size 0x00ea7ea0, offset  0x148160 for rootfs
- size  00010000,  offset 0xFF000 for art

Now the question is which dts file should be modified for the TL-WR841ND V8. After compiling I am going to write the firmware partition with the factory image.

See Tl-wr 841nd v8 16M flash sysupgrade - #2 by maurer

After DTS modification, the router boots.
For future reference: the dts openwrt/target/linux/ath79/dts/ar9341_tplink_tl-wr841-v8.dts was modified following way:

starting on line 52:

 partition@20000 {
                                compatible = "tplink,firmware";
                                label = "firmware";
                                reg = <0x020000 0xfd0000>;
                        };

                        art: partition@3f0000 {
                                label = "art";
                                reg = <0xff0000 0x010000>;
                                read-only;

The size of the firmware partition was modified to 0xfd0000 and the beginning of the art partition was modified to 0xff0000 ( 0xfd0000+0x020000).

After this modification the sysupgrade image was uploaded and flashed to the device.

This post provides explanation why the 18.06 method of compilation was not working anymore.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.