You may have better luck if you flash over serial and TFTP. If you first boot an initramfs image via TFTP, you can test your image to check that everything is functional. Without this first step, you risk bricking the device.
## Loading kernel from FIT Image at 44000000 ...
Using 'config@1' configuration
Trying 'kernel-1' kernel subimage
Description: ARM64 OpenWrt Linux-6.6.74
Type: Kernel Image
Compression: gzip compressed
Data Start: 0x440000e8
Data Size: 12833683 Bytes = 12.2 MiB
Architecture: AArch64
OS: Linux
Load Address: 0x41000000
Entry Point: 0x41000000
Hash algo: crc32
Hash value: fa914021
Hash algo: sha1
Hash value: 5fa50b54417ce9a0116f8532c64457b488cc489e
Verifying Hash Integrity ... crc32+ sha1+ OK
## Loading fdt from FIT Image at 44000000 ...
Using 'config@1' configuration
Trying 'fdt-1' fdt subimage
Description: ARM64 OpenWrt tplink_eap620hd-v2 device tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x44c3d5c0
Data Size: 32642 Bytes = 31.9 KiB
Architecture: AArch64
Hash algo: crc32
Hash value: 43740a60
Hash algo: sha1
Hash value: bcda09e7a84256eb303219f637357f161ee91dd6
Verifying Hash Integrity ... crc32+ sha1+ OK
Booting using the fdt blob at 0x44c3d5c0
Uncompressing Kernel Image ... OK
Loading Device Tree to 484f5000, end 484fff81 ... OK
mtdids not defined, no default present
Could not find PCI in device tree
Using machid 0x8030200 from environment
Starting kernel ...
Jumping to AARCH64 kernel via monitor
Yes, I agree that your DTS file may be wrong. Given it doesn't even start the kernel, it's also possible that the memory location the image is loaded to doesn't match where uboot moves execution to - but I do not understand uboot well enough to help here.
Could you share your DTS? (Unsure if I can help, but I can at least have a look).
I would first try changing the serial settings to match the eap610-outdoors - I'm guessing it is more likely to be the same as the eap610-outdoors as it is the SOC (and at least another 6018 device uses uart3). This would also make sense if the serial comms drop off immediately after handover to the kernel from uboot.
To be specific - change lines 18, 26, and 51-53 (to match 63-67).
(I'm a first timer as well but sometimes fresh eyes help)
excellent - we can boot openwrt on it! thanks for that help/tip
Still not completely out of the woods yet
Cannot parse config file '/etc/fw_env.config': No such file or directory
Failed to find NVMEM device
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
and i did not see the lan interface come up either just loopback
I suppose we need to change more dts towards eap610-outdoor still
dmesg doesnt show much in string search of interface/eth.
I do see
[ 10.503537] ath11k c000000.wifi: failed to fetch board data for bus=ahb,qmi-c
hip-id=0,qmi-board-id=255,variant=TP-Link-EAP620-HD-v2 from ath11k/IPQ6018/hw1.0
/board-2.bin
[ 10.503605] ath11k c000000.wifi: failed to fetch board data for bus=ahb,qmi-c
hip-id=0,qmi-board-id=255 from ath11k/IPQ6018/hw1.0/board-2.bin
[ 10.517748] ath11k c000000.wifi: failed to fetch board data for bus=ahb,qmi-c
hip-id=0,qmi-board-id=255 from ath11k/IPQ6018/hw1.0/board-2.bin
[ 10.530377] ath11k c000000.wifi: failed to fetch board.bin from IPQ6018/hw1.0
[ 10.542952] ath11k c000000.wifi: qmi failed to fetch board file: -12
[ 10.549959] ath11k c000000.wifi: failed to load board data file: -12
bdwlan_*.bin is going to be the board data file (BDF). I think it might be in a raw file, so the first thing to try is putting it in the roots as board.bin. There's a tool named ath11k-bdencoder that can wrap the BDF in the newer format that board-2.bin uses
@mrnuke i pulled in gpl and found /lib/firmware/IPQ6018/bdwlan_US.bin" so i copied that over to "package/firmware/ipq-wifi/files/board-tplink_eap620hd-v2.ipq6018.bin". I am hoping thats the correct way to pull in a BDF for build?
However on the complie i am still getting the same errors with wifi not seeing board-2.bin on boot. Perhaps i missed something?
I think bdwlan_US.bin is an API1 format. If you just pop the file into ipq-wifi, you'll get a board-2.bin. The kernel expects that to be API2 format and wil throw errors otherwise. To get the kernel to use API 1, you need to name it board.bin. Just scp bdwlan_US.bin to the rootfs, and name the BDF board.bin
If you insist on putting the BDF in ipq-wifi without first testing it, you need to convert it with ath11k-bdencoder -c desc.json . The JSON file describes some of the strings that get added. For example:
i am still testing with initramfs. So in this case wouldnt i need to place the bwlan_US.bin somehow in the build process?
Sorry if im missunderstanding but i dont believe i can scp the file into the initramfs as i would need to reboot the device to see if wifi card picked it up?
I see. I had (incorrectly) assumed it was running from flash. Then we end up at ath11k-bdencoder, and package/firmware/ipq-wifi/files/board-tplink_eap620hd-v2.ipq6018.bin. This would be the proper way.
There's also the possibiliy of droping files into target/linux/qualcommax/ipq60xx/base-files/ (the hacky way)
ok from trying putting the bdwlan.bin into package/firmware/ipq-wifi/files/board-tplink_eap620hd-v2.ipq6018.bin and building. I am still unable to get wifi to come up on initramfs:
root@OpenWrt:~# ls -l /lib/firmware/IPQ6018/
-rw-r--r-- 1 root root 156458 Jan 1 00:00 Notice.txt
-rw-r--r-- 1 root root 148 Jan 1 00:00 m3_fw.b00
-rw-r--r-- 1 root root 6712 Jan 1 00:00 m3_fw.b01
-rw-r--r-- 1 root root 294912 Jan 1 00:00 m3_fw.b02
-rw-r--r-- 1 root root 153 Jan 1 00:00 m3_fw.flist
-rw-r--r-- 1 root root 6860 Jan 1 00:00 m3_fw.mdt
-rw-r--r-- 1 root root 340 Jan 1 00:00 q6_fw.b00
-rw-r--r-- 1 root root 7000 Jan 1 00:00 q6_fw.b01
-rw-r--r-- 1 root root 4696 Jan 1 00:00 q6_fw.b02
-rw-r--r-- 1 root root 2559184 Jan 1 00:00 q6_fw.b03
-rw-r--r-- 1 root root 412288 Jan 1 00:00 q6_fw.b04
-rw-r--r-- 1 root root 198052 Jan 1 00:00 q6_fw.b05
-rw-r--r-- 1 root root 9408 Jan 1 00:00 q6_fw.b07
-rw-r--r-- 1 root root 453484 Jan 1 00:00 q6_fw.b08
-rw-r--r-- 1 root root 408 Jan 1 00:00 q6_fw.flist
-rw-r--r-- 1 root root 7340 Jan 1 00:00 q6_fw.mdt
root@OpenWrt:~# dmesg | grep wifi
[ 11.018518] ath11k c000000.wifi: ipq6018 hw1.0
[ 11.018554] ath11k c000000.wifi: FW memory mode: 0
[ 11.352067] ath11k c000000.wifi: qmi fail to get qcom,m3-dump-addr, ignore m3 dump mem req
[ 11.357548] ath11k c000000.wifi: chip_id 0x0 chip_family 0x4 board_id 0xff soc_id 0xffffffff
[ 11.365200] ath11k c000000.wifi: fw_version 0x25008f8e fw_build_timestamp 2024-03-01 03:54 fw_build_id WLAN.HK.2.5.0.1-03982-QCAHKSWPL_SILICONZ-3
[ 11.474621] ath11k c000000.wifi: failed to fetch board data for bus=ahb,qmi-chip-id=0,qmi-board-id=255,variant=TP-Link-EAP620HD-v2 from ath11k/IPQ6018/hw1.0/board-2.bin
[ 11.474684] ath11k c000000.wifi: failed to fetch board data for bus=ahb,qmi-chip-id=0,qmi-board-id=255 from ath11k/IPQ6018/hw1.0/board-2.bin
[ 11.488819] ath11k c000000.wifi: failed to fetch board data for bus=ahb,qmi-chip-id=0,qmi-board-id=255 from ath11k/IPQ6018/hw1.0/board-2.bin
[ 11.501346] ath11k c000000.wifi: failed to fetch board.bin from IPQ6018/hw1.0
[ 11.513922] ath11k c000000.wifi: qmi failed to fetch board file: -12
[ 11.520954] ath11k c000000.wifi: failed to load board data file: -12
Hello rspierz, I bought one of those eap610, it was an indoor unit from amazon, It was suppose to be a V2 and they sent a V3 instead. Had to update the firm manually it worked ok(good thing didn't flash with V2), nice stuff. No support not recognized so no fancy phone app for phone with US V3 in Canada, there was two breaches from that with the OEM firmware.It got sent back after 30 days of use.
Anyway, are you using putty with TPFT opensource by Jouchim, I think?
I had a problem using the goods on a Windows 11 machine, had to move back over to windows 10 to get it done to an other unrelated.
Thank-you to trying to make that better, and good lucky to jailbreak that.
yes just got that working.. sorry i was confused by the intructions. Generated a board-2.bin and placed in the iqp-wifi files path. Unfortunately on recomplie it still doesnt have the board file in /lib/firmware/IPQ6018 and dmesg complains of the same.
Is it possible that the complie path isnt actually adding it to the final image? Is there anything else i would need to edit to ensure its baked into the image?