Adding OpenWrt support for QNAP QHora-301W

anom3 · 2024-04-06T08:46:50.139Z

big thanks for this.

i've been running both interfaces off the old 301w install instructions, which mention nothing of:

a) different firmware for 10g-1 vs 10g-2
b) recommend writing 5.6.7 to mtd10

thanks!

sppmaster · 2024-04-06T13:44:57.838Z

You found the right instructions to load the stock firmware from NVMEM. There are a few other excellent posts form MusikJunk. One being about extracting the 10G FW from QNAP firmware.
I really wonder why there are two different stock firmwares for each 10G port.
Please let us know if that method works OK for you with NSS builds.
It wasn't working for me neither before nor after the robimarko's fix. 10G-1 port simply doesn't work with NSS builds. I still believe that "just NSS" is not the only reason for this but obviously fixing it requires the knowledge and spare time that just a few people here have.
See this if you haven't already seen it.

anom3 · 2024-04-06T18:07:02.744Z

hey so i got it all figured out and tried flashing one of my 301ws with 5.4.C.

everything initially went fine, removed the aq_load via fw_setenv etc.

devices booted fine, dmesg showed the driver was loading from nvmem (0x0 and 0x8).

i then moved my cable to 10g-1 and it was not working, uniphy autoneg time out!.

i know about the fix, here is the funny thing:

i am still running the last 6.1.82 build, right before qosmio pushed it to 6.6.


root@OPENWRT-SALON:~# uname -a
Linux OPENWRT-SALON 6.1.82 #0 SMP Fri Mar 29 06:22:24 2024 aarch64 GNU/Linux

anyways not a huge deal,

i flashed mtd10 back to the firmware in the initial 301w install guide and added the params back to fw_setenv and everything came back to life.

anom3 · 2024-04-08T14:51:10.545Z

I've been able to load the 10g-1 and 10g-2 firmware using the aq-fw-download command.

I am unsure if this is because of the recent changes to allow NVMEM + file system loading of the firmware but here goes:

The adapter resets (in dmesg) after this and comes back up, so something is happening 10g-2 is the same but 0x0 in the filename + 0 at the end of the command. Note though, I am not 100% sure if I am loading the correct firmware (10g-1 -> 0x8, 10g-2 -> 0x0) or not.

root@OPENWRT-SALON:/etc/scripts# ./aq-fw-download AQR-G4_v5.4.C-AQR_CIG_WF-1945_0x8_ID44776_VER1630.cld 10g-1 8
CRC check good on image file (0x71C0)

Segment Addresses and Sizes as read from the PHY ROM image header:

Primary Iram Address: 0x5400
Primary Iram Size: 0x3c0c8
Primary Dram Address: 0x41600
Primary Dram Size: 0x1e55c


Loading IRAM:

    Byte: 800:
    Byte: 1000:
    Byte: 1800:
    Byte: 2000:
    Byte: 2800:
    Byte: 3000:
    Byte: 3800:
    Byte: 4000:
    Byte: 4800:
    Byte: 5000:
    Byte: 5800:
    Byte: 6000:
    Byte: 6800:
    Byte: 7000:
    Byte: 7800:
    Byte: 8000:
    Byte: 8800:
    Byte: 9000:
    Byte: 9800:
    Byte: A000:
    Byte: A800:
    Byte: B000:
    Byte: B800:
    Byte: C000:
    Byte: C800:
    Byte: D000:
    Byte: D800:
    Byte: E000:
    Byte: E800:
    Byte: F000:
    Byte: F800:
    Byte: 10000:
    Byte: 10800:
    Byte: 11000:
    Byte: 11800:
    Byte: 12000:
    Byte: 12800:
    Byte: 13000:
    Byte: 13800:
    Byte: 14000:
    Byte: 14800:
    Byte: 15000:
    Byte: 15800:
    Byte: 16000:
    Byte: 16800:
    Byte: 17000:
    Byte: 17800:
    Byte: 18000:
    Byte: 18800:
    Byte: 19000:
    Byte: 19800:
    Byte: 1A000:
    Byte: 1A800:
    Byte: 1B000:
    Byte: 1B800:
    Byte: 1C000:
    Byte: 1C800:
    Byte: 1D000:
    Byte: 1D800:
    Byte: 1E000:
    Byte: 1E800:
    Byte: 1F000:
    Byte: 1F800:
    Byte: 20000:
    Byte: 20800:
    Byte: 21000:
    Byte: 21800:
    Byte: 22000:
    Byte: 22800:
    Byte: 23000:
    Byte: 23800:
    Byte: 24000:
    Byte: 24800:
    Byte: 25000:
    Byte: 25800:
    Byte: 26000:
    Byte: 26800:
    Byte: 27000:
    Byte: 27800:
    Byte: 28000:
    Byte: 28800:
    Byte: 29000:
    Byte: 29800:
    Byte: 2A000:
    Byte: 2A800:
    Byte: 2B000:
    Byte: 2B800:
    Byte: 2C000:
    Byte: 2C800:
    Byte: 2D000:
    Byte: 2D800:
    Byte: 2E000:
    Byte: 2E800:
    Byte: 2F000:
    Byte: 2F800:
    Byte: 30000:
    Byte: 30800:
    Byte: 31000:
    Byte: 31800:
    Byte: 32000:
    Byte: 32800:
    Byte: 33000:
    Byte: 33800:
    Byte: 34000:
    Byte: 34800:
    Byte: 35000:
    Byte: 35800:
    Byte: 36000:
    Byte: 36800:
    Byte: 37000:
    Byte: 37800:
    Byte: 38000:
    Byte: 38800:
    Byte: 39000:
    Byte: 39800:
    Byte: 3A000:
    Byte: 3A800:
    Byte: 3B000:
    Byte: 3B800:
    Byte: 3C000:

