We have defaulted to 6.6 for a while so its time to completely drop 6.1
so new devices dont have to include patches for 6.1.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Currently the compile phase of the kernel builds `Image dtbs modules`.
However, none of the dtbs that get built are used for the final image.
This ends up unnecessarily taking CPU cycles and produces a lot of
`WARNINGS` that can lead users to believe there's cause for concern. I
believe the same principle can be applied to other targets.
```
DTC arch/arm64/boot/dts/qcom/msm8996-mtp.dtb
arch/arm64/boot/dts/qcom/msm8996.dtsi:2954.36-2962.5: Warning (clocks_property):
/soc/clock-controller@6400000: Missing property '#clock-cells' in node
/soc/mailbox@9820000 or bad phandle (referred from clocks[2])
DTC arch/arm64/boot/dts/qcom/msm8996-sony-xperia-tone-dora.dtb
arch/arm64/boot/dts/qcom/msm8996.dtsi:2954.36-2962.5: Warning (clocks_property):
/soc/clock-controller@6400000: Missing property '#clock-cells' in node
/soc/mailbox@9820000 or bad phandle (referred from clocks[2])
DTC arch/arm64/boot/dts/qcom/msm8996-sony-xperia-tone-kagura.dtb
arch/arm64/boot/dts/qcom/msm8996.dtsi:2954.36-2962.5: Warning (clocks_property):
/soc/clock-controller@6400000: Missing property '#clock-cells' in node
/soc/mailbox@9820000 or bad phandle (referred from clocks[2])
DTC arch/arm64/boot/dts/qcom/msm8996-sony-xperia-tone-keyaki.dtb
arch/arm64/boot/dts/qcom/msm8996.dtsi:2954.36-2962.5: Warning (clocks_property):
/soc/clock-controller@6400000: Missing property '#clock-cells' in node
/soc/mailbox@9820000 or bad phandle (referred from clocks[2])
DTC arch/arm64/boot/dts/qcom/msm8996-xiaomi-gemini.dtb
arch/arm64/boot/dts/qcom/msm8996.dtsi:2954.36-2962.5: Warning (clocks_property):
/soc/clock-controller@6400000: Missing property '#clock-cells' in node
/soc/mailbox@9820000 or bad phandle (referred from clocks[2])
DTC arch/arm64/boot/dts/qcom/msm8996-xiaomi-natrium.dtb
arch/arm64/boot/dts/qcom/msm8996.dtsi:2954.36-2962.5: Warning (clocks_property):
/soc/clock-controller@6400000: Missing property '#clock-cells' in node
/soc/mailbox@9820000 or bad phandle (referred from clocks[2])
DTC arch/arm64/boot/dts/qcom/msm8996-xiaomi-scorpio.dtb
arch/arm64/boot/dts/qcom/msm8996.dtsi:2954.36-2962.5: Warning (clocks_property):
/soc/clock-controller@6400000: Missing property '#clock-cells' in node
/soc/mailbox@9820000 or bad phandle (referred from clocks[2])
```
Signed-off-by: Sean Khan <datapronix@protonmail.com>
6.6 has been in testing on qualcommax for a while so it should be in a
good shape, but lets default to it to get a wider audience.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Kernel 6.6 has changed the path of WLAN devices as the soc node was updated
to include an adress as well because according to spec it needed one:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/arm64/boot/dts/qcom/ipq8074.dtsi?h=v6.6.21&id=da6aa1111a17db11367817ddc10c5a6c188cdc44
So, this will break existing configuration as device path was changed for
example:
"platform/soc/c000000.wifi" to "platform/soc@0/c000000.wifi"
"platform/soc/c000000.wifi+1" to "platform/soc@0/c000000.wifi+1"
PCIe attached devices also have their path changed, so lets add a script
that will migrate the paths based on the detected running kernel version
so returning to kernel 6.1 will work as well.
Co-developed-by: Sean Khan <datapronix@protonmail.com>
Signed-off-by: Robert Marko <robimarko@gmail.com>
This is an automatically generated commit which aids following Kernel patch history,
as git will see the move and copy as a rename thus defeating the purpose.
See: https://lists.openwrt.org/pipermail/openwrt-devel/2023-October/041673.html
for the original discussion.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Currently, 6 MAC addresses are read from the "boarddata1" partition and set for network interfaces in sequence.
This partition only contains 3 MAC addresses:
1. lan mac
2. wan mac
3. wlan5g mac
As result only lan2, lan3 and lan4 have correct (OUI) MAC addresses.
lan1, lan5 and wan interfaces get MAC addresses with incorrect OUI from random data on "boarddata1" partition.
This commit fix this and use first MAC for lan and second MAC for wan interfaces.
Signed-off-by: Paweł Owoc <frut3k7@gmail.com>
The port 5 of most ipq60xx devices is connected to qca8075,
a few are connected to qca8081. So assume that the default
connection is qca8075 and set the phy mode to psgmii.
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
On Buffalo WXR-5590AX12, some LEDs don't have "function" property and
only "color" property is available for the newer binding of LED on
Linux Kernel.
2e659930d3 ("qualcommax: drop redundant label with new LED
color/function format") removes "label" property from LEDs, then,
multiple "<color>:" (ex.: "white:"/"red:") will be appeared as LED names
and renamed to "<color>:_<num>" ("ex.: "white:_1", "green:_2", ...) by
kernel.
logs:
[ 5.372863] leds-gpio leds: Led white: renamed to white:_1 due to name collision
[ 5.375796] leds-gpio leds: Led red: renamed to red:_1 due to name collision
/sys/class/leds:
root@OpenWrt:/# ls /sys/class/leds/
red: red:power white: white:power
red:_1 red:wlan white:_1 white:wlan
Fix this issue by adding missing "function" property to LEDs on Buffalo
WXR-5950AX12.
Note: there are no appropriate functions in dt-bindings/leds/common.h
for some LEDs, so use the hardcoded strings for them instead.
Fixes: 2e659930d3 ("qualcommax: drop redundant label with new LED color/function format")
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
On QNAP QHora-301W, all LEDs don't have "function" property and only
"color" property is available for the newer binding of LED on Linux
Kernel.
2e659930d3 ("qualcommax: drop redundant label with new LED
color/function format") removes "label" property from LEDs, then,
multiple "<color>:" (ex.: "amber:"/"green:"/"red:") will be appeared as
LED names and renamed to "<color>:_<num>" ("ex.: "green:_1", "green:_2",
...) by kernel.
logs:
[ 4.246494] leds-gpio leds: Led green: renamed to green:_1 due to name collision
[ 4.248978] leds-gpio leds: Led green: renamed to green:_2 due to name collision
[ 4.256345] leds-gpio leds: Led green: renamed to green:_3 due to name collision
[ 4.263770] leds-gpio leds: Led green: renamed to green:_4 due to name collision
[ 4.271105] leds-gpio leds: Led amber: renamed to amber:_1 due to name collision
[ 4.278487] leds-gpio leds: Led green: renamed to green:_5 due to name collision
[ 4.285856] leds-gpio leds: Led amber: renamed to amber:_2 due to name collision
[ 4.293257] leds-gpio leds: Led green: renamed to green:_6 due to name collision
[ 4.300616] leds-gpio leds: Led amber: renamed to amber:_3 due to name collision
[ 4.308002] leds-gpio leds: Led green: renamed to green:_7 due to name collision
[ 4.315384] leds-gpio leds: Led amber: renamed to amber:_4 due to name collision
[ 4.322760] leds-gpio leds: Led green: renamed to green:_8 due to name collision
[ 4.330135] leds-gpio leds: Led amber: renamed to amber:_5 due to name collision
/sys/class/leds:
amber: amber:_4 green:_2 green:_6
amber:_1 green:_5 green:_3 green:_7
amber:_2 green: green:_4 green:_8
amber:_3 green:_1 green:_5 red:
Fix this issue by adding missing "function" (and "function-enumerator")
property to LEDs on QNAP QHora-301W.
Note: there are no appropriate functions in dt-bindings/leds/common.h
for some LEDs, so use the hardcoded strings for them instead.
Fixes: 2e659930d3 ("qualcommax: drop redundant label with new LED color/function format")
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
Netgear WAX214 is a 802.11 ax dual-band AP
with PoE. (similar to Engenius EWS357APV3)
Specifications:
• CPU: Qualcomm IPQ6010 Quad core Cortex-A53
• RAM: 512MB of DDR3
• Storage: 128MB NAND (Macronix MX30UF1G18AC)
• Ethernet: 1x 1G RJ45 port (QCA8072) PoE
• WIFI:
2.4GHz: Qualcomm QCN5022 2x2 802.11b/g/n/ax 574 Mbps PHY rate
5GHz: Qualcomm QCN5052 2x2 802.11a/b/g/n/ac/ax 1201 PHY rate
• LEDs:
4 x GPIO-controlled LEDs
- 1 Power LED (orange)
- 1 LAN LED (blue)
- 1 WIFI 5g LED (blue)
- 1 WIFI 2g LED (blue)
black_small_square Buttons: 1x soft reset
black_small_square Power: 12V DC jack or PoE (802.3af )
An populated serial header is onboard, format is
1.25mm 4p (DF13A-4P-1.25H)
RX/TX is working, bootwait is active, secure boot is not
enabled.
The root password of the stock firmware is unknown,
but failsafe mode can be entered to reset the password.
Installation Instructions:
- obtain serial access
- stop auto boot (press "4", Entr boot command line
interface)
- setenv active_fw 0 (to boot from the primary rootfs,
or set to 1 to boot from the secondary rootfs
partition)
- saveenv
- tftpboot the initramfs image
- bootm
- copy
openwrt-qualcommax-ipq60xx-netgear_wax214-squashfs-factory.ubi
to the device
- write the image to the NAND:
- cat /proc/mtd and look for rootfs partition (should
be mtd11,
or mtd12 if you choose active_fw 1)
- ubiformat /dev/mtd11 -f -y
openwrt-qualcommax-ipq60xx-netgear_wax214-squashfs-factory.ubi
- reboot
Note: the firmware is senao-based. But I was unable to build
a valid senao-header into the image.
Maybe they changed the header format and senaoFW isn't
working any more.
Signed-off-by: Dirk Buchwalder <buchwalder@posteo.de>
Enable DEBUG_BUGVERBOSE by default on qualcommax as without it once BUG()
is called we will not get any output other than
"------------[ cut here ]------------"
which is not usefull at all, so since we dont have kernel size constraints
lets enable it by default.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Add node to support the QUP4 SPI controller inside of IPQ8074.
Some devices use this bus to communicate to a Bluetooth controller.
Signed-off-by: Robert Marko <robimarko@gmail.com>
[port 8ed390a (qualcommax: set correct PHY mode for port 0-4) to ipq60xx]
Port 0-4 have the mode set to SGMII instead of PSGMII. Now that we use
he upstream qca807x driver, this conflicts with the qca SSDK driver
that expects the mode to be PSGMII as for not integrated driver, it does
refer to the real PHY mode.
Update the entry for port 0-4 to PSGMII to solve warning from qca SSDK
in ipq6018-ess.dtsi.
Signed-off-by: Mantas Pucka <mantas@8devices.com>
UNIPHY2 on the WAX630 is connected to a QCA8081 PHY which is only 2.5G and
it does not support using USXGMII at all but rather only SGMII or SGMII+.
Tested-by: Kristian Skramstad <kristian+github@83.no>
Signed-off-by: Robert Marko <robimarko@gmail.com>
Interfaces that have AQR-s attached to them are using USXGMII and not just
the default SGMII.
This was fine until SSDK added some sanity checking and now on Qnap 301W it
would fail with:
[ 24.740197] nss-dp 3a001800.dp5 10g-1 (uninitialized): failed to connect to phy device
[ 24.740264] nss-dp: probe of 3a001800.dp5 failed with error -14
Since this is not Qnap 301W specific lets fix it subtarget wide by
declaring the correct PHY mode for 10G AQR-s.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Interfaces that have AQR-s attached to them are using USXGMII and not just
the default SGMII.
This was fine until SSDK added some sanity checking and now on Qnap 301W it
would fail with:
[ 24.740197] nss-dp 3a001800.dp5 10g-1 (uninitialized): failed to connect to phy device
[ 24.740264] nss-dp: probe of 3a001800.dp5 failed with error -14
So, lets fix 10G AQR ports by declaring the correct PHY mode.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Since we can configure the PHY LED of the qca8081,
add a configuration for this device.
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Reviewed-by: Robert Marko <robimarko@gmail.com>
The dts of Arcadyan AW1000 forgot to convert qca807x PHY
to PHY package implementation. This commit fix it.
Fixes: 0ab4b92 ("qualcommax: convert qca807x PHY to PHY package implementation")
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Reviewed-by: Robert Marko <robimarko@gmail.com>
Convert qca807x PHY to new implementation like for other devices.
Signed-off-by: Paweł Owoc <frut3k7@gmail.com>
Reviewed-by: Robert Marko <robimarko@gmail.com>
Now that Malibu (QCA807x) PHY is using the upstream driver, we dont need
support to define address of the first PHY in package, so remove the
malibu_first_phy_addr DTS property.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Xiaomi AX9000 apply a special PHY LEDs configuration where the unique
green LED for each qca807x PHY port is turned on also on 1000Mbps link.
Apply this special configuration to reflect original implementation.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Xiaomi AX3600 apply a special PHY LEDs configuration where the unique
green LED for each qca807x PHY port is turned on also on 1000Mbps link.
Apply this special configuration to reflect original implementation.
Also enable CONFIG_PHYLIB_LEDS to actually expose the PHY LEDs if
defined in DT.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Convert every qca807x PHY definition in DT to new PHY package
implementation to correctly support applying fixup for the correct PHY
mode.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Port 0-4 have the mode set to SGMII instead of PSGMII. Now that we use
the upstream qca807x driver, this conflicts with the qca SSDK driver
that expects the mode to be PSGMII as for not integrated driver, it does
refer to the real PHY mode.
Update the entry for port 0-4 to PSGMII to solve warning from qca SSDK
in ipq8074-ess.dtsi.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
IPQ807x have integrated qca8074 PHY supported by the upstream qca807x driver.
Enable it to use it instead of the downstream qca SSDK variant.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Commit d737ae99cb ("qualcommax: Fix Buffalo WXR-5950AX12 Ethernet
DTS") reverted the switch bmp to the original OEM definition and
added the malibu_first_phy_addr property.
Problem is that OEM bmp definition is wrong and actually doesn't make sense,
probably caused by copy-paste of the QCOM reference DTS without actually
setting real values. What actually fixed the regression was adding the
malibu_first_phy_addr as without it the MALIBU PHY was actually not
correctly configured and the Aquantia PHY were actually configured as
MALIBU PHY.
Fix all these wrong PHY definition.
The BPM is reverted and the following fixes are applied:
- Drop ESS_PORT1 as it's not actually attached in HW.
- Move ESS_PORT5 AGAIN from lan to wan. This refer to the first Aquantia
PHY that is labelled "wan"
- Move ESS_PORT6 AGAIN from wan to lan. This refer to the second
Aquantia PHY that is labelled "lan1".
Also PHY tag in MDIO node are renumbered to start from 0 following the
tagging standard used also in other dts and the not attached one (reg
0x18 and reg 0x1c) are correctly dropped.
Definition for port@1 in phyinfo is dropped as it doesn't exist.
dp nodes are updated to reference the new PHY tag numbering.
Fixes: d737ae99cb ("qualcommax: Fix Buffalo WXR-5950AX12 Ethernet DTS")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Refresh kernel patches changed from the just introduced ipq60xx new
subtarget.
Patch automatically refreshed with make target/linux/refresh.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
These recipes are generic and will be used for other subtargets, so lets
move them to the target Makefile so they can reused.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Introduce support for the Qualcomm IPQ60xx SoC. WiFi support still has
to be handled and correctly fix hence this is currently marked as
source-only to have a solid base to progress on correct support of this
and hope Upstream QUIC publish newers ath11k drivers for this SoC.
Co-developed-by: Robert Marko <robimarko@gmail.com>
Signed-off-by: Robert Marko <robimarko@gmail.com>
Signed-off-by: Mantas Pucka <mantas@8devices.com>
[ improve commit description, add SoB for Robert, make it source-only ]
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Initial conversion to new LED color/function format
and drop label format where possible. The same label
is composed at runtime.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Drop redundant label with new LED color/function format declared.
This was needed previously when the new format wasn't supported by
leds.sh functions script. Now that is supported this property
can be removed in favor of the new format.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
CONFIG_PHYLIB_LEDS is required in order for phylib to probe the DT for LEDs
attached to PHY-s.
Fixes: 75ad5c2 ("qualcommax: switch to qca8081 upstream PHY driver")
Signed-off-by: Robert Marko <robimarko@gmail.com>
The qca8081 phy needs to set the reset delay time,
otherwise it will not be detected by the mdio bus.
Fixes: 75ad5c2 ("qualcommax: switch to qca8081 upstream PHY driver")
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Switch to qca8081 upstream PHY. Update every device that have LEDs
attached to the qca8081 PHY to follow new way of defining the LEDs and
add original OEM configuration.
Signed-off-by: Christian Marangi <ansuelsmth@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>
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>
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>
Add support for loading Aquantia FW from NVMEM for Zyxel NBG7815
restoring correct functionality of the 10g port.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
By default Linux will default to most IRQ-s being mapped to core 0 which
during high loads will completely swamp the core 0, so lets add the widely
used script that has been floating around forums for a long time to try and
optimize the IRQ mapping a bit.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Enable LED driver LP5562 on HAZE device tree and include its kernel
module package on default package for HAZE.
Signed-off-by: CheWei Chien <chewei.chien@wnc.com.tw>
Some devices (MX42CF) have a wrong MAC address configuration. The correct one is located only on the devinfo partition.
Signed-off-by: Paweł Owoc <frut3k7@gmail.com>
Currently, WiFi interfaces on WXR-5950AX12 / WXR-6000AX12 devices
come up with some MAC addresses inconsistent with vendor and Ethernet
addresses. This adds a hotplug override in order to make it consistent
with what is in u-boot env as well as OAM firmware where 1st radio MAC
is set at Ethernet MAC + 8, and 2nd radio mac at Ethernet MAC + 16.
fw_printenv | grep addr
ethaddr=68:e1:dc:xx:xx:d8
ipaddr=192.168.11.1
wlan0addr=68:e1:dc:xx:xx:e0
wlan1addr=68:e1:dc:xx:xx:e8
wlan2addr=00:00:00:00:00:00
For OEM bootlog and MAC assagnment check
https://openwrt.org/toh/buffalo/wxr-5950ax12#openwrt_uimage_tftp_bootlog
Tested-by: Samir Ibradžić <sibradzic@gmail.com> # Buffalo WXR-6000AX12P
Signed-off-by: Samir Ibradžić <sibradzic@gmail.com>
Linksys MX4200 is a 802.11ax Tri-band router/AP.
Specifications:
* CPU: Qualcomm IPQ8174 Quad core Cortex-A53 1.4GHz
* RAM: 512MB of DDR3
* Storage: 512Mb NAND
* Ethernet: 4x1G RJ45 ports (QCA8075)
* WLAN:
* 2.4GHz: Qualcomm QCN5024 2x2 802.11b/g/n/ax 574 Mbps PHY rate
* 5GHz: Qualcomm QCN5054 2x2@80MHz or 2x2@160MHz 802.11a/b/g/n/ac/ax 2402 PHY rate
* 5GHz: Qualcomm QCN5054 4x4@80MHz or 2x2@160MHz 802.11a/b/g/n/ac/ax 2402 PHY rate
* LED-s:
* RGB system led
* Buttons: 1x Soft reset 1x WPS
* Power: 12V DC Jack
Installation instructions:
Open Linksys Web UI - http://192.168.1.1/ca or http://10.65.1.1/ca depending on your setup.
Login with your admin password. The default password can be found on a sticker under the device.
To enter into the support mode, click on the “CA” link and the bottom of the page.
Open the “Connectivity” menu and upload the squash-factory image with the “Choose file” button.
Click start. Ignore all the prompts and warnings by click “yes” in all the popups.
The Wifi radios are turned off by default. To configure the router, you will need to connect your computer to the LAN port of the device.
Then you would need to write openwrt to the other partition for it to work
- First Check booted partition
fw_printenv -n boot_part
- Then install Openwrt to the other partition if booted in slot 1:
mtd -r -e alt_kernel -n write openwrt-qualcommax-ipq807x-linksys_mx4200v(X)-squashfs-factory.bin alt_kernel
- If in slot 2:
mtd -r -e kernel -n write openwrt-qualcommax-ipq807x-linksys_mx4200v(X)-squashfs-factory.bin kernel
Replace (X) with your model version either 1 or 2
Signed-off-by: Mohammad Sayful Islam <sayf.mohammad01@gmail.com>
Reviewed-by: Robert Marko <robimarko@gmail.com>
`ok` status is obsolete and thus `okay` should be used instead:
spi@78b9000: status:0: 'ok' is not one of ['okay', 'disabled', 'reserved']
Signed-off-by: Petr Štetiar <ynezz@true.cz>
* Revert the switch_lan_bmp and switch_wan_bmp to match the values from
the original device support DTS
* Add specific malibu_first_phy_addr, as it differs from default for
this device
Fixes: #14234
Reviewed-by: Robert Marko <robimarko@gmail.com>
Tested-by: Samir Ibradžić <sibradzic@gmail.com> # Buffalo WXR-6000AX12P
Signed-off-by: Samir Ibradžić <sibradzic@gmail.com>
Hardware specifications:
SoC: Qualcomm IPQ8071A
RAM: 512MB of DDR3
Flash1: Eon EN25S64 8MB
Flash2: MX30UF2G18AC 256MB
Ethernet: 2x 2.5G RJ45 port
Phone: 1x RJ11 port (SPI)
USB: 1x Type-C 2.0 port
WiFi1: QCN5024 2.4GHz
WiFi2: QCN5054 5GHz
Button: Reset, WPS
Flash instructions:
1. Connect the router via serial port (115200 8N1 1.8V)
2. Download the initramfs image, rename it to initramfs.bin,
and host it with the tftp server.
3. Interrupt U-Boot and run these commands:
tftpboot initramfs.bin
bootm
4. After openwrt boots up, use scp or luci web
to upload sysupgrade.bin to upgrade.
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Reviewed-by: Robert Marko <robimarko@gmail.com>
We have a report in the forum, that lan/wan is non-functional
on the EAP102 (https://forum.openwrt.org/t/edgecore-eap102/178449)
Fixing that by swapping label and phy-handle of the dp-nodes and
updating the lan/wan bmp.
Note: the original commiter of the device support seems absent for a
long time in the forum and on the OpenWrt github group.
Tested-by: Antonio Della Selva <antonio.dellaselva@uniurb.it>
Signed-off-by: Dirk Buchwalder <buchwalder@posteo.de>
Reviewed-by: Robert Marko <robimarko@gmail.com>
Hardware specification:
SoC: Qualcomm IPQ8072A
Flash: Toshiba NAND 1GiB
RAM: 1 GiB of DDR3 466 MHz
Ethernet: 4x 1Gbps + 1x 2.5Gbps
WiFi1: QCN5024 2.4GHz ax 4x4
WiFi2: QCN5054 5GHz ax 4x4
Button: WiFi, WPS, Reset
Modem: RG500Q-EA
USB: 1 x USB 3.0
Power: DC 12V 4A
Flash instructions:
1. Download the initramfs image, rename it to
initramfs.bin, and host it with tftp server.
2. Interrupt U-Boot and run these commands:
tftpboot initramfs.bin
bootm
3. After openwrt boots up, use scp or luci web
to upload sysupgrade.bin to upgrade.
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Reviewed-by: Robert Marko <robimarko@gmail.com>
Replace blanks with tabs, also sort base-files alphabetically.
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Reviewed-by: Robert Marko <robimarko@gmail.com>
Correct oob size from 128 to 256 for Toshiba TH58NYG3S0HBAI4 flash.
Since it is not ONFI compliant NAND, the model name cannot be read
from anywhere, add a static NAND ID entry to correct this.
However, the NAND ID of this flash is inconsistent with the datasheet.
The actual NAND ID is only 4 ID bytes, the last ID byte is missing.[1]
Maybe this flash is counterfeit, or maybe it's another problem.
Another Toshiba flash had the same problem before. Refer to commit
a83dc6b ("kernel: move Toshiba-TC58NVG0S3H patch to ipq40xx"), put
the patch into qualcommax target to avoid affecting other devices.
The patch is verified on Arcadyan AW1000.
[1] Datasheet available at (the ID table is on page 50):
https://europe.kioxia.com/content/dam/kioxia/newidr/productinfo/datasheet/201910/DST_TH58NYG3S0HBAI4-TDE_EN_31565.pdf
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Reviewed-by: Robert Marko <robimarko@gmail.com>
DP nodes live under the soc node, and since soc is a simple bus it requires
node adresses to be present.
So, simply add the node addreses to avoid the following dtc warning:
Warning (unit_address_vs_reg): /soc/dp1: node has a reg or ranges property, but no unit name
Warning (unit_address_vs_reg): /soc/dp2: node has a reg or ranges property, but no unit name
Warning (unit_address_vs_reg): /soc/dp3: node has a reg or ranges property, but no unit name
Warning (unit_address_vs_reg): /soc/dp4: node has a reg or ranges property, but no unit name
Warning (unit_address_vs_reg): /soc/dp5: node has a reg or ranges property, but no unit name
Warning (unit_address_vs_reg): /soc/dp6: node has a reg or ranges property, but no unit name
Warning (unit_address_vs_reg): /soc/dp5-syn: node has a reg or ranges property, but no unit name
Warning (unit_address_vs_reg): /soc/dp6-syn: node has a reg or ranges property, but no unit name
Signed-off-by: Robert Marko <robimarko@gmail.com>
It seems that ESS dt-bindings somehow ended up with Windows line endings,
this is obviously incorrect, so lets convert it to UNIX endings.
Signed-off-by: Robert Marko <robimarko@gmail.com>
In fixing ipq8074 WAX630 dts, there was a typo in the switch lan bmp.
Fix it to fix compilarion error.
Fixes: f3cd4bfb7f ("ipq807x: fix multiple error on ESS switch port define")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Fix multiple error on ESS switch port define.
- Fix wrong switch CPU and WAN bmp define. (many times wan port are
actually set in lan mask and lan port in wan mask)
- Renumber phyinfo port, use port_id instead of phy_address as it
doesn't make sense using that for port enumeration
- Drop additional port for devices that have them not connected.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Every board in qualcommax is using the same BM and TM switch tick modes, so
instead of specifying them in each board lets just set them in the ESS DTSI
directly.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Now that we have the MAC modes defined in DT bindings, lets replace all of
the raw hex values with defines.
While we are here, we can drop the disabled UNIPHY-s as that is the default
value in the ESS DTSI.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Every board that has the switch enabled needs to have MAC modes defined for
all 3 UNIPHY instances.
So, instead of having to at least put the disabled MAC mode for UNIPHY-s
let disable them by default and then boards can override it.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Since every board needs to define the correct MAC modes, it makes sense
to document the allowed hex values with a humanly readable name.
So, lets document all of the allowed MAC modes from SSDK 12.4 as bindings,
so later we can replace all of the hex values in DTS-es with these.
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>
switch_lan_bmp and switch_wan_bmp have wrong values and now cause
problems with the new version of the qca-ssdk.
Fix the wrong entry and drop the redundant switch_cpu_bmp.
Also introduce some convenient define to better understand values in
this map.
Fixes: eea264fead ("kernel: qca-ssdk: update to 12.4")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Tested-by: Robert Marko <robimarko@gmail.com> # Dynalink AX3600 and Qnap 301W
Reviewed by: Robert Marko <robimarko@gmail.com>
SSDK has switched to using the upstream SMEM helper to get the SoC ID and
then look it up in the QCA SMEM ID header, so we need these in order for
SSDK to compile as they are currently undefined.
Signed-off-by: Robert Marko <robimarko@gmail.com>
It seems that I forgot one zero in the patch numbering while marking these
as backports, so lets fix it.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Currently, qualcommax target contains the full kernel config for the
ipq807x subtarget, but since I am working on ipq60xx as well it makes
sense to split out the ipq807x specific kernel options to subtarget
config.
ipq60xx will use the same approach and use subtarget config.
Should result in the same end kernel config, verified by comparing the
generated kernel .config.
Signed-off-by: Robert Marko <robimarko@gmail.com>
This makes it possible to build the ipq807x netgear-wax218 without initramfs - which is required for downstream projects (gluon)
Signed-off-by: Florian Maurer <f.maurer@outlook.de>
```
Specifications:
* CPU: Qualcomm IPQ8074A, SoC Version: 2.0, Quad core 1651 MHz
* RAM: 1 GiB of DDR3 466 MHz
* Flash: NAND 512 MiB (Winbond W29N04GZ)
* 6 RGB LEDs: Power, LAN1, LAN2, 2.4GHz, 5GHz H and 5GHz L
* UART: One 4-pin populated header next to the heatsink and a chip.
GND RXD TXD, beginning from the external antennas. 115200n8.
Lan:
* One 100/1000/2.5GBASE-T Gigabit Ethernet 802.3bt/at
* One 100/1000 Gigabit Ethernet
Wlan:
* 4x4 in 2.4GHz : 802.11b/g/n/ax
* 4x4 in 5.0GHz L: 802.11a/n/ac/ax
* 4x4 in 5.0GHz H: 802.11a/n/ac/ax
* OFDM and OFDMA
* Bidir and MU-MIMO
* Internal antenna 2.86/4.41/4.98 dBi (2.4GHz/5GHz L/5GHz H)
Power:
* 802.3bt/at 30.1W
* DC 12V/3.5A
Mounting: Wall and ceiling
```
```
1. Download the OpenWrt initramfs image. Copy the image to a TFTP server
2. Connect to the console on the AP, and connect the LAN port to your LAN
3. Stop auto boot to get to U-boot shell, interrupt the autoboot process by pressing '0' when prompted
4. Set active_fw in env
4. Set active_fw in env
# setenv active_fw 1
5. Transfer the initramfs image with TFTP
# setenv serverip 192.168.1.10 (IP of TFTP server host)
# setenv ipaddr 192.168.1.1 (IP used by the router for getting the image, must be in the same subnet as the TFTP host)
# tftpboot openwrt-qualcommax-ipq807x-netgear_wax630-initramfs-uImage.itb
6. Reboot and load the image
# bootm
7. SCP factory image to the AP
# scp openwrt-qualcommax-ipq807x-netgear_wax630-squashfs-factory.ubi root@192.168.1.1:/tmp/
8. Connect to device using SSH (use the LAN port)
9. Flash squashfs-factory.ubi from within the initramfs instance of OpenWRT
Before you flash, please check your mtd partitions where mtdX is the right mtd rootfs partition.
# cat /proc/mtd (To check MTD partitions)
# ubiformat /dev/mtd18 -y -f /tmp/openwrt-qualcommax-ipq807x-netgear_wax630-squashfs-factory.ubi
10. Set active_fw to 0
# /usr/sbin/fw_setenv active_fw 0
11. Reboot the AP and your done
# reboot
```
Reviewed-by: Robert Marko <robimarko@gmail.com>
Signed-off-by: Kristian Skramstad <kristian+github@83.no>
As requested by the maintainers, the order for the WAX family
should be alphabetically. WAX620 is now after WAX218.
Files changed:
+ipq807x.mk
+01_leds
No changes to the content.
Signed-off-by: Kristian Skramstad <kristian+github@83.no>
IPQ8074 CPUFreq NVMEM support has finally landed upstream, so lets use the
upstreamed version.
This has a benefit of also supporting IPQ8174 (Oak) family for which SMEM
SoC ID-s were also upstreamed.
Signed-off-by: Robert Marko <robimarko@gmail.com>
SBL will configure IPQ807x cores to boot at 800MHz as a safe default
frequency that is provided by GPLL0, but GPLL0 is not currently configured
as a possible parent in the APSS clock driver not being passed to it via
DTS which will then cause the kernel to not properly identify the current
CPU frequency during booting and will think that CPU is currently at XO
frequency of 19.2MHz instead of 800MHz cores are actually at and print:
cpufreq: cpufreq_online: CPU0: Running at unlisted initial frequency: 19200 KHz, changing to: 1017600 KHz
So, lets import patches pending upstream to prevent GPLL scaling and feed
the GPLL0 clock to APSS clock driver so we get:
cpufreq: cpufreq_online: CPU0: Running at unlisted initial frequency: 800000 KHz, changing to: 1017600 KHz
This is mostly cosmetic fix, but with all of the possible SBL and FW
versions there could be edge cases resolved by this and not scaling GPLL-s
anymore.
Signed-off-by: Robert Marko <robimarko@gmail.com>
