Support for DIR-842 rev: C1

Glad to hear this, but if I understood right: testing is not done by "cooking" bin's and flashing them in emergency/recovery mode (which accepts "any" firmware)? There shouldn't be a need for tftp.

Look, dir-859 works flashing openwrt in emergency mode straight away: D-Link DIR-859 A3 AC1750 works with DIR-869 A1 image

Essentially what else would we need?

Sorry if I appear too simple, but: take openwrt from dir-859 (edit: 869 also similar, all revisions?), put qca9888 driver and the hw addresses found in bootlog. And done. It should just work, isn't it?

When modifying hardware, routers, computer systems. It's prudent to base actions on could. Not should.

One "should" ask oneself;

  1. What do I need to do ( we have now pretty much cleared that up... barring some seama / boot trick schemantics )

  2. How am I going to do it. You've addressed the software creation side of this.... Can you go into more detail on applying test firmware.

  3. What can go wrong, and what am I going to do if/when it does. What are your plans?

This is where my limited knowledge and availability of tools ends. Advanced software and hardware is something that I won't be able to help with. I can learn and acquire them, but it takes time and money.

However I am perfectly willing to:

  1. Try and find someone to do a hexdump on the memory, in the process desoldering it and destroying the router.
  2. Mail it in Europe (or even somewhere else not too far away from Romania) via post service, it's dirt cheap.
  3. Risk bricking the device with even the most poorly built firmware, with the poorest of boot tricks stuck-together.


I was kind of hoping you'd say that......

Hi all,

I try to flash the router using this fw via recovery mode

not working, the router stuck in recovery mode.
I need to reflash it again using dlink fw


Some relevant info in this thread... Please don't spam it with C1 stuff. Anyone with the skills may be interested in perusing or testing the PR.

The C2 support has been merged into master. That image should work on C1 as well.
If someone is ready to test, it is quite easy to add official C1 support.

Pull request to support C1 is here:

C2 image works perfectly on C1


Why don't you disable USBfor c1 in dts?

Mainly because the USB on C1 can be modded with some soldering skills. So people wont have to recompile the image if they have a modded C1, they just have to install kmod-usb2

This is not the way it is normally done. Those who can solder USB can also build an image with modified dts.
Otherwise I don't see a reason of having a separate image for c1. We could have one for both c1 and c2 since the only diff is the USB.

Also soldering people can simply install C2 image.

Today I got my hands on a C3 (or maybe C3EU). I created Support for D-Link DIR842 (Rev C3) - Maybe EU version? for the discussion.

Has anyone actually confirmed that GPIO 15 is correct for the power / status LED ?
I'm just wondering why it's constantly on during boot, rather than showing the typical OpenWRT flash pattern to allow for entering failsafe mode.

Also I noticed that 2.4 GHz wifi will use the label mac in OpenWRT (i.e. the same as for LAN), rather than the WAN mac as the stock firmware would do. Is this intended behaviour so that wifi would use the same MAC as LAN?

Is anyone willing to share a backup of an ART partition for the C1 with me? Mine doesn't seem to have any ath10k data.

your device seems to have art partition stored in another partition.

It seems like we have two kinds of dir-842, they store art in different partition

I think I answered my own question in this thread: Support for D-Link DIR842 (Rev C3)

The version I have seems to load boarddata from the firmware image provided by dlink, not from the art partition. I've got mine mostly working by commenting out the caldata_extract line for this model in /etc/hotplug.d/firmware/11-ath10k-caldata and copying boardData_2_0_QCA9888_5G_Y9582.bin from the vendor firmware to /lib/firmware/ath10k/pre-cal-pci-0000:00:00.0.bin

I spent about 20 minutes reverse engineering qca_ol.ko, but didn't make it far enough to understand what the offset in the structure was for the ID it was mapping in ol_ath_softc_net80211 (this changes based on various compile time flags). Someone who is more familiar with qsdk could probably figure out the image selection fairly quickly.

I'm also not sure what the stance is from openwrt of including boarddata from the vendor directly in the openwrt source tree and what the copyright implications are.

Do you have a ttl adapter to do a cat /proc/mtd ?

I am interested in what the partition layout are, it seems like the partition layout is different

If I understand correctly boardData_2_0_QCA9888_5G_Y9582.bin is different from the calibration data.

boardData_2_0_QCA9888_5G_Y9582.bin is a board file while the data in art partition is the calibration data.

I suspect that the DIR842 you got stores the calibration file in other location (or the partition layout is different)

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