CRC-16 after loading IRAM: 0x7011

Loading DRAM:

    Byte: 800:
    Byte: 1000:
    Byte: 1800:
    Byte: 2000:
    Byte: 2800:
    Byte: 3000:
    Byte: 3800:
    Byte: 4000:
    Byte: 4800:
    Byte: 5000:
    Byte: 5800:
    Byte: 6000:
    Byte: 6800:
    Byte: 7000:
    Byte: 7800:
    Byte: 8000:
    Byte: 8800:
    Byte: 9000:
    Byte: 9800:
    Byte: A000:
    Byte: A800:
    Byte: B000:
    Byte: B800:
    Byte: C000:
    Byte: C800:
    Byte: D000:
    Byte: D800:
    Byte: E000:
    Byte: E800:
    Byte: F000:
    Byte: F800:
    Byte: 10000:
    Byte: 10800:
    Byte: 11000:
    Byte: 11800:
    Byte: 12000:
    Byte: 12800:
    Byte: 13000:
    Byte: 13800:
    Byte: 14000:
    Byte: 14800:
    Byte: 15000:
    Byte: 15800:
    Byte: 16000:
    Byte: 16800:
    Byte: 17000:
    Byte: 17800:
    Byte: 18000:
    Byte: 18800:
    Byte: 19000:
    Byte: 19800:
    Byte: 1A000:
    Byte: 1A800:
    Byte: 1B000:
    Byte: 1B800:
    Byte: 1C000:
    Byte: 1C800:
    Byte: 1D000:
    Byte: 1D800:
    Byte: 1E000:

0th port: Image load good - mailbox CRC-16 matches (0x646)
Image load good - mailbox CRC-16 matches

anom3 · 2024-04-08T14:57:35.204Z

Btw, the inspiration for this came from:

https://openwrt.org/inbox/toh/netgear/netgear_rax120_nighthawk_ax12

They use the command to load the firmware after OpenWrt is installed.

robimarko · 2024-04-08T15:08:56.783Z

Can I ask what is the benefit of loading from userspace?

anom3 · 2024-04-08T15:10:37.712Z

You are not going to like this because I know your opinion on the NSS build, and I have not tested yet as its daytime and they are all online so kick in the face if I reset the AP...

Using the NSS build loading from NVMEM 10g-1 does not work... I am unsure if it will now though (after loading the fw as above), untested still, as I run this floor on 10g-2 and 10g-1 empty... And like I said, they are all online

anom3 · 2024-04-08T15:12:10.130Z

Ok I took the chance:

[150430.774158] nss-dp 3a001800.dp5 10g-1: PHY Link up speed: 10000
[150430.774330] br-lan: port 5(10g-1) entered blocking state
[150430.779265] br-lan: port 5(10g-1) entered forwarding state

It works.

