Really appreciated !
It boots and works normally, whit out it the boot should have failed and a pain to debrick?
Yes since it contains the partition table
@robimarko with this change, will the installation steps from MusikJunk shown below still work?
That will still work, but it means that you are still relying on U-Boot to load the FW.
Downside is that you are loading the same FW to both AQR-s which isn't ideal as LED config is wrong that way.
So instead of having to modify U-Boot bootargs one can simply flash the AQR firmware extracted from stock FW to 0:ethphyfw1 and 0:ethphyfw2 partitions and then kernel will load the FW, that is what I am using
Appreciate your reply, Thanks a bunch!
I know that you don't care about NSS builds but I want to tell you and to everyone else interested @anom3 @rmandrad that this method of loading AQR stock 10G FW to 0:ethphyfw1 and 0:ethphyfw2 partitions and then kernel loads the FW now finally works on NSS builds too.
Previously it simply failed for 10G-1 port with uniphy autoneg time out!.
Now we have it working finally on NSS builds too, when loaded from NVMEM.
root@QNAP:~# fw_printenv -n bootcmd
bootipq
root@QNAP:~# dd if=/dev/mtd10 | strings | grep v5
v5.4.C CIG WF-1945_0x0 060120 02:47:48
root@QNAP:~# dd if=/dev/mtd11 | strings | grep v5
v5.4.C CIG WF-1945_0x8 060120 02:47:48
Kernel log - finally 10G-1 port works OK on NSS builds too.
Aquantia AQR113C 90000.mdio-1:00: loading firmware version 'v5.4.C CIG WF-1945_0x0 060120 02:47:48' from 'NVMEM'
Aquantia AQR113C 90000.mdio-1:08: loading firmware version 'v5.4.C CIG WF-1945_0x8 060120 02:47:48' from 'NVMEM'
Aquantia AQR113C 90000.mdio-1:08: attached PHY driver (mii_bus:phy_addr=90000.mdio-1:08, irq=POLL)
Aquantia AQR113C 90000.mdio-1:00: attached PHY driver (mii_bus:phy_addr=90000.mdio-1:00, irq=POLL)
...
[ 605.598378] nss-dp 3a001800.dp5 10g-1: PHY Link up speed: 2500
[ 605.598554] br-lan: port 1(10g-1) entered blocking state
[ 605.603131] br-lan: port 1(10g-1) entered forwarding state
[ 1609.203776] nss-dp 3a001800.dp5 10g-1: PHY Link is down
[ 1609.204077] br-lan: port 1(10g-1) entered disabled state
[ 2173.927509] nss-dp 3a001800.dp5 10g-1: PHY Link up speed: 2500
[ 2173.927751] br-lan: port 1(10g-1) entered blocking state
[ 2173.932258] br-lan: port 1(10g-1) entered forwarding state
I've checked the latest QNAP 301w firmware - QHora-301W
2.4.5.032 build 20241029 but there is no newer AQR 10G FW version in it.
1 Like
One question to all using QNAP 301w.
It's about the 3.7GiB eMMC device and particularly the usage of partition 9.
Flash Layout eMMC
GPT fdisk (gdisk) version 1.0.10
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Command (? for help): p
Disk /dev/mmcblk0: 7634944 sectors, 3.6 GiB
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): xxxxxxxx-xxxx-xxxx-xxxxx-xxxxxxxxxxxx
Partition table holds up to 12 entries
Main partition table begins at sector 2 and ends at sector 4
First usable sector is 34, last usable sector is 7634910
Partitions will be aligned on 2-sector boundaries
Total free space is 42941 sectors (21.0 MiB)
Number Start (sector) End (sector) Size Code Name
1 34 32801 16.0 MiB FFFF 0:HLOS
2 32802 65569 16.0 MiB FFFF 0:HLOS_1
3 65570 98337 16.0 MiB FFFF 0:HLOS_2
4 98338 1146913 512.0 MiB FFFF rootfs
5 1146914 2195489 512.0 MiB FFFF rootfs_1
6 2195490 3244065 512.0 MiB FFFF rootfs_2
7 3244066 3252257 4.0 MiB FFFF 0:WIFIFW
8 3252258 3285025 16.0 MiB 8301 reserved
9 3285026 7591969 2.1 GiB FFFF rootfs_data
I'm curious if anyone here uses the extra partition 9 for storage of any additional data.
There is a very interesting recent discussion on the subject starting here.
For example that extra storage (2.1GiB) can potentially be used for saving additional data (like e.g. backups for adblock, statistics, SSH history, rclone config and many others) that survives sysupgrades.
See this Pull Request for additional info.
That would give us really useful possibility for very advanced usage of the hardware.
Did you recover the partition before router reboot? I suppose the 301w won't boot without this partition.
Somehow by luck, I saw the history of what I've typed and realized the mistake and hoped for the router not to reboot/crash, as I had previously a few days where it crashed don't know why.
1 Like
It's safer to use the partition name when erase/write to a partition.
Hello @MusikJunk
I followed the steps described on your post but noticed duplicate entries in dmseg as shown below:
root@OpenWrt:~# dmesg | grep AQ
[ 1.837888] Aquantia AQR113C 90000.mdio-1:00: loading firmware version 'v5.4.C CIG WF-1945_0x0 060120 02:47:48' from 'NVMEM'
[ 13.329276] Aquantia AQR113C 90000.mdio-1:08: loading firmware version 'v5.4.C CIG WF-1945_0x8 060120 02:47:48' from 'NVMEM'
[ 24.948988] Aquantia AQR113C 90000.mdio-1:08: attached PHY driver (mii_bus:phy_addr=90000.mdio-1:08, irq=POLL)
[ 24.974002] Aquantia AQR113C 90000.mdio-1:00: attached PHY driver (mii_bus:phy_addr=90000.mdio-1:00, irq=POLL)
root@OpenWrt:~# fw_printenv -n bootcmd
bootipq
Do you know why I end up with those duplicate?
Anyone here knows what's going on?
They are different - 301w has two 10g ports and on stock QNAP firmware they use two different firmware versions for each separate 10g port.
Following the instructions you probably wrote those two firmwares to the 0:ethphyfw1 and 0:ethphyfw2 partitions and they were loaded from NVMEM.
Just test if both work OK and that's it. See my kernel log above.
Thanks for the reply, both 10G ports work as they should.
I've noticed either of the 10g ports could randomly stop when the ethernet cable is disconnected and reconnected. This behaviour is limited to the 10g ports only and a reboot usually brings the stopped10g port back online. Have you noticed this behaviour too?
What 10g firmware did you use?
Yep, exactly the same (only found the issue initially on 10g-1 but probably present on second port too but my PC is permanently connected to it so I don't reconnect often the cable to it) and I reported it earlier in my older posts.
Will see how it goes now with the usage of the stock firmware loaded from NVMEM.
Previously i've used the mbn firmware for the two 10g ports.
1 Like
In my case, I first discovered the issue sometime in 2022 after flashing openwrt and writing the downloaded firmware [AQR_ethphyfw.mbn] to /dev/mtd10 and loading the fw via U-Boot bootargs.
I had to revert to stock fw due to this issue but noticed the issue still persisted in stock fw. I had to park the router for around one year, assuming I was dealing with hw issue.
After reading comments from @robimarko above, I decided to reflash openwrt on the router with the intension of loading the AQ fw from NVMEM. After installing openwrt today, I noticed that the 10G fw were loaded from U-Boot bootargs which was a bit surprising since I had not modified U-Boot bootargs yet. I concluded that I had forgotten to revert U-Boot bootargs before reverting to stock fw and the router had been loading AQ fw via U-Boot bootargs even when it ran stock fw, probably explains why the intermittent 10g port outage was reproducible in stock fw.
I have now corrected U-Boot bootargs and AQ fw now loaded from NVMEM, the 2 10g ports have been connected for around 4 hours, I have unplugged/plugged the ethernet cable on the 10g ports a number of times and except I'm dealing with pure luck today, I'm leaning towards believing that the intermittent 10g port issues may have been resolved.
I'll continue with my attempts to reproduce the issue and report back here if I'm successful.
EDIT: just noticed that 10g -1 port LED is now yellow when connection speed is 1G and green when connected at 10G. 10g -2 port LED is always green regardless of 1G/10G connection speed.
1 Like
I have the same issue with the 10G ports no having link only after a reboot, and with original fw also, I also believed that's why it was so cheap at purchase years ago. But I think that also only one of them
1 Like
Let's hope this issue was really resolved. I've tried to trigger it by repeatedly disconnecting and connecting the LAN cable over a dozen of times but couldn't force the 10g port to fail at this point. Previously it failed randomly after a few cable disconnects/reconnects and only a reboot could fix it.
Let's see for a couple of days more.
There is a little guide here for using the eMMC partition 9 "rootfs_data" as an extra storage for saving data that should survive sysupgrades.
Credits and appreciation to @Lanchon for the excellent instructions.
I copy it here so it's right on the place but be absolutely sure to read all the Warnings on the PR and be cautious about the consequences.
Partition 9 "rootfs_data" is mostly empty (only 4% occupied) as can be seen.
Seems that this partition was used by the QNAP stock firmware to write to and to save data to it. So if you need to use the stock firmware better don't touch it.
Filesystem Size Used Available Use% Mounted on
/dev/mmcblk0p9 2.0G 79.9M 1.8G 4% /mnt/extra
root@QNAP:~# fstrim -v /mnt/extra
/mnt/extra: 1.9 GiB (2016382976 bytes) trimmed
Then I've made two backups of partiton 9 - as a binary image and as an archive.
root@QNAP:~# gzip -c /dev/mmcblk0p9 > /tmp/p9.img.gz
root@QNAP:~# tar --acls --xattrs --selinux -cpvzf /tmp/p9.tgz /mnt/extra
Of course save the archive files to your PC.
After the backup choose a fs and format the partition. f2fs should work better for write heavy loads. Make sure trim is enabled and fstrim -v works on it.
root@QNAP:~# mkfs.f2fs /dev/mmcblk0p9
F2FS-tools: mkfs.f2fs Ver: 1.16.0 (2023-04-11)
Info: Disable heap-based policy
Info: Debug level = 0
Info: Trim is enabled
Info: Segments per section = 1
Info: Sections per zone = 1
Info: sector size = 512
Info: total sectors = 4306944 (2103 MB)
Info: zone aligned segment0 blkaddr: 512
Info: format version with
"Linux version 6.6.58 (aarch64-openwrt-linux-musl-gcc (OpenWrt GCC 14.2.0 r27829-11038acff2) 14.2.0, GNU ld (GNU Binutils) 2.43.1) #"
Info: [/dev/mmcblk0p9] Discarding device
Info: This device doesn't support BLKSECDISCARD
Info: Discarded 2103 MB
Info: Overprovision ratio = 3.530%
Info: Overprovision segments = 37 (GC reserved = 35)
Info: format successful
root@QNAP:~# fstrim -v /mnt/extra
/mnt/extra: 0 B (0 bytes) trimmed
I rebooted the router and started to configure some packages to use the extra space for data that should survive sysupgrades.
Finally I have it working
I've made OpenWrt sysupgrade and the data in extra storage survived after the reboot.
I really appreciate @Lanchon invaluable help so now this device is almost ready to fly up to the Moon :).
Very Important Note - be sure to read this opened issue by @Lanchon very carefully and fully understand the current situation. And if you decide to use this extra storage make sure you have a backup of the data you store on it.
4 Likes
as said before, this is a bit dangerous because this #9 partition you are using is named rootfs_data. having that name, it should be used as overlay, but a bug in openwrt is causing the partition to be ignored. if the bug is fixed, openwrt may silently overwrite your extra partition and destroy your data.
renaming this partition with gdisk to for example extra will stop this from happening. (but will break sysupgrade when the abovementioned changes are done.)
DO NOT RENAME ANY PARTITIONS OR DO ANY CHANGES TO THE GPT IF YOUR DEVICE HAS SECURE BOOT ENABLED. any changes will result in a hard brick only recoverable via JTAG.
2 Likes
sorry for the noise again,
Trying to use the latest snapshot and load the AQR firmware from flash or user space but it's seems that I face some issues:
took the cld files from original FW used the python3 mkheader.py 0x44000000 0x13 AQR-*cld to aqr.mbn for each of them
wrote them to mtd10 (0x0) / mtd11 (0x8) but it doesn't seem to work
[ 1.830349] Aquantia AQR113C 90000.mdio-1:00: bad firmware CRC: file 0x0000 calculated 0x6d37
[ 1.830401] Aquantia AQR113C 90000.mdio-1:00: firmware loading failed: -22
[ 1.838040] Aquantia AQR113C 90000.mdio-1:00: Direct firmware load for marvell/AQR-G4_v5.4.C-AQR_CIG_WF-1945_0x0_ID44778_VER1630.cld failed with error -2
[ 1.844651] Aquantia AQR113C 90000.mdio-1:00: Falling back to sysfs fallback for: marvell/AQR-G4_v5.4.C-AQR_CIG_WF-1945_0x0_ID44778_VER1630.cld
..
[ 64.486272] Aquantia AQR113C 90000.mdio-1:00: failed to find FW file marvell/AQR-G4_v5.4.C-AQR_CIG_WF-1945_0x0_ID44778_VER1630.cld (-110)
[ 64.490512] Aquantia AQR113C: probe of 90000.mdio-1:00 failed with error -110
..
ls -la /lib/firmware/marvell/
drwxr-xr-x 2 root root 1024 Nov 4 23:51 .
drwxr-xr-x 1 root root 1024 Nov 4 23:57 ..
-rw-r--r-- 1 root root 392194 Oct 29 07:50 AQR-G4_v5.4.C-AQR_CIG_WF-1945_0x0_ID44778_VER1630.cld
-rw-r--r-- 1 root root 392194 Oct 29 07:50 AQR-G4_v5.4.C-AQR_CIG_WF-1945_0x8_ID44776_VER1630.cld
..
md5sum AQR-G4_v5.4.C-AQR_CIG_WF-1945_0x0_ID44778_VER1630.cld
ff9644eabcea5e1ac475efc2e9c9398a AQR-G4_v5.4.C-AQR_CIG_WF-1945_0x0_ID44778_VER1630.cld
md5sum AQR-G4_v5.4.C-AQR_CIG_WF-1945_0x8_ID44776_VER1630.cld
0fc891d29c002d6b82b15624cb6f1ed8 AQR-G4_v5.4.C-AQR_CIG_WF-1945_0x8_ID44776_VER1630.cld
No, do not MBN wrap them, just flash the CLD-s to respective MTD partitions
1 Like