Porting to DIR 815 B1


I would like to port OpenWrt to my D-Link DIR 815 Rev B1 router. It's specs (http://en.techinfodepot.shoutwiki.com/wiki/D-Link_DIR-815_rev_B1) are very similar to DIR 620 D1 (http://en.techinfodepot.shoutwiki.com/wiki/D-Link_DIR-620_rev_D1) which is already supported. I am fairly comfortable with embedded development but have only worked with OpenWrt as a user so far. Is flashing the DIR-620 image to DIR-815 and then working through any hardware issues that arise a viable approach?


No, it's not and pretty much guaranteed to brick the device for good. You need serial console access and start around with first documenting the OEM firmware (flash partitioning, GPIO assignments, etc.) and then carefully writing a DTS/ device recipe and testing initramfs images.

Thank you for the reply. I have serial access to the device. Are there any guides on writing the DTS profile and testing initramfs images? I can try reading source for the former but have no clue about the latter.

I am trying to collect MTD layout information but the stock OEM environment on the router is extremely limited, e.g., the mtd command referenced in the documentation is not available. I can see the various MTD blocks in /dev/mtd but i haven't been able to find any information on how to get their offsets in flash. The boot messages are also not very enlightening in this respect. I'm to the point of simply trying to dump flash and then using binwalk to figure out what its layout is. But even this is nontrivial since there are no utilities for transferring data from the device. I found a way to transfer files to the router but my attempts to get netcat running on the router have come up short so far. I have also tried to reconfigure httpd to give read access to the entire filesystem but the installed httpd.conf does not follow Apache syntax... Are there any known tricks for adding new binaries to stock OEM environment or another way of inferring the MTD layout?

According to your links:
Flash Size 8 MiB
RAM Size 32 MiB

I think the effort is not worth it.
If you start porting it now, the next release window will be with 23.xx.
And it is not even guaranteed, whether 22.03 will work without issues on 32MB RAM.

I think that depends on what you intend to do with the hardware. I have a router with much less RAM than that running OpenWrt, working perfectly as an AP for isolating IoT devices; which i wouldn't have been able to do with stock firmware. In addition i managed to keep it out of a waste dump somewhere and saved (a little) money in the process. I also get great satisfaction from exercising full ownership over devices the manufacturers "crippled" for business reasons. Anyway, there are many good reasons for me to push this through.

Seems to follow the common DLink layout: UBoot at 0-30000, UBoot-env 30000-40000, Factory 40000-50000, Firmware 50000-end.

$ binwalk flash.bin 

0             0x0             uImage header, header size: 64 bytes, header CRC: 0x14C106AB, created: 2011-08-30 03:06:28, image size: 137172 bytes, Data Address: 0x80200000, Entry Point: 0x80200000, data CRC: 0x6D684DFC, OS: Linux, CPU: MIPS, image type: Standalone Program, compression type: none, image name: "SPI Flash Image"
107184        0x1A2B0         U-Boot version string, "U-Boot 1.1.3 (Aug 30 2011 - 11:06:24) (ALPHA)"
107808        0x1A520         CRC32 polynomial table, little endian
123984        0x1E450         HTML document header
124339        0x1E5B3         HTML document footer
124348        0x1E5BC         HTML document header
124540        0x1E67C         HTML document footer
124708        0x1E724         HTML document header
125401        0x1E9D9         HTML document footer
262160        0x40010         gzip compressed data, maximum compression, from Unix, last modified: 1999-12-31 16:17:22
327680        0x50000         SEAMA firmware header, big endian, meta size: 36, image size: 4603936
327712        0x50020         Unix path: /dev/mtdblock/2
327744        0x50040         LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: 3805904 bytes
1638464       0x190040        PackImg section delimiter tag, little endian size: 4207104 bytes; big endian size: 3293184 bytes
1638496       0x190060        Squashfs filesystem, little endian, version 4.0, compression:lzma, size: 3289945

Flash Macronix MX25L6406E (https://www.macronix.com/Lists/Datasheet/Attachments/8630/MX25L6406E,%203V,%2064Mb,%20v1.9.pdf)
nearly identical to MX25L6405D (https://www.mxic.com.tw/Lists/Datasheet/Attachments/8570/MX25L6405D,%203V,%2064Mb,%20v1.5.pdf)
used by DIR 620 already supported by OpenWrt.

I got the initramfs kernel to boot but i'm getting the following error

[   16.207657] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 3352, rev 0200 detected
[   16.223083] ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 000c detected
[   16.236762] ------------[ cut here ]------------
[   16.245980] WARNING: CPU: 0 PID: 480 at backports-5.10.110-1/drivers/net/wireless/ralink/rt2x00/rt2800lib.c:394 0x81e6299c [rt2800lib@(ptrval)+0x18eb0]
[   16.272851] phy0: invalid access of EEPROM word 39
[   16.282357] Modules linked in: rt2800soc(+) rt2800mmio rt2800lib pppoe ppp_async iptable_nat xt_state xt_nat xt_conntrack xt_REDIRECT xt_MASQUERADE xt_FLOWOFFLOAD rt
2x00soc rt2x00mmio rt2x00lib pppox ppp_generic nf_nat nf_flow_table_hw nf_flow_table nf_conntrack mac80211 ipt_REJECT cfg80211 xt_time xt_tcpudp xt_multiport xt_mark xt
_mac xt_limit xt_comment xt_TCPMSS xt_LOG slhc nf_reject_ipv4 nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_filter ip_tables crc_ccitt compat nf_log_
ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 leds_gpio gpio_button_hotplug
[   16.391380] CPU: 0 PID: 480 Comm: kmodloader Not tainted 5.4.188 #0
[   16.403817] Stack : 803bd9f4 803bd9d4 803bcffc 81f3ba4c 00000000 00000000 00000000 00000000
[   16.420398]         00000000 00000000 00000000 00000000 00000000 00000001 81f3ba00 fa654b4b
[   16.436971]         81f3ba98 00000000 00000000 00000076 00000038 80364944 20646574 2e342e35
[   16.453548]         6d6d6f43 02a4b070 a0000000 6d6b203a 80000000 00000000 00000009 00000009
[   16.470125]         81e7642c 00000004 807b0000 81e7e2ec 00000002 801cd4e4 00000000 80780000
[   16.486702]         ...
[   16.491572] Call Trace:
[   16.491641] [<80364944>] 0x80364944
[   16.503458] [<801cd4e4>] 0x801cd4e4

Do you have any suggestions for debugging this? I've tried googling and some source code browsing but so far have not been able to figure out what's going on.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.