D-Link DIR-2150 A1 support

I have a file here made a while ago
http://luckys.onmypc.net/openwrt/DIR-2150/DIR-2150A1_V106B01_unencrypted.bin
can't remember if I got feed back it if it worked but I often don't

something you can try I believe the V23 DIR-3060-A1 or V22 DIR-1960-A1
never got that last update removing the wan from the switch
I don't expect the leds or radio to just work but just to test you wan port speed
you should be able to just sysupgrade with the override option when you get openwrt back on in

I have a file here made a while ago

Yep - that's exactly this file (I've preserved the name to make it obvious) - I believe there is pretty much no other accessible software for this router except your directory with the compiled openwrt & unencrypted.bin - so really big thanks for all the great work you are doing here.

ATM I'm also trying to adapt some .c code for uploading firmware directly instead of using 'curl' - but I doubt there will be much progress - as it's really unclear why the recovery u-boot simply stops without any logged reasing (i.e. I'm trying to add some 'delays' in the uploading - whether it's too fast ??)

Would be probably interesting to see timed Wireshark eth0 traffic captrure from the successful firmware recovery - to see what is going wrong - as all I can see is 14MiB is successfully uploaded to the router - then router emits HTTP response and 'hangs' - so maybe it needs to be still connected while upgrading ?? - so far I'm kind of clueless what all can go wrong ?

BTW - is there any change to 'replace' u-boot with some newer version - or is this badly coded u-boot somehow tied to the router ? (my stick on the router's bottom sais it's version 1.01)

Later today I'll try to upload 3060 - to see what happens - certaily with serial line its quite 'recoverable' - although now it looks like only back to openwrt :wink:

Maybe someone can post original 'kernel' mtd5 for restore from 2150 ?

it seems to be the linux tcpip stack that's the problem
as firefox works on windows but the same one compiled for linux wont
as a side note
based in the difference I have observed between the DIR-878-A1 and the DIR-878-R1
the R1 has the basic default u-boot media tech header and seems to just work
I remember I did tests noted that it worked "R1 emergency interface"
where the A1 didn't "recovery interface"

so maybe when they change the u-boot header & load location they broke it
but they interface in the R1 is so much better maybe they fixed it

sorry it's not clear if that unencrypted.bin worked and returned you back to the dlink firmware ?
if not I'll remove it

So I've some updates -

The most impressive part is - I"m actually able to easily 'upload' Dir-882 Oficial firmware to this Dir-2150 router via 'recovery boot' - so really nothing wrong with Linux tcpip - the image is easily accepted/uploaded via 'curl' - and serial line showed nice flashing log.

After the flashing - it boots - and it even works! - however only 2.4G radio works - 5G emits kernel log errors. So surprise to me :wink: - altough the GUI then does NOT allow to flash 2150 firmware - only 882.

I've even flashed 2660 firmware loaded from your ftp directory published in 2660 thread - this was also accepted & flashed via 'curl' - however the booting process at some point ends with kernel error:

Switching to clocksource Ralink Systick timer
NET: Registered protocol family 2
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP: reno registered
UDP hash table entries: 256 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
NET: Registered protocol family 1
BUG: Bad page state in process swapper/0  pfn:0a875
page:82869ea0 count:-1912406016 mapcount:0 mapping:8f848030 index:0x0
page flags: 0x0()
Modules linked in:
CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.10.14+ #19
Stack : 82647db2 00000036 00000000 81750000 00000000 00000000 00000000 00000000
	  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
	  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
	  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
	  00000000 00000000 00000000 00000000 00000000 00000000 00000000 8fc3b880
	  ...
Call Trace:[<8100acfc>] 0x8100acfc
[<8100acfc>] 0x8100acfc
[<8108e458>] 0x8108e458
[<8108ea94>] 0x8108ea94
[<81005a4c>] 0x81005a4c
[<8108ec6c>] 0x8108ec6c

So this kernel is not usable.

It looks like the problem is the construction of the flashable/rescueable image for 2150 router.
None of images downloaded either from oficial DLink site or your build works ATM to me.
But yours image gives the biggest 'progress' - not sure what is validated and is missing - but 882 image (DIR-882_REVA_FIRMWARE_v1.10B02.zip) has it - as well as 2660 image.

Even when I try to use 'tftp' boot over serial line and I 'try' to flash those 2150 images - it's flashing - but then during boot I can see this:


=================================================
Check image validation:hdr1_addr[bc180000]hdr2_addr[c0980000]
Image1 Header Magic Number --> Failed
Image2 Header Magic Number --> OK
Image2 Header Checksum --> OK
Image2 Data Checksum --> ...........................................................................................................................................................................................................OK
Image1 Stable Flag --> Not stable
Image1 Try Counter --> 1
Image1: Broken Image2: OK
Image1 is borken. Copy Image2 to Image1

Copy Image:
Image2(0x4980000) to Image1(0x180000), size=0xCA696E
.........................................................................................................................................................................................................
..ranand_erase: start:180000, len:20000 
..ranand_erase: start:1a0000, len:20000 
..ranand_erase: start:1c0000, len:20000 
..ranand_erase: start:1e0000, len:20000 

