Yes, its not an issue to extract the FW, but we lack the kernel/userspace tools to upload that currently.
there is usr.squashfs\sbin\aq-fw-download why do we need to (re)upload the fw into the Aquantia chip? Who does this normally? Why it is required? And what is it used for?
Its needed because they wont work without the proper firmware, it contains all of the configuration.
Userspace does it with a application, script or whatever, sometimes U-boot can also do it.
The thing has some kind of MCU inside that runs on that FW, without it its useless.
Mainline U-boot can for sure.
The precompile binary in the stock FW does not really help.
Anything you want me to investigate (for dummies) I am doing this the first time. But like I said I can code and debug etc. I am just not familiar with the Toolchain and my Linux knowledge is a bit rusty.
Can you tell me which config it loads when booting?
So that I know which reference design is used.
Unfortunately, not much you can do currently.
Can you tell me which config it loads when booting?
What do I need to look for?
Just when the U-boot loads the kernel.
You will see the FIT image information being printed.
Copy/paste that here
Usually its possible to have the AQR PHY load the FW directly for SPI-NOR or EEPROM but that costs money and MDIO you already have so they load it from Linux.
Is it this what you are looking for?
MMC read: dev # 0, block # 32802, count 32768 ... 32768 blocks read: OK
## Loading kernel from FIT Image at 44000000 ...
Using 'config@hk01' configuration
Trying 'kernel@1' kernel subimage
Description: ARM64 OpenWrt Linux-4.4.60
Type: Kernel Image
Compression: gzip compressed
Data Start: 0x440000e8
Data Size: 5080168 Bytes = 4.8 MiB
Architecture: AArch64
OS: Linux
Load Address: 0x41080000
Entry Point: 0x41080000
Hash algo: crc32
Hash value: 601db371
Hash algo: sha1
Hash value: 67168a753639fd8d3f357b58320dbf11e7604e87
Verifying Hash Integrity ... crc32+ sha1+ OK
## Loading fdt from FIT Image at 44000000 ...
Using 'config@hk01' configuration
Trying 'fdt@hk01' fdt subimage
Description: ARM64 OpenWrt qcom-ipq807x-hk01 device tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x444d8698
Data Size: 91662 Bytes = 89.5 KiB
Architecture: AArch64
Hash algo: crc32
Hash value: 909da436
Hash algo: sha1
Hash value: c518be5f9b045495141d5217890e256f4433cec1
Verifying Hash Integrity ... crc32+ sha1+ OK
Booting using the fdt blob at 0x444d8698
Uncompressing Kernel Image ... OK
Loading Device Tree to 4a3e6000, end 4a3ff60d ... OK
Using machid 0x8010000 from environment
Yes, exactly that.
So, its just a HK01 reference board.
Probably the HK01.2 model.
They look similar. Just the extra WAN Port and MMC card slot etc. are missing physically.
It just means that is based on that reference design, it does not have to have all of the stuff.
The extracted dtb from squashfs using extract-dtb
/dts-v1/;
/ {
#address-cells = <0x02>;
#size-cells = <0x02>;
model = "Qualcomm Technologies, Inc. IPQ807x/AP-HK01-C1";
compatible = "qcom,ipq807x-hk01\0qcom,ipq807x";
qcom,msm-id = <0x143 0x00 0x158 0x00 0x186 0x00 0x188 0x00>;
interrupt-parent = <0x01>;
qcom,board-id = <0x08 0x00>;
qcom,pmic-id = <0x00 0x00 0x00 0x00>;
Anything else we can do to help?
Didnt open up my router just yet 
Or do we just have to wait until the ipq807x SOC family is supported before we can go on?
Thanks!
In case anybody still looking for SSH access, I've just got the following from QNAP Support:
How to open Qhora SSH function
-> Default SSH is disable, please Hold and Keep the WPS button(around 12 seconds) until heard twice “bi” to enable SSH, then you can use putty tool SSH the Qhora device.
Login to the terminal via SSH using the utility, ex: PuTTY
- IP / port: 192.168.100.1 / 22200
- Login name / password: admin / the Mac Address of QHora
EDIT: Tested on my device, Port 22200 opens after the second beep of WPS and login works with the locally setup user (it's in sudoers so basically root).
7 Likes
Has there been any success with the built in QVPN OpenVPN client? Are you able to connect to 3rd party VPN providers such as Vypr VPN?
I have been struggling to get the connection to work. The client connects but the router does not route traffic through the VPN tunnel, traffic continues to go through my ISP. I see the following error on the openvpn log file:
40 NOTE: unable to redirect default gateway -- Cannot read current default gateway from system
It seems the build in OpenVPN client does not support connection to 3rd party VPN services, any opinion about this?
I'm working on support for the QNAP 301w (got one with a discount)
I compiled a working initramfs image and my goal is to use A/B partition switching during sysupgrade.
The sysupgrade script itself works but there is one major problem afterwards:
U-boot is providing always the same PARTUUID from the first rootfs partition (root=PARTUUID=2a213133-47f8-80a1-5d66-1d565a2ec756) as the rootdev cmdline regardless of what partition is actually booting.
This leads to wrong rootfs/rootfs_data mapping. (stock firmware has it's own rootfs/rootfs_data logic and doesn't use the rootdev from the cmdline)
Of cause I can add a "bootargs-append" in the DTS but when the rootdev would be also hardcoded.
Do you know a way to ignore/replace the u-boot rootdev dynamically with the proper rootdev depending on the actual boot partition?
Second point is the emmc:
I just added a "status = okay" to the DTS for the sdhc node. But that leads to an error -110 from the emmc (means emmc doesn't respond to voltage switch as far as I know)
I then disabled voltage switching and reduced speed:
no-1-8-v;
cap-sd-highspeed;
cap-mmc-highspeed;
max-frequency = <5000000>;
Now the emmc is working, but slowly. Stock firmware runs the emmc at 1_8v / HS200
Do you know if that's even possible with the upstream msm sdhc driver on ipq807x? I think there is a regulator definition & driver neccessary, right? Strange thing is, stock DTS doesn't even define vqmmc-supply, cd-gpios etc. for the sdhc_1 node but only for the disabled sdhc_2 node.
Third point is more just information:
I got the two 10G aquantia ports running. Luckily u-boot contains the aq_load_fw command. Unfortunately the ethphyfw mtd partition seems empty 
But I found a proper AQR113C ethphyfw image in a zyxel GPL drop and wrote that to the ethphyfw mtd partition. Now aq_load_fw 0 && aq_load_fw 8 succesfully loads the firmware to the phy's.
After a small patch for ssdk with the proper phy id and enabling the AQ PHY kernel config (support for the AQR113C has been added a few days ago (https://github.com/openwrt/openwrt/commit/35b3c4c212588deb49369635571ef63a7413b6f6) the aquantia phy's are working in openwrt 
2 Likes
Hi,
The Qhora looks really interesting with the 10G ports, I have been looking for a discount but they don't drop below 240 or so EUR.
The bootloader always passing the same PARTUUID is stupid, they most likely haven't bothered to implement anything in the bootloader and shifted the logic to the SDK.
Can you provide the u-boot environment content as I wouldn't be surprised if there was a variable telling exactly what it's booting from?
Cause if there is then it can be changed during sysupgrade.
As far as eMMC goes, yeah the VQMMC property is missing, I have added the LDO for SDHCI in the DTS but I have not added it to the SDHCI node.
So you just need to add it to SDHCI node as vqmmc-supply and it should work just fine, currently, it's missing 1.8V despite the DT property telling it explicitly that 1.8V is supposed hence why it doesn't work.
So just add it as:
vqmmc-supply = <&ldo11>;
sdhc_1 and sdhc_2 are actually the same HW, they just intended the sdhc_1 to be used for SD cards, hence the 4-bit width and shdc_2 for eMMC, that's why it's 8-bit wide and has the inline crypto engine enabled.
Nice work on the AQR PHY-s, it should be easy to add support for loading the FW from Linux as well, they for sure already have the FW somewhere in the stock firmware image.
Now, if I could only find one Qhora for a decent price, I would really like to have a 10G copper device
This are the u-boot env vars:
baudrate=115200
boot_1=good
boot_2=good
bootargs=console=ttyMSM0,115200n8
bootcmd=bootipq
bootdelay=2
fdt_high=0x4A400000
fdtcontroladdr=4a96c8d0
flash_type=8
fw_type=router
machid=8010000
netmask=255.255.255.0
soc_version_major=2
soc_version_minor=0
stderr=serial@78B3000
stdin=serial@78B3000
stdout=serial@78B3000
boot_0=good
BMAC=245EBE52E40B
QSN=Q20BQ00758
MN=A03
NMAC=8
PN=X6QHora-301W
SSID=QHora-301W_E40B
MD=2020/11/05 10:00
HV=0x01
PLN=IPQ8072a
MF=0x01
CC=US
VN=0x01
FWMode=Normal
current_entry=0
Regarding emmc:
the vqmmc-supply = <&ldo11>; property alone doesn't help:
sdhci_msm 7824900.sdhci: mmc0: DLL failed to LOCK
[ 2.934269] mmc0: tuning execution failed: -110
[ 2.938974] mmc0: error -110 whilst initialising MMC card
What about the sd_pins they used in the stock DTS?
sd_pins: sd_pins {
mux {
pins = "gpio63";
function = "sd_card";
drive-strength = <8>;
bias-pull-up;
};
};
&sdhc_1 {
pinctrl-0 = <&sd_pins>;
pinctrl-names = "default";
cd-gpios = <&tlmm 63 1>;
};
- Update: i added the sd_pins node and the corresponding pinctrl/cd-gpios properties, but now the emmc isn't even recognized.......
Regarding AQ fw loading in linux: I actually tried that with aq-fw-download util, but this ends up with a "invalid argument" message.
That's why I decided to use u-boot firmware loading mechanism.
Hmm, the current_entry looks interesting.
You don't need the CD GPIO at all since it's not an SD card and cannot be removed.
I cannot really debug this without the board, the only thing I can think of is to remove the feature advertisements from the DTS and let the core negotiate the features
Yes, current_entry controls which kernel/rootfs boots.
I used that in my sysupgrade script to switch partitions.
Regarding emmc: allright thanks anyway. At least emmc is working, maybe we find a way to enable the voltage switch and HS200 in the future.
I will polish the code for the board in the next couple of days and will when open a PR in your repo. Which branch should i use? restart or backports?