Trying to compile for ipq60xx will fail with:
ERROR: modpost: "qca808x_phy_reset" [build_dir/target-aarch64_cortex-a53_musl/linux-qualcommax_ipq60xx/qca-ssdk-2024.06.13~c451136b/qca-ssdk.ko] undefined!
So, lets fix this by disabling Manhattan switch and PHY support as this is
the new 2.5G quad port switch that is not present on ipq60xx boards.
Fixes: 87a45ea432 ("kernel: qca-ssdk: update 12.5 to 2024-06-13")
Signed-off-by: Robert Marko <robimarko@gmail.com>
There are some new commits, so refresh and update patches.
Some build warnings have been fixed upstream too.
Add backport target/linux/generic/backport-6.6/722-v6.10-dt-bindings-arm-qcom-ids-Add-SoC-ID-for-IPQ5321.patch.
Removed upstream:
[-] qca-ssdk/patches/101-hsl_phy-add-support-for-detection-PSGMII-PHY-mode.patch
[-] qca-ssdk/patches/201-fix-compile-warnings.patch
List of changes:
2024-04-16 -c451136b- qca-ssdk: strip MRPPE code
2024-06-05 -f455a820- [qca-ssdk]: fix enum-int-mismatch warnings
2024-05-31 -bbfc0fa9- Merge "[qca-ssdk]: update eee status of phydev"
2024-05-31 -adbe9dc5- Merge "[qca-ssdk]: support psgmii and uqsxgmii mode of kernel"
2024-05-31 -d06ca777- Merge "[qca-ssdk]: fix 5G issue with the AQR FW that use 5gbaser for 5G speed"
2024-05-31 -c6f539a5- Merge "qca-ssdk: support mrppe pktedit padding functions"
2024-04-29 -c321e2a9- qca-ssdk: support mrppe pktedit padding functions
2024-05-24 -ee6e201e- qca-ssdk: Fix the big endian compile error
2024-05-15 -8c116bb9- [qca-ssdk]: update eee status of phydev
2024-05-20 -f0341a2c- Merge "qca-ssdk: Enable igmp for PPE MINI profile"
2024-05-16 -44a0ce93- qca-ssdk: Enable igmp for PPE MINI profile
2024-05-15 -8b91bbf6- [qca-ssdk]: support psgmii and uqsxgmii mode of kernel
2024-05-14 -7eec1658- [qca-ssdk]: fix 5G issue with the AQR FW that use 5gbaser for 5G speed
2024-05-12 -b9f5ea0e- [qca-ssdk]: ethtool support, do not change wake-up timer when the requested timer is 0
2024-05-09 -5e2c15ed- Merge "[qca-ssdk]: remove check when mht clock enable"
2024-05-09 -a1563b90- Merge "[qca-ssdk] support new sku IPQ5321"
2024-04-23 -f04b7680- [qca-ssdk]: show unknown status when link down
2024-03-22 -33b91b30- [qca-ssdk]: remove check when mht clock enable
2024-04-29 -b6362f2b- Merge "qca-ssdk:fix bug in marina nptv6 iid cal"
2024-04-29 -097033ae- Merge "[qca-ssdk] support cypress uniphy0 connecting MHT switch port0"
2024-04-24 -d45560fd- qca-ssdk:fix bug in marina nptv6 iid cal
2024-04-24 -7d7a42af- qca-ssdk: enable policer counter on low memory profile
2024-04-18 -e36cf6ea- Merge "[qca-ssdk]: change portvlan egress mode initial value as untouched"
2024-04-18 -27817881- Merge "[qca-ssdk]: update the aqr phy supported ability"
2024-04-18 -5a3a693c- Merge "qca-ssdk:support marina nptv6"
2024-04-16 -129fe9b3- Merge "qca-ssdk: support tunnel fields and innner fields inverse"
2024-01-09 -fc8f6abd- qca-ssdk:support marina nptv6
Signed-off-by: Kristian Skramstad <kristian+github@83.no>
Link: https://github.com/openwrt/openwrt/pull/15771
Signed-off-by: Robert Marko <robimarko@gmail.com>
Currently, trying to compile qca-ssdk on macOS will fail in a weird way:
make[6]: *** No rule to make target 'openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-qualcommax_ipq807x/qca-ssdk-2024.04.17~3d060f7a/-n',
needed by 'openwrt/build_dir/target-aarch64_cortex-a53_musl/linux-qualcommax_ipq807x/qca-ssdk-2024.04.17~3d060f7a/qca-ssdk.o'. Stop.
After looking looking at src_list.dep from which KBuild cmd_mod will
generate the list of objects to compile it looked like:
-n /src/adpt/adpt.c
-n
-n
Which was rather suspicous so after comparing to the same file but with
Fedora as host:
/src/adpt/adpt.c src/adpt/hppe/adpt_hppe_fdb.c src/adpt/hppe/adpt_hppe_mib.c
It was clear that echo -n which was used in SSDK-s target.mk was not
working as intented, and it looked like the POSIX only version of echo
was being used which does not honor -n.
So, after failling to reproduce it externally, replacing the call to echo
with a full path to coreutils echo fixed the compilation.
After further debugging, it was determined that SSDK does not honor
CONFIG_SHELL like other kernel modules so it was defaulting to /bin/sh as
the shell make was calling thus calling the /bin/sh built-in echo which on
macOS is the old Bash 3.2 one and it does not respect -n.
So, we have to explicitly pass SHELL=$(BASH) to SSDK to make it use bash
like kernel build or other kernel modules.
This is not an issue since on macOS we always build bash anyway.
Link: https://github.com/openwrt/openwrt/pull/15459
Signed-off-by: Robert Marko <robimarko@gmail.com>
Qualcomm recently committed a new branch (12.5.r2) targeting kernel
6.6. This lets us clean up a few patches particularly the one for
"C22/C45" mdio.
A quick way to see what changed for IPQ807x/6018 was to list the files produced
during build (**/*.o), replace the extension with ".c", and doing a
`git log`.
Filtering from those commits, ones of particular interest are listed
below:
```
2024-04-16 - 0d8f30aa - fix compile issue on hk with linux style build
2024-01-29 - 636464f7 - update the check for port link notify
2024-01-24 - 30c10e7f - enable and disable loopback for xgmac to fix qm stuck issue
2024-01-15 - b6ea10aa - update the the APIs to access switch
2024-01-08 - a1687502 - Disable Tx bridge mac before power off the PHY
2024-01-07 - 3eafb613 - support led configure for malibu phy
2024-01-07 - 5c1af60d - remove phy type check from mac reset when mode switch
2023-12-17 - 79d0b1e8 - remove the PHY access APIs in ssdk_plat.c
2023-12-16 - b2953740 - Update mii read/write functions
2023-12-11 - 37f2eac3 - add port id check for fdb entry
2023-12-11 - d040ca4d - support mdio clause45 on kernel6.6
2023-12-07 - 11494fbc - use barrier mw() during access fdb entry table
2023-12-03 - 8e40a284 - fix build warnings on kernel6.6
2023-11-10 - 10aa0a02 - change speed value when call ssdk_port_link_notify
2023-11-06 - ee4c4a60 - Update mac bitmap value of L3 table on MAC delete
2023-11-03 - 7cd27d39 - support 10G phy common feature
2023-10-30 - 383cc0d2 - fix mactype and mux select issue
2023-10-24 - decf534a - support autoneg status query on force port
2023-10-11 - 111d574e - move ssdk_led_init to regi_init
2023-10-08 - 6b14c142 - the combo port also need to parse SFP pins
2023-10-03 - fb2e0401 - fix port5 interface mode switch issue in erp case
```
Verified with users on QNAP 301W, NBG7815, and myself on Dynalink
DL-WRX36 that everything is functional, including LEDS.
Signed-off-by: Sean Khan <datapronix@protonmail.com>
Link: https://github.com/openwrt/openwrt/pull/15379
Signed-off-by: Robert Marko <robimarko@gmail.com>
When using zst instead of xz, the hash changes. This commit fixes the
hash for packages and tools in core.
Signed-off-by: Paul Spooren <mail@aparcar.org>
The current build procedure always wipes away build files, this is
costly as ssdk is a parent dependency on a whole host of packages and
will always end up rebuilding (and in serial) the whole package.
This patch includes:
1. Module Building Optimization: Instead of creating a temporary
directory (temp) and copying files into it for module building,
the directly invoke the module build command with the
necessary paths. This simplifies the build process
and avoids unnecessary file operations, speeding up
the build process and reducing disk usage.
2. Parallel Build Support: By removing the explicit creation of
the temporary directory and associated file copying operations,
and passing in $(MAKE) $(PKG_JOBS) allows building in parallel.
3. Fix `EXTRA_CFLAGS`: This variable is referenced and set within MAKE_FLAGS,
so doesn't preserve spaces. Should have its defined value quoted.
Signed-off-by: Sean Khan <datapronix@protonmail.com>
Kernel 6.3 has introduced separate C45 read/write operations, and thus
split them out of the C22 operations completely so the old way of marking
C45 reads and writes via the register value does not work anymore.
This is causing SSDK to fail and find C45 only PHY-s such as Aquantia ones:
[ 22.187877] ssdk_phy_driver_init[371]:INFO:dev_id = 0, phy_adress = 8, phy_id = 0x0 phytype doesn't match
[ 22.209924] ssdk_phy_driver_init[371]:INFO:dev_id = 0, phy_adress = 0, phy_id = 0x0 phytype doesn't match
This in turn causes USXGMII MAC autoneg bit to not get set and then UNIPHY
autoneg will time out, causing the 10G ports not to work:
[ 37.292784] uniphy autoneg time out!
So, lets detect C45 reads and writes by the magic BIT(30) in the register
argument and if so call separate C45 mdiobus read/write functions.
Signed-off-by: Robert Marko <robimarko@gmail.com>
With the change in version schema the downloaded files changed, too,
mostly the hash is now prefixed with a tilde `~` instead of a dash `-`.
Since each downloaded archive contains folder with the same name as the
archive, the checksum changed.
Signed-off-by: Paul Spooren <mail@aparcar.org>
Disable Malibu PHY driver in Qca SSDK in favor of the upstream version.
The same workaround are applied and the version upstream is just a drop
in replacement and is well tested from the ipq40xx target.
Also using the upstream version permits further support for LEDs.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
IPQ60xx uses a different codename for SSDK, so lets pass the correct one
as otherwise SSDK asumes we are building for the old MIPS SoC-s.
Signed-off-by: Robert Marko <robimarko@gmail.com>
[ drop outdated commit description info ]
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Disable compiling qca8081 PHY driver in favor of upstream to better
support it and add better control of attached LEDs.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
ISISC is the QCA codename for their Atheros switch family including
AR237, QCA8337 etc.
Since we have qca8k support in OpenWrt, there is no need to have SSDK
support for these switches, and boards that also have external switches
can just use qca8k.
Disable QCA803x PHY support as well, since all of those are supportable
via at803x driver.
Signed-off-by: Robert Marko <robimarko@gmail.com>
PTP and swconfig support in SSDK require kernel modifications we dont need
nor we want to support for now, so move the PTP and swconfig disablement
into general build options as they are not ipq807x specific.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Recent SSDK versions started also parsing the "SoC" variable to identify
the SoC along with the "CHIP_TYPE".
We are not passing "SoC" currently and this leads to components we dont
need like MHT (New 2.5G quad port switch) being compiled and then unused,
so lets just pass the "SoC" as well.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Commit 947b44d ("ipq807x: fix wrong define for LAN and WAN ess mask")
started fixing wrong switch_lan_bmp that defined lan there weren't
actually present. This displayed a fragility in the malibu phy init code
in qca-ssdk.
Add patch to fix this. Also update each DTS with the new required
property if needed.
The new binding malibu_phy_start_addr is required with devices that
place the malibu first PHY referring port1 on a different PHY addres
than 0. The most common configuration is 0 but some device (for example
Qnap 301W) place the malibu PHY at an offset to address 16.
Refer to ipq8074-ess dtsi for extensive description on how to derive
this value.
Quoting the patch detailed description:
The usage of first_phy_addr is EXTREMELY FRAGILE and results
in dangerous results if the OEM (or anyone that by chance try to
implement things in a logical manner) deviates from the default values
from the "magical template".
To be in more details. With QSDK 12.4, some tweaks were done to improve
autoneg and now on every call of port status, the phydev is tried to
add. This resulted in the call and log spam of an error with ports that
are actually not present on the system with qsdk reporting phydev is
NULL. This itself is not an error and printing the error is correct.
What is actually an error from ages is setting generic bitmap reporting
presence of port that are actually not present. This is very common on
OEM where the switch_lan_bmp is always a variant of 0x1e (that on bitmap
results in PORT1 PORT2 PORT3 PORT4 present) or 0x3e (PORT1 PORT2 PORT3
PORT4 PORT5). Reality is that many device are used as AP with one LAN
port or one WAN port. (or even exotic configuration with PORT1 not
present and PORT2 PORT3 PORT4 present (Xiaomi 3600)
With this finding one can say... ok nice, then lets update the DT and
set the correct bitmap...
Again world is a bad place and reality is that this cause wonderful
regression in some case of by extreme luck the first ever connected
port working and the rest of the switch dead.
The problem has been bisected to all the device that doesn't have the
PORT1 declared in any of the bitmap.
With this prefaction in mind, on to the REAL problem.
malibu_phy_hw_init FOR SOME REASON, set a global variable first_phy_addr
to the first detected PHY addr that coincidentally is always PORT1.
PORT1 addr is 0x0. The entire code in malibu_phy use this variable to
derive the phy addrs in some function.
Declaring a bitmap where the PORT1 is missing (or worse PORT4 the only
one connected) result in first_phy_addr set to 1 or whatever phy addr is
detected first setting wrong value all over the init stage.
To fix this, introduce a new binding malibu_first_phy_addr to manually
declare the first phy that the malibu PHY driver should use and permit
to detach it from port bmp detection. The legacy detection is kept for
compatibility reason.
Fixes: #13945
Fixes: 947b44d9ae ("ipq807x: fix wrong define for LAN and WAN ess mask")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Tested-by: Robert Marko <robimarko@gmail.com> # Qnap 301W
Reviewed-by: Robert Marko <robimarko@gmail.com>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
This reverts commit 8cce00bc9d.
The confusion was real and this change cause regression on other
advanced devices that makes actual use of the first_phy_addr value.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Commit 947b44d9ae ("ipq807x: fix wrong define for LAN and WAN ess mask")
started fixing wrong switch_lan_bmp that defined lan there weren't
actually present. This displayed a fragility in the malibu phy init code
in qca-ssdk.
Add patch to fix this.
Quoting the patch detailed description:
I'm very confused by this and to me it's not clear the real usage of
this logic.
From what I can see the usage of this is EXTREMELY FRAGILE and results
in dangerous results if the OEM (or anyone that by chance try to
implement things in a logical manner) deviates from the default values
from the "magical template".
To be in more details. With QSDK 12.4, some tweaks were done to improve
autoneg and now on every call of port status, the phydev is tried to
add. This resulted in the call and log spam of an error with ports that
are actually not present on the system with qsdk reporting phydev is
NULL. This itself is not an error and printing the error is correct.
What is actually an error from ages is setting generic bitmap reporting
presence of port that are actually not present. This is very common on
OEM where the switch_lan_bmp is always a variant of 0x1e (that on bitmap
results in PORT1 PORT2 PORT3 PORT4 present) or 0x3e (PORT1 PORT2 PORT3
PORT4 PORT5). Reality is that many device are used as AP with one LAN
port or one WAN port. (or even exotic configuration with PORT1 not
present and PORT2 PORT3 PORT4 present (Xiaomi 3600)
With this finding one can say... ok nice, then lets update the DT and
set the correct bitmap...
Again world is a bad place and reality is that this cause wonderful
regression in some case of by extreme luck the first ever connected
port working and the rest of the switch dead.
The problem has been bisected to all the device that doesn't have the
PORT1 declared in any of the bitmap.
With this perfection in mind, on to the REAL problem.
malibu_phy_hw_init FOR SOME REASON, set a global variable first_phy_addr
to the first detected PHY addr that coincidentally is always PORT1.
PORT1 addr is 0x0. The entire code in malibu_phy use this variable to
derive the phy addrs in some function.
Declaring a bitmap where the PORT1 is missing (or worse PORT4 the only
one connected) result in first_phy_addr set to 1 or whatever phy addr is
detected first setting wrong value all over the init stage.
To fix this, just drop this variable and hardcode everything to assume
the first phy adrr is ALWAYS 0 and remove calculation and use define for
special case.
With the following change normal switch traffic is restored and ports
function is recovered.
Fixes: #13945
Fixes: 947b44d9ae ("ipq807x: fix wrong define for LAN and WAN ess mask")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Update SSDK version to 12.4, this fixes weird SFP port link up/downs
while there is no SFP module plugged in.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Make use of new toolchain define. TOOLCHAIN_DIR should be used only for
toolchain related packages and for everything else TOOLCHAIN_ROOT_DIR
and other define should be used instead.
Switch to new entry where possible.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Qualcomm has finally started the preparatory work in order to support
kernel 6.1, so lets make use of that and update SSDK 12.4.5.r1 which
allows us to drop almost all of the patches.
Lets also install the forgotten SSDK netlink header.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Now that qualcommax exists as a target and dependencies have been updated
let move ipq807x support to subtarget of qualcommax.
This is mostly copy/paste with the exception of having to update SSDK and
NSS-DP to use CONFIG_TARGET_SUBTARGET.
This is a preparation for later addition of IPQ60xx and IPQ50xx support.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Currently, ipq807x only covers Qualcomm IPQ807x SoC-s.
However, Qualcomm also has IPQ60xx and IPQ50xx SoC-s under the AX WiSoC-s
and they share a lot of stuff with IPQ807x, especially IPQ60xx so to avoid
duplicating kernel patches and everything lets make a common target with
per SoC subtargets.
Start doing that by renaming ipq807x to qualcommax so that dependencies
on ipq807x target can be updated.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Currently, SSDK is rather special in the sense that its not being built as
a proper out of tree module at all but rather like a userspace application
and that involves a lot of make magic which unfortunately broke with make
version 4.4 and newer.
Luckily QCA finally added a way to build SSDK as an out of tree module
and it uses the kernel buildsystem which makes it compile with make 4.4
as well.
So lets backport the support for it and switch to using it.
Signed-off-by: Robert Marko <robimarko@gmail.com>
SSDK is doing everything custom, so trying to use mold and/or LTO
fails, so lets opt-out of using both of them.
Signed-off-by: Robert Marko <robimarko@gmail.com>
[a.heider: split and switch to PKG_BUILD_FLAGS]
Signed-off-by: Andre Heider <a.heider@gmail.com>
Qualcomm SSDK is driver for Qualcomm Atheros switches and PHY-s.
It is quite complicated and used by rest of the Qualcomm SDK stack for
anything switch or PHY related.
It is required for IPQ807x support as currently, there is no better driver
for the built-in switch or UNIPHY.
So, lets add the fixed-up version that supports kernel 5.15 for use on
ipq807x target until a better driver is available.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Signed-off-by: Robert Marko <robimarko@gmail.com>