So it fallback to the workable image - which was 882 at this time.

As for 100Mbps - it seems also 882 firmware reported this speed for WAN port - so I'm getting impression the maybe soldering serial line pins possible cause some 'heat' damage as it's quite close to WAN ?? - so it always negotiate to 100Mbps - such hw failure looks possible to me - although before openwrt experimenting the router was routing 500Mbps -so WAN ported worked.

But there is 'usable workaround' when configured/switched WAN ports as lan1 via Luci - router then operates in full speed with openwrt (and I want to use it as a cheap mesh extender anyway)

So I've now flashed back OpenWrt Dir-2150 firmware and I'm doing some experiments with this.

Forget to mention - all OpenWrt firmwares for 3060, 2660, 1960 sysupgraded and booted and also worked - except for 5Ghz network - but I've not spent too much time with them looking for problem :slight_smile: - so IMHO I could imagine some 'universal' firmware for such router families - which would then only load specific firmwares for radio drivers.

1st thing is the DIR-882-A1 is the wrong flash type I'm surprised it booted
the DIR-1960-A1 is the same PCB as the DIR-882-A1 but different flash type loaded
oh and double the ram may differing usb ports loaded also
what else is weird is the versions above 1.04 for the DIR-882-A1 are encrypted from dlink ?

the difference in the nor and nand flash versions is the big chunk of FF's between the large flash pages
so sounds like the it having problems there
if this is true the initramfs upload should work also
https://downloads.openwrt.org/releases/23.05.2/targets/ramips/mt7621/openwrt-23.05.2-ramips-mt7621-dlink_dir-1960-a1-initramfs-kernel.bin
maybe somehow you have erased it's identity as a dir-2150-a1 Header Magic Number --> Failed

yes you loaded the openwrt dir-3060 but what speed was the wan port ?
v22 dir-1960-a1 would also have the same efect

1st thing is the DIR-882-A1 is the wrong flash type I'm surprised it booted
else is weird is the versions above 1.04 for the DIR-882-A1 are encrypted from dlink ?

Actually correct - this .zip file contains 2 images:
DIR882A1_FW104B02_Middle_FW_Unencrypt.bin
DIR882A1_FW110B02.bin

And I've used 1.04 version.

In all versions I've flashed&tested (openwrt/dlink) it's been always negotiating 100Mbps for the wan port (so all firmwares 1960, 2660,3060,882)

The only thing which is still impossible is to flash back firmware for 2150 :slight_smile:
More experiments could happen during the night time .

Maybe you could know how to take 882 1.04 image and replace internal chunks with 2150 parts and put the image back ?

It looks like the firmare image for 2660 created by you had no problems - so I guess it should be somehow possible ?

Also looking at RAM sizes of my Dir-882 / Dir-2150 - looks the same

So the main problem (at least for my 'couple minute glance' ) was the missing 5G radio - but on the other hand - with this firmware user gets 'range extender' in Dlink firmware - which is otherwise missing in 2150 cutted variant....

root@Dir-882:~# uname -a
Linux Dir-882 5.15.147 #0 SMP Sat Jan 27 09:30:47 2024 mips GNU/Linux

root@Dir-882:~# cat /proc/meminfo 
MemTotal:         119880 kB
root@Dir-2150:~# uname -a
Linux Dir-2150 5.15.134 #0 SMP Mon Oct 9 21:45:35 2023 mips GNU/Linux

root@Dir-2150:~# cat /proc/meminfo 
MemTotal:         120528 kB

I have manually changed the header on for this file
http://luckys.onmypc.net/openwrt/DIR-2150/DIR-2150A1_V106B01_unencrypted%20with%20882%20header.bin

it has got an odd header as it had the model number where the linux edition should be

it's weird as the FCC image has no ram chip
https://fccid.io/KA2DIR2150A1/Internal-Photos/Internal-Photos-4800721.iframe
https://fccid.io/KA2IR878A1/Internal-Photos/Internal-Photos-3348851

Ok - so the positive part is - I've been now able to restore device back to original DLink firmware with your lastest '...header.bin' image.

However - it's been impossible to upload the firmware via Dlink recovery boot - freezed on the same place. But I was able to upload this firmware back via tftp upload using serial line - great victory :slight_smile:

After this tftp upload - it also looked like all the entered data have simply dissapeared whenever the router was switched off - maybe these errors could be corresponding ?

[   19.280000] jffs2: compression type 0x06 not available
[   19.288000] jffs2: Error: jffs2_decompress returned -5

Also some 'historical' luci GUI reminders showed up strangly when accessing dlink page after reboot...

Anyway after GUI flashing again with downloaded DIR-2150A1_V106B01.bin (md5sum b9d15c904877815101e188f36e17c6ca) router starts to remember all passwords and settings agains.

