[OpenWrt-Devel] [PATCH] ramips: Add support for Phicomm PSG1208
This patch adds support for Phicomm PSG1208.This is a router with MT7620A SoC
with 8M flash and 64M ram.
The WPS led is uesd as status_led because the power light can't be controlled
with GPIO.
It seems that the 5g wifi led is connected to MT7612E and it can't be
controlled with GPIO too.
Signed-off-by: Chuanhong Guo
---
target/linux/ramips/base-files/etc/board.d/01_leds | 3 +
.../linux/ramips/base-files/etc/board.d/02_network | 1 +
target/linux/ramips/base-files/etc/diag.sh | 3 +-
target/linux/ramips/base-files/lib/ramips.sh | 3 +
.../ramips/base-files/lib/upgrade/platform.sh | 1 +
target/linux/ramips/dts/PSG1208.dts| 114 +
target/linux/ramips/image/Makefile | 2 +
target/linux/ramips/mt7620/profiles/phicomm.mk | 16 +++
8 files changed, 142 insertions(+), 1 deletion(-)
create mode 100644 target/linux/ramips/dts/PSG1208.dts
create mode 100644 target/linux/ramips/mt7620/profiles/phicomm.mk
diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds
b/target/linux/ramips/base-files/etc/board.d/01_leds
index b10f5f1..d1b4e15 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -208,6 +208,9 @@ pbr-m1)
ucidef_set_led_default "power" "power" "$board:blue:power" "1"
ucidef_set_led_default "sys" "sys" "$board:blue:sys" "1"
;;
+psg1208)
+ set_wifi_led "$board:white:wlan2g"
+ ;;
px-4885)
set_wifi_led "$board:orange:wifi"
set_usb_led "$board:blue:storage"
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
b/target/linux/ramips/base-files/etc/board.d/02_network
index 9853729..0121e51 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -74,6 +74,7 @@ ramips_setup_interfaces()
mzk-w300nh2|\
oy-0001|\
pbr-m1|\
+ psg1208|\
sap-g3200u3|\
wf-2881|\
whr-300hp2|\
diff --git a/target/linux/ramips/base-files/etc/diag.sh
b/target/linux/ramips/base-files/etc/diag.sh
index 59c5965..c7c7815 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -75,7 +75,8 @@ get_status_led() {
dir-645)
status_led="$board:green:wps"
;;
- cf-wr800n)
+ cf-wr800n|\
+ psg1208)
status_led="$board:white:wps"
;;
cy-swr1100|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh
b/target/linux/ramips/base-files/lib/ramips.sh
index aed8350..c6c32fe 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -292,6 +292,9 @@ ramips_board_detect() {
*"PBR-M1")
name="pbr-m1"
;;
+ *"PSG1208")
+ name="psg1208"
+ ;;
*"PSR-680W"*)
name="psr-680w"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 78edd22..5575b4c 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -84,6 +84,7 @@ platform_check_image() {
nw718|\
oy-0001|\
pbr-m1|\
+ psg1208|\
psr-680w|\
px-4885|\
re6500|\
diff --git a/target/linux/ramips/dts/PSG1208.dts
b/target/linux/ramips/dts/PSG1208.dts
new file mode 100644
index 000..c3be8ef
--- /dev/null
+++ b/target/linux/ramips/dts/PSG1208.dts
@@ -0,0 +1,114 @@
+/dts-v1/;
+
+/include/ "mt7620a.dtsi"
+
+/ {
+ compatible = "PSG1208", "ralink,mt7620a-soc";
+ model = "Phicomm PSG1208";
+
+ palmbus@1000 {
+ gpio1: gpio@638 {
+ status = "okay";
+ };
+
+ gpio3: gpio@688 {
+ status = "okay";
+ };
+
+ spi@b00 {
+ status = "okay";
+
+ m25p80@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ reg = <0 0>;
+ linux,modalias = "m25p80", "en25q64";
+ spi-max-frequency = <1000>;
+
+ partition@0 {
+ label = "u-boot";
+ r
Re: [OpenWrt-Devel] [PATCH] ath79: add support for tplink tl-wdr3600 modified with 16M flash
Hi! On Fri, Mar 15, 2019 at 2:42 PM Russell Senior wrote: > > > To modify a WDR3600 with 16MB flash, you will need an external SPI programmer > and soldering tools. First, obtain a copy of the starting contents either > with > the external programmer or from commands in OpenWrt: Unfortunately OpenWrt never accepts device support requiring hardware modifications. I think part of the reason is that there are too many possible variants when it comes to hardware modifications and all those variants will make users confused. Some maintainers talked about this problem in a past thread but I can't find it now. Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: add support for GL.iNet GL-X1200
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h
> b/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h
> index 9722744..f5c3e3d 100644
> --- a/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h
> +++ b/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h
> @@ -138,6 +138,7 @@ enum ath79_mach_type {
> ATH79_MACH_GL_INET, /* GL-CONNECT GL-INET */
> ATH79_MACH_GL_MIFI, /* GL-MIFI support */
> ATH79_MACH_GL_USB150, /* GL.iNet GL-USB150 */
> + ATH79_MACH_GL_X1200,/* GL.iNet GL-X1200 */
> ATH79_MACH_GS_MINIBOX_V1, /* GainStrong MiniBox V1.0 */
> ATH79_MACH_GS_MINIBOX_V32, /* Gainstrong MiniBox V3.2 */
> ATH79_MACH_GS_OOLITE_V1,/* GainStrong Oolite V1.0 */
> diff --git a/target/linux/ar71xx/generic/config-default
> b/target/linux/ar71xx/generic/config-default
> index 25b58ae..de7586f 100644
> --- a/target/linux/ar71xx/generic/config-default
> +++ b/target/linux/ar71xx/generic/config-default
> @@ -99,6 +99,7 @@ CONFIG_ATH79_MACH_GL_DOMINO=y
> CONFIG_ATH79_MACH_GL_INET=y
> CONFIG_ATH79_MACH_GL_MIFI=y
> CONFIG_ATH79_MACH_GL_USB150=y
> +CONFIG_ATH79_MACH_GL_X1200=y
> CONFIG_ATH79_MACH_GS_MINIBOX_V32=y
> CONFIG_ATH79_MACH_GS_OOLITE_V1=y
> CONFIG_ATH79_MACH_GS_OOLITE_V5_2=y
> diff --git a/target/linux/ar71xx/image/generic.mk
> b/target/linux/ar71xx/image/generic.mk
> index 30a8b34..3b16fef 100644
> --- a/target/linux/ar71xx/image/generic.mk
> +++ b/target/linux/ar71xx/image/generic.mk
> @@ -543,6 +543,19 @@ define Device/gl-usb150
> endef
> TARGET_DEVICES += gl-usb150
>
> +define Device/gl-x1200
> + DEVICE_TITLE := GL.iNet GL-X1200
> + DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-storage \
> + kmod-ath10k ath10k-firmware-qca9888
> + BOARDNAME := GL-X1200
> + SUPPORTED_DEVICES := gl-x1200
> + IMAGE_SIZE := 16000k
> + MTDPARTS := spi0.0:256k(u-boot)ro,64k(u-boot-env),64k(art)ro,-(firmware)
> + IMAGE/sysupgrade.bin := append-kernel | pad-to (BLOCKSIZE) | \
> + append-rootfs | pad-rootfs | append-metadata | check-size
> (IMAGE_SIZE)
> +endef
> +TARGET_DEVICES += gl-x1200
> +
> define Device/lan-turtle
>$(Device/tplink-16mlzma)
>DEVICE_TITLE := Hak5 LAN Turtle
> --
> 2.7.4
>
>
>
Regards,
Chuanhong Guo
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/4] ath79: add QCA955x SGMII link loss workaround
Hi! On Fri, May 31, 2019 at 9:34 PM Christian Lamparter wrote: > > Not to be a party pooper. The ag71xx is well on its way to upstream. > https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/drivers/net/ethernet/atheros/ag71xx.c?id=d51b6ce441d356369387d20bc1de5f2edb0ab71e > > So sadly this all would need to be somehow upstreamed first and then > backported again. *sight* :( > The upstream driver is pretty much broken on every SoCs with external PHY/switch. Getting every ath79 SoC working with that driver is already a headache. I think we should just keep maintaining our ag71xx driver until someone having a pile of ath79 routers get that driver working. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/4] ath79: add QCA955x SGMII link loss workaround
On Sat, Jun 1, 2019 at 12:26 AM Christian Lamparter wrote: > > On Friday, May 31, 2019 4:44:50 PM CEST Chuanhong Guo wrote: > > Hi! > > > > On Fri, May 31, 2019 at 9:34 PM Christian Lamparter > > wrote: > > > > > > Not to be a party pooper. The ag71xx is well on its way to upstream. > > > https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/drivers/net/ethernet/atheros/ag71xx.c?id=d51b6ce441d356369387d20bc1de5f2edb0ab71e > > > > > > So sadly this all would need to be somehow upstreamed first and then > > > backported again. *sight* :( > > > > > The upstream driver is pretty much broken on every SoCs with external > > PHY/switch. Getting every ath79 SoC working with that driver is > > already a headache. > > > > I think we should just keep maintaining our ag71xx driver until > > someone having a pile of ath79 routers get that driver working. > > Well, look what happend to ar71xx then. The development on it is being > defered in favor of the upstream ath79 dts. So what do you think will > happen to the special out-of-tree ag71xx drivers now? That happens after we got ath79 target working. There is a period of time when ath79 has broken wireless support, during which ar71xx patches were still accepted. Author of upstream ag71xx driver did a 'rework' of OpenWrt ag71xx driver dropped all mii interface configuration stuff. Unless someone patches it back, it won't work on qca9558 in this case. To upstream this particular patch, we need to: 1. patch mii interface configuration code back. (Somehow we named it PLL and the author thought it's a clock register that doesn't belong to ethernet driver.) 2. patch the miscellaneous ethernet-related configuration code back. (gmac-config in our driver which is used by this patch.) Our current code for both of them will have little chance being accepted by upstream. Since this patch depends on gmac-config that doesn't exist in upstream ag71xx yet and we won't be using the upstream driver in upcoming 19.x release, I think it's fine to have this problem fixed in our driver and then port it upstream (likely to be a rework) with gmac-config code. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] sysupgrade: Cross-flashing NOR/NAND proof of concept
Hi! On Wed, Jun 12, 2019 at 8:42 AM Jeff Kletsky wrote: > > From: Jeff Kletsky > * The kernel and software for both the NOR- and NAND-resident > variants need to be able to read/write raw MTD as well as UBI. > > * The existing sysupgrade paths already prevent flashing of a > NOR-intended image onto a NAND-based device, as well as the other > way around. As such, even if a approach like this is accepted > after these board names are "in the wild", sysupgrade will be > "safe" on "old" builds against future additions to SUPPORTED_DEVICES. Why would someone do such a cross-flashing at the first place? If you want to recover the firmware in SPI NAND with a firmware in SPI NOR, You could just flash a initramfs image of the NAND variant into NOR flash. (And vice versa) > > * The MTD partitioning for both variants need to define both NOR and > NAND partitioning GL-AR300M has an NOR-only variant and by adding SPI NAND node into the NOR variant you'll add some unnecessary error messages into kernel log. Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: mt7621: Add new device AsiaRF AP7621-001
ere.
Just drop the above 4 lines so that one "leds" node contains both of your leds.
> +
> + wlan0 {
> + label = "ap7621-001:orange:wlan0";
> + gpios = <&gpio0 12 GPIO_ACTIVE_LOW>;
> + };
> + };
> +};
> +
> +&sdhci {
> + status = "okay";
> +};
> +
> +&spi0 {
> +status = "okay";
> +
> +m25p80@0 {
This one could be renamed to "flash@0"
> +#address-cells = <1>;
> +#size-cells = <1>;
> +compatible = "jedec,spi-nor";
> +reg = <0>;
> +spi-max-frequency = <1000>;
10MHz is a pretty low spi frequency. You could try if a higher
frequency (e.g. 40MHz) works for you.
> +m25p,chunked-io = <32>;
This is for an old m25p80 driver hack that has been replaced. This
line can be dropped.
> +
> +partition@0 {
> +label = "u-boot";
> +reg = <0x0 0x3>;
> +read-only;
> +};
> +
> +// partition@3 {
> +// label = "u-boot-env";
> +// reg = <0x3 0x1>;
> +// };
These comment lines should be dropped.
> +
> +partition@3 {
> +label = "u-boot-env";
> +reg = <0x3 0x2000>;
> +};
> +
> +partition@32000 {
> +label = "2860";
> +reg = <0x32000 0x4000>;
> +};
> +
> +partition@36000 {
> +label = "rtdev";
> +reg = <0x36000 0x2000>;
> +};
> +
> +partition@38000 {
> +label = "Reserve";
> +reg = <0x38000 0x8000>;
> +};
> +
> +factory: partition@4 {
> +label = "factory";
> +reg = <0x4 0x1>;
> +read-only;
> +};
> +
> +firmware: partition@5 {
> +label = "firmware";
Add a compatible string here:
compatible = "denx,uimage";
and then you don't need CONFIG_MTD_SPLIT_FIRMWARE=y which is also deprecated.
> +reg = <0x5 0xfa>;
> +};
> +
> +partition@ff {
> +label = "nvram";
> +reg = <0xff 0x1>;
> +};
> +};
> +};
> +
> +&pcie {
> + status = "okay";
> +
> + pcie0 {
> + wifi@14c3,7662 {
> + compatible = "pci14c3,7662";
> + reg = <0x 0 0 0 0>;
> + mediatek,mtd-eeprom = <&factory 0x>;
> +// ieee80211-freq-limit = <240 250>;
Just drop this line if it isn't needed.
> + };
> + };
> +
> + pcie1 {
> + wifi@14c3,7662 {
> + compatible = "pci14c3,7662";
> + reg = <0x 0 0 0 0>;
> + mediatek,mtd-eeprom = <&factory 0x8000>;
> +// ieee80211-freq-limit = <500 600>;
same as above.
> + };
> + };
> +};
> +
> +ðernet {
> + mtd-mac-address = <&factory 0xe000>;
> + mediatek,portmap = "w";
> +};
> +
> +&pinctrl {
> + state_default: pinctrl0 {
> + gpio {
> + ralink,group = "wdt", "jtag" ;
gpio11 12 and 18 is used, which belongs to uart2 and wdt group.
So this line should be:
ralink,group = "uart2", "wdt";
> + ralink,function = "gpio";
> + };
> + };
> +};
> +
> diff --git a/target/linux/ramips/image/mt7621.mk
> b/target/linux/ramips/image/mt7621.mk
> index 2eb7feb5bf..29e4111ce8 100644
> --- a/target/linux/ramips/image/mt7621.mk
> +++ b/target/linux/ramips/image/mt7621.mk
> @@ -640,3 +640,15 @@ define Device/zbt-wg3526-32M
> kmod-usb3 kmod-usb-ledtrig-usbport wpad-basic
> endef
> TARGET_DEVICES += zbt-wg3526-32M
> +
&
Re: [OpenWrt-Devel] [PATCH] ramips: add support for ASUS RT-AC57U
Hi! On Tue, Jun 25, 2019 at 5:23 PM Christian Lamparter wrote: > Is 10MHz even a supported frequency for the SPI-NOR chip? It is supported. It's just unnecessarily slow. Mediatek uses 30MHz in their SDK and all my boards works fine with 40MHz. > > I think you can measure the time it takes to read the SPI-NOR and check > if the KiB/s match with the selected frequency or not. Did a quick test on my router with 40MHz SPI clock: # time dd if=/dev/mtdblock3 of=/dev/null bs=64k 251+0 records in 251+0 records out real 0m 4.98s user 0m 0.00s sys 0m 0.16s around 25Mbit/s Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: ASUS RT-AC57 only supports USB2, not USB3
Hi! On Sat, Jul 13, 2019 at 4:51 PM Stijn Segers wrote: > > Commit 14e0e4f138e35c3e2a15cc3a836c939547ee053b added support for the ASUS > RT-AC57U but erroneously > included kmod-usb3 whereas the RT-AC57U, despite the mt7621 SoC supporting > USB3, only has a USB2 > port. Make DEVICE_PACKAGES reflect this. MT7621 uses XHCI controller for both its usb2 and usb3 ports. It needs kmod-usb3 instead of kmod-usb2 even if that's just a usb2.0 port. Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: add support for gl-ar750
#size-cells = <0>;
> + status = "okay";
> +
> + hub_port: port@1 {
> + reg = <1>;
> + #trigger-source-cells = <0>;
> + };
> +};
> +
> +&usb_phy {
> + status = "okay";
> +};
> +
> +&spi {
> + status = "okay";
> + num-cs = <0>;
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <2500>;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "u-boot";
> + reg = <0x00 0x04>;
> + read-only;
> + };
> +
> + partition@4 {
> + label = "u-boot-env";
> + reg = <0x04 0x01>;
> + read-only;
> + };
> +
> + art: partition@5 {
> + label = "art";
> + reg = <0x05 0x01>;
> + read-only;
> + };
> +
> + partition@6 {
> + compatible = "denx,uimage";
> + label = "firmware";
> + reg = <0x06 0xfa>;
> + };
> + };
> + };
> +};
> +
> +ð0 {
> + status = "okay";
> + mtd-mac-address = <&art 0x0>;
> + phy-handle = <&swphy4>;
> +};
> +
> +ð1 {
> + mtd-mac-address = <&art 0x0>;
> + mtd-mac-address-increment = <1>;
> +};
> +
> +&wmac {
> + status = "okay";
> + mtd-cal-data = <&art 0x1000>;
> + mtd-mac-address = <&art 0x1002>;
This is just the location of default mac address in art.
mtd-mac-address is only needed if the one in art is incorrect and you
need to specify a mac address stored elsewhere.
This line can be dropped.
> +};
> diff --git a/target/linux/ath79/image/generic.mk
> b/target/linux/ath79/image/generic.mk
> index d5f67b8..033cfa3 100644
> --- a/target/linux/ath79/image/generic.mk
> +++ b/target/linux/ath79/image/generic.mk
> @@ -389,6 +389,14 @@ define Device/glinet_gl-ar300m-nor
> endef
> TARGET_DEVICES += glinet_gl-ar300m-nor
>
> +define Device/glinet_gl-ar750
> + ATH_SOC := qca9531
> + DEVICE_TITLE := GL.iNet GL-AR750
There's a recent splitting of DEVICE_TITLE [0]
You'd need to split this DEVICE_TITLE into DEVICE_VENDOR and DEVICE_MODEL
[0]
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=8c3dbaf8b49233e275b2dce4e30dc0a2bf8c86c5
> + DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-ath10k-ct
> ath10k-firmware-qca9887-ct
kmod-usb2 depends on kmod-usb-core and kmod-usb-core can be dropped here.
> + IMAGE_SIZE := 16000k
> +endef
> +TARGET_DEVICES += glinet_gl-ar750
> +
> define Device/glinet_gl-ar750s
>ATH_SOC := qca9563
>DEVICE_TITLE := GL.iNet GL-AR750S
Regards,
Chuanhong Guo
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH RFC 0/3] ramips: fix SDXC for HiWiFi HC5661A
Since mt76x8 ver1 eco2, SDXC pins can be switched to the following pinmap: sd_d1 -> PAD_I2S_SDI sd_d0 -> PAD_I2S_WS sd_cmd -> PAD_I2S_CLK sd_d3 -> PAD_I2C_SCLK sd_d2 -> PAD_I2C_SD sd_clk -> PAD_GPIO0 sd_wp -> PAD_TXD1 sd_cd -> PAD_RXD1 To use this pinmap, one would need to set ESD_MODE bit (bit 15) to 1 in GPIO1_MODE and switch other used pads into GPIO mode. HC5661A is a router which used this pinmap so that all 5 ethernet ports and SDXC interface can be used simutaneously. I think this patchset is kind of hacky so I decided to send it here for review/suggestions. Chuanhong Guo (3): ramips: mtk-mmc: mt76x8: check ESD_MODE before applying AGPIO_CFG ramips: mt76x8: pinctrl: add a hack for ESD_MODE bit in GPIO1_MODE ramips: enable sdxc driver for hc5661a .../ramips/dts/mt7628an_hiwifi_hc5661a.dts| 17 ++ .../files-4.14/drivers/mmc/host/mtk-mmc/sd.c | 12 ++-- target/linux/ramips/image/mt76x8.mk | 1 + .../500-hack-mt76x8-pinctrl-esdmode.patch | 55 +++ 4 files changed, 77 insertions(+), 8 deletions(-) create mode 100644 target/linux/ramips/patches-4.14/500-hack-mt76x8-pinctrl-esdmode.patch -- 2.21.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH RFC 3/3] ramips: enable sdxc driver for hc5661a
Since we've fixed AGPIO_MODE setup in sdxc driver, we can enable
SDXC interface for HC5661A now.
Signed-off-by: Chuanhong Guo
---
pinctrl disallows "double enable" for a function (meaning can't set a
group to gpio twice), so the gpio group needs to be specified for every
dts and can't be put into mt7628.dtsi
.../ramips/dts/mt7628an_hiwifi_hc5661a.dts | 17 +
target/linux/ramips/image/mt76x8.mk | 1 +
2 files changed, 18 insertions(+)
diff --git a/target/linux/ramips/dts/mt7628an_hiwifi_hc5661a.dts
b/target/linux/ramips/dts/mt7628an_hiwifi_hc5661a.dts
index df239e1fb8..3ba3774f1c 100644
--- a/target/linux/ramips/dts/mt7628an_hiwifi_hc5661a.dts
+++ b/target/linux/ramips/dts/mt7628an_hiwifi_hc5661a.dts
@@ -50,6 +50,18 @@
};
&pinctrl {
+ sdxc_router_pins: sdxc_router_mode {
+ gpio {
+ ralink,group = "i2s", "sdmode", "uart1", "gpio";
+ ralink,function = "gpio";
+ };
+
+ esdmode {
+ ralink,group = "esdmode";
+ ralink,function = "sdxc";
+ };
+ };
+
state_default: pinctrl0 {
gpio {
ralink,group = "i2c", "refclk", "wled_an";
@@ -58,6 +70,11 @@
};
};
+&sdhci {
+ status = "okay";
+ pinctrl-0 = <&sdxc_router_pins>;
+};
+
&spi0 {
status = "okay";
diff --git a/target/linux/ramips/image/mt76x8.mk
b/target/linux/ramips/image/mt76x8.mk
index fae9fb03cf..033cc7527d 100644
--- a/target/linux/ramips/image/mt76x8.mk
+++ b/target/linux/ramips/image/mt76x8.mk
@@ -97,6 +97,7 @@ define Device/hiwifi_hc5661a
DEVICE_VENDOR := HiWiFi
DEVICE_MODEL := HC5661A
SUPPORTED_DEVICES += hc5661a
+ DEVICE_PACKAGES := kmod-sdhci-mt7620
endef
TARGET_DEVICES += hiwifi_hc5661a
--
2.21.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH RFC 2/3] ramips: mt76x8: pinctrl: add a hack for ESD_MODE bit in GPIO1_MODE
This bit is used to specify sdxc pinmap for mt76x8. Details available
in patch description.
To properly solve this problem and the other pinctrl hack in mtk-mmc
driver we'll need to write a dedicated pinctrl driver for mt76x8,
with the support for configuring AGPIO_MODE and RGCTL registers as
well as specially handling GPIO reservation/pinctrl setup for ESDMODE.
Signed-off-by: Chuanhong Guo
---
.../500-hack-mt76x8-pinctrl-esdmode.patch | 55 +++
1 file changed, 55 insertions(+)
create mode 100644
target/linux/ramips/patches-4.14/500-hack-mt76x8-pinctrl-esdmode.patch
diff --git
a/target/linux/ramips/patches-4.14/500-hack-mt76x8-pinctrl-esdmode.patch
b/target/linux/ramips/patches-4.14/500-hack-mt76x8-pinctrl-esdmode.patch
new file mode 100644
index 00..af8ce1257a
--- /dev/null
+++ b/target/linux/ramips/patches-4.14/500-hack-mt76x8-pinctrl-esdmode.patch
@@ -0,0 +1,55 @@
+From: Chuanhong Guo
+Date: Sat, 13 Jul 2019 17:59:03 +0800
+Subject: [PATCH] ramips: hack: add esdmode pinctrl group
+
+Since mt76x8an ver1 eco2, SDXC pins can be switched to the
+following pinmap:
+sd_d1 -> PAD_I2S_SDI
+sd_d0 -> PAD_I2S_WS
+sd_cmd -> PAD_I2S_CLK
+sd_d3 -> PAD_I2C_SCLK
+sd_d2 -> PAD_I2C_SD
+sd_clk -> PAD_GPIO0
+sd_wp -> PAD_TXD1
+sd_cd -> PAD_RXD1
+
+To use this pinmap, one would need to set ESD_MODE bit (bit 15)
+to 1 in GPIO1_MODE and switch other used pads into GPIO mode.
+
+MTK called this pinmap "router mode" and the pinmap described
+in their datasheed is called "iot mode".
+
+This patch is hacky because:
+1. pinmux-rt2880 doesn't support reserving noncontiguous GPIO
+ pins so those GPIOs can't be properly reserved.
+2. it misused "gpio" function for "iot mode", due to the fact
+ that this mode doesn't reserve any GPIOs.
+
+Signed-off-by: Chuanhong Guo
+---
+--- a/arch/mips/ralink/mt7620.c
b/arch/mips/ralink/mt7620.c
+@@ -149,6 +149,7 @@ static struct rt2880_pmx_func refclk_grp
+ static struct rt2880_pmx_func perst_grp_mt7628[] = { FUNC("perst", 0, 36, 1)
};
+ static struct rt2880_pmx_func wdt_grp_mt7628[] = { FUNC("wdt", 0, 38, 1) };
+ static struct rt2880_pmx_func spi_grp_mt7628[] = { FUNC("spi", 0, 7, 4) };
++static struct rt2880_pmx_func esd_mode_grp_mt7628[] = { FUNC("sdxc", 1, 0, 0)
};
+
+ static struct rt2880_pmx_func sd_mode_grp_mt7628[] = {
+ FUNC("jtag", 3, 22, 8),
+@@ -297,6 +298,7 @@ static struct rt2880_pmx_func wled_an_gr
+ #define MT7628_GPIO_MODE_I2C 20
+ #define MT7628_GPIO_MODE_REFCLK 18
+ #define MT7628_GPIO_MODE_PERST16
++#define MT7628_GPIO_MODE_ESDMODE 15
+ #define MT7628_GPIO_MODE_WDT 14
+ #define MT7628_GPIO_MODE_SPI 12
+ #define MT7628_GPIO_MODE_SDMODE 10
+@@ -319,6 +321,7 @@ static struct rt2880_pmx_group mt7628an_
+ 1, MT7628_GPIO_MODE_I2C),
+ GRP("refclk", refclk_grp_mt7628, 1, MT7628_GPIO_MODE_REFCLK),
+ GRP("perst", perst_grp_mt7628, 1, MT7628_GPIO_MODE_PERST),
++ GRP_G("esdmode", esd_mode_grp_mt7628, 1, 0, MT7628_GPIO_MODE_ESDMODE),
+ GRP("wdt", wdt_grp_mt7628, 1, MT7628_GPIO_MODE_WDT),
+ GRP("spi", spi_grp_mt7628, 1, MT7628_GPIO_MODE_SPI),
+ GRP_G("sdmode", sd_mode_grp_mt7628, MT7628_GPIO_MODE_MASK,
--
2.21.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH RFC 1/3] ramips: mtk-mmc: mt76x8: check ESD_MODE before applying AGPIO_CFG
Since mt76x8an ver1 eco2, SDXC pins can be switched to the
following pinmap:
sd_d1 -> PAD_I2S_SDI
sd_d0 -> PAD_I2S_WS
sd_cmd -> PAD_I2S_CLK
sd_d3 -> PAD_I2C_SCLK
sd_d2 -> PAD_I2C_SD
sd_clk -> PAD_GPIO0
sd_wp -> PAD_TXD1
sd_cd -> PAD_RXD1
To use this pinmap, one would need to set ESD_MODE bit (bit 15)
to 1 in GPIO1_MODE and switch other used pads into GPIO mode.
In this mode, we don't need to switch ethernet pins to digital
pad.
Check ESD_MODE bit before applying AGPIO_CFG and use rt_sysc_m32
to set it.
Signed-off-by: Chuanhong Guo
---
.../ramips/files-4.14/drivers/mmc/host/mtk-mmc/sd.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/target/linux/ramips/files-4.14/drivers/mmc/host/mtk-mmc/sd.c
b/target/linux/ramips/files-4.14/drivers/mmc/host/mtk-mmc/sd.c
index 4ced4b6605..cb0aa4231a 100644
--- a/target/linux/ramips/files-4.14/drivers/mmc/host/mtk-mmc/sd.c
+++ b/target/linux/ramips/files-4.14/drivers/mmc/host/mtk-mmc/sd.c
@@ -2205,16 +2205,12 @@ static int msdc_drv_probe(struct platform_device *pdev)
struct msdc_host *host;
struct msdc_hw *hw;
int ret;
- u32 reg;
//FIXME: this should be done by pinconf and not by the sd driver
- if (ralink_soc == MT762X_SOC_MT7688 ||
- ralink_soc == MT762X_SOC_MT7628AN) {
- /* set EPHY pads to digital mode */
- reg = sdr_read32((void __iomem *)(RALINK_SYSCTL_BASE + 0x3c));
- reg |= 0x1e << 16;
- sdr_write32((void __iomem *)(RALINK_SYSCTL_BASE + 0x3c), reg);
- }
+ if ((ralink_soc == MT762X_SOC_MT7688 ||
+ralink_soc == MT762X_SOC_MT7628AN) &&
+ (!(rt_sysc_r32(0x60) & BIT(15
+ rt_sysc_m32(0xf << 17, 0xf << 17, 0x3c);
hw = &msdc0_hw;
--
2.21.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ath79: add support for Qihoo C301
Specifications: - SoC: AR9344 - RAM: 128MB - Flash: 2 * 16MB (MX25L12845) - Ethernet: 2 * FE LAN & 1 * FE WAN - WiFi: 2.4G: AR9344 5G: QCA9882 Flash instruction: 1. Hold reset and power up the router 2. Set your IP to 192.168.1.x 3. Open 192.168.1.1 and upload the generated *factory* firmware Signed-off-by: Chuanhong Guo --- package/boot/uboot-envtools/files/ath79 | 3 + .../ath79/base-files/etc/board.d/01_leds | 3 + .../ath79/base-files/etc/board.d/02_network | 9 + .../etc/hotplug.d/firmware/10-ath9k-eeprom| 4 + .../etc/hotplug.d/firmware/11-ath10k-caldata | 4 + .../ath79/base-files/etc/init.d/bootcount | 11 + target/linux/ath79/config-4.19| 1 + target/linux/ath79/dts/ar9344_qihoo_c301.dts | 236 ++ target/linux/ath79/image/generic.mk | 12 + 9 files changed, 283 insertions(+) create mode 100755 target/linux/ath79/base-files/etc/init.d/bootcount create mode 100644 target/linux/ath79/dts/ar9344_qihoo_c301.dts diff --git a/package/boot/uboot-envtools/files/ath79 b/package/boot/uboot-envtools/files/ath79 index 069d7be06b..cc11725242 100644 --- a/package/boot/uboot-envtools/files/ath79 +++ b/package/boot/uboot-envtools/files/ath79 @@ -29,6 +29,9 @@ openmesh,om5p-ac-v2|\ yuncore,a770) ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x1" "0x1" ;; +qihoo,c301) + ubootenv_add_uci_config "/dev/mtd9" "0x0" "0x1" "0x1" + ;; esac config_load ubootenv diff --git a/target/linux/ath79/base-files/etc/board.d/01_leds b/target/linux/ath79/base-files/etc/board.d/01_leds index 46b3e51193..ecfb7b0694 100755 --- a/target/linux/ath79/base-files/etc/board.d/01_leds +++ b/target/linux/ath79/base-files/etc/board.d/01_leds @@ -104,6 +104,9 @@ pcs,cr3000) ucidef_set_led_switch "lan3" "LAN3" "pcs:blue:lan3" "switch0" "0x10" ucidef_set_led_switch "lan4" "LAN4" "pcs:blue:lan4" "switch0" "0x02" ;; +qihoo,c301) + ucidef_set_led_wlan "wlan" "WLAN" "$boardname:green:wlan" "phy0tpt" + ;; tplink,archer-a7-v5|\ tplink,archer-c7-v4|\ tplink,archer-c7-v5) diff --git a/target/linux/ath79/base-files/etc/board.d/02_network b/target/linux/ath79/base-files/etc/board.d/02_network index 85e57c6eb5..f7cac3e300 100755 --- a/target/linux/ath79/base-files/etc/board.d/02_network +++ b/target/linux/ath79/base-files/etc/board.d/02_network @@ -184,6 +184,11 @@ ath79_setup_interfaces() ucidef_add_switch "switch0" \ "0@eth0" "3:lan:1" "5:lan:2" "4:wan" ;; + qihoo,c301) + ucidef_set_interface_wan "eth1" + ucidef_add_switch "switch0" \ + "0@eth0" "2:lan" "3:lan" + ;; rosinson,wr818) ucidef_add_switch "switch0" \ "0@eth0" "1:lan" "2:lan" "3:wan" @@ -328,6 +333,10 @@ ath79_setup_macs() lan_mac=$(k2t_get_mac "lan_mac") wan_mac=$(k2t_get_mac "wan_mac") ;; + qihoo,c301) + lan_mac=$(mtd_get_mac_ascii devdata lanmac) + wan_mac=$(mtd_get_mac_ascii devdata wanmac) + ;; rosinson,wr818) wan_mac=$(mtd_get_mac_binary factory 0) lan_mac=$(macaddr_setbit_la "$wan_mac") diff --git a/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom b/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom index 5a20b84344..f049dbd46a 100644 --- a/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom +++ b/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom @@ -127,6 +127,10 @@ case "$FIRMWARE" in ath9k_eeprom_extract "art" 4096 1088 ath9k_patch_fw_mac $(mtd_get_mac_text board_data 1664) 2 ;; + qihoo,c301) + ath9k_eeprom_extract "radiocfg" 4096 1088 + ath9k_patch_fw_mac $(mtd_get_mac_ascii devdata "wlan24mac") 2 + ;; *) ath9k_eeprom_die "board $board is not supported yet" ;; diff --git a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata index 06a48e2258..149d744eb8 100644 --- a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata +++ b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata @@ -138,6 +138,10 @@ case "$FIRMWARE" in
Re: [OpenWrt-Devel] [PATCH] ath79: add support for Qihoo C301
On Mon, Jul 15, 2019 at 7:53 PM Chuanhong Guo wrote:
> +&builtin_switch {
> +pinctrl-names = "default";
> +pinctrl-0 = <&pmx_led_switch>;
> +};
Here's an indentation using 4 spaces. I've fixed it locally.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: Don't override the bootloader cmdline args if none are provided in dtb
Hi! On Fri, Jun 21, 2019 at 6:58 AM wrote: > > From: Joe Stefek > > This change allows cmdline arguments provided by the bootloader to be used > if no cmdline arguments are provided in the "custom" section of the device > tree. I've dropped the entire prom-fixes patch two weeks ago [0] and I guess we don't need this fix anymore :) Regards, Chuanhong Guo [0] https://git.openwrt.org/7a8d3432c739c6ff038295176e8b6324e92fc116 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: add support for Qihoo C301
Hi! On Mon, Jul 15, 2019 at 9:29 PM Adrian Schmutzler wrote: > can you tell which of the 4 MAC addresses is on the device label, so I can > add it to my label-mac-address PR? I guess the router I have is a weird engineering sample. None of the 6 MAC addresses stored in mtd matches the one on the label :( Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH RFC 1/3] ramips: mtk-mmc: mt76x8: check ESD_MODE before applying AGPIO_CFG
On Mon, Jul 15, 2019 at 12:34 AM Chuanhong Guo wrote: > > Since mt76x8an ver1 eco2, SDXC pins can be switched to the > following pinmap: > sd_d1 -> PAD_I2S_SDI > sd_d0 -> PAD_I2S_WS > sd_cmd -> PAD_I2S_CLK > sd_d3 -> PAD_I2C_SCLK > sd_d2 -> PAD_I2C_SD > sd_clk -> PAD_GPIO0 > sd_wp -> PAD_TXD1 > sd_cd -> PAD_RXD1 > > To use this pinmap, one would need to set ESD_MODE bit (bit 15) > to 1 in GPIO1_MODE and switch other used pads into GPIO mode. > In this mode, we don't need to switch ethernet pins to digital > pad. > > Check ESD_MODE bit before applying AGPIO_CFG and use rt_sysc_m32 > to set it. > > Signed-off-by: Chuanhong Guo Pushed this single patch since it's just a fix for the original hack anyway. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: Remove left-over mistyped device string from 02_network
Hi!
On Mon, Jul 15, 2019 at 11:50 PM Adrian Schmutzler
wrote:
>
> In 2011 (!), network setup for nexaira,bc2 was moved to network
> defaults script with a typo so it became b2c:
> https://github.com/openwrt/openwrt/commit/295e04084c5e106dfac0d9f05ac530de5d0fc07d
I remembered that kernel checkpatch.pl checks for git commit
referencing style and I decided to fix it manually before applying.
But I did it the wrong way. Oops...
The following is the output of checkpatch.pl in kernel:
Please use git commit description style 'commit <12+ chars of sha1>
("")' - ie: 'commit 295e04084c5e ("ramips: setup bc2 mac
addresses from the generic network script")'
>
> This patch just removes the useless entry without replacement,
> since it seems to have worked for 8 years anyway.
>
> Signed-off-by: Adrian Schmutzler
Applied. Thanks!
Regards,
Chuanhong Guo
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] treewide: sync bootcount scripts across targets
This commit made the following changes to sync all bootcount scripts:
1. use boot() instead of start()
This script only needs to be executed once when boot is complete.
use boot() to make this explicit.
2. drop sourcing of /lib/functions.sh
This is aready done in /etc/rc.common.
3. ramips: replace board name checking with a case
Signed-off-by: Chuanhong Guo
---
target/linux/ath79/base-files/etc/init.d/bootcount| 1 +
target/linux/ipq40xx/base-files/etc/init.d/bootcount | 4 +---
target/linux/ipq806x/base-files/etc/init.d/bootcount | 4 +---
target/linux/kirkwood/base-files/etc/init.d/bootcount | 4 +---
target/linux/mvebu/base-files/etc/init.d/bootcount| 4 +---
target/linux/ramips/base-files/etc/init.d/bootcount | 11 +--
6 files changed, 10 insertions(+), 18 deletions(-)
diff --git a/target/linux/ath79/base-files/etc/init.d/bootcount
b/target/linux/ath79/base-files/etc/init.d/bootcount
index b71fbf9a69..c734fd9d33 100755
--- a/target/linux/ath79/base-files/etc/init.d/bootcount
+++ b/target/linux/ath79/base-files/etc/init.d/bootcount
@@ -1,4 +1,5 @@
#!/bin/sh /etc/rc.common
+
START=99
boot() {
diff --git a/target/linux/ipq40xx/base-files/etc/init.d/bootcount
b/target/linux/ipq40xx/base-files/etc/init.d/bootcount
index f2d76f125f..b9d625e296 100755
--- a/target/linux/ipq40xx/base-files/etc/init.d/bootcount
+++ b/target/linux/ipq40xx/base-files/etc/init.d/bootcount
@@ -2,9 +2,7 @@
START=99
-start() {
- . /lib/functions.sh
-
+boot() {
case $(board_name) in
alfa-network,ap120c-ac)
[ -n "$(fw_printenv bootcount changed 2>/dev/null)" ] &&\
diff --git a/target/linux/ipq806x/base-files/etc/init.d/bootcount
b/target/linux/ipq806x/base-files/etc/init.d/bootcount
index 6a5a6d52ad..d0bf708e66 100755
--- a/target/linux/ipq806x/base-files/etc/init.d/bootcount
+++ b/target/linux/ipq806x/base-files/etc/init.d/bootcount
@@ -2,9 +2,7 @@
START=99
-start() {
- . /lib/functions.sh
-
+boot() {
case $(board_name) in
linksys,ea8500)
mtd resetbc s_env || true
diff --git a/target/linux/kirkwood/base-files/etc/init.d/bootcount
b/target/linux/kirkwood/base-files/etc/init.d/bootcount
index 20fb3a425c..478f3d0134 100755
--- a/target/linux/kirkwood/base-files/etc/init.d/bootcount
+++ b/target/linux/kirkwood/base-files/etc/init.d/bootcount
@@ -2,9 +2,7 @@
START=99
-start() {
- . /lib/functions.sh
-
+boot() {
case $(board_name) in
linksys,audi|\
linksys,viper)
diff --git a/target/linux/mvebu/base-files/etc/init.d/bootcount
b/target/linux/mvebu/base-files/etc/init.d/bootcount
index 6e8e310849..dd2266bdc8 100755
--- a/target/linux/mvebu/base-files/etc/init.d/bootcount
+++ b/target/linux/mvebu/base-files/etc/init.d/bootcount
@@ -2,9 +2,7 @@
START=99
-start() {
- . /lib/functions.sh
-
+boot() {
case $(board_name) in
linksys,caiman |\
linksys,cobra |\
diff --git a/target/linux/ramips/base-files/etc/init.d/bootcount
b/target/linux/ramips/base-files/etc/init.d/bootcount
index 60b93f72b3..807801a34f 100755
--- a/target/linux/ramips/base-files/etc/init.d/bootcount
+++ b/target/linux/ramips/base-files/etc/init.d/bootcount
@@ -2,11 +2,10 @@
START=99
-start() {
- . /lib/functions.sh
-
- local board=$(board_name)
- if [ $board = "samknows,whitebox-v8" ]; then
+boot() {
+ case $(board_name) in
+ samknows,whitebox-v8)
fw_setenv bootcount 0
- fi
+ ;;
+ esac
}
--
2.21.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: add support for gl-ar750
ort@1 {
> + reg = <1>;
> + #trigger-source-cells = <0>;
> + };
This hub_port node is only used for a usb-port LED trigger. It can be
dropped if you don't have a USB LED.
> +};
> +
> +&usb_phy {
> + status = "okay";
> +};
> +
> +&spi {
> + status = "okay";
> + num-cs = <0>;
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <2500>;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "u-boot";
> + reg = <0x00 0x04>;
> + read-only;
> + };
> +
> + partition@4 {
> + label = "u-boot-env";
> + reg = <0x04 0x01>;
> + read-only;
> + };
> +
> + art: partition@5 {
> + label = "art";
> + reg = <0x05 0x01>;
> + read-only;
> + };
> +
> + partition@6 {
> + compatible = "denx,uimage";
> + label = "firmware";
> + reg = <0x06 0xfa>;
> + };
> + };
> + };
> +};
> +
> +ð0 {
> + status = "okay";
> + mtd-mac-address = <&art 0x0>;
> + phy-handle = <&swphy4>;
> +};
> +
> +ð1 {
> + mtd-mac-address = <&art 0x0>;
> + mtd-mac-address-increment = <1>;
> +};
> +
> +&wmac {
> + status = "okay";
> + mtd-cal-data = <&art 0x1000>;
> +};
> diff --git a/target/linux/ath79/image/generic.mk
> b/target/linux/ath79/image/generic.mk
> index c5807f2..26b700d 100644
> --- a/target/linux/ath79/image/generic.mk
> +++ b/target/linux/ath79/image/generic.mk
> @@ -486,6 +486,16 @@ define Device/glinet_gl-ar300m-nor
> endef
> TARGET_DEVICES += glinet_gl-ar300m-nor
>
> +define Device/glinet_gl-ar750
> + ATH_SOC := qca9531
> + DEVICE_VENDOR := GL.iNet
> + DEVICE_MODEL := GL-AR750
> + DEVICE_PACKAGES := kmod-usb2 kmod-ath10k-ct ath10k-firmware-qca9887-ct
> block-mount
block-mount shouldn't be included in DEVICE_PACKAGES.
> + IMAGE_SIZE := 16000k
> + SUPPORTED_DEVICES += gl-ar750
> +endef
> +TARGET_DEVICES += glinet_gl-ar750
> +
> define Device/glinet_gl-ar750s
>ATH_SOC := qca9563
>DEVICE_VENDOR := GL.iNet
> --
> 2.7.4
>
Regards,
Chuanhong Guo
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath9k: mtd-cal-data vs firmware bin file
Hi! On Wed, Aug 14, 2019 at 4:59 PM Michal Cieslakiewicz wrote: > /etc/hotplug.d/firmware/10-ath9k-eeprom for these routers just extracts > 4k of calibration data from ART to bin file in /lib/firmware. I > compared bin file to mtd area and they are identical. Why ath9k cannot > use this data directly accessing /dev/mtd6? Is that 'mtd-cal-data' dts > option for? If so, why does it not work in this case? (tested, ath9k > initialization ends with error) mtd-cal-data is part of a local hack for wmac devices only: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/kernel/mac80211/patches/ath/552-ahb_of.patch;h=1170fc64bd9092d374ee78285060b504a699b720;hb=HEAD It loads calibration data and create an ath9k_platform_data struct. >I recall there was no such operation in ar71xx target In ar71xx, calibration data is loaded through ath9k_platform_data for newer wifi cards and for older cards, there's a piece of code feeding caldata in arch/mips/ath79/pci-ath9k-fixup.c before ath9k loads (in ath79 and lantiq this is replaced by owl-loader). Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/3] kernel: add support for realtek rtl8367s
Hi! On Thu, Aug 15, 2019 at 4:26 PM Serge Vasilugin wrote: > > Adding support for tplink archer c5 v4 some problems arise: > 1. Device use unsupported rtl8367s switch. > 2. rtl8367s switch have non default 0 phy address at mii-bus (29). > 3. rtl8367s switch is connected through unsupported extended interface 2. > > The patches resolve these problems. Many info and sources were used from > forum topic [0]. Vendor driver and u-boot identify rtl8367s as RTL8367C > so I keep it. > All thease patches may be backported to previous release without changes There are some review comments about this driver on GitHub PR#2174 [0] Would you mind to check it out there? (v2 patch could still be sent here on the mailing list) > > [0] https://forum.openwrt.org/t/support-for-new-archer-c5-v4 > > --- > serge > Regards, Chuanhong Guo [0] https://github.com/openwrt/openwrt/pull/2174 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] ath79: add support for gl-ar750
Hi! On Fri, Aug 23, 2019 at 5:08 PM Luochongjun wrote: > > This patch supports gl-ar750, which was previously supported by ar71xx. > > Specification: > - SOC: QCA9531 (650MHz) > - Flash: 16 MiB (W25Q128FVSG) > - RAM: 128 MiB DDR2 > - Ethernet: 10/100: 2xLAN + 10/100: 1xWAN > - Wireless: 2.4GHz (bgn) and 5GHz (ac) > - USB: 1x USB 2.0 port > - Switch: 1x switch > - Button: 1x reset button > - LED: 3x LEDS (white) > > Flash instruction: > Support for sysupgrade directive upgrades, as well as luci upgrades. > > Signed-off-by: Luochongjun > --- Merged into my staging tree at: https://git.openwrt.org/?p=openwrt/staging/981213.git Thanks! Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 18.06 1/3] ramips: remove duplicate case for MAC setup of freestation5
Hi! On Sat, Sep 7, 2019 at 11:07 PM Adrian Schmutzler wrote: > > ARC FreeStation5 is present twice in MAC address setup. > > From older commits/changes, it is not possible to reconstruct > the correct choice only by reading the annotations. > > Thus, remove the second case and keep the first one, so behavior > stays the same (as nobody seems to have complained about it). > > Signed-off-by: Adrian Schmutzler > (cherry picked from commit ad4eb2241b33b05b0942a3fa7ed2e53fb6e84386) > --- > target/linux/ramips/base-files/etc/board.d/02_network | 1 - > 1 file changed, 1 deletion(-) > Both patchset applied to corresponding branches. Thanks! Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Negative offset for checksum in ath79's 10-ath9k-eeprom
Hi! On Wed, Sep 18, 2019 at 8:18 PM Adrian Schmutzler wrote: > > Hi, > > I've encountered the following issue, for which I would like a second opinion. > > In ath79's 10-ath9k-eeprom, in addition to patching the firmware MAC address, > some devices also need a checksum adjustment: > https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom#L60 > > For this purpose, the function ath9k_patch_fw_mac_crc is used (below > ath9k_patch_fw_mac), where the chksum_offset is calculated by subtracting 10 > from the mac_offset. > (For ath10k chksum_offset value is hardcoded to 2). > > However, in ath79's 10-ath9k-eeprom, some devices call this function with a > mac_offset of 0x2, e.g. > > dlink,dir-825-c1|\ > dlink,dir-835-a1) > ath9k_eeprom_extract "art" 0x1000 0x440 > ath9k_patch_fw_mac_crc $(mtd_get_mac_text "mac" 0x4) 0x2 > > This would result in a negative chksum_offset. > > To me this looks like a misuse of ath9k_patch_fw_mac_crc where > ath9k_patch_fw_mac should have been used. That's indeed a misuse. ar9300 eeproms (which are used on ar9331 and later socs and ar938x pcie cards) have their macs at 0x4 and don't have a checksum field at all. BTW there's another misuse in ath10k-caldata: All ath10k eeproms have checksum fields and should use ath10k_patch_mac_crc, ath10k_patch_mac exists only because ath10k firmware doesn't verify it. Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Negative offset for checksum in ath79's 10-ath9k-eeprom
On Wed, Sep 18, 2019 at 10:06 PM Chuanhong Guo wrote: > That's indeed a misuse. ar9300 eeproms (which are used on ar9331 and > later socs and ar938x pcie cards) have their macs at 0x4 and don't Oops. Typo here. mac is at 0x2 > have a checksum field at all. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 1/3] kernel: rtl8366_smi: explicitly set phy addr for switch
Hi!
On Tue, Aug 27, 2019 at 5:49 PM Serge Vailugin wrote:
> [...]
> @@ -1558,6 +1558,14 @@ int rtl8366_smi_probe_of(struct platform_device
> *pdev, struct rtl8366_smi *smi)
> goto try_gpio;
> }
>
> + of_property_read_u32(np, "phy_id", &smi->phy_id);
> + if(smi->phy_id < 0) {
> + smi->phy_id = MDC_REALTEK_PHY_ADDR;
> + }
When of_property_read_u32 fails, it returns a negative value and leave
destination variable unchanged. You should check return value here
instead.
> +
> + dev_info(&pdev->dev,
> + "switch phy addr=%d\n", smi->phy_id);
> +
> return 0;
>
> try_gpio:
Regards,
Chuanhong Guo
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 2/3] kernel: rtl8367b: add configuration for extended interface 2
Hi!
On Tue, Aug 27, 2019 at 5:50 PM Serge Vailugin wrote:
>
> Both rtl8367b and rtl8367s have two extended interface
> rtl8367rb: 5 port + 2*RGMII/MII
> rtl8367s: 5 port + SGMII/HSGMI + RGMII/MII
> (?)rtl8367sb: 5 port + 2*RGMII/MII
> These interfaces correspond to EXT1 and EXT2 (ports 6 and 7 respectivly).
> Current driver don't support EXT2 configuration but notexisting EXT0
> (port 5).
> This patch allow to configure EXT2 in dts-file:
>
> rtl8367rb {
> compatible = "realtek,rtl8367b";
> cpu_port = <7>;
> realtek,extif2 = <1 0 1 1 1 1 1 1 2>; /* configuration for
> EXT2 */
> mii-bus = <&mdio0>;
> phy_id = <29>;
> };
>
> This patch is independent of the rtl8366_smi patch (set switch phy address)
> and may be helpful for device with rtl8367rb connected through EXT2.
>
> Signed-off-by: Serge Vasilugin
This patch seems to be broken in patchwork:
https://patchwork.ozlabs.org/patch/1153690/
Would you mind to create patches using git format-patch and resend
them with git send-email?
Regards,
Chuanhong Guo
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: initialize youhua, wr1200js WAN MAC addresses from flash
Hi! On Sun, Sep 22, 2019 at 6:01 PM Adrian Schmutzler wrote: > > This patch changes wan MAC address setup for youhua,wr1200js > from retrieving it by calculation to reading it from flash. > > This has been checked on-device. > > Signed-off-by: Adrian Schmutzler Applied on my staging tree at: https://git.openwrt.org/?p=openwrt/staging/981213.git Thanks! Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/1] ath79: Restore GL.iNet GL-AR300M-Lite first-boot connectivity
Hi!
On Sat, Sep 28, 2019 at 12:33 AM Jeff Kletsky wrote:
> [...]
> As suggested by Alberto Bursi in the linked thread, one approach to
> resolution would be to disable the "unused" interface, GMAC1. This
> would have the additional advantage of removing the unconnected
> interface from the kernel and end-user visibility. By disabling GMAC1,
> it was expected that GMAC0 would be identified by the kernel as "eth0"
> as the sole Ethernet interface visible.
>
> ð1 {
>status = "disabled";
> };
>
To disable GMAC1, you should use the following:
ð1 {
compatible = "syscon", "simple-mfd";
}
Regards,
Chuanhong Guo
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 3/3] ramips: add RT6855A SoC Linux support patches
Hi! On Thu, Dec 24, 2020 at 12:52 AM Rafaël Carré wrote: > > TODO: the spi-mt7621 patches will break support for other targets Does that work on RT6855A at all? spi-mt7621 is a mediatek IP core. For a Ralink SoC I'm expected to see a controller supported by existing spi-ralink.c instead. The GPL code you linked in one of your patch only contains the driver for the ralink spi controller and I can't find the mt7621 driver (ralink_spi_bbu.c) at all. And please try your best to finish the TODOs before sending them for review. Or send it as RFC instead. I'm marking this patch rejected for the exact reasons you've realized yourself in those TODOs: 1. adding the old vendor pci drivers 2. breaking the spi driver for mt7621/mt7628. Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 3/3] ramips: add RT6855A SoC Linux support patches
Hi! On Thu, Dec 24, 2020 at 10:12 AM Chuanhong Guo wrote: > > Hi! > > On Thu, Dec 24, 2020 at 12:52 AM Rafaël Carré wrote: > > > > TODO: the spi-mt7621 patches will break support for other targets > > Does that work on RT6855A at all? spi-mt7621 is a mediatek IP core. > For a Ralink SoC I'm expected to see a controller supported by > existing spi-ralink.c instead. > The GPL code you linked in one of your patch only contains > the driver for the ralink spi controller and I can't find the mt7621 > driver (ralink_spi_bbu.c) at all. Oops. I'm not careful enough. Found it now. -- Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 3/3] ramips: add RT6855A SoC Linux support patches
On Thu, Dec 24, 2020 at 12:52 AM Rafaël Carré wrote: > diff --git > a/target/linux/ramips/patches-5.4/304-HACK-spi-mt7621-rt6855a-fix.patch > b/target/linux/ramips/patches-5.4/304-HACK-spi-mt7621-rt6855a-fix.patch > new file mode 100644 > index 00..972e969fc4 > --- /dev/null > +++ b/target/linux/ramips/patches-5.4/304-HACK-spi-mt7621-rt6855a-fix.patch > @@ -0,0 +1,35 @@ > +From cbc220c515f2b387462795b730b52dea96687885 Mon Sep 17 00:00:00 2001 > +From: =?UTF-8?q?Rafa=C3=ABl=20Carr=C3=A9?= > +Date: Wed, 23 Dec 2020 14:18:31 +0100 > +Subject: [PATCH 2/5] HACK: spi-mt7621: rt6855a fix > +MIME-Version: 1.0 > +Content-Type: text/plain; charset=UTF-8 > +Content-Transfer-Encoding: 8bit > + > +TODO: no idea what this does or if it's needed on other targets > +using this driver. This spi controller doesn't provide us with chipselect control, so the maximum transfer size is limited to the buffer size of MOREBUF mode. In order to get rid of that limit, we need to hold chipselect pins ourselves. It's accomplished in spi-mt7621.c this way: 1. set RS_SLAVE_SEL to 7 so that controller controls nonexistent CS7 for every transfer. 2. set actual chipselect pins by configuring CS polarity in SPI_CS_POLAR register. Now we can trigger the controller to do multiple transfers without deactivating chipselects in between, thus the transfer size limit is lifted for this controller. Datasheet for MT7688 is publicly available: https://labs.mediatek.com/en/download/50WkbgbH and you can find register details there. > + > +Signed-off-by: Rafaël Carré > +--- > + drivers/spi/spi-mt7621.c | 5 - > + 1 file changed, 4 insertions(+), 1 deletion(-) > + > +diff --git a/drivers/spi/spi-mt7621.c b/drivers/spi/spi-mt7621.c > +index 2c3b7a2a1ec7..58fb028ed776 100644 > +--- a/drivers/spi/spi-mt7621.c > b/drivers/spi/spi-mt7621.c > +@@ -87,7 +87,10 @@ static void mt7621_spi_set_cs(struct spi_device *spi, int > enable) > +* reliably) > +*/ > + master = mt7621_spi_read(rs, MT7621_SPI_MASTER); > +- master |= MASTER_RS_SLAVE_SEL | MASTER_MORE_BUFMODE; > ++ master |= MASTER_MORE_BUFMODE; > ++#ifndef CONFIG_SOC_RT6855A > ++ master |= MASTER_RS_SLAVE_SEL; > ++#endif > + master &= ~MASTER_FULL_DUPLEX; > + mt7621_spi_write(rs, MT7621_SPI_MASTER, master); > + > +-- > +2.27.0 > + -- Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 2/3] ramips: add RT6855A support to ethernet driver
[FE_REG_PDMA_RST_CFG] = RT5350_PDMA_RST_CFG,// RST_IDX > + [FE_REG_DLY_INT_CFG] = RT5350_DLY_INT_CFG, // OK > + [FE_REG_TX_BASE_PTR0] = RT5350_TX_BASE_PTR0, > + [FE_REG_TX_MAX_CNT0] = RT5350_TX_MAX_CNT0, > + [FE_REG_TX_CTX_IDX0] = RT5350_TX_CTX_IDX0, > + [FE_REG_TX_DTX_IDX0] = RT5350_TX_DTX_IDX0, > + [FE_REG_RX_BASE_PTR0] = RT5350_RX_BASE_PTR0, > + [FE_REG_RX_MAX_CNT0] = RT5350_RX_MAX_CNT0, > + [FE_REG_RX_CALC_IDX0] = RT5350_RX_CALC_IDX0, > + [FE_REG_RX_DRX_IDX0] = RT5350_RX_DRX_IDX0, > + [FE_REG_FE_INT_ENABLE] = RT5350_FE_INT_ENABLE, // OK > + [FE_REG_FE_INT_STATUS] = RT5350_FE_INT_STATUS, // OK > + [FE_REG_FE_RST_GL] = 0, > + [FE_REG_FE_DMA_VID_BASE] = 0, > +}; > + > +static void rt5350_init_data(struct fe_soc_data *data, Rename these functions with a rt6855a_ prefix instead. -- Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/3] ramips: add support for the RT6855A SoC
update > + > +board=$(board_name) > + > +board_config_flush > + > +exit 0 > diff --git a/target/linux/ramips/rt6855a/config-5.4 > b/target/linux/ramips/rt6855a/config-5.4 > new file mode 100644 > index 00..77ac7af2c0 > --- /dev/null > +++ b/target/linux/ramips/rt6855a/config-5.4 > @@ -0,0 +1,2266 @@ > +# > +# Automatically generated file; DO NOT EDIT. > +# Linux/mips 5.4.85 Kernel Configuration > +# OpenWrt buildroot has scripts to deal with kernel configs. You should use make kernel_menuconfig and exit the config menu to get this config file refreshed. (Common options defined in kernel packages and target/linux/generic will be remobed by kconfig scripts.) > [...] > diff --git a/target/linux/ramips/rt6855a/profiles/00-default.mk > b/target/linux/ramips/rt6855a/profiles/00-default.mk > new file mode 100644 > index 00..c0706254c7 > --- /dev/null > +++ b/target/linux/ramips/rt6855a/profiles/00-default.mk > @@ -0,0 +1,17 @@ > +# > +# Copyright (C) 2011 OpenWrt.org > +# > +# This is free software, licensed under the GNU General Public License v2. > +# See /LICENSE for more information. > +# > + > +define Profile/Default > + NAME:=Default Profile > + PRIORITY:=1 > + PACKAGES:= > +endef > + > +define Profile/Default/Description > + Default package set compatible with most boards. > +endef > +$(eval $(call Profile,Default)) > diff --git a/target/linux/ramips/rt6855a/target.mk > b/target/linux/ramips/rt6855a/target.mk > new file mode 100644 > index 00..0efedf4fde > --- /dev/null > +++ b/target/linux/ramips/rt6855a/target.mk > @@ -0,0 +1,15 @@ > +# > +# Copyright (C) 2009 OpenWrt.org > +# > + > +SUBTARGET:=rt6855a > +BOARDNAME:=RT6855A based boards > +FEATURES+=ramdisk pci > +CPU_TYPE:=34kc > + > +DEFAULT_PACKAGES += wpad-basic-wolfssl swconfig > + > +define Target/Description > + Build firmware images for Ralink RT6855A based boards. > +endef > + -- Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 3/3] ramips: add RT6855A SoC Linux support patches
Hi! On Sun, Dec 27, 2020 at 8:49 PM Rafaël Carré wrote: > Thanks for the explanation. > > I had a look at the datasheet, also at the commits log of spi-mt7621.c. > This also explains why I had to use dd bs=32 to get correct MTD reads. > > I am still a bit confused by the difference between chipselect and > slaveselect. > > On my target "rs_slave_sel" needs to have value "0 (default is flash)" > to be able to read flash. > > https://en.wikipedia.org/wiki/Chip_select starts with "Chip select (CS) > or slave select (SS)" so they can be synonymous. I guess in this case > the rs_slave_sel does something different from toggling the chipselect > pin of the (flash) SPI slave. They are the same thing. If you have to set it to 0, that probably means... > I also tried different values of cs_polar in SPI_CS_POLAR, but they > don't seem to have any effect, the flash can always be read as long as > rs_slave_sel stays 0. ... there may not be a SPI_CS_POLAR on RT6855A. And you have to live with that transfer size limitation unfortunately. > I am not sure what else to try or where to look at. > Should I try a different version of vendor driver (bbu_spiflash.c) > maybe, to gather some more informations on this rt6855a SoC ? As you can't trick the hardware to control chipselect, there isn't much in current spi-mt7621.c for you to reuse. You need to write a new spi driver to use the controller as a spi flash controller with limited transfer capability, using spi-mem interface available since linux v4.18. > Another thing, I noticed "master->num_chipselect = 2;" in the driver, > is there a reason for this limit, rather than 8 as rs_slave_sel is 3 > bits? (or 7 to keep device 7 as non-existent) ? This controller was known to be used on mt7621/mt76x8 only. Both mt7621 and mt7628 only have 2 chipselect pins exposed. As it's unlikely to be used on any other new SoCs, it's filled with the actual available chipselects, which is 2. -- Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ramips: replace obsolete mx25l25635f hack
Hi! On Fri, Jan 22, 2021 at 11:28 AM DENG Qingfang wrote: > > Hi, > > On Thu, Jan 21, 2021 at 5:37 PM David Bauer wrote: > > > > Is this dependent on board design? The need for the old hack should be > > fixed by > > this upstream commit [0]. Given that commit adds SNOR_F_4B_OPCODES for the > > mx25l25635f, it should in turn disable the hack enabled by > > broken-flash-reset, as > > this is dependend on 4B opcodes not being supported. [1] > > I'm aware of the upstream fix, but some Youku-YK1 users have reported > their routers cannot survive a reboot on kernel 5.4, but are fine on > 4.14 (with the mx25l25635f dts hack) [0]. Some Youku-YK1 uses Winbond W25Q256FV, and we used to have a hack similar to current broken-flash-reset for all W25Q256FV in 4.14. (It's called 4B_READ_OP or something) You only need the broken-flash-reset for this specific model. > So, adding broken-flash-reset serves as a fail-safe. It's not added as a replacement for "mx25l25635f" compatible string, so I think it should be dropped from this patch or moved into a separated one. -- Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Initial flashing over "OEM-OpenWrt"
Hi! On Sun, Feb 7, 2021 at 12:49 AM Adrian Schmutzler wrote: > > Hi, > > when reviewing device-support PRs, I frequently encounter the case that > initial flashing means sysupgrading from an OEM-modified OpenWrt. > > This obviously means that the config of this OEM-OpenWrt should be wiped to > prevent config-clashes, but since we only provide sysupgrade in this case we > can only tell the user to do so. > > In this context, I wonder whether we should exploit the compat_version for > that purpose, i.e. make the initial "proper" OpenWrt image version 1.1. > Since the OEM-OpenWrt won't know about compat_version, this technically will > have the same effect as removing SUPPORTED_DEVICES, i.e. the user will need > to use -F (and we still can't check whether he uses the necessary -F -n). Wouldn't the same message annoy all current OpenWrt users as OpenWrt 19.07 and older don't know about compat_version either? > However, the compat_version approach will give us the chance to show an > additional message, and thus at least will allow to instruct the user during > the upgrade itself, and not just in the Wiki or in the commit message (which > he might or might not read). > > The purpose of this e-mail is thus to ask: > 1. Do we need this, or do we just expect the user to care, i.e. if he breaks > the device by keeping config it's his fault? Fixing this kind of breakage is as simple as pressing down the reset button if we have the reset button properly defined. I think that's a fair price to pay for not reading the instructions :D -- Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ramips: overwrite reset gpio properties in DIR-860L DTS
Hi!
On Sat, Feb 13, 2021 at 5:55 PM Stijn Segers wrote:
>
> As suggested by Sergio, this adds GPIOs 19 and 8 explicitly into the
> DIR-860L DTS, so the PCI-E ports get reset and the N radio (radio1)
> on PCI-E port 1 comes up reliably.
>
> Fixes the following error that popped up in dmesg:
>
> [1.638942] mt7621-pci 1e14.pcie: pcie1 no card, disable it (RST &
> CLK)
>
> Suggested-by: Sergio Paracuellos
> Signed-off-by: Stijn Segers
> ---
> target/linux/ramips/dts/mt7621_dlink_dir-860l-b1.dts | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/target/linux/ramips/dts/mt7621_dlink_dir-860l-b1.dts
> b/target/linux/ramips/dts/mt7621_dlink_dir-860l-b1.dts
> index 5d1c336736..65d53e4ef4 100644
> --- a/target/linux/ramips/dts/mt7621_dlink_dir-860l-b1.dts
> +++ b/target/linux/ramips/dts/mt7621_dlink_dir-860l-b1.dts
> @@ -142,6 +142,12 @@
> };
>
> &pcie {
> + pinctrl-names = "default";
pinctrl-names is already "default" in mt7621.dtsi.
> + pinctrl-0 = <&pcie_pins>;
pinctrl-0 is already pcie_pins in mt7621.dtsi as well.
I'm fine with just dropping these two lines due to the fact that
we mainly used state_default to set up pinctrl in ramips.
(Ideally a separated pinctrl node with uart3 as gpio should be
defined and referenced here.)
> +
> + reset-gpios = <&gpio 19 GPIO_ACTIVE_LOW>,
> + <&gpio 8 GPIO_ACTIVE_LOW>;
> +
> status = "okay";
> };
>
--
Regards,
Chuanhong Guo
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ramips: add support for TOTOLINK X5000R
Hi! On Sat, Mar 13, 2021 at 7:27 AM Bas Mevissen wrote: > > Hi, > > Thanks for creating this patch. Got my X5000R today. Before flashing it > to OpenWRT, can you please tell me whether you (or anyone else) did > performance measurements with the original and the OpenWRT firmware? The wifi chip used in this router wasn't supported by mt76 when I created this patch, so my X5000R has no wifi now and I don't have any wireless performance numbers. My X5000R has been sitting on the shelf since I posted this patch, and I don't even know whether the mt7915d used in this router is supported now or not. You should probably ask TOTOLINK for a copy of the original firmware image before trying OpenWrt, so that you can go back to the original firmware if needed. (A forced sysupgrade from OpenWrt using their firmware image should work.) -- Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 2/2] ramips: enable TRGMII on Ubiquiti ER-X{,-SFP}
Hi! On Tue, Mar 16, 2021 at 1:33 PM Ilya Lipnitskiy wrote: > > TRGMII allows to run the CPU switch port 6 and GMAC0 at 1.2 Gb. This > change should improve performance. Both ER-X and ER-X-SFP have DDR3 RAM, > allowing them to take advantage of TRGMII: NACK on patch 2/2 unless someone managed to implement audio PLL clock support for TRGMII. (I can only find a implementation in the raeth driver of the old mtk openwrt sdk based on barrier breaker, and it's writing magic values into a bunch of undocumented registers.) Not every mt7621 router using DDR3 ram can enable TRGMII. The actual requirement is the 1200MHz memory clock, because TRGMII needs an extra clock either derived from memory clock or audio PLL. Current upstream driver only implemented the former, and enabling TRGMII will break ethernet for those who replaced their bootloader or for some other reason don't have their memory running at exactly 1200MHz. I think it doesn't worth to potentially brick someone's router for this extra 200Mbps bandwidth on CPU port. -- Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/2] kernel: backports: mt7530: fix TRGMII mode after reset
On Tue, Mar 16, 2021 at 1:33 PM Ilya Lipnitskiy
wrote:
>
> Backport upstream patch that fixes TRGMII mode now that mt7530 is
> actually resetting the switch on ramips devices.
>
> Patches apply to both Linux 5.4 and 5.10, since TRGMII is broken on both.
>
> Fixes: 69551a244292 ("ramips: manage low reset lines")
> Signed-off-by: Ilya Lipnitskiy
Merged. I'll push it after a build test.
Thanks!
--
Regards,
Chuanhong Guo
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] mediatek/mt7629: specify CPU_SUBTYPE as neon-vfpv4
Hi! On Fri, Apr 2, 2021 at 9:05 PM Rui Salvaterra wrote: > > In Cortex-A7, VFPv4 and NEON aren't optional. It is, and mt7629 does have a Cortex A7 without FPU according to the datasheet and SDK code. NACK. -- Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ramips: gpio-ralink: use ngpios, not ralink,num-gpios
Hi! On Thu, Apr 8, 2021 at 6:41 AM Ilya Lipnitskiy wrote: > > On Wed, Apr 7, 2021 at 2:46 AM Sander Vanheule wrote: > > > > Hi Ilya, > > > > On Mon, 2021-04-05 at 22:53 -0700, Ilya Lipnitskiy wrote: > > > DTS properties that match *-gpios are treated specially. > > > > > > Use ngpios instead, as most GPIO drivers upstream do. > > > > > > Fixes 5.10 DTS errors such as: > > > OF: /palmbus@30/gpio@600: could not find phandle > > > > > > Fixes DTC warnings such as: > > > Warning (gpios_property): /palmbus@30/gpio@600:ralink,num- > > > gpios: > > > Could not get phandle node for (cell 0) > > > > > > Signed-off-by: Ilya Lipnitskiy > > > Cc: Daniel Golle > > > --- > > > > > > > [...] > > > > > diff --git a/target/linux/ramips/patches-5.10/802-GPIO-MIPS-ralink- > > > add-gpio-driver-for-ralink-SoC.patch b/target/linux/ramips/patches- > > > 5.10/802-GPIO-MIPS-ralink-add-gpio-driver-for-ralink-SoC.patch > > > index 141d29f9401c..c173336924d2 100644 > > > --- a/target/linux/ramips/patches-5.10/802-GPIO-MIPS-ralink-add-gpio- > > > driver-for-ralink-SoC.patch > > > +++ b/target/linux/ramips/patches-5.10/802-GPIO-MIPS-ralink-add-gpio- > > > driver-for-ralink-SoC.patch > > > @@ -357,7 +357,7 @@ Cc: linux-g...@vger.kernel.org > > > + return -EINVAL; > > > + } > > > + > > > -+ ngpio = of_get_property(np, "ralink,num-gpios", NULL); > > > ++ ngpio = of_get_property(np, "ngpios", NULL); > > > > I guess you just went for the smallest patch that fixes the errors and > > warnings? > Correct, the goal of this patch was just to rename "ralink,num-gpios" > to "ngpios". > > > > > Based on my recent experience with linux-gpio, I think more things > > would need to change too, for the driver to be upstream-compatible. But > > I don't know what your plans are with this driver, so maybe this quick > > fix is sufficient for OpenWrt. > I wasn't planning on fixing all issues and upstreaming the driver, but > may attempt that in the future. Just trying to make a step in the > right direction here and save people time so they don't see these > errors/warnings. This whole driver probably needs a complete rewrite if you want to upstream it. Multiple gpio nodes should be merged into one, bgpio_init should be used to replace our current manual register operations, and this num-gpios is a SoC-specific property, which should be hard-coded in the driver and distinguished using compatible strings. I think current upstream gpio driver for mt7621 is a good start point. It's on my to-do list but I probably won't find any time for it before June. -- Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ath79: drop cs-gpios property
Hi! On Fri, Apr 16, 2021 at 4:43 AM David Bauer wrote: > > The spi-ath79 driver performs the chipselect by writing to dedicated > register in the SPI register block. So the GPIO numbers were not used. This is cs-gpios is a hack to override incorrect num_chipselects in spi-ath79 driver (which is set to fixed 1). spi-ath79 should be patched to fix this problem before cs-gpios for ar7161/ar7242 devices can be dropped. It's not needed on ar9344 because the new spi-ar934x driver doesn't have this problem. -- Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ath79: drop cs-gpios property
Hi! On Fri, Apr 16, 2021 at 6:23 PM David Bauer wrote: > > Hi, > > On 4/16/21 4:12 AM, Chuanhong Guo wrote: > > Hi! > > > > On Fri, Apr 16, 2021 at 4:43 AM David Bauer wrote: > >> > >> The spi-ath79 driver performs the chipselect by writing to dedicated > >> register in the SPI register block. So the GPIO numbers were not used. > > > > This is cs-gpios is a hack to override incorrect num_chipselects in > > spi-ath79 > > driver (which is set to fixed 1). spi-ath79 should be patched to fix > > this problem > > before cs-gpios for ar7161/ar7242 devices can be dropped. > > Thanks for the hint, i missed ar93xx uses the newer SPI driver. > > Looking at spi-ath79, the number of CS lines can be modified using platform > data, however all datasheets from ar71xx up to qca956x i could get my hand on > list 3 chipselect lines available - so a patch which sets the CS count to 3 > should be sufficient? Correct. -- Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/3] ramips: lzma-loader: make FLASH_START configurable
FLASH_START is supposed to point at the memory area where NOR flash are
mapped. We currently have an incorrect FLASH_START copied from ar71xx
back then and the loader doesn't work under OKLI mode.
On ramips, mt7621 has it's flash mapped to 0x1fc0 and other SoCs
uses 0x1c00. This commit makes FLASH_START a configurable value to
handle both cases.
Signed-off-by: Chuanhong Guo
---
target/linux/ramips/image/lzma-loader/Makefile | 2 ++
target/linux/ramips/image/lzma-loader/src/Makefile | 5 +
target/linux/ramips/image/lzma-loader/src/loader.c | 5 +
3 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/target/linux/ramips/image/lzma-loader/Makefile
b/target/linux/ramips/image/lzma-loader/Makefile
index f22151c9d7..4cf700d8c6 100644
--- a/target/linux/ramips/image/lzma-loader/Makefile
+++ b/target/linux/ramips/image/lzma-loader/Makefile
@@ -13,6 +13,7 @@ LOADER:= loader.bin
LOADER_NAME:= $(basename $(notdir $(LOADER)))
LOADER_DATA:=
TARGET_DIR :=
+FLASH_START:=
FLASH_OFFS :=
FLASH_MAX :=
BOARD :=
@@ -40,6 +41,7 @@ loader-compile: $(PKG_BUILD_DIR)/.prepared
$(MAKE) -C $(PKG_BUILD_DIR) CROSS_COMPILE="$(TARGET_CROSS)" \
LZMA_TEXT_START=$(LZMA_TEXT_START) \
LOADER_DATA=$(LOADER_DATA) \
+ FLASH_START=$(FLASH_START) \
FLASH_OFFS=$(FLASH_OFFS) \
FLASH_MAX=$(FLASH_MAX) \
BOARD="$(BOARD)" \
diff --git a/target/linux/ramips/image/lzma-loader/src/Makefile
b/target/linux/ramips/image/lzma-loader/src/Makefile
index d20cd77346..97fd6dad47 100644
--- a/target/linux/ramips/image/lzma-loader/src/Makefile
+++ b/target/linux/ramips/image/lzma-loader/src/Makefile
@@ -19,6 +19,7 @@ LOADADDR :=
LZMA_TEXT_START:= 0x80a0
LOADER_DATA:=
BOARD :=
+FLASH_START:=
FLASH_OFFS :=
FLASH_MAX :=
PLATFORM :=
@@ -64,6 +65,10 @@ ifneq ($(strip $(KERNEL_CMDLINE)),)
CFLAGS += -DCONFIG_KERNEL_CMDLINE='"$(KERNEL_CMDLINE)"'
endif
+ifneq ($(strip $(FLASH_START)),)
+CFLAGS += -DCONFIG_FLASH_START=$(FLASH_START)
+endif
+
ifneq ($(strip $(FLASH_OFFS)),)
CFLAGS += -DCONFIG_FLASH_OFFS=$(FLASH_OFFS)
endif
diff --git a/target/linux/ramips/image/lzma-loader/src/loader.c
b/target/linux/ramips/image/lzma-loader/src/loader.c
index c73b60b351..a3513eccf1 100644
--- a/target/linux/ramips/image/lzma-loader/src/loader.c
+++ b/target/linux/ramips/image/lzma-loader/src/loader.c
@@ -28,9 +28,6 @@
#include "printf.h"
#include "LzmaDecode.h"
-#define AR71XX_FLASH_START 0x1f00
-#define AR71XX_FLASH_END 0x1fe0
-
#define KSEG0 0x8000
#define KSEG1 0xa000
@@ -178,7 +175,7 @@ static void lzma_init_data(void)
unsigned long kernel_ofs;
unsigned long kernel_size;
- flash_base = (unsigned char *) KSEG1ADDR(AR71XX_FLASH_START);
+ flash_base = (unsigned char *) KSEG1ADDR(CONFIG_FLASH_START);
printf("Looking for OpenWrt image... ");
--
2.26.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 3/3] ramips: image: example usage of OKLI loader
This is an example of using OKLI loader and will not be part of final commits. First uImage header covers loader + kernel so that the original firmware mtdsplit can be used. --- target/linux/ramips/image/Makefile | 10 ++ target/linux/ramips/image/mt7620.mk | 1 + target/linux/ramips/image/mt7621.mk | 2 +- 3 files changed, 12 insertions(+), 1 deletion(-) diff --git a/target/linux/ramips/image/Makefile b/target/linux/ramips/image/Makefile index 10e9edd3bb..b985882897 100644 --- a/target/linux/ramips/image/Makefile +++ b/target/linux/ramips/image/Makefile @@ -224,6 +224,16 @@ define Device/uimage-lzma-loader KERNEL := kernel-bin | append-dtb | lzma | loader-kernel | uImage none endef +define Device/uimage-okli-loader + LOADER_TYPE := bin + LOADER_FLASH_OFFS := 0x51000 + COMPILE := loader-$(1).bin + COMPILE/loader-$(1).bin := loader-okli-compile + KERNEL := kernel-bin | append-dtb | lzma | uImage lzma -M 0x4f4b4c49 + KERNEL_INITRAMFS := kernel-bin | append-dtb | lzma | uImage lzma + IMAGE/sysupgrade.bin := append-loader-okli $(1) | pad-to 16k | lzma | pad-to 4032 | append-kernel | uImage lzma | append-rootfs | pad-rootfs | append-metadata | check-size +endef + include $(SUBTARGET).mk $(eval $(call BuildImage)) diff --git a/target/linux/ramips/image/mt7620.mk b/target/linux/ramips/image/mt7620.mk index 0cfaa95cf0..fa8c303903 100644 --- a/target/linux/ramips/image/mt7620.mk +++ b/target/linux/ramips/image/mt7620.mk @@ -599,6 +599,7 @@ endef TARGET_DEVICES += lb-link_bl-w1200 define Device/lenovo_newifi-y1 + $(Device/uimage-okli-loader) SOC := mt7620a IMAGE_SIZE := 16064k DEVICE_VENDOR := Lenovo diff --git a/target/linux/ramips/image/mt7621.mk b/target/linux/ramips/image/mt7621.mk index d2d41be269..a15d7e25af 100644 --- a/target/linux/ramips/image/mt7621.mk +++ b/target/linux/ramips/image/mt7621.mk @@ -614,7 +614,7 @@ TARGET_DEVICES += jcg_jhr-ac876m define Device/lenovo_newifi-d1 $(Device/dsa-migration) - $(Device/uimage-lzma-loader) + $(Device/uimage-okli-loader) IMAGE_SIZE := 32448k DEVICE_VENDOR := Newifi DEVICE_MODEL := D1 -- 2.26.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 0/3] ramips: fix OKLI lzma-loader
OKLI mode of our lzma-loader in ramips still contains left-over bits from ar71xx and isn't used before. This patchset fixes it so that it can be used in future devices. (e.g. https://github.com/openwrt/openwrt/pull/2645) Chuanhong Guo (3): ramips: lzma-loader: make FLASH_START configurable ramips: image: add recipe for OKLI loader ramips: image: example usage of OKLI loader target/linux/ramips/image/Makefile| 28 ++- .../linux/ramips/image/lzma-loader/Makefile | 2 ++ .../ramips/image/lzma-loader/src/Makefile | 5 .../ramips/image/lzma-loader/src/loader.c | 5 +--- target/linux/ramips/image/mt7620.mk | 1 + target/linux/ramips/image/mt7621.mk | 2 +- 6 files changed, 37 insertions(+), 6 deletions(-) -- 2.26.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/3] ramips: image: add recipe for OKLI loader
Signed-off-by: Chuanhong Guo --- target/linux/ramips/image/Makefile | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/target/linux/ramips/image/Makefile b/target/linux/ramips/image/Makefile index f5166f8ae1..10e9edd3bb 100644 --- a/target/linux/ramips/image/Makefile +++ b/target/linux/ramips/image/Makefile @@ -7,7 +7,7 @@ include $(TOPDIR)/rules.mk include $(INCLUDE_DIR)/image.mk -DEVICE_VARS += LOADER_TYPE +DEVICE_VARS += LOADER_TYPE LOADER_FLASH_OFFS DEVICE_VARS += NETGEAR_BOARD_ID NETGEAR_HW_ID DEVICE_VARS += BUFFALO_TAG_PLATFORM BUFFALO_TAG_VERSION BUFFALO_TAG_MINOR DEVICE_VARS += SEAMA_SIGNATURE SEAMA_MTDBLOCK @@ -21,8 +21,12 @@ loadaddr-$(CONFIG_TARGET_ramips_mt7621) := 0x80001000 ldrplatform-y := ralink ldrplatform-$(CONFIG_TARGET_ramips_mt7621) := mt7621 +ldrflashstart-y := 0x1c00 +ldrflashstart-$(CONFIG_TARGET_ramips_mt7621) := 0x1fc0 + KERNEL_LOADADDR := $(loadaddr-y) LOADER_PLATFORM := $(ldrplatform-y) +LOADER_FLASH_START := $(ldrflashstart-y) KERNEL_DTB = kernel-bin | append-dtb | lzma @@ -74,6 +78,18 @@ define Build/loader-kernel $(call Build/loader-common,LOADER_DATA="$@") endef +define Build/loader-okli-compile + $(call Build/loader-common, \ + FLASH_START=$(LOADER_FLASH_START) \ + FLASH_OFFS=$(LOADER_FLASH_OFFS) \ + FLASH_MAX=0 \ + ) +endef + +define Build/append-loader-okli + cat "$(KDIR)/loader-$(word 1,$(1)).$(LOADER_TYPE)" >> "$@" +endef + # combine kernel and rootfs into one image # mkdlinkfw define Build/mkdlinkfw -- 2.26.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/3] ramips: lzma-loader: make FLASH_START configurable
Hi! On Thu, Sep 3, 2020 at 1:03 AM Adrian Schmutzler wrote: > > --- a/target/linux/ramips/image/lzma-loader/src/loader.c > > +++ b/target/linux/ramips/image/lzma-loader/src/loader.c > > @@ -28,9 +28,6 @@ > > #include "printf.h" > > #include "LzmaDecode.h" > > > > -#define AR71XX_FLASH_START 0x1f00 > > -#define AR71XX_FLASH_END 0x1fe0 > > - > > Am I understanding this right, that if FLASH_START is not defined and set in > ramips/image/Makefile, then compilation will fail here as the > CONFIG_FLASH_START symbol is not defined? That's my intention. It'll actually fail... > > #define KSEG00x8000 > > #define KSEG10xa000 > > > > @@ -178,7 +175,7 @@ static void lzma_init_data(void) > > unsigned long kernel_ofs; > > unsigned long kernel_size; > > > > - flash_base = (unsigned char *) KSEG1ADDR(AR71XX_FLASH_START); > > + flash_base = (unsigned char *) KSEG1ADDR(CONFIG_FLASH_START); ...here. It'll fail if CONFIG_FLASH_START isn't defined and no lzma blob is provided. -- Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 0/3] ramips: fix OKLI lzma-loader
Hi! On Thu, Sep 3, 2020 at 1:00 AM Adrian Schmutzler wrote: > Thanks for taking care of that. In case you haven't read already, I have > tidied up/rebased the Hootoo PR onto these changes here: > https://git.openwrt.org/?p=openwrt/staging/adrian.git;a=shortlog;h=refs/heads/hootoo > > Those are tested by the author now. > > Depending on what you prefer, I'd either wait for you to merge your two > commits and then push the final one, or just merge all three myself. Feel free to merge all 3 patches :) -- Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ath79: ar8216: make switch register access atomic
reg accesses on integrated ar8229 sometimes fails. As a result, phy read
got incorrect port status and wan link goes down and up mysteriously.
After comparing ar8216 with the old driver, these local_irq_save/restore
calls are the only meaningful differences I could find and it does fix
the issue.
The same changes were added in svn r26856 by Gabor Juhos:
ar71xx: ag71xx: make switch register access atomic
As I can't find the underlying problem either, this hack is broght
back to fix the unstable link issue.
This hack is only suitable for ath79 mdio and may easily break the
driver on other platform. Limit it to ath79-only as a target patch.
Fixes: FS#2216
Fixes: FS#3226
Signed-off-by: Chuanhong Guo
---
.../930-ar8216-make-reg-access-atomic.patch | 61 +++
1 file changed, 61 insertions(+)
create mode 100644
target/linux/ath79/patches-5.4/930-ar8216-make-reg-access-atomic.patch
diff --git
a/target/linux/ath79/patches-5.4/930-ar8216-make-reg-access-atomic.patch
b/target/linux/ath79/patches-5.4/930-ar8216-make-reg-access-atomic.patch
new file mode 100644
index 00..42f3305195
--- /dev/null
+++ b/target/linux/ath79/patches-5.4/930-ar8216-make-reg-access-atomic.patch
@@ -0,0 +1,61 @@
+From b3797d1a92afe97c173b00fdb7824cedba24eef0 Mon Sep 17 00:00:00 2001
+From: Chuanhong Guo
+Date: Sun, 20 Sep 2020 01:00:45 +0800
+Subject: [PATCH] ath79: ar8216: make switch register access atomic
+
+due to some unknown reason these register accesses sometimes fail
+on the integrated switch without this patch.
+
+THIS ONLY WORKS ON ATH79 AND MAY BREAK THE DRIVER ON OTHER PLATFORMS!
+The mdio bus on ath79 works in polling mode and doesn't rely on
+any interrupt. This patch breaks the driver on any mdio master
+with interrupts used.
+
+---
+--- a/drivers/net/phy/ar8216.c
b/drivers/net/phy/ar8216.c
+@@ -253,12 +253,14 @@ ar8xxx_mii_write32(struct ar8xxx_priv *p
+ u32
+ ar8xxx_read(struct ar8xxx_priv *priv, int reg)
+ {
++ unsigned long flags;
+ struct mii_bus *bus = priv->mii_bus;
+ u16 r1, r2, page;
+ u32 val;
+
+ split_addr((u32) reg, &r1, &r2, &page);
+
++ local_irq_save(flags);
+ mutex_lock(&bus->mdio_lock);
+
+ bus->write(bus, 0x18, 0, page);
+@@ -266,6 +268,7 @@ ar8xxx_read(struct ar8xxx_priv *priv, in
+ val = ar8xxx_mii_read32(priv, 0x10 | r2, r1);
+
+ mutex_unlock(&bus->mdio_lock);
++ local_irq_restore(flags);
+
+ return val;
+ }
+@@ -273,11 +276,13 @@ ar8xxx_read(struct ar8xxx_priv *priv, in
+ void
+ ar8xxx_write(struct ar8xxx_priv *priv, int reg, u32 val)
+ {
++ unsigned long flags;
+ struct mii_bus *bus = priv->mii_bus;
+ u16 r1, r2, page;
+
+ split_addr((u32) reg, &r1, &r2, &page);
+
++ local_irq_save(flags);
+ mutex_lock(&bus->mdio_lock);
+
+ bus->write(bus, 0x18, 0, page);
+@@ -285,6 +290,7 @@ ar8xxx_write(struct ar8xxx_priv *priv, i
+ ar8xxx_mii_write32(priv, 0x10 | r2, r1, val);
+
+ mutex_unlock(&bus->mdio_lock);
++ local_irq_restore(flags);
+ }
+
+ u32
--
2.26.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: mac80211: Fixed a bug: STA disconnects frequently
Hi! On Mon, Sep 21, 2020 at 4:49 PM Georgi Valkov wrote: > Please grant me write access to OpenWRT, so I can contribute other important > fixes in the future, such as: > https://github.com/openwrt/openwrt/pull/3391 That's totally not how the development of OpenWrt works. Please take your time to read OpenWrt contribution guidelines [0] and fix all the formal issues first. [0] https://openwrt.org/submitting-patches -- Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ath79: ar8216: make switch register access atomic
Hi! On Mon, Sep 21, 2020 at 9:24 PM Felix Fietkau wrote: > > + > > + split_addr((u32) reg, &r1, &r2, &page); > > + > > ++local_irq_save(flags); > > + mutex_lock(&bus->mdio_lock); > Taking a mutex in an irq-disabled section is basically asking for a > deadlock. What router is this issue reproduced on? Any ar934x/qca953x router using built-in switch, based on Flyspray bug reports. I can reproduce it on ar9341/tp-link-wr841n-v8 As there's an ancient commit about the same issue I guess it appears on ar724x/ar933x as well. here's the commit message: commit 5d77f370d695c9a70f25ffb8367db64efadaaedd Author: Gabor Juhos Date: Sun May 8 16:32:53 2011 + ar71xx: ag71xx: make switch register access atomic Reading of the PHY registers occasionally returns with bogus values under heavy load. This misleads the PHY driver and thus causes false link/speed change notifications which leads to performance loss. [and some dmesg after this] > What else is running at the time this happens? I'm using a minimal wr841n-v8 image. (make menuconfig, select the device, save and build the firmware) no extra background tasks are running. swconfig led trigger is used so the kernel is constantly polling port status from switch in the background. -- Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ath79: ar8216: make switch register access atomic
Hi! On Tue, Sep 22, 2020 at 12:37 AM Felix Fietkau wrote: > You could try making a global spinlock in ag71xx_mdio.c and do > spin_lock_bh(&mdio_lock) in ag71xx_mdio_mii_read and ag71xx_mdio_mii_write I've just tried that and it doesn't work. Should I move local_irq_save below mutex_lock and send a v2 or do you have other suggestions? -- Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v4 1/4] ipq806x: add support for Linksys E8350 v1
Hi! On Tue, Sep 29, 2020 at 2:00 AM Todor Colov wrote: > --- a/target/linux/ipq806x/image/Makefile > +++ b/target/linux/ipq806x/image/Makefile > @@ -13,6 +13,17 @@ define Build/buffalo-rootfs-cksum > ) >> $@ > endef > > +# tune addpattern for Linksys E8350-V1 fw pattern generation > +define Build/linksys-bin > +$(STAGING_DIR_HOST)/bin/addpattern -p $(FW_DEVICE_ID) -v > $(FW_VERSION) $(if $(SERIAL),-s $(SERIAL)) -i $@ -o $@.new > +mv $@.new $@ > +endef > +# Use Linksys fw header generator to upgrade openwrt factory image over the > native Linksys WEB interface > +define Build/linksys-addfwhdr > +-$(STAGING_DIR_HOST)/bin/addfwhdr -i $@ -o $@.new \ > + ;mv "$@.new" "$@" > +endef > + > define Device/Default > PROFILES := Default > KERNEL_DEPENDS = $$(wildcard $(DTS_DIR)/$$(DEVICE_DTS).dts) > @@ -122,6 +133,24 @@ define Device/edgecore_ecw5410 > endef > TARGET_DEVICES += edgecore_ecw5410 > > +define Device/linksys_e8350-v1 > +$(call Device/LegacyImage) > +DEVICE_VENDOR := Linksys > +DEVICE_MODEL := E8350 > +DEVICE_VARIANT := v1 > +SOC := qcom-ipq8064 > +FW_VERSION := v1.0.03.003 > +FW_DEVICE_ID := 8350 > +PAGESIZE := 2048 > +BLOCKSIZE := 128k > +KERNEL_IN_UBI := 1 > +IMAGES = factory.bin sysupgrade.ubi > +IMAGE/sysupgrade.ubi := append-ubi | check-size 0x0400 | > append-metadata Could you try the tar sysupgrade package instead? Replace this line with: IMAGE/sysupgrade.bin = sysupgrade-tar | append-metadata The resulting sysupgrade.bin should work without other changes. When ubi image is used for sysupgrade, the entire ubi partition is reformatted, which is suboptimal. -- Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ath79: ar8216: make switch register access atomic
Hi! On Sun, Oct 4, 2020 at 12:33 PM Baptiste Jonglez wrote: > > Hi, > > Thanks a lot for fixing this! > > Can you backport it to openwrt-19.07? ath79 is also affected there. backport pushed. -- Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ramips: add support for TOTOLINK X5000R
Specifications:
- SoC: MT7621AT
- RAM: 256MB
- Flash: 16MB (EN25QH128A)
- Ethernet: 5xGbE
- WiFi: MT7915 2x2 2.4G 573.5Mbps + 2x2 5G 1201Mbps
Known issue:
MT7915 DBDC variant isn't supported yet.
Flash instruction:
Upload the sysupgrade firmware to the firmware upgrade page in
vendor fw.
Other info:
MT7915 seems to have two PCIEs connected to MT7621. Card detected on
PCIE0 has an ID of 14c3:7916 and the other one on PCIE1 has 14c3:7915.
Signed-off-by: Chuanhong Guo
---
.../ramips/dts/mt7621_totolink_x5000r.dts | 139 ++
target/linux/ramips/image/mt7621.mk | 10 ++
2 files changed, 149 insertions(+)
create mode 100644 target/linux/ramips/dts/mt7621_totolink_x5000r.dts
diff --git a/target/linux/ramips/dts/mt7621_totolink_x5000r.dts
b/target/linux/ramips/dts/mt7621_totolink_x5000r.dts
new file mode 100644
index 00..b05d83978d
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_totolink_x5000r.dts
@@ -0,0 +1,139 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "mt7621.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "totolink,x5000r", "mediatek,mt7621-soc";
+ model = "TOTOLINK X5000R";
+
+ aliases {
+ led-boot = &led_sys;
+ led-failsafe = &led_sys;
+ led-running = &led_sys;
+ led-upgrade = &led_sys;
+ label-mac-device = &gmac0;
+ serial0 = &uartlite;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ bootargs = "console=ttyS0,115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_sys: sys {
+ label = "blue:sys";
+ gpios = <&gpio 18 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ reset {
+ label = "reset";
+ gpios = <&gpio 4 GPIO_ACTIVE_LOW>;
+ debounce-interval = <60>;
+ linux,code = ;
+ };
+ };
+};
+
+&spi0 {
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <5000>;
+ m25p,fast-read;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "u-boot";
+ reg = <0x0 0x3>;
+ read-only;
+ };
+
+ partition@3 {
+ label = "u-boot-env";
+ reg = <0x3 0x1>;
+ read-only;
+ };
+
+ factory: partition@4 {
+ label = "factory";
+ reg = <0x4 0x1>;
+ read-only;
+ };
+
+ partition@5 {
+ compatible = "denx,uimage";
+ label = "firmware";
+ reg = <0x5 0xfb>;
+ };
+ };
+ };
+};
+
+&pcie {
+ status = "okay";
+};
+
+&pcie1 {
+ wifi@0,0 {
+ compatible = "mediatek,mt76";
+ reg = <0x 0 0 0 0>;
+ mediatek,mtd-eeprom = <&factory 0x>;
+ };
+};
+
+&gmac0 {
+ mtd-mac-address = <&factory 0xe000>;
+};
+
+&switch0 {
+ ports {
+ port@0 {
+ status = "okay";
+ label = "lan1";
+ };
+
+ port@1 {
+ status = "okay";
+ label = "lan2";
+ };
+
+ port@2 {
+ status = "okay";
+ label = "lan3";
+ };
+
+ port@3 {
+ status = "okay";
+ label = "lan4";
+ };
+
+ port@4 {
+ status = "okay";
+ label = "wan";
+ mtd-mac-address = <&factory 0xe006>;
+ };
+ };
+};
+
+&state_default {
+ gpio {
+
Re: [PATCH] ath79: drop num-cs for SPI controller
Hi! On Mon, Nov 30, 2020 at 1:05 AM Adrian Schmutzler wrote: > > None of the spi drivers on ath79 uses the num-cs property. > > Cc: Chuanhong Guo > Signed-off-by: Adrian Schmutzler Acked-by: Chuanhong Guo -- Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Why ath79 firmware can not write to different size flash as ar71xx firmware did.
If you mean TP-Link devices, yes, you need to create separated dts for different flash size. Currently the mtd parser "tplinkpart" isn't available on ath79 so we can't make mtd partitions automatically detected. xinglp 于2018年8月15日周三 上午11:29写道： > > I have some same model devices, but they have different size of flash, > 4MB 8MB 16MB. > They all work well with same ar71xx firmware. But when I update them > with ath79 firmware, then can only recognize 4MB space. > Do I have to write DTS file for each sizes of flash ? > > Thanks. > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [RFC] ath79: ag71xx: apply interface mode to MII0/1_CNTL on ar71xx/ar913x
Signed-off-by: Chuanhong Guo
---
RFC:
Previous discussion about this patch can be found on GitHub PR#1271.
This patch applies correct interface mode to MII0/1_CNTL register at 0x1807/
0x18070004. But there is a small difference in values for these two registers:
| GMAC0| GMAC1 |
|--|-|
| 0 GMII | 0 RGMII |
| 1 MII| 1 RMII |
| 2 RGMII | |
| 3 RMII | |
I currently have 4 ways of dealing with this:
1. Use a bool value in dts indicating whether this is the second GMAC. This one
is pretty dirty and I dropped it.
2. Split MII_CNTL into separated dt node and use different compatible for them
like we did for ETH_CFG (gmac node) on ar933x and later SoCs. After some
discussion
on GitHub it turns out to be unreasonable to treat those in separated nodes.
3. Use ar7100-eth0/ar7100-eth1 as compatible string. This is what I've done in
this patch I sent here. But I think my way of using compatible string here
is ugly :(
A possible cleaner implementation would be introducing
ar7100-eth0/ar7100-eth1/
ar9130-eth0/ar9130-eth1 to replace ar7100-eth/ar9130-eth. But I doubt whether
introducing 4 new compatible strings for such a slight difference is worthy.
4. Somehow write all the possible values for each interface mode in device tree.
e.g. qca,if-modes = "gmii","mii","rgmii","rmii"; for eth0 and
qca,if-modes = "rgmii","rmii"; for eth1.
Which one is better? Is there any other possible solutions for this problem?
target/linux/ath79/dts/ar7100.dtsi| 4 +-
target/linux/ath79/dts/ar9132.dtsi| 2 +-
.../net/ethernet/atheros/ag71xx/ag71xx_main.c | 61 +++
3 files changed, 64 insertions(+), 3 deletions(-)
diff --git a/target/linux/ath79/dts/ar7100.dtsi
b/target/linux/ath79/dts/ar7100.dtsi
index 8994a7d688..89c17bcede 100644
--- a/target/linux/ath79/dts/ar7100.dtsi
+++ b/target/linux/ath79/dts/ar7100.dtsi
@@ -171,7 +171,7 @@
};
ð0 {
- compatible = "qca,ar7100-eth";
+ compatible = "qca,ar7100-eth0", "qca,ar7100-eth";
reg = <0x1900 0x200
0x1807 0x4>;
@@ -189,7 +189,7 @@
};
ð1 {
- compatible = "qca,ar7100-eth";
+ compatible = "qca,ar7100-eth1", "qca,ar7100-eth";
reg = <0x1a00 0x200
0x18070004 0x4>;
diff --git a/target/linux/ath79/dts/ar9132.dtsi
b/target/linux/ath79/dts/ar9132.dtsi
index 9d8ddcf9ba..a136b06e69 100644
--- a/target/linux/ath79/dts/ar9132.dtsi
+++ b/target/linux/ath79/dts/ar9132.dtsi
@@ -185,7 +185,7 @@
};
ð0 {
- compatible = "qca,ar9130-eth", "syscon";
+ compatible = "qca,ar9130-eth", "qca,ar7100-eth0", "syscon";
reg = <0x1900 0x200
0x1807 0x4>;
pll-data = <0x1a00 0x13000a44 0x00441099>;
diff --git
a/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
b/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
index 1e0bb6937f..5ea9ef40d2 100644
--- a/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
+++ b/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
@@ -529,6 +529,60 @@ static void ath79_set_pll(struct ag71xx *ag)
udelay(100);
}
+static void ath79_mii_ctrl_set_if(struct ag71xx *ag, unsigned int mii_if)
+{
+ u32 t;
+
+ t = __raw_readl(ag->mii_base);
+ t &= ~(AR71XX_MII_CTRL_IF_MASK);
+ t |= (mii_if & AR71XX_MII_CTRL_IF_MASK);
+ __raw_writel(t, ag->mii_base);
+}
+
+static void ath79_mii0_ctrl_set_if(struct ag71xx *ag)
+{
+ unsigned int mii_if;
+
+ switch (ag->phy_if_mode) {
+ case PHY_INTERFACE_MODE_MII:
+ mii_if = AR71XX_MII0_CTRL_IF_MII;
+ break;
+ case PHY_INTERFACE_MODE_GMII:
+ mii_if = AR71XX_MII0_CTRL_IF_GMII;
+ break;
+ case PHY_INTERFACE_MODE_RGMII:
+ mii_if = AR71XX_MII0_CTRL_IF_RGMII;
+ break;
+ case PHY_INTERFACE_MODE_RMII:
+ mii_if = AR71XX_MII0_CTRL_IF_RMII;
+ break;
+ default:
+ WARN(1, "Impossible PHY mode defined.\n");
+ return;
+ }
+
+ ath79_mii_ctrl_set_if(ag, mii_if);
+}
+
+static void ath79_mii1_ctrl_set_if(struct ag71xx *ag)
+{
+ unsigned int mii_if;
+
+ switch (ag->phy_if_mode) {
+ case PHY_INTERFACE_MODE_RMII:
+ mii_if = AR71XX_MII1_CTRL_IF_RMII;
+ break;
+ case PHY_INTERFACE_MODE_RGMII:
+ mii_if = AR71XX_MII1_CTRL_IF_RGMII;
+ break;
+ default:
+ WARN(1, "Impossible PHY mode defined.\n");
+ return;
+ }
+
+ ath79_mii_ctrl_set_if(a
[OpenWrt-Devel] [PATCH v2] ath79: ag71xx: apply interface mode to MII0/1_CTRL on ar71xx/ar913x
Signed-off-by: Chuanhong Guo
---
Changes since that RFC patch:
Changed compatible string to ar7100-mii0/1-eth and
ar9130-mii0-eth/ar9132-mii1-eth. AR9130 dosen't have
a second gmac so I named the second one ar9132-mii1-eth.
target/linux/ath79/dts/ar7100.dtsi| 4 +-
target/linux/ath79/dts/ar9132.dtsi| 2 +-
.../net/ethernet/atheros/ag71xx/ag71xx_main.c | 102 +++---
3 files changed, 92 insertions(+), 16 deletions(-)
diff --git a/target/linux/ath79/dts/ar7100.dtsi
b/target/linux/ath79/dts/ar7100.dtsi
index 8994a7d688..bb3c10bdc5 100644
--- a/target/linux/ath79/dts/ar7100.dtsi
+++ b/target/linux/ath79/dts/ar7100.dtsi
@@ -171,7 +171,7 @@
};
ð0 {
- compatible = "qca,ar7100-eth";
+ compatible = "qca,ar7100-mii0-eth";
reg = <0x1900 0x200
0x1807 0x4>;
@@ -189,7 +189,7 @@
};
ð1 {
- compatible = "qca,ar7100-eth";
+ compatible = "qca,ar7100-mii1-eth";
reg = <0x1a00 0x200
0x18070004 0x4>;
diff --git a/target/linux/ath79/dts/ar9132.dtsi
b/target/linux/ath79/dts/ar9132.dtsi
index 9d8ddcf9ba..bf5e9c06fa 100644
--- a/target/linux/ath79/dts/ar9132.dtsi
+++ b/target/linux/ath79/dts/ar9132.dtsi
@@ -185,7 +185,7 @@
};
ð0 {
- compatible = "qca,ar9130-eth", "syscon";
+ compatible = "qca,ar9130-mii0-eth", "syscon";
reg = <0x1900 0x200
0x1807 0x4>;
pll-data = <0x1a00 0x13000a44 0x00441099>;
diff --git
a/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
b/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
index 1e0bb6937f..72c6673037 100644
--- a/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
+++ b/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
@@ -529,6 +529,60 @@ static void ath79_set_pll(struct ag71xx *ag)
udelay(100);
}
+static void ath79_mii_ctrl_set_if(struct ag71xx *ag, unsigned int mii_if)
+{
+ u32 t;
+
+ t = __raw_readl(ag->mii_base);
+ t &= ~(AR71XX_MII_CTRL_IF_MASK);
+ t |= (mii_if & AR71XX_MII_CTRL_IF_MASK);
+ __raw_writel(t, ag->mii_base);
+}
+
+static void ath79_mii0_ctrl_set_if(struct ag71xx *ag)
+{
+ unsigned int mii_if;
+
+ switch (ag->phy_if_mode) {
+ case PHY_INTERFACE_MODE_MII:
+ mii_if = AR71XX_MII0_CTRL_IF_MII;
+ break;
+ case PHY_INTERFACE_MODE_GMII:
+ mii_if = AR71XX_MII0_CTRL_IF_GMII;
+ break;
+ case PHY_INTERFACE_MODE_RGMII:
+ mii_if = AR71XX_MII0_CTRL_IF_RGMII;
+ break;
+ case PHY_INTERFACE_MODE_RMII:
+ mii_if = AR71XX_MII0_CTRL_IF_RMII;
+ break;
+ default:
+ WARN(1, "Impossible PHY mode defined.\n");
+ return;
+ }
+
+ ath79_mii_ctrl_set_if(ag, mii_if);
+}
+
+static void ath79_mii1_ctrl_set_if(struct ag71xx *ag)
+{
+ unsigned int mii_if;
+
+ switch (ag->phy_if_mode) {
+ case PHY_INTERFACE_MODE_RMII:
+ mii_if = AR71XX_MII1_CTRL_IF_RMII;
+ break;
+ case PHY_INTERFACE_MODE_RGMII:
+ mii_if = AR71XX_MII1_CTRL_IF_RGMII;
+ break;
+ default:
+ WARN(1, "Impossible PHY mode defined.\n");
+ return;
+ }
+
+ ath79_mii_ctrl_set_if(ag, mii_if);
+}
+
static void ath79_mii_ctrl_set_speed(struct ag71xx *ag)
{
unsigned int mii_speed;
@@ -573,8 +627,10 @@ __ag71xx_link_adjust(struct ag71xx *ag, bool update)
return;
}
- if (!of_device_is_compatible(np, "qca,ar9130-eth") &&
- !of_device_is_compatible(np, "qca,ar7100-eth"))
+ if (!of_device_is_compatible(np, "qca,ar9130-mii0-eth") &&
+ !of_device_is_compatible(np, "qca,ar9132-mii1-eth") &&
+ !of_device_is_compatible(np, "qca,ar7100-mii0-eth") &&
+ !of_device_is_compatible(np, "qca,ar7100-mii1-eth"))
ag71xx_fast_reset(ag);
cfg2 = ag71xx_rr(ag, AG71XX_REG_MAC_CFG2);
@@ -612,8 +668,10 @@ __ag71xx_link_adjust(struct ag71xx *ag, bool update)
ag71xx_wr(ag, AG71XX_REG_FIFO_CFG3, ag->fifodata[2]);
if (update) {
- if (of_device_is_compatible(np, "qca,ar7100-eth") ||
- of_device_is_compatible(np, "qca,ar9130-eth")) {
+ if (of_device_is_compatible(np, "qca,ar7100-mii0-eth") ||
+ of_device_is_compatible(np, "qca,ar7100-mii1-eth") ||
+ of_device_is_compatible(np, "qca,ar9130-mii0-eth") ||
+
[OpenWrt-Devel] [PATCH v2] ath79: ag71xx: apply interface mode to MII0/1_CTRL on ar71xx/ar913x
We currently don't have any code configuring interface mode in ath79,
meaning that we relies on bootloader to set the correct interface mode.
This patch added code to set interface correctly so that everything works
even if bootloader configures it wrong.(e.g. on WNDR3800 u-boot set
the second GMAC mode to RMII but it should be RGMII.)
Signed-off-by: Chuanhong Guo
---
Resend to add commit message.
target/linux/ath79/dts/ar7100.dtsi| 4 +-
target/linux/ath79/dts/ar9132.dtsi| 2 +-
.../net/ethernet/atheros/ag71xx/ag71xx_main.c | 102 +++---
3 files changed, 92 insertions(+), 16 deletions(-)
diff --git a/target/linux/ath79/dts/ar7100.dtsi
b/target/linux/ath79/dts/ar7100.dtsi
index 8994a7d688..bb3c10bdc5 100644
--- a/target/linux/ath79/dts/ar7100.dtsi
+++ b/target/linux/ath79/dts/ar7100.dtsi
@@ -171,7 +171,7 @@
};
ð0 {
- compatible = "qca,ar7100-eth";
+ compatible = "qca,ar7100-mii0-eth";
reg = <0x1900 0x200
0x1807 0x4>;
@@ -189,7 +189,7 @@
};
ð1 {
- compatible = "qca,ar7100-eth";
+ compatible = "qca,ar7100-mii1-eth";
reg = <0x1a00 0x200
0x18070004 0x4>;
diff --git a/target/linux/ath79/dts/ar9132.dtsi
b/target/linux/ath79/dts/ar9132.dtsi
index 9d8ddcf9ba..bf5e9c06fa 100644
--- a/target/linux/ath79/dts/ar9132.dtsi
+++ b/target/linux/ath79/dts/ar9132.dtsi
@@ -185,7 +185,7 @@
};
ð0 {
- compatible = "qca,ar9130-eth", "syscon";
+ compatible = "qca,ar9130-mii0-eth", "syscon";
reg = <0x1900 0x200
0x1807 0x4>;
pll-data = <0x1a00 0x13000a44 0x00441099>;
diff --git
a/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
b/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
index 1e0bb6937f..72c6673037 100644
--- a/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
+++ b/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
@@ -529,6 +529,60 @@ static void ath79_set_pll(struct ag71xx *ag)
udelay(100);
}
+static void ath79_mii_ctrl_set_if(struct ag71xx *ag, unsigned int mii_if)
+{
+ u32 t;
+
+ t = __raw_readl(ag->mii_base);
+ t &= ~(AR71XX_MII_CTRL_IF_MASK);
+ t |= (mii_if & AR71XX_MII_CTRL_IF_MASK);
+ __raw_writel(t, ag->mii_base);
+}
+
+static void ath79_mii0_ctrl_set_if(struct ag71xx *ag)
+{
+ unsigned int mii_if;
+
+ switch (ag->phy_if_mode) {
+ case PHY_INTERFACE_MODE_MII:
+ mii_if = AR71XX_MII0_CTRL_IF_MII;
+ break;
+ case PHY_INTERFACE_MODE_GMII:
+ mii_if = AR71XX_MII0_CTRL_IF_GMII;
+ break;
+ case PHY_INTERFACE_MODE_RGMII:
+ mii_if = AR71XX_MII0_CTRL_IF_RGMII;
+ break;
+ case PHY_INTERFACE_MODE_RMII:
+ mii_if = AR71XX_MII0_CTRL_IF_RMII;
+ break;
+ default:
+ WARN(1, "Impossible PHY mode defined.\n");
+ return;
+ }
+
+ ath79_mii_ctrl_set_if(ag, mii_if);
+}
+
+static void ath79_mii1_ctrl_set_if(struct ag71xx *ag)
+{
+ unsigned int mii_if;
+
+ switch (ag->phy_if_mode) {
+ case PHY_INTERFACE_MODE_RMII:
+ mii_if = AR71XX_MII1_CTRL_IF_RMII;
+ break;
+ case PHY_INTERFACE_MODE_RGMII:
+ mii_if = AR71XX_MII1_CTRL_IF_RGMII;
+ break;
+ default:
+ WARN(1, "Impossible PHY mode defined.\n");
+ return;
+ }
+
+ ath79_mii_ctrl_set_if(ag, mii_if);
+}
+
static void ath79_mii_ctrl_set_speed(struct ag71xx *ag)
{
unsigned int mii_speed;
@@ -573,8 +627,10 @@ __ag71xx_link_adjust(struct ag71xx *ag, bool update)
return;
}
- if (!of_device_is_compatible(np, "qca,ar9130-eth") &&
- !of_device_is_compatible(np, "qca,ar7100-eth"))
+ if (!of_device_is_compatible(np, "qca,ar9130-mii0-eth") &&
+ !of_device_is_compatible(np, "qca,ar9132-mii1-eth") &&
+ !of_device_is_compatible(np, "qca,ar7100-mii0-eth") &&
+ !of_device_is_compatible(np, "qca,ar7100-mii1-eth"))
ag71xx_fast_reset(ag);
cfg2 = ag71xx_rr(ag, AG71XX_REG_MAC_CFG2);
@@ -612,8 +668,10 @@ __ag71xx_link_adjust(struct ag71xx *ag, bool update)
ag71xx_wr(ag, AG71XX_REG_FIFO_CFG3, ag->fifodata[2]);
if (update) {
- if (of_device_is_compatible(np, "qca,ar7100-eth") ||
- of_device_is_compatible(np, "qca,ar9130-eth")) {
+ if (of_device_is_compatible(np, "qca,ar7100-mii0-eth") ||
Re: [OpenWrt-Devel] [PATCH] ath79: fix SUPPORTED_DEVICES for TL-MR3020
I've just noticed that Image metadata isn't required on ar71xx so at least fot TP-LINK devices ar71xx accept factory firmware. Dmitry Tunin 于2018年8月19日周日 下午7:34写道： > > вс, 19 авг. 2018 г. в 14:29, Dmitry Tunin : > > > > вс, 19 авг. 2018 г. в 12:28, Mathias Kresin : > > > > > > 18.08.2018 14:01, David Bauer: > > > > Sysupgrading to ath79 from ar71xx currently fails because of mismatching > > > > supported_devices. ar71xx is expecting "tl-mr3020" which is missing in > > > > the ath79 image. Upgrading from ath79 is unaffected, as the image > > > > contains the old string for ar71xx and the new one coming from the > > > > device-tree. > > > > > > > > Signed-off-by: David Bauer > > > > --- > > > > target/linux/ath79/image/tiny-tp-link.mk | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/target/linux/ath79/image/tiny-tp-link.mk > > > > b/target/linux/ath79/image/tiny-tp-link.mk > > > > index 6ccc9d7dba..dadcd24b42 100644 > > > > --- a/target/linux/ath79/image/tiny-tp-link.mk > > > > +++ b/target/linux/ath79/image/tiny-tp-link.mk > > > > @@ -17,7 +17,7 @@ define Device/tplink_tl-mr3020-v1 > > > > DEVICE_TITLE := TP-LINK TL-MR3020 v1 > > > > DEVICE_PACKAGES := kmod-usb-core kmod-usb-chipidea2 > > > > kmod-usb-ledtrig-usbport > > > > TPLINK_HWID := 0x3021 > > > > - SUPPORTED_DEVICES += tl-mr3020-v1 > > > > + SUPPORTED_DEVICES += tl-mr3020 > > > > endef > > > > TARGET_DEVICES += tplink_tl-mr3020-v1 > > > > > > I was the opinion it's the ar71xx boardname and it's added to allow an > > > update from the ar71xx image. But lets do the obvious and ask the > > > author. > > > > > > Dmitry, was the SUPPORTED_DEVICES added to allow an update from the > > > ar71xx image? > > > > > > Mathias > > > > Exactly. The idea was to allow updates. We are moving to ath79 and I > > don't think that this is nice to create problems in upgrade for users. > > When we are ready to release with ath79 images, we'll need to add the > > supported devices back. > > > > Now only those who can build images themselves are using, si I see no > > reason why don't we leave the easy upgrade path. > > But I was no the author of MR3020, I added MR3040. > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ath79: drop SUPPORTED_DEVICES for all TP-LINK routers
These lines are coming from ar71xx to allow using sysupgrade to switch from ar71xx to ath79. But a sysupgrade with config preserved won't work since some of the config files are incompatible. This commit removed all SUPPORTED_DEVICES for TP-LINK routers. For those who want to use sysupgrade to switch target on TP-LINK router you could use the generated factory firmware instead. This works because: 1. ar71xx doesn't require a image metadata so using a firmware without OpenWrt metadata will skip fwtool checking. 2. The differences between factory and sysupgrade image is the metadata and the tail padding. 3. Using factory firmware for TP-LINK devices here automatically disallows preserving config files because sysupgrade.tar won't be appended after 0xdeadc0de jffs2 mark. 4. ar71xx still check the device model in TP-LINK firmware header so an invalid image won't pass sysupgrade checking. PISEN WMM003N is never supported by ar71xx, this commit also removed SUPPORTED_DEVICES for it because it's completely useless. Signed-off-by: Chuanhong Guo --- I personally don't like these SUPPORTED_DEVICES because it's used to create compatibility with a target that will finally be obsolete. These lines will be useless when ar71xx is replaced by ath79. They are also somehow misleading as we've seen many contributors adding a SUPPORTED_DEVICES line with a string that never exists in ar71xx. (I used "somehow" here because it's not misleading to me but I just saw these mistakes made by others.) Use factory firmware to do the sysupgrade from ar71xx to ath79 for TP-LINK routers will pass firmware checking in ar71xx and automatically gain the ability to prohibit config preserving so I think at least removing them for TP-LINK routers is reasonable. target/linux/ath79/image/generic-tp-link.mk | 7 --- target/linux/ath79/image/generic.mk | 1 - target/linux/ath79/image/tiny-tp-link.mk| 9 - 3 files changed, 17 deletions(-) diff --git a/target/linux/ath79/image/generic-tp-link.mk b/target/linux/ath79/image/generic-tp-link.mk index 4c85099a1a..dceb2130f2 100644 --- a/target/linux/ath79/image/generic-tp-link.mk +++ b/target/linux/ath79/image/generic-tp-link.mk @@ -35,7 +35,6 @@ define Device/tplink_tl-wdr3600 DEVICE_TITLE := TP-LINK TL-WDR3600 DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ledtrig-usbport TPLINK_HWID := 0x3601 - SUPPORTED_DEVICES += tl-wdr3600 endef TARGET_DEVICES += tplink_tl-wdr3600 @@ -45,7 +44,6 @@ define Device/tplink_tl-wdr4300 DEVICE_TITLE := TP-LINK TL-WDR4300 DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ledtrig-usbport TPLINK_HWID := 0x4301 - SUPPORTED_DEVICES += tl-wdr4300 endef TARGET_DEVICES += tplink_tl-wdr4300 @@ -64,7 +62,6 @@ define Device/tplink_tl-wr1043nd-v1 DEVICE_TITLE := TP-LINK TL-WR1043N/ND v1 DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ledtrig-usbport TPLINK_HWID := 0x10430001 - SUPPORTED_DEVICES += tl-wr1043nd endef TARGET_DEVICES += tplink_tl-wr1043nd-v1 @@ -74,7 +71,6 @@ define Device/tplink_tl-wr1043nd-v2 DEVICE_TITLE := TP-LINK TL-WR1043N/ND v2 DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ledtrig-usbport TPLINK_HWID := 0x10430002 - SUPPORTED_DEVICES += tl-wr1043nd-v2 endef TARGET_DEVICES += tplink_tl-wr1043nd-v2 @@ -84,7 +80,6 @@ define Device/tplink_tl-wr1043nd-v3 DEVICE_TITLE := TP-LINK TL-WR1043N/ND v3 DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ledtrig-usbport TPLINK_HWID := 0x10430003 - SUPPORTED_DEVICES += tl-wr1043nd-v3 endef TARGET_DEVICES += tplink_tl-wr1043nd-v3 @@ -100,7 +95,6 @@ define Device/tplink_tl-wr1043nd-v4 IMAGE/sysupgrade.bin := append-rootfs | tplink-safeloader sysupgrade | \ append-metadata | check-size (IMAGE_SIZE) IMAGE/factory.bin := append-rootfs | tplink-safeloader factory - SUPPORTED_DEVICES += tl-wr1043nd-v4 endef TARGET_DEVICES += tplink_tl-wr1043nd-v4 @@ -113,6 +107,5 @@ define Device/tplink_tl-wr2543-v1 IMAGE/sysupgrade.bin := append-rootfs | mktplinkfw sysupgrade -v 3.13.99 | \ append-metadata | check-size (IMAGE_SIZE) IMAGE/factory.bin := append-rootfs | mktplinkfw factory -v 3.13.99 - SUPPORTED_DEVICES += tl-wr2543-v1 endef TARGET_DEVICES += tplink_tl-wr2543-v1 diff --git a/target/linux/ath79/image/generic.mk b/target/linux/ath79/image/generic.mk index b3eaee48b7..f211db981a 100644 --- a/target/linux/ath79/image/generic.mk +++ b/target/linux/ath79/image/generic.mk @@ -185,7 +185,6 @@ define Device/pisen_wmm003n DEVICE_TITLE := Pisen WMM003N (Cloud Easy Power) DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-chipidea2 TPLINK_HWID := 0x07030101 - SUPPORTED_DEVICES += wmm003n IMAGES := sysupgrade.bin endef TARGET_DEVICES += pisen_wmm003n diff --git a/target/linux/ath79/image/tiny-tp-link.mk b/target/linux/ath79/image/tiny-tp-link.mk index 6ccc9d7dba..baa0005f9c 100644 --- a/target/lin
Re: [OpenWrt-Devel] [PATCH] ath79: drop SUPPORTED_DEVICES for all TP-LINK routers
Another difference there is that eth0 and eth1 are swapped for chips with builtin switch (except ar7240). And I think this one makes it really annoying to write a config migration script. We now have some boards got SUPPORTED_DEVICES from ar71xx and some boards not. I'm confused about whether we should add such a SUPPORTED_DEVICES string when we port a board from ar71xx to ath79. (And I agree that my patch here didn't improve this situation.) I hope we could either add all the missing ones or remove all the existing ones. I wanted to make this RFC on mailing list but then I think this discussion will end up nowhere :( So...This patch can be dropped as it improved nothing... Dmitry Tunin 于2018年8月19日周日 下午11:40写道： > > вс, 19 авг. 2018 г. в 17:46, Mathias Kresin : > > > > 2018-08-19 15:47 GMT+02:00 Chuanhong Guo : > > > These lines are coming from ar71xx to allow using sysupgrade to > > > switch from ar71xx to ath79. But a sysupgrade with config preserved > > > won't work since some of the config files are incompatible. > > > > To be honest, I don't see that your patch really fixes the issue. Even > > if you drop the ar71xx compatible string, it's possible that people > > are using a forced sysupgade and therefore have the same problem > > again. Means, it's rather a "might work" workaround. Furthermore, > > there aren't only tp-link boards affected by this issues. I would > > really like to see a treewide handling of the issue. > > > > It isn't that uncommon that something changes and an upgrade of > > existing user configs is required. We're usually add uci-defaults > > scripts to do so. One example of doing so can be found in the lantiq > > target[0]. > > > > I'm not yet in a position to say what the correct approach would be > > here. I'm only aware that the "option path" in /e/c/wireless has > > changed for some(?) boards. No idea what else has changed between > > ar71xx and ath79. > > > Frankly speaking even this path change doesn't hurt. If you upgrade > from ar71xx to ath79 with a wrong (for ath79) path, > new entries for wireless devices are added to /etc/config/wireless > with correct path. > > I upgraded a lot these days on different devices from ar71xx to ath79 > and back with keeping configs. > Nothing really wrong happens except a few useless lines in > /etc/config/wireless. > > Even if this happens the correct wifi device will be disabled because > of the default config. > In this case user will open the file and see what happened. > > So I don't see any sufficient reason to prevent upgrading with the old > configs. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] GPL Violation to chase + Engenius/Senao firmware non-update
GPL doesn't prevent the manufacturer from blocking third-party firmware being installed on their router. They just need to provide GPL code for their firmware (and they don't need to explicitly submit their device support to OpenWrt project.) BTW: It seemed that the bootrom of Qualcomm IPQ40xx comes from other Qualcomm Android chips and contains some security features that preventing unauthorized firmware to be installed on their router. An RSA pubkey can be burnt in to SoC and SoC bootrom will verify contents on flash before booting it. If this feature is used by the manufacturer you'll be impossible to flash any third-party firmware on this router. Michael Holstein 于2018年8月20日周一 下午9:41写道： > > I was finally frustrated at these Engenus/Saneo units and found the > serial port and got into uBoot and looked at the image .. it's yours > .. but oddly, you don't support it all. > > Well gee, that's curious, it seems somebody's breaking the rules, and > it isn't you. > > I'd nastygram Engenius and make them post the GPL contrib so you have > the BLOB for the Broacdom IPQ4019 that's in there. This is the > EAP1250/1300 (identical except for where RJ45 port is) .. there are > 100 others that use this board (I ran the board ID through the FCC API > if you want all the makes/models). > > Here's your goods let me know if you want anything else .. I'm going > to build the image for it and flash but since they broke the rules to > begin with I'm dumping the flash and using the FDT to help modernize. > > These are cool because they are dual radio soft APs that are PoE and > AC wave 2. A 3 pack is $160 on Amazon. With OpenWISP you can do most > anything shy of a college campus > > ahywho ..here's all the proof you need. They didn't even bother to > change the name. > > I'm not a contributor I just do lots of embedded work and this made me > mad. Note that the you've already noticed this on the Engenius 300 > (the wiki poings out the factory firmware is openwrt) > > Company contact/owner is easiest found via their FCC filings : most > recent one from > company president > > https://fccid.io/A8J-EAP1300/Letter/Confidentiality-Request-3409208 > > Cheers, > > -Michael. > > PS: It looks like they locked the UART from which I obtained this in > u-boot from allowing interrupt so I'm going to poke about and find out > how to get in there. I know this can be done but it's first I've seen > it done .. The uBoot is reworked from Saneo, per the version string. > > Anyone have a clever tip on that work-around? .. If I can get console > at u-Boot I can skip a couple steps. > > ---snip---. > > bootm 0x8400#configÉ4 > > ## Booting kernel from FIT Image at 8400 ... >Using 'configÉ4' configuration >Trying 'kernelÉ1' kernel subimage > Description: ARM OpenWrt Linux-3.14.43 LOL OKAY COUGH IT UP > Type: Kernel Image > Compression: gzip compressed > Data Start: 0x84e4 > Data Size:3180186 Bytes = 3 MiB > Architecture: ARM > OS: tLinux > Load Address: 0x80208000 > Entry Point: 0x80208000 > Hash algo:crc32 > Hash value: 34c16a99 > Hash algo:sha1 > Hash value: 620a666c88729f60ee5b3f90fa261ed2bb3de6cb >Verifying Hash Integrity ... crc32+ sha1+ OK > > ## Flattened Device Tree from FIT Image at 8400 >Using 'configÉ4' configuration >Trying 'fdtÉ4' FDT blob subimage > Description: ARM OpenWrt qcom-ipq40xx-ap.dkxx device tree blob > Type: Flat Device Tree > Compression: uncompressed > Data Start: 0x84325520 > Data Size:33495 Bytes = 32.7 KiB > Architecture: ARM > Hash algo:crc32 > Hash value: 19be728a > Hash algo:sha1 > Hash value: 633f6dbf948179ecf1f72f737981d2b38fabe6ee >Verifying Hash Integrity ... crc32+ sha1+ OK >Booting using the fdt blob at 0x84325520 >Uncompressing Kernel Image ... OK > >Loading Device Tree to 86ff4000, end 86fff2d6 ... > > And guilty party : > > Linux version 3.14.43 (root@liwei) (gcc version 4.8.3 20140106 > (prerelease) (Linaro GCC 4.8-2014.01) ) #1 SMP PREEMPT Tue Jan 30 > 18:20:10 CST 2018 > > [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d > > [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing > instruction cache > > [0.00] Machine model: Qualcomm Technologies, Inc. IPQ40xx/EAP1250 > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] GPL Violation to chase + Engenius/Senao firmware non-update
A small correction: IPQ40xx is made by Qualcomm not Broadcom and that feature is called QSEE instead. :) If my memory is right, Qualcomm verify SBL (SBL is a binary provided by Qualcomm to bootstrap some basic modules like RAM controller and load U-boot) in their bootrom before bootrom starts SBL, SBL will then verify U-boot and refuse to boot if U-boot doesn't pass the signature checking. As for how U-boot verify firmware this depends on implementation of the manufacturer. Since the RSA pubkey is burnt into SoC instead of an external flash, this guaranteed that anyone can't replace the U-boot with an unsigned one. (I agree that this is an unrelated topic here and I'll just stop further discussion about this. Michael Holstein 于2018年8月20日周一 下午11:08写道： > > that feature is called TXE (it's also in the Pi's Broadcom SoC) and it > doesn't "prevent" it "complicates", particularly in this > implementation. > You're correct on your GPL comment. But they did it before and didn't > release source either, so whoever has ownership should at least ask > them pretty-please. > > There's a workaround to this little problem (wearing the work hat, I'd > call that a decent security problem in how TXE and uBoot interact in > Broadcom's implementation), this being another discussion, and > unrelated. > > -Michael. > > On Mon, Aug 20, 2018 at 10:26 AM, Chuanhong Guo wrote: > > GPL doesn't prevent the manufacturer from blocking third-party > > firmware being installed on their router. > > They just need to provide GPL code for their firmware (and they don't > > need to explicitly submit their device support to OpenWrt project.) > > BTW: It seemed that the bootrom of Qualcomm IPQ40xx comes from other > > Qualcomm Android chips and contains some security features that > > preventing unauthorized firmware to be installed on their router. An > > RSA pubkey can be burnt in to SoC and SoC bootrom will verify contents > > on flash before booting it. If this feature is used by the > > manufacturer you'll be impossible to flash any third-party firmware on > > this router. > > Michael Holstein 于2018年8月20日周一 下午9:41写道： > >> > >> I was finally frustrated at these Engenus/Saneo units and found the > >> serial port and got into uBoot and looked at the image .. it's yours > >> .. but oddly, you don't support it all. > >> > >> Well gee, that's curious, it seems somebody's breaking the rules, and > >> it isn't you. > >> > >> I'd nastygram Engenius and make them post the GPL contrib so you have > >> the BLOB for the Broacdom IPQ4019 that's in there. This is the > >> EAP1250/1300 (identical except for where RJ45 port is) .. there are > >> 100 others that use this board (I ran the board ID through the FCC API > >> if you want all the makes/models). > >> > >> Here's your goods let me know if you want anything else .. I'm going > >> to build the image for it and flash but since they broke the rules to > >> begin with I'm dumping the flash and using the FDT to help modernize. > >> > >> These are cool because they are dual radio soft APs that are PoE and > >> AC wave 2. A 3 pack is $160 on Amazon. With OpenWISP you can do most > >> anything shy of a college campus > >> > >> ahywho ..here's all the proof you need. They didn't even bother to > >> change the name. > >> > >> I'm not a contributor I just do lots of embedded work and this made me > >> mad. Note that the you've already noticed this on the Engenius 300 > >> (the wiki poings out the factory firmware is openwrt) > >> > >> Company contact/owner is easiest found via their FCC filings : most > >> recent one from > >> company president > >> > >> https://fccid.io/A8J-EAP1300/Letter/Confidentiality-Request-3409208 > >> > >> Cheers, > >> > >> -Michael. > >> > >> PS: It looks like they locked the UART from which I obtained this in > >> u-boot from allowing interrupt so I'm going to poke about and find out > >> how to get in there. I know this can be done but it's first I've seen > >> it done .. The uBoot is reworked from Saneo, per the version string. > >> > >> Anyone have a clever tip on that work-around? .. If I can get console > >> at u-Boot I can skip a couple steps. > >> > >> ---snip---. > >> > >> bootm 0x8400#configÉ4 > >> > >> ## B
[OpenWrt-Devel] [PATCH v3] ath79: ag71xx: apply interface mode to MII0/1_CTRL on ar71xx/ar913x
We currently don't have any code configuring interface mode in ath79,
meaning that we relies on bootloader to set the correct interface mode.
This patch added code to set interface correctly so that everything works
even if bootloader configures it wrong.(e.g. on WNDR3800 u-boot set
the second GMAC mode to RMII but it should be RGMII.)
Introduced "qca,mac-idx" for the difference in MII_CTRL register value.
Signed-off-by: Chuanhong Guo
---
v2-v3: Changed dt binding
target/linux/ath79/dts/ar7100.dtsi| 2 +
target/linux/ath79/dts/ar9132.dtsi| 1 +
.../net/ethernet/atheros/ag71xx/ag71xx_main.c | 64 ++-
3 files changed, 66 insertions(+), 1 deletion(-)
diff --git a/target/linux/ath79/dts/ar7100.dtsi
b/target/linux/ath79/dts/ar7100.dtsi
index 8994a7d688..6402657841 100644
--- a/target/linux/ath79/dts/ar7100.dtsi
+++ b/target/linux/ath79/dts/ar7100.dtsi
@@ -182,6 +182,7 @@
resets = <&rst 9>;
reset-names = "mac";
+ qca,mac-idx = <0>;
};
&mdio1 {
@@ -201,4 +202,5 @@
resets = <&rst 13>;
reset-names = "mac";
+ qca,mac-idx = <1>;
};
diff --git a/target/linux/ath79/dts/ar9132.dtsi
b/target/linux/ath79/dts/ar9132.dtsi
index 9d8ddcf9ba..2264994279 100644
--- a/target/linux/ath79/dts/ar9132.dtsi
+++ b/target/linux/ath79/dts/ar9132.dtsi
@@ -193,4 +193,5 @@
pll-handle = <&pll>;
resets = <&rst 9>;
reset-names = "mac";
+ qca,mac-idx = <0>;
};
diff --git
a/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
b/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
index 1e0bb6937f..7f64a65817 100644
--- a/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
+++ b/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
@@ -529,6 +529,60 @@ static void ath79_set_pll(struct ag71xx *ag)
udelay(100);
}
+static void ath79_mii_ctrl_set_if(struct ag71xx *ag, unsigned int mii_if)
+{
+ u32 t;
+
+ t = __raw_readl(ag->mii_base);
+ t &= ~(AR71XX_MII_CTRL_IF_MASK);
+ t |= (mii_if & AR71XX_MII_CTRL_IF_MASK);
+ __raw_writel(t, ag->mii_base);
+}
+
+static void ath79_mii0_ctrl_set_if(struct ag71xx *ag)
+{
+ unsigned int mii_if;
+
+ switch (ag->phy_if_mode) {
+ case PHY_INTERFACE_MODE_MII:
+ mii_if = AR71XX_MII0_CTRL_IF_MII;
+ break;
+ case PHY_INTERFACE_MODE_GMII:
+ mii_if = AR71XX_MII0_CTRL_IF_GMII;
+ break;
+ case PHY_INTERFACE_MODE_RGMII:
+ mii_if = AR71XX_MII0_CTRL_IF_RGMII;
+ break;
+ case PHY_INTERFACE_MODE_RMII:
+ mii_if = AR71XX_MII0_CTRL_IF_RMII;
+ break;
+ default:
+ WARN(1, "Impossible PHY mode defined.\n");
+ return;
+ }
+
+ ath79_mii_ctrl_set_if(ag, mii_if);
+}
+
+static void ath79_mii1_ctrl_set_if(struct ag71xx *ag)
+{
+ unsigned int mii_if;
+
+ switch (ag->phy_if_mode) {
+ case PHY_INTERFACE_MODE_RMII:
+ mii_if = AR71XX_MII1_CTRL_IF_RMII;
+ break;
+ case PHY_INTERFACE_MODE_RGMII:
+ mii_if = AR71XX_MII1_CTRL_IF_RGMII;
+ break;
+ default:
+ WARN(1, "Impossible PHY mode defined.\n");
+ return;
+ }
+
+ ath79_mii_ctrl_set_if(ag, mii_if);
+}
+
static void ath79_mii_ctrl_set_speed(struct ag71xx *ag)
{
unsigned int mii_speed;
@@ -1272,7 +1326,7 @@ static int ag71xx_probe(struct platform_device *pdev)
struct resource *res;
struct ag71xx *ag;
const void *mac_addr;
- u32 max_frame_len;
+ u32 max_frame_len, mac_idx;
int tx_size, err;
if (!np)
@@ -1427,6 +1481,14 @@ static int ag71xx_probe(struct platform_device *pdev)
goto err_free;
}
+ if ((ag->mii_base) &&
+ (!of_property_read_u32(np, "qca,mac-idx", &mac_idx))) {
+ if (mac_idx == 0)
+ ath79_mii0_ctrl_set_if(ag);
+ else if (mac_idx == 1)
+ ath79_mii1_ctrl_set_if(ag);
+ }
+
netif_napi_add(dev, &ag->napi, ag71xx_poll, AG71XX_NAPI_WEIGHT);
ag71xx_wr(ag, AG71XX_REG_MAC_CFG1, 0);
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: ar71xx create a separate driver for ar71xx pci interrupt controller.
Hi!
Comments inline:
Dmitry Tunin 于2018年8月21日周二 下午10:59写道：
>
> It is based on Chuanhong Guo work.
>
> PCI interrupt controller is not part of PCI. It is a part of reset controller
> with 0x18060018, 0x1806001c control registers.
>
> This should fix a bug with one IRQ for all PCI devices and also handle the
> PCI_CORE interrupt.
No it doesn't. Assigning it in dts doesn't mean that we "handled" it.
But I still like this patch because it's doing a cleanup of the messy code.
>
> I am not sure that this kind of cascading is good for performance, but this
> way we are more flexible when cofiguring IRQs.
It shouldn't affect performance because doing this separation doesn't
change the way it dispatches PCI IRQ.
>
> Run tested on DIR-825 B1.
> ---
> target/linux/ath79/dts/ar7100.dtsi | 22 ++-
> ...turn-pci-ar71xx-driver-into-a-pure-OF-dri.patch | 168 -
> .../0036-MIPS-ath79-add-pci-intc.patch | 205
> +
> 3 files changed, 306 insertions(+), 89 deletions(-)
> create mode 100644
> target/linux/ath79/patches-4.14/0036-MIPS-ath79-add-pci-intc.patch
>
> diff --git a/target/linux/ath79/dts/ar7100.dtsi
> b/target/linux/ath79/dts/ar7100.dtsi
> index 8994a7d..6dc1751 100644
> --- a/target/linux/ath79/dts/ar7100.dtsi
> +++ b/target/linux/ath79/dts/ar7100.dtsi
> @@ -96,6 +96,16 @@
> #reset-cells = <1>;
> };
>
> + pci_intc: interrupt-controller@18060018 {
> + compatible = "qca,ar7100-pci-intc";
> + reg = <0x18060018 0x4>;
> + interrupt-parent = <&cpuintc>;
> + interrupts = <2>;
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + };
> +
For other chips this node is a subnode of reset-controller. But in
this case here we can just put this above reset-controller@18060024.
Nodes in dts are supposed to be ordered by register address.
> +
> pcie0: pcie-controller@180c {
> compatible = "qca,ar7100-pci";
> #address-cells = <3>;
> @@ -105,14 +115,16 @@
> reg-names = "cfg_base";
> ranges = <0x200 0 0x1000 0x1000 0
> 0x0700/* pci memory */
> 0x100 0 0x 0x000 0
> 0x01>; /* io space */
> - interrupt-parent = <&cpuintc>;
> - interrupts = <2>;
> + interrupt-parent = <&pci_intc>;
> + interrupts = <4>;
Do we really need this? We don't even have a handler that actually do
anything for it. I think the above two lines can simply be dropped.
>
> - interrupt-controller;
> #interrupt-cells = <1>;
>
> - interrupt-map-mask = <0 0 0 1>;
> - interrupt-map = <0 0 0 0 &pcie0 0>;
> + interrupt-map-mask = <0xf800 0 0 0>;
> + interrupt-map = <0x8800 0 0 0 &pci_intc 1
> +0x9000 0 0 0 &pci_intc 2
> +0x9800 0 0 0 &pci_intc 3>;
> +
> status = "disabled";
> };
> };
> diff --git
> a/target/linux/ath79/patches-4.14/0020-MIPS-ath79-turn-pci-ar71xx-driver-into-a-pure-OF-dri.patch
>
> b/target/linux/ath79/patches-4.14/0020-MIPS-ath79-turn-pci-ar71xx-driver-into-a-pure-OF-dri.patch
> index ea3514a..95ca6d1 100644
> ---
> a/target/linux/ath79/patches-4.14/0020-MIPS-ath79-turn-pci-ar71xx-driver-into-a-pure-OF-dri.patch
> +++
> b/target/linux/ath79/patches-4.14/0020-MIPS-ath79-turn-pci-ar71xx-driver-into-a-pure-OF-dri.patch
It's not a good idea to mix the removal of IRQ part into this patch. I
suggest using a separated patch to do the removing.
> @@ -9,8 +9,10 @@ Signed-off-by: John Crispin
> arch/mips/pci/pci-ar71xx.c | 81
> +++---
> 1 file changed, 40 insertions(+), 41 deletions(-)
>
> a/arch/mips/pci/pci-ar71xx.c
> -+++ b/arch/mips/pci/pci-ar71xx.c
> +Index: linux-4.14.65/arch/mips/pci/pci-ar71xx
Re: [OpenWrt-Devel] [PATCH] ath79: ar71xx create a separate driver for ar71xx pci interrupt controller.
Dmitry Tunin 于2018年8月22日周三 上午12:26写道：
> I am still not very competent in the IRQ handling. I thought that if we set
> interrupts = <4>; and the new partent, your "case 4:" may work.
We have it there because it appears in datasheet. But we don't need it
to work unless we know what it's used for.
>
> > >
> > > + pci_intc: interrupt-controller@18060018 {
> > > + compatible = "qca,ar7100-pci-intc";
> > > + reg = <0x18060018 0x4>;
> > > + interrupt-parent = <&cpuintc>;
> > > + interrupts = <2>;
> > > + interrupt-controller;
> > > + #interrupt-cells = <1>;
> > > + };
> > > +
> > For other chips this node is a subnode of reset-controller. But in
> > this case here we can just put this above reset-controller@18060024.
> > Nodes in dts are supposed to be ordered by register address.
>
> No problem with that, I thought about a child node. But it doesn't
> make any difference IMHO.
> > > +
> > > pcie0: pcie-controller@180c {
> > > compatible = "qca,ar7100-pci";
> > > #address-cells = <3>;
> > > @@ -105,14 +115,16 @@
> > > reg-names = "cfg_base";
> > > ranges = <0x200 0 0x1000
> > > 0x1000 0 0x0700/* pci memory */
> > > 0x100 0 0x
> > > 0x000 0 0x01>; /* io space */
> > > - interrupt-parent = <&cpuintc>;
> > > - interrupts = <2>;
> > > + interrupt-parent = <&pci_intc>;
> > > + interrupts = <4>;
> > Do we really need this? We don't even have a handler that actually do
> > anything for it. I think the above two lines can simply be dropped.
>
> See above. I thought the existing handler could work. I must be wrong.
All the job of the existing handler is now done by the added cascade
driver. And you have removed the existing handler in driver :)
>
> > > diff --git
> > > a/target/linux/ath79/patches-4.14/0020-MIPS-ath79-turn-pci-ar71xx-driver-into-a-pure-OF-dri.patch
> > >
> > > b/target/linux/ath79/patches-4.14/0020-MIPS-ath79-turn-pci-ar71xx-driver-into-a-pure-OF-dri.patch
> > > index ea3514a..95ca6d1 100644
> > > ---
> > > a/target/linux/ath79/patches-4.14/0020-MIPS-ath79-turn-pci-ar71xx-driver-into-a-pure-OF-dri.patch
> > > +++
> > > b/target/linux/ath79/patches-4.14/0020-MIPS-ath79-turn-pci-ar71xx-driver-into-a-pure-OF-dri.patch
> > It's not a good idea to mix the removal of IRQ part into this patch. I
> > suggest using a separated patch to do the removing.
>
> It is a minor issue if everything else looks good. The idea was to
> keep number of patches smaller.
Keeping patches inside that directory less isn't useful at all.(If
it's useful why not squash all of them into one?)
Instead we need each patch did one job and that job is described in
file name/title in mbox header.
As @blogic put in the mbox header, this patch "turns the existing PCI
driver into a pure OF driver" but what you did is "Removing IRQ
dispatcher from PCI driver". Squashing them together only makes the
patch more confusing.
>
>
> > I haven't read the code thoroghly but it seemed that irq-ath79-misc
> > works in a similar way. Is it possible to use the misc intc driver for
> > PCI?
>
> They are similar. I used that code as an example, but the
> irq-ath79-pci has your mask/unmask for pci with reading the registers.
> It is possible to make one driver for both, but is it really needed?
It helps reducing code duplication.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: ar71xx create a separate driver for ar71xx pci interrupt controller.
Dmitry Tunin 于2018年8月22日周三 下午1:08写道： > > > > They are similar. I used that code as an example, but the > > > irq-ath79-pci has your mask/unmask for pci with reading the registers. > > > It is possible to make one driver for both, but is it really needed? > > It helps reducing code duplication. > > If we completely drop that PCI_CORE IRQ that we are not using anyway, > I see no reason why we can't > define 2 subnodes or the reset controller with the same irq-ath79-misc driver. I'm actually saying about directly using irq-ath79-misc for PCI interrupt, and this means define two nodes using different reg but make the compatible string the same(qca,ar7100-misc) :) And this doesn't mean that we can't use PCI_CORE IRQ if we need it. Simply use hwirq 0-2 for devices and hwirq 4 for PCI_CORE. > We'll need only to set PCI IRQs to 0-2 instead of 1-3. That's all. > > After some other feedback is received, I can do the change. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: ar7100: remove IRQ code from PCI driver
Dmitry Tunin 于2018年8月22日周三 下午5:07写道：
>
> Currently all PCI devices get the same IRQ that affects performance badly.
>
> This commit adresses this problem and cleans the code.
>
> ar7100 has a special PCI interrupt controller@18060018 that works exactly
> the same way as misc interrupt controller.
>
> This patch does the following:
>
> 1. Removes all IRQ handling code from the PCI driver.
> 2. Defines pci-intc interrupt controller@18060018 in dtsi.
> 3. Removes interrupt-controller property from PCI node.
> 4. Sets a correct interrupt mask for PCI devices.
>
> Run tested on DIR-825 B1.
>
> Signed-off-by: Dmitry Tunin
> ---
> target/linux/ath79/dts/ar7100.dtsi | 21 +++-
> .../0036-MIPS-ath79-remove-irq-code-from-pci.patch | 117
> +
> 2 files changed, 133 insertions(+), 5 deletions(-)
> create mode 100644
> target/linux/ath79/patches-4.14/0036-MIPS-ath79-remove-irq-code-from-pci.patch
>
> diff --git a/target/linux/ath79/dts/ar7100.dtsi
> b/target/linux/ath79/dts/ar7100.dtsi
> index 8994a7d..0632050 100644
> --- a/target/linux/ath79/dts/ar7100.dtsi
> +++ b/target/linux/ath79/dts/ar7100.dtsi
> @@ -88,6 +88,14 @@
> clock-names = "wdt";
> };
>
> + pci_intc: interrupt-controller@18060018 {
> + compatible = "qca,ar7240-misc-intc";
> + reg = <0x18060018 0x4>;
I guess this should be <0x18060018 0x8>?
Interrupt status is at 0x18060018-0x1806001c and interrupt mask is at
0x1806001c-0x18060020. The length of used memory space is 8 bytes.
BTW I noticed that reg of miscintc is <0x18060010 0x4> but the
register of interrupt status and mask is 0x18060010-0x18060018, also 8
bytes.
Are these two mistakes or my misunderstanding of the size in reg property?
> + interrupt-parent = <&cpuintc>;
> + interrupts = <2>;
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + };
>
> rst: reset-controller@18060024 {
> compatible = "qca,ar7100-reset";
> @@ -105,14 +113,17 @@
> reg-names = "cfg_base";
> ranges = <0x200 0 0x1000 0x1000 0
> 0x0700/* pci memory */
> 0x100 0 0x 0x000 0
> 0x01>; /* io space */
> - interrupt-parent = <&cpuintc>;
> - interrupts = <2>;
>
> - interrupt-controller;
> + interrupt-parent = <&pci_intc>;
> + interrupts = <4>;
> +
> #interrupt-cells = <1>;
>
> - interrupt-map-mask = <0 0 0 1>;
> - interrupt-map = <0 0 0 0 &pcie0 0>;
> + interrupt-map-mask = <0xf800 0 0 0>;
> + interrupt-map = <0x8800 0 0 0 &pci_intc 0
> +0x9000 0 0 0 &pci_intc 1
> +0x9800 0 0 0 &pci_intc 2>;
> +
> status = "disabled";
> };
> };
> diff --git
> a/target/linux/ath79/patches-4.14/0036-MIPS-ath79-remove-irq-code-from-pci.patch
>
> b/target/linux/ath79/patches-4.14/0036-MIPS-ath79-remove-irq-code-from-pci.patch
> new file mode 100644
> index 000..b3fc19a
> --- /dev/null
> +++
> b/target/linux/ath79/patches-4.14/0036-MIPS-ath79-remove-irq-code-from-pci.patch
> @@ -0,0 +1,117 @@
> +Index: linux-4.14.65/arch/mips/pci/pci-ar71xx.c
> +===
> +--- linux-4.14.65.orig/arch/mips/pci/pci-ar71xx.c
> linux-4.14.65/arch/mips/pci/pci-ar71xx.c
> +@@ -269,103 +269,6 @@ static struct pci_ops ar71xx_pci_ops = {
> + .write = ar71xx_pci_write_config,
> + };
> +
> +-static void ar71xx_pci_irq_handler(struct irq_desc *desc)
> +-{
> +- void __iomem *base = ath79_reset_base;
> +- struct irq_chip *chip = irq_desc_get_chip(desc);
> +- struct ar71xx_pci_controller *apc = irq_desc_get_handler_data(desc);
> +- u32 pending;
> +-
> +- chained_irq_enter(chip, desc);
> +- pending = __raw_readl(base + AR71XX_RESET_REG_PCI_INT_STATUS) &
> +-__raw_readl(base + AR71XX_RESET_REG_PCI_INT_ENABLE);
> +-
> +- if (pending & AR71XX_PCI_INT_DEV0)
> +- generic_handle_irq(irq_linear_revmap(apc->domain, 1));
> +-
> +- else if (pending & AR71XX_PCI_INT_DEV1)
> +- generic_handle_irq(irq_linear_revmap(apc->domain, 2));
> +-
> +- else if (pending & AR71XX_PCI_INT_DEV2)
> +- generic_handle_irq(irq_linear_revmap(apc->doma
Re: [OpenWrt-Devel] [PATCH v3] ath79: ag71xx: apply interface mode to MII0/1_CTRL on ar71xx/ar913x
Hi!
John Crispin 于2018年8月22日周三 下午5:05写道：
>
>
>
> On 21/08/18 13:39, Chuanhong Guo wrote:
> > We currently don't have any code configuring interface mode in ath79,
> > meaning that we relies on bootloader to set the correct interface mode.
> >
> > This patch added code to set interface correctly so that everything works
> > even if bootloader configures it wrong.(e.g. on WNDR3800 u-boot set
> > the second GMAC mode to RMII but it should be RGMII.)
> >
> > Introduced "qca,mac-idx" for the difference in MII_CTRL register value.
> >
> > Signed-off-by: Chuanhong Guo
>
> Hi,
> I have applied a slightly modified version of the patch to my staging
> tree, could you kindly verify that it still fixes the issue please
> before i push it to master
I could only test on AR9132 and I've tested that your staging tree
works well on my TL-WR941N v2 (AR9132+MV88E6060, it uses gmac0 only).
> -->
> https://git.openwrt.org/?p=openwrt/staging/blogic.git;a=shortlog;h=refs/heads/staging
> John
>
> > ---
> >
> > v2-v3: Changed dt binding
> >
> > target/linux/ath79/dts/ar7100.dtsi| 2 +
> > target/linux/ath79/dts/ar9132.dtsi| 1 +
> > .../net/ethernet/atheros/ag71xx/ag71xx_main.c | 64 ++-
> > 3 files changed, 66 insertions(+), 1 deletion(-)
> >
> > diff --git a/target/linux/ath79/dts/ar7100.dtsi
> > b/target/linux/ath79/dts/ar7100.dtsi
> > index 8994a7d688..6402657841 100644
> > --- a/target/linux/ath79/dts/ar7100.dtsi
> > +++ b/target/linux/ath79/dts/ar7100.dtsi
> > @@ -182,6 +182,7 @@
> >
> > resets = <&rst 9>;
> > reset-names = "mac";
> > + qca,mac-idx = <0>;
> > };
> >
> > &mdio1 {
> > @@ -201,4 +202,5 @@
> >
> > resets = <&rst 13>;
> > reset-names = "mac";
> > + qca,mac-idx = <1>;
> > };
> > diff --git a/target/linux/ath79/dts/ar9132.dtsi
> > b/target/linux/ath79/dts/ar9132.dtsi
> > index 9d8ddcf9ba..2264994279 100644
> > --- a/target/linux/ath79/dts/ar9132.dtsi
> > +++ b/target/linux/ath79/dts/ar9132.dtsi
> > @@ -193,4 +193,5 @@
> > pll-handle = <&pll>;
> > resets = <&rst 9>;
> > reset-names = "mac";
> > + qca,mac-idx = <0>;
> > };
> > diff --git
> > a/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
> >
> > b/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
> > index 1e0bb6937f..7f64a65817 100644
> > ---
> > a/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
> > +++
> > b/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
> > @@ -529,6 +529,60 @@ static void ath79_set_pll(struct ag71xx *ag)
> > udelay(100);
> > }
> >
> > +static void ath79_mii_ctrl_set_if(struct ag71xx *ag, unsigned int mii_if)
> > +{
> > + u32 t;
> > +
> > + t = __raw_readl(ag->mii_base);
> > + t &= ~(AR71XX_MII_CTRL_IF_MASK);
> > + t |= (mii_if & AR71XX_MII_CTRL_IF_MASK);
> > + __raw_writel(t, ag->mii_base);
> > +}
> > +
> > +static void ath79_mii0_ctrl_set_if(struct ag71xx *ag)
> > +{
> > + unsigned int mii_if;
> > +
> > + switch (ag->phy_if_mode) {
> > + case PHY_INTERFACE_MODE_MII:
> > + mii_if = AR71XX_MII0_CTRL_IF_MII;
> > + break;
> > + case PHY_INTERFACE_MODE_GMII:
> > + mii_if = AR71XX_MII0_CTRL_IF_GMII;
> > + break;
> > + case PHY_INTERFACE_MODE_RGMII:
> > + mii_if = AR71XX_MII0_CTRL_IF_RGMII;
> > + break;
> > + case PHY_INTERFACE_MODE_RMII:
> > + mii_if = AR71XX_MII0_CTRL_IF_RMII;
> > + break;
> > + default:
> > + WARN(1, "Impossible PHY mode defined.\n");
> > + return;
> > + }
> > +
> > + ath79_mii_ctrl_set_if(ag, mii_if);
> > +}
> > +
> > +static void ath79_mii1_ctrl_set_if(struct ag71xx *ag)
> > +{
> > + unsigned int mii_if;
> > +
> > + switch (ag->phy_if_mode) {
> > + case PHY_INTERFACE_MODE_RMII:
> > + mii_if = AR71XX_MII1_CTRL_IF_RMII;
> > + break;
> > + case PHY_INTERFACE_MODE_RGMII:
> > + mii_if = AR71XX_MII1_CTRL_IF_RGMII;
> > + break;
> > +
Re: [OpenWrt-Devel] [PATCH] ath79: reduce irq count in irq-ath79-misc.c
Hi!
Dmitry Tunin 于2018年8月22日周三 下午8:31写道：
>
> We probably need to add a SoC check there. Otherwise we'll have two 32
> IRQ domains when using it with PCI.
But this doesn't matter at all :)
> I guess older ones have 8 IRQs and newer ones - 16. We cal leave
> default of 32 for unknown SoCs if there are any.
> ср, 22 авг. 2018 г. в 13:59, Dmitry Tunin :
> >
> > Oops. I looked into newer specs. Some chips now have 16.
> > ср, 22 авг. 2018 г. в 13:50, Dmitry Tunin :
> > >
> > > According to specs this interrupt controller has 8 IRQs (0-7).
> > > If we reuse it for PCI, we need even less (0-4).
> > > We don't need that hude domain there.
> > >
> > > Signed-off-by: Dmitry Tunin
> > > ---
> > > .../0037-MIPS-ath79-irq-misc-reduce-irq-count.patch | 13
> > > +
> > > 1 file changed, 13 insertions(+)
> > > create mode 100644
> > > target/linux/ath79/patches-4.14/0037-MIPS-ath79-irq-misc-reduce-irq-count.patch
> > >
> > > diff --git
> > > a/target/linux/ath79/patches-4.14/0037-MIPS-ath79-irq-misc-reduce-irq-count.patch
> > >
> > > b/target/linux/ath79/patches-4.14/0037-MIPS-ath79-irq-misc-reduce-irq-count.patch
> > > new file mode 100644
> > > index 000..b9ab092
> > > --- /dev/null
> > > +++
> > > b/target/linux/ath79/patches-4.14/0037-MIPS-ath79-irq-misc-reduce-irq-count.patch
> > > @@ -0,0 +1,13 @@
> > > +Index: linux-4.14.65/drivers/irqchip/irq-ath79-misc.c
> > > +===
> > > +--- linux-4.14.65.orig/drivers/irqchip/irq-ath79-misc.c
> > > linux-4.14.65/drivers/irqchip/irq-ath79-misc.c
> > > +@@ -21,7 +21,7 @@
> > > + #define AR71XX_RESET_REG_MISC_INT_STATUS 0
> > > + #define AR71XX_RESET_REG_MISC_INT_ENABLE 4
> > > +
> > > +-#define ATH79_MISC_IRQ_COUNT 32
> > > ++#define AR71XX_MISC_IRQ_COUNT 8
> > > +
> > > + static void ath79_misc_irq_handler(struct irq_desc *desc)
> > > + {
> > > --
> > > 2.7.4
> > >
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: ar7100: remove IRQ code from PCI driver
Dmitry Tunin 于2018年8月23日周四 上午1:24写道：
>
> I looked into the specs and now I see that the
> AR71XX_RESET_REG_MISC_INT_STATUS is read-only on ar7100, so we need to
> change the compatible
> to "qca,ar7100-misc-intc" and also change it for the "real" misc
> controller. Writing to RO register makes no sense at all.
Please be aware that the access mode is *RO/RWC*, meaning *Read/Write to Clear*.
>
> Nothing is said about these registers in AR7240 datasheet, but I
> suspect they work exactly same way ;-).
>
> >
> > Looking into irq-ath79-misc.c I found a few things to cleanup.
> >
> > 1. It appears that two chips are declared: "qca,ar7100-misc-intc" and
> > "qca,ar7240-misc-intc".
> > The only difference is mask-ack proc. The registers seem to work the
> > same way and practically we are using "qca,ar7240-misc-intc" on ar7100
> > according to dtsi.
> > I found that the other chip was declared only when looking into the code.
> >
> > At the same time the code I removed from the PCI driver used the
> > ar7100 type of mask-ack, that worked also OK.
> >
> > I see no reason of having two different ways of mask-ack for similar
> > hardware. We need to chose one that looks better and drop the other.
> >
> > 2. Instead of declaring two different chips this way, since we are
> > reusing this driver for PCI, I suggest to declare also
> > "qca,ath79-pci-intc" that will
> > have a different chip name = "PCI", so that "MISC and "PCI" will be
> > seen separately in /proc/interrupts.
> >
> > 3. I suggest removing legacy __init ath79_misc_irq_init() and leaving
> > only the OF stuff.
> >
> > Any comments?
> > ср, 22 авг. 2018 г. в 14:47, Chuanhong Guo :
> > >
> > > Dmitry Tunin 于2018年8月22日周三 下午5:07写道：
> > > >
> > > > Currently all PCI devices get the same IRQ that affects performance
> > > > badly.
> > > >
> > > > This commit adresses this problem and cleans the code.
> > > >
> > > > ar7100 has a special PCI interrupt controller@18060018 that works
> > > > exactly
> > > > the same way as misc interrupt controller.
> > > >
> > > > This patch does the following:
> > > >
> > > > 1. Removes all IRQ handling code from the PCI driver.
> > > > 2. Defines pci-intc interrupt controller@18060018 in dtsi.
> > > > 3. Removes interrupt-controller property from PCI node.
> > > > 4. Sets a correct interrupt mask for PCI devices.
> > > >
> > > > Run tested on DIR-825 B1.
> > > >
> > > > Signed-off-by: Dmitry Tunin
> > > > ---
> > > > target/linux/ath79/dts/ar7100.dtsi | 21 +++-
> > > > .../0036-MIPS-ath79-remove-irq-code-from-pci.patch | 117
> > > > +
> > > > 2 files changed, 133 insertions(+), 5 deletions(-)
> > > > create mode 100644
> > > > target/linux/ath79/patches-4.14/0036-MIPS-ath79-remove-irq-code-from-pci.patch
> > > >
> > > > diff --git a/target/linux/ath79/dts/ar7100.dtsi
> > > > b/target/linux/ath79/dts/ar7100.dtsi
> > > > index 8994a7d..0632050 100644
> > > > --- a/target/linux/ath79/dts/ar7100.dtsi
> > > > +++ b/target/linux/ath79/dts/ar7100.dtsi
> > > > @@ -88,6 +88,14 @@
> > > > clock-names = "wdt";
> > > > };
> > > >
> > > > + pci_intc: interrupt-controller@18060018 {
> > > > + compatible = "qca,ar7240-misc-intc";
> > > > + reg = <0x18060018 0x4>;
> > > I guess this should be <0x18060018 0x8>?
> > > Interrupt status is at 0x18060018-0x1806001c and interrupt mask is at
> > > 0x1806001c-0x18060020. The length of used memory space is 8 bytes.
> > > BTW I noticed that reg of miscintc is <0x18060010 0x4> but the
> > > register of interrupt status and mask is 0x18060010-0x18060018, also 8
> > > bytes.
> > > Are these two mistakes or my misunderstanding of the size in reg property?
> > > > + interrupt-parent = <&cpuintc>;
> > > > + interrupts = <2>;
> > > > + interrupt-controller;
> > > > + #interrupt-cells
Re: [OpenWrt-Devel] [PATCH] ath79: ar7100: remove IRQ code from PCI driver
Dmitry Tunin 于2018年8月23日周四 下午2:07写道： > > чт, 23 авг. 2018 г. в 6:36, Chuanhong Guo : > > > > Dmitry Tunin 于2018年8月23日周四 上午1:24写道： > > > > > > I looked into the specs and now I see that the > > > AR71XX_RESET_REG_MISC_INT_STATUS is read-only on ar7100, so we need to > > > change the compatible > > > to "qca,ar7100-misc-intc" and also change it for the "real" misc > > > controller. Writing to RO register makes no sense at all. > > Please be aware that the access mode is *RO/RWC*, meaning *Read/Write to > > Clear*. > > I noticed that, and it is implemented, and only some bits are RWC. This is true for ar7100. On other chips the entire RST_MISC_INTERRUPT_STATUS block is marked as Read/Write-to-Clear. > It makes no sense to have a separate ack done this way. It slow things down. You can use an implementation without ack for PCI but you should keep the one used for MISC_INTC unchanged. > > And we already tested it both ways. It works either way, but one way > is faster than another. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar71xx with kernel 4.14 - a few test results
Hi! Tom Psyborg 于2018年8月23日周四 下午8:36写道： > > Hi Dirk > > You say: "works quite fine, both radios are available, > no issues at all" > > but no feedback on how it actually performs... > > From my test I got throughput of 215Mbps on 2.4GHz wifi with 4.9 > After upgraded to 4.14 the throughput dropped to 185-190Mbps. same > device same settings and testing conditions. I personally think the performance is expected to be slightly worse because the newer kernel is bigger and more complicated. Qualcomm Atheros addressed some performance loss in their QSDK5.3 release manual as "Limitations" where in this version they upgraded kernel from 3.14 to 4.4. And I experienced a significant decreasing in Samba writing speed on IPQ4019 after this kernel bump in QSDK. There are other shortcomings along with upgraded kernel e.g. the kernel is getting so big that we may not be able to use 4M flash with even just basic functions of a router in a near future. (I remember that someone successfully fit USB support and Samba into 4M flash using OpenWrt Backfire 10.04 and back to those days there are some routers running Linux with only 16M ram.) I guess the reason why OpenWrt still keeps bumping kernels is that it's not realistic to maintain so many kernel versions forever. My suggestion is that if you really care so much about the performance loss caused by bumping kernels you can just keep using an older stable release. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] this patch adds supports for GL-X750. Specification: - SOC: QCA9531 (650MHz) - Flash: 16 MiB (W25Q128FVSG) - RAM: 128 MiB DDR2 - Ethernet: 10/100: 1xLAN + 10/100: 1xWAN - W
First of all, It seems that there is a blank line missing between
title and commit description?
And several suggestions inline :)
Luochongjun 于2018年10月10日周三 下午7:36写道：
>
> Flash instruction:
> The original firmware is openwrt, so both LuCI or sysupgrade can be used.
>
> Signed-off-by: Luo chongjun
> ---
> target/linux/ath79/base-files/etc/board.d/01_leds | 3 +
> .../linux/ath79/base-files/etc/board.d/02_network | 1 +
> .../etc/hotplug.d/firmware/11-ath10k-caldata | 1 +
> target/linux/ath79/dts/qca9533_glinet_x750.dts | 45 ++
> target/linux/ath79/dts/qca9533_glinet_x750.dtsi| 97
> ++
> target/linux/ath79/image/generic.mk| 9 ++
> 6 files changed, 156 insertions(+)
> create mode 100644 target/linux/ath79/dts/qca9533_glinet_x750.dts
> create mode 100644 target/linux/ath79/dts/qca9533_glinet_x750.dtsi
>
> diff --git a/target/linux/ath79/base-files/etc/board.d/01_leds
> b/target/linux/ath79/base-files/etc/board.d/01_leds
> index f04eb7f..46ea99a 100755
> --- a/target/linux/ath79/base-files/etc/board.d/01_leds
> +++ b/target/linux/ath79/base-files/etc/board.d/01_leds
> @@ -42,6 +42,9 @@ on,n150r)
> pcs,cap324)
> ucidef_set_led_netdev "lan" "LAN" "pcs:lan:green" "eth0"
> ;;
> +glinet,x750)
> + ucidef_set_led_netdev "wan" "WAN" "gl-x750:green:wan" "eth0"
> + ;;
All the entries here are ordered alphabetically so you should follow that.
> pcs,cr3000)
> ucidef_set_led_netdev "wan" "WAN" "pcs:blue:wan" "eth1"
> ucidef_set_led_switch "lan1" "LAN1" "pcs:blue:lan1" "switch0" "0x04"
> diff --git a/target/linux/ath79/base-files/etc/board.d/02_network
> b/target/linux/ath79/base-files/etc/board.d/02_network
> index 56eb42f..c18558e 100755
> --- a/target/linux/ath79/base-files/etc/board.d/02_network
> +++ b/target/linux/ath79/base-files/etc/board.d/02_network
> @@ -69,6 +69,7 @@ ath79_setup_interfaces()
> ucidef_set_interface_lan "eth0" "dhcp"
> ;;
> glinet,ar150|\
> + glinet,x750|\
Also needs to follow alphabetical order here.
> glinet,ar300m)
> ucidef_set_interfaces_lan_wan "eth1" "eth0"
> ;;
> diff --git
> a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> index 9365d67..4768488 100644
> --- a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> +++ b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> @@ -104,6 +104,7 @@ case "$FIRMWARE" in
> ath10kcal_extract "art" 20480 2116
> ath10kcal_patch_mac $(macaddr_add $(cat
> /sys/class/net/eth1/address) -1)
> ;;
> + glinet,x750|\
By doing so you break the alphabetical order in this file. The entire
"case" entry should be moved above.
> tplink,re450-v2)
> ath10kcal_extract "art" 20480 2116
> ath10kcal_patch_mac $(macaddr_add $(cat
> /sys/class/net/eth0/address) +1)
> diff --git a/target/linux/ath79/dts/qca9533_glinet_x750.dts
> b/target/linux/ath79/dts/qca9533_glinet_x750.dts
> new file mode 100644
> index 000..2a4044b
> --- /dev/null
> +++ b/target/linux/ath79/dts/qca9533_glinet_x750.dts
> @@ -0,0 +1,45 @@
> +/dts-v1/;
> +
> +#include
> +#include
> +
> +#include "qca9533_glinet_x750.dtsi"
> +
> +&spi {
> + status = "okay";
> + num-cs = <0>;
> +
> + flash@0 {
> + compatible = "winbond,w25q128", "jedec,spi-nor";
"winbond,w25q128" can be dropped here. m25p80 will automatically detect chips.
> + reg = <0>;
> + spi-max-frequency = <2500>;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "u-boot";
> + reg = <0x00 0x04>;
> + read-only;
> + };
> +
> + partition@1 {
Wrong partition label. It should be "partition@{start address}" (so it
should be partition@4 here.)
> + label = "u-boot-env";
> + reg = <0x04 0x01>;
> + };
> +
> +art: partition@2 {
Same as above.
> +label = "art";
> +reg = <0x05 0x01>;
> +};
> +
> + partition@3 {
Same as above.
> + label = "firmware";
> + reg = <0x06 0xfa>;
> + };
> +
> + };
> + };
> +};
> diff --git a/target/linux/ath79/dts/qca9533_glinet_x750.dtsi
> b/target/linux/ath79/dts/q
Re: [OpenWrt-Devel] [PATCH] ath79: add support for Ubiquiti AirRouter
Several suggestions inline :) Russell Senior 于2018年11月16日周五 下午5:25写道： ... > diff --git a/target/linux/ath79/base-files/etc/board.d/01_leds > b/target/linux/ath79/base-files/etc/board.d/01_leds > index f04eb7f5c6..1343e03f90 100755 > --- a/target/linux/ath79/base-files/etc/board.d/01_leds > +++ b/target/linux/ath79/base-files/etc/board.d/01_leds > @@ -93,6 +93,8 @@ tplink,tl-wr841-v11) > ucidef_set_led_switch "lan3" "LAN3" "tp-link:green:lan3" "switch0" > "0x04" > ucidef_set_led_switch "lan4" "LAN4" "tp-link:green:lan4" "switch0" > "0x02" > ;; > +ubnt,airrouter) > + ;; This did nothing. 01_leds is used to add default led configurations. If this device don't need this step you can skip modifying this file. > ubnt,bullet-m|\ > ubnt,nano-m|\ > ubnt,rocket-m) > diff --git a/target/linux/ath79/base-files/etc/board.d/02_network > b/target/linux/ath79/base-files/etc/board.d/02_network > index 5f02c5769a..8fb0188bb6 100755 > --- a/target/linux/ath79/base-files/etc/board.d/02_network > +++ b/target/linux/ath79/base-files/etc/board.d/02_network > @@ -31,6 +31,11 @@ ath79_setup_interfaces() > wd,mynet-wifi-rangeextender) > ucidef_set_interface_lan "eth0" > ;; > + ubnt,airrouter) these "case" statements are in alphabetical order. This should be moved below. > + ucidef_set_interfaces_lan_wan "eth1" "eth0" lan has been handled by ucidef_add_switch. Using ucidef_set_interface_wan "eth0" here should be enough. And by doing so this default configuration is duplicated with tp-link,tl-wr841-v7. You can add this router there. > + ucidef_add_switch "switch0" \ > + "0@eth1" "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" > + ;; > avm,fritz4020) > ucidef_set_interface_wan "eth0" > ucidef_add_switch "switch0" \ ... ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] stop accepting 4/32M board patches
Hi! proxy 于2018年12月6日周四 下午3:31写道： ... > > I'm a user from the Third World. Since devices with 64MB of RAM or Seriously? :) > more are a little expensive for us. > I bought many devices with 1MB flash and 8MB ram, mainly ar9331 qca9533. > Then update the RAM to 64MB, and solder a simple sop8 socket to it, > and use 4MB 8MB 16MB of flash for it. > All works well. These kinds of device modifications isn't the topic discussed here. OpenWrt never accepts device supports that requires any hardware modifications and supports for modified routers usually stays in third-party repositories. Several ar71xx images works on modified TP-LINK routers because: 1. ar71xx has the ability to auto-detect memory and flash size for TP-LINK partition table. 2. TP-LINK sells different products inside China and some routers happens to have a similar board design (except flash/ram) as products they sells worldwide.> > > > > > I'm not sure whether the topic qualifies for a formal voting, hence the > > > RFC. > > > > Thanks for bringing up this topic. > > > > -- > > Cheers, > > Piotr > > > > ___ > > openwrt-devel mailing list > > openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ipq806x: add ath10k calibration data MAC addresses patching
Hi!
On Mon, Oct 29, 2018 at 12:40 AM Christian Lamparter wrote:
>
> Ben Greear reported in his patch:
> |Subject: netgear r7800: Fix mac address of radios.
> |
> |Reloading the driver causes the phyX to change, and that
> |caused the MAC address to change.
>
> This is because all ODM/OEMs except QCA bothered to write
> the correct MAC address for the ath10k wifi into the
> calibration data.
>
> This patch copies over the MAC patching helper functions from ipq40xx's
> target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> file and converts all the devices to patch the correct MACs into the
> extracted calibration data before it gets sent to the driver, which sets
> up the device with the correct MAC address. It also removes the
> 10_fix_wifi_mac file as it has served its purpose.
>
> Please note the C2600: There is conflicting information on what
> the offset for the second wifi is supposed to be. This patch uses
> what was specified in 10_fix_wifi_mac.
>
> Reported-by: Ben Greear
> Signed-off-by: Christian Lamparter
> ---
> .../etc/hotplug.d/firmware/11-ath10k-caldata | 64 +--
> .../etc/hotplug.d/ieee80211/10_fix_wifi_mac | 37 ---
> 2 files changed, 57 insertions(+), 44 deletions(-)
> delete mode 100644
> target/linux/ipq806x/base-files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
>
> diff --git
> a/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> b/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> index fa49c250f0..1d070603f2 100644
> --- a/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> +++ b/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> @@ -1,5 +1,21 @@
> #!/bin/sh
>
> +# xor multiple hex values of the same length
> +xor() {
> + local val
> + local ret="0x$1"
> + local retlen=${#1}
> +
> + shift
> + while [ -n "$1" ]; do
> + val="0x$1"
> + ret=$((ret ^ val))
> + shift
> + done
> +
> + printf "%0${retlen}x" "$ret"
> +}
> +
> ath10kcal_die() {
> echo "ath10cal: " "$*"
> exit 1
> @@ -36,6 +52,29 @@ ath10kcal_patch_mac() {
> macaddr_2bin $mac | dd of=/lib/firmware/$FIRMWARE conv=notrunc bs=1
> seek=6 count=6
> }
>
> +ath10kcal_patch_mac_crc() {
> + local mac=$1
> + local mac_offset=6
> + local chksum_offset=2
> + local xor_mac
> + local xor_fw_mac
> + local xor_fw_chksum
> +
> + xor_fw_mac=$(hexdump -v -n 6 -s $mac_offset -e '/1 "%02x"'
> /lib/firmware/$FIRMWARE)
> + xor_fw_mac="${xor_fw_mac:0:4} ${xor_fw_mac:4:4} ${xor_fw_mac:8:4}"
> +
> + ath10kcal_patch_mac "$mac" && {
> + xor_mac=${mac//:/}
> + xor_mac="${xor_mac:0:4} ${xor_mac:4:4} ${xor_mac:8:4}"
> +
> + xor_fw_chksum=$(hexdump -v -n 2 -s $chksum_offset -e '/1
> "%02x"' /lib/firmware/$FIRMWARE)
> + xor_fw_chksum=$(xor $xor_fw_chksum $xor_fw_mac $xor_mac)
> +
> + printf "%b" "\x${xor_fw_chksum:0:2}\x${xor_fw_chksum:2:2}" | \
> + dd of=/lib/firmware/$FIRMWARE conv=notrunc bs=1
> seek=$chksum_offset count=2
> + }
> +}
> +
I think we should replace the ath10kcal_patch_mac directly instead of
introducing another function.
All ath10k calibration data have a checksum at 0x2.
ath10kcal_patch_mac works for QCA9880/QCA9882 only because the ath10k
firmware for these two chips doesn't check the checksum value. (QCA
proprietary driver checks this and refuses to use caldata with
incorrect checksum.)
> [ -e /lib/firmware/$FIRMWARE ] && exit 0
>
> . /lib/functions.sh
> @@ -43,53 +82,64 @@ ath10kcal_patch_mac() {
>
> board=$(board_name)
>
> -
> case "$FIRMWARE" in
> "ath10k/pre-cal-pci-:01:00.0.bin")
> case $board in
> linksys,ea8500)
> - hw_mac_addr=$(mtd_get_mac_ascii devinfo hw_mac_addr)
> ath10kcal_extract "art" 4096 12064
> + ath10kcal_patch_mac_crc $(macaddr_add $(mtd_get_mac_ascii
> devinfo hw_mac_addr) +1)
> + ;;
> + nec,wg2600hp)
> + ath10kcal_extract "ART" 4096 12064
> + ath10kcal_patch_mac_crc $(macaddr_add $(mtd_get_mac_binary
> PRODUCTDATA 12) +1)
> ;;
> netgear,d7800 |\
> netgear,r7500v2 |\
> netgear,r7800)
> ath10kcal_extract "art" 4096 12064
> + ath10kcal_patch_mac_crc $(macaddr_add $(mtd_get_mac_binary
> art 6) +1)
> ;;
> tplink,c2600)
> ath10kcal_extract "radio" 4096 12064
> -# ath10kcal_patch_mac $(macaddr_add $(mtd_get_mac_binary
> default-mac 8) -1)
> + ath10kcal_patch_mac_crc $(macaddr_add $(mtd_get_mac_binary
> default-mac 8) -1)
> ;;
> - nec,wg2600hp |\
> tplink,vr2600v)
> ath10kcal_extract "ART" 4096 12064
> + at
Re: [OpenWrt-Devel] ath79: seting GPIO registers to specific values via DTS?
Hi!
On Mon, Dec 17, 2018 at 7:43 AM Roger Pueyo Centelles | Guifi.net
wrote:
>
> Hi Seb,
>
> You nailed it! :-)
>
> I was missing the ' "pinctrl-names = "default"; ' line. I must have
> removed it from the .dts file I used as the source for mine at some
> point. Then I just sorted the pinctrl-0/1 issue, which I had already
> tried in any possible combination.
>
> After fixing this, I have detected another issue that had passed
> unnoticed to me before. The eth1 interface always appears as UP (i.e.,
> having link), even if I unplug the cable.
This is expected. gmac1 is connected to builtin switch, which means
this link is always up. Link changes happen in builtin switch, not
gmac.
ar71xx mixed switch and gmac driver together and it uses switch port
status for gmac link. These two drivers are separated in ath79.
>
> According to the datasheet, GMAC1 (eth1 here) is internally connected to
> the integrated switch. The "swconfig dev switch0 show" command gives:
>
> Port 0:
> enable_mirror_rx: 0
> enable_mirror_tx: 0
> pvid: 0
> link: port:0 link:up speed:1000baseT full-duplex txflow rxflow
> Port 1:
> enable_mirror_rx: 0
> enable_mirror_tx: 0
> pvid: 1
> link: port:1 link:up speed:100baseT full-duplex auto
>
> How should I manage this?
>
> Thank you very much for your support.
>
> Best,
>
> Roger
>
> El 16/12/18 a les 19:07, Sebastian Kemper ha escrit:
> > On Sun, Dec 16, 2018 at 06:23:53PM +0100, Roger Pueyo Centelles | Guifi.net
> > wrote:
> >>
> >> Hi,
> > Hello Roger!
> >
> >> [...]
> >>
> >> leds {
> >> compatible = "gpio-leds";
> >> pinctrl-1 = <&led_rssilow_pin &led_rssimediumhigh_pin
> >> &led_rssihigh_pin>;
> >>
> >> [...]
> >>
> >> &pinmux {
> >> led_rssilow_pin: pinmux_rssilow_pin {
> >> pinctrl-single,bits = <0x8 0x0 0xff00>;
> >> };
> >>
> >> led_rssimediumhigh_pin: pinmux_rssimediumhigh_pin {
> >> pinctrl-single,bits = <0xc 0x0 0x00ff>;
> >> };
> >>
> >> led_rssihigh_pin: pinmux_rssihigh_pin {
> >> pinctrl-single,bits = <0x10 0x0 0x00ff>;
> >> };
> >> };
> >>
> >> [...]
> > The pinmux part looks OK to me. Could you change the leds part to the
> > below and try again?
> >
> > leds {
> > compatible = "gpio-leds";
> >
> > pinctrl-names = "default";
> > pinctrl-0 = <&jtag_disable_pins &led_rssilow_pin
> > &led_rssimediumhigh_pin &led_rssihigh_pin>;
> >
> > [...]
> >
> > I added the jtag bit because I saw that you use it under keys. You have
> > to remove
> >
> > pinctrl-0 = <&jtag_disable_pins>;
> >
> > under keys. Just put them all in one place.
> >
> > From my testing, when defining pinctrl-0 and pinctrl-1, the second one
> > doesn't do anything. For example:
> >
> > pinctrl-0 = <&jtag_disable_pins>; // works
> > pinctrl-1 = <&enable_gpio_11>; // nothing happens
> >
> > But
> >
> > pinctrl-0 = <&jtag_disable_pins &enable_gpio_11>; // both are applied -
> > works
> >
> >
> > Kind regards,
> > Seb
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] generic: ar8216: ar8327: kill warnings
This fixed warnings caused by returning value in a void function
Signed-off-by: Chuanhong Guo
---
target/linux/generic/files/drivers/net/phy/ar8327.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/target/linux/generic/files/drivers/net/phy/ar8327.c
b/target/linux/generic/files/drivers/net/phy/ar8327.c
index 13e911bbc3..5af6aaf6f2 100644
--- a/target/linux/generic/files/drivers/net/phy/ar8327.c
+++ b/target/linux/generic/files/drivers/net/phy/ar8327.c
@@ -139,7 +139,7 @@ ar8327_phy_rgmii_set(struct ar8xxx_priv *priv, struct
phy_device *phydev)
if (!of_property_read_bool(np, "qca,phy-rgmii-en")) {
pr_err("ar8327: qca,phy-rgmii-en is not specified\n");
- return -EINVAL;
+ return;
}
ar8xxx_phy_dbg_read(priv, phyaddr,
AR8327_PHY_MODE_SEL, &phy_val);
@@ -150,7 +150,7 @@ ar8327_phy_rgmii_set(struct ar8xxx_priv *priv, struct
phy_device *phydev)
/* set rgmii tx clock delay if needed */
if (!of_property_read_bool(np, "qca,txclk-delay-en")) {
pr_err("ar8327: qca,txclk-delay-en is not specified\n");
- return -EINVAL;
+ return;
}
ar8xxx_phy_dbg_read(priv, phyaddr,
AR8327_PHY_SYS_CTRL, &phy_val);
@@ -161,7 +161,7 @@ ar8327_phy_rgmii_set(struct ar8xxx_priv *priv, struct
phy_device *phydev)
/* set rgmii rx clock delay if needed */
if (!of_property_read_bool(np, "qca,rxclk-delay-en")) {
pr_err("ar8327: qca,rxclk-delay-en is not specified\n");
- return -EINVAL;
+ return;
}
ar8xxx_phy_dbg_read(priv, phyaddr,
AR8327_PHY_TEST_CTRL, &phy_val);
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Invalid revision range
Hi! On Tue, Jan 22, 2019 at 3:16 AM R. Diez via openwrt-devel wrote: ... > If Git fails with a "fatal" error inside getver.sh, how come the build does > not stop at that point? Failed to calculate current revision isn't a "fatal error". As you can see in getver.sh it falls back to reporting an "unknown" version and the rest of the buildroot works just fine. A exact revision isn't a must during the entire building procedure. > For example: do we still need support for "version" and "hg" (Mercurial) in > that script? The version file is for people to easily set their custom version if they want. (e.g. if a manufacturer wants to pack their own OpenWrt buildroot for their customers, this feature is useful) As for hg OpenWrt never officially uses this as a version controlling tool. I think it's there so that it's convenient when people want to use this in their custom branch. It was added 10 years ago in svn r17432. > > Best regards, >rdiez > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: ag71xx: Fix tx queue timeouts during ifup
Hi! On Thu, Jan 3, 2019 at 10:25 AM Petr Štetiar wrote: > > On ath79 and UBNT Bullet M XW (ar9342) I was experiencing weird issues during > network setup[1] which I was able to reproduce easily with following commands: > > uci set network.lan.ipaddr='192.168.1.20' > uci commit network > ifup lan > > Which resulted after some time in: > > ... > WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:461 > dev_watchdog+0x16c/0x280 > NETDEV WATCHDOG: eth0 (ag71xx): transmit queue 0 timed out > ... > So I've looked at ag71xx_stop() in ar71xx, added the missing bits to ath79 and > fixed this issue. I ran into the same issue today on QCA9558 and this commit fixed the problem for me, too :) > > 1. https://github.com/openwrt/openwrt/pull/1635#issuecomment-448638246 > > Signed-off-by: Petr Štetiar > ... ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Current "OpenWrt Style Guide for DTS"?
Hi!
I picked several things I could answer below :)
On Wed, Jan 23, 2019 at 6:07 AM Jeff Kletsky wrote:
...
>
> Choice of Node Naming for Partitions
>
>
> In some DTS files, the partitions are named using sequential integers.
> In others, the offset of the partition is used.
>
> * Which of the two is preferred?
>
> uboot: u-boot@0 {
> firmware@2 {
> art: art@ff {
>
> vs.
>
> partition@0 {
> partition@1 {
> partition@2 {
> art: partition@3 {
Neither. It's partition@:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=6dd94c2781b79ffd20f1a57a48fa2314d67ee190
>
...
> TAB vs. SPACE Indentation
> =
>
> * It appears that TAB indentation is being used. Is this correct?
Yes.
>
> read-only Partitions
>
>
> * Is it appropriate to mark the boot-loader partition as read-only?
>
> * What about the art partition?
>
> Doing so would seem to be able help prevent users following outdated
> or ill-advised suggestions to write to their file systems using
> low-level access.
Correct. Both of those partitions aren't supposed to be written normally.
>
> Advanced users that, for some reason, want to overwrite these critical
> partitions could always compile their own kernel with the restriction
> removed.
Yes. They are always able to make their custom firmware for this purpose.
>
>
>
> ---
> Context for the following questions is discussed below the "8<" marker
> TL;DR Stable references to partitions for DT modification when "inheriting"
> ---
>
> Partition "label" Properties
>
>
> Some of the "label" properties seem obviously named, like "firmware"
> and "art" and I assume that the kernel and drivers key off of these.
>
> * Is there a list of "reserved" and/or "preferred" values for the
>label property of the partitions?
OpenWrt kernel will try to automatically split "firmware“ into
kernel/rootfs, and it'll auto-attach "ubi" partition as a ubi device.
Besides these two the other names doesn't have any strict
requirements. People usually follow what the manufacturer defined in
their stock firmware.
"art" stands for "Atheros Radio Test" and it's widely used for
calibration data on QCA routers by the manufacturers. There are some
devices using other names for calibration data partition.
We tell the driver where to load calibration data in dts or load it
for drivers using firmware hotplug scripts.
>
>
>
> Labels for Partition Nodes
> ==
>
> I've noticed that there are some common labels for partition nodes in
> use. A quick check of the ath79 platform shows
>
> addr, art, ART, caldata, eeprom, firmware, info, mac, mtdparts,
> nvram, partitions, uboot, ubootenv
>
> * Is there a list of any of these that are "reserved" by general DTS
>files under OpenWrt?
As I said above, "firmware" and "ubi" are reserved for special purposes.
Other labels are usually just copied from manufacturers' firmware.
>
> At least as I understand DTS definition, these labels are not passed
> to the kernel, but only during compilation.
No. These labels will be saved in the compiled dtb files and can be
used by drivers.
e.g. mtd partition node labels will be used as mtd partition name.
>
> * Assuming this is the case, is there any guidance for adding
>"commonly used" labels or "device-specific" labels?
>
>
> 8<
>
> The questions above around the "label" property and labels arise
> mainly because I'm working with devices that have both NOR and NAND
> flash. With the goal of easier maintainability and potential utility,
> I'd like to define the partitioning *once* for a physical device and,
> if needed, modify it for the NOR and NAND instances.
>
> These devices that I'm working with can, once the boot loader is
> running off NOR, boot either from NOR or from NAND (with fall-back if
> the preferred one fails). Flashing both variants simultaneously has
> benefits, but how to accomplish that may need to be the subject of
> another thread.
>
> At least as I (weakly) understand the use of
>
> label = "firmware"
> compatible = "denx,uimage"
>
> from https://openwrt.org/docs/guide-developer/defining-firmware-partitions
> there is some magic in the boot loader to know that the kernel is in the
> "firmware" partition and that the kernel, once running, can split the
> firmware partition into kernel and filesystem partitions, on the
> fly.
Incorrect. They are used by the kernel to properly split firmware
partition into kernel/rootfs.
OpenWrt dynamically determine the sizes of these two partitions to
avoid space wasted in a fixed kernel partition.
This compatible string was introduced upstream and OpenWrt folks wants
to use it to get rid of the current hack for firmware partition.
Currently OpenWrt patched the mtd framework so that when registering a
partition named 'firmware' it tries to apply every available mtdsplit
Re: [OpenWrt-Devel] ath79 (qca95xx): Status of SPI-Attached NAND Drivers?
Hi! On Sat, Jan 26, 2019 at 5:09 AM Jeff Kletsky wrote: > > Context > === > > Working on bringing up the GL.iNet AR750S as a NAND variant > on the ath79 target. While I can build an image, it fails to attach > a driver to the SPI-attached NAND. There is a GL.iNet AR300M NAND > variant, but I am unable to confirm if this device will fully boot > from the images generated (as my AR300M is NOR only). > > > Questions > = > > * What is the level of support for QCA9531 and QCA9563 SoCs for NAND? Completely nothing :) The upstream SPI NAND framework is available in 4.19. I do have a backport of it to 4.14 but that changed so many things that it doesn't worth submitting. As for raw nand driver for AR9344/QCA9558, the ar934x-nfc driver isn't ported to ath79 yet. > > * Is the AR300M NAND target bootable? No due to lack of a SPI NAND driver. > >* If not, should it be removed from the list of valid targets > until NAND support is available and confirmed bootable? I agree. I think this subtarget should be disabled. > > > Thanks, > > Jeff > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ramips: drop m25p,chunked-io from dts
This option was a spi nor hack which is dropped in gbcf4a5f474
Signed-off-by: Chuanhong Guo
---
target/linux/ramips/dts/AP-MT7621A-V60.dts | 1 -
target/linux/ramips/dts/AWUSFREE1.dts | 1 -
target/linux/ramips/dts/DIR-860L-B1.dts| 1 -
target/linux/ramips/dts/DUZUN-DM06.dts | 1 -
target/linux/ramips/dts/EW1200.dts | 1 -
target/linux/ramips/dts/FIREWRT.dts| 1 -
target/linux/ramips/dts/GB-PC1.dts | 1 -
target/linux/ramips/dts/GB-PC2.dts | 1 -
target/linux/ramips/dts/GL-MT300N-V2.dts | 1 -
target/linux/ramips/dts/HC5661A.dts| 1 -
target/linux/ramips/dts/HC5861B.dts| 1 -
target/linux/ramips/dts/K2P.dts| 1 -
target/linux/ramips/dts/LINKIT7688.dts | 1 -
target/linux/ramips/dts/MAC1200RV2.dts | 1 -
target/linux/ramips/dts/MIWIFI-NANO.dts| 1 -
target/linux/ramips/dts/MT7628.dts | 1 -
target/linux/ramips/dts/Newifi-D2.dts | 1 -
target/linux/ramips/dts/OMEGA2.dtsi| 1 -
target/linux/ramips/dts/PBR-D1.dts | 1 -
target/linux/ramips/dts/PBR-M1.dts | 1 -
target/linux/ramips/dts/R6120.dts | 1 -
target/linux/ramips/dts/RE350.dts | 1 -
target/linux/ramips/dts/RE6500.dts | 1 -
target/linux/ramips/dts/SAP-G3200U3.dts| 1 -
target/linux/ramips/dts/SK-WB8.dts | 1 -
target/linux/ramips/dts/SKW92A.dts | 1 -
target/linux/ramips/dts/TL-MR3020V3.dts| 1 -
target/linux/ramips/dts/TL-WR840NV5.dts| 1 -
target/linux/ramips/dts/TPLINK-8M-SPLIT-UBOOT.dtsi | 1 -
target/linux/ramips/dts/TPLINK-8M.dtsi | 1 -
target/linux/ramips/dts/Timecloud.dts | 1 -
target/linux/ramips/dts/U7621-06-256M-16M.dts | 1 -
target/linux/ramips/dts/U7621-06-512M-64M.dts | 1 -
target/linux/ramips/dts/U7628-01-128M-16M.dts | 1 -
target/linux/ramips/dts/UBNT-ER-e50.dtsi | 1 -
target/linux/ramips/dts/VOCORE2.dts| 1 -
target/linux/ramips/dts/VOCORE2LITE.dts| 1 -
target/linux/ramips/dts/VR500.dts | 1 -
target/linux/ramips/dts/W06.dts| 1 -
target/linux/ramips/dts/W2914NSV2.dtsi | 1 -
target/linux/ramips/dts/WCR-1166DS.dts | 1 -
target/linux/ramips/dts/WIDORA-NEO-16M.dts | 1 -
target/linux/ramips/dts/WIDORA-NEO-32M.dts | 1 -
target/linux/ramips/dts/WITI.dtsi | 1 -
target/linux/ramips/dts/WL-WN570HA1.dts| 1 -
target/linux/ramips/dts/WL-WN575A3.dts | 1 -
target/linux/ramips/dts/WN-AX1167GR.dts| 1 -
target/linux/ramips/dts/WN-GX300GR.dts | 1 -
target/linux/ramips/dts/WNDR3700V5.dts | 1 -
target/linux/ramips/dts/WR1200JS.dts | 1 -
target/linux/ramips/dts/WR1201.dts | 1 -
target/linux/ramips/dts/WRC-1167GHBK2-S.dts| 1 -
target/linux/ramips/dts/WRTNODE2.dtsi | 1 -
target/linux/ramips/dts/WSR-1166.dts | 1 -
target/linux/ramips/dts/WSR-600.dts| 1 -
target/linux/ramips/dts/ZBT-WE1226.dts | 1 -
target/linux/ramips/dts/ZBT-WE1326.dts | 1 -
target/linux/ramips/dts/ZBT-WE3526.dts | 1 -
target/linux/ramips/dts/ZBT-WG2626.dts | 1 -
target/linux/ramips/dts/ZBT-WG3526.dtsi| 1 -
target/linux/ramips/dts/elecom_wrc-gst.dtsi| 1 -
target/linux/ramips/dts/ki_rb.dts | 1 -
62 files changed, 62 deletions(-)
diff --git a/target/linux/ramips/dts/AP-MT7621A-V60.dts
b/target/linux/ramips/dts/AP-MT7621A-V60.dts
index bd29e0b3f2..b613c9c371 100644
--- a/target/linux/ramips/dts/AP-MT7621A-V60.dts
+++ b/target/linux/ramips/dts/AP-MT7621A-V60.dts
@@ -85,7 +85,6 @@
compatible = "mx25l6405d","jedec,spi-nor";
reg = <0 0>;
spi-max-frequency = <1000>;
- m25p,chunked-io = <32>;
partitions {
compatible = "fixed-partitions";
diff --git a/target/linux/ramips/dts/AWUSFREE1.dts
b/target/linux/ramips/dts/AWUSFREE1.dts
index 3edafb3335..52d1e4ebe2 100644
--- a/target/linux/ramips/dts/AWUSFREE1.dts
+++ b/target/linux/ramips/dts/AWUSFREE1.dts
@@ -129,7 +129,6 @@
compatible = "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <1000>;
- m25p,chunked-io = <32>;
partitions {
compatible = "fixed-partitions";
diff --git a/target/linux/ramips/dts/DIR-860L-B1.dts
b/target/linux/ramips/dts/DIR-860L-B1.dts
index a37d68ff3b..541520f852 100644
--- a/target/linux/r
Re: [OpenWrt-Devel] [PATCH 1/2] ath79: fix qca955x pcie0 memory size
Hi! On Fri, Feb 1, 2019 at 9:53 PM Philippe Mathieu-Daudé wrote: > [...] > Now that you pointed this line, I am not sure it is correct... > It maps I/O (0x0100) region of 1B (0 0x01) from PCI 0x > (0 0x) at 0x000 (0x000) into cpu space. > But the DDR is already mapped at 0x000 in cpu address space... > Am I missing something? The atheros PCIE controller doesn't have an IO space at all. (at least the documentation doesn't mention it.) I'm not sure if it's possible to write a PCIE driver without IO space. I guess the existing code just uses 1 byte of system memory as a placeholder. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: Increase GB-PC2 SPI speed to 50MHz
Hi! On Mon, Feb 11, 2019 at 7:49 AM Rosen Penev wrote: > [...] > On the PC1, I can go even higher with the SPI frequency to get better > performance. However, the later versions of the PC1 switched flash > chips to Spansion to avoid a restart bug. Those are documented as > accepting 50MHz for read requests. FYI: I haven't check the Spansion datasheet, but when Winbond datasheets say read instruction accepts SPI clock up to 50MHz it refers to the normal read instruction (0x03) and for higher clock you should switch to fast read instruction (0x0B) which can be done by adding m25p,fast-read to dts. I guess the situation with Spansion datasheets are the same. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ath79: fix wmac memory region for qca953x
According to /arch/mips/include/asm/mach-ath79/ar71xx_regs.h
the size of wmac register range for qca953x is only 0x2.
Signed-off-by: Chuanhong Guo
---
target/linux/ath79/dts/qca953x.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/ath79/dts/qca953x.dtsi
b/target/linux/ath79/dts/qca953x.dtsi
index 4ce5bfe0a2..669e3fb851 100644
--- a/target/linux/ath79/dts/qca953x.dtsi
+++ b/target/linux/ath79/dts/qca953x.dtsi
@@ -173,7 +173,7 @@
wmac: wmac@1810 {
compatible = "qca,qca9530-wmac";
- reg = <0x1810 0x23>;
+ reg = <0x1810 0x2>;
interrupt-parent = <&intc2>;
interrupts = <0>;
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] mediatek: add support for TOTOLINK A8000RU
Specifications:
- SoC: MT7622
- RAM: 512MB
- Flash: MX35LF1GE4AB 128MB SPI NAND
- Ethernet: RTL8367S 5x1GbE
- WiFi: 2.4G: MT7622 5G: MT7615N x2
- Other ports: USB3.0 x1
Flash instruction:
*important*: upgrade vendor firmware to at least V7.1cu.643_B20200521
1. hold the reset button and power on the device. wait for about 10s
before releasing the reset button.
2. upload sysupgrade.bin via u-boot recovery page on http://192.168.1.1
Signed-off-by: Chuanhong Guo
---
.../mediatek/dts/mt7622-totolink-a8000ru.dts | 329 ++
target/linux/mediatek/image/mt7622.mk | 10 +
.../mt7622/base-files/lib/upgrade/platform.sh | 6 +
3 files changed, 345 insertions(+)
create mode 100644 target/linux/mediatek/dts/mt7622-totolink-a8000ru.dts
diff --git a/target/linux/mediatek/dts/mt7622-totolink-a8000ru.dts
b/target/linux/mediatek/dts/mt7622-totolink-a8000ru.dts
new file mode 100644
index 00..0386865cc2
--- /dev/null
+++ b/target/linux/mediatek/dts/mt7622-totolink-a8000ru.dts
@@ -0,0 +1,329 @@
+// SPDX-License-Identifier: (GPL-2.0-only OR MIT)
+
+/dts-v1/;
+#include
+#include
+
+#include "mt7622.dtsi"
+#include "mt6380.dtsi"
+
+/ {
+ model = "TOTOLINK A8000RU";
+ compatible = "totolink,a8000ru", "mediatek,mt7622";
+
+ aliases {
+ label-mac-device = &gmac0;
+ led-boot = &led_status;
+ led-failsafe = &led_status;
+ led-running = &led_status;
+ led-upgrade = &led_status;
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ bootargs = "earlycon=uart8250,mmio32,0x11002000 swiotlb=512";
+ };
+
+ cpus {
+ cpu@0 {
+ proc-supply = <&mt6380_vcpu_reg>;
+ sram-supply = <&mt6380_vm_reg>;
+ };
+
+ cpu@1 {
+ proc-supply = <&mt6380_vcpu_reg>;
+ sram-supply = <&mt6380_vm_reg>;
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ reset {
+ label = "reset";
+ linux,code = ;
+ gpios = <&pio 0 GPIO_ACTIVE_LOW>;
+ };
+
+ wps {
+ label = "wps";
+ linux,code = ;
+ gpios = <&pio 102 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ led_status: status_red {
+ label = "red:status";
+ gpios = <&pio 81 GPIO_ACTIVE_LOW>;
+ default-state = "on";
+ };
+ };
+
+ reg_1p8v: regulator-1p8v {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-1.8V";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.3V";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ rtkgsw: rtkgsw@0 {
+ compatible = "mediatek,rtk-gsw";
+ mediatek,ethsys = <ðsys>;
+ mediatek,mdio = <&mdio>;
+ mediatek,reset-pin = <&pio 54 0>;
+ status = "okay";
+ };
+};
+
+&pcie0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie0_pins>;
+ status = "okay";
+};
+
+&slot0 {
+ mt7615@0,0 {
+ reg = <0x 0 0 0 0>;
+ mediatek,mtd-eeprom = <&factory 0x5000>;
+ ieee80211-freq-limit = <549 600>;
+ };
+};
+
+&pcie1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie1_pins>;
+ status = "okay";
+};
+
+&slot1 {
+ mt7615@0,0 {
+ reg = <0x 0 0 0 0>;
+ mediatek,mtd-eeprom = <&factory 0x1>;
+ ieee80211-freq-limit = <500 549>;
+ };
+};
+
+&pio {
+ eth_pins: eth-pins {
+ mux {
+ function = "eth";
+ groups = "mdc_mdio", "rgmii_via_gmac2";
+ };
+
[PATCH] mediatek: bmt: use generic mtd api
BMT replaces nand-specific ops for erasing and writing, but the
mtk-snand driver only implements generic mtd api.
Replace erase, block_isbad, block_markbad in mtd_info for generic mtd
drivers.
Fixes: b600aee3ed ("mediatek: attach bmt to the new snand driver")
Signed-off-by: Chuanhong Guo
---
.../patches-5.10/330-mtk-bmt-support.patch| 107 ++
1 file changed, 57 insertions(+), 50 deletions(-)
diff --git a/target/linux/mediatek/patches-5.10/330-mtk-bmt-support.patch
b/target/linux/mediatek/patches-5.10/330-mtk-bmt-support.patch
index 72a729c7f3..bf70fb75b9 100644
--- a/target/linux/mediatek/patches-5.10/330-mtk-bmt-support.patch
+++ b/target/linux/mediatek/patches-5.10/330-mtk-bmt-support.patch
@@ -23,7 +23,7 @@
obj-y += raw/
--- /dev/null
+++ b/drivers/mtd/nand/mtk_bmt.c
-@@ -0,0 +1,781 @@
+@@ -0,0 +1,788 @@
+/*
+ * Copyright (c) 2017 MediaTek Inc.
+ * Author: Xiangsheng Hou
@@ -43,7 +43,7 @@
+#include
+#include
+#include
-+#include
++#include
+#include
+#include
+#include
@@ -89,7 +89,9 @@
+struct mtd_oob_ops *ops);
+ int (*_write_oob) (struct mtd_info *mtd, loff_t to,
+ struct mtd_oob_ops *ops);
-+ const struct nand_ops *nand_ops;
++ int (*_erase) (struct mtd_info *mtd, struct erase_info *instr);
++ int (*_block_isbad) (struct mtd_info *mtd, loff_t ofs);
++ int (*_block_markbad) (struct mtd_info *mtd, loff_t ofs);
+
+ struct bbbt *bbt;
+
@@ -145,12 +147,13 @@
+
+static inline int bbt_nand_erase(u16 block)
+{
-+ struct nand_device *nand = mtd_to_nanddev(bmtd.mtd);
-+ loff_t addr = (loff_t)block << bmtd.blk_shift;
-+ struct nand_pos pos;
++ struct mtd_info *mtd = bmtd.mtd;
++ struct erase_info instr = {
++ .addr = (loff_t)block << bmtd.blk_shift,
++ .len = bmtd.blk_size,
++ };
+
-+ nanddev_offs_to_pos(nand, addr, &pos);
-+ return bmtd.nand_ops->erase(nand, &pos);
++ return bmtd._erase(mtd, &instr);
+}
+
+/* Bad Blocks Management */
@@ -544,76 +547,80 @@
+ return 0;
+}
+
-+
-+
+static int
-+mtk_bmt_erase(struct nand_device *nand, const struct nand_pos *pos)
++mtk_bmt_mtd_erase(struct mtd_info *mtd, struct erase_info *instr)
+{
-+ struct nand_pos new_pos = *pos;
++ struct erase_info mapped_instr = {
++ .len = bmtd.blk_size,
++ };
+ int retry_count = 0;
++ u64 start_addr, end_addr;
+ int ret;
-+
-+retry:
-+ new_pos.eraseblock = get_mapping_block_index(pos->eraseblock);
-+
-+ ret = bmtd.nand_ops->erase(nand, &new_pos);
-+ if (ret) {
-+ update_bmt(pos->eraseblock);
-+ if (retry_count++ < 10)
-+ goto retry;
++ u16 orig_block, block;
++
++ start_addr = instr->addr & (~mtd->erasesize_mask);
++ end_addr = instr->addr + instr->len;
++
++ while (start_addr < end_addr) {
++ orig_block = start_addr >> bmtd.blk_shift;
++ block = get_mapping_block_index(orig_block);
++ mapped_instr.addr = (loff_t)block << bmtd.blk_shift;
++ ret = bmtd._erase(mtd, &mapped_instr);
++ if (ret) {
++ update_bmt(orig_block);
++ if (retry_count++ < 10)
++ continue;
++ instr->fail_addr = start_addr;
++ break;
++ }
++ start_addr += mtd->erasesize;
++ retry_count = 0;
+ }
+
+ return ret;
+}
-+
-+static bool
-+mtk_bmt_isbad(struct nand_device *nand, const struct nand_pos *pos)
++static int
++mtk_bmt_block_isbad(struct mtd_info *mtd, loff_t ofs)
+{
-+ struct nand_pos new_pos = *pos;
+ int retry_count = 0;
-+ bool ret;
++ u16 orig_block = ofs >> bmtd.blk_shift;
++ u16 block;
++ int ret;
+
+retry:
-+ new_pos.eraseblock = get_mapping_block_index(pos->eraseblock);
-+
-+ ret = bmtd.nand_ops->isbad(nand, &new_pos);
++ block = get_mapping_block_index(orig_block);
++ ret = bmtd._block_isbad(mtd, (loff_t)block << bmtd.blk_shift);
+ if (ret) {
-+ update_bmt(pos->eraseblock);
++ update_bmt(orig_block);
+ if (retry_count++ < 10)
+ goto retry;
+ }
-+
+ return ret;
+}
+
+static int
-+mtk_bmt_markbad(struct nand_device *nand, const struct nand_pos *pos)
++mtk_bmt_block_markbad(struct mtd_info *mtd, loff_t ofs)
+{
-+ struct nand_pos new_pos = *pos;
-+
-+ new_pos.eraseblock = get_mapping_block_index(new_pos.eraseblock);
-+ update_bmt(pos->eraseblock);
-+
-+ return bmtd.nand_ops->markbad(nand, &new_pos);
++ u16 orig_block = ofs >> bmtd.blk_shift;
++ u16 block = get_mapping_block
Re: [PATCH 3/3] ramips: mt7621-dts: add pinctrl properties for ethernet
Hi! On Tue, Feb 8, 2022 at 3:38 AM Arınç ÜNAL wrote: > diff --git a/target/linux/ramips/dts/mt7621.dtsi > b/target/linux/ramips/dts/mt7621.dtsi > index 9256e118e4..95113d4e11 100644 > --- a/target/linux/ramips/dts/mt7621.dtsi > +++ b/target/linux/ramips/dts/mt7621.dtsi > @@ -456,6 +456,9 @@ > > mediatek,ethsys = <&sysc>; > > + pinctrl-names = "default"; > + pinctrl-0 = <&rgmii1_pins &rgmii2_pins &mdio_pins>; > + There are devices using rgmii2 pins as GPIO. (e.g. PBR-M1) rgmii2_pins should be excluded from pinctrl-0 in dts of these routers if you enable it by default here. -- Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 21.02] ramips: mt7621: do memory detection on KSEG1
Hi!
On Mon, Feb 21, 2022 at 10:22 AM Szabolcs Hubai wrote:
>
> From: Chuanhong Guo
>
> It's reported that current memory detection code occasionally detects
> larger memory under some bootloaders.
> Current memory detection code tests whether address space wraps around
> on KSEG0, which is unreliable because it's cached.
>
> Rewrite memory size detection to perform the same test on KSEG1 instead.
> While at it, this patch also does the following two things:
> 1. use a fixed pattern instead of a random function pointer as the magic
>value.
> 2. add an additional memory write and a second comparison as part of the
>test to prevent possible smaller memory detection result due to
>leftover values in memory.
>
> Fixes: 6d91ddf517 ("ramips: mt7621: add support for memory detection")
> Reported-by: Rui Salvaterra
> Tested-by: Rui Salvaterra
> Signed-off-by: Chuanhong Guo
> (cherry picked from commit 2f024b79331141e2a62c9bf3601c803b26bde77b)
> [backport for OpenWrt 21.02 as it was reproducible with Kernel 5.4, see [1]]
> [1]: https://forum.openwrt.org/t/113081
> Tested-by: Dimitri Souza [mt7621/archer-c6-v3]
> Signed-off-by: Szabolcs Hubai
Merged. Thanks!
--
Regards,
Chuanhong Guo
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ar71xx: Add support for PISEN TS-D084
PISEN TS-D084 is an wireless router with a battery and integrated power supply
based on Atheros AR9331.
Specification:
- 400/400/200 MHz (CPU/DDR/AHB)
- 64 MB of RAM (DDR2)
- 8 MB of FLASH (SPI NOR)
- 1x 10/100 Mbps Ethernet
- 1T1R 2.4 GHz (AR9331)
- 1x USB 2.0
Flash instruction:
The manufacturer are using exactly the same firmware header as TP-LINK
TL-WR703N (including device ID!). Simply upload the factory firmware into WebUI
and flashing is done.
Signed-off-by: Chuanhong Guo
---
target/linux/ar71xx/base-files/etc/diag.sh | 1 +
target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 +
.../ar71xx/base-files/lib/upgrade/platform.sh | 1 +
target/linux/ar71xx/config-4.9 | 1 +
.../ar71xx/files/arch/mips/ath79/Kconfig.openwrt | 10 +++
target/linux/ar71xx/files/arch/mips/ath79/Makefile | 1 +
.../ar71xx/files/arch/mips/ath79/mach-ts-d084.c| 86 ++
.../linux/ar71xx/files/arch/mips/ath79/machtypes.h | 1 +
target/linux/ar71xx/generic/config-default | 1 +
target/linux/ar71xx/image/generic.mk | 11 +++
10 files changed, 116 insertions(+)
create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-ts-d084.c
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
b/target/linux/ar71xx/base-files/etc/diag.sh
index 797c30f8a5..6a42335f2f 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -208,6 +208,7 @@ get_status_led() {
;;
e600g-v2|\
oolite-v5.2-dev|\
+ ts-d084|\
wifi-pineapple-nano)
status_led="$board:blue:system"
;;
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 7249cb6151..73b6fa9859 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -1319,6 +1319,9 @@ ar71xx_board_detect() {
*"TL-WR942N v1")
name="tl-wr942n-v1"
;;
+ *"TS-D084")
+ name="ts-d084"
+ ;;
*"Tube2H")
name="tube2h"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 376984a14a..39a8e90bb7 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -483,6 +483,7 @@ platform_check_image() {
tl-wr941nd|\
tl-wr941nd-v5|\
tl-wr941nd-v6|\
+ ts-d084|\
wifi-pineapple-nano)
local magic_ver="0100"
diff --git a/target/linux/ar71xx/config-4.9 b/target/linux/ar71xx/config-4.9
index 5cea1b7bde..356c939c10 100644
--- a/target/linux/ar71xx/config-4.9
+++ b/target/linux/ar71xx/config-4.9
@@ -232,6 +232,7 @@ CONFIG_ATH79=y
# CONFIG_ATH79_MACH_TL_WR941ND is not set
# CONFIG_ATH79_MACH_TL_WR941ND_V6 is not set
# CONFIG_ATH79_MACH_TL_WR942N_V1 is not set
+# CONFIG_ATH79_MACH_TS_D084 is not set
# CONFIG_ATH79_MACH_TUBE2H is not set
# CONFIG_ATH79_MACH_UBNT is not set
# CONFIG_ATH79_MACH_UBNT_UNIFIAC is not set
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
index 4a032f6021..d0a811b544 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
+++ b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
@@ -1997,6 +1997,16 @@ config ATH79_MACH_TL_WR2543N
select ATH79_DEV_M25P80
select ATH79_DEV_USB
+config ATH79_MACH_TS_D084
+ bool "PISEN TS-D084 support"
+ select SOC_AR933X
+ select ATH79_DEV_ETH
+ select ATH79_DEV_GPIO_BUTTONS
+ select ATH79_DEV_LEDS_GPIO
+ select ATH79_DEV_M25P80
+ select ATH79_DEV_USB
+ select ATH79_DEV_WMAC
+
config ATH79_MACH_TEW_632BRP
bool "TRENDnet TEW-632BRP support"
select SOC_AR913X
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Makefile
b/target/linux/ar71xx/files/arch/mips/ath79/Makefile
index e606e2c3df..c603273e2e 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/Makefile
+++ b/target/linux/ar71xx/files/arch/mips/ath79/Makefile
@@ -242,6 +242,7 @@ obj-$(CONFIG_ATH79_MACH_TL_WR941ND) +=
mach-tl-wr941nd.o
obj-$(CONFIG_ATH79_MACH_TL_WR941ND_V6) += mach-tl-wr941nd-v6.o
obj-$(CONFIG_ATH79_MACH_TL_WR940N_V4) += mach-tl-wr940n-v4.o
obj-$(CONFIG_ATH79_MACH_TL_WR942N_V1) += mach-tl-wr942n-v1.o
+obj-$(CONFIG_ATH79_MACH_TS_D084) += mach-ts-d084.o
obj-$(CONFIG_ATH79_MACH_TUBE2H)+= mach-tube2h.o
obj-$(CONFIG_ATH79_MACH_UBNT) += mach-ubnt.o
obj-$(CONFIG_ATH79_MACH_UBNT_UNIFIAC) += mach-ubnt-unifiac.o
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-ts-d084
