qualcommax: 301w: enable using kernel for AQR firmware loadin #14484
+101
−3
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
kernel
robimarko
force-pushed
the
qnap-aqr-fw
branch
2 times, most recently
from
5dc4057 to
78de4a0
Compare
Now that we have support for firmware loading via the kernel driver, it makes sense to populate the firmware name as well, so if its present the driver can load it. In later patches, loading the FW via NVMEM will be added as well. Signed-off-by: Robert Marko <robimarko@gmail.com>
It seems that the reset GPIO-s defined for the two AQR PHY-s are actually reversed. Manually testing confirmed that GPIO44 is actually reset GPIO of AQR at 0, while GPIO59 is reset of AQR at 8: root@OpenWrt:~# mdio 9* DEV PHY-ID LINK 0x00 0x00000000 down 0x08 0x00000000 down 0x10 0x004dd0b1 down 0x11 0x004dd0b1 down 0x12 0x004dd0b1 down 0x13 0x004dd0b1 up 0x14 0x004dd0b1 down 0x15 0x04820a05 down root@OpenWrt:~# gpioset gpiochip0 44=0 root@OpenWrt:~# mdio 9* DEV PHY-ID LINK 0x08 0x00000000 down 0x10 0x004dd0b1 down 0x11 0x004dd0b1 down 0x12 0x004dd0b1 down 0x13 0x004dd0b1 up 0x14 0x004dd0b1 down 0x15 0x04820a05 down root@OpenWrt:~# gpioset gpiochip0 44=1 root@OpenWrt:~# mdio 9* DEV PHY-ID LINK 0x00 0x00000000 down 0x08 0x00000000 down 0x10 0x004dd0b1 down 0x11 0x004dd0b1 down 0x12 0x004dd0b1 down 0x13 0x004dd0b1 up 0x14 0x004dd0b1 down 0x15 0x04820a05 down root@OpenWrt:~# gpioset gpiochip0 59=0 root@OpenWrt:~# mdio 9* DEV PHY-ID LINK 0x00 0x00000000 down 0x10 0x004dd0b1 down 0x11 0x004dd0b1 down 0x12 0x004dd0b1 down 0x13 0x004dd0b1 up 0x14 0x004dd0b1 down 0x15 0x04820a05 down root@OpenWrt:~# gpioset gpiochip0 59=1 root@OpenWrt:~# mdio 9* DEV PHY-ID LINK 0x00 0x00000000 down 0x08 0x00000000 down 0x10 0x004dd0b1 down 0x11 0x004dd0b1 down 0x12 0x004dd0b1 down 0x13 0x004dd0b1 up 0x14 0x004dd0b1 down 0x15 0x04820a05 down Signed-off-by: Robert Marko <robimarko@gmail.com>
In order to get rid of having to modify U-boot bootcmd and having U-boot load the Aquantia PHY-s firmware lets use some of the free space on SPI-NOR to add a second ethphyfw partition and be able to load AQR FW via NVMEM cells. Signed-off-by: Robert Marko <robimarko@gmail.com>
|
Currently using the QNAP stock 10G Firmware with (officially unsupported) NSS enabled community builds brakes the 10G_1 port connection. Cannot get/lease IP address. See this. Doesn't work with 2.5G mode either. Don't use on NSS builds at least for now! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, AQR firmware is loaded via U-Boot as previously there was no support for the kernel to load the firmware, however, that has recently changed and with the MDIO frequency fixed as well we can now rely on the kernel to load the firmware instead.
This has multiple benefits:
This PR allows loading the firmware via 2 ways:
/lib/firmware0:ethphyfw1and0:ethphyfw2partitions and then they will be loaded via NVMEM.