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.
Today I got my hands on a C3 (or maybe C3EU). I created Support for D-Link DIR842 (Rev C3) - Maybe EU version? for the discussion.
Has anyone actually confirmed that GPIO 15 is correct for the power / status LED ?
I'm just wondering why it's constantly on during boot, rather than showing the typical OpenWRT flash pattern to allow for entering failsafe mode.
Also I noticed that 2.4 GHz wifi will use the label mac in OpenWRT (i.e. the same as for LAN), rather than the WAN mac as the stock firmware would do. Is this intended behaviour so that wifi would use the same MAC as LAN?
1 Like
Is anyone willing to share a backup of an ART partition for the C1 with me? Mine doesn't seem to have any ath10k data.
your device seems to have art partition stored in another partition.
It seems like we have two kinds of dir-842, they store art in different partition
I think I answered my own question in this thread: Support for D-Link DIR842 (Rev C3) - #77 by augs
The version I have seems to load boarddata from the firmware image provided by dlink, not from the art partition. I've got mine mostly working by commenting out the caldata_extract line for this model in /etc/hotplug.d/firmware/11-ath10k-caldata and copying boardData_2_0_QCA9888_5G_Y9582.bin from the vendor firmware to /lib/firmware/ath10k/pre-cal-pci-0000:00:00.0.bin
I spent about 20 minutes reverse engineering qca_ol.ko, but didn't make it far enough to understand what the offset in the structure was for the ID it was mapping in ol_ath_softc_net80211 (this changes based on various compile time flags). Someone who is more familiar with qsdk could probably figure out the image selection fairly quickly.
I'm also not sure what the stance is from openwrt of including boarddata from the vendor directly in the openwrt source tree and what the copyright implications are.
Do you have a ttl adapter to do a cat /proc/mtd ?
I am interested in what the partition layout are, it seems like the partition layout is different
If I understand correctly boardData_2_0_QCA9888_5G_Y9582.bin is different from the calibration data.
boardData_2_0_QCA9888_5G_Y9582.bin is a board file while the data in art partition is the calibration data.
I suspect that the DIR842 you got stores the calibration file in other location (or the partition layout is different)
This is from openwrt, I have not actually soldered the UART pins to check from the stock firmware, I only extracted the image from an older variant and looked around the filesystem:
dev: size erasesize name
mtd0: 00040000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00010000 00010000 "devdata"
mtd3: 00010000 00010000 "devconf"
mtd4: 00010000 00010000 "misc"
mtd5: 00f50000 00010000 "firmware"
mtd6: 001bffc0 00010000 "kernel"
mtd7: 00d90000 00010000 "rootfs"
mtd8: 00af0000 00010000 "rootfs_data"
mtd9: 00010000 00010000 "art"
mtd10: 00020000 00010000 "reserved"
[ 0.406236] Creating 8 MTD partitions on "spi0.0":
[ 0.411196] 0x000000000000-0x000000040000 : "u-boot"
[ 0.417111] 0x000000040000-0x000000050000 : "u-boot-env"
[ 0.423348] 0x000000050000-0x000000060000 : "devdata"
[ 0.429340] 0x000000060000-0x000000070000 : "devconf"
[ 0.435336] 0x000000070000-0x000000080000 : "misc"
[ 0.440983] 0x000000080000-0x000000fd0000 : "firmware"
[ 0.451171] 2 seama-fw partitions found on MTD device firmware
[ 0.457252] Creating 2 MTD partitions on "firmware":
[ 0.462384] 0x000000000040-0x0000001c0000 : "kernel"
[ 0.468275] 0x0000001c0000-0x000000f50000 : "rootfs"
[ 0.474045] mtd: device 7 (rootfs) set to be root filesystem
[ 0.481372] 1 squashfs-split partitions found on MTD device rootfs
[ 0.487827] 0x000000460000-0x000000f50000 : "rootfs_data"
[ 0.494153] 0x000000fd0000-0x000000fe0000 : "art"
[ 0.499841] 0x000000fe0000-0x000001000000 : "reserved"
hexdump -s 0x5000 /dev/mtd9
0005000 ffff ffff ffff ffff ffff ffff ffff ffff
*
0010000
Ya, as you can see the mtd9 partition is filled with ff ff ff ff ff only....
The layout scheme of openwrt is pre-defined, so we need to get the partition layout of the original firmware in order to find out where the calibration (art) partition is.
in mtd1, the uboot environment contains these bootflags
bootargs=console=ttyS0,115200 root=31:02 rootfstype=jffs2 init=/sbin/init mtdparts=ath-nor0:256k(u-boot),64k(u-boot-env),14528k(rootfs),1408k(uImage),64k(mib0),64k(ART)
Which means art should line up at 0xff0000
Dumping /dev/mtd10 with openwrt booted yields 128k of data (0xfe0000-0x1000000), and what looks like the magic I see for the first 2 bytes of other art partitions at 0x5000 I have inspected:
$hexdump -s 0x15000 -n 16 mtd10
0015000 2f20 0e15 0101 0300 257f 2514 0000 0020
However, the driver doesn't load when I try to use that for pre-cal-pci-0000:00:00.0.bin when I patched 11-ath10k-caldata to read from there, nor does it load if I indicate that as cal-pci-0000:00:00.0.bin.
Another interesting note:
mtd9:0x1000 looks like ath9 data as is mtd10:0x11000
$ hexdump -s 0x1000 -n 16 mtd9
0001000 0202 0302 008f 8e03 0000 0000 0000 0000
$ hexdump -s 0x11000 -n 16 mtd10
0011000 0202 0200 0403 0605 0000 0000 0000 0000
1 Like
my router also shows:
bootargs=console=ttyS0,115200 root=31:02 rootfstype=jffs2 init=/sbin/init mtdparts=ath-nor0:256k(u-boot),64k(u-boot-env),14528k(rootfs),1408k(uImage),64k(mib0),64k(ART)
but my art partition starts at 0xfd0000 , so i dont think the bootargs actually corresponds to the partition layout
Can you show how you patch the 11-ath10k-caldata ?
case "$FIRMWARE" in
"ath10k/pre-cal-pci-0000:00:00.0.bin")
case $board in
dlink,dir-842-c1)
caldata_extract "reserved" 0x15000 0x2f20
ath10k_patch_mac $(mtd_get_mac_ascii devdata wlan5mac)
ln -sf /lib/firmware/ath10k/pre-cal-pci-0000\:00\:00.0.bin \
/lib/firmware/ath10k/QCA9888/hw2.0/board.bin
;;
I think I screwed up the first time I tried it and left some files in /lib/firmware from other attempts, after clearing everything out and using that patch, it does function properly, the radio signal and link characteristics do not seem to work quite as well as with boardData_2_0_QCA9888_5G_Y9582.bin:
mtd:0xff5000:
client signal @ 2m distance: -54 dBm
boardData_2_0_QCA9888_5G_Y9582.bin:
client signal @ 2m distance: -42 dBm
The other thing that puzzles me is that I don't see any bash scripting in the stock firmware trying to extract that range from the mtd, however it is likely buried in the qsdk driver they are using in binary form.
The closed source driver in the stock firmware and read the art partition directly, so it does not need to extract the data from mtd.
If you can make sure this is working, can you open a pull request? I am not sure how OpenWrt maintainers are going to deal with this though. We need some scripts to select where to load the art data. (without breaking the working wifi on some of the DIR842)
Anyway thank you very much for you work!
Personally I think the better approach would be to go against the decree in https://openwrt.org/docs/guide-developer/defining-firmware-partitions and instead use the flash layout specified in the u-boot env to maximize compatibility, however we would need to collect a sufficient set of u-boot env samples to determine that we never accidentally overwrite art.
Can you post the u-boot env boot flags from your c1 device?
u-boot env does not correspond to the real flash layout