anom3 · 2024-04-08T15:14:10.428Z

Important, earlier on (same boot, no reboots since) I ran the 2:

ssdk_sh debug phy set 0 0x4004c441 0x8
ssdk_sh debug phy set 8 0x4004c441 0x8

commands.

So maybe this is why it works? Still untested.

sppmaster · 2024-04-08T19:04:01.787Z

Really cool that you made it. I think it's worth trying this method as I still experience this glitch and we better have an alternate method and can utilize the stock FW too.
Can you write the recipe to load the 10G FW from userspace.

lytr · 2024-04-08T19:35:49.035Z

How is AQR firmware loaded in OEM? From u-boot?

sppmaster · 2024-04-08T23:46:45.929Z

AFAIK it's loaded from userspace. See the link above.
@anom3 Did you write a script in init.d and used aq-fw-download tool to load the FW?

anom3 · 2024-04-09T06:24:39.523Z

It still does not work btw...

I mean, everything looks like it should work, but it doesnt:

Install 5.4.C on mtd10 + mtd11.
Load from NVMEM.
So at this point 10g-1 is broken.
Load using aq-fw-download.
Adapter restarts (dmesg) but still broken, 10g-1 autoneg timeout.

sppmaster · 2024-04-10T08:54:52.803Z

Looks expected that it doesn't work when loaded from userspace either. Because I think no matter what way the firmware was loaded (U-Boot, NVMEM or userspace) it should work once loaded.
It's still good that we can now load it from userspace too even though the port actually doesn't work.
Every manufacturer AFAIK load the FW from userspace obviously (for a reason) using scripts to configure/set additional parameters and it works that way.
So if we could figure out what "magic" they do we may be able to finally have it working. All stock firmwares are NSS enabled too.

robimarko · 2024-04-10T08:59:55.321Z

They dont do anything magical, all that those 2 same writes to PHY regs do are:

Enable USXGMII MAC autoneg
Restart PHY autoneg

Both of these are already done by SSDK after FW is loaded

lytr · 2024-04-10T09:20:55.629Z

For AQR114C there is something more in the init script (wan_AQR_monitor.sh): OpenWrt support for Linksys MX8500 - #24 by lytr

sppmaster · 2024-04-10T09:25:28.004Z

@robimarko I've used "magic" just as a metaphor and because I don't have the complete understanding what the script does.
I'm really well aware that you are one of the most knowledgeable persons here especially on this topic too.
That's why, I really appreciate your feedback and clarification here.
Still I think my logic is right and I really wonder why only one of the 10G ports, doesn't work.
Considering the stock firmware limited capabilities compared to what OpenWrt gives us, I really don't believe (don't trust) the stock firmware (10G FW in this case) is definitely better than the (generic) one we use in OpenWrt.

robimarko · 2024-04-10T09:27:43.583Z

Trust me I get what you are trying to say.

robimarko · 2024-04-10T09:36:57.760Z

Ok, so lets try and figure out what they are doing:

0x401ec430 0xc0ef
1E.C430 is Global LED Provisioning 1
0x401ec431 0xc0e0
1E.C431 is Global LED Provisioning 2
0x40070010 0x91e1
7.1 is Autonegotiation Standard Status 1.
No idea what they are trying to set here as most bits are RO or duplicates from another register, only reserved bits are RW
0x40070000 0x3200
7.0 is Autonegotiation Standard Control 1.
They are restarting autonegotation here, required after FW is loaded.
0x4004c441 0x8
4.C441 XAUI RX Reserved Vendor Provisioning 2.
They are enabling USXGMII MAC Autoneg, this is also a standard thing.

The only one that I dont have any docs on is:
0x401e2680 0x1
But given that 1E.2681 is Global Common POR control 2 and it only does resetting my bet is that its another reset register.

sppmaster · 2024-04-10T09:54:12.492Z

I quote myself.

sppmaster:

I see another glitch with 10G ports. If the cable is plugged in and out several times (5-6 times) into any of the 10G ports, the port stops making a connection (LED is off too) and I have to reboot the router in order to recover from this situation.

Do you have any suggestion how can I investigate this?
I suppose not many people do it, plug in and out their cables too often. But as I tested another device I had to do this several times and that's the result. Port simply stops working.
I've found this while testing kernel 6.6 on RB5009 and another possible issue.