Support for DIR-842 rev: C1

This is from openwrt, I have not actually soldered the UART pins to check from the stock firmware, I only extracted the image from an older variant and looked around the filesystem:

dev:    size   erasesize  name
mtd0: 00040000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00010000 00010000 "devdata"
mtd3: 00010000 00010000 "devconf"
mtd4: 00010000 00010000 "misc"
mtd5: 00f50000 00010000 "firmware"
mtd6: 001bffc0 00010000 "kernel"
mtd7: 00d90000 00010000 "rootfs"
mtd8: 00af0000 00010000 "rootfs_data"
mtd9: 00010000 00010000 "art"
mtd10: 00020000 00010000 "reserved"

[    0.406236] Creating 8 MTD partitions on "spi0.0":
[    0.411196] 0x000000000000-0x000000040000 : "u-boot"
[    0.417111] 0x000000040000-0x000000050000 : "u-boot-env"
[    0.423348] 0x000000050000-0x000000060000 : "devdata"
[    0.429340] 0x000000060000-0x000000070000 : "devconf"
[    0.435336] 0x000000070000-0x000000080000 : "misc"
[    0.440983] 0x000000080000-0x000000fd0000 : "firmware"
[    0.451171] 2 seama-fw partitions found on MTD device firmware
[    0.457252] Creating 2 MTD partitions on "firmware":
[    0.462384] 0x000000000040-0x0000001c0000 : "kernel"
[    0.468275] 0x0000001c0000-0x000000f50000 : "rootfs"
[    0.474045] mtd: device 7 (rootfs) set to be root filesystem
[    0.481372] 1 squashfs-split partitions found on MTD device rootfs
[    0.487827] 0x000000460000-0x000000f50000 : "rootfs_data"
[    0.494153] 0x000000fd0000-0x000000fe0000 : "art"
[    0.499841] 0x000000fe0000-0x000001000000 : "reserved"


hexdump -s 0x5000 /dev/mtd9
0005000 ffff ffff ffff ffff ffff ffff ffff ffff
*
0010000

Ya, as you can see the mtd9 partition is filled with ff ff ff ff ff only....

The layout scheme of openwrt is pre-defined, so we need to get the partition layout of the original firmware in order to find out where the calibration (art) partition is.

in mtd1, the uboot environment contains these bootflags

bootargs=console=ttyS0,115200 root=31:02 rootfstype=jffs2 init=/sbin/init mtdparts=ath-nor0:256k(u-boot),64k(u-boot-env),14528k(rootfs),1408k(uImage),64k(mib0),64k(ART)

Which means art should line up at 0xff0000

Dumping /dev/mtd10 with openwrt booted yields 128k of data (0xfe0000-0x1000000), and what looks like the magic I see for the first 2 bytes of other art partitions at 0x5000 I have inspected:

$hexdump -s 0x15000 -n 16 mtd10
0015000 2f20 0e15 0101 0300 257f 2514 0000 0020

However, the driver doesn't load when I try to use that for pre-cal-pci-0000:00:00.0.bin when I patched 11-ath10k-caldata to read from there, nor does it load if I indicate that as cal-pci-0000:00:00.0.bin.

Another interesting note:

mtd9:0x1000 looks like ath9 data as is mtd10:0x11000

$ hexdump -s 0x1000 -n 16 mtd9
0001000 0202 0302 008f 8e03 0000 0000 0000 0000
$ hexdump -s 0x11000 -n 16 mtd10
0011000 0202 0200 0403 0605 0000 0000 0000 0000

1 Like

my router also shows:
bootargs=console=ttyS0,115200 root=31:02 rootfstype=jffs2 init=/sbin/init mtdparts=ath-nor0:256k(u-boot),64k(u-boot-env),14528k(rootfs),1408k(uImage),64k(mib0),64k(ART)

but my art partition starts at 0xfd0000 , so i dont think the bootargs actually corresponds to the partition layout

Can you show how you patch the 11-ath10k-caldata ?

case "$FIRMWARE" in
"ath10k/pre-cal-pci-0000:00:00.0.bin")                  
        case $board in                                  
        dlink,dir-842-c1)                               
                caldata_extract "reserved" 0x15000 0x2f20
                ath10k_patch_mac $(mtd_get_mac_ascii devdata wlan5mac)
                ln -sf /lib/firmware/ath10k/pre-cal-pci-0000\:00\:00.0.bin \
                        /lib/firmware/ath10k/QCA9888/hw2.0/board.bin        
                ;;

I think I screwed up the first time I tried it and left some files in /lib/firmware from other attempts, after clearing everything out and using that patch, it does function properly, the radio signal and link characteristics do not seem to work quite as well as with boardData_2_0_QCA9888_5G_Y9582.bin:

mtd:0xff5000:
client signal @ 2m distance: -54 dBm

boardData_2_0_QCA9888_5G_Y9582.bin:
client signal @ 2m distance: -42 dBm

The other thing that puzzles me is that I don't see any bash scripting in the stock firmware trying to extract that range from the mtd, however it is likely buried in the qsdk driver they are using in binary form.

The closed source driver in the stock firmware and read the art partition directly, so it does not need to extract the data from mtd.

If you can make sure this is working, can you open a pull request? I am not sure how OpenWrt maintainers are going to deal with this though. We need some scripts to select where to load the art data. (without breaking the working wifi on some of the DIR842)

Anyway thank you very much for you work!

Personally I think the better approach would be to go against the decree in https://openwrt.org/docs/guide-developer/defining-firmware-partitions and instead use the flash layout specified in the u-boot env to maximize compatibility, however we would need to collect a sufficient set of u-boot env samples to determine that we never accidentally overwrite art.

Can you post the u-boot env boot flags from your c1 device?

u-boot env does not correspond to the real flash layout

Interesting. I would be curious to see what is at 0xff0000, 0xff1000 and 0xff5000 for comparison.

I haven’t found anywhere in flash that contains a model number or serial that the stock firmware could be using to detect. They use a single image for all 3 models so I would like to figure out how the vendor expects this to work with their own firmware.

It would also be interesting to compare serial/model numbers over PM. Mine at least has a second sticker covering the stock label. I’ll dig it out of the closet tonight to take a look.

The interesting thing is that not only C1 user, but C2 and C3 users have this "two version" issue too.

But unfortunately I dont have the router now so I cant give you my serial numbers. I will do it as soon as i can

1 Like

I do have a C1 at my hands and I do have the same issue that OpenWRT seems to have problems accessing the ART partition.

Would it be of any help, if I posted a boot log from the stock firmware?