Flash OpenWrt into D-Link DWR-M921 (Realtek Chip)

Hello everyone. I know there is no official support for DWR-M921 but I need to install openwrt on it. What I have done so far is that I have been able to build the openwrt image using this source https://github.com/cgoder/openwrt_rtk/tree/master/rtk_openwrt_sdk but I am unable to flash the router with the image.

Just for reference (from the datasheet ftp://ftp.d-link.co.za/DWR/dwrm921/datasheet/D-Link-DWR-M921_Datasheet-C03.pdf)

Chipset RLT8197FN
CPU frequency 800MHz
Memory 64MB 16-bit DDR2 SDRAM
Flash 8MB

As you already noticed yourself, DWR-M921 is not supported by OpenWrt, therefore only limited support regarding your question possible.

However, since your question seems to be regarding flashing via TFTP, maybe some generic help can be given.

That's too unspecific to be helpfull.
What have you done already?
What is working, what is not working?

What I have done already and what is working:

  1. Make menuconfig
  2. I ran make command using the configuration in the screenshot attached and produced the following bin files:
    openwrt-rtkmipsel-rtl8197f-AP-4k-fw.bin
    openwrt-rtkmipsel-rtl8197f-AP-64k-fw.bin
    openwrt-rtkmipsel-rtl8197f-AP-fw.bin

What is not working:

  1. I tried to use all of the files one by one to upgrade the D-link DWR-M921 firmware from the web interface like I did with D-LINK DWR-921(Supported by Openwrt). It restarted the router after uploading but after booting there was no change. The default D-link firmware was still in the router instead of Openwrt.

This is interesting. There is not a Realtek mipsel SOC Target system option in the OpenWRT build system so I'm guessing that the D-Link DWR-M921 incorporated Realtek Code in the OpenWRT build system. This makes it GPL2'd.

Getting back to your image, if you can figure out what image format the OEM flashes, you can make sure that you select the right options in "Target Images"

I downloaded an update date image from
https://dlinkmea.com/index.php/product/details?det=RkxYbk9uWkZ0TVdkQVBJWDdkSVBqZz09
and converted to hex. Saw several "ub" entries - maybe it is a ubinized.bin?

Interesting to see there seems to be such a sophisticated level of support for these SoC's, apparently your problem is now just to match the vendor's factory image format.

Also I haven't seen this device anywhere in the EMEA region, might be a rebranded model.

I checked the header of the firmware, it should be cr6c i.e. FW_HEADER_WITH_ROOT according to

Does any of your generated images match this header?
Otherwise you might just need to add/change the factory image format in the Makefile entry for your device (i.e. add a new device there), to use the firmware tool to generate the appropriate header.

As tmomas pointed out, initiating a tftp update via the bootloader does usually not check the image so thoroughly, but you would need to solder a serial header for a USB TTL converter.

I will try this. I have no idea how I missed this. I will try it and give feedback

How do I check if the images match the header?
Here is the link to a folder containing the Bin files. https://mega.nz/folder/rQNVUCyI#XaphUCgZ1uV3FrMH92i5dA

So I am not very experienced with Openwrt. Just wrote a firmware (captive portal) that works on openwrt. I have been able to configure only 3 devices supported by Openwrt successfully- TP-link MR3420, D-Link DWR-921 and MikroTik RB951Ui-2HnD.

I tried this and it did not work. I used this same method in flashing my TP-link MR3420 and it was successful. But this is not working for the D-Link DWR-M921.
Here is a link to the bin files https://mega.nz/folder/rQNVUCyI#XaphUCgZ1uV3FrMH92i5dA
So I am not very experienced with Openwrt. I just wrote a firmware (captive portal) that works on openwrt. I have been able to configure only 3 devices supported by Openwrt successfully- TP-link MR3420, D-Link DWR-921 and MikroTik RB951Ui-2HnD.

I selected the right options in target Image. See the screenshot I uploaded.


Here is the datasheet ftp://ftp.d-link.co.za/DWR/dwrm921/datasheet/D-Link-DWR-M921_Datasheet-C03.pdf
I really don't understand what you mean by ubinized.bin.

There are a multitude of Image Formats. The OEM bootloader will look for a specific format.

https://openwrt.org/docs/techref/image.format

Unless someone has already obtained the USB TTL serial output for your device, you are not going to make much progress with openwrt based firmware.

The header of your images is cs6c, but the d-link updater is expecting cr6c:

#define FW_HEADER_WITH_ROOT ((char *)"cr6c")
#define FW_HEADER           ((char *)"cs6c")

Is there maybe any option in menuconfig where you could set something like 'linux-ro' instead of 'linux'?

I am not sure about this but I will check it and give you feedback.

I could not find anyplace to set 'linux-ro'. Can you attempt to run make menuconfig on the source(https://github.com/cgoder/openwrt_rtk/tree/master/rtk_openwrt_sdk)? That is the source I used.

I checked out the repo, and there is currently no Makefile entry for that format;

in target/linux/rtkmipsel/image/Makefile there is a block where the images are generated:

  define Image/Build/Profile/$(1)/squashfs
	$(call Image/BuildLoader,loader-$(SUBTARGET)-$(1),bin,$(call mkcmdline,$(1),$(2),$(3),$(6),$(7)),$(5))

	cvimg-$(SUBTARGET) linux $(KDIR)/loader-$(SUBTARGET)-$(1).bin $(BIN_DIR)/$(IMG_PREFIX)-$(1)-linux.bin $(5) $(6)
	dd if=$(BIN_DIR)/$(IMG_PREFIX)-$(1)-linux.bin of=$(BIN_DIR)/$(IMG_PREFIX)-$(1)-linux_4k.bin bs=4k conv=sync
	dd if=$(BIN_DIR)/$(IMG_PREFIX)-$(1)-linux.bin of=$(BIN_DIR)/$(IMG_PREFIX)-$(1)-linux_64k.bin bs=64k conv=sync
	cat $(BIN_DIR)/$(IMG_PREFIX)-$(1)-linux_4k.bin $(KDIR)/root.squashfs-4k > $(BIN_DIR)/$(IMG_PREFIX)-$(1)-fw_4k_cat.bin
	cat $(BIN_DIR)/$(IMG_PREFIX)-$(1)-linux_64k.bin $(KDIR)/root.squashfs-64k > $(BIN_DIR)/$(IMG_PREFIX)-$(1)-fw_64k_cat.bin
	cvimg-$(SUBTARGET) fix_chksum  $(BIN_DIR)/$(IMG_PREFIX)-$(1)-fw_4k_cat.bin $(BIN_DIR)/$(IMG_PREFIX)-$(1)-4k-fw.bin
	cvimg-$(SUBTARGET) fix_chksum  $(BIN_DIR)/$(IMG_PREFIX)-$(1)-fw_64k_cat.bin $(BIN_DIR)/$(IMG_PREFIX)-$(1)-64k-fw.bin
	cp $(BIN_DIR)/$(IMG_PREFIX)-$(1)-4k-fw.bin $(BIN_DIR)/$(IMG_PREFIX)-$(1)-fw.bin
	rm -rf $(BIN_DIR)/$(IMG_PREFIX)-$(1)-linux_4k.bin $(BIN_DIR)/$(IMG_PREFIX)-$(1)-fw_4k_cat.bin $(BIN_DIR)/$(IMG_PREFIX)-$(1)-linux.bin
	rm -rf $(BIN_DIR)/$(IMG_PREFIX)-$(1)-linux_64k.bin $(BIN_DIR)/$(IMG_PREFIX)-$(1)-fw_64k_cat.bin
  endef

The tool /tools/rtk-tools/src/cvimg.c will choose the signature to be written to the image header depending on the parameter (here it is called with linux), later mgbin would read the header magic value when merging the parts for the final image. The images are then copied and padded with dd for different block sizes (4k, 64k), then fixing the checksum due to the newly added 0x00 bytes.

You could try to copy the whole Makefile block above to e.g. Image/Build/Profile/$(1)/squashfs-ro and change the parameters in the cvimg calls from linux to linux-ro, this should give you a new setting squashfs-ro in menuconfig -> Target Images.

And even if this works to generate images with the cr6c header, it would just be the first step to supporting the device, but then again I don't have any experience with the rtk targets and can not say how complicated it could be (flash layout, GPIO pins, mac addresses, wifi calibration etc.).

Wow. Thanks for this. I will try it out and see what I can achieve with the information you provided.

I tried to change the parameters and after running make menu config I still see squashfs in the Target Images and not squashfs-ro which I specified. Is it possible to make this changes on your end and send me the Binary files so I can attempt to flash.

It might be required to make clean (or even distclean?) and/or delete your local .config when there are changes that affect menuconfig options. (I'm not sure what exactly is needed for which kind of changes, but distclean always used to work for me, although it takes hours to rebuild everything from scratch again...)

But since you don't need the cs6c type image anyways, you could just overwrite the original squashfs entry and replace linux with linux-ro.

Alright. I will try and get back to you