Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Hi Andre, On Tue, Apr 7, 2020 at 9:28 PM Andre Valentin wrote: > > Am 07.04.20 um 20:05 schrieb Sergio Paracuellos: > > Hi, > > > > On Tue, Apr 7, 2020 at 12:16 PM Chuanhong Guo wrote: > >> > >> [CC Sergio who worked on upstream PCIE driver] > >> > >> On Tue, Apr 7, 2020 at 4:45 PM Andre Valentin > >> wrote: > >>> > >>> Hi! > >>> > >>> Currently I'm having some serious problems with the new 5.4 port. > >>> 1) PCIe > >>> I'm developing on the ZyXEL LTE3301-PLUS. It has PCIe and a mt7615e > >>> connected to second bus on the first phy. > >>> If booting the device, kernel hangs with a RST message, telling the > >>> device is not detected. It seems the PCIe bus 1 > >>> cannot be reseted because nothing is connected to bus 0. > >>> An upport of the old PCI driver reenables the function. I can provide > >>> more logs on this if needed. > > > > Logs and dmesg traces are always welcome and would be helpful. Both > > working and not working traces. > > Of course, here we go with the old PCIe driver taken from 4.14 openwrt kernel: > [0.485729] pinctrl core: add 0 pinctrl maps > [0.485865] pull PCIe RST: RALINK_RSTCTRL = 400 > [0.796015] release PCIe RST: RALINK_RSTCTRL = 700 > [0.806088] * Xtal 40MHz * > [0.812829] release PCIe RST: RALINK_RSTCTRL = 700 > [0.823025] Port 0 N_FTS = 1b102800 > [0.829933] Port 1 N_FTS = 1b105000 > [0.836849] Port 2 N_FTS = 1b102800 > [1.995991] PCIE0 no card, disable it(RST) > [2.004682] PCIE2 no card, disable it(RST) > [2.013495] -> 20107f2 > [2.018328] PCIE1 enabled > [2.023532] PCI host bridge /pcie@1e14 ranges: > [2.033045] MEM 0x6000..0x6fff > [2.043401] IO 0x1e16..0x1e16 > [2.053762] PCI coherence region base: 0xbfbf8000, mask/settings: > 0x6000 > [2.091056] PCI host bridge to bus :00 > [2.099131] pci_bus :00: root bus resource [mem 0x6000-0x6fff] > [2.112734] pci_bus :00: root bus resource [io 0x] > [2.124486] pci_bus :00: root bus resource [??? 0x flags 0x0] > [2.137962] pci_bus :00: No busn resource found for root bus, will use > [bus 00-ff] > [2.153766] pci :00:00.0: [0e8d:0801] type 01 class 0x060400 > [2.165651] pci :00:00.0: reg 0x10: [mem 0x-0x7fff] > [2.178057] pci :00:00.0: reg 0x14: [mem 0x6010-0x6010] > [2.190585] pci :00:00.0: supports D1 > [2.198439] pci :00:00.0: PME# supported from D0 D1 D3hot > [2.211463] random: fast init done > [2.211838] pci :01:00.0: [14c3:7615] type 00 class 0x000280 > [2.230071] pci :01:00.0: reg 0x10: [mem 0x-0x000f 64bit] > [2.243675] pci :01:00.0: 2.000 Gb/s available PCIe bandwidth, limited > by 2.5 GT/s x1 link at :00:00.0 (capable of 4.000 Gb/s with 5 GT/s x1 > link) > [2.272296] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01 > [2.285339] pci_bus :00: busn_res: [bus 00-ff] end is updated to 01 > [2.298493] pci :00:00.0: BAR 0: no space for [mem size 0x8000] > [2.311581] pci :00:00.0: BAR 0: failed to assign [mem size 0x8000] > [2.325410] pci :00:00.0: BAR 8: assigned [mem 0x6000-0x600f] > [2.33] pci :00:00.0: BAR 1: assigned [mem 0x6010-0x6010] > [2.352376] pci :01:00.0: BAR 0: assigned [mem 0x6000-0x600f > 64bit] > [2.366887] pci :00:00.0: PCI bridge to [bus 01] > [2.376728] pci :00:00.0: bridge window [mem 0x6000-0x600f] > > > And this is on 5.4 with the new driver with pcie0 status=disabled: > [ 30.464407] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset > [ 30.464415] mt7621-pci 1e14.pcie: using device tree for GPIO lookup > [ 30.464474] mt7621-pci 1e14.pcie: using lookup tables for GPIO lookup > [ 30.464484] mt7621-pci 1e14.pcie: No GPIO consumer reset found > [ 30.664239] mt7621-pci 1e14.pcie: pcie1 no card, disable it (RST & CLK) > [ 30.678128] mt7621-pci 1e14.pcie: Nothing is connected in virtual > bridges. Exiting... > booting goes on. > > And with pcie status=enabled: > [ 32.415863] rt2880-pinmux pinctrl: pcie is already enabled > [ 32.426821] mt7621-pci 1e14.pcie: Error applying setting, reverse > things back > [ 32.441900] mt7621-pci-phy 1e149000.pcie-phy: PHY for 0xbe149000 (dual > port = 1) > [ 32.456880] mt7621-pci-phy 1e14a000.pcie-phy: PHY for 0xbe14a000 (dual > port = 0) > [ 32.571556] mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz > [ 32.582680] mt7621-pci-phy 1e14a000.pcie-phy: Xtal is 40MHz > [ 32.693592] mt7621-pci 1e14.pcie: pcie0 no card, disable it (RST & CLK) > hangs. I think the problem here is that upstream driver use two phy's nodes with pcie-phy0 being a dual ported one. Because there is nothing connected in pcie0 the phy is just stopped assuming nothing will be connected also in pcie1. Just
[OpenWrt-Devel] [PATCH] scripts: add docker-run-rootfs.sh
The script allows to run a OpenWrt x86/64 rootfs in no time. It is
possible to access the web interface and SSH via 192.168.1.1.
By using docker volume mounts you can easily share files/folders between
container and host, allowing ot use hosts tools to work on files
deployed in a running OpenWrt instance.
Additional parameters (like volumes) are passed to the `docker create`
command, an example for this below. When quiting the container via `C-d`
a "teardown" removes the container + created network.
./scripts/docker-run-rootfs.sh \
-v
$(pwd)/package/base-files/files/bin/sysupgrade-online:/bin/sysupgrade-online \
-v
$(pwd)/package/base-files/files/lib/upgrade/online.sh:/lib/upgrade/online.sh
Files and folders to share must be in 664 mode for "live" upgrades, see[0].
Aditionally it is possible to define "NETWORK_PREFIX" like "192.168.2"
(without final number) to change the created network the OpenWrt
container uses as LAN. This is to avoid network trouble (like if the
developer uses 192.168.1.x as upstream connection) or multiple container
should run in parralllel.
Network is disabled by default, enable it via --network or -n.
Using --prebuild or -p will download the OpenWrt image from docker hub.
[0]:
https://forums.docker.com/t/modify-a-file-which-mount-as-a-data-volume-but-it-didnt-change-in-container/2813/14
Signed-off-by: Paul Spooren
---
scripts/docker-run-rootfs.sh | 96
1 file changed, 96 insertions(+)
create mode 100755 scripts/docker-run-rootfs.sh
diff --git a/scripts/docker-run-rootfs.sh b/scripts/docker-run-rootfs.sh
new file mode 100755
index 00..494fd7a6e4
--- /dev/null
+++ b/scripts/docker-run-rootfs.sh
@@ -0,0 +1,96 @@
+#!/bin/sh
+
+set -e
+
+SELF="$0"
+ROOTFS_PATH="$(pwd)/bin/targets/x86/64/openwrt-x86-64-generic-rootfs.tar.gz"
+NETWORK_ENABLE="${NETWORK_ENABLE:-0}"
+NETWORK_PREFIX="${NETWORK_PREFIX:-192.168.1}"
+IMAGE_NAME="openwrt-rootfs:$NETWORK_PREFIX"
+NETWORK_NAME="none"
+
+die() {
+ echo "$1"
+ exit 1
+}
+
+usage() {
+ cat >&2 <]
+ [-n|--network]
+ [-p|--prebuild]
+
+ allows to specifiy a different path for the rootfs.
+ enables network access based on
+ uses the official docker images openwrtorg/rootfs:latest
+ -> changes to are ignored
+EOF
+}
+
+parse_args() {
+ while [ "$#" -gt 0 ]; do
+ case "$1" in
+ --rootfs) ROOTFS_PATH="$2"; shift 2 ;;
+ --network|-n) NETWORK_ENABLE=1; shift ;;
+ --prebuild|-p) PREBUILD=1; shift ;;
+ --help|-h)
+ usage
+ exit 0
+ ;;
+ *)
+ DOCKER_EXTRA="$DOCKER_EXTRA $1"
+ shift
+ ;;
+ esac
+ done
+}
+
+parse_args "$@"
+
+[ -f "$ROOTFS_PATH" ] || die "Couldn't find rootfs at $ROOTFS_PATH"
+
+if [ -z "$PREBUILD" ]; then
+ DOCKERFILE="$(mktemp -p $(dirname $ROOTFS_PATH))"
+ cat < "$DOCKERFILE"
+ FROM scratch
+ ADD $(basename $ROOTFS_PATH) /
+ RUN sed 's/pi_ip="192.168.1.1/pi_ip="$NETWORK_PREFIX.1"/'
+ RUN sed
's/pi_broadcast="192.168.1.255/pi_broadcast="$NETWORK_PREFIX.255"/'
+ RUN echo "console::askfirst:/usr/libexec/login.sh" >> /etc/inittab
+ EXPOSE 22 80 443
+ USER root
+ CMD ["/sbin/init"]
+EOT
+ docker build -t "$IMAGE_NAME" -f "$DOCKERFILE" "$(dirname $ROOTFS_PATH)"
+ rm "$DOCKERFILE"
+else
+ IMAGE_NAME="openwrtorg/rootfs:latest"
+ docker pull "$IMAGE_NAME"
+fi
+
+echo "[*] Build: $ROOTFS_PATH"
+
+if [ "$NETWORK_ENABLE" = 1 ]; then
+ NETWORK_NAME="openwrt-lan-$NETWORK_PREFIX"
+ LAN_IP="$NETWORK_PREFIX.1"
+ if [ -z "$(docker network ls | grep $NETWORK_NAME)" ]; then
+ docker network create \
+ --driver=bridge \
+ --subnet="$NETWORK_PREFIX.0/24" \
+ --ip-range="$NETWORK_PREFIX.0/24" \
+ --gateway="$NETWORK_PREFIX.2" \
+ "$NETWORK_NAME"
+ echo "[*] Created $NETWORK_NAME network "
+ fi
+fi
+
+docker run -it --rm --network="$NETWORK_NAME" --ip="$LAN_IP" \
+ --name openwrt-docker $DOCKER_EXTRA "$IMAGE_NAME"
+echo "[*] Created $IMAGE_NAME"
+
+if [ "$NETWORK_ENABLE" = 1 ]; then
+ docker network rm "$NETWORK_NAME"
+ echo "[*] Cleaned up network"
+fi
--
2.25.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] ramips: mt7620: Looking for github PR mt7620 driver patch reviewer
Hi everybody, sometime ago I sent github PR[1] with support for D-Link DWR-960. I prepared patch for mt7620, which add rgmii delays setting possibility. Could someone take a look at this and review it? [1] https://github.com/openwrt/openwrt/pull/2857 Regards, Pawel Dembicki ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 4/6] build: simplify building *config targets
Instead of passing pkg-config location through a variable when building qconf (make xconfig), prepend its parent directory to the PATH, as it is being done for other conf targets. Use a Makefile pattern rule to group all 'scripts/config/%onf' (currently conf, mconf, qconf) targets in a single rule. Add -O2 to CFLAGS when building them as well. Signed-off-by: Eneas U de Queiroz --- include/toplevel.mk | 15 --- scripts/config/Makefile | 23 +-- 2 files changed, 13 insertions(+), 25 deletions(-) diff --git a/include/toplevel.mk b/include/toplevel.mk index 2b3b55db9f..2965f75c7c 100644 --- a/include/toplevel.mk +++ b/include/toplevel.mk @@ -100,21 +100,14 @@ prepare-tmpinfo: FORCE fi ifneq ($(DISTRO_PKG_CONFIG),) -scripts/config/mconf: export PATH:=$(dir $(DISTRO_PKG_CONFIG)):$(PATH) +scripts/config/%onf: export PATH:=$(dir $(DISTRO_PKG_CONFIG)):$(PATH) endif -scripts/config/mconf: - @$(_SINGLE)$(SUBMAKE) -s -C scripts/config all CC="$(HOSTCC_WRAPPER)" +scripts/config/%onf: CFLAGS+= -O2 +scripts/config/%onf: + @$(_SINGLE)$(SUBMAKE) -s -C scripts/config $(notdir $@) CC="$(HOSTCC_WRAPPER)" $(eval $(call rdep,scripts/config,scripts/config/mconf)) -scripts/config/qconf: - @$(_SINGLE)$(SUBMAKE) -s -C scripts/config qconf \ - CC="$(HOSTCC_WRAPPER)" \ - DISTRO-PKG-CONFIG="$(DISTRO_PKG_CONFIG)" - -scripts/config/conf: - @$(_SINGLE)$(SUBMAKE) -s -C scripts/config conf CC="$(HOSTCC_WRAPPER)" - config: scripts/config/conf prepare-tmpinfo FORCE [ -L .config ] && export KCONFIG_OVERWRITECONFIG=1; \ $< Config.in diff --git a/scripts/config/Makefile b/scripts/config/Makefile index 0eac8edd22..1f9184e3aa 100644 --- a/scripts/config/Makefile +++ b/scripts/config/Makefile @@ -39,12 +39,7 @@ conf: $(conf-objs) mconf: $(mconf-objs) $(lxdialog-objs) $(CC) -o $@ $^ $(call check_lxdialog,ldflags $(CC)) qconf: $(qconf-cxxobjs) $(qconf-objs) -ifneq ($(DISTRO-PKG-CONFIG),) $(CXX) -o $@ $^ $(HOSTLOADLIBES_qconf) -else - echo "You don't have 'pkg-config' installed. Cannot continue" - echo "For now, you may use 'make menuconfig' instead of 'make xconfig'" -endif clean: rm -f *.o lxdialog/*.o $(clean-files) conf mconf @@ -74,17 +69,17 @@ qconf.o: .tmp_qtcheck # Qt needs some extra effort... .tmp_qtcheck: @set -e; echo " CHECK qt"; \ - if $(DISTRO-PKG-CONFIG) --exists Qt5Core; then \ - cflags="-std=c++11 -fPIC `$(DISTRO-PKG-CONFIG) --cflags Qt5Core Qt5Gui Qt5Widgets`"; \ - libs=`$(DISTRO-PKG-CONFIG) --libs Qt5Core Qt5Gui Qt5Widgets`; \ - moc=`$(DISTRO-PKG-CONFIG) --variable=host_bins Qt5Core`/moc; \ - elif $(DISTRO-PKG-CONFIG) --exists QtCore; then \ - cflags=`$(DISTRO-PKG-CONFIG) --cflags QtCore QtGui`; \ - libs=`$(DISTRO-PKG-CONFIG) --libs QtCore QtGui`; \ - moc=`$(DISTRO-PKG-CONFIG) --variable=moc_location QtCore`; \ + if pkg-config --exists Qt5Core; then \ + cflags="-std=c++11 -fPIC `pkg-config --cflags Qt5Core Qt5Gui Qt5Widgets`"; \ + libs=`pkg-config --libs Qt5Core Qt5Gui Qt5Widgets`; \ + moc=`pkg-config --variable=host_bins Qt5Core`/moc; \ + elif pkg-config --exists QtCore; then \ + cflags=`pkg-config --cflags QtCore QtGui`; \ + libs=`pkg-config --libs QtCore QtGui`; \ + moc=`pkg-config --variable=moc_location QtCore`; \ else \ echo >&2 "*"; \ - echo >&2 "* Could not find Qt via $(DISTRO-PKG-CONFIG)."; \ + echo >&2 "* Could not find Qt via pkg-config."; \ echo >&2 "* Please install either Qt 4.8 or 5.x. and make sure it's in PKG_CONFIG_PATH"; \ echo >&2 "*"; \ exit 1; \ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 3/6] build: define RTC_SUPPORT as a bool
Currently, RTC_SUPPORT is defined as a tristate, with 'depends on m', which is supposed to only let it be set to 'm' or 'n'. However, scripts/target-metadata.pl will 'select' it, or setting it to 'y', which defeats it's 'depends on m' restriction. The users of the symbol are not expecting it to be necessarily 'm' either, so we can safely use it as bool. Newer versions of Linux 'conf' will issue a warning when it detects such unmet dependencies, and will set it to 'n' instead of 'y', as the current version does. In all cases, 'm' is never used. Signed-off-by: Eneas U de Queiroz --- target/Config.in | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/target/Config.in b/target/Config.in index 3ee23ebf7f..9fead5994f 100644 --- a/target/Config.in +++ b/target/Config.in @@ -37,8 +37,7 @@ config USB_GADGET_SUPPORT bool config RTC_SUPPORT - tristate - depends on m + bool config BIG_ENDIAN bool ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 6/6] build: add option to warn on recursive dependency
This addes the option to treat recursive dependencies as warnings instead of errors, by running make with WARN_RECURSIVE_DEP=1. Note that the script/config targets will not get rebuilt when you add or remove WARN_RECURSIVE_DEP while running make. One must run 'make config-clean' before building config with a different setting. Signed-off-by: Eneas U de Queiroz --- include/toplevel.mk | 2 +- scripts/config/README | 4 scripts/config/symbol.c | 5 + 3 files changed, 10 insertions(+), 1 deletion(-) diff --git a/include/toplevel.mk b/include/toplevel.mk index 2965f75c7c..def80503dd 100644 --- a/include/toplevel.mk +++ b/include/toplevel.mk @@ -102,7 +102,7 @@ prepare-tmpinfo: FORCE ifneq ($(DISTRO_PKG_CONFIG),) scripts/config/%onf: export PATH:=$(dir $(DISTRO_PKG_CONFIG)):$(PATH) endif -scripts/config/%onf: CFLAGS+= -O2 +scripts/config/%onf: CFLAGS+= -O2 $(if $(WARN_RECURSIVE_DEP),-DWARN_RECURSIVE_DEP) scripts/config/%onf: @$(_SINGLE)$(SUBMAKE) -s -C scripts/config $(notdir $@) CC="$(HOSTCC_WRAPPER)" diff --git a/scripts/config/README b/scripts/config/README index ac5f094ff2..81243e8016 100644 --- a/scripts/config/README +++ b/scripts/config/README @@ -16,6 +16,10 @@ OpenWrt Buildroot: - reverted an upstream change that avoids writing symbols that are not visible to .config, which breaks OpenWrt busybox's '.config' generation logic. + - add a compilation option (-DWARN_RECURSIVE_DEP) to treat recursive deps + as a warning, avoiding a complete build failure because of unrelated or + minor recursive deps, or making a scrict check before commiting a change + that may cause one. - use pre-built *.lex.c *.tab.[ch] files by default, to avoid depending on flex & bison. Rebuild/remove these files only if running make with BUILD_SHIPPED_FILES defined diff --git a/scripts/config/symbol.c b/scripts/config/symbol.c index b1dd9be29d..5c6f540314 100644 --- a/scripts/config/symbol.c +++ b/scripts/config/symbol.c @@ -1250,6 +1250,11 @@ struct symbol *sym_check_deps(struct symbol *sym) sym->flags &= ~SYMBOL_CHECK; } +#ifdef WARN_RECURSIVE_DEP + if (sym2 && sym2 == sym) + sym2 = NULL; +#endif + return sym2; } ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 2/6] busybox: quote 'source' filenames in Config.in
Newer versions of the kconfig program requires quoting the arguments of the 'source' directive. These are the last ones not using them. Signed-off-by: Eneas U de Queiroz --- package/utils/busybox/config/Config.in| 44 +-- .../utils/busybox/config/networking/Config.in | 2 +- .../utils/busybox/config/util-linux/Config.in | 2 +- 3 files changed, 24 insertions(+), 24 deletions(-) diff --git a/package/utils/busybox/config/Config.in b/package/utils/busybox/config/Config.in index 8d1394c2e2..03af3464f9 100644 --- a/package/utils/busybox/config/Config.in +++ b/package/utils/busybox/config/Config.in @@ -702,30 +702,30 @@ config BUSYBOX_CONFIG_EFENCE endchoice -source libbb/Config.in +source "libbb/Config.in" endmenu comment "Applets" -source archival/Config.in -source coreutils/Config.in -source console-tools/Config.in -source debianutils/Config.in -source klibc-utils/Config.in -source editors/Config.in -source findutils/Config.in -source init/Config.in -source loginutils/Config.in -source e2fsprogs/Config.in -source modutils/Config.in -source util-linux/Config.in -source miscutils/Config.in -source networking/Config.in -source printutils/Config.in -source mailutils/Config.in -source procps/Config.in -source runit/Config.in -source selinux/Config.in -source shell/Config.in -source sysklogd/Config.in +source "archival/Config.in" +source "coreutils/Config.in" +source "console-tools/Config.in" +source "debianutils/Config.in" +source "klibc-utils/Config.in" +source "editors/Config.in" +source "findutils/Config.in" +source "init/Config.in" +source "loginutils/Config.in" +source "e2fsprogs/Config.in" +source "modutils/Config.in" +source "util-linux/Config.in" +source "miscutils/Config.in" +source "networking/Config.in" +source "printutils/Config.in" +source "mailutils/Config.in" +source "procps/Config.in" +source "runit/Config.in" +source "selinux/Config.in" +source "shell/Config.in" +source "sysklogd/Config.in" diff --git a/package/utils/busybox/config/networking/Config.in b/package/utils/busybox/config/networking/Config.in index 1a740d998e..f07a2d46e5 100644 --- a/package/utils/busybox/config/networking/Config.in +++ b/package/utils/busybox/config/networking/Config.in @@ -1196,7 +1196,7 @@ config BUSYBOX_CONFIG_ZCIP See http://www.zeroconf.org for further details, and "zcip.script" in the busybox examples. -source udhcp/Config.in +source "udhcp/Config.in" config BUSYBOX_CONFIG_IFUPDOWN_UDHCPC_CMD_OPTIONS string "ifup udhcpc command line options" diff --git a/package/utils/busybox/config/util-linux/Config.in b/package/utils/busybox/config/util-linux/Config.in index 1cb2245e32..1a3871e92c 100644 --- a/package/utils/busybox/config/util-linux/Config.in +++ b/package/utils/busybox/config/util-linux/Config.in @@ -994,6 +994,6 @@ config BUSYBOX_CONFIG_FEATURE_MTAB_SUPPORT About the only reason to use this is if you've removed /proc from your kernel. -source volume_id/Config.in +source "volume_id/Config.in" endmenu ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 1/6] kernel: add @IPV6 dependency to ipv6 modules
IPv6 modules should all depend on @IPV6, to avoid circular dependencies problems, especially if they select a module that depends on IPV6 as well. In theory, if a package A depends on IPV6, any package doing 'select A' (DEPENDS+= A) should also depend on IPV6; otherwise selecting A will fail. Sometimes the build system is forgiving this, but eventually, and unexpectedly, it may blow up on some other commit. Alternatively one can conditionally add IPv6 dependencies only if CONFIG_IPV6 is selected: (DEPENDS+= +IPV6:package6). Signed-off-by: Eneas U de Queiroz --- package/kernel/linux/modules/netfilter.mk | 13 - package/kernel/linux/modules/netsupport.mk | 6 +++--- 2 files changed, 11 insertions(+), 8 deletions(-) diff --git a/package/kernel/linux/modules/netfilter.mk b/package/kernel/linux/modules/netfilter.mk index 4f31fa8b18..5a3d490173 100644 --- a/package/kernel/linux/modules/netfilter.mk +++ b/package/kernel/linux/modules/netfilter.mk @@ -137,7 +137,7 @@ define KernelPackage/nf-nat6 SUBMENU:=$(NF_MENU) TITLE:=Netfilter IPV6-NAT KCONFIG:=$(KCONFIG_NF_NAT6) - DEPENDS:=+kmod-nf-conntrack6 +kmod-nf-nat + DEPENDS:=@IPV6 +kmod-nf-conntrack6 +kmod-nf-nat FILES:=$(foreach mod,$(NF_NAT6-m),$(LINUX_DIR)/net/$(mod).ko) AUTOLOAD:=$(call AutoProbe,$(notdir $(NF_NAT6-m))) endef @@ -471,6 +471,7 @@ $(eval $(call KernelPackage,ipt-raw)) define KernelPackage/ipt-raw6 TITLE:=Netfilter IPv6 raw table support + DEPENDS:=@IPV6 KCONFIG:=CONFIG_IP6_NF_RAW FILES:=$(LINUX_DIR)/net/ipv6/netfilter/ip6table_raw.ko AUTOLOAD:=$(call AutoProbe,ip6table_raw) @@ -482,6 +483,7 @@ $(eval $(call KernelPackage,ipt-raw6)) define KernelPackage/ipt-nat6 TITLE:=IPv6 NAT targets + DEPENDS:=@IPV6 KCONFIG:=$(KCONFIG_IPT_NAT6) FILES:=$(foreach mod,$(IPT_NAT6-m),$(LINUX_DIR)/net/$(mod).ko) AUTOLOAD:=$(call AutoLoad,43,$(notdir $(IPT_NAT6-m))) @@ -806,7 +808,7 @@ $(eval $(call KernelPackage,ipt-physdev)) define KernelPackage/ip6tables SUBMENU:=$(NF_MENU) TITLE:=IPv6 modules - DEPENDS:=+kmod-nf-reject6 +kmod-nf-ipt6 +kmod-ipt-core + DEPENDS:=@IPV6 +kmod-nf-reject6 +kmod-nf-ipt6 +kmod-ipt-core KCONFIG:=$(KCONFIG_IPT_IPV6) FILES:=$(foreach mod,$(IPT_IPV6-m),$(LINUX_DIR)/net/$(mod).ko) AUTOLOAD:=$(call AutoLoad,42,$(notdir $(IPT_IPV6-m))) @@ -821,7 +823,7 @@ $(eval $(call KernelPackage,ip6tables)) define KernelPackage/ip6tables-extra SUBMENU:=$(NF_MENU) TITLE:=Extra IPv6 modules - DEPENDS:=+kmod-ip6tables + DEPENDS:=@IPV6 +kmod-ip6tables KCONFIG:=$(KCONFIG_IPT_IPV6_EXTRA) FILES:=$(foreach mod,$(IPT_IPV6_EXTRA-m),$(LINUX_DIR)/net/$(mod).ko) AUTOLOAD:=$(call AutoLoad,43,$(notdir $(IPT_IPV6_EXTRA-m))) @@ -911,6 +913,7 @@ $(eval $(call KernelPackage,ebtables-ipv4)) define KernelPackage/ebtables-ipv6 TITLE:=ebtables: IPv6 support + DEPENDS:=@IPV6 FILES:=$(foreach mod,$(EBTABLES_IP6-m),$(LINUX_DIR)/net/$(mod).ko) KCONFIG:=$(KCONFIG_EBTABLES_IP6) AUTOLOAD:=$(call AutoProbe,$(notdir $(EBTABLES_IP6-m))) @@ -1049,7 +1052,7 @@ $(eval $(call KernelPackage,ipt-rpfilter)) define KernelPackage/nft-core SUBMENU:=$(NF_MENU) TITLE:=Netfilter nf_tables support - DEPENDS:=+kmod-nfnetlink +kmod-nf-reject +kmod-nf-reject6 +kmod-nf-conntrack6 +LINUX_5_4:kmod-nf-nat + DEPENDS:=+kmod-nfnetlink +kmod-nf-reject +IPV6:kmod-nf-reject6 +IPV6:kmod-nf-conntrack6 +LINUX_5_4:kmod-nf-nat FILES:=$(foreach mod,$(NFT_CORE-m),$(LINUX_DIR)/net/$(mod).ko) AUTOLOAD:=$(call AutoProbe,$(notdir $(NFT_CORE-m))) KCONFIG:= \ @@ -1106,7 +1109,7 @@ $(eval $(call KernelPackage,nft-nat)) define KernelPackage/nft-offload SUBMENU:=$(NF_MENU) TITLE:=Netfilter nf_tables routing/NAT offload support - DEPENDS:=+kmod-nf-flow +kmod-nft-nat + DEPENDS:=@IPV6 +kmod-nf-flow +kmod-nft-nat KCONFIG:= \ CONFIG_NF_FLOW_TABLE_INET \ CONFIG_NF_FLOW_TABLE_IPV4 \ diff --git a/package/kernel/linux/modules/netsupport.mk b/package/kernel/linux/modules/netsupport.mk index ca25138571..487d29b073 100644 --- a/package/kernel/linux/modules/netsupport.mk +++ b/package/kernel/linux/modules/netsupport.mk @@ -318,7 +318,7 @@ IPSEC6-m += $(ifeq ($$(strip $$(call CompareKernelPatchVer,$$(KERNEL_PATCHVER),l define KernelPackage/ipsec6 SUBMENU:=$(NETWORK_SUPPORT_MENU) TITLE:=IPsec related modules (IPv6) - DEPENDS:=kmod-ipsec +kmod-iptunnel6 + DEPENDS:=@IPV6 kmod-ipsec +kmod-iptunnel6 KCONFIG:= \ CONFIG_INET6_AH \ CONFIG_INET6_ESP \ @@ -383,7 +383,7 @@ $(eval $(call KernelPackage,ip-vti)) define KernelPackage/ip6-vti SUBMENU:=$(NETWORK_SUPPORT_MENU) TITLE:=IPv6 VTI (Virtual Tunnel Interface) - DEPENDS:=+kmod-iptunnel +kmod-ip6-tunnel +kmod-ipsec6 + DEPENDS:=@IPV6 +kmod-iptunnel +kmod-ip6-tunnel +kmod-ipsec6 KCONFIG:=CONFIG_IPV6_VTI FILES:=$(LINUX_DIR)/net/ipv6/ip6_vti.ko AUTOLOAD:=$(call AutoLoad,33,ip6_vti) @@ -399,7 +399,7 @@ $(eval $(call KernelPackage,ip6-vti)) define KernelPackage/xfrm-interface
[OpenWrt-Devel] [PATCH v2 0/6] build: update scritps/config to kconfig-v5.6
The full cover-letter is in the original series. V2 is about shipping
pre-generated c/h files to avoid depending on bison & flex.
The _shipped files are gone upstream, so I did not use the previous
scheme, of copying *_shipped files. Instead, I'm shipping the *.[ch]
files directly.
I've made it easier to generate the files if desired, by running make with
BUILD_SHIPPED_FILES=1 (the actual value does not matter). It is
documented in the README file. Defining the variable changes make clean
to remove the generated files as well.
--
Changelog
v1->v2:
- Added pre-generated *.tab.[ch] *.lex.c files to avoid depending on
flex & bison
Eneas U de Queiroz (6):
kernel: add @IPV6 dependency to ipv6 modules
busybox: quote 'source' filenames in Config.in
build: define RTC_SUPPORT as a bool
build: simplify building *config targets
build: scripts/config - update to kconfig-v5.6
build: add option to warn on recursive dependency
include/toplevel.mk | 15 +-
package/kernel/linux/modules/netfilter.mk | 13 +-
package/kernel/linux/modules/netsupport.mk|6 +-
package/utils/busybox/config/Config.in| 44 +-
.../utils/busybox/config/networking/Config.in |2 +-
.../utils/busybox/config/util-linux/Config.in |2 +-
scripts/config/.gitignore | 29 +-
scripts/config/Makefile | 179 +-
scripts/config/README | 30 +-
scripts/config/conf.c | 248 +-
scripts/config/confdata.c | 533 +-
scripts/config/expr.c | 216 +-
scripts/config/expr.h | 110 +-
scripts/config/images.c | 34 +-
scripts/config/images.h | 33 +
scripts/config/{zconf.l => lexer.l} | 340 +-
scripts/config/lexer.lex.c| 4499 +
scripts/config/list.h |1 +
scripts/config/lkc.h | 58 +-
scripts/config/lkc_proto.h| 21 +-
scripts/config/lxdialog/.gitignore|2 -
scripts/config/lxdialog/check-lxdialog.sh | 91 -
scripts/config/lxdialog/checklist.c | 19 +-
scripts/config/lxdialog/dialog.h | 23 +-
scripts/config/lxdialog/inputbox.c| 22 +-
scripts/config/lxdialog/menubox.c | 25 +-
scripts/config/lxdialog/textbox.c | 17 +-
scripts/config/lxdialog/util.c| 15 +-
scripts/config/lxdialog/yesno.c | 19 +-
scripts/config/mconf-cfg.sh | 50 +
scripts/config/mconf.c| 179 +-
scripts/config/menu.c | 451 +-
.../{zconf.tab.c_shipped => parser.tab.c} | 939 ++--
scripts/config/parser.tab.h | 129 +
scripts/config/{zconf.y => parser.y} | 429 +-
scripts/config/preprocess.c | 575 +++
scripts/config/qconf-cfg.sh | 32 +
scripts/config/qconf.cc | 174 +-
scripts/config/qconf.h|3 +-
scripts/config/symbol.c | 268 +-
scripts/config/util.c | 86 +-
scripts/config/zconf.gperf| 49 -
scripts/config/zconf.hash.c_shipped | 250 -
scripts/config/zconf.lex.c_shipped| 2533 --
target/Config.in |3 +-
45 files changed, 7798 insertions(+), 4998 deletions(-)
create mode 100644 scripts/config/images.h
rename scripts/config/{zconf.l => lexer.l} (50%)
create mode 100644 scripts/config/lexer.lex.c
delete mode 100644 scripts/config/lxdialog/.gitignore
delete mode 100644 scripts/config/lxdialog/check-lxdialog.sh
create mode 100755 scripts/config/mconf-cfg.sh
rename scripts/config/{zconf.tab.c_shipped => parser.tab.c} (73%)
create mode 100644 scripts/config/parser.tab.h
rename scripts/config/{zconf.y => parser.y} (64%)
create mode 100644 scripts/config/preprocess.c
create mode 100755 scripts/config/qconf-cfg.sh
delete mode 100644 scripts/config/zconf.gperf
delete mode 100644 scripts/config/zconf.hash.c_shipped
delete mode 100644 scripts/config/zconf.lex.c_shipped
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Am 07.04.20 um 20:05 schrieb Sergio Paracuellos:
> Hi,
>
> On Tue, Apr 7, 2020 at 12:16 PM Chuanhong Guo wrote:
>>
>> [CC Sergio who worked on upstream PCIE driver]
>>
>> On Tue, Apr 7, 2020 at 4:45 PM Andre Valentin wrote:
>>>
>>> Hi!
>>>
>>> Currently I'm having some serious problems with the new 5.4 port.
>>> 1) PCIe
>>> I'm developing on the ZyXEL LTE3301-PLUS. It has PCIe and a mt7615e
>>> connected to second bus on the first phy.
>>> If booting the device, kernel hangs with a RST message, telling the device
>>> is not detected. It seems the PCIe bus 1
>>> cannot be reseted because nothing is connected to bus 0.
>>> An upport of the old PCI driver reenables the function. I can provide more
>>> logs on this if needed.
>
> Logs and dmesg traces are always welcome and would be helpful. Both
> working and not working traces.
Of course, here we go with the old PCIe driver taken from 4.14 openwrt kernel:
[0.485729] pinctrl core: add 0 pinctrl maps
[0.485865] pull PCIe RST: RALINK_RSTCTRL = 400
[0.796015] release PCIe RST: RALINK_RSTCTRL = 700
[0.806088] * Xtal 40MHz *
[0.812829] release PCIe RST: RALINK_RSTCTRL = 700
[0.823025] Port 0 N_FTS = 1b102800
[0.829933] Port 1 N_FTS = 1b105000
[0.836849] Port 2 N_FTS = 1b102800
[1.995991] PCIE0 no card, disable it(RST)
[2.004682] PCIE2 no card, disable it(RST)
[2.013495] -> 20107f2
[2.018328] PCIE1 enabled
[2.023532] PCI host bridge /pcie@1e14 ranges:
[2.033045] MEM 0x6000..0x6fff
[2.043401] IO 0x1e16..0x1e16
[2.053762] PCI coherence region base: 0xbfbf8000, mask/settings: 0x6000
[2.091056] PCI host bridge to bus :00
[2.099131] pci_bus :00: root bus resource [mem 0x6000-0x6fff]
[2.112734] pci_bus :00: root bus resource [io 0x]
[2.124486] pci_bus :00: root bus resource [??? 0x flags 0x0]
[2.137962] pci_bus :00: No busn resource found for root bus, will use
[bus 00-ff]
[2.153766] pci :00:00.0: [0e8d:0801] type 01 class 0x060400
[2.165651] pci :00:00.0: reg 0x10: [mem 0x-0x7fff]
[2.178057] pci :00:00.0: reg 0x14: [mem 0x6010-0x6010]
[2.190585] pci :00:00.0: supports D1
[2.198439] pci :00:00.0: PME# supported from D0 D1 D3hot
[2.211463] random: fast init done
[2.211838] pci :01:00.0: [14c3:7615] type 00 class 0x000280
[2.230071] pci :01:00.0: reg 0x10: [mem 0x-0x000f 64bit]
[2.243675] pci :01:00.0: 2.000 Gb/s available PCIe bandwidth, limited
by 2.5 GT/s x1 link at :00:00.0 (capable of 4.000 Gb/s with 5 GT/s x1 link)
[2.272296] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01
[2.285339] pci_bus :00: busn_res: [bus 00-ff] end is updated to 01
[2.298493] pci :00:00.0: BAR 0: no space for [mem size 0x8000]
[2.311581] pci :00:00.0: BAR 0: failed to assign [mem size 0x8000]
[2.325410] pci :00:00.0: BAR 8: assigned [mem 0x6000-0x600f]
[2.33] pci :00:00.0: BAR 1: assigned [mem 0x6010-0x6010]
[2.352376] pci :01:00.0: BAR 0: assigned [mem 0x6000-0x600f
64bit]
[2.366887] pci :00:00.0: PCI bridge to [bus 01]
[2.376728] pci :00:00.0: bridge window [mem 0x6000-0x600f]
And this is on 5.4 with the new driver with pcie0 status=disabled:
[ 30.464407] mt7621-pci 1e14.pcie: GPIO lookup for consumer reset
[ 30.464415] mt7621-pci 1e14.pcie: using device tree for GPIO lookup
[ 30.464474] mt7621-pci 1e14.pcie: using lookup tables for GPIO lookup
[ 30.464484] mt7621-pci 1e14.pcie: No GPIO consumer reset found
[ 30.664239] mt7621-pci 1e14.pcie: pcie1 no card, disable it (RST & CLK)
[ 30.678128] mt7621-pci 1e14.pcie: Nothing is connected in virtual
bridges. Exiting...
booting goes on.
And with pcie status=enabled:
[ 32.415863] rt2880-pinmux pinctrl: pcie is already enabled
[ 32.426821] mt7621-pci 1e14.pcie: Error applying setting, reverse things
back
[ 32.441900] mt7621-pci-phy 1e149000.pcie-phy: PHY for 0xbe149000 (dual port
= 1)
[ 32.456880] mt7621-pci-phy 1e14a000.pcie-phy: PHY for 0xbe14a000 (dual port
= 0)
[ 32.571556] mt7621-pci-phy 1e149000.pcie-phy: Xtal is 40MHz
[ 32.582680] mt7621-pci-phy 1e14a000.pcie-phy: Xtal is 40MHz
[ 32.693592] mt7621-pci 1e14.pcie: pcie0 no card, disable it (RST & CLK)
hangs.
DTS Config:
mt7621.dtsi
pcie: pcie@1e14 {
compatible = "mediatek,mt7621-pci";
reg = <0x1e14 0x100 /* host-pci bridge registers */
0x1e142000 0x100/* pcie port 0 RC control registers
*/
0x1e143000 0x100/* pcie port 1 RC control registers
*/
0x1e144000 0x100>; /* pcie port 2 RC control registers
*/
#address-cells = <3>;
Re: [OpenWrt-Devel] [PATCH] ramips: use full 8MB flash on ZyXEL Keenetic
Hi,
> -Original Message-
> From: Alexey Dobrovolskiy [mailto:dobrovolskiy.ale...@gmail.com]
> Sent: Dienstag, 7. April 2020 20:51
> To: m...@adrianschmutzler.de
> Cc: openwrt-devel@lists.openwrt.org
> Subject: Re: [PATCH] ramips: use full 8MB flash on ZyXEL Keenetic
>
> Hi Adrian,
>
> thanks for you review.
>
> > But I still wonder how this device is now supported for almost three years
> now and nobody mentioned that so far?
> The problem has already been described in bugreport FS#2487 [1].
> So i should also add
> Fixes: FS#2487
Yes.
>
> > Do you have further evidence?
> WikiDevi page [2] says that ZyXEL Keenetic has FLA1: 8 MiB, there are some
> articles with specs [3], [4] (in Russian).
> I own this device and tested the patch before sending.
> I filed a bugreport FS#2964 [5] about another problem with ZyXEL Keenetic,
> there you may find bootlogs with this patch applied.
> If it is not enough, i can cite more internet forum posts about this problem.
> What of these should i add into commit description?
I'd add references [2] and [4] (the latter because of the nice pictures).
>
> > Despite, if this is merged, somebody should add
> >
> > Fixes: a7cbf59e0e04 ("ramips: add new device ZyXEL Keenetic as kn")
>
> I'll add.
Just add those pieces of information, resubmit and I will merge it.
Don't invest to much work in it, it's fine and I just wanted to have a little
bit more of evidence.
Best
Adrian
>
> [1] https://bugs.openwrt.org/index.php?do=details_id=2487
> [2] https://wikidevi.wi-cat.ru/ZyXEL_Keenetic
> [3] https://www.ixbt.com/comm/zyxel-keenetic.shtml
> [4] https://3dnews.ru/608774/page-2.html
> [5] https://bugs.openwrt.org/index.php?do=details_id=2964
>
> Best regards,
> Alexey
>
> пн, 6 апр. 2020 г. в 22:58, :
> >
> > Hi Alexey,
> >
> > this patch is obviously correct in its implementation.
> >
> > But I still wonder how this device is now supported for almost three years
> now and nobody mentioned that so far?
> >
> > Do you have further evidence?
> >
> > Interestingly, I just found that the initial support commit even mentions
> "Flash: 8 MiB". But this could also be an error in the commit message.
> >
> > Despite, if this is merged, somebody should add
> >
> > Fixes: a7cbf59e0e04 ("ramips: add new device ZyXEL Keenetic as kn")
> >
> > Best
> >
> > Adrian
> >
> > > -Original Message-
> > > From: Alexey Dobrovolsky [mailto:dobrovolskiy.ale...@gmail.com]
> > > Sent: Donnerstag, 26. März 2020 20:11
> > > To: m...@adrianschmutzler.de
> > > Cc: Alexey Dobrovolsky ; openwrt-
> > > de...@lists.openwrt.org
> > > Subject: [PATCH] ramips: use full 8MB flash on ZyXEL Keenetic
> > >
> > > ZyXEL Keenetic has 8MB flash, but OpenWrt uses only 4MB.
> > > This commit fixes the problem.
> > >
> > > Signed-off-by: Alexey Dobrovolsky
> > > ---
> > > target/linux/ramips/dts/rt3052_zyxel_keenetic.dts | 2 +-
> > > target/linux/ramips/image/rt305x.mk | 2 +-
> > > 2 files changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/target/linux/ramips/dts/rt3052_zyxel_keenetic.dts
> > > b/target/linux/ramips/dts/rt3052_zyxel_keenetic.dts
> > > index ad641f47e4..436743cff3 100644
> > > --- a/target/linux/ramips/dts/rt3052_zyxel_keenetic.dts
> > > +++ b/target/linux/ramips/dts/rt3052_zyxel_keenetic.dts
> > > @@ -48,7 +48,7 @@
> > > partition@5 {
> > > compatible = "denx,uimage";
> > > label = "firmware";
> > > - reg = <0x5 0x3b>;
> > > + reg = <0x5 0x7b>;
> > > };
> > > };
> > > };
> > > diff --git a/target/linux/ramips/image/rt305x.mk
> > > b/target/linux/ramips/image/rt305x.mk
> > > index 33f94edf3f..313c3fa315 100644
> > > --- a/target/linux/ramips/image/rt305x.mk
> > > +++ b/target/linux/ramips/image/rt305x.mk
> > > @@ -1149,7 +1149,7 @@ TARGET_DEVICES += zorlik_zl5900v2 define
> > > Device/zyxel_keenetic
> > >SOC := rt3052
> > >BLOCKSIZE := 64k
> > > - IMAGE_SIZE := 3776k
> > > + IMAGE_SIZE := 7872k
> > >DEVICE_VENDOR := ZyXEL
> > >DEVICE_MODEL := Keenetic
> > >DEVICE_PACKAGES := kmod-usb2 kmod-usb-ehci kmod-usb-ledtrig-
> > > usbport
> > > --
> > > 2.17.1
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: use full 8MB flash on ZyXEL Keenetic
Hi Adrian,
thanks for you review.
> But I still wonder how this device is now supported for almost three years
> now and nobody mentioned that so far?
The problem has already been described in bugreport FS#2487 [1].
So i should also add
Fixes: FS#2487
> Do you have further evidence?
WikiDevi page [2] says that ZyXEL Keenetic has FLA1: 8 MiB, there are
some articles with specs [3], [4] (in Russian).
I own this device and tested the patch before sending.
I filed a bugreport FS#2964 [5] about another problem with ZyXEL
Keenetic, there you may find bootlogs with this patch applied.
If it is not enough, i can cite more internet forum posts about this problem.
What of these should i add into commit description?
> Despite, if this is merged, somebody should add
>
> Fixes: a7cbf59e0e04 ("ramips: add new device ZyXEL Keenetic as kn")
I'll add.
[1] https://bugs.openwrt.org/index.php?do=details_id=2487
[2] https://wikidevi.wi-cat.ru/ZyXEL_Keenetic
[3] https://www.ixbt.com/comm/zyxel-keenetic.shtml
[4] https://3dnews.ru/608774/page-2.html
[5] https://bugs.openwrt.org/index.php?do=details_id=2964
Best regards,
Alexey
пн, 6 апр. 2020 г. в 22:58, :
>
> Hi Alexey,
>
> this patch is obviously correct in its implementation.
>
> But I still wonder how this device is now supported for almost three years
> now and nobody mentioned that so far?
>
> Do you have further evidence?
>
> Interestingly, I just found that the initial support commit even mentions
> "Flash: 8 MiB". But this could also be an error in the commit message.
>
> Despite, if this is merged, somebody should add
>
> Fixes: a7cbf59e0e04 ("ramips: add new device ZyXEL Keenetic as kn")
>
> Best
>
> Adrian
>
> > -Original Message-
> > From: Alexey Dobrovolsky [mailto:dobrovolskiy.ale...@gmail.com]
> > Sent: Donnerstag, 26. März 2020 20:11
> > To: m...@adrianschmutzler.de
> > Cc: Alexey Dobrovolsky ; openwrt-
> > de...@lists.openwrt.org
> > Subject: [PATCH] ramips: use full 8MB flash on ZyXEL Keenetic
> >
> > ZyXEL Keenetic has 8MB flash, but OpenWrt uses only 4MB.
> > This commit fixes the problem.
> >
> > Signed-off-by: Alexey Dobrovolsky
> > ---
> > target/linux/ramips/dts/rt3052_zyxel_keenetic.dts | 2 +-
> > target/linux/ramips/image/rt305x.mk | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/target/linux/ramips/dts/rt3052_zyxel_keenetic.dts
> > b/target/linux/ramips/dts/rt3052_zyxel_keenetic.dts
> > index ad641f47e4..436743cff3 100644
> > --- a/target/linux/ramips/dts/rt3052_zyxel_keenetic.dts
> > +++ b/target/linux/ramips/dts/rt3052_zyxel_keenetic.dts
> > @@ -48,7 +48,7 @@
> > partition@5 {
> > compatible = "denx,uimage";
> > label = "firmware";
> > - reg = <0x5 0x3b>;
> > + reg = <0x5 0x7b>;
> > };
> > };
> > };
> > diff --git a/target/linux/ramips/image/rt305x.mk
> > b/target/linux/ramips/image/rt305x.mk
> > index 33f94edf3f..313c3fa315 100644
> > --- a/target/linux/ramips/image/rt305x.mk
> > +++ b/target/linux/ramips/image/rt305x.mk
> > @@ -1149,7 +1149,7 @@ TARGET_DEVICES += zorlik_zl5900v2 define
> > Device/zyxel_keenetic
> >SOC := rt3052
> >BLOCKSIZE := 64k
> > - IMAGE_SIZE := 3776k
> > + IMAGE_SIZE := 7872k
> >DEVICE_VENDOR := ZyXEL
> >DEVICE_MODEL := Keenetic
> >DEVICE_PACKAGES := kmod-usb2 kmod-usb-ehci kmod-usb-ledtrig-
> > usbport
> > --
> > 2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Am 07.04.20 um 12:16 schrieb Chuanhong Guo: > [CC Sergio who worked on upstream PCIE driver] > > On Tue, Apr 7, 2020 at 4:45 PM Andre Valentin wrote: >> >> Hi! >> >> Currently I'm having some serious problems with the new 5.4 port. >> 1) PCIe >> I'm developing on the ZyXEL LTE3301-PLUS. It has PCIe and a mt7615e >> connected to second bus on the first phy. >> If booting the device, kernel hangs with a RST message, telling the device >> is not detected. It seems the PCIe bus 1 >> cannot be reseted because nothing is connected to bus 0. >> An upport of the old PCI driver reenables the function. I can provide more >> logs on this if needed. > > Hi Sergio: > You may want to look into this. > >> 2) DSA >> These are my first experiments with DSA. I've configured 2 bridges: >> lan: lan1 lan2 lan3 lan4 >> dmz: lan1.20 lan2.20 lan3.20 lan4.20 >> >> Inbound traffic on vlan 20 is comming in, outgoing traffic passes the lan1 >> port but does note arrive at the other end. >> >> Should this work with DSA on mediathek? > > It's supposed to work so this may be yet another bug upstream. > >> If not, I can offer that I write a patch for traditional swconfig. > > swconfig is considered deprecated so there's no need to do so. > In fact, this driver under mediatek target also works for mt7621: > target/linux/mediatek/files-5.4/drivers/net/phy/mtk/mt753x > I already took some patches from there. I'll gonna check if a replacement makes a difference. Kind regards, André smime.p7s Description: S/MIME Cryptographic Signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Hi! Am 07.04.20 um 17:49 schrieb Bjørn Mork: > Just remembered an issue on my todo list: There have been some MTU > handling changes in the kernel networking API. This affected the > qmi_wwan QMAP handling. I am not sure about the current status. Will > have to dig a bit more. But this might be your problem. Thank you very much for taking a look! André ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Hi, On Tue, Apr 7, 2020 at 12:16 PM Chuanhong Guo wrote: > > [CC Sergio who worked on upstream PCIE driver] > > On Tue, Apr 7, 2020 at 4:45 PM Andre Valentin wrote: > > > > Hi! > > > > Currently I'm having some serious problems with the new 5.4 port. > > 1) PCIe > > I'm developing on the ZyXEL LTE3301-PLUS. It has PCIe and a mt7615e > > connected to second bus on the first phy. > > If booting the device, kernel hangs with a RST message, telling the device > > is not detected. It seems the PCIe bus 1 > > cannot be reseted because nothing is connected to bus 0. > > An upport of the old PCI driver reenables the function. I can provide more > > logs on this if needed. Logs and dmesg traces are always welcome and would be helpful. Both working and not working traces. > > Hi Sergio: > You may want to look into this. > > > 2) DSA > > These are my first experiments with DSA. I've configured 2 bridges: > > lan: lan1 lan2 lan3 lan4 > > dmz: lan1.20 lan2.20 lan3.20 lan4.20 > > > > Inbound traffic on vlan 20 is comming in, outgoing traffic passes the lan1 > > port but does note arrive at the other end. > > > > Should this work with DSA on mediathek? > > It's supposed to work so this may be yet another bug upstream. > > > If not, I can offer that I write a patch for traditional swconfig. > > swconfig is considered deprecated so there's no need to do so. > In fact, this driver under mediatek target also works for mt7621: > target/linux/mediatek/files-5.4/drivers/net/phy/mtk/mt753x > > -- > Regards, > Chuanhong Guo Best regards, Sergio Paracuellos ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] ramips mt76x8: bug: mtk_soc_eth 10100000.ethernet eth0: transmit timed out
Hi, since a few days I get following Kernel Oops. The Omega2+ board doesn't get any ethernet connection. Any hints ? [0.00] Linux version 4.14.172 (gerd@nizza) (gcc version 8.4.0 (OpenWrt GCC 8.4.0 r12649-ecef29b294)) #0 PREEMPT Mon Apr 6 18:42:45 2020 [0.00] Board has DDR2 [0.00] Analog PMU set to hw control [0.00] Digital PMU set to hw control [0.00] SoC Type: MediaTek MT7688 ver:1 eco:2 [0.00] bootconsole [early0] enabled [0.00] CPU0 revision is: 00019655 (MIPS 24KEc) [0.00] MIPS: machine is Onion Omega2+ [ 32.260721] rt3050-esw 1011.esw: link changed 0x00 [ 36.387574] rt3050-esw 1011.esw: link changed 0x01 [ 36.750035] br-lan: port 1(eth0) entered blocking state [ 36.755353] br-lan: port 1(eth0) entered disabled state [ 36.780959] device eth0 entered promiscuous mode [ 36.818338] br-lan: port 1(eth0) entered blocking state [ 36.823656] br-lan: port 1(eth0) entered forwarding state [ 36.883276] IPv6: ADDRCONF(NETDEV_UP): br-lan: link is not ready [ 37.786743] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready [ 47.146685] [ cut here ] [ 47.151416] WARNING: CPU: 0 PID: 1494 at net/sched/sch_generic.c:320 dev_watchdog+0x1ac/0x2e8 [ 47.160090] NETDEV WATCHDOG: eth0 (mtk_soc_eth): transmit queue 0 timed out [ 47.167164] Modules linked in: pppoe ppp_async pppox ppp_generic pl2303 nf_conntrack_ipv6 mt7603e mt76 mac80211 iptable_nat ipt_REJECT ipt_MASQUERADE ftdi_sio cp210x c h341 cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_FLOWOFFLOAD usbserial usbmon slhc slcan nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_defrag_ipv6 nf_defrag_ ipv4 nf_conntrack_rtcache nf_conntrack iptable_mangle iptable_filter ip_tables crc_ccitt compat can_raw can_gw can_dev can ledtrig_oneshot ledtrig_heartbeat ledtrig_gpio nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 nfsv4 nfsv3 nfs msdos vfat [ 47.239021] fat ntfs lockd sunrpc grace dns_resolver nls_utf8 nls_iso8859_1 nls_cp437 mmc_block mtk_sd mmc_core leds_gpio ohci_platform ohci_hcd ledtrig_transient ehc i_platform ehci_hcd gpio_button_hotplug reiserfs ext4 mbcache jbd2 usbcore nls_base usb_common crc16 crc32c_generic crypto_hash [ 47.265490] CPU: 0 PID: 1494 Comm: sh Not tainted 4.14.172 #0 [ 47.271325] Stack : 8050 804aeb0c 80486490 87c07e14 87d69a04 804d9967 [ 47.279825] 80482428 05d6 80633660 0140 87c1f800 0001 87c07dc8 5a9508c0 [ 47.288329] 8063 80637d78 00e6 0007 [ 47.296831] 00040d12 8000 0009 802f0bd8 [ 47.305321] 804a8da4 0140 87c1f800 0200 8024d408 8063 [ 47.313819] ... [ 47.316309] Call Trace: [ 47.318823] [<8000b004>] show_stack+0x58/0x100 [ 47.323337] [<80027e0c>] __warn+0xe4/0x148 [ 47.327505] [<80027a54>] warn_slowpath_fmt+0x30/0x3c [ 47.332548] [<802f0bd8>] dev_watchdog+0x1ac/0x2e8 [ 47.337348] [<8006f7f0>] call_timer_fn.isra.29+0x24/0x84 [ 47.342739] [<8006fa38>] run_timer_softirq+0x1e8/0x294 [ 47.347985] [<803efb80>] __do_softirq+0xe8/0x2b4 [ 47.352676] [<8002b404>] irq_exit+0x88/0xe0 [ 47.356936] [<80006090>] except_vec_vi_end+0xb8/0xc4 [ 47.361971] ---[ end trace 5b34084e49d21194 ]--- [ 47.366674] mtk_soc_eth 1010.ethernet eth0: transmit timed out [ 47.372944] mtk_soc_eth 1010.ethernet eth0: dma_cfg:0057 [ 47.379056] mtk_soc_eth 1010.ethernet eth0: tx_ring=0, base=06db4000, max=1024, ctx=2, dtx=0, fdx=0, next=2 [ 47.389309] mtk_soc_eth 1010.ethernet eth0: rx_ring=0, base=06e0, max=1024, calc=23, drx=26 [ 48.566897] jffs2_scan_eraseblock(): End of filesystem marker found at 0x0 [ 48.573914] jffs2_build_filesystem(): unlocking the mtd device... [ 48.573919] done. [ 48.594224] jffs2_build_filesystem(): erasing all blocks after the end marker... [ 59.386631] mtk_soc_eth 1010.ethernet eth0: transmit timed out [ 59.400512] mtk_soc_eth 1010.ethernet eth0: dma_cfg:0057 [ 59.406636] mtk_soc_eth 1010.ethernet eth0: tx_ring=0, base=06ff4000, max=1024, ctx=1, dtx=0, fdx=0, next=1 [ 59.416888] mtk_soc_eth 1010.ethernet eth0: rx_ring=0, base=06008000, max=1024, calc=26, drx=27 [ 70.106634] mtk_soc_eth 1010.ethernet eth0: transmit timed out ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Just remembered an issue on my todo list: There have been some MTU handling changes in the kernel networking API. This affected the qmi_wwan QMAP handling. I am not sure about the current status. Will have to dig a bit more. But this might be your problem. Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Andre Valentin writes:
>> Is your modem connected by USB3 or USB2? Any of
>
> The modem is an integrated USB3 LTE modem. As said, without qmap it
> works stable.
ah, missed that important point.
There were a few qmap fixes between v4.14 and v5.4, but I guess we can
rule out those since you have the same issues with the v4.14 driver on
v5.4.
I must admit I am totally blank here. I haven't actually tested the
qmap features much yet. It is completely integrated in qmi_wwan. But
there is also a separate implementation from Qualcomm in
drivers/net/ethernet/qualcomm/rmnet . Which I haven't tried at all...
Are you using the QMAP implementation in qmi_wwan? That's the one with
the /sys/class/net/wwan0/qmi/{add,del}_mux ABI.
Bjørn
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Is it possible to create two images for the same device with a different set of DEVICE_PACKAGES?
Hi Bjørn. W dniu 07.04.2020 o 16:50, Bjørn Mork pisze: > Hannu Nyman writes: > >> I do not think that there is a nice clean solution, as I do not >> remember seeing a solution of different packages for iniramfs, factory >> and sysupgrade images. >> >> I would approach that with a two-step build process, using two .config >> recipes: >> >> * First a build with a smaller .config recipe without that large >> Quantenna firmware. This creates the initramfs image, (which you copy >> to a safe place before the second build) >> >> * Then a second build from a recipe including the Quantenna >> firmware. No need to do "make clean", so the second build is rather >> quick. That produces the full sysupgrade image. >> >> In your build automation scripts, those two builds could be run >> consequtively, with a copy step between them. >> >> That will be much easier than trying to code a logic into the actual >> OpenWrt build Makefiles. > > Yes, sure, this will work for my own use. But it doesn't solve the > general problem, with pre-built images involved. > > What if I want to make a recipe that works on the OpenWrt Buildbots? > The idea was to make first time installation as easy as possible, by > providing both an image that can be installed from OEM and an image that > enables the full hardware. > > I did come up with a sort of working proof-of-concept hack, where I add > a build rule like (yes, ugly - I'm not excpecting to push this): > > define Build/filtered-initramfs > rm -rf $(TARGET_DIR).x > sed -i -e 's,CONFIG_INITRAMFS_SOURCE="$(strip $(TARGET_DIR)) > ,CONFIG_INITRAMFS_SOURCE="$(strip $(TARGET_DIR)).x ,' $(LINUX_DIR)/.config > cp -a $(TARGET_DIR) $(TARGET_DIR).x > rm -rf $(TARGET_DIR).x/lib/firmware/qv840 > $(TARGET_DIR).x/usr/lib/opkg/info/qv840-firmware.* > $(call Image/BuildKernel/Initramfs) > endef > > > I was just hoping there would be nicer ways to do it. In include/kernel-defaults.mk there is INITRAMFS_EXTRA_FILES ?= $(GENERIC_PLATFORM_DIR)/image/initramfs-base-files.txt. Maybe You could add a logic for ignore files list if they exist. No other solution comes to my mind. > > > > > Bjørn > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > -- TMN ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Hi! Am 07.04.20 um 16:33 schrieb Bjørn Mork: > Andre Valentin writes: > >> 3) Problems with QMI Interfaces >> QMI is used for mobile phones and interact with the qmi_wwan driver in the >> kernel. I had transmit issues, >> switched the driver back to the 4.14 while still on 5.4. But the same >> problem happens again. >> Under 4.14 this was not a problem. So it seems 5.4 or the SOC patches >> somehow are the root cause. >> Here's the kernel message: >> >> >> [ 4199.444191] [ cut here ] >> [ 4199.453534] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:447 >> dev_watchdog+0x2f8/0x300 >> [ 4199.470074] NETDEV WATCHDOG: wwan0 (qmi_wwan): transmit queue 0 timed out > > And this is not just an occasional timeout? The driver hangs completely > there? It hangs, no more packets are transmitted over network, > > I don't think there were many qmi_wwan changes between v4.14 and v5.4, > except for device additions and some fixes which mostly have been > backported to v4.14-stable. But maybe this is related to your specific > modem? Do you have a device ID for that? The funny thing is, that if I remove all changes from 5.4 qmi_wwan.c and set it back to the 4.14 driver, the same happens again. Perhaps the problem is in the muxing code? Is that outside of qmi_wwan.c ? Only if I disable qmap and use the wwan0 device with only one PDF, it seems to be stable over days. The device is a: Bus 002 Device 002: ID 2c7c:0306 Quectel Wireless Solutions Co., Ltd. EG06/EP06/EM06 LTE-A modem > Do we know that USB is working on v5.4 BTW? The MT7621 device I am > using doesn't have any USB ports, so I can't check that myself. > > Is your modem connected by USB3 or USB2? Any of The modem is an integrated USB3 LTE modem. As said, without qmap it works stable. > > lsusb -v -- Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 3.00 bDeviceClass9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 3 bMaxPacketSize0 9 idVendor 0x1d6b Linux Foundation idProduct 0x0003 3.0 root hub bcdDevice5.04 iManufacturer 3 Linux 5.4.28 vhci_hcd iProduct2 USB/IP Virtual Host Controller iSerial 1 vhci_hcd.0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 31 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 12 bMaxBurst 0 Hub Descriptor: bLength 12 bDescriptorType 42 nNbrPorts 8 wHubCharacteristic 0x0001 Per-port power switching Ganged overcurrent protection bPwrOn2PwrGood0 * 2 milli seconds bHubContrCurrent 0 milli Ampere bHubDecLat 0.4 micro seconds wHubDelay 4 nano seconds DeviceRemovable0xff 0xff Hub Port Status: Port 1: .0200 5Gbps power U0 Port 2: .0200 5Gbps power U0 Port 3: .0200 5Gbps power U0 Port 4: .0200 5Gbps power U0 Port 5: .0200 5Gbps power U0 Port 6: .0200 5Gbps power U0 Port 7: .0200 5Gbps power U0 Port 8: .0200 5Gbps power U0 Binary Object Store Descriptor: bLength 5 bDescriptorType15 wTotalLength 15 bNumDeviceCaps 1 SuperSpeed USB Device Capability: bLength10 bDescriptorType16 bDevCapabilityType 3 bmAttributes 0x00 wSpeedsSupported 0x0008 Device can operate at SuperSpeed (5Gbps) bFunctionalitySupport 3 Lowest fully-functional device speed is SuperSpeed (5Gbps) bU1DevExitLat 0 micro seconds bU2DevExitLat 0 micro seconds Device Status: 0x0001 Self Powered Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass9 Hub bDeviceSubClass
Re: [OpenWrt-Devel] Is it possible to create two images for the same device with a different set of DEVICE_PACKAGES?
Hannu Nyman writes: > I do not think that there is a nice clean solution, as I do not > remember seeing a solution of different packages for iniramfs, factory > and sysupgrade images. > > I would approach that with a two-step build process, using two .config > recipes: > > * First a build with a smaller .config recipe without that large > Quantenna firmware. This creates the initramfs image, (which you copy > to a safe place before the second build) > > * Then a second build from a recipe including the Quantenna > firmware. No need to do "make clean", so the second build is rather > quick. That produces the full sysupgrade image. > > In your build automation scripts, those two builds could be run > consequtively, with a copy step between them. > > That will be much easier than trying to code a logic into the actual > OpenWrt build Makefiles. Yes, sure, this will work for my own use. But it doesn't solve the general problem, with pre-built images involved. What if I want to make a recipe that works on the OpenWrt Buildbots? The idea was to make first time installation as easy as possible, by providing both an image that can be installed from OEM and an image that enables the full hardware. I did come up with a sort of working proof-of-concept hack, where I add a build rule like (yes, ugly - I'm not excpecting to push this): define Build/filtered-initramfs rm -rf $(TARGET_DIR).x sed -i -e 's,CONFIG_INITRAMFS_SOURCE="$(strip $(TARGET_DIR)) ,CONFIG_INITRAMFS_SOURCE="$(strip $(TARGET_DIR)).x ,' $(LINUX_DIR)/.config cp -a $(TARGET_DIR) $(TARGET_DIR).x rm -rf $(TARGET_DIR).x/lib/firmware/qv840 $(TARGET_DIR).x/usr/lib/opkg/info/qv840-firmware.* $(call Image/BuildKernel/Initramfs) endef I was just hoping there would be nicer ways to do it. Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Andre Valentin writes: > 3) Problems with QMI Interfaces > QMI is used for mobile phones and interact with the qmi_wwan driver in the > kernel. I had transmit issues, > switched the driver back to the 4.14 while still on 5.4. But the same problem > happens again. > Under 4.14 this was not a problem. So it seems 5.4 or the SOC patches somehow > are the root cause. > Here's the kernel message: > > > [ 4199.444191] [ cut here ] > [ 4199.453534] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:447 > dev_watchdog+0x2f8/0x300 > [ 4199.470074] NETDEV WATCHDOG: wwan0 (qmi_wwan): transmit queue 0 timed out And this is not just an occasional timeout? The driver hangs completely there? I don't think there were many qmi_wwan changes between v4.14 and v5.4, except for device additions and some fixes which mostly have been backported to v4.14-stable. But maybe this is related to your specific modem? Do you have a device ID for that? Do we know that USB is working on v5.4 BTW? The MT7621 device I am using doesn't have any USB ports, so I can't check that myself. Is your modem connected by USB3 or USB2? Any of lsusb -v cat /sys/kernel/debug/usb/devices grep . /sys/bus/usb/devices/*/version will tell. You'll have to match up the latter with the device if you have more than one USB device connected. Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Is it possible to create two images for the same device with a different set of DEVICE_PACKAGES?
I do not think that there is a nice clean solution, as I do not remember seeing a solution of different packages for iniramfs, factory and sysupgrade images. I would approach that with a two-step build process, using two .config recipes: * First a build with a smaller .config recipe without that large Quantenna firmware. This creates the initramfs image, (which you copy to a safe place before the second build) * Then a second build from a recipe including the Quantenna firmware. No need to do "make clean", so the second build is rather quick. That produces the full sysupgrade image. In your build automation scripts, those two builds could be run consequtively, with a copy step between them. That will be much easier than trying to code a logic into the actual OpenWrt build Makefiles. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] bcm53xx: add support for Luxul FullMAC WiFi devices
On 07.04.2020 01:14, Dan Haab wrote: @@ -87,20 +96,28 @@ bcm53xx_setup_macs() case "$board" in asus,rt-ac87u) etXmacaddr=$(nvram get et1macaddr) + offset=1 ;; dlink,dir-885l | \ netgear,r7900 | \ netgear,r8000 | \ netgear,r8500) etXmacaddr=$(nvram get et2macaddr) + offset=1 + ;; + luxul,xwr-3100v1 | \ + luxul,xwr-3150-v1) + etXmacaddr=$(nvram get et0macaddr) + offset=5 ;; *) etXmacaddr=$(nvram get et0macaddr) + offset=1 ;; esac This seems like a bit of code duplication but nothing too scary at this point I believe. We can refactor if if it gets worse. Thanks! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Is it possible to create two images for the same device with a different set of DEVICE_PACKAGES?
The device I am playing with (ZyXEL WAP6805) can be upgraded to OpenWrt by tftp'ing an OpenWrt initramfs image to it. But the image *must* be less than 6815744 bytes, which is a hard coded limit in the OEM tftp server. The device also includes a Quantenna module, which needs a rather large firmware image (4 MB or more). I want to include this firmware in the OpenWrt sysupgrade images, to enable as much hardware support as possible by default. But if I include the Quantenna firmware in DEVICE_PACKAGES, then the initramfs image becomes too large to be installed from OEM firmware. Is there any way to work around this? I have been looking at the magic of image.mk and friends for hours now, without seeing any obvious and clean solution. It would be nice if it was possible to build a separate rootfs with an explicit short package list, overriding the .config for special purpose, size restricted, images. Anyone have pointers to docs or relevant examples? Or maybe some "don't do that" advice? I have a sneaky feeling I am looking at this from the wrong side or something... Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v4] mvebu: add support for Buffalo LinkStation LS421DE
Buffalo LinkStation LS421DE is a dual bay NAS, based on Marvell Armada 370
Hardware:
SoC: Marvell Armada 88F6707-A1
CPU: Cortex-A9 1200 MHz, 1 core
Flash: SPI-NOR 1 MiB, NAND 512 MiB
RAM: DDR3 512 MiB
Ethernet:1x 10/100/1000 Mbps
USB: 1x 2.0, 1x 3.0
SATA:2x 3.0 Gbps
LEDs/Input : 5x / 2x (1x button, 1x slide-switch)
RTC: Ricoh RS5C372A, I2C, no battery
Flash instruction (UART+TFTP):
1. Downgrade the OEM firmware to 1.34 version (BUFFALO_BOOTVER=0.13)
2. Remove any hard drive from inside the bays.
3. Boot the Openwrt initramfs image using the U-Boot serial console:
tftpboot 0x120 buffalo_ls421de-initramfs-kernel.bin
bootm 0x120
4. Flash the sysupgrade image using the Openwrt console:
sysupgrade -n buffalo_ls421de-squashfs-sysupgrade.bin
5. Wait until it finish, the device will reboot with Openwrt installed
on the NAND flash.
Note:
- Device shuting down doesn't work, even if the power slide switch is
used. We must first, via MDIO, set the unused LED2 at the ethernet
phy0 to off state. Reboot works ok.
Signed-off-by: Daniel González Cabanelas
Reviewed-by: Tomasz Maciej Nowak
---
Changes in v2:
- dts file tuned
- Adjusted the i2c bus speed to the max supported by the RTC
- Deleted unneded kernel patch
- Image creation: only included neccesary packages, delete the ubinize
parameter
Changes in v3:
- dts file tuned
- Adjusted the i2c bus speed to the max supported by the SoC
- Added vdd cpu power down pinmux
- Image creation: adjusted the packages required by this device.
Deleted redundant parameters.
- Fixed installation instructions
Changes in v4:
- Commit log: Added reviewer info
.../base-files/lib/preinit/06_set_iface_mac | 4 +
.../base-files/lib/upgrade/platform.sh| 3 +
.../boot/dts/armada-370-buffalo-ls421de.dts | 360 ++
target/linux/mvebu/image/Makefile | 14 +
target/linux/mvebu/image/cortexa9.mk | 16 +
5 files changed, 397 insertions(+)
create mode 100644
target/linux/mvebu/files-4.19/arch/arm/boot/dts/armada-370-buffalo-ls421de.dts
diff --git
a/target/linux/mvebu/cortexa9/base-files/lib/preinit/06_set_iface_mac
b/target/linux/mvebu/cortexa9/base-files/lib/preinit/06_set_iface_mac
index fd41836c8d..62ce2653a0 100644
--- a/target/linux/mvebu/cortexa9/base-files/lib/preinit/06_set_iface_mac
+++ b/target/linux/mvebu/cortexa9/base-files/lib/preinit/06_set_iface_mac
@@ -9,6 +9,10 @@ preinit_set_mac_address() {
. /lib/functions.sh
case $(board_name) in
+ buffalo,ls421de)
+ mac=$(mtd_get_mac_ascii u-boot-env eth1addr)
+ ip link set dev eth0 address $mac 2>/dev/null
+ ;;
linksys,caiman|linksys,cobra|linksys,rango|linksys,shelby|linksys,venom)
# rename interfaces back to the way they were with 4.4
case "$(readlink /sys/class/net/eth0)" in
diff --git a/target/linux/mvebu/cortexa9/base-files/lib/upgrade/platform.sh
b/target/linux/mvebu/cortexa9/base-files/lib/upgrade/platform.sh
index 8baed969a3..63042b1535 100755
--- a/target/linux/mvebu/cortexa9/base-files/lib/upgrade/platform.sh
+++ b/target/linux/mvebu/cortexa9/base-files/lib/upgrade/platform.sh
@@ -22,6 +22,9 @@ platform_check_image() {
platform_do_upgrade() {
case "$(board_name)" in
+ buffalo,ls421de)
+ nand_do_upgrade "$1"
+ ;;
cznic,turris-omnia|\
solidrun,clearfog-base-a1|\
solidrun,clearfog-pro-a1)
diff --git
a/target/linux/mvebu/files-4.19/arch/arm/boot/dts/armada-370-buffalo-ls421de.dts
b/target/linux/mvebu/files-4.19/arch/arm/boot/dts/armada-370-buffalo-ls421de.dts
new file mode 100644
index 00..6b8a964ab3
--- /dev/null
+++
b/target/linux/mvebu/files-4.19/arch/arm/boot/dts/armada-370-buffalo-ls421de.dts
@@ -0,0 +1,360 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree file for Buffalo LinkStation LS421DE
+ *
+ * Copyright (C) 2020 Daniel González Cabanelas
+ */
+
+/dts-v1/;
+
+#include "armada-370.dtsi"
+#include "mvebu-linkstation-fan.dtsi"
+#include
+#include
+
+/ {
+ model = "Buffalo LinkStation LS421DE";
+ compatible = "buffalo,ls421de", "marvell,armada370",
"marvell,armada-370-xp";
+
+ aliases {
+ led-boot = _boot;
+ led-failsafe = _failsafe;
+ led-running = _power;
+ led-upgrade = _upgrade;
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,115200 earlyprintk noinitrd
rootfstype=squashfs";
+ stdout-path = "serial0:115200n8";
+ append-rootblock = "nullparameter="; /* override the bootloader
args */
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x2000>; /* 512 MB */
+ };
+
+ soc {
+ ranges = ;
+
[OpenWrt-Devel] [PATCH] base-files: add enabled commands to service rc.common
Add missing enbaled command help output. Signed-off-by: Florian Eckert --- package/base-files/Makefile| 2 +- package/base-files/files/etc/rc.common | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/package/base-files/Makefile b/package/base-files/Makefile index 107d53e74f..8e252153fe 100644 --- a/package/base-files/Makefile +++ b/package/base-files/Makefile @@ -12,7 +12,7 @@ include $(INCLUDE_DIR)/version.mk include $(INCLUDE_DIR)/feeds.mk PKG_NAME:=base-files -PKG_RELEASE:=214 +PKG_RELEASE:=215 PKG_FLAGS:=nonshared PKG_FILE_DEPENDS:=$(PLATFORM_DIR)/ $(GENERIC_PLATFORM_DIR)/base-files/ diff --git a/package/base-files/files/etc/rc.common b/package/base-files/files/etc/rc.common index dbe26ec3bd..7c11544405 100755 --- a/package/base-files/files/etc/rc.common +++ b/package/base-files/files/etc/rc.common @@ -73,6 +73,7 @@ Available commands: reload Reload configuration files (or restart if service does not implement reload) enable Enable service autostart disable Disable service autostart + enabled Check if service is started on boot $EXTRA_HELP EOF } -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/6] build: update scritps/config to kconfig-v5.6
Eneas Queiroz [2020-04-07 08:20:44]: > I'm in the dark here with exactly what went wrong I've made the build step more verbose[1]: make[2]: Entering directory '/builds/ynezz/openwrt/scripts/config' cc -O2-c -o conf.o conf.c cc -O2-c -o confdata.o confdata.c cc -O2-c -o expr.o expr.c bison -l -d -b parser parser.y make[2]: bison: Command not found Makefile:95: recipe for target 'parser.tab.h' failed > but I've caught an oversight on my part: Linux now requires flex & bison > to build files that it used to ship prebuilt. I can either restore the > previous behavior, or we can require them as well, and then I'll add a check > for them--and later perhaps remove them from tools/? What do you think? I think, that this additional dependencies doesn't make much sense if it was working for years without those. I would prefer to ship preprocessed files instead, if that would work just fine. 1. https://gitlab.com/ynezz/openwrt/-/jobs/501743309 -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/6] build: update scritps/config to kconfig-v5.6
On Tue, Apr 7, 2020 at 5:19 AM Petr Štetiar wrote: > > Eneas U de Queiroz [2020-04-06 17:10:30]: > > Hi, > > > TLDR: You can't review this by only looking at the patches. > > Just tried to build[1] test it on x86/64 sunxi/a53 imx6 ipq40xx and it fails > to build: > > make -s -C scripts/config conf CC=cc: build failed. > > 1. https://gitlab.com/ynezz/openwrt/pipelines/133543034 > > -- ynezz Thanks for trying to test this. I'm in the dark here with exactly what went wrong, but I've caught an oversight on my part: Linux now requires flex & bison to build files that it used to ship prebuilt. I can either restore the previous behavior, or we can require them as well, and then I'll add a check for them--and later perhaps remove them from tools/? What do you think? BTW, here's the output of that make subcommand if you take out '-s' in include/toplevel.mk:107: cc -O2 -c -o conf.o conf.c cc -O2 -c -o confdata.o confdata.c cc -O2 -c -o expr.o expr.c bison -l -d -b parser parser.y flex -L -olexer.lex.c lexer.l cc -O2 -I ./. -c -o lexer.lex.o lexer.lex.c cc -O2 -I ./. -c -o parser.tab.o parser.tab.c cc -O2 -c -o preprocess.o preprocess.c cc -O2 -c -o symbol.o symbol.c cc -O2 -c -o util.o util.c cc conf.o confdata.o expr.o lexer.lex.o parser.tab.o preprocess.o symbol.o util.o -o conf rm lexer.lex.c That's why I assume it's missing bison & flex. Eneas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ramips/mt7621 after 5.4 switch
[CC Sergio who worked on upstream PCIE driver] On Tue, Apr 7, 2020 at 4:45 PM Andre Valentin wrote: > > Hi! > > Currently I'm having some serious problems with the new 5.4 port. > 1) PCIe > I'm developing on the ZyXEL LTE3301-PLUS. It has PCIe and a mt7615e connected > to second bus on the first phy. > If booting the device, kernel hangs with a RST message, telling the device is > not detected. It seems the PCIe bus 1 > cannot be reseted because nothing is connected to bus 0. > An upport of the old PCI driver reenables the function. I can provide more > logs on this if needed. Hi Sergio: You may want to look into this. > 2) DSA > These are my first experiments with DSA. I've configured 2 bridges: > lan: lan1 lan2 lan3 lan4 > dmz: lan1.20 lan2.20 lan3.20 lan4.20 > > Inbound traffic on vlan 20 is comming in, outgoing traffic passes the lan1 > port but does note arrive at the other end. > > Should this work with DSA on mediathek? It's supposed to work so this may be yet another bug upstream. > If not, I can offer that I write a patch for traditional swconfig. swconfig is considered deprecated so there's no need to do so. In fact, this driver under mediatek target also works for mt7621: target/linux/mediatek/files-5.4/drivers/net/phy/mtk/mt753x -- Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ramips: mt7621: tidy up names for Ubiquiti devices
The "proper" vendor prefix for Ubiquiti is "ubnt", this is used in
all targets except ramips and also recommended by the kernel.
This patch adjusts the various board/image/device name variables
accordingly. Since we touch it anyway, this also adds the space
in "EdgeRouter X" as a hyphen to those variables to really make
them consistent with the model name.
While at it, create a real shared definition for the devices in
image/mt7621.mk instead of deriving one device from another.
Signed-off-by: Adrian Schmutzler
---
.../dts/mt7621_ubiquiti_edgerouterx-sfp.dts | 17 --
.../dts/mt7621_ubiquiti_edgerouterx.dts | 8 ---
.../dts/mt7621_ubnt_edgerouter-x-sfp.dts | 17 ++
.../ramips/dts/mt7621_ubnt_edgerouter-x.dts | 8 +++
...erx.dtsi => mt7621_ubnt_edgerouter-x.dtsi} | 0
target/linux/ramips/image/mt7621.mk | 23 +++
.../mt7621/base-files/etc/board.d/02_network | 4 ++--
.../base-files/etc/board.d/03_gpio_switches | 4 ++--
.../lib/preinit/07_mt7621_bringup_dsa_master | 4 ++--
.../mt7621/base-files/lib/upgrade/platform.sh | 4 ++--
10 files changed, 46 insertions(+), 43 deletions(-)
delete mode 100644 target/linux/ramips/dts/mt7621_ubiquiti_edgerouterx-sfp.dts
delete mode 100644 target/linux/ramips/dts/mt7621_ubiquiti_edgerouterx.dts
create mode 100644 target/linux/ramips/dts/mt7621_ubnt_edgerouter-x-sfp.dts
create mode 100644 target/linux/ramips/dts/mt7621_ubnt_edgerouter-x.dts
rename target/linux/ramips/dts/{mt7621_ubiquiti_edgerouterx.dtsi =>
mt7621_ubnt_edgerouter-x.dtsi} (100%)
diff --git a/target/linux/ramips/dts/mt7621_ubiquiti_edgerouterx-sfp.dts
b/target/linux/ramips/dts/mt7621_ubiquiti_edgerouterx-sfp.dts
deleted file mode 100644
index b4deb490ed..00
--- a/target/linux/ramips/dts/mt7621_ubiquiti_edgerouterx-sfp.dts
+++ /dev/null
@@ -1,17 +0,0 @@
-/dts-v1/;
-
-#include "mt7621_ubiquiti_edgerouterx.dtsi"
-
-/ {
- model = "UBNT-ERX-SFP";
- compatible = "ubiquiti,edgerouterx-sfp", "mediatek,mt7621-soc";
-};
-
- {
- status = "okay";
-
- pca9555@25 {
- compatible = "nxp,pca9555";
- reg = <0x25>;
- };
-};
diff --git a/target/linux/ramips/dts/mt7621_ubiquiti_edgerouterx.dts
b/target/linux/ramips/dts/mt7621_ubiquiti_edgerouterx.dts
deleted file mode 100644
index 5c1d9ec887..00
--- a/target/linux/ramips/dts/mt7621_ubiquiti_edgerouterx.dts
+++ /dev/null
@@ -1,8 +0,0 @@
-/dts-v1/;
-
-#include "mt7621_ubiquiti_edgerouterx.dtsi"
-
-/ {
- model = "UBNT-ERX";
- compatible = "ubiquiti,edgerouterx", "mediatek,mt7621-soc";
-};
diff --git a/target/linux/ramips/dts/mt7621_ubnt_edgerouter-x-sfp.dts
b/target/linux/ramips/dts/mt7621_ubnt_edgerouter-x-sfp.dts
new file mode 100644
index 00..9515f1d8b5
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_ubnt_edgerouter-x-sfp.dts
@@ -0,0 +1,17 @@
+/dts-v1/;
+
+#include "mt7621_ubnt_edgerouter-x.dtsi"
+
+/ {
+ model = "Ubiquiti EdgeRouter X SFP";
+ compatible = "ubnt,edgerouter-x-sfp", "mediatek,mt7621-soc";
+};
+
+ {
+ status = "okay";
+
+ pca9555@25 {
+ compatible = "nxp,pca9555";
+ reg = <0x25>;
+ };
+};
diff --git a/target/linux/ramips/dts/mt7621_ubnt_edgerouter-x.dts
b/target/linux/ramips/dts/mt7621_ubnt_edgerouter-x.dts
new file mode 100644
index 00..260baf9cf9
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_ubnt_edgerouter-x.dts
@@ -0,0 +1,8 @@
+/dts-v1/;
+
+#include "mt7621_ubnt_edgerouter-x.dtsi"
+
+/ {
+ model = "Ubiquiti EdgeRouter X";
+ compatible = "ubnt,edgerouter-x", "mediatek,mt7621-soc";
+};
diff --git a/target/linux/ramips/dts/mt7621_ubiquiti_edgerouterx.dtsi
b/target/linux/ramips/dts/mt7621_ubnt_edgerouter-x.dtsi
similarity index 100%
rename from target/linux/ramips/dts/mt7621_ubiquiti_edgerouterx.dtsi
rename to target/linux/ramips/dts/mt7621_ubnt_edgerouter-x.dtsi
diff --git a/target/linux/ramips/image/mt7621.mk
b/target/linux/ramips/image/mt7621.mk
index cdae42f3e4..767ada3f2f 100644
--- a/target/linux/ramips/image/mt7621.mk
+++ b/target/linux/ramips/image/mt7621.mk
@@ -768,27 +768,30 @@ define Device/tplink_re650-v1
endef
TARGET_DEVICES += tplink_re650-v1
-define Device/ubiquiti_edgerouterx
+define Device/ubnt_edgerouter_common
+ DEVICE_VENDOR := Ubiquiti
IMAGE_SIZE := 256768k
FILESYSTEMS := squashfs
KERNEL_SIZE := 3145728
KERNEL_INITRAMFS := $$(KERNEL) | \
ubnt-erx-factory-image
$(KDIR)/tmp/$$(KERNEL_INITRAMFS_PREFIX)-factory.tar
IMAGE/sysupgrade.bin := sysupgrade-tar | append-metadata
- DEVICE_VENDOR := Ubiquiti
+endef
+
+define Device/ubnt_edgerouter-x
+ $(Device/ubnt_edgerouter_common)
DEVICE_MODEL := EdgeRouter X
- SUPPORTED_DEVICES += ubnt-erx
+ SUPPORTED_DEVICES += ubnt-erx ubiquiti,edgerouterx
endef
-TARGET_DEVICES += ubiquiti_edgerouterx
+TARGET_DEVICES += ubnt_edgerouter-x
-define Device/ubiquiti_edgerouterx-sfp
-
[OpenWrt-Devel] ramips/mt7621 after 5.4 switch
Hi! Currently I'm having some serious problems with the new 5.4 port. 1) PCIe I'm developing on the ZyXEL LTE3301-PLUS. It has PCIe and a mt7615e connected to second bus on the first phy. If booting the device, kernel hangs with a RST message, telling the device is not detected. It seems the PCIe bus 1 cannot be reseted because nothing is connected to bus 0. An upport of the old PCI driver reenables the function. I can provide more logs on this if needed. 2) DSA These are my first experiments with DSA. I've configured 2 bridges: lan: lan1 lan2 lan3 lan4 dmz: lan1.20 lan2.20 lan3.20 lan4.20 Inbound traffic on vlan 20 is comming in, outgoing traffic passes the lan1 port but does note arrive at the other end. Should this work with DSA on mediathek? If not, I can offer that I write a patch for traditional swconfig. 3) Problems with QMI Interfaces QMI is used for mobile phones and interact with the qmi_wwan driver in the kernel. I had transmit issues, switched the driver back to the 4.14 while still on 5.4. But the same problem happens again. Under 4.14 this was not a problem. So it seems 5.4 or the SOC patches somehow are the root cause. Here's the kernel message: [ 4199.444191] [ cut here ] [ 4199.453534] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:447 dev_watchdog+0x2f8/0x300 [ 4199.470074] NETDEV WATCHDOG: wwan0 (qmi_wwan): transmit queue 0 timed out Mon Apr 6 16:27[ 4199.483839] Modules linked in: qcserial option cdc_mbim usb_wwan sierra_net sierra rndis_host qmi_wwan pppoe pl2303 l2tp_ppp iptable_nat ipt_REJECT huawei_cdc_ncm ftdi_sio cdc_subset cdc_ncm cdc_ether cdc_eem xt_u32 xt_time xt_tcpudp xt_tcpmss xt_string xt_statistic xt_state xt_socket xt_recent xt_quota xt_policy xt_pkttype xt_owner xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_iprange xt_hl xt_helper xt_hashlimit xt_esp xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_cluster xt_bpf xt_addrtype xt_TRACE xt_TPROXY xt_TCPMSS xt_REDIRECT xt_NETMAP xt_MASQUERADE xt_LOG xt_LED xt_HL xt_DSCP xt_CT xt_CLASSIFY xor wireguard vhci_hcd usbserial usbnet usblp usbip_host usbip_core ts_fsm ts_bm pptp pppox ppp_synctty ppp_mppe ppp_async nfnetlink_queue nfnetlink_log nf_tproxy_ipv6 nf_tproxy_ipv4 nf_socket_ipv6 nf_socket_ipv4 nf_reject_ipv4 nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_pptp nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda nf_nat nf_log_ipv4 :24 2020 kern.wa[ 4199.484081] nf_conntrack_tftp nf_conntrack_snmp nf_conntrack_sip nf_conntrack_pptp nf_conntrack_netlink nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp nf_conntrack_broadcast ts_kmp nf_conntrack_amanda nf_conncount macvlan iptable_raw iptable_mangle iptable_filter ipt_ah ipt_ECN ipt_CLUSTERIP ipheth ip6table_raw ip_tables hso crc_ccitt cdc_wdm cdc_acm asn1_decoder arptable_filter arpt_mangle arp_tables fuse sch_teql sch_sfq sch_red sch_prio sch_pie sch_multiq sch_gred sch_fq sch_dsmark sch_codel em_text em_nbyte em_meta em_cmp act_simple act_police act_pedit act_ipt act_gact act_csum libcrc32c act_connmark nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 sch_tbf sch_ingress sch_htb sch_hfsc em_u32 cls_u32 cls_tcindex cls_route cls_matchall cls_fw cls_flow cls_basic act_skbedit act_mirred evdev lp i2c_dev ledtrig_usbport ppdev parport ledtrig_heartbeat ledtrig_gpio cryptodev xt_set ip_set_list_set ip_set_hash_netportnet ip_set_hash_netport ip_set_hash_netnet ip_set_hash_netiface rn kernel: [ 419[ 4199.660920] ip_set_hash_net ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink ip6t_rt ip6t_mh ip6t_ipv6header ip6t_hbh ip6t_frag ip6t_eui64 ip6t_ah nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 pppoatm ppp_generic slhc msdos bonding ip6_gre ip_gre gre ifb dummy nat46 l2tp_ip6 l2tp_ip l2tp_eth ip6_vti ip_vti sit l2tp_netlink l2tp_core ipcomp6 xfrm6_tunnel esp6 ah6 xfrm4_tunnel ipcomp esp4 ah4 ipip ip6_tunnel tunnel6 tunnel4 ip_tunnel veth tun xfrm_user xfrm_ipcomp af_key xfrm_algo vfat fat udf crc_itu_t ntfs isofs dns_resolver br2684 atm fscache nls_utf8 nls_iso8859_1 nls_cp850 nls_cp437 nls_cp1250 vxlan udp_tunnel ip6_udp_tunnel wp512 twofish_generic twofish_common tgr192 tea serpent_generic khazad cast6_generic cast5_generic cast_common camellia_generic blowfish_generic blowfish_common anubis xts 9.444191] --[ 4199.836284] crypto_user algif_skcipher algif_rng algif_hash algif_aead af_alg sha512_generic sha256_generic libsha256 sha1_generic seqiv jitterentropy_rng drbg pcbc michael_mic md5 md4 hmac ghash_generic gf128mul gcm echainiv ecb des_generic libdes ctr cmac ccm cbc authenc arc4 usb_storage input_polldev leds_gpio xhci_plat_hcd xhci_pci xhci_mtk xhci_hcd ledtrig_transient fsl_mph_dr_of ehci_platform ehci_fsl sd_mod scsi_mod ehci_hcd gpio_button_hotplug ext4 mbcache
[OpenWrt-Devel] [PATCH v6] ramips: add support for JS76x8 series DEV boards
This commit adds support for the Jotale JS76x8 series development boards.
These devices have the following specifications:
- SOC: MT7628AN/NN, MT7688AN, MT7628DAN
- RAM of MT7628AN/NN and MT7688AN: 64/128/256 MB (DDR2)
- RAM of MT7628DAN: 64 MB (DDR2)
- FLASH:8/16/32 MB (SPI NOR)
- Ethernet:3x 10/100 Mbps ethernet ports (MT76x8 built-in switch)
- WIFI:1x 2T2R 2.4 GHz Wi-Fi
- LEDs:1x system status green LED, 1x wifi green LED,
3x ethernet green LED
- Buttons:1x reset button, 2x user defined button
- 1x microSD slot
- 4x USB 2.0 port
- 1x mini-usb debug UART
- 1x DC jack for main power (DC 5V)
- 1x TTL/RS232 UART
- 1x TTL/RS485 UART
- 13x GPIO header
- 1x audio codec(wm8960)
Installation via OpenWrt:
The original firmware is OpenWrt, so both LuCI or sysupgrade can be used.
Installation via U-boot web:
1. Power on board with reset button pressed, release it
after wifi led start blinking.
2. Setup static IP 192.168.1.123/4 on your PC.
3. Go to 192.168.1.8 in browser and upload "sysupgrade" image.
Installation via U-boot tftp:
1. Connect to serial console at the mini usb, which has been connected to UART0
on board (115200 8N1)
2. Setup static IP 192.168.1.123/4 on your PC.
3. Place openwrt-firmware.bin on your PC tftp server (192.168.1.123).
3. Connect one of LAN ports on board to your PC.
4. Start terminal software (e.g. screen /dev/ttyUSB0 115200) on PC.
5. Apply power to board.
6. Interrupt U-boot with keypress of "2".
7. At u-boot prompts:
Warning!! Erase Linux in Flash then burn new one. Are you sure?(Y/N) Y
Input device IP (192.168.1.8) ==:192.168.1.8
Input server IP (192.168.1.123) ==:192.168.1.123
Input Linux Kernel filename (root_uImage) ==:openwrt-firmware.bin
8. board will download file from tftp server, write it to flash and reboot.
Signed-off-by: Robinson Wu
---
.../ramips/dts/mt7628an_jotale_js76x8-16m.dts | 12 ++
.../ramips/dts/mt7628an_jotale_js76x8-32m.dts | 12 ++
.../linux/ramips/dts/mt7628an_jotale_js76x8-8m.dts | 12 ++
.../linux/ramips/dts/mt7628an_jotale_js76x8.dtsi | 156 +
target/linux/ramips/image/mt76x8.mk| 30
.../ramips/mt76x8/base-files/etc/board.d/01_leds | 6 +
.../mt76x8/base-files/etc/board.d/02_network | 6 +
7 files changed, 234 insertions(+)
create mode 100644 target/linux/ramips/dts/mt7628an_jotale_js76x8-16m.dts
create mode 100644 target/linux/ramips/dts/mt7628an_jotale_js76x8-32m.dts
create mode 100644 target/linux/ramips/dts/mt7628an_jotale_js76x8-8m.dts
create mode 100644 target/linux/ramips/dts/mt7628an_jotale_js76x8.dtsi
diff --git a/target/linux/ramips/dts/mt7628an_jotale_js76x8-16m.dts
b/target/linux/ramips/dts/mt7628an_jotale_js76x8-16m.dts
new file mode 100644
index 000..53ed6d8
--- /dev/null
+++ b/target/linux/ramips/dts/mt7628an_jotale_js76x8-16m.dts
@@ -0,0 +1,12 @@
+/dts-v1/;
+
+#include "mt7628an_jotale_js76x8.dtsi"
+
+/ {
+ compatible = "jotale,js76x8-16m", "jotale,js76x8",
"mediatek,mt7628an-soc";
+ model = "Jotale JS76x8 (16M)";
+};
+
+ {
+ reg = <0x5 0xfb>;
+};
diff --git a/target/linux/ramips/dts/mt7628an_jotale_js76x8-32m.dts
b/target/linux/ramips/dts/mt7628an_jotale_js76x8-32m.dts
new file mode 100644
index 000..851e6db
--- /dev/null
+++ b/target/linux/ramips/dts/mt7628an_jotale_js76x8-32m.dts
@@ -0,0 +1,12 @@
+/dts-v1/;
+
+#include "mt7628an_jotale_js76x8.dtsi"
+
+/ {
+ compatible = "jotale,js76x8-32m", "jotale,js76x8",
"mediatek,mt7628an-soc";
+ model = "Jotale JS76x8 (32M)";
+};
+
+ {
+ reg = <0x5 0x1fb>;
+};
diff --git a/target/linux/ramips/dts/mt7628an_jotale_js76x8-8m.dts
b/target/linux/ramips/dts/mt7628an_jotale_js76x8-8m.dts
new file mode 100644
index 000..8cac3fb
--- /dev/null
+++ b/target/linux/ramips/dts/mt7628an_jotale_js76x8-8m.dts
@@ -0,0 +1,12 @@
+/dts-v1/;
+
+#include "mt7628an_jotale_js76x8.dtsi"
+
+/ {
+ compatible = "jotale,js76x8-8m", "mediatek,mt7628an-soc";
+ model = "Jotale JS76x8 (8M)";
+};
+
+ {
+ reg = <0x5 0x7b>;
+};
diff --git a/target/linux/ramips/dts/mt7628an_jotale_js76x8.dtsi
b/target/linux/ramips/dts/mt7628an_jotale_js76x8.dtsi
new file mode 100644
index 000..d9cd5d4
--- /dev/null
+++ b/target/linux/ramips/dts/mt7628an_jotale_js76x8.dtsi
@@ -0,0 +1,156 @@
+#include "mt7628an.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "jotale,js76x8", "mediatek,mt7628an-soc";
+
+ aliases {
+ led-boot = _system;
+ led-failsafe = _system;
+ led-running = _system;
+ led-upgrade = _system;
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,115200";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_system: system {
+ label = "js76x8:green:system";
+ gpios = < 5 GPIO_ACTIVE_LOW>;
+ };
+
+ wifi {
+ label =
[OpenWrt-Devel] [PATCH] ramips: mt7621: harmonize naming scheme for Mikrotik
So far, image/device/board names for Mikrotik devices in mt7621 have
been used quite inconsistently.
This patch harmonizes the naming scheme by applying the same style
as used lately in ath79, i.e. using "RouterBOARD" as separate word
in the model name (instead of RB prefix for the number) and deriving
the board/device name from that (= make lower case and replace spaces
by hyphens).
This style has already been used for most the model/DEVICE_MODEL
variables in mt7621, so this is essentially just adjusting the remaining
variables to that.
Signed-off-by: Adrian Schmutzler
---
... => mt7621_mikrotik_routerboard-750gr3.dts} | 6 +++---
...ts => mt7621_mikrotik_routerboard-m11g.dts} | 14 +++---
...ts => mt7621_mikrotik_routerboard-m33g.dts} | 4 ++--
target/linux/ramips/image/mt7621.mk| 18 ++
.../mt7621/base-files/etc/board.d/01_leds | 2 +-
.../mt7621/base-files/etc/board.d/02_network | 10 +-
.../base-files/etc/board.d/03_gpio_switches| 2 +-
.../etc/uci-defaults/04_led_migration | 10 +-
.../mt7621/base-files/lib/upgrade/platform.sh | 6 +++---
9 files changed, 41 insertions(+), 31 deletions(-)
rename target/linux/ramips/dts/{mt7621_mikrotik_rb750gr3.dts =>
mt7621_mikrotik_routerboard-750gr3.dts} (94%)
rename target/linux/ramips/dts/{mt7621_mikrotik_rbm11g.dts =>
mt7621_mikrotik_routerboard-m11g.dts} (88%)
rename target/linux/ramips/dts/{mt7621_mikrotik_rbm33g.dts =>
mt7621_mikrotik_routerboard-m33g.dts} (97%)
diff --git a/target/linux/ramips/dts/mt7621_mikrotik_rb750gr3.dts
b/target/linux/ramips/dts/mt7621_mikrotik_routerboard-750gr3.dts
similarity index 94%
rename from target/linux/ramips/dts/mt7621_mikrotik_rb750gr3.dts
rename to target/linux/ramips/dts/mt7621_mikrotik_routerboard-750gr3.dts
index e268b233d4..3f37155f24 100644
--- a/target/linux/ramips/dts/mt7621_mikrotik_rb750gr3.dts
+++ b/target/linux/ramips/dts/mt7621_mikrotik_routerboard-750gr3.dts
@@ -7,7 +7,7 @@
#include
/ {
- compatible = "mikrotik,rb750gr3", "mediatek,mt7621-soc";
+ compatible = "mikrotik,routerboard-750gr3", "mediatek,mt7621-soc";
model = "MikroTik RouterBOARD 750Gr3";
aliases {
@@ -25,13 +25,13 @@
compatible = "gpio-leds";
pwr {
- label = "rb750gr3:blue:pwr";
+ label = "routerboard-750gr3:blue:pwr";
gpios = < 16 GPIO_ACTIVE_HIGH>;
default-state = "on";
};
led_usr: usr {
- label = "rb750gr3:green:usr";
+ label = "routerboard-750gr3:green:usr";
gpios = < 0 GPIO_ACTIVE_HIGH>;
};
};
diff --git a/target/linux/ramips/dts/mt7621_mikrotik_rbm11g.dts
b/target/linux/ramips/dts/mt7621_mikrotik_routerboard-m11g.dts
similarity index 88%
rename from target/linux/ramips/dts/mt7621_mikrotik_rbm11g.dts
rename to target/linux/ramips/dts/mt7621_mikrotik_routerboard-m11g.dts
index bcfce33a16..5b631da7c7 100644
--- a/target/linux/ramips/dts/mt7621_mikrotik_rbm11g.dts
+++ b/target/linux/ramips/dts/mt7621_mikrotik_routerboard-m11g.dts
@@ -6,7 +6,7 @@
#include
/ {
- compatible = "mikrotik,rbm11g", "mediatek,mt7621-soc";
+ compatible = "mikrotik,routerboard-m11g", "mediatek,mt7621-soc";
model = "MikroTik RouterBOARD M11G";
aliases {
@@ -24,32 +24,32 @@
compatible = "gpio-leds";
led_usr: usr {
- label = "rbm11g:green:usr";
+ label = "routerboard-m11g:green:usr";
gpios = < 0 GPIO_ACTIVE_HIGH>;
};
rssi0 {
- label = "rbm11g:green:rssi0";
+ label = "routerboard-m11g:green:rssi0";
gpios = < 22 GPIO_ACTIVE_LOW>;
};
rssi1 {
- label = "rbm11g:green:rssi1";
+ label = "routerboard-m11g:green:rssi1";
gpios = < 23 GPIO_ACTIVE_LOW>;
};
rssi2 {
- label = "rbm11g:green:rssi2";
+ label = "routerboard-m11g:green:rssi2";
gpios = < 24 GPIO_ACTIVE_LOW>;
};
rssi3 {
- label = "rbm11g:green:rssi3";
+ label = "routerboard-m11g:green:rssi3";
gpios = < 25 GPIO_ACTIVE_LOW>;
};
rssi4 {
- label = "rbm11g:green:rssi4";
+ label = "routerboard-m11g:green:rssi4";
gpios = < 26 GPIO_ACTIVE_LOW>;
};
};
diff --git a/target/linux/ramips/dts/mt7621_mikrotik_rbm33g.dts
b/target/linux/ramips/dts/mt7621_mikrotik_routerboard-m33g.dts
similarity index 97%
rename
Re: [OpenWrt-Devel] [PATCH 0/6] build: update scritps/config to kconfig-v5.6
Eneas U de Queiroz [2020-04-06 17:10:30]: Hi, > TLDR: You can't review this by only looking at the patches. Just tried to build[1] test it on x86/64 sunxi/a53 imx6 ipq40xx and it fails to build: make -s -C scripts/config conf CC=cc: build failed. 1. https://gitlab.com/ynezz/openwrt/pipelines/133543034 -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][RFC] Revert "ramips: mt7621: disable image for mikrotik_rbm11g"
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Chuanhong Guo > Sent: Dienstag, 7. April 2020 04:27 > To: openwrt-devel@lists.openwrt.org > Cc: Chuanhong Guo > Subject: [OpenWrt-Devel] [PATCH][RFC] Revert "ramips: mt7621: disable > image for mikrotik_rbm11g" > > This reverts commit 838f1fbb50e91ebaf1d34f9666ae6b65eb49df5c. > > It can be guessed from Mikrotik GPL kernel that this router uses port0. > And even if it doesn't, RBM11G has easy-to-use tftp recovery mechanism for > users to restore their firmware. Let's enable this image and see if users > complains. > > Signed-off-by: Chuanhong Guo > --- > RFC: Should I do this? > If I don't do so, users will complain about missing image; But if I do and > brick > users devices, users may also complain. That may not be a big deal as users > can recover their devices easily. > I have no idea what I should do at this moment. IMO, if you have a chance for an educated guess, it's better to have the image available (just as you justified it in the actual commit message). Due to the DSA introduction, users will have to do more conscious updates anyway. Acked-by: Adrian Schmutzler Best Adrian > > It's even better if a developer with this device can spot this mail and help > testing the firmware :D > > target/linux/ramips/image/mt7621.mk | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/target/linux/ramips/image/mt7621.mk > b/target/linux/ramips/image/mt7621.mk > index cdae42f3e4..a4484b408f 100644 > --- a/target/linux/ramips/image/mt7621.mk > +++ b/target/linux/ramips/image/mt7621.mk > @@ -497,7 +497,6 @@ TARGET_DEVICES += mikrotik_rb750gr3 define > Device/mikrotik_rbm11g >$(Device/MikroTik) >DEVICE_MODEL := RouterBOARD M11G > - DEFAULT := n # disabled due to unknown port assignment endef > TARGET_DEVICES += mikrotik_rbm11g > > -- > 2.25.1 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