Unfortunatelly WAN remains limited to 100Mbps - so likely some damage must have happened during serial pin soldering - unsure which kind thought - but maybe heat so close to WAN port could be somehow problematic.

However all Lan ports are still full 1Gbps - so no big deal for me (and for it's price... :wink:
And yes - it routes nicely via WiFi Mesh - although I now want to recheck whether DAWN or usteer will give some better numbers and functionality - although there is not much benchmarking available for this....

I guess if user wants to go now to OpenWrt - he can flash 1.04 882 firmware via 'recovery' - then he can apply 'telnet' hack - and then upload and mtd write openwrt to this router - kind of ugly - but workable solution.

Wondering what is still wrong with this recovery uboot and current images - I can probably upload full screen -L log from console if it would help to anyting?

I think at some point you have erased something important
just running firmware with a differing memory format "nor not nand"
you may have erase some important regional & or factory type data
if you have made backups it's time to find out what changed
and start returning memory back to what it originally was

I don't think there was anything wrong with the device when I've flashed the firmware again from the DLink's GUI - from that moment it looked like it has worked normally AFAIK - except for the faulty WAN port speed - but all the WiFi & lan - all was fine - no errors in the logs.

It's just that 'tftp' flash likely has not 'restored' content of all the partitions - but it seems like after

But let's just dive deeply into what happens during 'tftp' flash of your new '...header.bin' image:

2: System Load Linux Kernel then write to Flash via TFTP. 
 Warning!! Erase Linux in Flash then burn new one. Are you sure?(Y/N)
 Please Input new ones /or Ctrl-C to discard
      Input device IP (192.168.0.1) ==:192.168.0.1
      Input server IP (192.168.0.101) ==:192.168.0.101
      Input Linux Kernel filename (dir.bin) ==:dir.bin

 NetLoop,call eth_halt ! 

 NetLoop,call eth_init ! 
Trying Eth0 (10/100-M)

 Waitting for RX_DMA_BUSY status Start... done


 ETH_STATE_ACTIVE!! 
TFTP from server 192.168.0.101; our IP address is 192.168.0.1
Filename 'dir.bin'.

TIMEOUT_COUNT=10,Load address: 0x84000000
Loading: checksum bad
checksum bad
Got ARP REPLY, set server/gtwy eth addr (00:1c:25:14:4a:e2)
Got it
#################################################################
...
       ###################################
done
Bytes transferred = 14155780 (d80004 hex)
LoadAddr=84000000 NetBootFileXferSize= 00d80004
ranand_erase: start:180000, len:20000 
..ranand_erase: start:1a0000, len:20000 
...
..ranand_erase: start:ee0000, len:20000 
....ranand_erase: start:f00000, len:20000 
.(5192)offs=15728640 piece=0 piece_size=4 rc=0
Done!

So IMHO in this log - during tftp flash - the bad check check right in the front seems to be a sign there is still something not OK although unclear what it could be - as download seems to be signaled later on with '#' chars.

I'll probably attach more traces with 2660 & 882 images to compare the behaviour.

Now when this image boots:

3: System Boot system code via Flash.
## Booting image at bc180000 ...
   Image Name:   DIR-2150
   Image Type:   MIPS Linux Kernel Image (lzma compressed)
   Data Size:    3180436 Bytes =  3 MB
   Load Address: 81001000
   Entry Point:  81001000
.................................................   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
No initrd
## Transferring control to Linux (at address 81001000) ...
## Giving linux memsize in MB, 128

Now comes the problematic part I guess with this firmware image:

[    2.200000] Scanning device for bad blocks
[    2.344000] Signature matched and data read!
[    2.352000] load_fact_bbt success 1023
[    2.360000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
[    2.380000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
[    2.400000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
[    2.420000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
[    2.440000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
[    2.460000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
[    2.480000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
[    2.500000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
[    2.520000] Creating 11 MTD partitions on "MT7621-NAND":
[    2.528000] 0x000000000000-0x000007f80000 : "ALL"
[    2.572000] 0x000000000000-0x000000080000 : "Bootloader"
[    2.584000] 0x000000080000-0x000000100000 : "Config"
[    2.596000] 0x000000100000-0x000000140000 : "Factory"
[    2.604000] 0x000000140000-0x000000180000 : "Config2"
[    2.616000] 0x000000180000-0x000001f80000 : "firmware"
[    2.640000] 0x000000488834-0x000001f80000 : "rootfs"
[    2.648000] mtd: partition "rootfs" must either start or end on erase block boundary or be smaller than an erase block -- forcing read-only
[    2.680000] 0x000001f80000-0x000002980000 : "rootfs_data"
[    2.696000] 0x000002980000-0x000004980000 : "Private"
[    2.716000] 0x000004980000-0x000007180000 : "firmware2"
[    2.736000] 0x000007180000-0x000007780000 : "mydlink"
[    2.748000] 0x000007780000-0x000008080000 : "Reserved"
[    2.760000] mtd: partition "Reserved" extends beyond the end of device "MT7621-NAND" -- size truncated to 0x800000
[    2.784000] [mtk_nand] probe successfully!
[    2.792000] rootfs = 488834 to 1f80000
[    2.812000] IMQ driver loaded successfully. (numdevs = 16, numqueues = 1)

rootfs looks like totally misplaced ???

this then results into this weird error

[system]: fota_config init
init_fota: Fota time is not set, generate random time 3:38.
[system]: /usr/sbin/fotaCheck.sh start_timer
[system]: /etc/init.d/cron restart
[   19.280000] jffs2: compression type 0x06 not available
[   19.288000] jffs2: Error: jffs2_decompress returned -5
[   19.300000] jffs2: compression type 0x06 not available
[   19.312000] jffs2: Error: jffs2_decompress returned -5
[   19.324000] jffs2: compression type 0x06 not available
[   19.332000] jffs2: Error: jffs2_decompress returned -5
[   19.344000] jffs2: compression type 0x06 not available
[   19.352000] jffs2: Error: jffs2_decompress returned -5
certificate req or private key is not exist
wizard_flag:24601
EU countrycode default wizard_flag should be 9430
enter_parent_rule_add

followed with this bunch of errors - causing likely inability to rememeber any presets:

[   66.080000] 
[   66.160000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000000: 0x4255 instead
[   66.180000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000004: 0x0001 instead
[   66.196000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000018: 0x2465 instead
[   66.216000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000003c: 0xd309 instead
start get online fw version
Thu Apr 6 16:24:31 UTC 2023
[   66.312000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020000: 0x4255 instead
[   66.332000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020004: 0x0001 instead
[   66.352000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020018: 0x2465 instead
[   66.372000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0002003c: 0xd309 instead
[   66.468000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00040000: 0x4255 instead
[   66.496000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00040004: 0x0001 instead
[   66.512000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00040018: 0x2465 instead
...

Then lets flash again from within Dlink official firmware and we get this fancy log:

heck image validation:hdr1_addr[bc180000]hdr2_addr[c0980000]
Image1 Header Magic Number --> OK
Image2 Header Magic Number --> OK
Image1 Header Checksum --> OK
Image2 Header Checksum --> OK
Image1 Data Checksum --> .................................................OK
..Erasing NAND Flash...
ranand_erase: start:80000, len:20000 
.Writing to NAND Flash...
done
Image2 Data Checksum --> .................................................OK
Image1 Stable Flag --> Stable
Image1 Try Counter --> 1

Image1: OK Image2: OK

we still get weird tables:

[    2.184000] Scanning device for bad blocks
[    2.328000] Signature matched and data read!
[    2.336000] load_fact_bbt success 1023
[    2.344000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
[    2.364000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
[    2.384000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
[    2.404000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
[    2.424000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
[    2.444000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
[    2.464000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
[    2.484000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
[    2.504000] Creating 11 MTD partitions on "MT7621-NAND":
[    2.512000] 0x000000000000-0x000007f80000 : "ALL"
[    2.556000] 0x000000000000-0x000000080000 : "Bootloader"
[    2.568000] 0x000000080000-0x000000100000 : "Config"
[    2.580000] 0x000000100000-0x000000140000 : "Factory"
[    2.588000] 0x000000140000-0x000000180000 : "Config2"
[    2.600000] 0x000000180000-0x000001f80000 : "firmware"
[    2.624000] 0x000000488834-0x000001f80000 : "rootfs"
[    2.632000] mtd: partition "rootfs" must either start or end on erase block boundary or be smaller than an erase block -- forcing read-only
[    2.668000] 0x000001f80000-0x000002980000 : "rootfs_data"
[    2.680000] 0x000002980000-0x000004980000 : "Private"
[    2.700000] 0x000004980000-0x000007180000 : "firmware2"
[    2.720000] 0x000007180000-0x000007780000 : "mydlink"
[    2.732000] 0x000007780000-0x000008080000 : "Reserved"
[    2.744000] mtd: partition "Reserved" extends beyond the end of device "MT7621-NAND" -- size truncated to 0x800000
[    2.768000] [mtk_nand] probe successfully!
[    2.776000] rootfs = 488834 to 1f80000
[    2.796000] IMQ driver loaded successfully. (numdevs = 16, numqueues = 1)
[    2.808000]  Hooking IMQ after NAT on PREROUTING.

But then jffs looks promising:

[   18.144000] jffs2: notice: (1677) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
[   18.252000] jffs2: Empty flash at 0x00049254 ends at 0x00049800
[   18.372000] jffs2: notice: (1677) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
version_old=[3.6.10-b04
], version_new=[3.6.10-b04
]
flag=0, len of config2_base64date is 2336!
/mydlink/cert/client.crt.key is ok!
flag=1, len of config2_base64date is 1752!
/mydlink/cert/client.crt.pem is ok!
load_wifi_skutable(79): Country24g=EU
load_wifi_skutable(141): Country58g=EU
load_wifi_skutable(209): pMode_2g=CE,pMode_5g=CE

no more errors - everything worked fine from this moment (except for the WAN 100Mbps - which is likely now a hw damage)

Now let's move on the tftp upload of yours OpenWrt image:

TFTP from server 192.168.0.101; our IP address is 192.168.0.1
Filename 'open.bin'.

 TIMEOUT_COUNT=10,Load address: 0x84000000
Loading: checksum bad
checksum bad
checksum bad
Got ARP REPLY, set server/gtwy eth addr (00:1c:25:14:4a:e2)
Got it
#################################################################

NOTICE 3 'checksum bad' errors - so the image likely needs some different checksumming to match something I've no idea what ??
(And your '....header.bin' image showed just 2 'checksum bad' - so maybe you've fixed 1 header - and 2 more to fix in that file ?? - and 3 to fix in your openwrt build ?)

then we boot to openwrt

# Booting image at bc180000 ...
   Image Name:   MIPS OpenWrt Linux-5.15.134
   Image Type:   MIPS Linux Kernel Image (lzma compressed)
   Data Size:    2796688 Bytes =  2.7 MB
   Load Address: 80001000
   Entry Point:  80001000
...........................................   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
No initrd
## Transferring control to Linux (at address 80001000) ...
## Giving linux memsize in MB, 128

Starting kernel ...

[    0.000000] Linux version 5.15.134 (builder@buildhost) (mipsel-openwrt-linux-musl-gcc (OpenWrt GCC 12.3.0 r23497-6637af95aa) 12.3.0, GNU ld (GNU Binutils) 2.40.0) #0 SMP Mon Oct 9 21:45:35 2023
[    0.000000] SoC Type: MediaTek MT7621 ver:1 eco:3

and we can see the partition layout looks just fine for openwrt:

[    2.167317] mt7621-nand 1e003000.nand: ECC strength adjusted to 4 bits
[    2.180423] 9 fixed-partitions partitions found on MTD device mt7621-nand
[    2.195259] Creating 9 MTD partitions on "mt7621-nand":
[    2.205735] 0x000000000000-0x000000080000 : "Bootloader"
[    2.220031] 0x000000080000-0x000000100000 : "config"
[    2.233477] 0x000000100000-0x000000140000 : "factory"
[    2.246022] 0x000000140000-0x000000180000 : "config2"
[    2.258353] 0x000000180000-0x000002980000 : "firmware"
[    2.479475] 2 uimage-fw partitions found on MTD device firmware
[    2.491380] Creating 2 MTD partitions on "firmware":
[    2.501281] 0x000000000000-0x000000400000 : "kernel"
[    2.532359] 0x000000400000-0x000002800000 : "ubi"
[    2.724215] 0x000002980000-0x000004980000 : "private"
[    2.896436] 0x000004980000-0x000007180000 : "firmware2"
[    3.109525] 0x000007180000-0x000007780000 : "mydlink"
[    3.150956] 0x000007780000-0x000008000000 : "reserved"
[    3.345869] mtk_soc_eth 1e100000.ethernet: generated random MAC address 8a:63:30:17:e1:ca
[    3.363809] mt7530-mdio mdio-bus:1f: MT7530 adapts as multi-chip module
[    3.384342] mtk_soc_eth 1e100000.ethernet eth0: mediatek frame engine at 0xbe100000, irq 21
[    3.404747] mtk_soc_eth 1e100000.ethernet wan: mediatek frame engine at 0xbe100000, irq 21
[    3.423053] i2c_dev: i2c /dev entries driver

and yes the 100Mbps negotiation remains effective:

[   29.768698] mtk_soc_eth 1e100000.ethernet wan: PHY [mdio-bus:04] driver [MediaTek MT7530 PHY] (irq=POLL)
[   29.787797] mtk_soc_eth 1e100000.ethernet wan: configuring for phy/rgmii link mode
[   31.873912] mtk_soc_eth 1e100000.ethernet wan: Link is Up - 100Mbps/Full - flow control rx/tx
[   31.891006] IPv6: ADDRCONF(NETDEV_CHANGE): wan: link becomes ready
[   33.499077] mt7530-mdio mdio-bus:1f lan1: Link is Up - 1Gbps/Full - flow control rx/tx
[   33.514968] br-lan: port 1(lan1) entered blocking state
[   33.525425] br-lan: port 1(lan1) entered forwarding state
[   33.537413] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
[  364.672328] mtk_soc_eth 1e100000.ethernet wan: Link is Down
[  377.152363] mtk_soc_eth 1e100000.ethernet wan: Link is Up - 1Gbps/Full - flow control rx/tx
[  378.192299] mtk_soc_eth 1e100000.ethernet wan: Link is Down
[  379.232362] mtk_soc_eth 1e100000.ethernet wan: Link is Up - 100Mbps/Full - flow control rx/tx

Other then this - all works just fine in OpenWrt - and there is no problem to make WAN port as Lan1 - so still no problem to use this router for gigabit routing - although -1 Lan :slight_smile:

So now - can we still improve those images - so they would upload easily with 'recovery boot' ?

I can pass logs from 2660 & 882 - which are both easily accepted & flashed by 2150 recovery boot.

And final comment - I don't have backups of partitions before switch to openwrt - so I can't really compare/restore to that state - I was just about happy openwrt flash worked via tfpt :wink: and works and operates nicely as Mesh node

sounds like physical damage on your wan port
that image I got the image builder to make
it's possible the u boot check-some wasn't calculated properly
tho I think this would force it to boot off image 2
anyway a real image needs to be made & related pull request etc

you do need to backup as much as you can as early as you can
there is regional stuff like ISP profiles stored in private etc

if I erase this stuff even the dlink updates brake & the serial number for mcafee is lost etc
it only matters when you go back to dlink's software

you router is now limited to 500M max due to the lan ports being on the switch
where the wan ports has it's own Ethernet port

just now need more attention & support on https://github.com/openwrt/openwrt/pull/12624

a good thing for you and others to do would be compile openwrt with this pr & test the image it makes
and give feedback on github about it

I doubt there would be anything localized for my country :wink: within the router thus no big deal - as long as frequencies for radios are working I'm just fine - as this router 'destination' is to be a cheap 'wireless' Mesh extender (so it will not be even connected with any ethernet cable at all).

So before I'll deploy it to its final destination - I can spend few weeks testing the stuff - so if there will be any more new images to test - I can do that and provide logs - once it will be installed and deployed - the router will be 'gone' :slight_smile: - so unless I will buy another one for playing - as it's dirty cheap especially for its power - it's basically just like my 882-a1 - which costed way more money back in time - and the only difference seem to be those missing USB port. The raw CPU performance is the same and wirelless seems to be good enough for my net provided speed - and 500M is my current home limit anyway :slight_smile: but router will be installed even in the slower network environment.

1 Like

I'll just recap results on mine Dir-2150 H/W Ver A1 F/W Ver 1.01

What can be done without soldering to the device (however without them and applying these modification, there is NO way to go back to the original 2150, so just to be aware...!

So let's start with recovery images accepted by Dir-2150 recovery boot:

filename: DIR2660A1_FW104B03.bin
md5: e2cd55c3599b3d7e0f3d8b5b41eafb54
size: 17984113 bytes

Log from the recovery boot upload and flash:

checksum bad
checksum bad
checksum bad
Got ARP REQUEST, return our IP
to check image type

=================================================
Check image validation:
Image1 Header Magic Number --> OK
Image1 Header Checksum --> OK
Image1 Data Checksum --> OK

=================================================[check_img_return:0]
image is unencrypto kernel images
*********** len: 1355, s->dataSize: 1355
lost ACK
image_flg = 0, length = 17984113

=================================================

updating img...........
ranand_erase: start:180000, len:20000 
..ranand_erase: start:1a0000, len:20000 
..ranand_erase: start:1c0000, len:20000 
..ranand_erase: start:1e0000, len:20000 
..ranand_erase: start:200000, len:20000 
..ranand_erase: start:220000, len:20000 
...
..ranand_erase: start:1240000, len:20000 
..ranand_erase: start:1260000, len:20000 
..ranand_erase: start:1280000, len:20000 
....ranand_erase: start:12a0000, len:20000 
.(5192)offs=19529728 piece=0 piece_size=27249 rc=0
Done!

===================================================================
     		MT7621   stage1 code Mar 12 2015 14:42:52 (ASIC)
     		CPU=50000000 HZ BUS=16666666 HZ
==================================================================
Change MPLL source from XTAL to CR...
do MEMPLL setting..

Unfortunatelly this build does NOT run on this router as it ends with this kernel oops:

Switching to clocksource Ralink Systick timer
NET: Registered protocol family 2
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP: reno registered
UDP hash table entries: 256 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
NET: Registered protocol family 1
Unhandled kernel unaligned access[#1]:
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.10.14+ #19
task: 8fc39ad8 ti: 8fc3a000 task.ti: 8fc3a000
$ 0   : 00000000 c0a574f0 0000001f 00000007
$ 4   : 0000001d 0000000b 00000000 00000006
$ 8   : 81822dec 81822ee8 00000000 ffffff80
$12   : 8fc20000 c0a4f4f0 00000001 00000000
$16   : 00000000 8286a014 81822dec 81822dc0
$20   : 00000000 00000001 81750000 81635808
$24   : 00000000 81092f20                  
$28   : 8fc3a000 8fc3b930 82927c18 8108e988
Hi    : 00000000
Lo    : 00000010
epc   : 8108da24 0x8108da24
    Not tainted
ra    : 8108e988 0x8108e988
Status: 1100fc02	KERNEL EXL 
Cause : 40800014
BadVA : 00000021
PrId  : 0001992f (MIPS 1004Kc)
Modules linked in:
Process swapper/0 (pid: 1, threadinfo=8fc3a000, task=8fc39ad8, tls=00000000)
Stack : 8fc3b930 8fc3b930 0000003d 82640000 0000000a 81822f54 00000000 82650000
	  00000000 0000000f 000200d2 82869ff4 81822dc0 0000000b 82927c18 8108e988
	  8fc06380 8fc17400 81750000 8169d2e8 00000041 81850000 81822dc0 810bbf98
	  00000001 8175136c 82927c24 00000000 00000008 81823344 00000000 00000001
	  00000000 0000000e 00000001 00000000 82927c20 00000001 ffffffff 0000000f
	  ...
Call Trace:[<8108e988>] 0x8108e988
[<810bbf98>] 0x810bbf98
[<810d5894>] 0x810d5894
[<8108ec6c>] 0x8108ec6c
[<811e30bc>] 0x811e30bc
[<81087ac0>] 0x81087ac0
[<81087058>] 0x81087058
[<81087be8>] 0x81087be8
[<81088064>] 0x81088064
[<810e827c>] 0x810e827c
[<81087824>] 0x81087824
[<810bd360>] 0x810bd360
[<81088c34>] 0x81088c34
[<81096ae8>] 0x81096ae8
[<81088fe0>] 0x81088fe0
[<810beda4>] 0x810beda4
[<810bfab0>] 0x810bfab0
[<810bbdc4>] 0x810bbdc4
[<810bff7c>] 0x810bff7c
[<8109db64>] 0x8109db64
[<81826a40>] 0x81826a40
[<81826ddc>] 0x81826ddc
[<81825ff8>] 0x81825ff8
[<81092f20>] 0x81092f20
[<81825f08>] 0x81825f08
[<81837088>] 0x81837088
[<8183619c>] 0x8183619c
[<81825f08>] 0x81825f08
[<81825f24>] 0x81825f24
[<810bbf98>] 0x810bbf98
[<8182654c>] 0x8182654c
[<81825f08>] 0x81825f08
[<8162319c>] 0x8162319c
[<812070b4>] 0x812070b4
[<818271b8>] 0x818271b8
[<81824210>] 0x81824210
[<818271e8>] 0x818271e8
[<81206e64>] 0x81206e64
[<8184175c>] 0x8184175c
[<818271b8>] 0x818271b8
[<81001554>] 0x81001554
[<81824ab0>] 0x81824ab0
[<81824210>] 0x81824210
[<81621088>] 0x81621088
[<81621098>] 0x81621098
[<81621088>] 0x81621088
[<81005a90>] 0x81005a90


Code: 8c510000  8e220004  8e240000 <ac820004> ac440000  3c020010  24420100  ae220000  3c020020 
---[ end trace 3ecb951f82e0a15a ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

But this image is easily accepted by the plain simple 'curl' command i.e.:

curl -v -i -F "file=@DIR2660A1_FW104B03.bin" 192.168.0.1

No tricks with Firefox/Chrome/MSIE whatever needed, curl upload just works, image is accepted and flashed - works on Linux without any problems, the only mandatory part is to set Linux's ethernet address in the range 192.168.0.X (1 < X < 255) i.e.: 192.168.0.101

Next working image tested by me is:

filename: DIR882A1_FW104B02_Middle_FW_Unencrypt.bin obtained from DIR-882_REVA_FIRMWARE_v1.10B02.zip
md5: 0033169720f7b89df8d1ea90fd629913
size: 13265262

curl -v -i -F "file=@DIR882A1_FW104B02_Middle_FW_Unencrypt.bin" 192.168.0.1

log from upload and flash:

checksum bad
checksum bad
checksum bad
Got ARP REQUEST, return our IP
to check image type

=================================================
Check image validation:
Image1 Header Magic Number --> OK
Image1 Header Checksum --> OK
Image1 Data Checksum --> OK

=================================================[check_img_return:0]
image is unencrypto kernel images
*********** len: 1355, s->dataSize: 1355
lost ACK
image_flg = 0, length = 13265262

=================================================

updating img...........
ranand_erase: start:180000, len:20000 
..ranand_erase: start:1a0000, len:20000 
..ranand_erase: start:1c0000, len:20000 
..ranand_erase: start:1e0000, len:20000 
...
..ranand_erase: start:dc0000, len:20000 
..ranand_erase: start:de0000, len:20000 
..ranand_erase: start:e00000, len:20000 
....ranand_erase: start:e20000, len:20000 
.(5192)offs=14811136 piece=0 piece_size=26990 rc=0
Done!

===================================================================
     		MT7621   stage1 code Mar 12 2015 14:42:52 (ASIC)
     		CPU=50000000 HZ BUS=16666666 HZ
==================================================================
Change MPLL source from XTAL to CR...
do MEMPLL setting..
MEMPLL Config : 0x11100000
3PLL mode + External loopback
=== XTAL-40Mhz === DDR-1200Mhz ===

This image properly boots to the point the LAN interface provides working ethernet access with DHCP in the 192.168.0.X range.
However the radio/wifi chipset is different so there is no working WiFi.
The good part is the firmware constains the 'telnet bug' so from the boot one can follow this guide how to flash OpenWRT for Dir-882 - recovery-mode-dir-882 with DIR-878.py python script - just instead of 'mtd write' 882 openwrt image - use the 2150 - which can be at this moment download from Lucky's directory: Lucky Dir 2150 ATM file: [openwrt-23.05.0-b76d880406e5-ramips-mt7621-dlink_dir-1960-a1-squashfs-factory.bin]

From this moment after the reboot the user should have the fully working OpenWRT router on the Dir-2150.

Going back to the original DLink firmware ATM requires soldering serial line pins - since only TFTP can be used to upload back currently the only working and accepted firmware
DIR-2150A1_V106B01_unencrypted with 882 header.bin
This image is ATM rejected by recovery boot after it's being uploaded by curl and checked afterwards.

Although there is not much reasoning to go back :wink: as DLink's firmware is considerable less powerful - although setting Guest network and access rules are bit easier there.

Hopefully this might help some users.

for other out there please do not try to flash the DIR-882-A1 to this router
it's flash and memory layout is not the same
I believe the 1st thing these firmware's do
is look for a valid configuration and if not valid
create a factory default config erasing what ever is at the expected address
going by address this will over right the 2nd half on the boot loader
this is the last thing you want to risk if it writes due to incorrect flash type

at your 1st opportunity always backup as much flash as you can
even if it's after openwrt boots you can still get factory,configuration,boot-loader etc
you can recover if you have backups and thins goo wrong
hard if it's the boot loader but with tools you can

if lost you can never really get back your radio calibration data
with out the manufacture recreating it via another costly recalibration

Since you say there is possile some 'data loss' of some unique firmware data - I'm wondering what kind of - since I've flashed this router several times all around - speed of 5G network always easily runs ~700Mbps iperf3 - which is about the maximum my surrouding hardware can measure. So while I'm certainly not persuading anyone to use the approach via flashing mismatching firmware - unless there is any chance to 'combine' factory.bin image in a way it's accepted by the recovery boot of this version of router then a user does not have many options other then to hw modify router (possibly risking damage of the WAN port as happened in my case...).

So what kind of data and what kind of impact this can have ?
How those data would be accessed/used by openwrt firmware ?

So far I'm not seeing anything weird on the radio handling - so what else can go wrong ?
And as said, for the price of better lunch....

My primary point is however to help someone else to look at those particular firmware files and decode what those firmwares have within then so the 'recovery boot' can take and flash them - so the compiled openwrt firmware file will be easily accepted and flashed

Looking across other threads - it's pretty common problem - it may help other users to not need i.e. telnet hacks to flash 882 and likely other Dlinks as well.

If there will be firmware images to test - no problem for me for a week or two - to just take and try to flash them and see whether that can be flashed or not - ATM I'm feeling somewhat 'safe' as it seems it's very hard to brick it...

this should help in the future
the DIR-882-A1 under next release including snapshots now
you can flash via the d-link web interface same as you normal dlink update

the DIR-2150-A1 key appear to have been leek and added to the encryption library
I have requested the lines to make this work added to the current DIR-2150-A1 pull request
but it will need to be confirmed to work by someone with a device

Great - if there will be image testing I'll happily try it.

Assuming I should flash back the original Dlink firmware - and then use the GUI to upgrade firmware with openwrt factory.bin (or sysupgrade.bin) ?

And what can be still wrong with the 'recovery boot' ?
I'm looking at uboot firmware - assuming it shouldn't different to see what is code doing after accepting & checking image - but before starting to flash.

At least 'strings' from uboot seems to have lots of plain text - so assuming skilled MIPS asm reader shouldn't have problem to see what is code doing/checking for in that moment.

Also - I've looked over the boot log after flash - and these line can be seen there:

flag=0, len of config2_base64date is 2336!
/mydlink/cert/client.crt.key is ok!
flag=1, len of config2_base64date is 1752!
/mydlink/cert/client.crt.pem is ok!
load_wifi_skutable(79): Country24g=EU
load_wifi_skutable(141): Country58g=EU
load_wifi_skutable(209): pMode_2g=CE,pMode_5g=CE
[system]: cp -rf /etc/wireless/mt7603/SKU_tables_mt7603/SingleSKU_CE.dat /etc/wireless/mt7603/mt7603-sku.dat
[system]: cp -rf /etc/wireless/mt7603/SKU_tables_mt7603/SKU_CE_BF.dat /etc/wireless/mt7603/mt7603-sku-bf.dat
[system]: cp -rf /etc/wireless/mt7615/SKU_tables_mt7615/SingleSKU_CE.dat /etc/wireless/mt7615/mt7615-sku.dat
[system]: cp -rf /etc/wireless/mt7615/SKU_tables_mt7615/SKU_CE_BF.dat /etc/wireless/mt7615/mt7615-sku-bf.dat

So maybe those 'chip calibration data' are now part of normal firmware flashing ?

I test compile of current snapshot with PR for 2150 & 3040
http://luckys.onmypc.net/openwrt/2024-02-14%20Test/
Updated * wan led not auto assigned