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

jackcolentern · July 14, 2019, 4:10pm

it is wlan5mac=00:11:22:33:44:55 , sorry for not making it clear.
current building with changed 11-ath10k-caldata thanks for your help!

Pilot6 · July 14, 2019, 4:12pm

You don't have to rebuild. You can change it in /etc/hotplug.d/firmware in the router. Then run wifi command to check.

jackcolentern · July 14, 2019, 4:22pm

Thanks!!! now i got ac wifi working!
I am now looking at 2.4G wifi.
Thanks again

Pilot6 · July 14, 2019, 4:39pm

When you are done, don't forget to send a PR to maintainers.

jackcolentern · July 14, 2019, 4:41pm

I definitely will, but i need to fix the bootm 9f080000 problem first, otherwise it is not possible to boot without serial port attached to router

Thanks for your help again

EDIT: 2.4Ghz wifi working as well, now i need to fix the bootm problem and gpio and i am done!

jackcolentern · July 14, 2019, 5:29pm

I used md 9f080000 command to print the first few bytes of the original firmware and openwrt in location 9f080000

I really cant see why original firmware boots from 9f080040

anon50098793 · July 14, 2019, 5:32pm

so how did you write the openwrt kernel there?

jackcolentern · July 14, 2019, 5:34pm

I just upgrade the openwrt factory.bin in the original firmware web gui

anon50098793 · July 14, 2019, 5:35pm

paste in code tags your device definition from target/linux/athxx/image....

jackcolentern · July 14, 2019, 5:37pm

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

anon50098793 · July 14, 2019, 5:51pm

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

jackcolentern · July 14, 2019, 6:12pm

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?

Pilot6 · July 14, 2019, 6:16pm

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

jackcolentern · July 14, 2019, 6:17pm

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.

jackcolentern · July 14, 2019, 6:21pm

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....)

Pilot6 · July 14, 2019, 6:27pm

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.

jackcolentern · July 14, 2019, 6:30pm

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?

jackcolentern · July 14, 2019, 6:55pm

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

jackcolentern · July 14, 2019, 7:00pm

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?

Pilot6 · July 14, 2019, 7:11pm

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