Support for D-Link DIR-842 (Rev C2)

define Device/dlink_dir-842-c2
  KERNEL := kernel-bin | append-dtb | relocate-kernel | lzma
  KERNEL_INITRAMFS := $$(KERNEL) | seama
  IMAGES += factory.bin
  SEAMA_MTDBLOCK := 5
  # 64 bytes offset:
  # - 28 bytes seama_header
  # - 36 bytes of META data (4-bytes aligned)
  IMAGE/default := append-kernel | pad-offset $$$$(BLOCKSIZE) 64 | append-rootfs
  IMAGE/sysupgrade.bin := \
	$$(IMAGE/default) | seama | pad-rootfs | append-metadata | check-size $$$$(IMAGE_SIZE)
  IMAGE/factory.bin := \
	$$(IMAGE/default) | pad-rootfs -x 64 | seama | seama-seal | check-size $$$$(IMAGE_SIZE)
  SEAMA_SIGNATURE :=
  ATH_SOC := qca9563
  DEVICE_VENDOR := D-Link
  DEVICE_MODEL := DIR-842
  DEVICE_VARIANT := =i
  IMAGE_SIZE := 15680k
  DEVICE_PACKAGES :=  kmod-usb-core kmod-usb2 kmod-ath10k-ct ath10k-firmware-qca988x-ct
  SEAMA_SIGNATURE := wrgac65_dlink.2015_dir842
  SUPPORTED_DEVICES += dir-842-c2
endef
TARGET_DEVICES += dlink_dir-842-c2

Just taking a (wild) guess but try under kernel

KERNEL_ENTRY := 0x9f080040

( note that seama signature will have to go or be investigated... later )

KERNEL_LOADADDR := 0x9f080040

is sometimes something one alters but in your case i'm still digesting whats going on....and i suspect its more of a seama thing + i have absolutely no experience.... with seama...

the thing to consider is that both the flashing process, and the loading process introduce opportunities for things to be altered.

better not speculate so this is where i leave it to the experts :wink:

Thanks, I am building the image now, will let you know after i tested.

I initially suspected the original firmware has some padding(or other data) in the first 40(h) bytes, but the md result proves me wrong.

Do you have anidea why the original firmware boots at 9f080040 instead of 9f080000?
Because it should be booting from 9f080000 by the looks of it right?

Because of bootcmd=bootm 0x9f080040 in u-boot env.

Thanks for reply,
I understand the bootm settings, but what I dont understand is why the original firmware should boot from 9f080040 and openwrt should boot from 9f080000, because both firmware looks the same in the first 40(h) bytes.

Here is my result

KERNEL_ENTRY := 0x9f080040

Cant boots from 9f080040 (Bad magic number), but boots from 9f080000

KERNEL_LOADADDR := 0x9f080040

Cant boot from 9f080000 (Bad magic number), cant boot from 9f080000 also (stuck as Starting kernel....)

The fastest way to resolve this is to send a PR mentioning this issue.
It will be reviewed by someone who deals with this on a daily basis, most likely @mkresin
And you'll get a suggestion how to fix it. It shouldn't be difficult.

1 Like

I found something interesting

When i binwalk the original image, i got

112           0x70            uImage header, header size: 64 bytes, header CRC: 0x443AD3BC, created: 2017-10-03 10:51:26, image size: 1225907 bytes, Data Address: 0x80060000, Entry Point: 0x80060000, data CRC: 0x6967A9F8, OS: Linux, CPU: MIPS, image type: Multi-File Image, compression type: lzma, image name: "MIPS Seattle Linux-3.3.8"

binwalk openwrt i got

112           0x70            LZMA compressed data, properties: 0x6D, dictionary size: 8388608 bytes, uncompressed size: 5810276 bytes

can is the missing of uImage header cause this?

Thanks! I will submit PR after I fixed the LED and gpio buttons.

1 Like

It does make a difference! after i spliced the original uimage header on openwrt using hex editor (I know this is wrong, but i can get more information), i got this

 Booting image at 9f080040 ...
   Image Name:   MIPS Seattle Linux-3.3.8
   Created:      2017-10-03  10:51:26 UTC
   Image Type:   MIPS Linux Multi-File Image (lzma compressed)
   Data Size:    1225907 Bytes =  1.2 MB
   Load Address: 80060000
   Entry Point:  80060000
   Contents:
   Image 0:  1225899 Bytes =  1.2 MB
   Verifying Checksum at 0x9f080080 ...Bad Data CRC

So I just need to find a way to generate the correct image header?

1 Like

There are things like append-uImage-fakehdr, but I don't know the usage.

I dont know this is progress or not but i managed to "fool" the bootloader into booting by appending the first 40(h) bytes of the firmware to all 00 00 00....

But doing so messed up the partition scheme and openwrt cant detect rootfs anymore, so i would assume that this is not an ideal solution

Thanks, I tried to add | append-uImage-fakehdr firmware | before | append-kernel , It cant boot as the header checksum is wrong, I think generating the proper uImage header is the only way now?

I used mkimage utilities to generate the uImage header for ther kernel, but for now it doesn't seems to be working, I am figuring out what the problem is.

   Image Name:   Plsss work
   Created:      2019-07-15   7:00:43 UTC
   Image Type:   MIPS Linux Multi-File Image (lzma compressed)
   Data Size:    1834920 Bytes =  1.7 MB
   Load Address: 80060000
   Entry Point:  80060000
   Contents:
   Image 0:  1834912 Bytes =  1.7 MB
   Verifying Checksum at 0x9f080040 ...OK
   Uncompressing Multi-File Image ... Too big uncompressed streamLZMA ERROR 1 - must RESET board to recover

Thanks In advanced

Unfortunately I cant get the ac wifi mac to set correctly,
I can see the correct mac is patched in pre-cal-pci-0000:00:00.0.bin , but the mac address used is not the correct one, but it is not random at every boot.

Maybe you need to use mtd_get_mac_text instead.

Thanks but the result is the same, I can see the correct MAC in hex format in the precal file, but the mac used is still wrong

Maybe it only looks correct. It's a common mistake with d-link. see th difference between mtd_get_mac_ascii and mtd_get_max_text. I wrote the second one.

Just realized I need to delete pre-cal-pci-0000:00:00.0.bin to make it generate a new one, I found something interesting:

with mtd_get_mac_text , the mac address in the pre-cal file is wrong, but it is the same as the mac inside wifi1.caldata I pulled from the original Dlink firmware.

It is not wrong, It is in different format. Note that mtd_get_mac_text() doesn't use $key parameter. Only $offset. All depends on which format the mac is initially stored.