[PATCH v2 1/4] kernel: remove target specific setting of CONFIG_TCP_CONG_ADVANCED
The option was introduced in upstream linux commit a6484045 ("[TCP]: Do
not present confusing congestion control options by default.").
The option is set to y in generic config and to the moment does not
incur additional size increment. Make it y for all so that packages
such as kmod-tcp-bbr do not have to set it on every occasion
Signed-off-by: Yousong Zhou
---
target/linux/layerscape/armv7/config-5.4 | 1 -
target/linux/layerscape/armv8_64b/config-5.4 | 1 -
target/linux/zynq/config-5.4 | 1 -
3 files changed, 3 deletions(-)
diff --git a/target/linux/layerscape/armv7/config-5.4
b/target/linux/layerscape/armv7/config-5.4
index 15c3492349..019119d6db 100644
--- a/target/linux/layerscape/armv7/config-5.4
+++ b/target/linux/layerscape/armv7/config-5.4
@@ -715,7 +715,6 @@ CONFIG_SYNC_FILE=y
CONFIG_SYSFS_SYSCALL=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_SYS_SUPPORTS_HUGETLBFS=y
-# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_THERMAL=y
CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE=y
CONFIG_THERMAL_EMERGENCY_POWEROFF_DELAY_MS=0
diff --git a/target/linux/layerscape/armv8_64b/config-5.4
b/target/linux/layerscape/armv8_64b/config-5.4
index dd9abca986..cd8ea82e52 100644
--- a/target/linux/layerscape/armv8_64b/config-5.4
+++ b/target/linux/layerscape/armv8_64b/config-5.4
@@ -894,7 +894,6 @@ CONFIG_TASKS_RCU=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
CONFIG_TASK_XACCT=y
-# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_THERMAL=y
CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE=y
CONFIG_THERMAL_EMERGENCY_POWEROFF_DELAY_MS=0
diff --git a/target/linux/zynq/config-5.4 b/target/linux/zynq/config-5.4
index 5b7b0ebfb3..04fde2add2 100644
--- a/target/linux/zynq/config-5.4
+++ b/target/linux/zynq/config-5.4
@@ -572,7 +572,6 @@ CONFIG_SWP_EMULATE=y
CONFIG_SYNC_FILE=y
CONFIG_SYSFS_SYSCALL=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
-# CONFIG_TCP_CONG_ADVANCED is not set
# CONFIG_TEXTSEARCH is not set
CONFIG_THERMAL=y
CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE=y
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 4/4] kmod-tcp-hybla: new module for hybla congestion control algorithm
Just the module and no default sysctl conf file is provided Link: https://forum.openwrt.org/t/20-xx-tcp-hybla/83076 Signed-off-by: Yousong Zhou --- package/kernel/linux/modules/netsupport.mk | 18 ++ 1 file changed, 18 insertions(+) diff --git a/package/kernel/linux/modules/netsupport.mk b/package/kernel/linux/modules/netsupport.mk index d287e46270..4e78ac5478 100644 --- a/package/kernel/linux/modules/netsupport.mk +++ b/package/kernel/linux/modules/netsupport.mk @@ -947,6 +947,24 @@ endef $(eval $(call KernelPackage,tcp-bbr)) +define KernelPackage/tcp-hybla + SUBMENU:=$(NETWORK_SUPPORT_MENU) + TITLE:=TCP-Hybla congestion control algorithm + KCONFIG:=CONFIG_TCP_CONG_HYBLA + FILES:=$(LINUX_DIR)/net/ipv4/tcp_hybla.ko + AUTOLOAD:=$(call AutoProbe,tcp_hybla) +endef + +define KernelPackage/tcp-hybla/description + TCP-Hybla is a sender-side only change that eliminates penalization of + long-RTT, large-bandwidth connections, like when satellite legs are + involved, especially when sharing a common bottleneck with normal + terrestrial connections. +endef + +$(eval $(call KernelPackage,tcp-hybla)) + + define KernelPackage/ax25 SUBMENU:=$(NETWORK_SUPPORT_MENU) TITLE:=AX25 support ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 0/4] add tcp hybla congestion control algorithm
CONFIG_TCP_CONG_ADVANCED=y do not incur addition space cost. Quote
commit message of the first commit
> The option was introduced in upstream linux commit a6484045 ("[TCP]:
> Do not present confusing congestion control options by default.").
tcp-hybla cca will be a module, like kmod-tcp-bbr, it should not affect
users of default build and config
v2 <- v1
- Use CONFIG_TCP_CONG_ADVANCED=y in generic config
- Use AutoProbe instead of AutoLoad with custom prio order
- Existing kmod-tcp-bbr was changed to align with above
Yousong Zhou (4):
kernel: remove target specific setting of CONFIG_TCP_CONG_ADVANCED
kmod-tcp-bbr: leave CONFIG_TCP_CONG_ADVANCED to target config
kmod-tcp-bbr: use AutoProbe
kmod-tcp-hybla: new module for hybla congestion control algorithm
package/kernel/linux/modules/netsupport.mk | 24
target/linux/layerscape/armv7/config-5.4 | 1 -
target/linux/layerscape/armv8_64b/config-5.4 | 1 -
target/linux/zynq/config-5.4 | 1 -
4 files changed, 20 insertions(+), 7 deletions(-)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 3/4] kmod-tcp-bbr: use AutoProbe
Signed-off-by: Yousong Zhou --- package/kernel/linux/modules/netsupport.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/kernel/linux/modules/netsupport.mk b/package/kernel/linux/modules/netsupport.mk index 958b510015..d287e46270 100644 --- a/package/kernel/linux/modules/netsupport.mk +++ b/package/kernel/linux/modules/netsupport.mk @@ -928,7 +928,7 @@ define KernelPackage/tcp-bbr TITLE:=BBR TCP congestion control KCONFIG:=CONFIG_TCP_CONG_BBR FILES:=$(LINUX_DIR)/net/ipv4/tcp_bbr.ko - AUTOLOAD:=$(call AutoLoad,74,tcp_bbr) + AUTOLOAD:=$(call AutoProbe,tcp_bbr) endef define KernelPackage/tcp-bbr/description ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 2/4] kmod-tcp-bbr: leave CONFIG_TCP_CONG_ADVANCED to target config
Since generic has the option set to y and other targets now inherit that choice, there is no behaviour change Signed-off-by: Yousong Zhou --- package/kernel/linux/modules/netsupport.mk | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/package/kernel/linux/modules/netsupport.mk b/package/kernel/linux/modules/netsupport.mk index 0c68b394d1..958b510015 100644 --- a/package/kernel/linux/modules/netsupport.mk +++ b/package/kernel/linux/modules/netsupport.mk @@ -926,9 +926,7 @@ $(eval $(call KernelPackage,sched)) define KernelPackage/tcp-bbr SUBMENU:=$(NETWORK_SUPPORT_MENU) TITLE:=BBR TCP congestion control - KCONFIG:= \ - CONFIG_TCP_CONG_ADVANCED=y \ - CONFIG_TCP_CONG_BBR + KCONFIG:=CONFIG_TCP_CONG_BBR FILES:=$(LINUX_DIR)/net/ipv4/tcp_bbr.ko AUTOLOAD:=$(call AutoLoad,74,tcp_bbr) endef ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: arc700 + glibc fails
On Wed, Dec 23, 2020 at 8:40 PM Alexey Brodkin
wrote:
>
> Hi Rosen, Hauke!
>
> > On Wed, Dec 23, 2020 at 6:54 AM Hauke Mehrtens wrote:
> > >
> > > Hi,
> > >
> > > ARC was switched from uClibc to glibc here:
> > > https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=95f1002acab574c24ad78f4453f091bf5a6731c7
> > > uClibc support was removed from OpenWrt in the next commit.
> > >
> > > It looks like arc700 is not supported by glibc 2.32, only ARC HS38 is
> > > supported.
>
> Correct, upstream glibc v2.32 only supports ARCv2 as of today.
> I forgot about that fact during discussion about uClibc removal here
> https://github.com/openwrt/openwrt/pull/3673#issuecomment-747373099
> because we used to add support for ARCompact ISA (i.e. ARC700 cores)
> via off-the-tree-patch, see
> https://github.com/foss-for-synopsys-dwc-arc-processors/glibc/commit/571c4c3df73bddbbb012b792a62f03e76b980ef3
> and note how simple it is fixing exactly the issue reported here.
Great. My current patch against glibc is:
--- a/sysdeps/arc/atomic-machine.h
+++ b/sysdeps/arc/atomic-machine.h
@@ -64,6 +64,10 @@ typedef uintmax_t uatomic_max_t;
__atomic_val_bysize (__arch_compare_and_exchange_val, int, \
mem, new, old, __ATOMIC_ACQUIRE)
+#ifdef __ARC700__
+#define atomic_full_barrier() ({ asm volatile ("sync":::"memory"); })
+#else
#define atomic_full_barrier() ({ asm volatile ("dmb 3":::"memory"); })
+#endif
#endif /* _ARC_BITS_ATOMIC_H */
--- a/sysdeps/unix/sysv/linux/arc/syscall.S
+++ b/sysdeps/unix/sysv/linux/arc/syscall.S
@@ -24,8 +24,13 @@ ENTRY (syscall)
mov_s r1, r2
mov_s r2, r3
mov_s r3, r4
+#ifdef __ARC700__
+ mov r4, r5
+ mov r5, r6
+#else
mov_s r4, r5
mov_s r5, r6
+#endif
ARC_TRAP_INSN
brhir0, -4096, L (call_syscall_err)
--- a/sysdeps/unix/sysv/linux/arc/sysdep.h
+++ b/sysdeps/unix/sysv/linux/arc/sysdep.h
@@ -128,7 +128,11 @@ L (call_syscall_err):
ASM_LINE_SEP\
movr8, __NR_##syscall_name ASM_LINE_SEP\
ARC_TRAP_INSN ASM_LINE_SEP
+# ifdef __ARC700__
+# define ARC_TRAP_INSN trap0
+# else
# define ARC_TRAP_INSN trap_s 0
+# endif
#else /* !__ASSEMBLER__ */
@@ -139,7 +143,11 @@ extern long int __syscall_error (long int);
hidden_proto (__syscall_error)
# endif
+# ifdef __ARC700__
+# define ARC_TRAP_INSN "trap0 \n\t"
+# else
# define ARC_TRAP_INSN "trap_s 0 \n\t"
+#endif
# undef INTERNAL_SYSCALL_NCS
# define INTERNAL_SYSCALL_NCS(number, nr_args, args...)\
Initial results look promising. I'll test compilation before submitting.
>
> > > On the arc770 target I am getting this compiler errors in the glibc:
> > > -
> > > msort.c: Assembler messages:
> > > msort.c:201: Error: opcode 'dmb' not supported for target arc700
> > > -
> > > http://buildbot.openwrt.org/master/images/builders/arc770%2Fgeneric/builds/749
> > >
> > > After this one is fixed I get this one:
> > > -
> > > ../sysdeps/unix/sysv/linux/arc/syscall.S: Assembler messages:
> > > ../sysdeps/unix/sysv/linux/arc/syscall.S:27: Error: register must be
> > > either r0-r3 or r12-r15 for instruction 'mov_s'
> > > ../sysdeps/unix/sysv/linux/arc/syscall.S:28: Error: register must be
> > > either r0-r3 or r12-r15 for instruction 'mov_s'
> > > -
> > >
> > > Does anyone plan to fix glibc with arc700 or should we just remove the
> > > arc770 target, the arhs38 target is compiling?
>
> So indeed what we may do here is either to retrofit ARC700 into existing glibc
> via aforementioned patch in OpenWrt or remove support of ARC700 at all.
>
> I'd suggest for a moment to stop building for ARC700 while this discussion
> is in progress and some people who's opinion I'd like to hear also are
> on the Christmas break.
ARC700 can be marked as BROKEN which means disabled by default.
>
> > I'll look into it. My vote is to remove support for ARC altogether as
> > it doesn't seem any hardware uses it except for some dev kits.
>
> Well that I'd prefer to not do. Even though in upstream OpenWrt indeed we
> only have 2 development boards which we support, there might be other users
> (and here I mean companies, not even individuals) which use or plan to use
> OpenWrt on their ARC-based SoCs/boards.
>
> The fact those boards are not exposed to wider audience and are not sold
> as affordable consumer Wi-Fi routers doesn't mean they don't exist.
Right. The OpenWrt project began to service WiFi routers. That's still
most of the userbase.
>
> Moreover with recent introduction of ARCv3 processors which include
> 64-bit cores we're planning to add their support in OpenWrt as well
> as soon as our toolchain matures a little bit so that we're confident
> majority of packages could be built with it normally.
That's great to hear.
>
> So if ARC doesn't add a lot of troubles for the community, let's keep it
> in the project.
Not hav
Re: arc700 + glibc fails
Hi Rosen, Hauke! > On Wed, Dec 23, 2020 at 6:54 AM Hauke Mehrtens wrote: > > > > Hi, > > > > ARC was switched from uClibc to glibc here: > > https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=95f1002acab574c24ad78f4453f091bf5a6731c7 > > uClibc support was removed from OpenWrt in the next commit. > > > > It looks like arc700 is not supported by glibc 2.32, only ARC HS38 is > > supported. Correct, upstream glibc v2.32 only supports ARCv2 as of today. I forgot about that fact during discussion about uClibc removal here https://github.com/openwrt/openwrt/pull/3673#issuecomment-747373099 because we used to add support for ARCompact ISA (i.e. ARC700 cores) via off-the-tree-patch, see https://github.com/foss-for-synopsys-dwc-arc-processors/glibc/commit/571c4c3df73bddbbb012b792a62f03e76b980ef3 and note how simple it is fixing exactly the issue reported here. > > On the arc770 target I am getting this compiler errors in the glibc: > > - > > msort.c: Assembler messages: > > msort.c:201: Error: opcode 'dmb' not supported for target arc700 > > - > > http://buildbot.openwrt.org/master/images/builders/arc770%2Fgeneric/builds/749 > > > > After this one is fixed I get this one: > > - > > ../sysdeps/unix/sysv/linux/arc/syscall.S: Assembler messages: > > ../sysdeps/unix/sysv/linux/arc/syscall.S:27: Error: register must be > > either r0-r3 or r12-r15 for instruction 'mov_s' > > ../sysdeps/unix/sysv/linux/arc/syscall.S:28: Error: register must be > > either r0-r3 or r12-r15 for instruction 'mov_s' > > - > > > > Does anyone plan to fix glibc with arc700 or should we just remove the > > arc770 target, the arhs38 target is compiling? So indeed what we may do here is either to retrofit ARC700 into existing glibc via aforementioned patch in OpenWrt or remove support of ARC700 at all. I'd suggest for a moment to stop building for ARC700 while this discussion is in progress and some people who's opinion I'd like to hear also are on the Christmas break. > I'll look into it. My vote is to remove support for ARC altogether as > it doesn't seem any hardware uses it except for some dev kits. Well that I'd prefer to not do. Even though in upstream OpenWrt indeed we only have 2 development boards which we support, there might be other users (and here I mean companies, not even individuals) which use or plan to use OpenWrt on their ARC-based SoCs/boards. The fact those boards are not exposed to wider audience and are not sold as affordable consumer Wi-Fi routers doesn't mean they don't exist. Moreover with recent introduction of ARCv3 processors which include 64-bit cores we're planning to add their support in OpenWrt as well as soon as our toolchain matures a little bit so that we're confident majority of packages could be built with it normally. So if ARC doesn't add a lot of troubles for the community, let's keep it in the project. > > I think the archs38 target was not runtime tested with glibc, could > > someone with access to the hardware please check if it is still working > > with glibc in master. gdbserver also got ARC support please also check > > if this now works and we can remove the dependency on !arc. Right, there's a chance we haven't run glibc flavor of OpenWrt on ARC, previously focused on uClibc. But we'll do that now, thanks for the hint! -Alexey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: arc700 + glibc fails
On Wed, Dec 23, 2020 at 6:54 AM Hauke Mehrtens wrote:
>
> Hi,
>
> ARC was switched from uClibc to glibc here:
> https://git.openwrt.org/95f1002acab574c24ad78f4453f091bf5a6731c7
> uClibc support was removed from OpenWrt in the next commit.
>
> It looks like arc700 is not supported by glibc 2.32, only ARC HS38 is
> supported.
>
> On the arc770 target I am getting this compiler errors in the glibc:
> -
> msort.c: Assembler messages:
> msort.c:201: Error: opcode 'dmb' not supported for target arc700
> -
> http://buildbot.openwrt.org/master/images/builders/arc770%2Fgeneric/builds/749
>
> After this one is fixed I get this one:
> -
> ../sysdeps/unix/sysv/linux/arc/syscall.S: Assembler messages:
> ../sysdeps/unix/sysv/linux/arc/syscall.S:27: Error: register must be
> either r0-r3 or r12-r15 for instruction 'mov_s'
> ../sysdeps/unix/sysv/linux/arc/syscall.S:28: Error: register must be
> either r0-r3 or r12-r15 for instruction 'mov_s'
> -
>
> Does anyone plan to fix glibc with arc700 or should we just remove the
> arc770 target, the arhs38 target is compiling?
I'll look into it. My vote is to remove support for ARC altogether as
it doesn't seem any hardware uses it except for some dev kits.
>
> I think the archs38 target was not runtime tested with glibc, could
> someone with access to the hardware please check if it is still working
> with glibc in master. gdbserver also got ARC support please also check
> if this now works and we can remove the dependency on !arc.
>
> Hauke
>
>
> This fixes the first build problem:
>
> --- a/sysdeps/arc/atomic-machine.h
> +++ b/sysdeps/arc/atomic-machine.h
> @@ -64,6 +64,10 @@
> __atomic_val_bysize (__arch_compare_and_exchange_val, int, \
>mem, new, old, __ATOMIC_ACQUIRE)
>
> +#ifdef __ARCHS__
> #define atomic_full_barrier() ({ asm volatile ("dmb 3":::"memory"); })
> +#else
> +#define atomic_full_barrier() ({ asm volatile ("sync":::"memory"); })
uClibc-ng uses __asm__ __volatile__("": : :"memory"). No idea if bug or not.
> +#endif
>
> #endif /* _ARC_BITS_ATOMIC_H */
>
>
> ___
> 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: [PATCH 1/3] ramips: add support for the RT6855A SoC
Hi!
On Thu, Dec 24, 2020 at 12:51 AM Rafaël Carré wrote:
>
> Add Linksys WAP300N target
Please separate device support from target addition, and check
your device support against our wiki checklist:
https://openwrt.org/docs/guide-developer/device-support-policies
>
> Signed-off-by: Rafaël Carré
> ---
> target/linux/ramips/Makefile |2 +-
> target/linux/ramips/dts/rt6855.dtsi | 93 +
> .../ramips/dts/rt6855a_linksys_wap300n.dts| 18 +
> target/linux/ramips/image/Makefile|1 +
> target/linux/ramips/image/rt6855a.mk | 15 +
> .../rt6855a/base-files/etc/board.d/01_leds| 12 +
> .../rt6855a/base-files/etc/board.d/02_network | 11 +
> .../base-files/etc/board.d/03_gpio_switches | 11 +
> target/linux/ramips/rt6855a/config-5.4| 2266 +
> .../ramips/rt6855a/profiles/00-default.mk | 17 +
> target/linux/ramips/rt6855a/target.mk | 15 +
> 11 files changed, 2460 insertions(+), 1 deletion(-)
> create mode 100644 target/linux/ramips/dts/rt6855.dtsi
> create mode 100644 target/linux/ramips/dts/rt6855a_linksys_wap300n.dts
> create mode 100644 target/linux/ramips/image/rt6855a.mk
> create mode 100755 target/linux/ramips/rt6855a/base-files/etc/board.d/01_leds
> create mode 100755
> target/linux/ramips/rt6855a/base-files/etc/board.d/02_network
> create mode 100755
> target/linux/ramips/rt6855a/base-files/etc/board.d/03_gpio_switches
> create mode 100644 target/linux/ramips/rt6855a/config-5.4
> create mode 100644 target/linux/ramips/rt6855a/profiles/00-default.mk
> create mode 100644 target/linux/ramips/rt6855a/target.mk
>
> diff --git a/target/linux/ramips/Makefile b/target/linux/ramips/Makefile
> index c3d118b2ab..f03118c1aa 100644
> --- a/target/linux/ramips/Makefile
> +++ b/target/linux/ramips/Makefile
> @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
> ARCH:=mipsel
> BOARD:=ramips
> BOARDNAME:=MediaTek Ralink MIPS
> -SUBTARGETS:=mt7620 mt7621 mt76x8 rt288x rt305x rt3883
> +SUBTARGETS:=mt7620 mt7621 mt76x8 rt288x rt305x rt3883 rt6855a
> FEATURES:=squashfs gpio
>
> KERNEL_PATCHVER:=5.4
> diff --git a/target/linux/ramips/dts/rt6855.dtsi
> b/target/linux/ramips/dts/rt6855.dtsi
> new file mode 100644
> index 00..4ff9460256
> --- /dev/null
> +++ b/target/linux/ramips/dts/rt6855.dtsi
> @@ -0,0 +1,93 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "ralink,rt6855-soc";
> +
> + cpus {
> + cpu@0 {
> + compatible = "mips,mips34Kc";
> + };
> + };
> +
> + cpuintc: cpuintc {
> + #address-cells = <0>;
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + compatible = "mti,cpu-interrupt-controller";
> + };
> +
> + palmbus@1fb0 {
> + compatible = "palmbus";
> + reg = <0x1fb0 0xe>;
> + ranges = <0x0 0x1fb0 0x10>;
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + sysc@0 {
> + compatible = "ralink,rt6855-sysc";
> + reg = <0x0 0x100>;
> + };
> +
> + intc: intc@4 {
> + compatible = "ralink,rt6855-intc";
> + reg = <0x4 0x100>;
> +
> + interrupt-controller;
> + #interrupt-cells = <1>;
> +
> + interrupt-parent = <&cpuintc>;
> + };
> +
> + memc@300 {
> + compatible = "ralink,rt6855-memc",
> "ralink,rt3050-memc";
> + reg = <0x300 0x100>;
> + };
> +
> + watchdog@f0100 {
> + compatible = "ralink,rt6855-wdt";
> + reg = <0xf0100 0x10>;
> + };
> +
> + uart: uart@f {
> + compatible = "ns8250";
> + reg = <0xf 0x30>;
> + interrupts = <0>;
> +
> + clock-frequency = <921600>;
> +
> + reg-io-width = <4>;
> + reg-shift = <2>;
> + no-loopback-test;
> +
> + status = "okay";
> +
> + interrupt-parent = <&intc>;
> + };
> +
> + gdma: gdma@3 {
> + compatible = "ralink,gdma-rt2880";
> + reg = <0x3 0x100>;
> + };
> +
> +ethernet: ethernet@5{
> +compatible = "ralink,rt6855-eth";
This doesn't match your compatible string choice in the ethernet driver.
> +reg = <0x5 0x1>;
> +
> +interrupt-parent = <&intc>;
> +interrupts = <21>;
> +
> +mediatek,switch = <&esw>;
> +
Re: [PATCH 2/3] ramips: add RT6855A support to ethernet driver
Hi!
On Thu, Dec 24, 2020 at 12:52 AM Rafaël Carré wrote:
>
> TODO: document offsets in rt305x_mii_write ?
Please do so if you know what they mean.
> [...]
> diff --git
> a/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3050.c
> b/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3050.c
> index 292f11a170..7f3693e6c1 100644
> --- a/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3050.c
> +++ b/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3050.c
> @@ -85,6 +85,7 @@
> #define RT305X_ESW_PCR0_WT_NWAY_DATA_S 16
> #define RT305X_ESW_PCR0_WT_PHY_CMD BIT(13)
> #define RT305X_ESW_PCR0_CPU_PHY_REG_S 8
> +#define RT305X_ESW_PCR0_WT_DONEBIT(31)
>
> #define RT305X_ESW_PCR1_WT_DONEBIT(0)
>
> @@ -271,8 +272,13 @@ static u32 rt305x_mii_write(struct rt305x_esw *esw, u32
> phy_addr,
> int ret = 0;
>
> while (1) {
> +#ifdef CONFIG_SOC_RT6855A
> + if (!(esw_r32(esw, RT305X_ESW_REG_PCR0) &
> + RT305X_ESW_PCR0_WT_DONE))
> +#else
> if (!(esw_r32(esw, RT305X_ESW_REG_PCR1) &
> RT305X_ESW_PCR1_WT_DONE))
> +#endif
Try using compatible strings to distinguish hardware, instead of
ifdefs like this.
> break;
> if (time_after(jiffies, t_start + RT305X_ESW_PHY_TIMEOUT)) {
> ret = 1;
> @@ -281,15 +287,27 @@ static u32 rt305x_mii_write(struct rt305x_esw *esw, u32
> phy_addr,
> }
>
> write_data &= 0x;
> +#ifdef CONFIG_SOC_RT6855A
> + esw_w32(esw, (write_data ) | (phy_register << 16) | (phy_addr << 24)
> | (1 << 30),
> + RT305X_ESW_REG_PCR0);
> + esw_w32(esw, (write_data ) | (phy_register << 16) | (phy_addr << 24)
> | (3 << 30),
> + RT305X_ESW_REG_PCR0);
> +#else
> esw_w32(esw, (write_data << RT305X_ESW_PCR0_WT_NWAY_DATA_S) |
> (phy_register << RT305X_ESW_PCR0_CPU_PHY_REG_S) |
> (phy_addr) | RT305X_ESW_PCR0_WT_PHY_CMD,
> RT305X_ESW_REG_PCR0);
> +#endif
>
> t_start = jiffies;
> while (1) {
> - if (esw_r32(esw, RT305X_ESW_REG_PCR1) &
> - RT305X_ESW_PCR1_WT_DONE)
> +#ifdef CONFIG_SOC_RT6855A
> + if (!(esw_r32(esw, RT305X_ESW_REG_PCR0) &
> + RT305X_ESW_PCR0_WT_DONE))
> +#else
> + if (!(esw_r32(esw, RT305X_ESW_REG_PCR1) &
> + RT305X_ESW_PCR1_WT_DONE))
> +#endif
same as above.
> break;
>
> if (time_after(jiffies, t_start + RT305X_ESW_PHY_TIMEOUT)) {
> diff --git
> a/target/linux/ramips/files/drivers/net/ethernet/ralink/mtk_eth_soc.h
> b/target/linux/ramips/files/drivers/net/ethernet/ralink/mtk_eth_soc.h
> index 00f1a0e7e6..19f0dacaa5 100644
> --- a/target/linux/ramips/files/drivers/net/ethernet/ralink/mtk_eth_soc.h
> +++ b/target/linux/ramips/files/drivers/net/ethernet/ralink/mtk_eth_soc.h
> @@ -294,6 +294,7 @@ enum fe_work_flag {
> #define FE_PDMA_SIZE_4DWORDS (0 << 4)
> #define FE_PDMA_SIZE_8DWORDS (1 << 4)
> #define FE_PDMA_SIZE_16DWORDS (2 << 4)
> +#define FE_PDMA_SIZE_32DWORDS (3 << 4)
>
> #define FE_US_CYC_CNT_MASK 0xff
> #define FE_US_CYC_CNT_SHIFT0x8
> diff --git
> a/target/linux/ramips/files/drivers/net/ethernet/ralink/soc_rt6855a.c
> b/target/linux/ramips/files/drivers/net/ethernet/ralink/soc_rt6855a.c
> new file mode 100644
> index 00..3e883713eb
> --- /dev/null
> +++ b/target/linux/ramips/files/drivers/net/ethernet/ralink/soc_rt6855a.c
> @@ -0,0 +1,102 @@
> +/* This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Copyright (C) 2009-2015 John Crispin
> + * Copyright (C) 2009-2015 Felix Fietkau
> + * Copyright (C) 2013-2015 Michael Lee
> + */
> +
> +#include
> +
> +#include
> +
> +#include "mtk_eth_soc.h"
> +#include "mdio_rt2880.h"
> +
> +static const u16 rt5350_reg_table[FE_REG_COUNT] = {
> + [FE_REG_PDMA_GLO_CFG] = RT5350_PDMA_GLO_CFG,// OK
> + [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
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 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
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] kernel: add module for tcp-hybla congestion control algorithm
On Wed, 23 Dec 2020 at 20:09, Hauke Mehrtens wrote: > > On 12/23/20 8:36 AM, Yousong Zhou wrote: > > Just the module and no default sysctl conf file is provided > > > > Ref: https://forum.openwrt.org/t/20-xx-tcp-hybla/83076 > > Signed-off-by: Yousong Zhou > > --- > > package/kernel/linux/modules/netsupport.mk | 20 > > 1 file changed, 20 insertions(+) > > > > diff --git a/package/kernel/linux/modules/netsupport.mk > > b/package/kernel/linux/modules/netsupport.mk > > index 0c68b394d1..156892c952 100644 > > --- a/package/kernel/linux/modules/netsupport.mk > > +++ b/package/kernel/linux/modules/netsupport.mk > > @@ -949,6 +949,26 @@ endef > > $(eval $(call KernelPackage,tcp-bbr)) > > > > > > +define KernelPackage/tcp-hybla > > + SUBMENU:=$(NETWORK_SUPPORT_MENU) > > + TITLE:=TCP-Hybla congestion control algorithm > > + KCONFIG:= \ > > + CONFIG_TCP_CONG_ADVANCED=y \ > > This is already set in the generic configuration for most targets: > - > :~/openwrt/openwrt/target/linux$ git grep TCP_CONG_ADVANCED > generic/config-5.4:CONFIG_TCP_CONG_ADVANCED=y > layerscape/armv7/config-5.4:# CONFIG_TCP_CONG_ADVANCED is not set > layerscape/armv8_64b/config-5.4:# CONFIG_TCP_CONG_ADVANCED is not set > zynq/config-5.4:# CONFIG_TCP_CONG_ADVANCED is not set > --- > > I would prefer if we set if for all targets, then it is not needed here > any more. Will do in v2 > > > > + CONFIG_TCP_CONG_HYBLA > > + FILES:=$(LINUX_DIR)/net/ipv4/tcp_hybla.ko > > + AUTOLOAD:=$(call AutoLoad,74,tcp_hybla) > > Is AutoProbe working here? Will test and send with modification also for tcp-bbr in v2. Regards, yousong ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/3] ramips: add RT6855A support to ethernet driver
TODO: document offsets in rt305x_mii_write ?
Signed-off-by: Rafaël Carré
---
.../files/drivers/net/ethernet/ralink/Kconfig | 6 +-
.../drivers/net/ethernet/ralink/Makefile | 1 +
.../drivers/net/ethernet/ralink/esw_rt3050.c | 22 +++-
.../drivers/net/ethernet/ralink/mtk_eth_soc.h | 1 +
.../drivers/net/ethernet/ralink/soc_rt6855a.c | 102 ++
5 files changed, 129 insertions(+), 3 deletions(-)
create mode 100644
target/linux/ramips/files/drivers/net/ethernet/ralink/soc_rt6855a.c
diff --git a/target/linux/ramips/files/drivers/net/ethernet/ralink/Kconfig
b/target/linux/ramips/files/drivers/net/ethernet/ralink/Kconfig
index 26e5e6d73e..ed437d3a9e 100644
--- a/target/linux/ramips/files/drivers/net/ethernet/ralink/Kconfig
+++ b/target/linux/ramips/files/drivers/net/ethernet/ralink/Kconfig
@@ -11,6 +11,10 @@ if NET_RALINK_SOC
choice
prompt "MAC type"
+config NET_RALINK_RT6855A
+ bool "RT6855A"
+ depends on MIPS && SOC_RT6855A
+
config NET_RALINK_RT2880
bool "RT2882"
depends on MIPS && SOC_RT288X
@@ -50,7 +54,7 @@ config NET_RALINK_MDIO_MT7620
config NET_RALINK_ESW_RT3050
def_tristate NET_RALINK_SOC
- depends on NET_RALINK_RT3050
+ depends on NET_RALINK_RT3050 || NET_RALINK_RT6855A
config NET_RALINK_GSW_MT7620
def_tristate NET_RALINK_SOC
diff --git a/target/linux/ramips/files/drivers/net/ethernet/ralink/Makefile
b/target/linux/ramips/files/drivers/net/ethernet/ralink/Makefile
index 79d2dbfef9..3de028ba5b 100644
--- a/target/linux/ramips/files/drivers/net/ethernet/ralink/Makefile
+++ b/target/linux/ramips/files/drivers/net/ethernet/ralink/Makefile
@@ -12,6 +12,7 @@ ralink-eth-$(CONFIG_NET_RALINK_RT2880)+= soc_rt2880.o
ralink-eth-$(CONFIG_NET_RALINK_RT3050) += soc_rt3050.o
ralink-eth-$(CONFIG_NET_RALINK_RT3883) += soc_rt3883.o
ralink-eth-$(CONFIG_NET_RALINK_MT7620) += soc_mt7620.o
+ralink-eth-$(CONFIG_NET_RALINK_RT6855A)+= soc_rt6855a.o
obj-$(CONFIG_NET_RALINK_ESW_RT3050)+= esw_rt3050.o
obj-$(CONFIG_NET_RALINK_GSW_MT7620)+= gsw_mt7620.o mt7530.o
diff --git a/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3050.c
b/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3050.c
index 292f11a170..7f3693e6c1 100644
--- a/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3050.c
+++ b/target/linux/ramips/files/drivers/net/ethernet/ralink/esw_rt3050.c
@@ -85,6 +85,7 @@
#define RT305X_ESW_PCR0_WT_NWAY_DATA_S 16
#define RT305X_ESW_PCR0_WT_PHY_CMD BIT(13)
#define RT305X_ESW_PCR0_CPU_PHY_REG_S 8
+#define RT305X_ESW_PCR0_WT_DONEBIT(31)
#define RT305X_ESW_PCR1_WT_DONEBIT(0)
@@ -271,8 +272,13 @@ static u32 rt305x_mii_write(struct rt305x_esw *esw, u32
phy_addr,
int ret = 0;
while (1) {
+#ifdef CONFIG_SOC_RT6855A
+ if (!(esw_r32(esw, RT305X_ESW_REG_PCR0) &
+ RT305X_ESW_PCR0_WT_DONE))
+#else
if (!(esw_r32(esw, RT305X_ESW_REG_PCR1) &
RT305X_ESW_PCR1_WT_DONE))
+#endif
break;
if (time_after(jiffies, t_start + RT305X_ESW_PHY_TIMEOUT)) {
ret = 1;
@@ -281,15 +287,27 @@ static u32 rt305x_mii_write(struct rt305x_esw *esw, u32
phy_addr,
}
write_data &= 0x;
+#ifdef CONFIG_SOC_RT6855A
+ esw_w32(esw, (write_data ) | (phy_register << 16) | (phy_addr << 24) |
(1 << 30),
+ RT305X_ESW_REG_PCR0);
+ esw_w32(esw, (write_data ) | (phy_register << 16) | (phy_addr << 24) |
(3 << 30),
+ RT305X_ESW_REG_PCR0);
+#else
esw_w32(esw, (write_data << RT305X_ESW_PCR0_WT_NWAY_DATA_S) |
(phy_register << RT305X_ESW_PCR0_CPU_PHY_REG_S) |
(phy_addr) | RT305X_ESW_PCR0_WT_PHY_CMD,
RT305X_ESW_REG_PCR0);
+#endif
t_start = jiffies;
while (1) {
- if (esw_r32(esw, RT305X_ESW_REG_PCR1) &
- RT305X_ESW_PCR1_WT_DONE)
+#ifdef CONFIG_SOC_RT6855A
+ if (!(esw_r32(esw, RT305X_ESW_REG_PCR0) &
+ RT305X_ESW_PCR0_WT_DONE))
+#else
+ if (!(esw_r32(esw, RT305X_ESW_REG_PCR1) &
+ RT305X_ESW_PCR1_WT_DONE))
+#endif
break;
if (time_after(jiffies, t_start + RT305X_ESW_PHY_TIMEOUT)) {
diff --git
a/target/linux/ramips/files/drivers/net/ethernet/ralink/mtk_eth_soc.h
b/target/linux/ramips/files/drivers/net/ethernet/ralink/mtk_eth_soc.h
index 00f1a0e7e6..19f0dacaa5 100644
--- a/target/linux/ramips/files/drivers/net/ethernet/ralink/mtk_eth_soc.h
+++ b/target/linux/ramips/files/drivers/net/ethernet/ralink/mtk_eth_soc.h
@@ -294,6 +294,7 @@ enum fe_work_flag {
#define FE_PDMA_SIZE_4DWORDS (0 << 4)
#define FE_PDMA_SIZE_8DWORDS (1 << 4)
#define FE_PDMA_SIZE_16DWORDS (2 << 4)
+#define FE_PDMA_SIZE_32DWORDS (3 << 4)
#define
[PATCH 3/3] ramips: add RT6855A SoC Linux support patches
TODO: the spi-mt7621 patches will break support for other targets
Signed-off-by: Rafaël Carré
---
...-ralink-adds-support-for-RT6855A-SoC.patch | 688 ++
.../304-HACK-spi-mt7621-rt6855a-fix.patch | 35 +
...HACK-spi-mt7621.c-hardcode-frequency.patch | 69 +
.../306-RT6855A-add-watchdog.patch| 236 +++
...855A-Use-Linksys-provided-PCI-driver.patch | 1884 +
5 files changed, 2912 insertions(+)
create mode 100644
target/linux/ramips/patches-5.4/303-MIPS-ralink-adds-support-for-RT6855A-SoC.patch
create mode 100644
target/linux/ramips/patches-5.4/304-HACK-spi-mt7621-rt6855a-fix.patch
create mode 100644
target/linux/ramips/patches-5.4/305-HACK-spi-mt7621.c-hardcode-frequency.patch
create mode 100644
target/linux/ramips/patches-5.4/306-RT6855A-add-watchdog.patch
create mode 100644
target/linux/ramips/patches-5.4/307-HACK-RT6855A-Use-Linksys-provided-PCI-driver.patch
diff --git
a/target/linux/ramips/patches-5.4/303-MIPS-ralink-adds-support-for-RT6855A-SoC.patch
b/target/linux/ramips/patches-5.4/303-MIPS-ralink-adds-support-for-RT6855A-SoC.patch
new file mode 100644
index 00..dc56e6c209
--- /dev/null
+++
b/target/linux/ramips/patches-5.4/303-MIPS-ralink-adds-support-for-RT6855A-SoC.patch
@@ -0,0 +1,688 @@
+From 7d3e6a27ac47b16d7b0b05d4ce186c48cc054625 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Rafa=C3=ABl=20Carr=C3=A9?=
+Date: Wed, 23 Dec 2020 14:16:37 +0100
+Subject: [PATCH 1/5] MIPS: ralink: adds support for RT6855A SoC
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+TODO:
+- clean up dts file
+some things are OpenWrt-only (mtd mac / eeprom)
+some things might be removed (gdma?)
+spi / pci should be moved to other commits
+ethernet should go in OpenWrt dts
+
+All code is my own or based on existing in-tree files.
+
+Signed-off-by: Rafaël Carré
+---
+ arch/mips/boot/dts/ralink/Makefile| 1 +
+ arch/mips/boot/dts/ralink/rt6855.dtsi | 207 ++
+ arch/mips/boot/dts/ralink/wap300n.dts | 22 ++
+ .../include/asm/mach-ralink/ralink_regs.h | 1 +
+ arch/mips/ralink/Kconfig | 13 +-
+ arch/mips/ralink/Makefile | 6 +-
+ arch/mips/ralink/Platform | 5 +
+ arch/mips/ralink/early_printk.c | 5 +-
+ arch/mips/ralink/irq-rt6855a.c| 172 +++
+ arch/mips/ralink/reset.c | 23 ++
+ arch/mips/ralink/rt6855a.c| 57 +
+ 11 files changed, 509 insertions(+), 3 deletions(-)
+ create mode 100644 arch/mips/boot/dts/ralink/rt6855.dtsi
+ create mode 100644 arch/mips/boot/dts/ralink/wap300n.dts
+ create mode 100644 arch/mips/ralink/irq-rt6855a.c
+ create mode 100644 arch/mips/ralink/rt6855a.c
+
+diff --git a/arch/mips/boot/dts/ralink/Makefile
b/arch/mips/boot/dts/ralink/Makefile
+index 6c26dfa0a903..08c612190936 100644
+--- a/arch/mips/boot/dts/ralink/Makefile
b/arch/mips/boot/dts/ralink/Makefile
+@@ -3,6 +3,7 @@ dtb-$(CONFIG_DTB_RT2880_EVAL) += rt2880_eval.dtb
+ dtb-$(CONFIG_DTB_RT305X_EVAL) += rt3052_eval.dtb
+ dtb-$(CONFIG_DTB_RT3883_EVAL) += rt3883_eval.dtb
+ dtb-$(CONFIG_DTB_MT7620A_EVAL)+= mt7620a_eval.dtb
++dtb-$(CONFIG_DTB_WAP300N) += wap300n.dtb
+ dtb-$(CONFIG_DTB_OMEGA2P) += omega2p.dtb
+ dtb-$(CONFIG_DTB_VOCORE2) += vocore2.dtb
+
+diff --git a/arch/mips/boot/dts/ralink/rt6855.dtsi
b/arch/mips/boot/dts/ralink/rt6855.dtsi
+new file mode 100644
+index ..8427696ff7bf
+--- /dev/null
b/arch/mips/boot/dts/ralink/rt6855.dtsi
+@@ -0,0 +1,207 @@
++// SPDX-License-Identifier: GPL-2.0
++/ {
++ #address-cells = <1>;
++ #size-cells = <1>;
++ compatible = "ralink,rt6855a-soc";
++
++ cpus {
++ cpu@0 {
++ compatible = "mips,mips34Kc";
++ };
++ };
++
++ cpuintc: cpuintc {
++ #address-cells = <0>;
++ #interrupt-cells = <1>;
++ interrupt-controller;
++ compatible = "mti,cpu-interrupt-controller";
++ };
++
++ palmbus@1fb0 {
++ compatible = "palmbus";
++ reg = <0x1fb0 0xe>;
++ ranges = <0x0 0x1fb0 0x10>;
++
++ #address-cells = <1>;
++ #size-cells = <1>;
++
++ sysc@0 {
++ compatible = "ralink,rt6855a-sysc";
++ reg = <0x0 0x100>;
++ };
++
++ intc: intc@4 {
++ compatible = "ralink,rt6855a-intc";
++ reg = <0x4 0x100>;
++
++ interrupt-controller;
++ #interrupt-cells = <1>;
++
++ interrupt-parent = <&cpuintc>;
++ };
++
++ memc@300 {
++ compatible = "ralink,rt6855a-memc",
"ralink,rt3050-memc";
++ reg = <0x300 0x
[PATCH 1/3] ramips: add support for the RT6855A SoC
Add Linksys WAP300N target
Signed-off-by: Rafaël Carré
---
target/linux/ramips/Makefile |2 +-
target/linux/ramips/dts/rt6855.dtsi | 93 +
.../ramips/dts/rt6855a_linksys_wap300n.dts| 18 +
target/linux/ramips/image/Makefile|1 +
target/linux/ramips/image/rt6855a.mk | 15 +
.../rt6855a/base-files/etc/board.d/01_leds| 12 +
.../rt6855a/base-files/etc/board.d/02_network | 11 +
.../base-files/etc/board.d/03_gpio_switches | 11 +
target/linux/ramips/rt6855a/config-5.4| 2266 +
.../ramips/rt6855a/profiles/00-default.mk | 17 +
target/linux/ramips/rt6855a/target.mk | 15 +
11 files changed, 2460 insertions(+), 1 deletion(-)
create mode 100644 target/linux/ramips/dts/rt6855.dtsi
create mode 100644 target/linux/ramips/dts/rt6855a_linksys_wap300n.dts
create mode 100644 target/linux/ramips/image/rt6855a.mk
create mode 100755 target/linux/ramips/rt6855a/base-files/etc/board.d/01_leds
create mode 100755
target/linux/ramips/rt6855a/base-files/etc/board.d/02_network
create mode 100755
target/linux/ramips/rt6855a/base-files/etc/board.d/03_gpio_switches
create mode 100644 target/linux/ramips/rt6855a/config-5.4
create mode 100644 target/linux/ramips/rt6855a/profiles/00-default.mk
create mode 100644 target/linux/ramips/rt6855a/target.mk
diff --git a/target/linux/ramips/Makefile b/target/linux/ramips/Makefile
index c3d118b2ab..f03118c1aa 100644
--- a/target/linux/ramips/Makefile
+++ b/target/linux/ramips/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
ARCH:=mipsel
BOARD:=ramips
BOARDNAME:=MediaTek Ralink MIPS
-SUBTARGETS:=mt7620 mt7621 mt76x8 rt288x rt305x rt3883
+SUBTARGETS:=mt7620 mt7621 mt76x8 rt288x rt305x rt3883 rt6855a
FEATURES:=squashfs gpio
KERNEL_PATCHVER:=5.4
diff --git a/target/linux/ramips/dts/rt6855.dtsi
b/target/linux/ramips/dts/rt6855.dtsi
new file mode 100644
index 00..4ff9460256
--- /dev/null
+++ b/target/linux/ramips/dts/rt6855.dtsi
@@ -0,0 +1,93 @@
+// SPDX-License-Identifier: GPL-2.0
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "ralink,rt6855-soc";
+
+ cpus {
+ cpu@0 {
+ compatible = "mips,mips34Kc";
+ };
+ };
+
+ cpuintc: cpuintc {
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ compatible = "mti,cpu-interrupt-controller";
+ };
+
+ palmbus@1fb0 {
+ compatible = "palmbus";
+ reg = <0x1fb0 0xe>;
+ ranges = <0x0 0x1fb0 0x10>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ sysc@0 {
+ compatible = "ralink,rt6855-sysc";
+ reg = <0x0 0x100>;
+ };
+
+ intc: intc@4 {
+ compatible = "ralink,rt6855-intc";
+ reg = <0x4 0x100>;
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ interrupt-parent = <&cpuintc>;
+ };
+
+ memc@300 {
+ compatible = "ralink,rt6855-memc", "ralink,rt3050-memc";
+ reg = <0x300 0x100>;
+ };
+
+ watchdog@f0100 {
+ compatible = "ralink,rt6855-wdt";
+ reg = <0xf0100 0x10>;
+ };
+
+ uart: uart@f {
+ compatible = "ns8250";
+ reg = <0xf 0x30>;
+ interrupts = <0>;
+
+ clock-frequency = <921600>;
+
+ reg-io-width = <4>;
+ reg-shift = <2>;
+ no-loopback-test;
+
+ status = "okay";
+
+ interrupt-parent = <&intc>;
+ };
+
+ gdma: gdma@3 {
+ compatible = "ralink,gdma-rt2880";
+ reg = <0x3 0x100>;
+ };
+
+ethernet: ethernet@5{
+compatible = "ralink,rt6855-eth";
+reg = <0x5 0x1>;
+
+interrupt-parent = <&intc>;
+interrupts = <21>;
+
+mediatek,switch = <&esw>;
+};
+
+esw: esw@6 {
+compatible = "ralink,rt3050-esw";
+reg = <0x6 0x8000>;
+
+interrupt-parent = <&intc>;
+interrupts = <15>;
+};
+
+ };
+};
diff --git a/target/linux/ramips/dts/rt6855a_linksys_wap300n.dts
b/target/linux/ramips/dts/rt6855a_linksys_wap300n.dts
new file mode 100644
index 00..d923946c4a
--- /dev/null
+++ b/target/linux/ramips/dts/rt6855a_linksys_wap300n.dts
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+/include/ "rt6855.dtsi"
+
+/ {
+
Re: [PATCH] kernel: add module for tcp-hybla congestion control algorithm
On 12/23/20 2:56 PM, Henrique de Moraes Holschuh wrote: On 23/12/2020 09:08, Hauke Mehrtens wrote: On 12/23/20 8:36 AM, Yousong Zhou wrote: Just the module and no default sysctl conf file is provided Ref: https://forum.openwrt.org/t/20-xx-tcp-hybla/83076 Signed-off-by: Yousong Zhou --- package/kernel/linux/modules/netsupport.mk | 20 1 file changed, 20 insertions(+) diff --git a/package/kernel/linux/modules/netsupport.mk b/package/kernel/linux/modules/netsupport.mk index 0c68b394d1..156892c952 100644 --- a/package/kernel/linux/modules/netsupport.mk +++ b/package/kernel/linux/modules/netsupport.mk @@ -949,6 +949,26 @@ endef $(eval $(call KernelPackage,tcp-bbr)) +define KernelPackage/tcp-hybla + SUBMENU:=$(NETWORK_SUPPORT_MENU) + TITLE:=TCP-Hybla congestion control algorithm + KCONFIG:= \ + CONFIG_TCP_CONG_ADVANCED=y \ This is already set in the generic configuration for most targets: - :~/openwrt/openwrt/target/linux$ git grep TCP_CONG_ADVANCED generic/config-5.4:CONFIG_TCP_CONG_ADVANCED=y layerscape/armv7/config-5.4:# CONFIG_TCP_CONG_ADVANCED is not set layerscape/armv8_64b/config-5.4:# CONFIG_TCP_CONG_ADVANCED is not set zynq/config-5.4:# CONFIG_TCP_CONG_ADVANCED is not set --- I would prefer if we set if for all targets, then it is not needed here any more. Is the size cost worth it? What would it be? As far as I understand this only allows to configure the TCP congestion control algorithm, but does not add any extra code. It is not like Hybla in OpenWRT is going to be helpful at all for most uses for most users: it can only affect openwrt **when it is the TCP endpoint**, on non-tcp-proxied-by-the-CPE high-rtt links, and only when openwrt is *serving* the high-volume content. If it is added as a module, like it is done here it is optional and the user has to selected it to integrate it. I've read the linked page and it doesn't make sense *outside of the content servers* of that satellite ISP. It can only affect anything if you are the TCP ENDPOINT serving contents, middle-boxes have no say in it unless they're L4/L7 *active* proxies -- i.e., they'd need to become the relevant TCP endpoint. To me, Hybla seems like something you'd want behind a KConfig option (default N) for specialized uses, only. Not something to be enabled by default on all targets. > NOTE: Hybla on *servers* is a different deal, but since you cannot select it by TCP negotiation, it is still only ever going to be useful on the satellite access provider *content proxies and servers*, since nobody is going to enable it on general-purpose servers that cather for both high and low RTT clients. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
arc700 + glibc fails
Hi,
ARC was switched from uClibc to glibc here:
https://git.openwrt.org/95f1002acab574c24ad78f4453f091bf5a6731c7
uClibc support was removed from OpenWrt in the next commit.
It looks like arc700 is not supported by glibc 2.32, only ARC HS38 is
supported.
On the arc770 target I am getting this compiler errors in the glibc:
-
msort.c: Assembler messages:
msort.c:201: Error: opcode 'dmb' not supported for target arc700
-
http://buildbot.openwrt.org/master/images/builders/arc770%2Fgeneric/builds/749
After this one is fixed I get this one:
-
../sysdeps/unix/sysv/linux/arc/syscall.S: Assembler messages:
../sysdeps/unix/sysv/linux/arc/syscall.S:27: Error: register must be
either r0-r3 or r12-r15 for instruction 'mov_s'
../sysdeps/unix/sysv/linux/arc/syscall.S:28: Error: register must be
either r0-r3 or r12-r15 for instruction 'mov_s'
-
Does anyone plan to fix glibc with arc700 or should we just remove the
arc770 target, the arhs38 target is compiling?
I think the archs38 target was not runtime tested with glibc, could
someone with access to the hardware please check if it is still working
with glibc in master. gdbserver also got ARC support please also check
if this now works and we can remove the dependency on !arc.
Hauke
This fixes the first build problem:
--- a/sysdeps/arc/atomic-machine.h
+++ b/sysdeps/arc/atomic-machine.h
@@ -64,6 +64,10 @@
__atomic_val_bysize (__arch_compare_and_exchange_val, int, \
mem, new, old, __ATOMIC_ACQUIRE)
+#ifdef __ARCHS__
#define atomic_full_barrier() ({ asm volatile ("dmb 3":::"memory"); })
+#else
+#define atomic_full_barrier() ({ asm volatile ("sync":::"memory"); })
+#endif
#endif /* _ARC_BITS_ATOMIC_H */
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: IEEE802.11w enabled by default
it could be kernel driver bug. try booting other distro, like kali or ubuntu releases from within last few years - e.g. 18.04,19.04,20.04 to see if it ever worked better. On 23/12/2020, Henrique de Moraes Holschuh wrote: > On 22/12/2020 11:31, Tom Psyborg wrote: >> In that case, check router side, client can support it most likely. >> Try different release or factory firmware > > > Well, according to this page: > > https://kevinlocke.name/bits/2019/12/28/checking-802.11w-support/ > > the *client* hardware supports it (CMAC is present in the "iw phy phy0 > info" output), but there is no MFP_OPTIONAL in the output of "iw phy" in > the client (iw version 5.0.1). In fact, there is no MFP anywhere in the > iw output for the client. > > From what I understood, that means the Debian 10 kernel driver+firmware > combination doesn't support MFP for QCA6174, although the hardware does. > > So, we have a client that has hardware support for MFP, but either its > firmware or the kernel driver apparently doesn't. Whether I can try to > address that in the Debian-stable side or not is something I will look > into later, after we have the full picture. > > > Now, for the router, in this case a Archer C6v2(US) which has a newer > chipset than the Archer C7v4(BR) where I also get the same problem: > > > ath10k 4.19 driver, optimized for CT firmware, probing pci device: 0x56. > ath10k_pci :00:00.0: pci irq legacy oper_irq_mode 1 irq_mode 0 > reset_mode 0 > firmware ath10k!QCA9888!hw2.0!firmware-6.bin: firmware_loading_store: > map pages failed > ath10k_pci :00:00.0: qca9888 hw2.0 target 0x0100 chip_id > 0x sub : > ath10k_pci :00:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 > testmode 0 > ath10k_pci :00:00.0: firmware ver 10.4b-ct-9888-fW-13-8c5b2baa2 api > 5 features > mfp,peer-flow-ctrl,txstatus-noack,wmi-10.x-CT,ratemask-CT,regdump-CT,txrate-CT,flush-all-CT,pingpong-CT,ch-regs-CT,nop-CT,set-special-CT,tx-rc-CT,cust-stats-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT,wmi-bcn-rc-CT > > crc32 cbf49903 > ath10k_pci :00:00.0: board_file api 2 bmi_id 0:24 crc32 f228337a > ath10k_pci :00:00.0: 10.4 wmi init: vdevs: 16 peers: 48 tid: 96 > ath10k_pci :00:00.0: msdu-desc: 2500 skid: 32 > ath10k_pci :00:00.0: wmi print 'P 48/48 V 16 K 144 PH 176 T 186 > msdu-desc: 2500 sw-crypt: 0 ct-sta: 0' > ath10k_pci :00:00.0: wmi print 'free: 114572 iram: 12804 sram: 29508' > ath10k_pci :00:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal pre-cal-file > max-sta 32 raw 0 hwcrypto 1 > > after that, it chances region to "BR", and complains about something > from the client: > ath: regdomain 0x804c dynamically updated by user > ath10k_pci :00:00.0: 10.4 wmi init: vdevs: 16 peers: 48 tid: 96 > ath10k_pci :00:00.0: msdu-desc: 2500 skid: 32 > ath10k_pci :00:00.0: wmi print 'P 48/48 V 16 K 144 PH 176 T 186 > msdu-desc: 2500 sw-crypt: 0 ct-sta: 0' > ath10k_pci :00:00.0: wmi print 'free: 114572 iram: 12804 sram: 29508' > ath10k_pci :00:00.0: Firmware lacks feature flag indicating a retry > limit of > 2 is OK, requested limit: 4 > ath10k_pci :00:00.0: mac-vif-chan had error in > htt_rx_h_vdev_channel, peer-id: 0 vdev-id: 0 peer-addr: xxx. > > However, "iw" in my OpenWrt build seems not to be iw-full, since it > doesn't list cyphers. debugfs does show MFP_CAPABLE. > > Should the lack of iw-full impact in the operation of ieee802.11w on the > openwrt side? > > I can do further tests and provide more information if requested. I > could try a special build to drop the -ct firmware and drivers, and > switch to vendor ath firmware and drivers, though, but if there are > other tests that can be done beforehand, it would be best. > > >> On 22/12/2020, Henrique de Moraes Holschuh wrote: >>> On 21/12/2020 17:13, Tom Psyborg wrote: In case your client doesn't support mfp, you should configure the setting on router to optional instead of required so non-mfp client can fallback to basic connection type. >>> >>> I took my time to answer to test it again just in case, but as soon as I >>> set it to "optional" from "disabled", the slowdown happens. For the >>> record, the client goes from 200Mbit/s effective transfer rate (not >>> signal rate) to about 65Mbit/s effective transfer rate. >>> >>> So, at least here, setting ieee 802.11w to "optional" does not avoid the >>> performance loss. >>> On 21/12/2020, Henrique de Moraes Holschuh wrote: > On 21/12/2020 17:01, Tom Psyborg wrote: >> Your firmware does not advertise mfp support, first check if your >> client device can actually support 802.11w > > Does it mean that we should expect the large performance loss for any > clients that don't have mfp support on any routers that have 802.11w > enabled? > > That sounds extremely sub-optimal, to use very nice words... so > hopefully there is more to the scenario? > > >> On 21/12/2020, Henrique de Moraes Holschuh
Re: IEEE802.11w enabled by default
On 22/12/2020 11:31, Tom Psyborg wrote: In that case, check router side, client can support it most likely. Try different release or factory firmware Well, according to this page: https://kevinlocke.name/bits/2019/12/28/checking-802.11w-support/ the *client* hardware supports it (CMAC is present in the "iw phy phy0 info" output), but there is no MFP_OPTIONAL in the output of "iw phy" in the client (iw version 5.0.1). In fact, there is no MFP anywhere in the iw output for the client. From what I understood, that means the Debian 10 kernel driver+firmware combination doesn't support MFP for QCA6174, although the hardware does. So, we have a client that has hardware support for MFP, but either its firmware or the kernel driver apparently doesn't. Whether I can try to address that in the Debian-stable side or not is something I will look into later, after we have the full picture. Now, for the router, in this case a Archer C6v2(US) which has a newer chipset than the Archer C7v4(BR) where I also get the same problem: ath10k 4.19 driver, optimized for CT firmware, probing pci device: 0x56. ath10k_pci :00:00.0: pci irq legacy oper_irq_mode 1 irq_mode 0 reset_mode 0 firmware ath10k!QCA9888!hw2.0!firmware-6.bin: firmware_loading_store: map pages failed ath10k_pci :00:00.0: qca9888 hw2.0 target 0x0100 chip_id 0x sub : ath10k_pci :00:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 0 ath10k_pci :00:00.0: firmware ver 10.4b-ct-9888-fW-13-8c5b2baa2 api 5 features mfp,peer-flow-ctrl,txstatus-noack,wmi-10.x-CT,ratemask-CT,regdump-CT,txrate-CT,flush-all-CT,pingpong-CT,ch-regs-CT,nop-CT,set-special-CT,tx-rc-CT,cust-stats-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT,wmi-bcn-rc-CT crc32 cbf49903 ath10k_pci :00:00.0: board_file api 2 bmi_id 0:24 crc32 f228337a ath10k_pci :00:00.0: 10.4 wmi init: vdevs: 16 peers: 48 tid: 96 ath10k_pci :00:00.0: msdu-desc: 2500 skid: 32 ath10k_pci :00:00.0: wmi print 'P 48/48 V 16 K 144 PH 176 T 186 msdu-desc: 2500 sw-crypt: 0 ct-sta: 0' ath10k_pci :00:00.0: wmi print 'free: 114572 iram: 12804 sram: 29508' ath10k_pci :00:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal pre-cal-file max-sta 32 raw 0 hwcrypto 1 after that, it chances region to "BR", and complains about something from the client: ath: regdomain 0x804c dynamically updated by user ath10k_pci :00:00.0: 10.4 wmi init: vdevs: 16 peers: 48 tid: 96 ath10k_pci :00:00.0: msdu-desc: 2500 skid: 32 ath10k_pci :00:00.0: wmi print 'P 48/48 V 16 K 144 PH 176 T 186 msdu-desc: 2500 sw-crypt: 0 ct-sta: 0' ath10k_pci :00:00.0: wmi print 'free: 114572 iram: 12804 sram: 29508' ath10k_pci :00:00.0: Firmware lacks feature flag indicating a retry limit of > 2 is OK, requested limit: 4 ath10k_pci :00:00.0: mac-vif-chan had error in htt_rx_h_vdev_channel, peer-id: 0 vdev-id: 0 peer-addr: xxx. However, "iw" in my OpenWrt build seems not to be iw-full, since it doesn't list cyphers. debugfs does show MFP_CAPABLE. Should the lack of iw-full impact in the operation of ieee802.11w on the openwrt side? I can do further tests and provide more information if requested. I could try a special build to drop the -ct firmware and drivers, and switch to vendor ath firmware and drivers, though, but if there are other tests that can be done beforehand, it would be best. On 22/12/2020, Henrique de Moraes Holschuh wrote: On 21/12/2020 17:13, Tom Psyborg wrote: In case your client doesn't support mfp, you should configure the setting on router to optional instead of required so non-mfp client can fallback to basic connection type. I took my time to answer to test it again just in case, but as soon as I set it to "optional" from "disabled", the slowdown happens. For the record, the client goes from 200Mbit/s effective transfer rate (not signal rate) to about 65Mbit/s effective transfer rate. So, at least here, setting ieee 802.11w to "optional" does not avoid the performance loss. On 21/12/2020, Henrique de Moraes Holschuh wrote: On 21/12/2020 17:01, Tom Psyborg wrote: Your firmware does not advertise mfp support, first check if your client device can actually support 802.11w Does it mean that we should expect the large performance loss for any clients that don't have mfp support on any routers that have 802.11w enabled? That sounds extremely sub-optimal, to use very nice words... so hopefully there is more to the scenario? On 21/12/2020, Henrique de Moraes Holschuh wrote: On 20/12/2020 06:42, Petr Štetiar wrote: I would like to let you know, that there was virtual meeting week ago and you can find the meeting minutes on the wiki[1]. 1. https://openwrt.org/meetings/20201210 FYI, about IEEE802.11w enabled by default: This is a very limited experience, but here it *tanks* client performance here drastically. The wireless routers are TP-Link Archer C6v2(US) and TP-Link Archer C7v4 (BR), running ope
Re: [PATCH] kernel: add module for tcp-hybla congestion control algorithm
On 23/12/2020 09:08, Hauke Mehrtens wrote: On 12/23/20 8:36 AM, Yousong Zhou wrote: Just the module and no default sysctl conf file is provided Ref: https://forum.openwrt.org/t/20-xx-tcp-hybla/83076 Signed-off-by: Yousong Zhou --- package/kernel/linux/modules/netsupport.mk | 20 1 file changed, 20 insertions(+) diff --git a/package/kernel/linux/modules/netsupport.mk b/package/kernel/linux/modules/netsupport.mk index 0c68b394d1..156892c952 100644 --- a/package/kernel/linux/modules/netsupport.mk +++ b/package/kernel/linux/modules/netsupport.mk @@ -949,6 +949,26 @@ endef $(eval $(call KernelPackage,tcp-bbr)) +define KernelPackage/tcp-hybla + SUBMENU:=$(NETWORK_SUPPORT_MENU) + TITLE:=TCP-Hybla congestion control algorithm + KCONFIG:= \ + CONFIG_TCP_CONG_ADVANCED=y \ This is already set in the generic configuration for most targets: - :~/openwrt/openwrt/target/linux$ git grep TCP_CONG_ADVANCED generic/config-5.4:CONFIG_TCP_CONG_ADVANCED=y layerscape/armv7/config-5.4:# CONFIG_TCP_CONG_ADVANCED is not set layerscape/armv8_64b/config-5.4:# CONFIG_TCP_CONG_ADVANCED is not set zynq/config-5.4:# CONFIG_TCP_CONG_ADVANCED is not set --- I would prefer if we set if for all targets, then it is not needed here any more. Is the size cost worth it? What would it be? It is not like Hybla in OpenWRT is going to be helpful at all for most uses for most users: it can only affect openwrt **when it is the TCP endpoint**, on non-tcp-proxied-by-the-CPE high-rtt links, and only when openwrt is *serving* the high-volume content. I've read the linked page and it doesn't make sense *outside of the content servers* of that satellite ISP. It can only affect anything if you are the TCP ENDPOINT serving contents, middle-boxes have no say in it unless they're L4/L7 *active* proxies -- i.e., they'd need to become the relevant TCP endpoint. To me, Hybla seems like something you'd want behind a KConfig option (default N) for specialized uses, only. Not something to be enabled by default on all targets. NOTE: Hybla on *servers* is a different deal, but since you cannot select it by TCP negotiation, it is still only ever going to be useful on the satellite access provider *content proxies and servers*, since nobody is going to enable it on general-purpose servers that cather for both high and low RTT clients. -- Henrique de Moraes Holschuh Analista de Projetos Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações (Ceptro.br) +55 11 5509-3537 R.:4023 INOC 22548*625 www.nic.br ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/2] kernel/hack-5.4: make UDP tunneling user-selectable
UDP tunneling support isn't user-selectable, but it's required by WireGuard which is, for the time being, an out-of-tree module. We currently work around this issue by selecting an unrelated module which depends on UDP tunnelling (VXLAN). This is inconvenient, as it implies this unrelated module needs to be built-in when doing a monolithic build. Fix this inconvenience by making UDP tunneling user-selectable in the kernel configuration. Signed-off-by: Rui Salvaterra --- .../generic/hack-5.4/249-udp-tunnel-selection.patch | 11 +++ 1 file changed, 11 insertions(+) create mode 100644 target/linux/generic/hack-5.4/249-udp-tunnel-selection.patch diff --git a/target/linux/generic/hack-5.4/249-udp-tunnel-selection.patch b/target/linux/generic/hack-5.4/249-udp-tunnel-selection.patch new file mode 100644 index 00..2c74298dfe --- /dev/null +++ b/target/linux/generic/hack-5.4/249-udp-tunnel-selection.patch @@ -0,0 +1,11 @@ +--- a/net/ipv4/Kconfig b/net/ipv4/Kconfig +@@ -315,7 +315,7 @@ config NET_IPVTI + on top. + + config NET_UDP_TUNNEL +- tristate ++ tristate "IP: UDP tunneling support" + select NET_IP_TUNNEL + default n + -- 2.30.0.rc1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 0/2] kernel/udptunnel: clean up the dependency awkwardness
This trivial series makes the kernel UDP tunnel a visible selection and drops
the VXLAN dependency from the udptunnel{4,6} packages, reducing the size of a
monolithic (no modules) by about 15 kiB.
Rui Salvaterra (2):
kernel/hack-5.4: make UDP tunneling user-selectable
kernel/modules: remove fake users from udptunnel{4,6} modules
package/kernel/linux/modules/netsupport.mk| 8 ++--
.../generic/hack-5.4/249-udp-tunnel-selection.patch | 11 +++
2 files changed, 13 insertions(+), 6 deletions(-)
create mode 100644 target/linux/generic/hack-5.4/249-udp-tunnel-selection.patch
--
2.30.0.rc1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/2] kernel/modules: remove fake users from udptunnel{4,6}
Since we're now able to select CONFIG_NET_UDP_TUNNEL at will, drop the fake dependencies. This is a partial revert of commit d7e040f8bccec06b64c82963be6435101423dbf1 "kernel: add fake users for udptunnel and iptunnel modules". Signed-off-by: Rui Salvaterra --- package/kernel/linux/modules/netsupport.mk | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/package/kernel/linux/modules/netsupport.mk b/package/kernel/linux/modules/netsupport.mk index 0c68b394d1..7b8605175e 100644 --- a/package/kernel/linux/modules/netsupport.mk +++ b/package/kernel/linux/modules/netsupport.mk @@ -60,9 +60,7 @@ $(eval $(call KernelPackage,bonding)) define KernelPackage/udptunnel4 SUBMENU:=$(NETWORK_SUPPORT_MENU) TITLE:=IPv4 UDP tunneling support - KCONFIG:= \ - CONFIG_NET_UDP_TUNNEL \ - CONFIG_VXLAN=m + KCONFIG:=CONFIG_NET_UDP_TUNNEL HIDDEN:=1 FILES:=$(LINUX_DIR)/net/ipv4/udp_tunnel.ko AUTOLOAD:=$(call AutoLoad,32,udp_tunnel) @@ -75,9 +73,7 @@ define KernelPackage/udptunnel6 SUBMENU:=$(NETWORK_SUPPORT_MENU) TITLE:=IPv6 UDP tunneling support DEPENDS:=@IPV6 - KCONFIG:= \ - CONFIG_NET_UDP_TUNNEL \ - CONFIG_VXLAN=m + KCONFIG:=CONFIG_NET_UDP_TUNNEL HIDDEN:=1 FILES:=$(LINUX_DIR)/net/ipv6/ip6_udp_tunnel.ko AUTOLOAD:=$(call AutoLoad,32,ip6_udp_tunnel) -- 2.30.0.rc1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] kernel: add module for tcp-hybla congestion control algorithm
On 12/23/20 8:36 AM, Yousong Zhou wrote: Just the module and no default sysctl conf file is provided Ref: https://forum.openwrt.org/t/20-xx-tcp-hybla/83076 Signed-off-by: Yousong Zhou --- package/kernel/linux/modules/netsupport.mk | 20 1 file changed, 20 insertions(+) diff --git a/package/kernel/linux/modules/netsupport.mk b/package/kernel/linux/modules/netsupport.mk index 0c68b394d1..156892c952 100644 --- a/package/kernel/linux/modules/netsupport.mk +++ b/package/kernel/linux/modules/netsupport.mk @@ -949,6 +949,26 @@ endef $(eval $(call KernelPackage,tcp-bbr)) +define KernelPackage/tcp-hybla + SUBMENU:=$(NETWORK_SUPPORT_MENU) + TITLE:=TCP-Hybla congestion control algorithm + KCONFIG:= \ + CONFIG_TCP_CONG_ADVANCED=y \ This is already set in the generic configuration for most targets: - :~/openwrt/openwrt/target/linux$ git grep TCP_CONG_ADVANCED generic/config-5.4:CONFIG_TCP_CONG_ADVANCED=y layerscape/armv7/config-5.4:# CONFIG_TCP_CONG_ADVANCED is not set layerscape/armv8_64b/config-5.4:# CONFIG_TCP_CONG_ADVANCED is not set zynq/config-5.4:# CONFIG_TCP_CONG_ADVANCED is not set --- I would prefer if we set if for all targets, then it is not needed here any more. + CONFIG_TCP_CONG_HYBLA + FILES:=$(LINUX_DIR)/net/ipv4/tcp_hybla.ko + AUTOLOAD:=$(call AutoLoad,74,tcp_hybla) Is AutoProbe working here? +endef + +define KernelPackage/tcp-hybla/description + TCP-Hybla is a sender-side only change that eliminates penalization of + long-RTT, large-bandwidth connections, like when satellite legs are + involved, especially when sharing a common bottleneck with normal + terrestrial connections. +endef + +$(eval $(call KernelPackage,tcp-hybla)) + + define KernelPackage/ax25 SUBMENU:=$(NETWORK_SUPPORT_MENU) TITLE:=AX25 support ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCHv3] ccache: update to 4.1
On Wed, Dec 23, 2020 at 12:28 AM Felix Fietkau wrote: > > > On 2020-12-23 09:14, Rosen Penev wrote: > > On Tue, Dec 22, 2020 at 11:53 PM Hannu Nyman wrote: > >> > >> Rosen Penev kirjoitti 23.12.2020 klo 8.33: > >> > Upstream switched to building with CMake. Adjust accordingly. > >> > > >> > Reapplied patch as upstream changed the file format. > >> > > >> > Added HOST_BUILD_PARALLEL for faster compilation. > >> > > >> > Added cmake tool dependency. > >> > > >> > Adjusted dependent tools to use NOCACHE as they are needed to build > >> > ccache. > >> > > >> > Signed-off-by: Rosen Penev > >> > --- > >> > v3: zstd was missing in the commit for some reason > >> > v2: fix compilation issues without OS tools. > >> > tools/Makefile | 1 + > >> > tools/ccache/Makefile | 17 + > >> > tools/ccache/patches/100-honour-copts.patch | 20 ++-- > >> > tools/libressl/Makefile | 1 + > >> > tools/pkgconf/Makefile | 2 ++ > >> > tools/zstd/Makefile | 1 + > >> > 6 files changed, 24 insertions(+), 18 deletions(-) > >> > > >> > diff --git a/tools/Makefile b/tools/Makefile > >> > index c66d4fb991..316ffb5ea6 100644 > >> > --- a/tools/Makefile > >> > +++ b/tools/Makefile > >> > @@ -82,6 +82,7 @@ endif > >> > ifneq ($(CONFIG_CCACHE)$(CONFIG_SDK),) > >> > $(foreach tool, $(filter-out xz patch,$(tools-y)), $(eval > >> > $(curdir)/$(tool)/compile += $(curdir)/ccache/compile)) > >> > tools-y += ccache > >> > +$(curdir)/ccache/compile := $(curdir)/cmake/compile > >> > $(curdir)/zstd/compile > >> > endif > >> > > >> > # in case there is no patch tool on the host we need to make patch > >> > tool a > >> > > >> > >> I am not sure if that is right. The v3 patch may create a circular > >> dependency. > > That doesn't seem to be the case. > > > > make tools/ccache/compile works perfectly fine with build/staging_dir > > removed. > > > > Without that addition, ccache will not compile. Removing that line and > > moving the tool names up to line 83 also does not compile. > Yes, it may work in your tests, but the build shows a lot of warnings > like this one: > make[1]: Circular tools/libressl/compile <- tools/ccache/compile > dependency dropped. > > Hannu is right about the circular dependency and his proposed solution. > Please fix your patch Fixed and resent. make tools/ccache/compile V=s &> err.txt grep "Circular" err.txt <-- no longer returns any results. > > - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCHv4] ccache: update to 4.1
Upstream switched to building with CMake. Adjust accordingly.
Reapplied patch as upstream changed the file format.
Added HOST_BUILD_PARALLEL for faster compilation.
Added cmake tool dependency and removed circular dependencies as a
result.
Adjusted dependent tools to use NOCACHE as they are needed to build
ccache.
Signed-off-by: Rosen Penev
---
v4: fixed circular dependencies
v3: zstd was missing in the commit for some reason
v2: fix compilation issues without OS tools.
tools/Makefile | 3 ++-
tools/ccache/Makefile | 17 +
tools/ccache/patches/100-honour-copts.patch | 20 ++--
tools/libressl/Makefile | 1 +
tools/pkgconf/Makefile | 2 ++
tools/zstd/Makefile | 1 +
6 files changed, 25 insertions(+), 19 deletions(-)
diff --git a/tools/Makefile b/tools/Makefile
index c66d4fb991..4bef951c46 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -80,8 +80,9 @@ ifneq ($(HOST_OS),Linux)
endif
ifneq ($(CONFIG_CCACHE)$(CONFIG_SDK),)
-$(foreach tool, $(filter-out xz patch,$(tools-y)), $(eval
$(curdir)/$(tool)/compile += $(curdir)/ccache/compile))
+$(foreach tool, $(filter-out xz zstd patch pkgconf libressl cmake,$(tools-y)),
$(eval $(curdir)/$(tool)/compile += $(curdir)/ccache/compile))
tools-y += ccache
+$(curdir)/ccache/compile := $(curdir)/cmake/compile $(curdir)/zstd/compile
endif
# in case there is no patch tool on the host we need to make patch tool a
diff --git a/tools/ccache/Makefile b/tools/ccache/Makefile
index 6e55001fd5..e016e0beb3 100644
--- a/tools/ccache/Makefile
+++ b/tools/ccache/Makefile
@@ -1,4 +1,4 @@
-#
+#
# Copyright (C) 2006-2015 OpenWrt.org
#
# This is free software, licensed under the GNU General Public License v2.
@@ -8,25 +8,26 @@ include $(TOPDIR)/rules.mk
include $(INCLUDE_DIR)/target.mk
PKG_NAME:=ccache
-PKG_VERSION:=3.7.11
+PKG_VERSION:=4.1
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
PKG_SOURCE_URL:=https://github.com/ccache/ccache/releases/download/v$(PKG_VERSION)
-PKG_HASH:=8d450208099a4d202bd7df87caaec81baee20ce9dd62da91e9ea7b95a9072f68
+PKG_HASH:=5fdc804056632d722a1182e15386696f0ea6c59cb4ab4d65a54f0b269ae86f99
+
+HOST_BUILD_PARALLEL:=1
include $(INCLUDE_DIR)/host-build.mk
+include $(INCLUDE_DIR)/cmake.mk
-HOST_CONFIGURE_VARS += CC="$(HOSTCC_NOCACHE)"
+CMAKE_HOST_OPTIONS += \
+ -DCMAKE_C_COMPILER_LAUNCHER="" \
+ -DCMAKE_CXX_COMPILER_LAUNCHER=""
define Host/Install/ccache
$(INSTALL_DIR) $(STAGING_DIR_HOST)/bin/
$(CP) ./files/* $(STAGING_DIR_HOST)/bin/
endef
-define Host/Clean
- -$(MAKE) -C $(HOST_BUILD_DIR) uninstall
- $(call Host/Clean/Default)
-endef
define Host/Install
$(call Host/Install/Default)
$(call Host/Install/ccache)
diff --git a/tools/ccache/patches/100-honour-copts.patch
b/tools/ccache/patches/100-honour-copts.patch
index ccfa1c0247..e4045ef9be 100644
--- a/tools/ccache/patches/100-honour-copts.patch
+++ b/tools/ccache/patches/100-honour-copts.patch
@@ -1,10 +1,10 @@
a/src/ccache.c
-+++ b/src/ccache.c
-@@ -2277,6 +2277,7 @@ calculate_object_hash(struct args *args,
- "CPLUS_INCLUDE_PATH",
- "OBJC_INCLUDE_PATH",
- "OBJCPLUS_INCLUDE_PATH", // clang
-+ "GCC_HONOUR_COPTS",
- NULL
- };
- for (const char **p = envvars; *p; ++p) {
+--- a/src/ccache.cpp
b/src/ccache.cpp
+@@ -1654,6 +1654,7 @@ calculate_result_name(Context& ctx,
+ "CPLUS_INCLUDE_PATH",
+ "OBJC_INCLUDE_PATH",
+ "OBJCPLUS_INCLUDE_PATH", // clang
++ "GCC_HONOUR_COPTS",
+ nullptr};
+ for (const char** p = envvars; *p; ++p) {
+ const char* v = getenv(*p);
diff --git a/tools/libressl/Makefile b/tools/libressl/Makefile
index dbd8ca4d1a..2b5a33450c 100644
--- a/tools/libressl/Makefile
+++ b/tools/libressl/Makefile
@@ -23,6 +23,7 @@ HOST_BUILD_PARALLEL:=1
include $(INCLUDE_DIR)/host-build.mk
+HOSTCC := $(HOSTCC_NOCACHE)
HOST_CONFIGURE_ARGS += --enable-static --disable-shared --disable-tests
HOST_CFLAGS += $(FPIC)
diff --git a/tools/pkgconf/Makefile b/tools/pkgconf/Makefile
index 7d785aae39..0f56de0e29 100644
--- a/tools/pkgconf/Makefile
+++ b/tools/pkgconf/Makefile
@@ -19,6 +19,8 @@ include $(INCLUDE_DIR)/host-build.mk
unexport PKG_CONFIG
+HOSTCC := $(HOSTCC_NOCACHE)
+
define Host/Install
$(MAKE) -C $(HOST_BUILD_DIR) install
mv $(STAGING_DIR_HOST)/bin/pkgconf
$(STAGING_DIR_HOST)/bin/pkg-config.real
diff --git a/tools/zstd/Makefile b/tools/zstd/Makefile
index 7459725e8e..ec85362544 100644
--- a/tools/zstd/Makefile
+++ b/tools/zstd/Makefile
@@ -15,6 +15,7 @@ HOST_BUILD_PARALLEL:=1
include $(INCLUDE_DIR)/host-build.mk
+HOSTCC := $(HOSTCC_NOCACH
Re: [PATCHv3] ccache: update to 4.1
On 2020-12-23 09:14, Rosen Penev wrote: > On Tue, Dec 22, 2020 at 11:53 PM Hannu Nyman wrote: >> >> Rosen Penev kirjoitti 23.12.2020 klo 8.33: >> > Upstream switched to building with CMake. Adjust accordingly. >> > >> > Reapplied patch as upstream changed the file format. >> > >> > Added HOST_BUILD_PARALLEL for faster compilation. >> > >> > Added cmake tool dependency. >> > >> > Adjusted dependent tools to use NOCACHE as they are needed to build >> > ccache. >> > >> > Signed-off-by: Rosen Penev >> > --- >> > v3: zstd was missing in the commit for some reason >> > v2: fix compilation issues without OS tools. >> > tools/Makefile | 1 + >> > tools/ccache/Makefile | 17 + >> > tools/ccache/patches/100-honour-copts.patch | 20 ++-- >> > tools/libressl/Makefile | 1 + >> > tools/pkgconf/Makefile | 2 ++ >> > tools/zstd/Makefile | 1 + >> > 6 files changed, 24 insertions(+), 18 deletions(-) >> > >> > diff --git a/tools/Makefile b/tools/Makefile >> > index c66d4fb991..316ffb5ea6 100644 >> > --- a/tools/Makefile >> > +++ b/tools/Makefile >> > @@ -82,6 +82,7 @@ endif >> > ifneq ($(CONFIG_CCACHE)$(CONFIG_SDK),) >> > $(foreach tool, $(filter-out xz patch,$(tools-y)), $(eval >> > $(curdir)/$(tool)/compile += $(curdir)/ccache/compile)) >> > tools-y += ccache >> > +$(curdir)/ccache/compile := $(curdir)/cmake/compile $(curdir)/zstd/compile >> > endif >> > >> > # in case there is no patch tool on the host we need to make patch tool a >> > >> >> I am not sure if that is right. The v3 patch may create a circular >> dependency. > That doesn't seem to be the case. > > make tools/ccache/compile works perfectly fine with build/staging_dir removed. > > Without that addition, ccache will not compile. Removing that line and > moving the tool names up to line 83 also does not compile. Yes, it may work in your tests, but the build shows a lot of warnings like this one: make[1]: Circular tools/libressl/compile <- tools/ccache/compile dependency dropped. Hannu is right about the circular dependency and his proposed solution. Please fix your patch - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCHv3] ccache: update to 4.1
Rosen Penev kirjoitti 23.12.2020 klo 10.14: On Tue, Dec 22, 2020 at 11:53 PM Hannu Nyman wrote: Rosen Penev kirjoitti 23.12.2020 klo 8.33: Upstream switched to building with CMake. Adjust accordingly. Reapplied patch as upstream changed the file format. Added HOST_BUILD_PARALLEL for faster compilation. Added cmake tool dependency. Adjusted dependent tools to use NOCACHE as they are needed to build ccache. Signed-off-by: Rosen Penev --- v3: zstd was missing in the commit for some reason v2: fix compilation issues without OS tools. tools/Makefile | 1 + tools/ccache/Makefile | 17 + tools/ccache/patches/100-honour-copts.patch | 20 ++-- tools/libressl/Makefile | 1 + tools/pkgconf/Makefile | 2 ++ tools/zstd/Makefile | 1 + 6 files changed, 24 insertions(+), 18 deletions(-) diff --git a/tools/Makefile b/tools/Makefile index c66d4fb991..316ffb5ea6 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -82,6 +82,7 @@ endif ifneq ($(CONFIG_CCACHE)$(CONFIG_SDK),) $(foreach tool, $(filter-out xz patch,$(tools-y)), $(eval $(curdir)/$(tool)/compile += $(curdir)/ccache/compile)) tools-y += ccache +$(curdir)/ccache/compile := $(curdir)/cmake/compile $(curdir)/zstd/compile endif # in case there is no patch tool on the host we need to make patch tool a I am not sure if that is right. The v3 patch may create a circular dependency. That doesn't seem to be the case. make tools/ccache/compile works perfectly fine with build/staging_dir removed. Did you also test after make dirclean? So that there are no tools. Without that addition, ccache will not compile. Removing that line and moving the tool names up to line 83 also does not compile. Hmm... "tool names" ??? I proposed (below) adding cmake to this filter list "$(filter-out xz patch,$(tools-y))". That would make cmake not to depend on ccache. And then you can quite nicely set ccache to depend on cmake on the next line * First, on line 83 all tools except xz and patch (and flock, sed and tar that are later handled separately) are marked to depend on ccache. This includes cmake. * Then the new addition to the next line makes ccache to depend on cmake. Sounds circular to me. Maybe we need to filter out also cmake on line 83 (in addition to xz and patch). Something like this (I also added zstd in the exclusion list, as ccache now depends on it): $(foreach tool, $(filter-out xz patch cmake zstd,$(tools-y)), $(eval $(curdir)/$(tool)/compile += $(curdir)/ccache/compile)) tools-y += ccache +$(curdir)/ccache/compile := $(curdir)/cmake/compile $(curdir)/zstd/compile ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCHv3] ccache: update to 4.1
On Tue, Dec 22, 2020 at 11:53 PM Hannu Nyman wrote: > > Rosen Penev kirjoitti 23.12.2020 klo 8.33: > > Upstream switched to building with CMake. Adjust accordingly. > > > > Reapplied patch as upstream changed the file format. > > > > Added HOST_BUILD_PARALLEL for faster compilation. > > > > Added cmake tool dependency. > > > > Adjusted dependent tools to use NOCACHE as they are needed to build > > ccache. > > > > Signed-off-by: Rosen Penev > > --- > > v3: zstd was missing in the commit for some reason > > v2: fix compilation issues without OS tools. > > tools/Makefile | 1 + > > tools/ccache/Makefile | 17 + > > tools/ccache/patches/100-honour-copts.patch | 20 ++-- > > tools/libressl/Makefile | 1 + > > tools/pkgconf/Makefile | 2 ++ > > tools/zstd/Makefile | 1 + > > 6 files changed, 24 insertions(+), 18 deletions(-) > > > > diff --git a/tools/Makefile b/tools/Makefile > > index c66d4fb991..316ffb5ea6 100644 > > --- a/tools/Makefile > > +++ b/tools/Makefile > > @@ -82,6 +82,7 @@ endif > > ifneq ($(CONFIG_CCACHE)$(CONFIG_SDK),) > > $(foreach tool, $(filter-out xz patch,$(tools-y)), $(eval > > $(curdir)/$(tool)/compile += $(curdir)/ccache/compile)) > > tools-y += ccache > > +$(curdir)/ccache/compile := $(curdir)/cmake/compile $(curdir)/zstd/compile > > endif > > > > # in case there is no patch tool on the host we need to make patch tool a > > > > I am not sure if that is right. The v3 patch may create a circular dependency. That doesn't seem to be the case. make tools/ccache/compile works perfectly fine with build/staging_dir removed. Without that addition, ccache will not compile. Removing that line and moving the tool names up to line 83 also does not compile. > > * First, on line 83 all tools except xz and patch (and flock, sed and tar > that are later handled separately) are marked to depend on ccache. This > includes cmake. > > * Then the new addition to the next line makes ccache to depend on cmake. > > Sounds circular to me. > > > Maybe we need to filter out also cmake on line 83 (in addition to xz and > patch). > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCHv3] ccache: update to 4.1
Rosen Penev kirjoitti 23.12.2020 klo 8.33: Upstream switched to building with CMake. Adjust accordingly. Reapplied patch as upstream changed the file format. Added HOST_BUILD_PARALLEL for faster compilation. Added cmake tool dependency. Adjusted dependent tools to use NOCACHE as they are needed to build ccache. Signed-off-by: Rosen Penev --- v3: zstd was missing in the commit for some reason v2: fix compilation issues without OS tools. tools/Makefile | 1 + tools/ccache/Makefile | 17 + tools/ccache/patches/100-honour-copts.patch | 20 ++-- tools/libressl/Makefile | 1 + tools/pkgconf/Makefile | 2 ++ tools/zstd/Makefile | 1 + 6 files changed, 24 insertions(+), 18 deletions(-) diff --git a/tools/Makefile b/tools/Makefile index c66d4fb991..316ffb5ea6 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -82,6 +82,7 @@ endif ifneq ($(CONFIG_CCACHE)$(CONFIG_SDK),) $(foreach tool, $(filter-out xz patch,$(tools-y)), $(eval $(curdir)/$(tool)/compile += $(curdir)/ccache/compile)) tools-y += ccache +$(curdir)/ccache/compile := $(curdir)/cmake/compile $(curdir)/zstd/compile endif # in case there is no patch tool on the host we need to make patch tool a I am not sure if that is right. The v3 patch may create a circular dependency. * First, on line 83 all tools except xz and patch (and flock, sed and tar that are later handled separately) are marked to depend on ccache. This includes cmake. * Then the new addition to the next line makes ccache to depend on cmake. Sounds circular to me. Maybe we need to filter out also cmake on line 83 (in addition to xz and patch). ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
