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
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
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
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:
(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.
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:
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:
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!
I Have a verson I compiled from the Master branch on 2021-12-22
this used what I found to be unused space on my DIR 1960
but make sure you backup all of your MTD partations just in case from you current install
& due to flash layout change you have to flash with the factory image
http://luckys.onmypc.net:81/openwrt/2021-12-22/targets/ramips/mt7621/openwrt-snapshot-r18012+384-9f90a89655-ramips-mt7621-dlink_dir-1960-a1-squashfs-factory.bin
Thanks a lot, @Lucky1! I downloaded the file. I am still a little bit conscious about this flashing procedure, but I guess I will give it a try if I don't find a way to save some space within the current install.
I have just a few more questions:
Once again, thanks a lot!
It changes what Openwrt's layout is so sysupgrade won't work it will just crash
& you have to flash with a factory file from the recovery interface this erases UBI
the partitions I have added to the available room where it's not used by my DIR-1960
you can go back to the dlink firmware yes
but just in case backup your MTD partitions so you can restore them later if needed
If you change back to default openwrt you will need to use it's factory image
no pull request
it's mixed up in the other models that share it's DTS
and due to the fact that openwrt crashes if the layup changes via sysupgrade
makes it complicated
you can make a Pull request if you like 