Any news, anyone working on this?
I am willing to mail the device to someone in Europe if that helps, I don't care much about things and I tore it apart anyway, if I can help with that I'll go ahead 
By JTAG you mean serial interface.
1 Like
Yeah I confused them at first. It's serial interface I'm doing right now.
How do I send the printenv command to it? Is it OEM locked if it sends no answer?
1 Like
The bootlog you put on pastebin seems to throw out some garbage earlyboot ( uboot )
So, either it's some sort of obfuscation i'm not familiar with or you'd need to have your serial device on another setting ( common cause of scrambling then unscrambling ) during the early boot stage to interrupt ( if it's possible - most are )
Search up on your device..... re: bootloader baud changes and interrupt key sequences.
( next common one to try would be 38xxx whatever it is..... and then 56xxx )
1 Like
Hmm indeed that was the problem. I played around a bit with baud rate and data bits, now the beginning is descrambled!
There are these lines saying this:
Hit any key to stop autoboot: 0
Reset button released
And serial connection info
[ 0.000000] Kernel command line: board=AP152 console=ttyS0,115200 mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env),64k(devdata),64k(devconf),64k(misc),15680k(upgrade),64k(art),16m@0(rootfs)ro root=/dev/mtdblock7 init=/sbin/init noinitrd crashkernel=10M@20M
Very curious. Let's see if I manage to intrerupt the bootloader.
Edit: Haha it doesn't want to be interrupted with a hardware key 
I will need to figure out the serial command
Hit any key to stop autoboot: 0
Reset button released
## Booting image at 9f080040 ...
1 Like
D-Link normally disables input from serial console. You can only see the output from there. no commands are possible.
1 Like
Oh, I understood. This is why it wasn't accepting any sort of command.
Anyway, now the descrambled part of the bootlog is showing some memory addresses and more filesystem info. Is it of enough help for at least some test builds?
I'd say it's close to 90% compatible with this device.
cat ./target/linux/ath79/dts/qca9563_dlink_dir-859-a1.dts | grep -A11 partition
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
partition@0 {
label = "bootloader";
reg = <0x000000 0x40000>;
read-only;
};
partition@40000 {
label = "bdcfg";
reg = <0x040000 0x10000>;
read-only;
};
partition@50000 {
label = "devdata";
reg = <0x050000 0x10000>;
read-only;
};
partition@60000 {
label = "devconf";
reg = <0x060000 0x10000>;
read-only;
};
partition@70000 {
compatible = "seama";
label = "firmware";
reg = <0x070000 0xf80000>;
};
art: partition@ff0000 {
label = "art";
reg = <0xff0000 0x010000>;
read-only;
};
cat ./target/linux/ath79/image/generic.mk | grep -A7 dir-859-a1 | head -n 9
define Device/dlink_dir-859-a1
$(Device/seama)
ATH_SOC := qca9563
DEVICE_TITLE := D-LINK DIR-859 A1
IMAGE_SIZE := 15872k
DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-ath10k-ct ath10k-firmware-qca988x-ct
--
SUPPORTED_DEVICES += dir-859-a1
endef
TEST being the operable word.... Without an initramfs recipe and / or a way to boot from tftp / usb .... Physical access and someone who knows seama / dlink firmware idiosyncrasies would be advisable.
Glad to hear this, but if I understood right: testing is not done by "cooking" bin's and flashing them in emergency/recovery mode (which accepts "any" firmware)? There shouldn't be a need for tftp.
Look, dir-859 works flashing openwrt in emergency mode straight away: D-Link DIR-859 A3 AC1750 works with DIR-869 A1 image
Essentially what else would we need?
Sorry if I appear too simple, but: take openwrt from dir-859 (edit: 869 also similar, all revisions?), put qca9888 driver and the hw addresses found in bootlog. And done. It should just work, isn't it?
When modifying hardware, routers, computer systems. It's prudent to base actions on could. Not should.
One "should" ask oneself;
-
What do I need to do ( we have now pretty much cleared that up... barring some seama / boot trick schemantics )
-
How am I going to do it. You've addressed the software creation side of this.... Can you go into more detail on applying test firmware.
-
What can go wrong, and what am I going to do if/when it does. What are your plans?
This is where my limited knowledge and availability of tools ends. Advanced software and hardware is something that I won't be able to help with. I can learn and acquire them, but it takes time and money.
However I am perfectly willing to:
- Try and find someone to do a hexdump on the memory, in the process desoldering it and destroying the router.
- Mail it in Europe (or even somewhere else not too far away from Romania) via post service, it's dirt cheap.
- Risk bricking the device with even the most poorly built firmware, with the poorest of boot tricks stuck-together.
Hi all,
I try to flash the router using this fw via recovery mode
https://downloads.openwrt.org/snapshots/targets/ath79/generic/openwrt-ath79-generic-dlink_dir-859-a1-squashfs-factory.bin
not working, the router stuck in recovery mode.
I need to reflash it again using dlink fw
Regards
Ari
Some relevant info in this thread... Please don't spam it with C1 stuff. Anyone with the skills may be interested in perusing or testing the PR.
The C2 support has been merged into master. That image should work on C1 as well.
If someone is ready to test, it is quite easy to add official C1 support.
Pull request to support C1 is here:
C2 image works perfectly on C1
2 Likes
Why don't you disable USBfor c1 in dts?
Mainly because the USB on C1 can be modded with some soldering skills. So people wont have to recompile the image if they have a modded C1, they just have to install kmod-usb2
1 Like
This is not the way it is normally done. Those who can solder USB can also build an image with modified dts.
Otherwise I don't see a reason of having a separate image for c1. We could have one for both c1 and c2 since the only diff is the USB.
1 Like
Also soldering people can simply install C2 image.