Luci / Custom Commands
Hi, I want like to add the following command to Luci/Custom Commands: echo "/" > /proc/net/xt_recent/SSH_BLOCK But I can only add: echo "> /proc/net/xt_recent/SSH_BLOCK" How can I do it? Regards, Hartmut ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ipq40xx: add support for GL.iNet GL-B2200-EMMC
This patch adds supports for GL-B2200-EMMC.
Specifications:
- SOC: Qualcomm IPQ4019 ARM Quad-Core
- RAM: 512 MiB
- Flash: 16 MiB NOR - SPI0
- EMMC: 8GB EMMC
- ETH: Qualcomm QCA8075
- WLAN1: Qualcomm Atheros QCA4019 2.4GHz 802.11b/g/n 2x2
- WLAN2: Qualcomm Atheros QCA4019 5GHz 802.11n/ac W2 2x2
- WLAN3: Qualcomm Atheros QCA9886 5GHz 802.11n/ac W2 2x2
- INPUT: Reset, WPS
- LED: Power, Internet
- UART1: On board pin header near to LED (3.3V, TX, RX, GND), 3.3V
without pin - 115200 8N1
- UART2: On board with BLE module
- SPI1: On board socket for Zigbee module
Update firmware instructions
Pleae update firmware on uboot web(default 192.168.1.1).
Signed-off-by: Li Zhang
---
package/firmware/ipq-wifi/Makefile | 2 +
.../ipq-wifi/board-glinet_gl-b2200-emmc.qca4019| Bin 0 -> 24316 bytes
.../ipq-wifi/board-glinet_gl-b2200-emmc.qca9888| Bin 0 -> 12168 bytes
target/linux/ipq40xx/Makefile | 2 +-
.../ipq40xx/base-files/etc/board.d/02_network | 5 +
.../etc/hotplug.d/firmware/11-ath10k-caldata | 3 +
.../arm/boot/dts/qcom-ipq4019-gl-b2200-emmc.dts| 374 +
target/linux/ipq40xx/image/gen_sdcard_img.sh | 95 ++
target/linux/ipq40xx/image/generic.mk | 22 ++
.../patches-5.4/901-arm-boot-add-dts-files.patch | 3 +-
10 files changed, 504 insertions(+), 2 deletions(-)
create mode 100644 package/firmware/ipq-wifi/board-glinet_gl-b2200-emmc.qca4019
create mode 100644 package/firmware/ipq-wifi/board-glinet_gl-b2200-emmc.qca9888
create mode 100644
target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-gl-b2200-emmc.dts
create mode 100755 target/linux/ipq40xx/image/gen_sdcard_img.sh
diff --git a/package/firmware/ipq-wifi/Makefile
b/package/firmware/ipq-wifi/Makefile
index 7703604..7d592d9 100644
--- a/package/firmware/ipq-wifi/Makefile
+++ b/package/firmware/ipq-wifi/Makefile
@@ -40,6 +40,7 @@ ALLWIFIBOARDS:= \
ezviz_cs-w3-wd1200g-eup \
glinet_gl-ap1300 \
glinet_gl-s1300 \
+ glinet_gl-b2200-emmc \
linksys_ea8300 \
linksys_mr8300-v0 \
luma_wrtq-329acn \
@@ -124,6 +125,7 @@ $(eval $(call
generate-ipq-wifi-package,engenius_emr3500,EnGenius EMR3500))
$(eval $(call generate-ipq-wifi-package,ezviz_cs-w3-wd1200g-eup,EZVIZ
CS-W3-WD1200G EUP))
$(eval $(call generate-ipq-wifi-package,glinet_gl-ap1300,GL.iNet GL-AP1300))
$(eval $(call generate-ipq-wifi-package,glinet_gl-s1300,GL.iNet GL-S1300))
+$(eval $(call generate-ipq-wifi-package,glinet_gl-b2200-emmc,GL.iNet
GL-B2200-EMMC))
$(eval $(call generate-ipq-wifi-package,linksys_ea8300,Linksys EA8300))
$(eval $(call generate-ipq-wifi-package,linksys_mr8300-v0,Linksys MR8300))
$(eval $(call generate-ipq-wifi-package,luma_wrtq-329acn,Luma WRTQ-329ACN))
diff --git a/package/firmware/ipq-wifi/board-glinet_gl-b2200-emmc.qca4019
b/package/firmware/ipq-wifi/board-glinet_gl-b2200-emmc.qca4019
new file mode 100644
index
..c4721328e1bbaad8722b3b5f74c88af6c8c5214d
GIT binary patch
literal 24316
zcmeHPdr(tX8b1jj>SE!BfCzXAAv{7MK%g2V@)iR`u&79YB2YzgYm|rKVdz3TJ}5*)
zpcV`fv<%9lDI(+Ii&(6!ol&NL>>oS(N88y)cV^wS9qmp#v%9$G-sD0Ei6#PD9`_69
zobR0bedm1VcTbXgbAH@66XJs7c8kJ7Q-kBv<1!L~OeO7fVZmrTe#r61Bo31!ep3DnB%+qM%G#aQNuf?c(5gK0h=xc-xL02{Ib=XTiQ$
zA);a$4cOE&A~NxQ1G{0C55QV`C#V3x1mLxBLNlFlxoo^E0K&t=e|q|qCSV_DXJ=<)AOPIKXKJCiKs&?a3hRc+!fvL_9HC5Ambg;V
zG>9)7z091<*r2Mh`apJSvS93*sj
z&;cVHdSNHU*{Om6*j-C?Np^-HRPW$FGrpJ9s-e8ZWaeSYVJ04?Ys(=%IItv!te
zm5~ShGd)wsTgz&bWW0SY@pt-5JCaTXl)2@14CHh~o??|d7xXq1$Ri8=c5O_)-F&!a
zn=~lLCHjlL>W|V-@ya*8eRH6)V@G3frDxH|>Ef#B1Kdm`@)op9#CSQ*(U*Ir?V^U)
zD?N&Dd{WUBQtMUXoWHbCqM{`cu(MzDn{|$ev&;Go9vjIIe1j7IjD3;7e&7WWp3&)a
z8lKzOz^~<1da=J!mlf*v;N6{kl*93Xf4*#QZy&Zdo1JO9+US~u42dci5P__$j5Ide
z3y$#f&rg4toW!qy1YBPqUE6OsTgJ4Z42YB8xAy;bH^T@Kfz)Eq2X0u)LVN@ftC
zmWCN%W;Cxzlx846RVV}~1SkY31SkY31XeHt>-p;uFUEHMb|js#nZFr{VXP(vWE8es
z8op|mkH@vQ|*#8Nv;`dUOb;@o28$Rhw?
zS*7eAd1PD$2Et#z;m_Y}7Nspm3>MK+G#N@PK!Ef2+&TclfFI=NctJK02U4NfFyUo0
zBMh+Fo}O$YX@l*vTiNW~Rt^vfXyB(K0JPa7wAcs$0#+kH2!yuzs}MkUp|8z_rIQn}
z>1Z-0s&RQB@O;RDNvH3JI}mVpnQpuKBPbW4kh2?wGM6@S7W{DS9{I{#>F?*u`8AVn
z=T5g*r`w$q@7$f0o4>zU+1%FN+1+zxaA;)o&S&?(dSv|pgMB>fu3VRlH6Zpu#f*A#
zCzRL&701_;yP(AWr&Ryu$T-SbSPG4TA
zOwWcn$wWL+PoAfk2@)q05iu&}iN%Q^Vln~|qC%cf95HYA*VCg~qq*{35tNa{PeRfd
zoA{fMXh!yV{587|@_UXfm&z@UwVeB~mvZi-@6%|Ia9`C-Fu+~9AtL#ZyKP?w6@tV4
zV$Qu}!8rHVhyV<-7jo_m>}IMj=iH-+p@)w9ZokUL&UT9Z4#4&2)>83Ja_$WW!vCMa
zK<0t#&tx(Io=96(qU%WSW{b(Te;MvEmwfBw(E{ps=Jzrr?ioO_`#B2>rOpPc;HkMqyNH^sRR
z(hE+#$65Dm_B?9(T@2XsoHbJmjN;tu?l5mp-)OEt)so*&4B7TNoq$Y-)`I8w+BM|c
zmAXceClP3`tIsJ)B}oEb?Xadt
zslX%xPyGMHZr}9}0MMaTEm!Q3@Fs>dXO%~=42eK9qVC2pNtz%?`#W`uLMDk9uyBVv
zIUeXrn#l;z$!$d
z01xe``a>clFFd5X_X4;8PPI#OMlDz7!;sYK6UtJBL~~W$g~>#5f{=+@noG)RY_Gsw
z=fL&D=g^`)rYusV!Gjl+RoG5R2n?h{A(x~IxD(ek=apqxx`=~2d^XO7C|%QbsLPdk
zi
Re: [PATCH] kernel: Disable IXP4xx physmap by default
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- I definitely have interested, but I’m currently trying to contribute to the new realtek switch effort and also have some D-Link and Netgear Octeon devices I’d like to add support for. I would be happy to provide reviews and testing on devices as time permits. I have about 30 different IXP4xx devices available in my collection. The Edgewater Networks and WatchGuard IXP4xx devices have decent specs and are widely available on eBay now that the vendors no longer support them. Ray > On Apr 15, 2021, at 4:48 AM, Linus Walleij wrote: > > On Thu, Apr 15, 2021 at 8:03 AM Raylynn Knight wrote: > >> Now that there is DTS support in the mainline kernel for IXP4xx what is the >> recommended approach for re-enabling support for devices with adequate >> Flash and RAM (i.e. ADI Engineering SBC250, Gateworks Avila and Cambria, >> US Robotics USR8200)? > > The right approach is to finish the driver migration in the mainline kernel, > so that all of the platform can be probed from DTS files. > > The two main drivers to be fixed are: > > - The ethernet phy DTS binding (I was planning to work on this but you > know, time) > > - The PCI host complex > > I think complete migration should be doable, some minor drivers may > need some extra work after that but these two things would make > complete device tree migration possible for all boards. > So if we fix this we can start to re-enable IXP4xx on top. > > (Then there will be some fringe drivers, for example the NSLU2 > beeper driver...) > > There is a bigger issue for complete modernization of the architecture. > The PCI host is a complicated beast because accesses to PCI on > IXP4xx are crippled. You can see that in this file: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-ixp4xx/include/mach/io.h > the _indirect versions of generic readw/writel etc are really serious > stuff. My idea for a long-term solution is to create some infrastructure > for runtime patching. A really complicated problem for someone > who has time to spend. > >> There is already a DTS available for the Gateworks Cambria GW2358. >> I also have access to Edgewater Networks, Secure Computing and >> WatchGuard devices that use the IXP4xx processor and have adequate >> Flash and RAM. > > I think making device trees for all of them should be doable once we > have migrated ethernet and PCI host to device tree. > > Now that I know there is interest I might get more motivation to > work on it :) can I include you on CC if I post patches for > review? > > Yours, > Linus Walleij > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel signature.asc Description: Message signed with OpenPGP --- End Message --- ___ 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
[PATCH] ath79: drop cs-gpios property
The spi-ath79 driver performs the chipselect by writing to dedicated
register in the SPI register block. So the GPIO numbers were not used.
Tested-on: Enterasys WS-AP3705i
Signed-off-by: David Bauer
---
target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dtsi| 1 -
target/linux/ath79/dts/ar7242_buffalo_wzr-bhr.dtsi | 2 --
target/linux/ath79/dts/ar7242_buffalo_wzr-hp-g302h-a1a0.dts | 2 --
target/linux/ath79/dts/ar9344_enterasys_ws-ap3705i.dts | 2 --
4 files changed, 7 deletions(-)
diff --git a/target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dtsi
b/target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dtsi
index 109ed0caf3..b8176dc059 100644
--- a/target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dtsi
+++ b/target/linux/ath79/dts/ar7161_buffalo_wzr-hp-ag300h.dtsi
@@ -219,7 +219,6 @@
&spi {
status = "okay";
- cs-gpios = <0>, <0>;
flash0: flash@0 {
compatible = "jedec,spi-nor";
diff --git a/target/linux/ath79/dts/ar7242_buffalo_wzr-bhr.dtsi
b/target/linux/ath79/dts/ar7242_buffalo_wzr-bhr.dtsi
index 98f6759eac..df28111598 100644
--- a/target/linux/ath79/dts/ar7242_buffalo_wzr-bhr.dtsi
+++ b/target/linux/ath79/dts/ar7242_buffalo_wzr-bhr.dtsi
@@ -107,8 +107,6 @@
&spi {
status = "okay";
- cs-gpios = <0>, <0>;
-
flash0: flash@0 {
compatible = "jedec,spi-nor";
reg = <0>;
diff --git a/target/linux/ath79/dts/ar7242_buffalo_wzr-hp-g302h-a1a0.dts
b/target/linux/ath79/dts/ar7242_buffalo_wzr-hp-g302h-a1a0.dts
index 7cb051a475..111d06491e 100644
--- a/target/linux/ath79/dts/ar7242_buffalo_wzr-hp-g302h-a1a0.dts
+++ b/target/linux/ath79/dts/ar7242_buffalo_wzr-hp-g302h-a1a0.dts
@@ -163,8 +163,6 @@
&spi {
status = "okay";
- cs-gpios = <0>, <0>;
-
flash0: flash@0 {
compatible = "jedec,spi-nor";
reg = <0>;
diff --git a/target/linux/ath79/dts/ar9344_enterasys_ws-ap3705i.dts
b/target/linux/ath79/dts/ar9344_enterasys_ws-ap3705i.dts
index 52becec18b..8f8276255a 100644
--- a/target/linux/ath79/dts/ar9344_enterasys_ws-ap3705i.dts
+++ b/target/linux/ath79/dts/ar9344_enterasys_ws-ap3705i.dts
@@ -114,8 +114,6 @@
&spi {
status = "okay";
- cs-gpios = <0>, <0>;
-
flash@0 {
compatible = "jedec,spi-nor";
reg = <0>;
--
2.31.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] kernel: Disable IXP4xx physmap by default
On Thu, Apr 15, 2021 at 8:03 AM Raylynn Knight wrote: > Now that there is DTS support in the mainline kernel for IXP4xx what is the > recommended approach for re-enabling support for devices with adequate > Flash and RAM (i.e. ADI Engineering SBC250, Gateworks Avila and Cambria, > US Robotics USR8200)? The right approach is to finish the driver migration in the mainline kernel, so that all of the platform can be probed from DTS files. The two main drivers to be fixed are: - The ethernet phy DTS binding (I was planning to work on this but you know, time) - The PCI host complex I think complete migration should be doable, some minor drivers may need some extra work after that but these two things would make complete device tree migration possible for all boards. So if we fix this we can start to re-enable IXP4xx on top. (Then there will be some fringe drivers, for example the NSLU2 beeper driver...) There is a bigger issue for complete modernization of the architecture. The PCI host is a complicated beast because accesses to PCI on IXP4xx are crippled. You can see that in this file: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-ixp4xx/include/mach/io.h the _indirect versions of generic readw/writel etc are really serious stuff. My idea for a long-term solution is to create some infrastructure for runtime patching. A really complicated problem for someone who has time to spend. > There is already a DTS available for the Gateworks Cambria GW2358. > I also have access to Edgewater Networks, Secure Computing and > WatchGuard devices that use the IXP4xx processor and have adequate > Flash and RAM. I think making device trees for all of them should be doable once we have migrated ethernet and PCI host to device tree. Now that I know there is interest I might get more motivation to work on it :) can I include you on CC if I post patches for review? Yours, Linus Walleij ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
