Any plans to support this router?
It's built on the AP-MTKH7-0002 REV1.0 board
shared with the DIR-878 & DIR-882 but with 128M NAND Flash a bit like the DIR-853-A3
so it's won't be hard but someone who has one has to do it
https://github.com/garyttirn/openwrt/commit/ca95ece5f330c8e32f07009f93cf149bd77926cb
These are the changes I made for my router. credit to Lucky1 for the work he has done on the DIR-878.
This is my DTS
/dts-v1/;
#include "mt7621.dtsi"
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>
/{
compatible = "dlink,dir-853-a3", "mediatek,mt7621-soc";
model = "D-Link DIR-853 A3";
aliases {
led-boot = &led_power_amber;
led-failsafe = &led_power_amber;
led-running = &led_power_blue;
led-upgrade = &led_power_amber;
label-mac-device = &gmac0;
};
chosen {
bootargs = "console=ttyS0,57600";
};
leds {
compatible = "gpio-leds";
wlan1 {
label = "dir-853-a3:blue:wlan2g";
gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
};
wlan0 {
label = "dir-853-a3:blue:wlan5g";
gpios = <&gpio 3 GPIO_ACTIVE_LOW>;
};
led_power_amber: power{
label = "dir-853-a3:amber:power";
gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
};
led_power_blue: power2{
label = "dir-853-a3:blue:power";
gpios = <&gpio 14 GPIO_ACTIVE_LOW>;
};
net {
label = "dir-853-a3:amber:internet";
gpios = <&gpio 15 GPIO_ACTIVE_HIGH>;
};
net2 {
label = "dir-853-a3:blue:internet";
gpios = <&gpio 16 GPIO_ACTIVE_LOW>;
};
usb {
label = "dir-853-a3:blue:usb";
gpios = <&gpio 10 GPIO_ACTIVE_LOW>;
trigger-sources = <&xhci_ehci_port1>, <&ehci_port2>;
linux,default-trigger = "usbport";
};
};
keys {
compatible = "gpio-keys";
wps {
label = "wps";
gpios = <&gpio 18 GPIO_ACTIVE_LOW>;
linux,code = <KEY_WPS_BUTTON>;
};
wifi {
label = "wifi";
gpios = <&gpio 7 GPIO_ACTIVE_LOW>;
linux,code = <KEY_RFKILL>;
};
reset {
label = "reset";
gpios = <&gpio 8 GPIO_ACTIVE_LOW>;
linux,code = <KEY_RESTART>;
};
};
};
&nand {
status = "okay";
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
partition@0 {
label = "bootloader";
reg = <0x0 0x80000>;
read-only;
};
partition@80000 {
label = "config";
reg = <0x80000 0x80000>;
};
factory: partition@100000 {
label = "factory";
reg = <0x100000 0x40000>;
read-only;
};
partition@140000 {
label = "config2";
reg = <0x140000 0x40000>;
read-only;
};
partition@180000 {
compatible = "ubootpad96,uimage";
label = "firmware";
reg = <0x180000 0x2800000>;
};
partition@2980000 {
label = "private";
reg = <0x2980000 0x2000000>;
};
partition@4980000 {
label = "kernel2";
reg = <0x4980000 0x2800000>;
};
partition@7180000 {
label = "mydlink";
reg = <0x7180000 0x600000>;
};
partition@7780000 {
label = "reserved";
reg = <0x7780000 0x800000>;
};
};
};
&pcie {
status = "okay";
};
&pcie0 {
mt76@0,0 {
reg = <0x0000 0 0 0 0>;
mediatek,mtd-eeprom = <&factory 0x0>;
};
};
&gmac0 {
mtd-mac-address = <&factory 0xe000>;
};
&switch0 {
ports {
port@0 {
status = "okay";
label = "lan4";
};
port@1 {
status = "okay";
label = "lan3";
};
port@2 {
status = "okay";
label = "lan2";
};
port@3 {
status = "okay";
label = "lan1";
};
port@4 {
status = "okay";
label = "wan";
mtd-mac-address = <&factory 0xe006>;
};
};
};
&state_default {
gpio {
groups = "uart3", "jtag", "wdt";
function = "gpio";
};
};
And this is the output of a git diff
diff --git a/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c b/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c
index 525ad8218b..15cb0a4863 100644
--- a/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c
+++ b/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_uimage.c
@@ -407,6 +407,43 @@ static struct mtd_part_parser uimage_fonfxc_parser = {
.parse_fn = mtdsplit_uimage_parse_fonfxc,
};
+/**************************************************
+ * ubootpad96
+ **************************************************/
+
+#define ubootpad96_PAD_LEN 96
+
+static ssize_t uimage_find_ubootpad96(u_char *buf, size_t len, int *extralen)
+{
+ if (uimage_verify_default(buf, len, extralen) < 0)
+ return -EINVAL;
+
+ *extralen = ubootpad96_PAD_LEN;
+
+ return 0;
+}
+
+static int
+mtdsplit_uimage_parse_ubootpad96(struct mtd_info *master,
+ const struct mtd_partition **pparts,
+ struct mtd_part_parser_data *data)
+{
+ return __mtdsplit_parse_uimage(master, pparts, data,
+ uimage_find_ubootpad96);
+}
+
+static const struct of_device_id mtdsplit_uimage_ubootpad96_of_match_table[] = {
+ { .compatible = "ubootpad96,uimage" },
+ {},
+};
+
+static struct mtd_part_parser uimage_ubootpad96_parser = {
+ .owner = THIS_MODULE,
+ .name = "ubootpad96-fw",
+ .of_match_table = mtdsplit_uimage_ubootpad96_of_match_table,
+ .parse_fn = mtdsplit_uimage_parse_ubootpad96,
+};
+
/**************************************************
* OKLI (OpenWrt Kernel Loader Image)
**************************************************/
@@ -470,6 +507,7 @@ static int __init mtdsplit_uimage_init(void)
register_mtd_parser(&uimage_netgear_parser);
register_mtd_parser(&uimage_edimax_parser);
register_mtd_parser(&uimage_fonfxc_parser);
+ register_mtd_parser(&uimage_ubootpad96_parser);
register_mtd_parser(&uimage_okli_parser);
return 0;
diff --git a/target/linux/ramips/image/mt7621.mk b/target/linux/ramips/image/mt7621.mk
index c2e96160cf..68749e18a3 100644
--- a/target/linux/ramips/image/mt7621.mk
+++ b/target/linux/ramips/image/mt7621.mk
@@ -81,6 +81,11 @@ define Build/iodata-mstc-header
)
endef
+define Build/ubootpad96
+ uimage_padhdr -i $@ -o $@.new -l 96
+ mv $@.new $@
+endef
+
define Build/ubnt-erx-factory-image
if [ -e $(KDIR)/tmp/$(KERNEL_INITRAMFS_IMAGE) -a "$$(stat -c%s $@)" -lt "$(KERNEL_SIZE)" ]; then \
echo '21001:7' > $(1).compat; \
@@ -212,6 +217,26 @@ define Device/buffalo_wsr-600dhp
endef
TARGET_DEVICES += buffalo_wsr-600dhp
+define Device/dlink_dir-853-a3
+ IMAGE_SIZE := 40960k
+ UBINIZE_OPTS := -E 5
+ BLOCKSIZE := 128k
+ PAGESIZE := 2048
+ KERNEL_SIZE := 4096k
+ DEVICE_VENDOR := D-Link
+ DEVICE_MODEL := DIR-853
+ DEVICE_VARIANT := A3
+ IMAGES += factory.bin
+ KERNEL_INITRAMFS := $$(KERNEL) | ubootpad96
+ DEVICE_PACKAGES := kmod-mt7615e kmod-usb3 kmod-usb-ledtrig-usbport wpad-basic
+ IMAGE/default := append-kernel | ubootpad96 | pad-to $$$$(KERNEL_SIZE)|\
+ append-ubi
+ IMAGE/factory.bin := $$(IMAGE/default) append-rootfs | pad-rootfs |\
+ check-size
+ IMAGE/sysupgrade.bin := sysupgrade-tar | append-metadata
+endef
+TARGET_DEVICES += dlink_dir-853-a3
+
define Device/dlink_dir-860l-b1
$(Device/seama)
BLOCKSIZE := 64k
diff --git a/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds b/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
index fdfd29d011..836e2238f2 100755
--- a/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
@@ -29,6 +29,12 @@ gehua,ghl-r-001)
dlink,dir-860l-b1)
ucidef_set_led_netdev "wan" "wan" "$boardname:green:net" "wan"
;;
+dlink,dir-853-a3)
+ ucidef_set_led_netdev "wan" "wan" "$boardname:amber:internet" "wan"
+ ucidef_set_led_netdev "internet" "internet" "$boardname:blue:internet" "wan"
+ ucidef_set_led_netdev "wlan2g" "WiFi 2.4GHz" "$boardname:blue:wlan2g" "wlan0"
+ ucidef_set_led_netdev "wlan5g" "WiFi 5GHz" "$boardname:blue:wlan5g" "wlan1"
+ ;;
gnubee,gb-pc1|\
gnubee,gb-pc2)
ucidef_set_led_netdev "lan1" "lan1" "$boardname:green:lan1" "lan1"
diff --git a/target/linux/ramips/mt7621/base-files/etc/board.d/02_network b/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
index 290069f4d3..49d88141a0 100755
--- a/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
@@ -73,7 +73,8 @@ ramips_setup_macs()
wan_mac="$(grep -m1 mac= "/dev/mtd${index}" | cut -d= -f2)"
lan_mac=$wan_mac
;;
- dlink,dir-860l-b1)
+ dlink,dir-860l-b1|\
+ dlink,dir-853-a3)
lan_mac=$(mtd_get_mac_ascii factory lanmac)
wan_mac=$(mtd_get_mac_ascii factory wanmac)
;;
If anyone want to forward support for this router here is a start
this is still very beta so i recommend only those with serial access
& knowledge to use the initramfs image to backup you flash partitions first
http://luckys.onmypc.net/openwrt/DIR-1960/
Hi! I terribly miss using OpenWrt ever since I've switched to this router. I see that there is a pretty active development going on for this device and I am inclined to flash this on my device. But before that I thought I should ask the helpful folks over here how their experience has been so far. I'll be grateful if you could tell me a few things.
Can the snapshot be used as a daily driver?
Is the PPOE mode working alright?
Do any of you have the unencrypted stock firmware that you could share?
Any hiccups in the flashing process?
Any other pointers you think is relevant.
Thank you!
Can the snapshot be used as a daily driver?
that depends n the day and what you use
Is the PPOE mode working alright?
don't use can't comment
Do any of you have the unencrypted stock firmware that you could share?
http://luckys.onmypc.net/openwrt/DIR-1960/
Any hiccups in the flashing process?
other than needed the unencrypted version to return it back
maybe problems with flashing form linux but windows in Private mode is fine
Any other pointers you think is relevant.
the wifi is still not there yet it keeps getting better all the time but not there yet
works but very slow
you do get DFS channels tho
1 Like
Is there anything I can do to help with the development?
It has made it into the master branch 
you can always try the snapshots and follow up on faults you find
I think really we are waiting on the next version of openwrt 20.x.x or 21.x.x
2 Likes
Can anyone report on speed tests using the snapshot? it uses the mt76 driver for the mt7615n correct?
I have had issues with a previous MT7621/mt7615n based router and openwrt.
The old router was some cheap chinese ac1200 rebranded as a hootoo nd001.
I just dont want to have the same issues with stability as i did with the old one
Secondly, i found out that there is often a second dual core chip on the MT7621 board that is populated but not activated. more information about that can be found here Support for Strong 1200
Has anyone looked into this, its a little out of my comfort zone.
I can't speak to the DIR-1960, but the Strong 1200 was a special case. They used the dual core MT7621AT chip, but their factory boot loader only enabled a single core. Any other MT7621AT device I've seen already enables both cores by default.
There is also the single core MT7621ST chip, which uses the same boot loader code. I'm guessing it was just a miss-configuration on the part of the people who developed that Strong / HooToo / MTC router
I'll also note that a bunch of improvements in the stability of the MT7621 platform, its network switch, and the MT76 drivers has been ongoing in the master branch (eventually version 20.x or 21.x depending on when it heads to release)
Ok, I will just wait for the master to increment and include the new pulls. I hope the DIR-1960 has both CPUs enabled, if it does not we should be able to flip the bit in the bootloader in a similar fashion.
Then I guess ill update the HooToo 1200 at the same time and use it as a access-point/mesh/something.
non-representative mini/quick Wifi speedtest on DLink dir-1960 using 21.03rc3:
- Wifi 5GHz: ~425 Mbit/s (same result for WPA2 and WPA3)
- proprietary stock FW on 5GHz: ~500 MBit/s (WPA2)
(I think my test client device is 2x2 mimo)
Quite nice for a new device that is first supported on 21.02.
I remember my older Dir-860l Wifi throughput having improved over several OpenWRT release iterations, now topping the proprietary stock FW.
Also stable so far as AP and router.
1 Like
I got just stunned about the super small dir-1960 OpenWRT overlay partition of just 25 Megabyte, even though the router has actually 128 Megabyte of Flash.
root@OpenWrt:~# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 3840 3840 0 100% /rom
tmpfs 126040 1120 124920 1% /tmp
/dev/ubi0_1 25000 1612 22076 7% /overlay
overlayfs:/overlay 25000 1612 22076 7% /
tmpfs 512 0 512 0% /dev
I've then noticed the partition table mentioned earlier in this thread. I tried to put the dir-1960 vendor partition table into a more readable form:
Start Offset Size
bootloader 0 524.288
config 524.288 524.288
factory 1.048.576 262.144
config2 1.310.720 262.144
ubootpad96,uimage,firmware 1.572.864 41.943.040
private 43.515.904 33.554.432
kernel2 77.070.336 41.943.040
mydlink 119.013.376 6.291.456
reserved 125.304.832 8.388.608
133.693.440 Bytes total
What is all this? It looks like there is a second fully redundant firmware partition just like on Linksy WRT devices available and lots of other stuff? And no idea why a full 33 MB had to be spent by D'Link as "private" and another 8MB and another 6MB. Come on, D'Link, you had one job.....that's so disappointing, I came from a 16MB device and was so happy to now move to a 128MB device 
Would be interesting to move the 41+33+41+6+8 MB into a single generous large OpenWRT overlay partition (probably dropping vendor firmware fallback, but retaining the emergency room, which I think should still reside in the bootloader) or whether even an OpenWRT dual boot ability as in Linksys WRT3200/32X devices would be possible.
I do not know about dir-2640 and dir-2660, but I strongly guess they have the same weird partition scheme. The older dir-878 with its 16MB in comparison does not have that redundant partition schema.
In other words: You practically cannot use most of the Flash at this time. As of now, there is no real need to pick the newer device variants, if you can get the older dir-variants cheaper.
Hi Pico
the currently submitted partition layout is just as d-link used it & I guess all they needed
the backup firmware is just that a backup controlled by the boot loader
this will correct a corrupted openwrt kernel tho on a checksum error
but with the stock boot loader your stuck with it at lest to the size of the kernel "uboot partition size"
but for what you want I have done this & recovered a lot of space
I have only allocated unused partition space I found to be blank on my DIR-1960
but I can't say it's the same for the other models for the shared DTS
you or anyone else can take or submit this if they like
as my pull requests just seem to sit there for months & go nowhere
just a note for concat
if the last partition ends at address 0x8000000 then if fails to work
so it's a page short to avoid this
also you have to flash the factory image so UBI gets formated
as openwrt will fail if the UBI partition size changes as in a sysupgrade
// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
#include "mt7621.dtsi"
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>
/ {
aliases {
label-mac-device = &gmac0;
led-boot = &led_power_orange;
led-failsafe = &led_power_white;
led-running = &led_power_white;
led-upgrade = &led_net_orange;
};
keys {
compatible = "gpio-keys";
reset {
label = "reset";
gpios = <&gpio 15 GPIO_ACTIVE_LOW>;
linux,code = <KEY_RESTART>;
};
wps {
label = "wps";
gpios = <&gpio 18 GPIO_ACTIVE_LOW>;
linux,code = <KEY_WPS_BUTTON>;
};
};
leds: leds {
compatible = "gpio-leds";
led_power_orange: power_orange {
label = "orange:power";
gpios = <&gpio 8 GPIO_ACTIVE_LOW>;
};
led_power_white: power_white {
label = "white:power";
gpios = <&gpio 16 GPIO_ACTIVE_LOW>;
};
led_net_orange: net_orange {
label = "orange:net";
gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
};
net_white {
label = "white:net";
gpios = <&gpio 3 GPIO_ACTIVE_LOW>;
};
};
ubi-concat {
compatible = "mtd-concat";
devices = <&ubiconcat0 &ubiconcat1 &ubiconcat2>;
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
partition@0 {
label = "ubi";
reg = <0x0 0x7080000>;
};
};
};
};
&nand {
status = "okay";
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
partition@0 {
label = "Bootloader";
reg = <0x0 0x80000>;
read-only;
};
partition@80000 {
label = "config";
reg = <0x80000 0x80000>;
read-only;
};
factory: partition@100000 {
label = "factory";
reg = <0x100000 0x40000>;
read-only;
};
partition@140000 {
label = "config2";
reg = <0x140000 0x40000>;
read-only;
};
partition@180000 {
label = "kernel";
compatible = "openwrt,uimage", "denx,uimage";
openwrt,padding = <96>;
reg = <0x180000 0x400000>;
};
ubiconcat0: partition@580000 {
label = "ubiconcat0";
reg = <0x580000 0x4400000>;
};
partition@4980000 {
label = "kernel2";
reg = <0x4980000 0x400000>;
};
ubiconcat1: partition@4D80000 {
label = "ubiconcat1";
reg = <0x4D80000 0x2400000>;
};
partition@7180000 {
label = "mydlink";
reg = <0x7180000 0x600000>;
read-only;
};
ubiconcat2: partition@7780000 {
label = "ubiconcat2";
reg = <0x7780000 0x860000>;
};
};
};
&pcie {
status = "okay";
};
&pcie0 {
wifi0: wifi@0,0 {
compatible = "mediatek,mt76";
reg = <0x0000 0 0 0 0>;
mediatek,mtd-eeprom = <&factory 0x0000>;
ieee80211-freq-limit = <2400000 2500000>;
led {
led-active-low;
};
};
};
&pcie1 {
wifi1: wifi@0,0 {
compatible = "mediatek,mt76";
reg = <0x0000 0 0 0 0>;
mediatek,mtd-eeprom = <&factory 0x8000>;
ieee80211-freq-limit = <5000000 6000000>;
led {
led-active-low;
};
};
};
&gmac0 {
mtd-mac-address = <&factory 0xe000>;
};
&switch0 {
ports {
port@0 {
status = "okay";
label = "lan4";
};
port@1 {
status = "okay";
label = "lan3";
};
port@2 {
status = "okay";
label = "lan2";
};
port@3 {
status = "okay";
label = "lan1";
};
port@4 {
status = "okay";
label = "wan";
mtd-mac-address = <&factory 0xe006>;
};
};
};
&state_default {
gpio {
groups = "i2c", "uart3", "jtag", "wdt";
function = "gpio";
};
};
I see. Thanks.
I also found DLink DIR-853 A3 - #74 by kar200, which gives some insight in how the dlink-dual-firmware-partitions work:
So it is not like Linksys WRT, instead the bootloader will manage both partitions fully on its own, the user cannot interfer and unlike Linksys the user cannot have 2 different firmware versions deployed at the same time or alternate at will between them:
- On every device boot, before loading the firmware, the boot loader automatically does some sanity checksum tests on both firmware partitions. If one partitions turns out defective, it will automatically be overwritten with the stuff from the other partition
- If both partitions are sane, but differ in content, the image from the first partition gets automatically copied over to the second partition, such that the backup partition is in sync with firmware updates
- then the regular boot process continues (always on the first firmware partition)
So the 2nd firmware partition cannot be reclaimed, but has some good purpose, it's not a complete waste.
Now I also seem to understand why some users report about failed flash processes, but still that router was able to boot back into the previous image. And probably I also understand, why this auto recovery did not work for some users, as the 853-thread mentions that the checksum test is not an indepth know-it-all check.
Unfortunately compiling or changing code of OpenWRT feels way beyond my current brain evolution level. As of now, I am glad to at least be somehow able, to keep up with how OpenWRT works and how new devices fit in. And it's the first time, I deal with an owned device that does not have a device page yet.
But still regarding 1960-partitions, does that mean:
- the firmware partitions have to retain in offset and size as predefined by D-Link? (as otherwise the boot loader would not be able to do its sanity magic anymore or break something?)
- if the space of several extra partitions in between is reclaimed as you suggest, how would those extra partition spaces be used by OpenWRT? Would these then become extra mount points?
if you look at the DTSI file I sent you
it has reclaimed some of space from the backup copy
is only copys the partition size stated in the uboot header
this is the kernel only in openwrt
so separation the kernel allocation allows the other room to be reallocated
& as the UBI has checking for NAND you don't need to back this up ether
you do have to work withing the constrains of the boot loader
so the start of the kernel & it's backup are fixed
and you will only be able to make an image as big as the boot loader can work with
but at lest the extra room can be available after the flashed image use just not for an all inclusive image file
the concat just gabs all the allocated areas & pools then into one new UBI partition
witch is the size of all of them combined
they are all concatenated together into one
@Lucky1 I wonder if there is a way to get this implemented with devices that are already using openwrt (change the layout through a sysupgrade).
The other inconvenience with Openwrt is that the kernel alone is not enough to recover from the other partition. so for example if you erase the main partition uboot will only recover the kernel part and would not be able to boot (or even use the rescue mode with the reset button while it boots openwrt). I think it needs rootfs as well otherwise there is a kernel panic IIRC and bootloop after that.
We need to retain the locations of both firmware as they get checked and overwritten. At the moment we are using a kernel size of 4mb so anything after that can be used and what @Lucky1 did is very useful as it uses nearly all the other unused partitions which in openwrt are seen as a single partition.
I'm not sure how it all works in the background
but if the size of the UBI partition is different
then maybe you just can't keeps settings
but would sill let you update & start of with factory default
I do think there is work need there
maybe even if it failes 10 times then it factory defaults
so it would at lest boot
or at lest able to enter a recover of sorts
Hello,
I've just installed OpenWRT of my DIR-1960. This is my first ever encounter with OpenWRT. I don't know the correct terminology yet, so forgive me for that.
I've configured the router, and I like the experience very much. But I struggle with the free space for packages (overlay partition?) you discussed above. I don't understand much of what you've said above about the DTSI file, but I assume this is used during the image build and cannot be configured during runtime?
My question is - Is there a way to get some of the unused storage for OpenWRT? Even if I have to reinstall the OpenWRT.
I need just a few MBs. I want to run the SMB share and the DLNA server, but they don't seem to fit the partition as currently I have 8 MB free after setting up the SMB and the DLNA requires 9,5 MB. I am afraid To run the installation because I don't know what will happen after the space on the partition depletes.
I tried to find some packages that I could (and am willing to) remove, but I found only the PPPoE, which should be only around 200 kB which is not enough.
Thanks for any advice!