RE: [PATCH] arc770: Remove arc770 target
> -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Hauke Mehrtens > Sent: Samstag, 22. Januar 2022 20:24 > To: openwrt-devel@lists.openwrt.org > Cc: alexey.brod...@synopsys.com; linux-snps-...@lists.infradead.org; > Hauke Mehrtens > Subject: [PATCH] arc770: Remove arc770 target > > The arc700 target is not booting up since some time, see here: > https://github.com/foss-for-synopsys-dwc-arc- > processors/toolchain/issues/400 > > It looks like there is a problem in the toolchain when using glibc. > > Currently no one is working on fixing this problem, remove the target > instead. This target also does not have many users we are aware of. > > If someone wants to have this target back, feel free to add a fixed version of > this target again. > > Signed-off-by: Hauke Mehrtens Acked-by: Adrian Schmutzler > --- > package/devel/perf/Makefile | 2 +- > target/linux/arc770/Makefile | 22 -- > .../arc770/base-files/etc/board.d/02_network | 17 -- > target/linux/arc770/config-5.4| 195 -- > .../arc770/generic/profiles/00-default.mk | 13 -- > target/linux/arc770/generic/target.mk | 8 - > target/linux/arc770/image/Config.in | 5 - > target/linux/arc770/image/Makefile| 84 > .../arc770/image/gen_axs10x_sdcard_img.sh | 29 --- > target/linux/arc770/image/uEnv.txt| 7 - > ...c-Disable-frame-filtering-completely.patch | 31 --- > 11 files changed, 1 insertion(+), 412 deletions(-) delete mode 100644 > target/linux/arc770/Makefile delete mode 100644 target/linux/arc770/base- > files/etc/board.d/02_network > delete mode 100644 target/linux/arc770/config-5.4 delete mode 100644 > target/linux/arc770/generic/profiles/00-default.mk > delete mode 100644 target/linux/arc770/generic/target.mk > delete mode 100644 target/linux/arc770/image/Config.in > delete mode 100644 target/linux/arc770/image/Makefile > delete mode 100755 target/linux/arc770/image/gen_axs10x_sdcard_img.sh > delete mode 100644 target/linux/arc770/image/uEnv.txt > delete mode 100644 target/linux/arc770/patches-5.4/700-stmmac-Disable- > frame-filtering-completely.patch > > diff --git a/package/devel/perf/Makefile b/package/devel/perf/Makefile > index bbf3aaf9ceac..9efd8f56e6b9 100644 > --- a/package/devel/perf/Makefile > +++ b/package/devel/perf/Makefile > @@ -27,7 +27,7 @@ include $(INCLUDE_DIR)/nls.mk define Package/perf >SECTION:=devel >CATEGORY:=Development > - DEPENDS:= +libelf +libdw +PACKAGE_libunwind:libunwind +libpthread > +librt +objdump @!IN_SDK @!TARGET_arc770 @KERNEL_PERF_EVENTS > + DEPENDS:= +libelf +libdw +PACKAGE_libunwind:libunwind +libpthread > + +librt +objdump @!IN_SDK @KERNEL_PERF_EVENTS >TITLE:=Linux performance monitoring tool >VERSION:=$(LINUX_VERSION)-$(PKG_RELEASE) >URL:=http://www.kernel.org > diff --git a/target/linux/arc770/Makefile b/target/linux/arc770/Makefile > deleted file mode 100644 index 1320c8283ba3.. > --- a/target/linux/arc770/Makefile > +++ /dev/null > @@ -1,22 +0,0 @@ > -# SPDX-License-Identifier: GPL-2.0-only -# -# Copyright (C) 2015 > OpenWrt.org > - > -include $(TOPDIR)/rules.mk > - > -ARCH:=arc > -BOARD:=arc770 > -BOARDNAME:=Synopsys DesignWare ARC 770D -SUBTARGETS:=generic > - > -KERNEL_PATCHVER:=5.4 > - > -DEVICE_TYPE:=basic > - > -define Target/Description > - Synopsys DesignWare boards > -endef > - > -include $(INCLUDE_DIR)/target.mk > - > -$(eval $(call BuildTarget)) > diff --git a/target/linux/arc770/base-files/etc/board.d/02_network > b/target/linux/arc770/base-files/etc/board.d/02_network > deleted file mode 100644 > index c90f3fb6a695.. > --- a/target/linux/arc770/base-files/etc/board.d/02_network > +++ /dev/null > @@ -1,17 +0,0 @@ > -# > -# Copyright (C) 2015 OpenWrt.org > -# > - > -. /lib/functions/uci-defaults.sh > - > -board_config_update > - > -case "$(board_name)" in > -snps,axs101) > - ucidef_set_interface_lan "eth0" "dhcp" > - ;; > -esac > - > -board_config_flush > - > -exit 0 > diff --git a/target/linux/arc770/config-5.4 b/target/linux/arc770/config-5.4 > deleted file mode 100644 index 4cd5f195e698.. > --- a/target/linux/arc770/config-5.4 > +++ /dev/null > @@ -1,195 +0,0 @@ > -# CONFIG_16KSTACKS is not set > -CONFIG_ARC=y > -CONFIG_ARCH_32BIT_OFF_T=y > -CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y > -CONFIG_ARCH_HAS_DMA_COHERENT_TO_PFN=y > -CONFIG_ARCH_HAS_DMA_PREP_COHERENT=y > -CONFIG_ARCH_HAS_PTE_SPECIAL=y > -CONFIG_ARCH_HAS_
RE: Switch issues and CI to GitHub
> ## Conclusion > > From a FOSS perspective I’d skip GitHub entirely and move to Codeberg or > sr.ht. Codeberg (Gitea) is a fine clone of GitHub and sr.ht comes with a great > _no bloat_ attitude and priority on email integration for tickets and git > (they > created git-send-email.io). Hi, just wanted to repeat what I already said in the virtual meeting so it's documented here as well: I have been using gitea in a different project, mostly by reviewing Pull Requests there. While I started with no particular partiality, and it looked rather well in the beginning, I quickly became annoyed because there is just so much functionality lacking or worse when it is compared to GitHub. From my experience, gitea might be nice for a small project if you absolutely need to host it yourself. But it still does not seem adequate for a mature project, and it's rather improbable that they will be able to keep pace with GitHub and others in the future either. I'm not aware of any particular drawbacks with respect to just hosting Issues there, but that does really not make much more sense than the current solution if it's kept isolated afterwards. From the aspect of pure usability, I'd favor GitHub, as so many other projects do. Best Adrian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH v2] kernel/5.10: remove CONFIG_DEVTMPFS{, _MOUNT} from kconfigs
Hi,
just a nitpick: Commit title prefix should be "kernel: 5.10: ...".
Best
Adrian
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Rui Salvaterra
> Sent: Sonntag, 16. Januar 2022 20:46
> To: openwrt-devel@lists.openwrt.org
> Cc: dan...@makrotopia.org; Rui Salvaterra
> Subject: [PATCH v2] kernel/5.10: remove CONFIG_DEVTMPFS{, _MOUNT}
> from kconfigs
>
> They are required for container support, but are handled in
Config-kernel.in.
>
> Signed-off-by: Rui Salvaterra
> ---
> v2: keep both ksyms (disabled) in the generic kconfig.
>
> target/linux/archs38/config-5.10 | 1 -
> target/linux/layerscape/armv7/config-5.10 | 2 --
> target/linux/layerscape/armv8_64b/config-5.10 | 2 --
> target/linux/mediatek/mt7622/config-5.10 | 2 --
> target/linux/oxnas/config-5.10| 2 --
> target/linux/rockchip/armv8/config-5.10 | 2 --
> 6 files changed, 11 deletions(-)
>
> diff --git a/target/linux/archs38/config-5.10
b/target/linux/archs38/config-
> 5.10
> index 5ba3877a64..b082a47331 100644
> --- a/target/linux/archs38/config-5.10
> +++ b/target/linux/archs38/config-5.10
> @@ -84,7 +84,6 @@ CONFIG_CRYPTO_RNG=y
> CONFIG_CRYPTO_RNG2=y
> CONFIG_CRYPTO_RNG_DEFAULT=y
> CONFIG_CRYPTO_SHA256=y
> -CONFIG_DEVTMPFS=y
> CONFIG_DMADEVICES=y
> CONFIG_DMA_DIRECT_REMAP=y
> CONFIG_DMA_ENGINE=y
> diff --git a/target/linux/layerscape/armv7/config-5.10
> b/target/linux/layerscape/armv7/config-5.10
> index 0ec201030f..dd97d67cba 100644
> --- a/target/linux/layerscape/armv7/config-5.10
> +++ b/target/linux/layerscape/armv7/config-5.10
> @@ -170,8 +170,6 @@ CONFIG_DETECT_HUNG_TASK=y #
> CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND is not set #
> CONFIG_DEVFREQ_GOV_USERSPACE is not set #
> CONFIG_DEVFREQ_THERMAL is not set -CONFIG_DEVTMPFS=y -
> CONFIG_DEVTMPFS_MOUNT=y CONFIG_DMADEVICES=y
> CONFIG_DMA_CMA=y CONFIG_DMA_ENGINE=y diff --git
> a/target/linux/layerscape/armv8_64b/config-5.10
> b/target/linux/layerscape/armv8_64b/config-5.10
> index aa4be18f05..03c85a5aef 100644
> --- a/target/linux/layerscape/armv8_64b/config-5.10
> +++ b/target/linux/layerscape/armv8_64b/config-5.10
> @@ -204,8 +204,6 @@ CONFIG_DECOMPRESS_LZMA=y
> CONFIG_DECOMPRESS_LZO=y CONFIG_DECOMPRESS_XZ=y
> CONFIG_DETECT_HUNG_TASK=y -CONFIG_DEVTMPFS=y -
> CONFIG_DEVTMPFS_MOUNT=y CONFIG_DIMLIB=y
> CONFIG_DMADEVICES=y CONFIG_DMATEST=y diff --git
> a/target/linux/mediatek/mt7622/config-5.10
> b/target/linux/mediatek/mt7622/config-5.10
> index da1b283f70..946cab7738 100644
> --- a/target/linux/mediatek/mt7622/config-5.10
> +++ b/target/linux/mediatek/mt7622/config-5.10
> @@ -134,8 +134,6 @@ CONFIG_CRYPTO_SHA256=y
> CONFIG_CRYPTO_ZSTD=y CONFIG_DCACHE_WORD_ACCESS=y
> CONFIG_DEBUG_MISC=y -CONFIG_DEVTMPFS=y -
> CONFIG_DEVTMPFS_MOUNT=y CONFIG_DIMLIB=y
> CONFIG_DMADEVICES=y CONFIG_DMATEST=y diff --git
> a/target/linux/oxnas/config-5.10 b/target/linux/oxnas/config-5.10 index
> b0e4789d1e..93fbf5386d 100644
> --- a/target/linux/oxnas/config-5.10
> +++ b/target/linux/oxnas/config-5.10
> @@ -117,8 +117,6 @@ CONFIG_DECOMPRESS_LZ4=y
> CONFIG_DECOMPRESS_LZMA=y CONFIG_DECOMPRESS_LZO=y
> CONFIG_DECOMPRESS_XZ=y -CONFIG_DEVTMPFS=y -
> CONFIG_DEVTMPFS_MOUNT=y CONFIG_DMA_CMA=y
> CONFIG_DMA_REMAP=y CONFIG_DNOTIFY=y diff --git
> a/target/linux/rockchip/armv8/config-5.10
> b/target/linux/rockchip/armv8/config-5.10
> index 9769bab72d..1063489dc6 100644
> --- a/target/linux/rockchip/armv8/config-5.10
> +++ b/target/linux/rockchip/armv8/config-5.10
> @@ -167,8 +167,6 @@ CONFIG_DEVFREQ_GOV_USERSPACE=y #
> CONFIG_DEVFREQ_THERMAL is not set CONFIG_DEVMEM=y #
> CONFIG_DEVPORT is not set -CONFIG_DEVTMPFS=y -
> CONFIG_DEVTMPFS_MOUNT=y CONFIG_DMADEVICES=y
> CONFIG_DMA_CMA=y CONFIG_DMA_DIRECT_REMAP=y
> --
> 2.34.1
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH] ramips: add support for Wavlink WL-WN576A2
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of dev.aldr...@gmail.com
> Sent: Montag, 5. Juli 2021 18:12
> To: openwrt-devel@lists.openwrt.org
> Cc: m...@adrianschmutzler.de; Thomas Aldrian ;
> coelner
> Subject: [PATCH] ramips: add support for Wavlink WL-WN576A2
>
> From: Thomas Aldrian
>
> This commit adds support for the Wavlink WL-WN576A2 wall-plug wireles
> repeater / router. It is also sold under the name SilverCrest SWV 733 B1.
Generally fine, a few remarks below.
Should be good to merge after those are resolved.
>
> Device specs:
>
> - CPU: MediaTek MT7628AN
> - Flash: 8MB
> - RAM: 64MB
> - Bootloader: U-Boot
> - Ethernet: 1x 10/100 Mbps
> - 2.4 GHz: b/g/n SoC
> - 5 GHz: a/n/ac MT7610EN
> - Buttons: WPS, reset, sliding switch (ap/repeater)
> - LEDs: 5x wifi status, 1x LAN/WAN, 1x WPS
>
> Flashing:
>
> U-Boot launches a TFTP client if WPS button is held during boot.
>
> - Server IP: 192.168.10.100
> - Firmware file name: firmware.bin
>
> Device will reboot automatically. First boot takes about 90s.
>
> Coelner is the original author, but I have made some fixes. He does not
wish
> to sign off using his real name.
>
> Signed-off-by: Thomas Aldrian
> Co-authored-by: coelner
Just add the e-mail address in the text above and remove the non-standard
Co-authored-by tag.
You may add Birger's Tested-by here.
> ---
> .../dts/mt7628an_wavlink_wl-wn576a2.dts | 171 ++
> target/linux/ramips/image/mt76x8.mk | 10 +
> .../mt76x8/base-files/etc/board.d/01_leds | 3 +
> .../mt76x8/base-files/etc/board.d/02_network | 2 +
> 4 files changed, 186 insertions(+)
> create mode 100644 target/linux/ramips/dts/mt7628an_wavlink_wl-
> wn576a2.dts
>
> diff --git a/target/linux/ramips/dts/mt7628an_wavlink_wl-wn576a2.dts
> b/target/linux/ramips/dts/mt7628an_wavlink_wl-wn576a2.dts
> new file mode 100644
> index 00..333a7dc950
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7628an_wavlink_wl-wn576a2.dts
> @@ -0,0 +1,171 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +
> +#include "mt7628an.dtsi"
> +
> +#include
> +#include
> +
> +/ {
> + compatible = "wavlink,wl-wn576a2", "mediatek,mt7628an-soc";
> + model = "Wavlink WL-WN576A2";
> +
> + aliases {
> + led-boot = _wps;
> + led-failsafe = _wps;
> + led-running = _wps;
> + led-upgrade = _wps;
> + };
> +
> + keys {
> + compatible = "gpio-keys";
> +
> + reset {
> + label = "reset";
> + gpios = < 43 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + wps {
> + label = "wps";
> + gpios = < 38 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + ap {
> + label = "ap";
> + gpios = < 41 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + linux,input-type = ;
> + };
> +
> + repeater {
> + label = "repeater";
> + gpios = < 42 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + linux,input-type = ;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + wifi-high {
> + label = "blue:wifi-high";
> + gpios = < 37 GPIO_ACTIVE_LOW>;
> + };
> +
> + wifi-mediumhigh {
> + label = "blue:wifi-mediumhigh";
> + gpios = < 11 GPIO_ACTIVE_LOW>;
> + };
> +
> + wifi-medium {
> + label = "blue:wifi-medium";
> + gpios = < 44 GPIO_ACTIVE_LOW>;
> + };
> +
> + wifi-mediumlow {
> + label = "blue:wifi-mediumlow";
> + gpios = < 39 GPIO_ACTIVE_LOW>;
> + };
> +
> + wifi-low {
> + label = "blue:wifi-low";
> + gpios = < 40 GPIO_ACTIVE_LOW>;
> + };
> +
> + lan {
> + label = "blue:lan";
> + gpios = < 2 GPIO_ACTIVE_LOW>;
> + };
> +
> + led_wps: wps {
> + label = "blue:wps";
> + gpios = < 4 GPIO_ACTIVE_LOW>;
> + };
> + };
> +};
> +
> +_default {
> + gpio {
> + groups = "i2c", "i2s", "wdt", "wled_an", "p0led_an",
> "p1led_an",
> + "p2led_an", "p3led_an", "p4led_an", "refclk",
"gpio";
> + function = "gpio";
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + wifi@0,0 {
> + reg = <0x 0 0 0 0>;
> + mediatek,mtd-eeprom = < 0x8000>;
> + ieee80211-freq-limit =
RE: [RFT 5/5] realtek: support Trendnet TPE-082WS V1
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Paul Fertser
> Sent: Dienstag, 5. Oktober 2021 21:40
> To: openwrt-devel@lists.openwrt.org
> Cc: Paul Fertser
> Subject: [RFT 5/5] realtek: support Trendnet TPE-082WS V1
>
> According to photos and specs for Trendnet TPE-082WS V1.2R it should be
> the same as D-Link DGS-1210-10P R1 but with more powerful PSU (90 W) so
> the PoE budget is specified as 75 W.
This should be properly sorted in image/Makefile.
Best
Adian
>
> Signed-off-by: Paul Fertser
> ---
> .../realtek/base-files/etc/board.d/02_network | 3 +
> .../rtl8380_trendnet_tpe-082ws-v1.dts | 67 +++
> target/linux/realtek/image/Makefile | 11 +++
> 3 files changed, 81 insertions(+)
> create mode 100644 target/linux/realtek/dts-5.10/rtl8380_trendnet_tpe-
> 082ws-v1.dts
>
> diff --git a/target/linux/realtek/base-files/etc/board.d/02_network
> b/target/linux/realtek/base-files/etc/board.d/02_network
> index e7c45de92328..f8e06aea3510 100644
> --- a/target/linux/realtek/base-files/etc/board.d/02_network
> +++ b/target/linux/realtek/base-files/etc/board.d/02_network
> @@ -61,6 +61,9 @@ netgear,gs110tpp-v1)
> netgear,gs310tp-v1)
> ucidef_set_poe 55 "$lan_list"
> ;;
> +trendnet,tpe-082ws-v1)
> + ucidef_set_poe 75 "$lan_list"
> + ;;
> zyxel,gs1900-10hp)
> ucidef_set_poe 77 "$lan_list"
> ;;
> diff --git a/target/linux/realtek/dts-5.10/rtl8380_trendnet_tpe-082ws-v1.dts
> b/target/linux/realtek/dts-5.10/rtl8380_trendnet_tpe-082ws-v1.dts
> new file mode 100644
> index ..9b61da7ffccf
> --- /dev/null
> +++ b/target/linux/realtek/dts-5.10/rtl8380_trendnet_tpe-082ws-v1.dts
> @@ -0,0 +1,67 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +
> +#include "rtl8380_d-link_dgs-1210-10.dtsi"
> +
> +/ {
> + compatible = "trendnet,tpe-082ws-v1", "realtek,rtl838x-soc";
> + model = "Trendnet TPE-082WS V1";
> +
> + memory@0 {
> + device_type = "memory";
> + reg = <0x0 0x1000>;
> + };
> +};
> +
> + {
> + status = "okay";
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <5000>;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "u-boot";
> + reg = <0x 0x008>;
> + read-only;
> + };
> +
> + partition@8 {
> + label = "u-boot-env";
> + reg = <0x0008 0x004>;
> + read-only;
> + };
> +
> + partition@c {
> + label = "u-boot-env2";
> + reg = <0x000c 0x004>;
> + };
> +
> + partition@10 {
> + label = "firmware";
> + compatible = "denx,uimage";
> + reg = <0x0010 0x0e8>;
> + };
> +
> + partition@f8 {
> + label = "kernel2";
> + reg = <0x00f8 0x018>;
> + };
> +
> + partition@110 {
> + label = "rootfs2";
> + reg = <0x0110 0x0d0>;
> + };
> +
> + partition@1e0 {
> + label = "jffs2";
> + reg = <0x01e0 0x020>;
> + };
> + };
> + };
> +};
> diff --git a/target/linux/realtek/image/Makefile
> b/target/linux/realtek/image/Makefile
> index c7238494606e..94f4d91a089a 100644
> --- a/target/linux/realtek/image/Makefile
> +++ b/target/linux/realtek/image/Makefile
> @@ -80,6 +80,17 @@ define Device/d-link_dgs-1210-10p-r1 endef
> TARGET_DEVICES += d-link_dgs-1210-10p-r1
>
> +define Device/trendnet_tpe-082ws-v1
> + SOC := rtl8380
> + IMAGE_SIZE := 14848k
> + DEVICE_VENDOR := Trendnet
> + DEVICE_MODEL := TPE-082WS
> + DEVICE_VARIANT := V1
> + # TODO
> + # DEVICE_PACKAGES += realtek-poe
> +endef
> +TARGET_DEVICES += trendnet_tpe-082ws-v1
> +
> define Device/d-link_dgs-1210-16
>$(Device/d-link_dgs-1210)
>DEVICE_MODEL := DGS-1210-16
> --
> 2.17.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
RE: [RFT 4/5] realtek: support D-Link DGS-1210-10P H/W:R1
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Paul Fertser
> Sent: Dienstag, 5. Oktober 2021 21:40
> To: openwrt-devel@lists.openwrt.org
> Cc: Paul Fertser
> Subject: [RFT 4/5] realtek: support D-Link DGS-1210-10P H/W:R1
>
[...]
>
> diff --git a/target/linux/realtek/base-files/etc/board.d/02_network
> b/target/linux/realtek/base-files/etc/board.d/02_network
> index 58461c9c995f..e7c45de92328 100644
> --- a/target/linux/realtek/base-files/etc/board.d/02_network
> +++ b/target/linux/realtek/base-files/etc/board.d/02_network
> @@ -48,6 +48,13 @@ done
> [ -n "$label_mac" ] && ucidef_set_label_macaddr $label_mac
>
> case $board in
> +d-link,dgs-1210-10p-f1|\
> +d-link,dgs-1210-10p-r1)
F1 should be added with F1 support here, unless I'm misunderstanding something.
Best
Adrian
> + ucidef_set_poe 65 "$lan_list"
> + # once PoE board data is standardised it should also include
> + # max per-port power: 30 W
> + # PoE id numbers: inversed, e.g. lan2 is id 7
> + ;;
> netgear,gs110tpp-v1)
> ucidef_set_poe 130 "$lan_list"
> ;;
> diff --git a/target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10p-r1.dts
> b/target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10p-r1.dts
> new file mode 100644
> index ..379e0140bdf0
> --- /dev/null
> +++ b/target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10p-r1.dts
> @@ -0,0 +1,67 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +
> +#include "rtl8380_d-link_dgs-1210-10.dtsi"
> +
> +/ {
> + compatible = "d-link,dgs-1210-10p-r1", "realtek,rtl838x-soc";
> + model = "D-Link DGS-1210-10P R1";
> +
> + memory@0 {
> + device_type = "memory";
> + reg = <0x0 0x1000>;
> + };
> +};
> +
> + {
> + status = "okay";
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <5000>;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "u-boot";
> + reg = <0x 0x008>;
> + read-only;
> + };
> +
> + partition@8 {
> + label = "u-boot-env";
> + reg = <0x0008 0x004>;
> + read-only;
> + };
> +
> + partition@c {
> + label = "u-boot-env2";
> + reg = <0x000c 0x004>;
> + };
> +
> + partition@10 {
> + label = "firmware";
> + compatible = "denx,uimage";
> + reg = <0x0010 0x0e8>;
> + };
> +
> + partition@f8 {
> + label = "kernel2";
> + reg = <0x00f8 0x018>;
> + };
> +
> + partition@110 {
> + label = "rootfs2";
> + reg = <0x0110 0x0d0>;
> + };
> +
> + partition@1e0 {
> + label = "jffs2";
> + reg = <0x01e0 0x020>;
> + };
> + };
> + };
> +};
> diff --git a/target/linux/realtek/image/Makefile
> b/target/linux/realtek/image/Makefile
> index 903ad3815690..c7238494606e 100644
> --- a/target/linux/realtek/image/Makefile
> +++ b/target/linux/realtek/image/Makefile
> @@ -69,6 +69,17 @@ define Device/d-link_dgs-1210-10p-f1 endef
> TARGET_DEVICES += d-link_dgs-1210-10p-f1
>
> +define Device/d-link_dgs-1210-10p-r1
> + $(Device/d-link_dgs-1210)
> + SOC := rtl8380
> + IMAGE_SIZE := 14848k
> + DEVICE_MODEL := DGS-1210-10P
> + DEVICE_VARIANT := R1
> + # TODO
> + # DEVICE_PACKAGES += realtek-poe
> +endef
> +TARGET_DEVICES += d-link_dgs-1210-10p-r1
> +
> define Device/d-link_dgs-1210-16
>$(Device/d-link_dgs-1210)
>DEVICE_MODEL := DGS-1210-16
> --
> 2.17.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
RE: [RFT 3/5] realtek: add non-PoE version of DGS-1210-10 F1
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Paul Fertser > Sent: Dienstag, 5. Oktober 2021 21:40 > To: openwrt-devel@lists.openwrt.org > Cc: Paul Fertser > Subject: [RFT 3/5] realtek: add non-PoE version of DGS-1210-10 F1 missing commit message, probably since it's RFT ... One remark below. > > Signed-off-by: Paul Fertser > --- > .../rtl8380_d-link_dgs-1210-10-f1.dts | 8 +++ > .../rtl8380_d-link_dgs-1210-10-f1.dtsi| 61 +++ > .../rtl8380_d-link_dgs-1210-10p-f1.dts| 60 +- > target/linux/realtek/image/Makefile | 10 ++- > 4 files changed, 78 insertions(+), 61 deletions(-) create mode 100644 > target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10-f1.dts > create mode 100644 target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210- > 10-f1.dtsi > [...] > diff --git a/target/linux/realtek/image/Makefile > b/target/linux/realtek/image/Makefile > index c1e47f719f3a..903ad3815690 100644 > --- a/target/linux/realtek/image/Makefile > +++ b/target/linux/realtek/image/Makefile > @@ -53,11 +53,17 @@ define Device/d-link_dgs-1210 >DEVICE_VENDOR := D-Link > endef > > -define Device/d-link_dgs-1210-10p-f1 > +define Device/d-link_dgs-1210-10-f1 >$(Device/d-link_dgs-1210) >SOC := rtl8380 > - DEVICE_MODEL := DGS-1210-10P > + DEVICE_MODEL := DGS-1210-10 >DEVICE_VARIANT := F1 > +endef > +TARGET_DEVICES += d-link_dgs-1210-10-f1 > + > +define Device/d-link_dgs-1210-10p-f1 > + $(Device/d-link_dgs-1210-10-f1) > + DEVICE_MODEL := DGS-1210-10P Please do not derive one device from another. Derive only from nodes that are not a device themselves. In the specific case, it's probably best to just have the few variables twice and derive from dgs-1210. Best Adrian >SUPPORTED_DEVICES += d-link,dgs-1210-10p >DEVICE_PACKAGES += lua-rs232 > endef > -- > 2.17.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
RE: [RFT 1/5] realtek: split DGS-1210-10P DTS
> -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Paul Fertser > Sent: Dienstag, 5. Oktober 2021 21:40 > To: openwrt-devel@lists.openwrt.org > Cc: Paul Fertser > Subject: [RFT 1/5] realtek: split DGS-1210-10P DTS > > In preparations to add support for more similar boards the common part is > split into a DTSI. > > The model that's currently supported is known to be revision F1 so mark it > accordingly and provide appropriate compatible string for sysupgrade to > work. > [...] > diff --git a/target/linux/realtek/image/Makefile > b/target/linux/realtek/image/Makefile > index 5e4b4cde800d..c1e47f719f3a 100644 > --- a/target/linux/realtek/image/Makefile > +++ b/target/linux/realtek/image/Makefile > @@ -53,12 +53,15 @@ define Device/d-link_dgs-1210 >DEVICE_VENDOR := D-Link > endef > > -define Device/d-link_dgs-1210-10p > +define Device/d-link_dgs-1210-10p-f1 >$(Device/d-link_dgs-1210) > + SOC := rtl8380 Please, don't overwrite SOC on different levels. If these devices have different SOC, it should be moved out of the common recipe and been set for every device individually. Best Adrian >DEVICE_MODEL := DGS-1210-10P > + DEVICE_VARIANT := F1 > + SUPPORTED_DEVICES += d-link,dgs-1210-10p >DEVICE_PACKAGES += lua-rs232 > endef > -TARGET_DEVICES += d-link_dgs-1210-10p > +TARGET_DEVICES += d-link_dgs-1210-10p-f1 > > define Device/d-link_dgs-1210-16 >$(Device/d-link_dgs-1210) > -- > 2.17.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
RE: [RFT 1/5] realtek: split DGS-1210-10P DTS
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Paul Fertser
> Sent: Dienstag, 5. Oktober 2021 21:40
> To: openwrt-devel@lists.openwrt.org
> Cc: Paul Fertser
> Subject: [RFT 1/5] realtek: split DGS-1210-10P DTS
>
> In preparations to add support for more similar boards the common part is
> split into a DTSI.
>
> The model that's currently supported is known to be revision F1 so mark it
> accordingly and provide appropriate compatible string for sysupgrade to
> work.
I'd say the device rename is way more important than the DTS split. It should
be covered in the commit title.
Personally, I'd split these two changes (one for rename, one for shared DTSI
and device recipe).
Best
Adrian
>
> Signed-off-by: Paul Fertser
> ---
> ...0p.dts => rtl8380_d-link_dgs-1210-10.dtsi} | 60 -
> .../rtl8380_d-link_dgs-1210-10p-f1.dts| 66 +++
> target/linux/realtek/image/Makefile | 7 +-
> 3 files changed, 71 insertions(+), 62 deletions(-) rename
> target/linux/realtek/dts-5.10/{rtl8382_d-link_dgs-1210-10p.dts => rtl8380_d-
> link_dgs-1210-10.dtsi} (60%) create mode 100644 target/linux/realtek/dts-
> 5.10/rtl8380_d-link_dgs-1210-10p-f1.dts
>
> diff --git a/target/linux/realtek/dts-5.10/rtl8382_d-link_dgs-1210-10p.dts
> b/target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10.dtsi
> similarity index 60%
> rename from target/linux/realtek/dts-5.10/rtl8382_d-link_dgs-1210-10p.dts
> rename to target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10.dtsi
> index 119eaadc16e6..c465e7354872 100644
> --- a/target/linux/realtek/dts-5.10/rtl8382_d-link_dgs-1210-10p.dts
> +++ b/target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10.dtsi
> @@ -6,9 +6,6 @@
> #include
>
> / {
> - compatible = "d-link,dgs-1210-10p", "realtek,rtl838x-soc";
> - model = "D-Link DGS-1210-10P";
> -
> aliases {
> led-boot = _power;
> led-failsafe = _power;
> @@ -20,11 +17,6 @@
> bootargs = "console=ttyS0,115200";
> };
>
> - memory@0 {
> - device_type = "memory";
> - reg = <0x0 0x800>;
> - };
> -
> leds {
> pinctrl-names = "default";
> pinctrl-0 = <_disable_sys_led>; @@ -50,58 +42,6
> @@
> };
> };
>
> -
> - {
> - status = "okay";
> - flash@0 {
> - compatible = "jedec,spi-nor";
> - reg = <0>;
> - spi-max-frequency = <1000>;
> -
> - partitions {
> - compatible = "fixed-partitions";
> - #address-cells = <1>;
> - #size-cells = <1>;
> -
> - partition@0 {
> - label = "u-boot";
> - reg = <0x 0x8>;
> - read-only;
> - };
> - partition@8 {
> - label = "u-boot-env";
> - reg = <0x0008 0x4>;
> - read-only;
> - };
> - partition@c {
> - label = "u-boot-env2";
> - reg = <0x000c 0x4>;
> - };
> - partition@28 {
> - label = "firmware";
> - compatible = "denx,uimage";
> - reg = <0x0010 0xd8>;
> - };
> - partition@be8 {
> - label = "kernel2";
> - reg = <0x00e8 0x18>;
> - };
> - partition@100 {
> - label = "sysinfo";
> - reg = <0x0100 0x4>;
> - };
> - partition@104 {
> - label = "rootfs2";
> - reg = <0x0104 0xc0>;
> - };
> - partition@1c4 {
> - label = "jffs2";
> - reg = <0x01c4 0x3c>;
> - };
> - };
> - };
> -};
> -
> {
> status = "okay";
> };
> diff --git a/target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10p-f1.dts
> b/target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10p-f1.dts
> new file mode 100644
> index ..9a301adb935c
> --- /dev/null
> +++ b/target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10p-f1.dts
> @@ -0,0 +1,66 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +
> +#include "rtl8380_d-link_dgs-1210-10.dtsi"
> +
> +/ {
> + compatible = "d-link,dgs-1210-10p-f1", "realtek,rtl838x-soc";
> + model = "D-Link DGS-1210-10P F1";
> +
> + memory@0 {
> + device_type =
RE: [PATCH 4/4] zynq: switch to kernel 5.10
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Luis Araneda > Sent: Sonntag, 3. Oktober 2021 17:35 > To: openwrt-devel@lists.openwrt.org > Cc: Luis Araneda > Subject: [PATCH 4/4] zynq: switch to kernel 5.10 > > Use kernel 5.10 by default > > compile-tested: all devices from target > run-tested: Digilent Zybo Z7-20 Won't build for me (with build bot settings and all packages installed): make -C "/data/openwrt/build_dir/target-arm_cortex-a9+neon_musl_eabi/linux-zynq/back ports-5.10.68-1" KCFLAGS="-ffile-prefix-map=/data/openwrt/build_dir/target-arm_cortex-a9+neon _musl_eabi=target-arm_cortex-a9+neon_musl_eabi" HOSTCFLAGS="-O2 -I/data/openwrt/staging_dir/host/include -I/data/openwrt/staging_dir/hostpkg/include -I/data/openwrt/staging_dir/target-arm_cortex-a9+neon_musl_eabi/host/include -Wall -Wmissing-prototypes -Wstrict-prototypes" CROSS_COMPILE="arm-openwrt-linux-muslgnueabi-" ARCH="arm" KBUILD_HAVE_NLS=no KBUILD_BUILD_USER="builder" KBUILD_BUILD_HOST="buildhost" KBUILD_BUILD_TIMESTAMP="Tue Oct 5 18:56:02 2021" KBUILD_BUILD_VERSION="0" HOST_LOADLIBES="-L/data/openwrt/staging_dir/host/lib" KBUILD_HOSTLDLIBS="-L/data/openwrt/staging_dir/host/lib" CONFIG_SHELL="bash" V='' cmd_syscalls= KBUILD_EXTRA_SYMBOLS="/data/openwrt/build_dir/target-arm_cortex-a9+neon_musl _eabi/linux-zynq/symvers/antfs.symvers /data/openwrt/build_dir/target-arm_cortex-a9+neon_musl_eabi/linux-zynq/symve rs/button-hotplug.symvers /data/openwrt/build_dir/target-arm_cortex-a9+neon_musl_eabi/linux-zynq/symve rs/cryptodev-linux.symvers /data/openwrt/build_dir/target-arm_cortex-a9+neon_musl_eabi/linux-zynq/symve rs/dahdi-linux.symvers /data/openwrt/build_dir/target-arm_cortex-a9+neon_musl_eabi/linux-zynq/symve rs/dmx_usb_module.symvers /data/openwrt/build_dir/target-arm_cortex-a9+neon_musl_eabi/linux-zynq/symve rs/gl-mifi-mcu.symvers /data/openwrt/build_dir/target-arm_cortex-a9+neon_musl_eabi/linux-zynq/symve rs/gpio-button-hotplug.symvers /data/openwrt/build_dir/target-arm_cortex-a9+neon_musl_eabi/linux-zynq/symve rs/ksmbd.symvers /data/openwrt/build_dir/target-arm_cortex-a9+neon_musl_eabi/linux-zynq/symve rs/mdio-netlink.symvers /data/openwrt/build_dir/target-arm_cortex-a9+neon_musl_eabi/linux-zynq/symve rs/mtd-rw.symvers /data/openwrt/build_dir/target-arm_cortex-a9+neon_musl_eabi/linux-zynq/symve rs/nat46.symvers /data/openwrt/build_dir/target-arm_cortex-a9+neon_musl_eabi/linux-zynq/symve rs/netatop.symvers /data/openwrt/build_dir/target-arm_cortex-a9+neon_musl_eabi/linux-zynq/symve rs/openvswitch.symvers /data/openwrt/build_dir/target-arm_cortex-a9+neon_musl_eabi/linux-zynq/symve rs/rtpengine.symvers /data/openwrt/build_dir/target-arm_cortex-a9+neon_musl_eabi/linux-zynq/symve rs/siit.symvers /data/openwrt/build_dir/target-arm_cortex-a9+neon_musl_eabi/linux-zynq/symve rs/trelay.symvers /data/openwrt/build_dir/target-arm_cortex-a9+neon_musl_eabi/linux-zynq/symve rs/usb-serial-xr_usb_serial_common.symvers /data/openwrt/build_dir/target-arm_cortex-a9+neon_musl_eabi/linux-zynq/symve rs/xtables-addons.symvers" KERNELRELEASE=5.10.70 EXTRA_CFLAGS="-I/data/openwrt/build_dir/target-arm_cortex-a9+neon_musl_eabi/ linux-zynq/backports-5.10.68-1/include -ffile-prefix-map=/data/openwrt/build_dir/target-arm_cortex-a9+neon_musl_eab i/linux-zynq/backports-5.10.68-1=backports-5.10.68-1" KLIB_BUILD="/data/openwrt/build_dir/target-arm_cortex-a9+neon_musl_eabi/linu x-zynq/linux-5.10.70" MODPROBE=true KLIB=/lib/modules/5.10.70 KERNEL_SUBLEVEL=10 KBUILD_LDFLAGS_MODULE_PREREQ= modules make[4]: Entering directory '/data/openwrt/build_dir/target-arm_cortex-a9+neon_musl_eabi/linux-zynq/back ports-5.10.68-1' make[5]: 'Kconfig.versions' is up to date. make[7]: 'Kconfig.versions' is up to date. make[8]: 'conf' is up to date. boolean symbol CRYPTO_LIB_ARC4 tested for 'm'? test forced to 'n' # # configuration written to .config # Building backport-include/backport/autoconf.h ... done. MODPOST /data/openwrt/build_dir/target-arm_cortex-a9+neon_musl_eabi/linux-zynq/backp orts-5.10.68-1/Module.symvers ERROR: modpost: "wireless_send_event" [/data/openwrt/build_dir/target-arm_cortex-a9+neon_musl_eabi/linux-zynq/back ports-5.10.68-1/net/wireless/lib80211_crypt_tkip.ko] undefined! make[8]: *** [scripts/Makefile.modpost:124: /data/openwrt/build_dir/target-arm_cortex-a9+neon_musl_eabi/linux-zynq/backp orts-5.10.68-1/Module.symvers] Error 1 make[8]: *** Deleting file '/data/openwrt/build_dir/target-arm_cortex-a9+neon_musl_eabi/linux-zynq/back ports-5.10.68-1/Module.symvers' make[7]: *** [Makefile:1726: modules] Error 2 make[6]: *** [Makefile.build:13: modules] Error 2 make[5]: *** [Makefile.real:93: modules] Error 2 make[4]: *** [Makefile:121: modules] Error 2 make[4]: Leaving directory '/data/openwrt/build_dir/target-arm_cortex-a9+neon_musl_eabi/linux-zynq/back ports-5.10.68-1' make[3]: *** [Makefile:568: /data/openwrt/build_dir/target-arm_cortex-a9+neon_musl_eabi/linux-zynq/backp
RE: Suggestion: Explicitly warn to not use GitHub web UI for patches
> -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Paul D > Sent: Dienstag, 5. Oktober 2021 16:24 > To: openwrt-devel@lists.openwrt.org > Subject: Re: Suggestion: Explicitly warn to not use GitHub web UI for patches > > Roughly > > Write this up into an FAQ/howto on openwrt.org (this is, after all, the OWRT > way) > > Link to it in a > > https://docs.github.com/en/repositories/configuring-branches-and-merges- > in-your-repository/defining-the-mergeability-of-pull- > requests/troubleshooting-required-status-checks > > which looks for any commit containing: > > > Committer: "GitHub " > > > > Accepting "drive-by" PRs is overall a good thing, even if it is a bumpy path. Is it still when getting it done means not accepting three other PRs, because all time is consumed for hacking git vs. GitHub UI? Best Adrian > > > > > On 2021-10-03 23:22, Adrian Schmutzler wrote: > > Hi, > > > > I've repeatedly made the observation that people who submit PRs with > edits > > from GitHub's web interface cannot do history edits there when we > request > > them. > > > > This leads to a lot of frustration both for the reviewers and the > > submitters. Eventually, it's mostly one of the following three undesirable > > options: > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Suggestion: Explicitly warn to not use GitHub web UI for patches
Hi, I've repeatedly made the observation that people who submit PRs with edits from GitHub's web interface cannot do history edits there when we request them. This leads to a lot of frustration both for the reviewers and the submitters. Eventually, it's mostly one of the following three undesirable options: 1. The submitter has to clone the repository anyway (as he would have done in the first place otherwise), and do the edits locally. This typically leads to additional problems with force-pushing to the existing PR, and in most cases simply means duplicate work for the submitter. 2. The reviewer (committer) has to do the edits for the submitter. 3. The submitter closes the PR because he does not want to do the same thing twice. I have dealt with any of these options multiple times. Consequently, I think the overall disadvantages of direct GitHub edits outweigh the advantage of this option for easy submissions. It's also really frustrating for myself when I have to decide whether I should invest precious time in doing a git 101 with somebody or have to leave him behind otherwise. Thus, I'd like actively discourage this option in submitting-patches, and edit the current references to this option there accordingly. This essentially implies something like "Please, do not use GitHub Web UI for creating commits because ...". Of course, not everybody will read it, but if it helps for a few of them, it's already better than now. Are there any (other) opinions out there? Do we require a vote for that or is it enough if there are no objections after a certain waiting time? Best Adrian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: mediatek: fix NETDEV WATCHDOG: eth0 (mtk_SOC_eth): Transmit queue 0 timed out
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of daxiong
> Sent: Sonntag, 3. Oktober 2021 13:35
> To: openwrt-devel@lists.openwrt.org
> Subject: mediatek: fix NETDEV WATCHDOG: eth0 (mtk_SOC_eth): Transmit
> queue 0 timed out
>
> Use flow control or BQL maybe lead to bug.
> Iperf3 was usedfor 24 hours, Transmit Queue 0 timed out may occur.
> example:
>Server: iperf3 -s
>Client: iperf3 -c 172.16.10.20
>
> Signed-off-by: daxiong
Is this your (full) real name?
Best
Adrian
> ---
> ...iatek-ethernet-transmit-queue-timeout-bug.patch | 109
> +
> 1 file changed, 109 insertions(+)
> create mode 100644 target/linux/ramips/patches-5.4/500-mediatek-
> ethernet-transmit-queue-timeout-bug.patch
>
> diff --git a/target/linux/ramips/patches-5.4/500-mediatek-ethernet-
> transmit-queue-timeout-bug.patch b/target/linux/ramips/patches-5.4/500-
> mediatek-ethernet-transmit-queue-timeout-bug.patch
> new file mode 100644
> index 000..d5da9e4
> --- /dev/null
> +++ b/target/linux/ramips/patches-5.4/500-mediatek-ethernet-transmit-
> que
> +++ ue-timeout-bug.patch
> @@ -0,0 +1,109 @@
> +--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c2021-10-03
> 18:46:25.065801660 +0800
> b/drivers/net/ethernet/mediatek/mtk_eth_soc.c2021-10-03
> 19:13:24.931017393 +0800
> +@@ -26,6 +26,11 @@
> +
> + #include "mtk_eth_soc.h"
> +
> ++//Bug info: NETDEV WATCHDOG: eth0 (mtk_soc_eth): transmit queue 0
> ++timed out //Bug fixed: BQL and FC maybe QUEUE to be stopped forever
> ++#define DISABLE_MTK_BQL //disable Byte Queue Limit #define
> ++DISABLE_MTK_FC //disable Flow Control
> ++
> + static int mtk_msg_level = -1;
> + module_param_named(msg_level, mtk_msg_level, int, 0);
> +MODULE_PARM_DESC(msg_level, "Message level
> +(-1=defaults,0=none,...,16=all)");
> +@@ -380,6 +385,10 @@ static void mtk_mac_config(struct phylin
> + mcr_new |= MAC_MCR_FORCE_RX_FC;
> + }
> +
> ++#ifdef DISABLE_MTK_FC
> ++mcr_new &= ~(MAC_MCR_FORCE_RX_FC |
> MAC_MCR_FORCE_TX_FC);
> ++#endif
> ++
> + /* Only update control register when needed! */
> + if (mcr_new != mcr_cur)
> + mtk_w32(mac->hw, mcr_new, MTK_MAC_MCR(mac->id));
> @@ -535,8 +544,10
> +@@ static void mtk_validate(struct phylink_
> + }
> + }
> +
> ++#ifndef DISABLE_MTK_FC
> + phylink_set(mask, Pause);
> + phylink_set(mask, Asym_Pause);
> ++#endif
> +
> + linkmode_and(supported, supported, mask);
> + linkmode_and(state->advertising, state->advertising, mask); @@
> +-1071,8 +1082,10 @@ static int mtk_tx_map(struct sk_buff *sk
> + txd_pdma->txd2 |= TX_DMA_LS1;
> + }
> +
> ++#ifndef DISABLE_MTK_BQL
> + netdev_sent_queue(dev, skb->len);
> + skb_tx_timestamp(skb);
> ++#endif
> +
> + ring->next_free = mtk_qdma_phys_to_virt(ring, txd->txd2);
> + atomic_sub(n_desc, >free_count); @@ -1496,7 +1509,9 @@
> static
> +int mtk_poll_tx(struct mtk_eth *e
> + for (i = 0; i < MTK_MAC_COUNT; i++) {
> + if (!eth->netdev[i] || !done[i])
> + continue;
> ++#ifndef DISABLE_MTK_BQL
> + netdev_completed_queue(eth->netdev[i], done[i],
> bytes[i]);
> ++#endif
> + total += done[i];
> + eth->tx_packets += done[i];
> + eth->tx_bytes += bytes[i];
> +--- a/drivers/net/dsa/mt7530.c 2021-10-03 18:47:00.077800119 +0800
> b/drivers/net/dsa/mt7530.c 2021-10-03 19:13:37.807016826 +0800
> +@@ -22,6 +22,8 @@
> +
> + #include "mt7530.h"
> +
> ++#define DISABLE_MTK_FC //disable Flow Control
> ++
> + /* String, offset, and register size in bytes if different from 4
> +bytes */ static const struct mt7530_mib_desc mt7530_mib[] = {
> + MIB_DESC(1, 0x00, "TxDrop"),
> +@@ -1281,6 +1283,18 @@ mt7530_setup(struct dsa_switch *ds)
> + val |= MHWTRAP_MANUAL;
> + mt7530_write(priv, MT7530_MHWTRAP, val);
> +
> ++#ifdef DISABLE_MTK_FC
> ++usleep_range(10, 20);
> ++
> ++val = mt7530_read(priv, 0x1FE0);
> ++val &= ~BIT(31);
> ++mt7530_write(priv, 0x1FE0, val);
> ++
> ++mt7530_write(priv, MT7530_PMCR_P(5), 0x5e30b);
> ++mt7530_write(priv, MT7530_PMCR_P(6), 0x5e30b);
> ++usleep_range(10, 20);
> ++#endif
> ++
> + priv->p6_interface = PHY_INTERFACE_MODE_NA;
> +
> + /* Enable and reset MIB counters */
> +@@ -1427,6 +1441,10 @@ static void mt7530_phylink_mac_config(st
> + mcr_new |= PMCR_RX_FC_EN;
> + }
> +
> ++#ifdef DISABLE_MTK_FC
> ++mcr_new &= ~(PMCR_TX_FC_EN | PMCR_RX_FC_EN);
> ++#endif
> ++
> + if (mcr_new != mcr_cur)
> + mt7530_write(priv, MT7530_PMCR_P(port), mcr_new); }
> @@ -1505,8
> ++1523,10 @@ unsupported:
> + }
> + }
> +
> ++#ifndef DISABLE_MTK_FC
> + phylink_set(mask, Pause);
> + phylink_set(mask, Asym_Pause);
> ++#endif
> +
> +
RE: [PATCH-21.02] fix bug: NETDEV WATCHDOG: eth0 (mtk_SOC_eth): Transmit Queue 0 timed out Use flow control or BQL maybe lead to bug. Iperf3 was used for 24 hours, Transmit Queue 0 timed out may occur
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of daxiong
> Sent: Sonntag, 3. Oktober 2021 13:03
> To: openwrt-devel@lists.openwrt.org
> Subject: [PATCH-21.02] fix bug: NETDEV WATCHDOG: eth0 (mtk_SOC_eth):
> Transmit Queue 0 timed out Use flow control or BQL maybe lead to bug.
> Iperf3 was used for 24 hours, Transmit Queue 0 timed out may occur.
> example: Server: iperf3 -s Client: iperf3 -c 172.16.10.20
This has formal issues. Please clean up your commit title/message, use proper
title, and use your real name for Signed-off-by.
https://openwrt.org/submitting-patches
Apart from that, note that changes should be submitted to master first.
Best
Adrian
>
> Signed-off-by: daxiong
> ---
> ...iatek-ethernet-transmit-queue-timeout-bug.patch | 113
> +
> 1 file changed, 113 insertions(+)
> create mode 100644 target/linux/ramips/patches-5.4/500-mediatek-
> ethernet-transmit-queue-timeout-bug.patch
>
> diff --git a/target/linux/ramips/patches-5.4/500-mediatek-ethernet-
> transmit-queue-timeout-bug.patch b/target/linux/ramips/patches-5.4/500-
> mediatek-ethernet-transmit-queue-timeout-bug.patch
> new file mode 100644
> index 000..cec27c6
> --- /dev/null
> +++ b/target/linux/ramips/patches-5.4/500-mediatek-ethernet-transmit-
> que
> +++ ue-timeout-bug.patch
> @@ -0,0 +1,113 @@
> +--- a/drivers/net/dsa/mt7530.c 2021-10-03 18:47:00.077800119 +0800
> b/drivers/net/dsa/mt7530.c 2021-10-03 18:47:33.353798655 +0800
> +@@ -22,6 +22,10 @@
> +
> + #include "mt7530.h"
> +
> ++#ifdef CONFIG_SUPPORT_IKUAI_CODE
> ++#define DISABLE_MTK_FC //disable Flow Control #endif
> ++
> + /* String, offset, and register size in bytes if different from 4
> +bytes */ static const struct mt7530_mib_desc mt7530_mib[] = {
> + MIB_DESC(1, 0x00, "TxDrop"),
> +@@ -1281,6 +1285,18 @@ mt7530_setup(struct dsa_switch *ds)
> + val |= MHWTRAP_MANUAL;
> + mt7530_write(priv, MT7530_MHWTRAP, val);
> +
> ++#ifdef DISABLE_MTK_FC
> ++usleep_range(10, 20);
> ++
> ++val = mt7530_read(priv, 0x1FE0);
> ++val &= ~BIT(31);
> ++mt7530_write(priv, 0x1FE0, val);
> ++
> ++mt7530_write(priv, MT7530_PMCR_P(5), 0x5e30b);
> ++mt7530_write(priv, MT7530_PMCR_P(6), 0x5e30b);
> ++usleep_range(10, 20);
> ++#endif
> ++
> + priv->p6_interface = PHY_INTERFACE_MODE_NA;
> +
> + /* Enable and reset MIB counters */
> +@@ -1427,6 +1443,10 @@ static void mt7530_phylink_mac_config(st
> + mcr_new |= PMCR_RX_FC_EN;
> + }
> +
> ++#ifdef DISABLE_MTK_FC
> ++mcr_new &= ~(PMCR_TX_FC_EN | PMCR_RX_FC_EN);
> ++#endif
> ++
> + if (mcr_new != mcr_cur)
> + mt7530_write(priv, MT7530_PMCR_P(port), mcr_new); }
> @@ -1505,8
> ++1525,10 @@ unsupported:
> + }
> + }
> +
> ++#ifndef DISABLE_MTK_FC
> + phylink_set(mask, Pause);
> + phylink_set(mask, Asym_Pause);
> ++#endif
> +
> + linkmode_and(supported, supported, mask);
> + linkmode_and(state->advertising, state->advertising, mask);
> +--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c2021-10-03
> 18:46:25.065801660 +0800
> b/drivers/net/ethernet/mediatek/mtk_eth_soc.c2021-10-03
> 18:47:33.353798655 +0800
> +@@ -26,6 +26,13 @@
> +
> + #include "mtk_eth_soc.h"
> +
> ++#ifdef CONFIG_SUPPORT_IKUAI_CODE
> ++//Bug info: NETDEV WATCHDOG: eth0 (mtk_soc_eth): transmit queue 0
> ++timed out //Bug fixed: BQL and FC maybe QUEUE to be stopped forever
> ++#define DISABLE_MTK_BQL //disable Byte Queue Limit #define
> ++DISABLE_MTK_FC //disable Flow Control #endif
> ++
> + static int mtk_msg_level = -1;
> + module_param_named(msg_level, mtk_msg_level, int, 0);
> +MODULE_PARM_DESC(msg_level, "Message level
> +(-1=defaults,0=none,...,16=all)");
> +@@ -380,6 +387,10 @@ static void mtk_mac_config(struct phylin
> + mcr_new |= MAC_MCR_FORCE_RX_FC;
> + }
> +
> ++#ifdef DISABLE_MTK_FC
> ++mcr_new &= ~(MAC_MCR_FORCE_RX_FC |
> MAC_MCR_FORCE_TX_FC);
> ++#endif
> ++
> + /* Only update control register when needed! */
> + if (mcr_new != mcr_cur)
> + mtk_w32(mac->hw, mcr_new, MTK_MAC_MCR(mac->id));
> @@ -535,8 +546,10
> +@@ static void mtk_validate(struct phylink_
> + }
> + }
> +
> ++#ifndef DISABLE_MTK_FC
> + phylink_set(mask, Pause);
> + phylink_set(mask, Asym_Pause);
> ++#endif
> +
> + linkmode_and(supported, supported, mask);
> + linkmode_and(state->advertising, state->advertising, mask); @@
> +-1071,8 +1084,10 @@ static int mtk_tx_map(struct sk_buff *sk
> + txd_pdma->txd2 |= TX_DMA_LS1;
> + }
> +
> ++#ifndef DISABLE_MTK_BQL
> + netdev_sent_queue(dev, skb->len);
> + skb_tx_timestamp(skb);
> ++#endif
> +
> + ring->next_free = mtk_qdma_phys_to_virt(ring, txd->txd2);
> + atomic_sub(n_desc, >free_count); @@ -1496,7 +1511,9 @@
> static
> +int mtk_poll_tx(struct mtk_eth *e
> +
RE: Removing 5.4 support for bcm27xx and bcm53xx
> -Original Message- > From: Rafał Miłecki [mailto:ra...@milecki.pl] > Sent: Samstag, 2. Oktober 2021 19:28 > To: Adrian Schmutzler > Cc: 'Álvaro Fernández Rojas' ; openwrt- > de...@lists.openwrt.org > Subject: Re: Removing 5.4 support for bcm27xx and bcm53xx > > On 2021-10-02 18:43, Adrian Schmutzler wrote: > > both bcm27xx and bcm53xx have kernel 5.10 by default for more than one > > month. > > > > I'd like to remove 5.4 patches etc. there, so we don't have to bother > > with > > 5.4 for new patches (like stintel had to when adding config symbols > > recently). > > bcm53xx + 5.10 is still broken for EA9500 and Tenda AC-9. Having 5.4 is useful > for debugging. I'd prefer to wait a moment before we drop it. Makes sense. I will not touch it. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH v3] realtek: ensure output drivers are enabled in RTL8231
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Paul Fertser
> Sent: Samstag, 2. Oktober 2021 18:51
> To: Adrian Schmutzler
> Cc: openwrt-devel@lists.openwrt.org; 'Sander Vanheule'
>
> Subject: Re: [PATCH v3] realtek: ensure output drivers are enabled in
> RTL8231
>
> Hello Adrian,
>
> Thank you for taking care about this. One note below.
>
> On Sat, Oct 02, 2021 at 06:37:22PM +0200, Adrian Schmutzler wrote:
> > > The bootloader can leave the GPIO expander in a state which doesn't
> > > have output drivers enabled so GPIOs will properly work for input
> > > but output operations will have no effect.
> ...
> > > Reviewed-by: Sander Vanheule
> > > Signed-off-by: Paul Fertser
> >
> > I added
> >
> > Fixes: 16ae56b4f9ec ("realtek: fix RTL8231 gpio expander for high
> > GPIOs")
>
> Even though the patch changes the code that was introduced before with
> the patch you mention it's not fixing it. Commit 16ae56b4f9ec was fixing
> another bug (working with high GPIOs) and it was consistent with the
> existing code (that wasn't changing input/output state on init). However,
> that clearly leads to GPIOs not being able to work for output at least on
some
> of the supported targets so if anything it should have
>
> Fixes: 2b88563ee5aa ("realtek: update the tree to the latest refactored
> version")
Thanks for the explanation.
In this case, I will simply drop my Fixes: again and use the patch as you
provided it.
Best
Adrian
>
> --
> Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
> mailto:fercer...@gmail.com
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH] nftables: install libnftables to staging dir
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Daniel Danzberger > Sent: Dienstag, 28. September 2021 11:49 > To: openwrt-devel@lists.openwrt.org > Cc: j...@phrozen.org; Daniel Danzberger > Subject: [PATCH] nftables: install libnftables to staging dir > > Makes libnftables library and headers available for other packages. Please bump PKG_RELEASE or use $(AUTORELEASE) instead. Best Adrian > > Signed-off-by: Daniel Danzberger > --- > package/network/utils/nftables/Makefile | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/package/network/utils/nftables/Makefile > b/package/network/utils/nftables/Makefile > index 7830596e84..32384aca0e 100644 > --- a/package/network/utils/nftables/Makefile > +++ b/package/network/utils/nftables/Makefile > @@ -61,6 +61,12 @@ endif > TARGET_CFLAGS += -flto > TARGET_LDFLAGS += -flto > > +define Build/InstallDev > + $(INSTALL_DIR) $(1)/usr/lib $(1)/usr/include > + $(CP) $(PKG_INSTALL_DIR)/usr/lib/*.so* $(1)/usr/lib/ > + $(CP) $(PKG_INSTALL_DIR)/usr/include/nftables $(1)/usr/include/ > endef > + > define Package/nftables/install/Default > $(INSTALL_DIR) $(1)/usr/sbin > $(CP) $(PKG_INSTALL_DIR)/usr/sbin/nft $(1)/usr/sbin/ > -- > 2.33.0 > > > ___ > 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
Removing 5.4 support for bcm27xx and bcm53xx
Hi, both bcm27xx and bcm53xx have kernel 5.10 by default for more than one month. I'd like to remove 5.4 patches etc. there, so we don't have to bother with 5.4 for new patches (like stintel had to when adding config symbols recently). Any objections? Best Adrian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH v3] realtek: ensure output drivers are enabled in RTL8231
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Paul Fertser
> Sent: Freitag, 1. Oktober 2021 11:37
> To: openwrt-devel@lists.openwrt.org
> Cc: Sander Vanheule ; Paul Fertser
>
> Subject: [PATCH v3] realtek: ensure output drivers are enabled in RTL8231
>
> The bootloader can leave the GPIO expander in a state which doesn't have
> output drivers enabled so GPIOs will properly work for input but output
> operations will have no effect.
>
> To avoid disrupting the boot in case the bootloader left direction and
data
> registers in an inconsistent state (e.g. pulling SoC's reset to 0)
reconfigure
> everything as input.
>
> Reviewed-by: Sander Vanheule
> Signed-off-by: Paul Fertser
I added
Fixes: 16ae56b4f9ec ("realtek: fix RTL8231 gpio expander for high GPIOs")
and will merge this later tonight.
Best
Adrian
> ---
>
> Notes:
> Changes from v2:
> - Fix 5.10 as well
>
> Changes from v1:
> - Fix comment to mention we affect two extra GPIOs
> - Remove unused "v" declaration.
>
> .../realtek/files-5.10/drivers/gpio/gpio-rtl8231.c | 12 +++-
> .../realtek/files-5.4/drivers/gpio/gpio-rtl8231.c| 12 +++-
> 2 files changed, 14 insertions(+), 10 deletions(-)
>
> diff --git a/target/linux/realtek/files-5.10/drivers/gpio/gpio-rtl8231.c
> b/target/linux/realtek/files-5.10/drivers/gpio/gpio-rtl8231.c
> index a8ffcdc31368..f4f5621e0c1b 100644
> --- a/target/linux/realtek/files-5.10/drivers/gpio/gpio-rtl8231.c
> +++ b/target/linux/realtek/files-5.10/drivers/gpio/gpio-rtl8231.c
> @@ -239,8 +239,6 @@ void rtl8231_gpio_set(struct gpio_chip *gc, unsigned
> int offset, int value)
>
> int rtl8231_init(struct rtl8231_gpios *gpios) {
> - u32 v;
> -
> pr_info("%s called, MDIO bus ID: %d\n", __func__, gpios-
> >smi_bus_id);
>
> gpios->reg_cached = 0;
> @@ -254,11 +252,15 @@ int rtl8231_init(struct rtl8231_gpios *gpios)
> sw_w32_mask(3, 1, RTL838X_DMY_REG5);
> }
>
> - /* Select GPIO functionality for pins 0-34 */
> + /* Select GPIO functionality and force input direction for pins 0-36
> +*/
> rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(0), 0x);
> + rtl8231_write(gpios, RTL8231_GPIO_DIR(0), 0x);
> rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(16), 0x);
> - v = rtl8231_read(gpios, RTL8231_GPIO_PIN_SEL(32));
> - rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(32), v | 0x7);
> + rtl8231_write(gpios, RTL8231_GPIO_DIR(16), 0x);
> + rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(32), 0x03ff);
> +
> + /* Set LED_Start to enable drivers for output mode */
> + rtl8231_write(gpios, RTL8231_LED_FUNC0, 1 << 1);
>
> return 0;
> }
> diff --git a/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c
> b/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c
> index a8ffcdc31368..f4f5621e0c1b 100644
> --- a/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c
> +++ b/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c
> @@ -239,8 +239,6 @@ void rtl8231_gpio_set(struct gpio_chip *gc, unsigned
> int offset, int value)
>
> int rtl8231_init(struct rtl8231_gpios *gpios) {
> - u32 v;
> -
> pr_info("%s called, MDIO bus ID: %d\n", __func__, gpios-
> >smi_bus_id);
>
> gpios->reg_cached = 0;
> @@ -254,11 +252,15 @@ int rtl8231_init(struct rtl8231_gpios *gpios)
> sw_w32_mask(3, 1, RTL838X_DMY_REG5);
> }
>
> - /* Select GPIO functionality for pins 0-34 */
> + /* Select GPIO functionality and force input direction for pins 0-36
> +*/
> rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(0), 0x);
> + rtl8231_write(gpios, RTL8231_GPIO_DIR(0), 0x);
> rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(16), 0x);
> - v = rtl8231_read(gpios, RTL8231_GPIO_PIN_SEL(32));
> - rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(32), v | 0x7);
> + rtl8231_write(gpios, RTL8231_GPIO_DIR(16), 0x);
> + rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(32), 0x03ff);
> +
> + /* Set LED_Start to enable drivers for output mode */
> + rtl8231_write(gpios, RTL8231_LED_FUNC0, 1 << 1);
>
> return 0;
> }
> --
> 2.17.1
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH] ramips: switch to kernel 5.10
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Stijn Segers > Sent: Donnerstag, 9. September 2021 14:26 > To: openwrt-devel@lists.openwrt.org; Paweł Dembicki > ; Rui Salvaterra > Cc: OpenWrt Development List ; Adrian > Schmutzler ; David Bauer bauer.net> > Subject: Re: [PATCH] ramips: switch to kernel 5.10 > > "Paweł Dembicki" schreef op 9 september > 2021 13:47:36 CEST: > >czw., 9 wrz 2021 o 10:49 Rui Salvaterra napisał(a): > >> > >> Tested on mt7621 (Redmi AC2100) and running stable for several months. > >> > > > >Hi Rui, > > > >Please remember, if this patch will be merged before my PR #4255 [1], > >all mt7620 JBOOT devices will be broken. > > > >The reason is simple: The 5.10 kernel will be > 2MB. My PR will switch > >all mt7620 JBOOT devices to the OKLI loader. > > Would something similar need to be done for the mt76x8 subtarget? > > I just have a single one of these but I reckon they are equally > flash-starved... But if KERNEL_SIZE/IMAGE_SIZE is set properly there, those would just fail to build, so no harm could be done? Best Adrian > > Cheers > > Stijn > > > > >Best Regards, > >Pawel > > > >[1] https://github.com/openwrt/openwrt/pull/4255 > > > >> Signed-off-by: Rui Salvaterra > >> --- > >> target/linux/ramips/Makefile | 3 +-- > >> 1 file changed, 1 insertion(+), 2 deletions(-) > >> > >> diff --git a/target/linux/ramips/Makefile > >> b/target/linux/ramips/Makefile index d3f2d4b8fc..c9fc1aa58a 100644 > >> --- a/target/linux/ramips/Makefile > >> +++ b/target/linux/ramips/Makefile > >> @@ -10,8 +10,7 @@ BOARDNAME:=MediaTek Ralink MIPS > >> SUBTARGETS:=mt7620 mt7621 mt76x8 rt288x rt305x rt3883 > >> FEATURES:=squashfs gpio > >> > >> -KERNEL_PATCHVER:=5.4 > >> -KERNEL_TESTING_PATCHVER:=5.10 > >> +KERNEL_PATCHVER:=5.10 > >> > >> define Target/Description > >> Build firmware images for Ralink RT288x/RT3xxx based boards. > >> -- > >> 2.33.0 > >> > >> > >> ___ > >> openwrt-devel mailing list > >> openwrt-devel@lists.openwrt.org > >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > > >___ > >openwrt-devel mailing list > >openwrt-devel@lists.openwrt.org > >https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > Hi, > -- > Sent from my smartphone with K-9 Mail. Please excuse my brevity. > > ___ > 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
RE: [PATCH] ath79/ag71xx: rearrange ag71xx structs to remove holes
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Rui Salvaterra > Sent: Samstag, 25. September 2021 20:32 > To: Adrian Schmutzler > Cc: openwrt-devel@lists.openwrt.org; ros...@gmail.com > Subject: Re: [PATCH] ath79/ag71xx: rearrange ag71xx structs to remove > holes > > Hi, Adrian, > > On Fri, 24 Sept 2021 at 22:28, Adrian Schmutzler > wrote: > > > > Commit title prefix should be "ath79: ag71xx:" or just "ath79:". > > To be honest, it makes more sense to me to have " > > ath79/ag71xx:", as it conveys the same information requiring one character > less (and this format has often been used before). However, "ath79:" works > for me too. Shall I respin? Well, rule is that prefix has to be the target. I don't see why we should deviate from this rule now just to save a character. Best Adrian > > > > Apart from that, I can contribute nothing useful :-( > > Thanks, > Rui > > ___ > 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
RE: [PATCH v4 1/6] at91: kernel: bump to 5.10
Hi,
> -Original Message-
> From: Claudiu Beznea [mailto:claudiu.bez...@microchip.com]
> Sent: Montag, 20. September 2021 11:28
> To: openwrt-devel@lists.openwrt.org
> Cc: Claudiu Beznea
> Subject: [PATCH v4 1/6] at91: kernel: bump to 5.10
>
> Bump at91 targets to kernel v5.10. With this patches and files for wb45n
and
> wb50n were removed as they are now included in upstream kernel. Along
> with:
> - this the kernel config for sam9x targets has been refreshed (with
> make kernel_menuconfig + save);
> - CONFIG_ARCH_AT91 and specific sam9x SoCs (AT91RM9200, AT91SAM9,
> SAM9X60) has been enabled such that sam9x SoCs to be able to boot.
I've just compared our "old" version of wb45n and wb50n DTS files to the
ones in the 5.10 kernel.
They look very different.
Has this been investigated or do we just not care here?
Best
Adrian
>
> Signed-off-by: Claudiu Beznea
> ---
> target/linux/at91/Makefile| 2 +-
> .../at91/files/arch/arm/boot/dts/wb45n.dts| 220 --
> .../at91/files/arch/arm/boot/dts/wb50n.dts| 113 -
> .../at91/files/arch/arm/boot/dts/wb50n.dtsi | 205
> target/linux/at91/image/sam9x.mk | 1 +
> target/linux/at91/image/sama5.mk | 1 +
> .../101-ARM-at91-build-dtb-for-q5xr5.patch| 10 +
> .../101-ARM-at91-build-dtb-for-q5xr5.patch| 10 -
> .../102-ARM-at91-build-dtb-for-wb45n.patch| 12 -
> ...2-ARM-at91-wb45n-fix-duplicate-label.patch | 20 --
> .../103-ARM-at91-build-dtb-for-wb50n.patch| 12 -
> ...3-ARM-at91-wb50n-fix-duplicate-label.patch | 39
> target/linux/at91/sam9x/config-default| 105 -
> 13 files changed, 57 insertions(+), 693 deletions(-) delete mode 100644
> target/linux/at91/files/arch/arm/boot/dts/wb45n.dts
> delete mode 100644 target/linux/at91/files/arch/arm/boot/dts/wb50n.dts
> delete mode 100644 target/linux/at91/files/arch/arm/boot/dts/wb50n.dtsi
> create mode 04 target/linux/at91/patches-5.10 create mode 100644
> target/linux/at91/patches-5.10/101-ARM-at91-build-dtb-for-q5xr5.patch
> delete mode 04 target/linux/at91/patches-5.4 delete mode 100644
> target/linux/at91/patches-5.4/101-ARM-at91-build-dtb-for-q5xr5.patch
> delete mode 100644 target/linux/at91/patches-5.4/102-ARM-at91-build-dtb-
> for-wb45n.patch
> delete mode 100644 target/linux/at91/patches-5.4/102-ARM-at91-wb45n-
> fix-duplicate-label.patch
> delete mode 100644 target/linux/at91/patches-5.4/103-ARM-at91-build-dtb-
> for-wb50n.patch
> delete mode 100644 target/linux/at91/patches-5.4/103-ARM-at91-wb50n-
> fix-duplicate-label.patch
>
> diff --git a/target/linux/at91/Makefile b/target/linux/at91/Makefile index
> fe6a93244a5f..e4da7fb7e7da 100644
> --- a/target/linux/at91/Makefile
> +++ b/target/linux/at91/Makefile
> @@ -10,7 +10,7 @@ BOARDNAME:=Microchip (Atmel AT91)
> FEATURES:=ext4 squashfs targz usb usbgadget ubifs
> SUBTARGETS:=sama5 sam9x
>
> -KERNEL_PATCHVER:=5.4
> +KERNEL_PATCHVER:=5.10
>
> include $(INCLUDE_DIR)/target.mk
>
> diff --git a/target/linux/at91/files/arch/arm/boot/dts/wb45n.dts
> b/target/linux/at91/files/arch/arm/boot/dts/wb45n.dts
> deleted file mode 100644
> index fd9d260f2ab5..
> --- a/target/linux/at91/files/arch/arm/boot/dts/wb45n.dts
> +++ /dev/null
> @@ -1,220 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0-or-later
> -/*
> - * wb45n.dts - Device Tree file for WB45NBT board
> - *
> - * Copyright (C) 2015 Laird
> - */
> -
> -/dts-v1/;
> -#include "at91sam9g25.dtsi"
> -
> -/ {
> - model = "Laird Workgroup Bridge 45N - Atmel AT91SAM (dt)";
> - compatible = "laird,wb45n", "laird,wbxx", "atmel,at91sam9x5",
> "atmel,at91sam9";
> -
> - chosen {
> - bootargs = "console=ttyS0,115200 root=/dev/mtdblock1 rw
> rootfstype=ubifs ubi.mtd=1 root=ubi0:rootfs";
> - };
> -
> - memory {
> - reg = <0x2000 0x400>;
> - };
> -
> - clocks {
> - #address-cells = <1>;
> - #size-cells = <1>;
> - ranges;
> -
> - main_clock: clock@0 {
> - compatible = "atmel,osc", "fixed-clock";
> - clock-frequency = <1200>;
> - };
> -
> - slow_xtal {
> - clock-frequency = <32768>;
> - };
> -
> - main_xtal {
> - clock-frequency = <1200>;
> - };
> - };
> -
> - ahb {
> - apb {
> -
> - rstc@fe00 {
> - compatible = "atmel,sama5d3-rstc";
> - };
> -
> - pinctrl@f400 {
> - nand {
> - pinctrl_nand: nand-0 {
> - atmel,pins =
> - AT91_PERIPH_A AT91_PINCTRL_NONE /* PD0 periph A Read Enable
> */
> -
RE: [PATCH] realtek: add support for D-Link DGS-1210-10P H/W:R1
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Paul Fertser
> Sent: Samstag, 18. September 2021 00:14
> To: openwrt-devel@lists.openwrt.org
> Cc: Paul Fertser
> Subject: [PATCH] realtek: add support for D-Link DGS-1210-10P H/W:R1
Some mostly nitpick comments below.
[...]
> +
> + {
> + status = "okay";
I like empty lines after status for readability.
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <5000>;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "u-boot";
> + reg = <0x 0x8>;
This is a bit hard to read, particularly since you switch the size to 6 digits
later. Would you just use 7 digits for all numbers here (offset and size)?
First could be abbreviated to 0x0 of course.
> + read-only;
> + };
I'd put empty lines between nodes.
> + partition@8 {
> + label = "u-boot-env";
> + reg = <0x0008 0x4>;
> + read-only;
> + };
> + partition@c {
> + label = "u-boot-env2";
> + reg = <0x000c 0x4>;
> + };
> + partition@10 {
> + label = "firmware";
> + compatible = "denx,uimage";
> + reg = <0x0010 0xe8>;
> + };
> + partition@f8 {
> + label = "kernel2";
> + reg = <0x00f8 0x18>;
> + };
> + partition@110 {
> + label = "rootfs2";
> + reg = <0x0110 0xd0>;
> + };
> + partition@1e0 {
> + label = "jffs2";
> + reg = <0x01e0 0x20>;
> + };
> + };
> + };
> +};
> +
> + {
> + mdio: mdio-bus {
> + compatible = "realtek,rtl838x-mdio";
> + regmap = <>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + INTERNAL_PHY(8)
> + INTERNAL_PHY(9)
> + INTERNAL_PHY(10)
> + INTERNAL_PHY(11)
> + INTERNAL_PHY(12)
> + INTERNAL_PHY(13)
> + INTERNAL_PHY(14)
> + INTERNAL_PHY(15)
> + INTERNAL_PHY(24)
> + INTERNAL_PHY(26)
> + };
> +};
> +
> + {
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + SWITCH_PORT(8, 1, internal)
> + SWITCH_PORT(9, 2, internal)
> + SWITCH_PORT(10, 3, internal)
> + SWITCH_PORT(11, 4, internal)
> + SWITCH_PORT(12, 5, internal)
> + SWITCH_PORT(13, 6, internal)
> + SWITCH_PORT(14, 7, internal)
> + SWITCH_PORT(15, 8, internal)
> + SWITCH_SFP_PORT(24, 9, rgmii-id)
> + SWITCH_SFP_PORT(26, 10, rgmii-id)
> +
> + port@28 {
> + ethernet = <>;
> + reg = <28>;
> + phy-mode = "internal";
I'd put an empty line before the block.
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> + };
> + };
> +};
> +
> + {
> + ports {
> + port@24 {
> + sfp = <>;
> + };
> +
> + port@26 {
> + sfp = <>;
> + };
> + };
> +};
> diff --git a/target/linux/realtek/image/Makefile
> b/target/linux/realtek/image/Makefile
> index 5900750797e8..727f7bfa4164 100644
> --- a/target/linux/realtek/image/Makefile
> +++ b/target/linux/realtek/image/Makefile
> @@ -60,6 +60,14 @@ define Device/d-link_dgs-1210-10p endef
> TARGET_DEVICES += d-link_dgs-1210-10p
>
> +define Device/d-link_dgs-1210-10p-r1
> + $(Device/d-link_dgs-1210)
> + DEVICE_MODEL := DGS-1210-10P-R1
Is this R1 actually a revision? If yes, I'd prefer DEVICE_VARIANT "R1" here.
Best
Adrian
> + # for rtl83xx-poe
> + DEVICE_PACKAGES += libubox-lua libubus-lua libuci-lua lua-rs232 endef
> +TARGET_DEVICES += d-link_dgs-1210-10p-r1
> +
> define Device/d-link_dgs-1210-16
>$(Device/d-link_dgs-1210)
>DEVICE_MODEL := DGS-1210-16
> --
> 2.17.1
>
>
> ___
> openwrt-devel
RE: [PATCH] ath79/ag71xx: rearrange ag71xx structs to remove holes
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Rui Salvaterra
> Sent: Sonntag, 19. September 2021 12:39
> To: openwrt-devel@lists.openwrt.org
> Cc: ros...@gmail.com; Rui Salvaterra
> Subject: [PATCH] ath79/ag71xx: rearrange ag71xx structs to remove holes
Commit title prefix should be "ath79: ag71xx:" or just "ath79:".
Apart from that, I can contribute nothing useful :-(
Best
Adrian
>
> From: Rosen Penev
>
> Remove cacheline_aligned attribute to ring structs. This actually
causes
> holes in the ag71xx struct as well as lower performance.
>
> Rearrange struct members to fall within respective cachelines. The RX ring
> struct now does not share a cacheline with the TX ring. The NAPI struct
now
> takes up its own cachelines and does not share.
>
> According to pahole -C ag71xx -c 32
>
> Before:
>
> struct ag71xx {
> /* size: 384, cachelines: 12, members: 22 */
> /* sum members: 375, holes: 2, sum holes: 9 */
>
> After:
>
> struct ag71xx {
> /* size: 376, cachelines: 12, members: 22 */
> /* last cacheline: 24 bytes */
>
> Signed-off-by: Rosen Penev [Fix typos in the patch
> description]
> Signed-off-by: Rui Salvaterra
> ---
> The ag71xx_ring changes are already part of the upstream driver. However,
> since we're not using it at all yet, let's apply this to our driver for
the time
> being, as David explicitly requests performance numbers before applying it
> upstream [1] (and rightly so, in my opinion).
>
> [1]
> https://lore.kernel.org/netdev/20190725.112108.2287417619951369896.dave
> m...@davemloft.net/
>
> .../net/ethernet/atheros/ag71xx/ag71xx.h | 32 ++-
> 1 file changed, 17 insertions(+), 15 deletions(-)
>
> diff --git
> a/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx.h
> b/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx.h
> index 5ff9439f0d..6ed1f78459 100644
> ---
> a/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx.h
> +++ b/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71x
> +++ x.h
> @@ -107,13 +107,16 @@ struct ag71xx_buf { };
>
> struct ag71xx_ring {
> - struct ag71xx_buf *buf;
> - u8 *descs_cpu;
> - dma_addr_t descs_dma;
> - u16 desc_split;
> - u16 order;
> + /* "Hot" fields in the data path. */
> unsigned intcurr;
> unsigned intdirty;
> +
> + /* "Cold" fields - not used in the data path. */
> + struct ag71xx_buf *buf;
> + u16 order;
> + u16 desc_split;
> + dma_addr_t descs_dma;
> + u8 *descs_cpu;
> };
>
> struct ag71xx_int_stats {
> @@ -151,21 +154,20 @@ struct ag71xx {
>* Critical data related to the per-packet data path are clustered
>* early in this structure to help improve the D-cache footprint.
>*/
> - struct ag71xx_ring rx_ring cacheline_aligned;
> - struct ag71xx_ring tx_ring cacheline_aligned;
> + struct ag71xx_ring rx_ring;
> + u16 rx_buf_size;
> + u16 rx_buf_offset;
> + u32 msg_enable;
>
> + struct ag71xx_ring tx_ring;
> int mac_idx;
> -
> u16 desc_pktlen_mask;
> - u16 rx_buf_size;
> - u8 rx_buf_offset;
> u8 tx_hang_workaround:1;
>
> + struct napi_struct napi;
> struct net_device *dev;
> struct platform_device *pdev;
> spinlock_t lock;
> - struct napi_struct napi;
> - u32 msg_enable;
>
> /*
>* From this point onwards we're not looking at per-packet fields.
> @@ -188,12 +190,12 @@ struct ag71xx {
> unsigned intspeed;
> int duplex;
>
> - struct delayed_work restart_work;
> - struct timer_list oom_timer;
> -
> struct reset_control *mac_reset;
> struct reset_control *mdio_reset;
>
> + struct delayed_work restart_work;
> + struct timer_list oom_timer;
> +
> u32 fifodata[3];
> u32 plldata[3];
> u32 pllreg[3];
> --
> 2.33.0
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Drop support for mtd-mac-address
Hi, about one month ago we replaced the last occurrences of mtd-mac-address in our (master) tree. Since no unexpected problems showed up since then, I'd like to entirely remove support for mtd-mac-address in master now. This will also be helpful with (new) device support submissions since mtd-mac-address will not work anymore for them, so (at least some) people will try to fix that already before submission. Ansuel Smith has prepared the necessary patch(es) here: https://github.com/openwrt/openwrt/pull/4467 I'd like to apply it next weekend, or earlier if we receive some Reviewed-by/Acked-by here. Best Adrian 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: [PATCH] ath79: add old JT-OR750i name to supported devices
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of g...@aiyionpri.me > Sent: Donnerstag, 16. September 2021 14:18 > To: openwrt-devel@lists.openwrt.org > Cc: m...@david-bauer.net; Jan-Niklas Burfeind > Subject: [PATCH] ath79: add old JT-OR750i name to supported devices > > From: Jan-Niklas Burfeind > > Allow forceless upgrade from ar71xx variants. > > Signed-off-by: Jan-Niklas Burfeind > --- > > The device has never been officially part of ar71xx, but has been developed > in the target. > There are a bunch of devices that could profit from this patch and it will do > no > harm to the others. No. I don't think we should start to support every variant somebody out there has developed. (And we don't have any idea what's in there, so essentially there is no way we can say it's "supported"). SUPPORTED_DEVICES should be limited to what "we" have had in the tree. The only exception IMO is when the vendor uses OpenWrt, and direct sysupgrade is possible. Marking this as "rejected". Best Adrian > > target/linux/ath79/image/generic.mk | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/target/linux/ath79/image/generic.mk > b/target/linux/ath79/image/generic.mk > index d8db054312..8c1d3d24e5 100644 > --- a/target/linux/ath79/image/generic.mk > +++ b/target/linux/ath79/image/generic.mk > @@ -1419,6 +1419,7 @@ define Device/joyit_jt-or750i >DEVICE_MODEL := JT-OR750i >DEVICE_PACKAGES := kmod-ath10k-ct ath10k-firmware-qca9887-ct >IMAGE_SIZE := 16000k > + SUPPORTED_DEVICES += jt-or750i > endef > TARGET_DEVICES += joyit_jt-or750i > > -- > 2.33.0 > > > ___ > 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
RE: Build issues gcc10
Hi again, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Rui Salvaterra > Sent: Dienstag, 14. September 2021 00:29 > To: Adrian Schmutzler > Cc: openwrt-devel@lists.openwrt.org > Subject: Re: Build issues gcc10 > > Hi, Adrian, > > On Mon, 13 Sept 2021 at 23:10, Adrian Schmutzler > wrote: > > > > Just had one try before I went to bed, but it appears the problem is that > cc1plus generated by the toolchain has no execute bit set: I've resolved the thing. It turned out to be a RAM virtualization issue. Read the full story below (pasted here FYI and for documentation): I've been using Hyper-V for virtualization of the relevant systems. Hyper-V provides a "Dynamic Memory" setting where one can set a minimum/maximum RAM value, so memory is provided to the machines "by demand" with some buffer. In addition, there is a "Startup RAM" setting that is used for boot etc. where the integration drivers for Hyper-V are not yet available in the guest system. For all relevant systems, Startup RAM had been set to 2048 MiB, and maximum memory was set to 8G or higher. During further investigation of my build logs, I found that - apart from the error reported here previously - I had another error which occurred earlier in the process. I received collect2: fatal error: ld terminated with signal 9 [Killed] during the following command: g++ -no-pie -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o cc1plus \ cp/cp-lang.o c-family/stub-objc.o cp/call.o cp/class.o cp/constexpr.o cp/constraint.o cp/coroutines.o cp/cp-gimplify.o cp/cp-objcp-common.o cp/cp-ubsan.o cp/cvt.o cp/cxx-pretty-print.o cp/decl.o cp/decl2.o cp/dump.o cp/error.o cp/except.o cp/expr.o cp/friend.o cp/init.o cp/lambda.o cp/lex.o cp/logic.o cp/mangle.o cp/method.o cp/name-lookup.o cp/optimize.o cp/parser.o cp/pt.o cp/ptree.o cp/rtti.o cp/search.o cp/semantics.o cp/tree.o cp/typeck.o cp/typeck2.o cp/vtable-class-hierarchy.o attribs.o incpath.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-indentation.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o c-family/c-ubsan.o c-family/known-headers.o c-family/c-attribs.o c-family/c-warn.o c-family/c-spellcheck.o arm-c.o glibc-c.o cc1plus-checksum.o libbackend.a main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/data/openwrt/staging_dir/host/lib -L/data/openwrt/staging_dir/host/lib -L/data/openwrt/staging_dir/host/lib -lmpc -lmpfr -lgmp -rdynamic -ldl -L./../zlib -lz So, effectively, the creation of cc1plus, which is done in this command, has been failing due to insufficient memory. Curiously, the file cc1plus is still created after that step, but missing the proper permissions: ls -al ./build_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-10.3.0_musl_eabi/gcc-10.3.0-final/gcc/cc1plus -rw-r--r-- 1 adsc adsc 244655320 Sep 15 23:00 ./build_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-10.3.0_musl_eabi/gcc-10.3.0-final/gcc/cc1plus Due to that reason, in subsequent builds Make did see the file and did not rerun the command above. Thus, build then only failed later when the gcc checks were investigating the file and found that it was not set up properly. (And hence, looking at it after the n-th try, I didn't find the root cause in the first place). Calling the command manually (in the correct folder) worked (with the same memory setup), and created a file with proper permissions: ls -al cc1plus -rwxr-xr-x 1 adsc adsc 244655320 Sep 15 23:16 cc1plus Note that the size is exactly the same as for the non-executable file after the failure before. (I did not compare contents). After fixing this (i.e. manually running the command), build continued to run. Internet told me that the "collect2 ..." error means insufficient memory. So, since I never reached the maximum level, I tried to increase the "Startup RAM" and found that this seems to be the solution (4G is already fine for -j12). It appears that although Hyper-V does signal that Dynamic Memory is adjusting values, this is not or not fully working inside the guest. Still, it's quite remarkable that the system reproducibly failed for gcc 10 and 11, while it worked for gcc 8 and 9, and all o
RE: Build issues gcc10
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Rui Salvaterra > Sent: Sonntag, 12. September 2021 19:12 > To: Adrian Schmutzler > Cc: openwrt-devel@lists.openwrt.org > Subject: Re: Build issues gcc10 > > Hi, Adrian, > > On Sun, 12 Sept 2021 at 15:15, Adrian Schmutzler > wrote: > > > > I'm having build issues with master and (default) gcc10 on ipq targets. > > I don't know about ipq, but I jumped straight to GCC 11.2. Does it make sense > to bother with 10? That said… > > > xgcc: fatal error: cannot execute 'cc1plus': execvp: No such file or > > directory > > … you seem to be missing the C++ compiler. Just had one try before I went to bed, but it appears the problem is that cc1plus generated by the toolchain has no execute bit set: /data/openwrt/build_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-10.3.0_musl_eabi/gcc-10.3.0-final/./gcc/cc1plus If I chmod +x on that file, the build continues. Best Adrian > > Cheers, > Rui > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: Build issues gcc10
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Stefan Lippers-Hollmann > Sent: Montag, 13. September 2021 00:30 > To: Adrian Schmutzler > Cc: openwrt-devel@lists.openwrt.org > Subject: Re: Build issues gcc10 > > Hi > > On 2021-09-12, Adrian Schmutzler wrote: > > Hi, > > > > I'm having build issues with master and (default) gcc10 on ipq targets. > > Just for reference, I've just (successfully) tried an ipq806x build on a long- > standing, but fully updated, Debian/ unstable host, using gcc-10 on the host I was not able to get it working. I tried various additional packages, but no luck. Could you export a list of installed packages on your (working) machine? Best Adrian > > $ gcc --version > gcc (Debian 10.3.0-10) 10.3.0 > Copyright (C) 2020 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is > NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A > PARTICULAR PURPOSE. > > and for the OpenWrt build > > $ grep CONFIG_GCC_VERSION .config > CONFIG_GCC_VERSION="10.3.0" > > $ git describe > reboot-17502-g0470159552 > > Rather minimal build-config (no feeds installed), roughly matching the > buildbot configs (just omitting the imagebuilder): > > $ ./scripts/diffconfig.sh > CONFIG_TARGET_ipq806x=y > CONFIG_TARGET_ipq806x_generic=y > CONFIG_TARGET_MULTI_PROFILE=y > CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_askey_rt4230w-rev6=y > CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_askey_rt42 > 30w-rev6="" > CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_asrock_g10=y > CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_asrock_g10 > ="" > CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_buffalo_wxr- > 2533dhp=y > CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_buffalo_wx > r-2533dhp="" > CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_compex_wpq864=y > CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_compex_w > pq864="" > CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_edgecore_ecw5410=y > CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_edgecore_ > ecw5410="" > CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_linksys_ea7500-v1=y > CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_linksys_ea7 > 500-v1="" > CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_linksys_ea8500=y > CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_linksys_ea8 > 500="" > CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_nec_wg2600hp=y > CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_nec_wg260 > 0hp="" > CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_nec_wg2600hp3=y > CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_nec_wg260 > 0hp3="" > CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_netgear_d7800=y > CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_netgear_d7 > 800="" > CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_netgear_r7500=y > CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_netgear_r7 > 500="" > CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_netgear_r7500v2=y > CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_netgear_r7 > 500v2="" > CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_netgear_r7800=y > CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_netgear_r7 > 800="" > CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_qcom_ipq8064-ap148- > legacy=y > CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_qcom_ipq8 > 064-ap148-legacy="" > CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_qcom_ipq8064-ap148=y > CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_qcom_ipq8 > 064-ap148="" > CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_qcom_ipq8064-ap161=y > CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_qcom_ipq8 > 064-ap161="" > CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_qcom_ipq8064- > db149=y > CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_qcom_ipq8 > 064-db149="" > CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_tplink_ad7200=y > CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_tplink_ad72 > 00="" > CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_tplink_c2600=y > CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_tplink_c260 > 0="" > CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_tplink_vr2600v=y > CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_tplink_vr26 > 00v="" > CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_ubnt_unifi-ac-hd=y > CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_ubnt_unifi- > ac-hd="" >
RE: Build issues gcc10
> -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Ansuel Smith > Sent: Sonntag, 12. September 2021 19:50 > To: Adrian Schmutzler > Cc: Rui Salvaterra ; OpenWrt Development List > > Subject: Re: Build issues gcc10 > > > > > > -Original Message- > > > From: Ansuel Smith [mailto:ansuels...@gmail.com] > > > Sent: Sonntag, 12. September 2021 19:18 > > > To: Rui Salvaterra > > > Cc: Adrian Schmutzler ; OpenWrt > > > Development List > > > Subject: Re: Build issues gcc10 > > > > > > Il giorno dom 12 set 2021 alle ore 19:16 Rui Salvaterra > > > ha scritto: > > > > > > > > Hi, Adrian, > > > > > > > > On Sun, 12 Sept 2021 at 15:15, Adrian Schmutzler > > > > wrote: > > > > > > > > > > I'm having build issues with master and (default) gcc10 on ipq > > > > > targets. > > > > > > > > I don't know about ipq, but I jumped straight to GCC 11.2. Does it > > > > make sense to bother with 10? That said… > > > > > > > > > xgcc: fatal error: cannot execute 'cc1plus': execvp: No such > > > > > file or directory > > > > > > > > … you seem to be missing the C++ compiler. > > > > > > A missing dependency for the prereq? Could be that they changed the > > > default package for debian 10 and 11 and nobody notice that? > > > > That was my first suspicion as well, but I didn't really have a good idea > what's missing ... > > > > > > Did you try reinstalling build-essential ? Yes, no change. Also tried various other additional apt packages. Apart from that, the problem seems not to be limited to ipq targets. In general, gcc 8 and 9 seem to build fine, and gcc 10 and 11 fail. Best Adrian > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: Build issues gcc10
> -Original Message- > From: Ansuel Smith [mailto:ansuels...@gmail.com] > Sent: Sonntag, 12. September 2021 19:18 > To: Rui Salvaterra > Cc: Adrian Schmutzler ; OpenWrt Development > List > Subject: Re: Build issues gcc10 > > Il giorno dom 12 set 2021 alle ore 19:16 Rui Salvaterra > ha scritto: > > > > Hi, Adrian, > > > > On Sun, 12 Sept 2021 at 15:15, Adrian Schmutzler > > wrote: > > > > > > I'm having build issues with master and (default) gcc10 on ipq targets. > > > > I don't know about ipq, but I jumped straight to GCC 11.2. Does it > > make sense to bother with 10? That said… > > > > > xgcc: fatal error: cannot execute 'cc1plus': execvp: No such file or > > > directory > > > > … you seem to be missing the C++ compiler. > > A missing dependency for the prereq? Could be that they changed the > default package for debian 10 and 11 and nobody notice that? That was my first suspicion as well, but I didn't really have a good idea what's missing ... ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Build issues gcc10
Hi, I'm having build issues with master and (default) gcc10 on ipq targets. Build fails with: true "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CFLAGS=-O2 -I/data/openwrt/staging_dir/host/include " "CXXFLAGS=-g -O2" "CFLAGS_FOR_BUILD=" "CFLAGS_FOR_TARGET=-Os -pipe -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro" "INSTALL=/data/openwrt/staging_dir/host/bin/install -c" "INSTALL_DATA=/data/openwrt/staging_dir/host/bin/install -c -m 644" "INSTALL_PROGRAM=/data/openwrt/staging_dir/host/bin/install -c" "INSTALL_SCRIPT=/data/openwrt/staging_dir/host/bin/install -c" "LDFLAGS=-static-libstdc++ -static-libgcc " "LIBCFLAGS=-O2 -I/data/openwrt/staging_dir/host/include " "LIBCFLAGS_FOR_TARGET=-Os -pipe -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro" "MAKE=make" "MAKEINFO=/data/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-10. 3.0_musl_eabi/gcc-10.3.0/missing makeinfo --split-size=500 --split-size=500 " "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/bash" "EXPECT=expect" "RUNTEST=runtest" "RUNTESTFLAGS=" "exec_prefix=/data/openwrt/staging_dir/toolchain-arm_cortex-a7+neon-vfpv4_gc c-10.3.0_musl_eabi" "infodir=/data/openwrt/staging_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-10 .3.0_musl_eabi/share/info" "libdir=/data/openwrt/staging_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-10. 3.0_musl_eabi/lib" "prefix=/data/openwrt/staging_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-10. 3.0_musl_eabi" "tooldir=/data/openwrt/staging_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-10 .3.0_musl_eabi/arm-openwrt-linux-muslgnueabi" "AR=ar" "AS=as" "CC=gcc" "CXX=g++" "LD=ld" "LIBCFLAGS=-O2 -I/data/openwrt/staging_dir/host/include " "NM=nm" "PICFLAG=" "RANLIB=ranlib" "DESTDIR=" DO=all multi-do # make make[5]: Leaving directory '/data/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-10.3.0_musl_ eabi/gcc-10.3.0-final/zlib' make[5]: Entering directory '/data/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-10.3.0_musl_ eabi/gcc-10.3.0-final/libbacktrace' make all-am make[6]: Entering directory '/data/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-10.3.0_musl_ eabi/gcc-10.3.0-final/libbacktrace' true DO=all multi-do # make make[6]: Leaving directory '/data/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-10.3.0_musl_ eabi/gcc-10.3.0-final/libbacktrace' make[5]: Leaving directory '/data/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-10.3.0_musl_ eabi/gcc-10.3.0-final/libbacktrace' make[5]: Entering directory '/data/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-10.3.0_musl_ eabi/gcc-10.3.0-final/libcpp' test -f config.h || (rm -f stamp-h1 && make stamp-h1) make[5]: Leaving directory '/data/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-10.3.0_musl_ eabi/gcc-10.3.0-final/libcpp' make[5]: Entering directory '/data/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-10.3.0_musl_ eabi/gcc-10.3.0-final/libdecnumber' make[5]: Nothing to be done for 'all'. make[5]: Leaving directory '/data/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-10.3.0_musl_ eabi/gcc-10.3.0-final/libdecnumber' make[5]: Entering directory '/data/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-10.3.0_musl_ eabi/gcc-10.3.0-final/gcc' /data/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-10.3.0_musl_e abi/gcc-10.3.0-final/./gcc/xgcc -B/data/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-10.3.0_musl _eabi/gcc-10.3.0-final/./gcc/ -xc++ -nostdinc /dev/null -S -o /dev/null -fself-test=/data/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-1 0.3.0_musl_eabi/gcc-10.3.0/gcc/testsuite/selftests xgcc: fatal error: cannot execute 'cc1plus': execvp: No such file or directory compilation terminated. make[5]: *** [/data/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-10.3.0_musl_ eabi/gcc-10.3.0/gcc/cp/Make-lang.in:178: s-selftest-c++] Error 1 make[5]: Leaving directory '/data/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-10.3.0_musl_ eabi/gcc-10.3.0-final/gcc' make[4]: *** [Makefile:4397: all-gcc] Error 2 make[4]: Leaving directory '/data/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-10.3.0_musl_ eabi/gcc-10.3.0-final' make[3]: *** [Makefile:961: all] Error 2 make[3]: Leaving directory '/data/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-10.3.0_musl_ eabi/gcc-10.3.0-final' make[2]: *** [Makefile:91: /data/openwrt/build_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-10.3.0_musl_e abi/gcc-10.3.0-final/.built] Error 2 make[2]: Leaving directory '/data/openwrt/toolchain/gcc/final' time: toolchain/gcc/final/compile#1.29#0.21#1.47 ERROR: toolchain/gcc/final failed to build. make[1]: *** [toolchain/Makefile:97: toolchain/gcc/final/compile] Error 1
RE: [PATCH] mvebu/kernel: promote 5.10 to stable
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Paul Spooren
> Sent: Dienstag, 7. September 2021 23:37
> To: Rui Salvaterra ; Daniel Golle
>
> Cc: openwrt-devel@lists.openwrt.org; pepe.schleho...@gmail.com;
> klaus.kudie...@gmail.com; tmn...@gmail.com; ha...@hauke-m.de
> Subject: Re: [PATCH] mvebu/kernel: promote 5.10 to stable
>
>
> On 9/7/21 11:31, Rui Salvaterra wrote:
> > Hi, Daniel,
> >
> > On Tue, 7 Sept 2021 at 22:09, Daniel Golle
wrote:
> >> I'd remove the KERNEL_TESTING_PATCHVER line then until we add 5.14 or
> >> whatever it's going to be.
> > Sure, I didn't know what the usual procedure was, so I just mimicked
> > aparcar. ;)
> > V2 coming up.
>
> This seems to be an ongoing thing, some add it and some remove it, I'm
> happy to make this consistent:
>
> * Remove KERNEL_TESTING_PATCHVER when promoting
>
> or
>
> * Set KERNEL_{,TESTING}_PATCHVER to the same value until a new testing
> Kernel is added
Some prefer not having to add it again, some prefer to have it removed.
In any case, lines are directly next to each other, so nobody should have a
problem with finding out that both are the same if it's kept.
Since there have been different opinions expressed by committers (e.g. I
prefer to keep it), we would technically need a vote on this.
However, I think this is definitely way too unimportant to vote on it. So
I'd just leave it to the submitters' and committers' taste.
Best
Adrian
>
> I'd prefer the former since it removes the feature flag `testing-kernel`,
> therefore I'd update my patch and we should do that for all further
*Kernel
> promotions*. Objections?
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH] base-files: reduce `mkdir` and `sed` calls
Hi Paul, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Paul Spooren > Sent: Mittwoch, 8. September 2021 23:14 > To: openwrt-devel@lists.openwrt.org > Cc: Paul Spooren > Subject: [PATCH] base-files: reduce `mkdir` and `sed` calls > > There is no need in calling `mkdir` every single time, instead give it multiple > folders at once. > > Also there is no need to create a folder (i.e. /etc/) after a sub folder of /etc/ > was already created. > > Additionally there is no need to call the `sed` version replacement script > multiple times with partly the same files. I'd consider to split this into two patches, one for the sed calls and one for the mkdir calls. Apart from that, mostly to share/document my test here: I wondered what happens when an error occurs during multi-arg mkdir, e.g. mkdir -p dir1 dir2 dir3 Actually, if dir2 triggers an error, dir3 will still be created. Thus, this patch is also cosmetic in terms of error handling. You might want to add that information to the commit message (or just ignore it, if that's obvious to anybody except me). Best Adrian > > Signed-off-by: Paul Spooren > --- > package/base-files/Makefile | 42 ++--- > 1 file changed, 21 insertions(+), 21 deletions(-) > > diff --git a/package/base-files/Makefile b/package/base-files/Makefile index > 58ad08c63a..af5c0e6b00 100644 > --- a/package/base-files/Makefile > +++ b/package/base-files/Makefile > @@ -150,37 +150,38 @@ define Package/base-files/install > > $(VERSION_SED_SCRIPT) \ > $(1)/etc/banner \ > + $(1)/etc/device_info \ > + $(1)/etc/openwrt_release \ > $(1)/etc/openwrt_version \ > $(1)/usr/lib/os-release > > - $(VERSION_SED_SCRIPT) \ > - $(1)/etc/openwrt_release \ > - $(1)/etc/device_info \ > - $(1)/usr/lib/os-release > > $(SED) "s#%PATH%#$(TARGET_INIT_PATH)#g" \ > $(1)/sbin/hotplug-call \ > $(1)/etc/preinit \ > $(1)/etc/profile > > - mkdir -p $(1)/CONTROL > - mkdir -p $(1)/dev > - mkdir -p $(1)/etc/config > - mkdir -p $(1)/etc/crontabs > - mkdir -p $(1)/etc/rc.d > - mkdir -p $(1)/overlay > - mkdir -p $(1)/lib/firmware > + mkdir -p \ > + $(1)/CONTROL \ > + $(1)/dev \ > + $(1)/etc/config \ > + $(1)/etc/crontabs \ > + $(1)/etc/rc.d \ > + $(1)/overlay \ > + $(1)/lib/firmware \ > + $(1)/mnt \ > + $(1)/proc \ > + $(1)/tmp \ > + $(1)/usr/lib \ > + $(1)/usr/bin \ > + $(1)/sys \ > + $(1)/www \ > + $(1)/root > + > + $(LN) /proc/mounts $(1)/etc/mtab > $(if $(LIB_SUFFIX),-$(LN) lib $(1)/lib$(LIB_SUFFIX)) > - mkdir -p $(1)/mnt > - mkdir -p $(1)/proc > - mkdir -p $(1)/tmp > - mkdir -p $(1)/usr/lib > $(if $(LIB_SUFFIX),-$(LN) lib $(1)/usr/lib$(LIB_SUFFIX)) > - mkdir -p $(1)/usr/bin > - mkdir -p $(1)/sys > - mkdir -p $(1)/www > - mkdir -p $(1)/root > - $(LN) /proc/mounts $(1)/etc/mtab > + > ifneq ($(CONFIG_TARGET_ROOTFS_PERSIST_VAR),y) > rm -f $(1)/var > $(LN) tmp $(1)/var > @@ -188,7 +189,6 @@ else > mkdir -p $(1)/var > $(LN) /tmp/run $(1)/var/run > endif > - mkdir -p $(1)/etc > $(LN) /tmp/resolv.conf /tmp/TZ /tmp/localtime $(1)/etc/ > > chmod 0600 $(1)/etc/shadow > -- > 2.30.2 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: Question about qca8k dsa driver and path to follow
> Is there any situation where the user would need to decide whether DSA or > swconfig should be used, assuming both are working? A kmod may be Just a side note on this: Having a user choice between drivers should not be a development goal by any means here. If it happens "by accident" due to other changes, there is nothing to say against it. But experience tells it's hard enough to properly support one configuration, so we definitely should not invest work in providing a choice here just for its own sake (always referring to different drivers on a single device, of course). Best Adrian > justified for devices having issues supporting the DSA driver. Another option > is to have DSA/non-DSA subtargets but there seems to be pushback against > this. > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH] sunxi: bring up DSA b53 switch on Lamobo R1
Hi, > --- a/target/linux/sunxi/image/cortexa7.mk > +++ b/target/linux/sunxi/image/cortexa7.mk > @@ -64,7 +64,10 @@ TARGET_DEVICES += friendlyarm_zeropi define > Device/lamobo_lamobo-r1 >DEVICE_VENDOR := Lamobo >DEVICE_MODEL := Lamobo R1 > - DEVICE_PACKAGES:=kmod-ata-sunxi kmod-rtl8192cu swconfig wpad-basic- > wolfssl > + DEVICE_ALT0_VENDOR := Bananapi > + DEVICE_ALT0_MODEL := BPi-R1 > + DEVICE_PACKAGES := kmod-ata-sunxi kmod-rtl8192cu wpad-basic-wolfssl > + DEVICE_COMPAT_VERSION := 2.0 compat_version needs to be set in two places. First for the image, which you did here, and second for the config, which you seem to miss (board.d or uci-default, depending on what kind of change you do). Apart from that, note that changing the major version means that upgrade is not possible at all (even without saving config), and factory flashing is required. I would rather have expected version 1.1 here, since your change should be covered by an update without keeping config (sysupgrade -n)? Apart from that, adding a proper message would help. You should get an overview of all the necessary changes here: https://github.com/openwrt/openwrt/commit/494f12c52df6767ec0fabf2b2fac8f4533 23a4c5 For a single device, you would probably not need the separate Device/dsa-migration definition, though, but could just add the two variables to the device. Best Adrian >SOC := sun7i-a20 > endef > TARGET_DEVICES += lamobo_lamobo-r1 > -- > 2.33.0 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH v3 4/6] at91: add support for sama5d27-wlsom1-ek board
> +define Device/microchip_sama5d27-wlsom1-ek > + $(Device/evaluation-dtb) > + DEVICE_VENDOR := Microchip > + DEVICE_MODEL := SAMA5D27 WSOM1 Ek > + DEVICE_DTS := at91-sama5d27_wlsom1_ek > + SUPPORTED_DEVICES := microchip,sama5d27-wlsom1-ek SUPPORTED_DEVICES can be dropped, this value is generated by default. Best Adrian > + KERNEL_SIZE := 6144k > + $(Device/evaluation-sdimage) > +endef > +TARGET_DEVICES += microchip_sama5d27-wlsom1-ek > + > define Device/microchip_sama5d2-ptc-ek >$(Device/evaluation-dtb) >DEVICE_VENDOR := Microchip > -- > 2.23.0 > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH v3 3/6] at91: add support for sama5d2 icp board
> +define Device/microchip_sama5d2-icp > + $(Device/evaluation-dtb) > + DEVICE_VENDOR := Microchip > + DEVICE_MODEL := SAMA5D2 ICP > + DEVICE_DTS := at91-sama5d2_icp > + SUPPORTED_DEVICES := microchip,sama5d2-icp SUPPORTED_DEVICES can be dropped. This value is generated by the global default. Best Adrian > + KERNEL_SIZE := 6144k > + $(Device/evaluation-sdimage) > +endef > +TARGET_DEVICES += microchip_sama5d2-icp > + > define Device/microchip_sama5d2-xplained >$(Device/evaluation-dtb) >DEVICE_VENDOR := Microchip > -- > 2.23.0 > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH] ath79: add support for TP-Link TL-WA1201 v2
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of bal...@iis.ee.ethz.ch
> Sent: Donnerstag, 2. September 2021 17:07
> To: openwrt-devel@lists.openwrt.org
> Cc: Robert Balas
> Subject: [PATCH] ath79: add support for TP-Link TL-WA1201 v2
>
> From: Robert Balas
>
> This device is a wireless access point working on the 2.4 GHz and 5 GHz
band,
> based on Qualcomm/Atheros QCA9563 + QCA9886.
Looks good, I'll take it.
I've converted to nvmem myself.
One comment/question inline below (not specifically to the author, but to
everybody).
>
> Specification
> - 775 MHz CPU
> - 128 MB of RAM (DDR2)
> - 16 MB of FLASH (SPI NOR)
> - QCA9563: 2.4 GHz 3x3
> - QCA9886: 5 GHz
> - AR8033: 1x 1 Gbs Ethernet
> - 4x LED, WPS factory reset and power button
> - bare UART on PCB (accessible through testpoints)
>
> Methods for Flashing:
> - Apply factory image in OEM firmware web-gui. Wait a minute after the
> progress bar completes and restart the device.
> - Sysupgrade on top of existing OpenWRT image
> - Solder wires onto UART testpoints and attach a terminal.
> Boot the device and press enter to enter u-boot's menu. Then issue the
> following commands
> 1. setenv serverip your-server-ip
> setenv ipaddr your-device-ip
> 2. tftp 0x8006 openwrt-squashfs.bin (Rembember output of size in
> hex, henceforth "sizeinhex")
> 3. erase 0x9f03 +"sizeinhex"
> 4. cp.b 0x8006 0x9f03 0x"sizeinhex"
> 5. reboot
>
> Recover:
> - U-boot serial console
>
> Signed-off-by: Robert Balas
> ---
[...]
> +
> + mdio2: mdio {
> + compatible = "virtual,mdio-gpio";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + gpios = < 3 GPIO_ACTIVE_HIGH>, /* MDC */
> + < 4 GPIO_ACTIVE_HIGH>; /* MDIO */
> +
I wonder whether it matters if address-/size-cells are set before or after
"gpios" here?
Both variants are found in the target.
Best
Adrian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: OpenWrt 21.02 status
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Hauke Mehrtens > Sent: Sonntag, 29. August 2021 11:54 > To: OpenWrt Development List > Cc: John Crispin; Jo-Philipp Wich; Kevin 'ldir' Darbyshire-Bryant > Subject: Re: OpenWrt 21.02 status > > Hi, > > We did the 21.02-rc4, but there is still a problem with flow offloading as > this > was not fixed. The other problems should be fixed now. > > On 7/17/21 5:45 PM, Hauke Mehrtens wrote: > > Currently we still have these problem: > > > > - IPv6 broken with flow offloading (according to reports, potentially > > related to hw flow offloading) > > - PPPoE allegedly broken (according to reports, not fully > > reproducible, likely related to hw flow offloading too) > >- https://bugs.openwrt.org/index.php?do=details_id=3909 > >- https://bugs.openwrt.org/index.php?do=details_id=3835 > > > Some more information can be found here: > https://forum.openwrt.org/t/software-flow-offloading-and-conntrack- > timeouts/74588 > https://bugs.openwrt.org/index.php?do=details_id=3373 > https://bugs.openwrt.org/index.php?do=details_id=3759 > > It could be that this change causes the problems: > https://patchwork.ozlabs.org/project/netdev/patch/20180720130906.27687- > 3-pa...@netfilter.org/ > > I do not know how much time and interest I have in debugging and fixing this > problem. If someone wants to have a closer look into this problem it would > be really nice. even when you can make it easier to reproduce it in a test > environment it would be nice. > > Should we just release with this as a known problem? Although my opinion should not be given much weight in this context, I'd also prefer a "quick" release, for about the same reasons as Hannu has given in his e-mail. As I understand it, disabling offloading will give you a working device, so it's fair enough. Best Adrian > > Other than this problem I am not aware of any other critical problem. > > Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Kernel 5.10: Current targets' state
Hi, I just created an overview of current 5.4->5.10 conversion state. Sharing it FYI below. Note that targets which are not converted or that nobody cares for always have the risk of being dropped. We probably also won't ask a hundred times like last time before doing so. Kernel 5.10 (only): bmips Kernel 5.10 (5.4 still present): bcm27xx gemini Testing 5.10: apm821xx armvirt ath79 bcm53xx bcm63xx imx6 ipq806x kirkwood lantiq malta mpc85xx mvebu mxs octeon oxnas ramips rockchip tegra x86 Mixed: mediatek: mt7622/mt7623: 5.10 mt7629: 5.4, bump prepared: https://git.openwrt.org/?p=openwrt/staging/981213.git;a=summary Kernel 5.4: arc770 archs38 at91 - https://patchwork.ozlabs.org/project/openwrt/list/?series=258951 ath25 bcm47xx bcm4908 ipq40xx - https://github.com/openwrt/openwrt/pull/4134 ipq807x layerscape octeontx omap pistachio realtek - https://github.com/openwrt/openwrt/pull/4448 sunxi - https://github.com/openwrt/openwrt/pull/3953 uml zynq Best Adrian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH 6/6] qoriq: add support for WatchGuard Firebox M300
Hi, > > > >> + reg = <0x00 0x1>; > >> + label = "NOR (RW) LANNER RCW Code"; > > Labels here might need some refactoring, too. > Since we're not really touching anything on the NOR (yet), I prefer to > keep the OEM names for now. What else would you suggest? I would at least remove the "NOR (RW)" prefix, but I won't cry if you don't ... Two other comments from your staging tree: > compatible = "watchguard,firebox-m300", "fsl,T2081QDS"; Is the latter still "correct" for this device? > + DEVICE_PACKAGES := \ > + kmod-hwmon-w83793 kmod-ptp-qoriq kmod-rtc-rs5c372a > +kmod-tpm-i2c-atmel We typically use (just) one tab for hanging indent in image/*.mk files. (I.e. remove the additional spaces before kmod-hwmon... Best Adrian <>___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH 6/6] qoriq: add support for WatchGuard Firebox M300
<>___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH] firmware-utils: seama.h replace LGPL-2.1-or-later boilerplate with SPDX
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Rafal Milecki > Sent: Freitag, 6. August 2021 13:00 > To: openwrt-devel@lists.openwrt.org > Cc: Rafał Miłecki > Subject: [PATCH] firmware-utils: seama.h replace LGPL-2.1-or-later > boilerplate with SPDX > > From: Rafał Miłecki > > This was missed because scancode license scanner was confused by a slightly > different than expected license text (96,75% license score). > > License text included "file" instead of "library" in the main part of the > licensing info. It also used "The GNU C Library" instead of the standard "This > library" in 2nd and 3rd paragraphs. > > The first paragraph clearly mentions LGPL-2.1-or-later and the use of "file" > instead of "library" should not affect licensing. Acked-by: Adrian Schmutzler A ":" is missing after seama.h in the commit title. Note that checkpatch.pl wants /* */ comments here: WARNING: Improper SPDX comment style for 'tools/firmware-utils/src/seama.h', ple ase use '/*' instead #190: FILE: tools/firmware-utils/src/seama.h:1: +// SPDX-License-Identifier: LGPL-2.1-or-later WARNING: Missing or malformed SPDX-License-Identifier tag in line 1 #190: FILE: tools/firmware-utils/src/seama.h:1: +// SPDX-License-Identifier: LGPL-2.1-or-later I'm not sure whether this is valid and whether it would also apply to your recently merged replacements as well. Best Adrian > > Signed-off-by: Rafał Miłecki > --- > tools/firmware-utils/src/seama.h | 16 +--- > 1 file changed, 1 insertion(+), 15 deletions(-) > > diff --git a/tools/firmware-utils/src/seama.h b/tools/firmware- > utils/src/seama.h > index 02683b6e98..bc58338a62 100644 > --- a/tools/firmware-utils/src/seama.h > +++ b/tools/firmware-utils/src/seama.h > @@ -1,24 +1,10 @@ > +// SPDX-License-Identifier: LGPL-2.1-or-later > /* vi: set sw=4 ts=4: */ > /* > * (SEA)ttle i(MA)ge is the image which used in project seattle. > * > * Created by David Hsieh > * Copyright (C) 2008-2009 Alpha Networks, Inc. > - * > - * This file is free software; you can redistribute it and/or > - * modify it under the terms of the GNU Lesser General Public > - * License as published by the Free Software Foundation; either' > - * version 2.1 of the License, or (at your option) any later version. > - * > - * The GNU C Library is distributed in the hope that it will be useful,' > - * but WITHOUT ANY WARRANTY; without even the implied warranty of > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > GNU > - * Lesser General Public License for more details. > - * > - * You should have received a copy of the GNU Lesser General Public > - * License along with the GNU C Library; if not, write to the Free > - * Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA > - * 02111-1307 USA. > */ > > #ifndef __SEAMA_HEADER_FILE__ > -- > 2.26.2 > > > ___ > 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
RE: [PATCH] base-files: add option to make /var persistent
Hi, > --- a/config/Config-images.in > +++ b/config/Config-images.in > @@ -303,4 +303,10 @@ menu "Target Images" > it will be mounted by PARTUUID which makes the kernel > find the > appropriate disk automatically. > > + config TARGET_ROOTFS_PERSIST_VAR > + bool "Make /var persistent" > + default n > + help > + Do not symlink /var to /tmp, so that its content will > + persist across reboots. I'd add information about /var/run here as well, just add something like "(/var/run will still be linked to /tmp/run)" ... Otherwise, the description would be misleading. Best Adrian > endmenu > diff --git a/package/base-files/Makefile b/package/base-files/Makefile index > 5f816a0d1b..687fbc5f78 100644 > --- a/package/base-files/Makefile > +++ b/package/base-files/Makefile > @@ -172,8 +172,13 @@ define Package/base-files/install > mkdir -p $(1)/www > mkdir -p $(1)/root > $(LN) /proc/mounts $(1)/etc/mtab > +ifeq ($(CONFIG_TARGET_ROOTFS_PERSIST_VAR),n) > rm -f $(1)/var > $(LN) tmp $(1)/var > +else > + mkdir $(1)/var > + $(LN) /tmp/run $(1)/var/run > +endif > mkdir -p $(1)/etc > $(LN) /tmp/resolv.conf /tmp/TZ /tmp/localtime $(1)/etc/ > > -- > 2.31.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
RE: [PATCH v6 3/3] mvebu: backport CN9130 dts files changes to 5.4
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of eveans2...@gmail.com
> Sent: Dienstag, 3. August 2021 05:36
> To: openwrt-devel@lists.openwrt.org
> Cc: Ian Chang
> Subject: [PATCH v6 3/3] mvebu: backport CN9130 dts files changes to 5.4
This patch lacks a commit message. What is it good for?
Best
Adrian
>
> From: Ian Chang
>
> Signed-off-by: Ian Chang
> ---
> ...l-Add-support-for-Marvell-CN9130-SoC.patch | 60 +
> ...64-dts-marvell-Add-support-for-CP115.patch | 35 +
> ...ll-Prepare-the-introduction-of-CP115.patch | 1331 +
> ...ell-Add-support-for-AP807-AP807-quad.patch | 110 ++
> ...ell-Add-AP807-quad-cache-description.patch | 91 ++
> ...l-Drop-PCIe-I-O-ranges-from-CP11x-fi.patch | 145 ++
> ...l-Externalize-PCIe-macros-from-CP11x.patch | 137 ++
> 7 files changed, 1909 insertions(+)
> create mode 100644 target/linux/mvebu/patches-5.4/000-v5.5-arm64-dts-
> marvell-Add-support-for-Marvell-CN9130-SoC.patch
> create mode 100644 target/linux/mvebu/patches-5.4/001-v5.5-arm64-dts-
> marvell-Add-support-for-CP115.patch
> create mode 100644 target/linux/mvebu/patches-5.4/002-v5.5-arm64-dts-
> marvell-Prepare-the-introduction-of-CP115.patch
> create mode 100644 target/linux/mvebu/patches-5.4/003-v5.5-arm64-dts-
> marvell-Add-support-for-AP807-AP807-quad.patch
> create mode 100644 target/linux/mvebu/patches-5.4/004-v5.5-arm64-dts-
> marvell-Add-AP807-quad-cache-description.patch
> create mode 100644 target/linux/mvebu/patches-5.4/005-v5.5-arm64-dts-
> marvell-Drop-PCIe-I-O-ranges-from-CP11x-fi.patch
> create mode 100644 target/linux/mvebu/patches-5.4/006-v5.5-arm64-dts-
> marvell-Externalize-PCIe-macros-from-CP11x.patch
>
> diff --git a/target/linux/mvebu/patches-5.4/000-v5.5-arm64-dts-marvell-
> Add-support-for-Marvell-CN9130-SoC.patch b/target/linux/mvebu/patches-
> 5.4/000-v5.5-arm64-dts-marvell-Add-support-for-Marvell-CN9130-SoC.patch
> new file mode 100644
> index 00..d5e5d6e0b2
> --- /dev/null
> +++ b/target/linux/mvebu/patches-5.4/000-v5.5-arm64-dts-marvell-Add-
> support-for-Marvell-CN9130-SoC.patch
> @@ -0,0 +1,60 @@
> +From 6b8970bd8d7a17a648e31f3996d9b21336b4a2cf Mon Sep 17 00:00:00
> 2001
> +From: Miquel Raynal
> +Date: Fri, 4 Oct 2019 16:27:35 +0200
> +Subject: [PATCH] arm64: dts: marvell: Add support for Marvell CN9130 SoC
> + support
> +
> +A CN9130 SoC has one AP807 and one internal CP115.
> +
> +Signed-off-by: Miquel Raynal
> +Signed-off-by: Gregory CLEMENT
> +---
> + arch/arm64/boot/dts/marvell/cn9130.dtsi | 37
> +
> + 1 file changed, 37 insertions(+)
> + create mode 100644 arch/arm64/boot/dts/marvell/cn9130.dtsi
> +
> +diff --git a/arch/arm64/boot/dts/marvell/cn9130.dtsi
> b/arch/arm64/boot/dts/marvell/cn9130.dtsi
> +new file mode 100644
> +index ..a2b7e5ec979d
> +--- /dev/null
> b/arch/arm64/boot/dts/marvell/cn9130.dtsi
> +@@ -0,0 +1,37 @@
> ++// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> ++/*
> ++ * Copyright (C) 2019 Marvell International Ltd.
> ++ *
> ++ * Device tree for the CN9130 SoC.
> ++ */
> ++
> ++#include "armada-ap807-quad.dtsi"
> ++
> ++/ {
> ++model = "Marvell Armada CN9130 SoC";
> ++compatible = "marvell,cn9130", "marvell,armada-ap807-quad",
> ++ "marvell,armada-ap807";
> ++};
> ++
> ++/*
> ++ * Instantiate the internal CP115
> ++ */
> ++
> ++#define CP11X_NAME cp0
> ++#define CP11X_BASE f200
> ++#define CP11X_PCIEx_MEM_BASE(iface) ((iface == 0) ? 0xc000 : \
> ++0xe000 + ((iface - 1) *
> 0x100))
> ++#define CP11X_PCIEx_MEM_SIZE(iface) ((iface == 0) ? 0x1ff0 :
> 0xf0)
> ++#define CP11X_PCIE0_BASEf260
> ++#define CP11X_PCIE1_BASEf262
> ++#define CP11X_PCIE2_BASEf264
> ++
> ++#include "armada-cp115.dtsi"
> ++
> ++#undef CP11X_NAME
> ++#undef CP11X_BASE
> ++#undef CP11X_PCIEx_MEM_BASE
> ++#undef CP11X_PCIEx_MEM_SIZE
> ++#undef CP11X_PCIE0_BASE
> ++#undef CP11X_PCIE1_BASE
> ++#undef CP11X_PCIE2_BASE
> +--
> +2.17.1
> diff --git a/target/linux/mvebu/patches-5.4/001-v5.5-arm64-dts-marvell-
> Add-support-for-CP115.patch b/target/linux/mvebu/patches-5.4/001-v5.5-
> arm64-dts-marvell-Add-support-for-CP115.patch
> new file mode 100644
> index 00..85395a358f
> --- /dev/null
> +++ b/target/linux/mvebu/patches-5.4/001-v5.5-arm64-dts-marvell-Add-
> support-for-CP115.patch
> @@ -0,0 +1,35 @@
> +From 96bb4b31aa660e39fca2bb464b9a9f399bd5b71c Mon Sep 17 00:00:00
> 2001
> +From: Miquel Raynal
> +Date: Fri, 4 Oct 2019 16:27:32 +0200
> +Subject: [PATCH] arm64: dts: marvell: Add support for CP115
> +
> +Create a DTSI file based on the CP11x one. Differences will be
> +described in the near future.
> +
> +Signed-off-by: Miquel Raynal
> +Signed-off-by: Gregory CLEMENT
> +---
> + arch/arm64/boot/dts/marvell/armada-cp115.dtsi | 12
> + 1 file changed, 12 insertions(+)
> + create mode
RE: [PATCH v6 1/3] mvebu: add support for iEi Puzzle-M901/Puzzle-M902
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of eveans2...@gmail.com
> Sent: Dienstag, 3. August 2021 05:36
> To: openwrt-devel@lists.openwrt.org
> Cc: Ian Chang
> Subject: [PATCH v6 1/3] mvebu: add support for iEi Puzzle-M901/Puzzle-
> M902
>
> From: Ian Chang
>
> Hardware specification
> --
> * CN9130 SoC, Quad-core ARMv8 Cortex-72 @ 2200 MHz
> * 4 GB DDR
> * 4 GB eMMC
> * mmcblk0
> - mmcblk0p164M kernel_1
> - mmcblk0p264M kernel_2
> - mmcblk0p3 512M rootfs_1
> - mmcblk0p4 512M rootfs_2
> - mmcblk0p5 512M Reserved
> - mmcblk0p664M Reserved
> - mmcblk0p7 1.8G rootfs_data
>
> * 4 MB (SPI Flash)
> * 6 x 2.5 Gigabit ports (Puzzle-M901)
> - External PHY with 6 ports (AQR112R)
> * 6 x 2.5 Gigabit ports (Puzzle-M902)
> - External PHY with 6 ports (AQR112R)
>3 x 10 Gigabit ports (Puzzle-M902)
> - External PHY with 3 ports (AQR113R)
> * 4 x Front panel LED
> * 1 x USB 3.0
> * Reset button on Rear panel
> * UART (115200 8N1,header on PCB)
>
> Flash instructions:
> The original firmware is based on OpenWrt.
> Flash firmware using LuCI and CLI
>
> Signed-off-by: Ian Chang
This commit should provide full support. Please include the DTS files here,
since adding them later will result in a broken state after this commit.
The fact that 2/3 is not really meaningful is also evidenced by the lack of a
proper commit message.
Best
Adrian
> ---
> .../base-files/etc/board.d/02_network | 6
> .../cortexa72/base-files/lib/upgrade/emmc.sh | 36 +++
> .../base-files/lib/upgrade/platform.sh| 8 +
> target/linux/mvebu/image/cortexa72.mk | 18 ++
> 4 files changed, 68 insertions(+)
> create mode 100644 target/linux/mvebu/cortexa72/base-
> files/lib/upgrade/emmc.sh
>
> diff --git a/target/linux/mvebu/cortexa72/base-
> files/etc/board.d/02_network b/target/linux/mvebu/cortexa72/base-
> files/etc/board.d/02_network
> index 9ab3c8174d..e0a4bc3015 100755
> --- a/target/linux/mvebu/cortexa72/base-files/etc/board.d/02_network
> +++ b/target/linux/mvebu/cortexa72/base-files/etc/board.d/02_network
> @@ -11,6 +11,12 @@ board_config_update
> board=$(board_name)
>
> case "$board" in
> +iei,puzzle-m901)
> + ucidef_set_interfaces_lan_wan "eth1 eth2 eth3 eth4 eth5" "eth0"
> + ;;
> +iei,puzzle-m902)
> + ucidef_set_interfaces_lan_wan "eth1 eth2 eth3 eth4 eth5 eth10
> eth11 eth12" "eth0"
> + ;;
> marvell,armada8040-mcbin-doubleshot|\
> marvell,armada8040-mcbin-singleshot)
> ucidef_set_interfaces_lan_wan "eth0 eth1 eth3" "eth2"
> diff --git a/target/linux/mvebu/cortexa72/base-files/lib/upgrade/emmc.sh
> b/target/linux/mvebu/cortexa72/base-files/lib/upgrade/emmc.sh
> new file mode 100644
> index 00..5e5c356ed6
> --- /dev/null
> +++ b/target/linux/mvebu/cortexa72/base-files/lib/upgrade/emmc.sh
> @@ -0,0 +1,36 @@
> +platform_do_upgrade_emmc() {
> + local board=$(board_name)
> + local diskdev partdev
> +
> + export_bootdevice && export_partdevice diskdev 0 || {
> + v "Unable to determine upgrade device"
> + return 1
> + }
> + sync
> + if [ "$UPGRADE_OPT_SAVE_PARTITIONS" = "1" ]; then
> + get_partitions "/dev/$diskdev" bootdisk
> + v "Extract boot sector from the image"
> + get_image_dd "$1" of=/tmp/image.bs count=1 bs=512b
> + get_partitions /tmp/image.bs image
> + fi
> +
> + #iterate over each partition from the image and write it to the boot
> disk
> + while read part start size; do
> + if export_partdevice partdev $part; then
> + if [ "$partdev" = "mmcblk0p2" ]; then
> + v "Writing image mmcblk0p3 for
> /dev/$partdev $start $size"
> + get_image_dd "$1" of="/dev/mmcblk0p3"
> ibs="512" obs=1M skip="$start" count="$size" conv=fsync
> + elif [ "$partdev" = "mmcblk0p1" ]; then
> + v "Writing image mmcblk0p1 for
> /dev/$partdev $start $size"
> + get_image_dd "$1" of="/dev/$partdev"
> ibs="512" obs=1M skip="$start" count="$size" conv=fsync
> + fi
> + else
> + v "Unable to find partition $part device, skipped."
> + fi
> + done < /tmp/partmap.image
> +
> + v "Writing new UUID to /dev/$diskdev..."
> + get_image_dd "$1" of="/dev/$diskdev" bs=1 skip=440 count=4
> seek=440
> +conv=fsync
> +
> + sleep 1
> +}
> diff --git a/target/linux/mvebu/cortexa72/base-
> files/lib/upgrade/platform.sh b/target/linux/mvebu/cortexa72/base-
> files/lib/upgrade/platform.sh
> index 04ea634097..9a89768d14 100755
> --- a/target/linux/mvebu/cortexa72/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/mvebu/cortexa72/base-files/lib/upgrade/platform.sh
> @@ -9,6 +9,8 @@
RE: OpenWrt 21.02.0 Fourth release candidate
> Hi Arınç, > > Thanks for working on a swconfig to DSA migration script. > I would prefer not to delay the final 21.02 release further. We should fix the > IPv6 flow offload problems and then do the final 21.02 release. +1 > Such a migration script also needs testing, user will have all sorts of > strange > configurations, so I would assume that we would need 2 months for testing > after the initial version is ready. > For 21.02 we should work on the DSA documentation which Rafal and Rich > already did and continue like it is now. Not all targets are migrated to DSA > yet, so a migration script would still be useful for the next release or we > could > integrate it into a later minor release. > > Hauke 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: [PATCH v3] ath79: add support for onion omega
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Jan-Niklas Burfeind
> Sent: Samstag, 14. August 2021 15:55
> To: openwrt-devel@lists.openwrt.org
> Cc: open...@sebastianschaper.net; m...@david-bauer.net; Jan-Niklas
> Burfeind
> Subject: [PATCH v3] ath79: add support for onion omega
some inline comments below.
>
> The Onion Omega is a hardware development platform with built-in WiFi.
>
> https://onioniot.github.io/wiki/
>
> Specifications:
> - QCA9331 @ 400 MHz (MIPS 24Kc Big-Endian Processor)
> - 64MB of DDR2 RAM running at 400 MHz
> - 16MB of on-board flash storage
> - Support for USB 2.0
> - Support for Ethernet at 100 Mbps
> - 802.11b/g/n WiFi at 150 Mbps
> - 18 digital GPIOs
> - A single Serial UART
> - Support for SPI
> - Support for I2S
>
> Flash instructions:
> The device is running OpenWrt upon release using the ar71xx target.
> Both a sysupgrade
> and uploading the factory image using u-boots web-UI do work fine.
>
> Depending on the ssh client, it might be necessary to enable outdated
> KeyExchange methods e.g. in the clients ssh-config:
>
> Host 192.168.1.1
> KexAlgorithms +diffie-hellman-group1-sha1
>
> The stock credentials are: root onioneer
>
> For u-boots web-UI manually configure `192.168.1.2/24` on your computer,
> connect to `192.168.1.1`.
>
> MAC addresses as verified by OEM firmware:
> 2G phy0 label
> LAN eth0 label - 1
>
> LAN is only available in combination with an optional expansion dock.
>
> Based on vendor acked commit:
> commit 5cd49bb067ca ("ar71xx: add support for Onion Omega")
>
> Partly reverts:
> commit fc553c7e4c8e ("ath79: drop unused/incomplete dts")
>
> Signed-off-by: Jan-Niklas Burfeind
> ---
> kmod-usb-chipidea2 is now included as well as tested; usb devices are now
> recognized.
>
> I added the usb vbus section, like the pisen wmm003n has it and verified the
> gpio looking at the ar71xx commit.
>
> target/linux/ath79/dts/ar9331_onion_omega.dts | 137
> ++
> .../generic/base-files/etc/board.d/02_network | 1 +
> target/linux/ath79/image/generic.mk | 13 ++
> 3 files changed, 151 insertions(+)
> create mode 100644 target/linux/ath79/dts/ar9331_onion_omega.dts
>
> diff --git a/target/linux/ath79/dts/ar9331_onion_omega.dts
> b/target/linux/ath79/dts/ar9331_onion_omega.dts
> new file mode 100644
> index 00..43a0b2f392
> --- /dev/null
> +++ b/target/linux/ath79/dts/ar9331_onion_omega.dts
> @@ -0,0 +1,137 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +
> +#include
> +#include
> +
> +#include "ar9331.dtsi"
This include needs to be before the others.
> +
> +/ {
> + model = "Onion Omega";
> + compatible = "onion,omega", "qca,ar9331";
> +
> + aliases {
> + serial0 =
You could add "label-mac-device = " here if your commit message is correct.
> + led-boot = _system;
> + led-failsafe = _system;
> + led-running = _system;
> + led-upgrade = _system;
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led_system: system {
> + label = "amber:system";
> + gpios = < 27 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + keys {
> + compatible = "gpio-keys";
> + poll-interval = <100>;
Poll-interval can be dropped with "gpio-keys".
> +
> + reset {
> + label = "reset";
> + linux,code = ;
> + gpios = < 11 GPIO_ACTIVE_HIGH>;
> + debounce-interval = <60>;
> + };
> + };
> +
> + reg_usb_vbus: reg_usb_vbus {
> + compatible = "regulator-fixed";
> + regulator-name = "usb_vbus";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + gpio = < 8 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +};
> +
> + {
> + clock-frequency = <2500>;
> +};
> +
> + {
> + status = "okay";
> +};
gpio is enabled by default, this block can be dropped.
> +
> + {
> + status = "okay";
> +
> + vbus-supply = <_usb_vbus>;
> + dr_mode = "host";
> +};
> +
> +_phy {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +
> + compatible = "syscon", "simple-mfd";
> +};
> +
> + {
> + status = "okay";
> +
> + nvmem-cells = <_uboot_1fc00>;
> + nvmem-cell-names = "mac-address";
> + mac-address-increment = <(-1)>;
> +
> + gmac-config {
> + device = <>;
> + switch-phy-addr-swap = <4>;
> + switch-phy-swap = <4>;
> + };
> +};
> +
> + {
> + status = "okay";
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + spi-max-frequency = <2500>;
> + reg = <0>;
> +
> + partitions {
> +
RE: [PATCH 8/8] at91: add support for sam9x60-ek board
Hi, > @@ -112,6 +112,15 @@ define Device/atmel_at91sam9x35ek endef > TARGET_DEVICES += atmel_at91sam9x35ek > > +define Device/microchip_sam9x60ek Please move device definition block according to alphabetic sorting. Best Adrian > + $(Device/evaluation-dtb) > + DEVICE_VENDOR := Microchip > + DEVICE_MODEL := SAM9X60-EK > + DEVICE_DTS := at91-sam9x60ek > + $(Device/evaluation-sdimage) > +endef > +TARGET_DEVICES += microchip_sam9x60ek > + > define Device/calamp_lmu5000 >$(Device/production) >DEVICE_VENDOR := CalAmp > -- > 2.23.0 > 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: [PATCH 2/8] at91: add support for sama5d2 icp board
Hi, > diff --git a/target/linux/at91/image/sama5.mk > b/target/linux/at91/image/sama5.mk > index f8e05aae9343..ae3494332139 100644 > --- a/target/linux/at91/image/sama5.mk > +++ b/target/linux/at91/image/sama5.mk > @@ -54,6 +54,17 @@ define Build/at91-sdcard >rm -f $@.img $@.boot $@-uboot.env $@-uboot-env.txt) endef > > +define Device/microchip_sama5d2-icp > + $(Device/evaluation-dtb) > + DEVICE_VENDOR := Microchip > + DEVICE_MODEL := SAMA5D2 ICP > + DEVICE_DTS := at91-sama5d2_icp > + SUPPORTED_DEVICES := microchip,sama5d2-icp SUPPORTED_DEVICES can be dropped here, the value matches the global default calculated from the device node name according to: https://github.com/openwrt/openwrt/blob/master/include/image.mk#L407 This possibly also applies to the other devices submitted, I won't resend for them if that's the case. Best Adrian > + KERNEL_SIZE := 6144k > + $(Device/evaluation-sdimage) > +endef > +TARGET_DEVICES += microchip_sama5d2-icp > + > define Device/microchip_sama5d2-xplained >$(Device/evaluation-dtb) >DEVICE_VENDOR := Microchip > -- > 2.23.0 > 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: [PATCH 6/6] qoriq: add support for WatchGuard Firebox M300
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Stijn Tintel
> Sent: Sonntag, 22. August 2021 01:15
> To: openwrt-devel@lists.openwrt.org
> Subject: [PATCH 6/6] qoriq: add support for WatchGuard Firebox M300
>
> This device is based on NXP's QorIQ T2081QDS board, with a quad-core dual-
> threaded 1.5 GHz ppc64 CPU and 4GB ECC RAM. The board has 5 ethernet
> interfaces, of which 3 are connected to the ethernet ports on the front
> panel. The other 2 are internally connected to a Marvell
> 88E6171 switch; the other 5 ports of this switch are also connected to the
> ethernet ports on the front panel.
>
> Installation: write the sdcard image to an SD card. Stock U-Boot will not
> boot,
> wait for it to fail then run these commands:
>
> setenv wgBootSysA "setenv bootargs root=/dev/mmcblk0p2 rw rootdelay=2
> console=$consoledev,$baudrate fsl_dpaa_fman.fsl_fm_max_frm=1522;
> ext2load mmc 0:1 $fdtaddr image-m300.dtb; ext2load mmc 0:1 $loadaddr
> firebox_m300-kernel.bin; bootm $loadaddr - $fdtaddr"
> saveenv
> reset
>
> The default U-Boot boot entry will now boot OpenWrt from the SD card.
a few mostly cosmetic comments below, with the only real issue at the very
bottom.
Target introduction in 5/6 looked fine.
>
> Signed-off-by: Stijn Tintel
> ---
> .../base-files/lib/preinit/79_move_config | 17 +
> .../qoriq/base-files/lib/upgrade/platform.sh | 38 +++
> .../files/arch/powerpc/boot/dts/fsl/m300.dts | 294 ++
> target/linux/qoriq/image/generic.mk | 13 +
> 4 files changed, 362 insertions(+)
> create mode 100644 target/linux/qoriq/base-
> files/lib/preinit/79_move_config
> create mode 100755 target/linux/qoriq/base-files/lib/upgrade/platform.sh
> create mode 100644
> target/linux/qoriq/files/arch/powerpc/boot/dts/fsl/m300.dts
>
> diff --git a/target/linux/qoriq/base-files/lib/preinit/79_move_config
> b/target/linux/qoriq/base-files/lib/preinit/79_move_config
> new file mode 100644
> index 00..22ec022f6a
> --- /dev/null
> +++ b/target/linux/qoriq/base-files/lib/preinit/79_move_config
> @@ -0,0 +1,17 @@
> +# Copyright (C) 2015 OpenWrt.org
New files should have an SPDX identifier.
> +
> +. /lib/functions.sh
> +. /lib/upgrade/common.sh
> +
> +move_config() {
> + local partdev
> +
> + if export_bootdevice && export_partdevice partdev 1; then
> + mkdir -p /boot
> + mount -o rw,noatime "/dev/$partdev" /boot
> + [ -f "/boot/$BACKUP_FILE" ] && mv -f "/boot/$BACKUP_FILE"
> /
> + umount /boot
> + fi
> +}
> +
> +boot_hook_add preinit_mount_root move_config
> diff --git a/target/linux/qoriq/base-files/lib/upgrade/platform.sh
> b/target/linux/qoriq/base-files/lib/upgrade/platform.sh
> new file mode 100755
> index 00..d88f70e3f6
> --- /dev/null
> +++ b/target/linux/qoriq/base-files/lib/upgrade/platform.sh
> @@ -0,0 +1,38 @@
> +#
> +# Copyright (C) 2011 OpenWrt.org
> +#
> +
> +PART_NAME=firmware
> +REQUIRE_IMAGE_METADATA=1
> +
> +platform_check_image() {
> + case "$(board_name)" in
> + watchguard,firebox-m300)
> + legacy_sdcard_check_image "$1"
> + ;;
> + *)
> + return 0
> + ;;
> + esac
> +}
> +
> +platform_copy_config() {
> + case "$(board_name)" in
> + watchguard,firebox-m300)
> + legacy_sdcard_copy_config "$1"
> + ;;
> + *)
> + return 0
> + esac
> +}
> +
> +platform_do_upgrade() {
> + case "$(board_name)" in
> + watchguard,firebox-m300)
> + legacy_sdcard_do_upgrade "$1"
> + ;;
> + *)
> + default_do_upgrade "$1"
> + ;;
> + esac
> +}
> diff --git a/target/linux/qoriq/files/arch/powerpc/boot/dts/fsl/m300.dts
> b/target/linux/qoriq/files/arch/powerpc/boot/dts/fsl/m300.dts
> new file mode 100644
> index 00..71ff57dcb6
> --- /dev/null
> +++ b/target/linux/qoriq/files/arch/powerpc/boot/dts/fsl/m300.dts
> @@ -0,0 +1,294 @@
> +// SPDX-License-Identifier: BSD-3-Clause OR GPL-2.0-or-later
> +/*
> + * WatchGuard Firebox M300 Device Tree Source
> + * Based on t2081qds.dts from Linux 5.10
> + *
> + * Copyright 2013 - 2015 Freescale Semiconductor Inc.
> + * Copyright 2020 - 2021 Stijn Tintel */
> +
> +/include/ "t208xsi-pre.dtsi"
> +/include/ "t208xqds.dtsi"
> +
> +/ {
> + model = "WatchGuard Firebox M300";
> + compatible = "watchguard,firebox-m300", "fsl,T2081QDS";
I'd add an empty line after these two.
> + #address-cells = <2>;
> + #size-cells = <2>;
Do we need these without a direct subnode?
> + interrupt-parent = <>;
> +
> + aliases {
> + };
Consider dropping the empty node.
> +};
> +
> +// mdio-mux under + its aliases removed. causes crash:
> +// Oops: Machine check, sig: 7 [#1]
> +
> +/include/ "t2081si-post.dtsi"
> +
> +// add stuff below the include to make sure we override whatever is
> +there
> +
> + {
> +
RE: [PATCH 3/6] openssl: add ppc64 support
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Stijn Tintel
> Sent: Sonntag, 22. August 2021 01:15
> To: openwrt-devel@lists.openwrt.org
> Subject: [PATCH 3/6] openssl: add ppc64 support
>
> Backport an upstream patch that adds support for ELFv2 ABI on big endian
> ppc64. As musl only supports ELFv2 ABI on ppc64 regardless of endianness,
> this is required to be able to build OpenSSL for ppc64be.
>
> Modify our targets patch to add linux-powerpc64-openwrt, which will use
> the linux64v2 perlasm scheme. This will probably break the combination
> ppc64 with glibc, but as we really only want to support musl, this shouldn't
> be
> a problem.
Looks like openssl still needs a PKG_RELEASE bump ...
Best
Adrian
>
> Signed-off-by: Stijn Tintel
> ---
> ...m-ppc-xlate.pl-add-linux64v2-flavour.patch | 63 +++
> .../openssl/patches/110-openwrt_targets.patch | 6 +-
> 2 files changed, 68 insertions(+), 1 deletion(-) create mode 100644
> package/libs/openssl/patches/001-crypto-perlasm-ppc-xlate.pl-add-
> linux64v2-flavour.patch
>
> diff --git a/package/libs/openssl/patches/001-crypto-perlasm-ppc-xlate.pl-
> add-linux64v2-flavour.patch b/package/libs/openssl/patches/001-crypto-
> perlasm-ppc-xlate.pl-add-linux64v2-flavour.patch
> new file mode 100644
> index 00..bdc0509f8c
> --- /dev/null
> +++ b/package/libs/openssl/patches/001-crypto-perlasm-ppc-xlate.pl-add-l
> +++ inux64v2-flavour.patch
> @@ -0,0 +1,63 @@
> +From 34ab13b7d8e3e723adb60be8142e38b7c9cd382a Mon Sep 17 00:00:00
> 2001
> +From: Andy Polyakov
> +Date: Sun, 5 May 2019 18:25:50 +0200
> +Subject: [PATCH] crypto/perlasm/ppc-xlate.pl: add linux64v2 flavour
> +MIME-Version: 1.0
> +Content-Type: text/plain; charset=UTF-8
> +Content-Transfer-Encoding: 8bit
> +
> +This is a big endian ELFv2 configuration. ELFv2 was already being used
> +for little endian, and big endian was traditionally ELFv1 but there are
> +practical configurations that use ELFv2 with big endian nowadays
> +(Adélie Linux, Void Linux, possibly Gentoo, etc.)
> +
> +Reviewed-by: Paul Dale
> +Reviewed-by: Richard Levitte (Merged from
> +https://github.com/openssl/openssl/pull/8883)
> +---
> + crypto/perlasm/ppc-xlate.pl | 8
> + 1 file changed, 4 insertions(+), 4 deletions(-)
> +
> +diff --git a/crypto/perlasm/ppc-xlate.pl b/crypto/perlasm/ppc-xlate.pl
> +index e52f2f6ea6..5fcd0526df 100755
> +--- a/crypto/perlasm/ppc-xlate.pl
> b/crypto/perlasm/ppc-xlate.pl
> +@@ -49,7 +49,7 @@ my $globl = sub {
> + /osx/ && do { $name = "_$name";
> + last;
> + };
> +-/linux.*(32|64le)/
> ++/linux.*(32|64(le|v2))/
> + && do { $ret .= ".globl $name";
> + if (!$$type) {
> + $ret .= "\n.type$name,\@function";
> +@@ -80,7 +80,7 @@ my $globl = sub {
> + };
> + my $text = sub {
> + my $ret = ($flavour =~ /aix/) ? ".csect\t.text[PR],7" : ".text";
> +-$ret = ".abiversion 2\n".$ret if ($flavour =~ /linux.*64le/);
> ++$ret = ".abiversion 2\n".$ret if ($flavour =~
> /linux.*64(le|v2)/);
> + $ret;
> + };
> + my $machine = sub {
> +@@ -186,7 +186,7 @@ my $vmr = sub {
> +
> + # Some ABIs specify vrsave, special-purpose register #256, as reserved
> +# for system use.
> +-my $no_vrsave = ($flavour =~ /aix|linux64le/);
> ++my $no_vrsave = ($flavour =~ /aix|linux64(le|v2)/);
> + my $mtspr = sub {
> + my ($f,$idx,$ra) = @_;
> + if ($idx == 256 && $no_vrsave) {
> +@@ -320,7 +320,7 @@ while($line=<>) {
> + if ($label) {
> + my $xlated = ($GLOBALS{$label} or $label);
> + print "$xlated:";
> +-if ($flavour =~ /linux.*64le/) {
> ++if ($flavour =~ /linux.*64(le|v2)/) {
> + if ($TYPES{$label} =~ /function/) {
> + printf "\n.localentry %s,0\n",$xlated;
> + }
> +--
> +2.31.1
> +
> diff --git a/package/libs/openssl/patches/110-openwrt_targets.patch
> b/package/libs/openssl/patches/110-openwrt_targets.patch
> index d0530b4661..828c14d21d 100644
> --- a/package/libs/openssl/patches/110-openwrt_targets.patch
> +++ b/package/libs/openssl/patches/110-openwrt_targets.patch
> @@ -12,7 +12,7 @@ new file mode 100644
> index 00..86a86d31e4
> --- /dev/null
> +++ b/Configurations/25-openwrt.conf
> -@@ -0,0 +1,48 @@
> +@@ -0,0 +1,52 @@
> +## Openwrt "CONFIG_ARCH" matching targets.
> +
> +# The targets need to end in '-openwrt' for the AFALG patch to work @@ -
> 52,6 +52,10 @@ index 00..86a86d31e4
> +"linux-powerpc-openwrt" => {
> +inherit_from=> [ "linux-ppc", "openwrt" ],
> +},
> ++"linux-powerpc64-openwrt" => {
> ++inherit_from=> [ "linux-ppc64", "openwrt" ],
> ++perlasm_scheme => "linux64v2",
> ++},
> +"linux-x86_64-openwrt" => {
> +inherit_from=> [
RE: convert mtd-mac-address to nvmem implementation
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of e9hack
> Sent: Montag, 19. Juli 2021 18:42
> To: Ansuel Smith; ynezz
> Cc: openwrt-devel
> Subject: Re: convert mtd-mac-address to nvmem implementation
>
> Am 19.07.2021 um 16:41 schrieb Ansuel Smith:
> > The dts has been migrated with a script and we decided to remove the
> > dtsi that caused some compilation problem.
> > We still need to take a decision for the device that have dtsi that
> > declare mtd-mac-address using partition tag declared in user dts (dtsi
> > use partition declared in the dts)
>
> For testing, I shifted the uboot partition definition from user dts file to
> the
> main dtsi file. Uboot partition definition is in all user dts files the same.
> MAC
> address's and partition layout looks fine.
I'd say it's desirable not to distribute the partitioning across too many files.
But this case here is an exception anyway, as many/most examples will depend on
art partitions that are not on the beginning and might have different offsets
anyway.
Best
Adrian
>
> Regards,
> Hartmut
>
> diff --git a/target/linux/ath79/dts/qca9558_tplink_archer-c.dtsi
> b/target/linux/ath79/dts/qca9558_tplink_archer-c.dtsi
> index 3f965f5b95..1c72047a3a 100644
> --- a/target/linux/ath79/dts/qca9558_tplink_archer-c.dtsi
> +++ b/target/linux/ath79/dts/qca9558_tplink_archer-c.dtsi
> @@ -146,10 +147,19 @@
> };
> };
>
> + {
> + uboot: partition@0 {
> + label = "u-boot";
> + reg = <0x00 0x02>;
> + read-only;
> + };
> +};
> +
>{
> status = "okay";
>
> - mtd-mac-address = < 0x1fc00>;
> + nvmem-cells = <_uboot_1fc00>;
> + nvmem-cell-names = "mac-address";
> mac-address-increment = <1>;
> phy-handle = <>;
> pll-data = <0x5600 0x0101 0x1616>; @@ -163,7 +173,8
> @@
>{
> status = "okay";
>
> - mtd-mac-address = < 0x1fc00>;
> + nvmem-cells = <_uboot_1fc00>;
> + nvmem-cell-names = "mac-address";
> pll-data = <0x03000101 0x0101 0x1616>;
>
> fixed-link {
> @@ -176,5 +187,17 @@
> status = "okay";
>
> mtd-cal-data = < 0x1000>;
> - mtd-mac-address = < 0x1fc00>;
> + nvmem-cells = <_uboot_1fc00>;
> + nvmem-cell-names = "mac-address";
> };
> +
> + {
> + compatible = "nvmem-cells";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + macaddr_uboot_1fc00: macaddr@1fc00 {
> + reg = <0x1fc00 0x6>;
> + };
> +};
> +
> diff --git a/target/linux/ath79/dts/qca9558_tplink_archer-c7-v2.dts
> b/target/linux/ath79/dts/qca9558_tplink_archer-c7-v2.dts
> index be99b8e3e4..785b4f8675 100644
> --- a/target/linux/ath79/dts/qca9558_tplink_archer-c7-v2.dts
> +++ b/target/linux/ath79/dts/qca9558_tplink_archer-c7-v2.dts
> @@ -25,12 +25,6 @@
> };
>
>{
> - uboot: partition@0 {
> - label = "u-boot";
> - reg = <0x00 0x02>;
> - read-only;
> - };
> -
> partition@2 {
> label = "firmware";
> reg = <0x02 0xfd>;
>
>
>
> ___
> 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
RE: convert mtd-mac-address to nvmem implementation
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Ansuel Smith > Sent: Montag, 19. Juli 2021 16:25 > To: e9hack; ynezz > Cc: openwrt-devel > Subject: convert mtd-mac-address to nvmem implementation > > hi, > some dtsi still use the old implementation as they have to be manually I thought we should not delay updating the majority of devices with this problem. I will take care of the remaining ones as soon as I can, and try to work out a sensible setup for the DTSI/DTS rearrangements. Best Adrian > migrated. Does it cause any problem ? > > > Hi, it looks like, that qca9558_tplink_archer-c.dtsi is missing in > > commit abc17bf (ath79: convert mtd-mac-address to nvmem > > implementation). Regards, Hartmut > > ___ > 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
RE: OpenWrt 21.02 status
> It could happen during early boot stages, after FS are mounted, before > services are started, something similar to uci-defaults, but not in a "run > once" > way. > It would cover both upgrades with confs and restores. We are asking the > user to upgrade without saving confs but nothing will prevent them from > keeping settings while using "sysupgrade -F" nor restoring an 19.07 backup > "manually" into a 21.02. I think an expert dev could solve this one with a 5 > line > script That's what everybody believes until he tries. The problem is how to detect whether the config is old or new. This might be hacked somehow for specific cases, but it's impossible to do in an acceptable way for a generic case. Note that compat 1.0->1.1 does not necessarily mean swconfig->DSA, so we have no general variable that will define which state we are in. There is a reason why nobody provided a DSA migration script (or even tried AFAIK). This horse is dead. (Doing -f without -n is a real world problem. They might pseudo-brick their devices. However, we have no better solution about that at the moment.) Best Adrian > ;-) > > Regards, 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 21.02 status
> -Original Message- > From: Daniel Golle [mailto:dan...@makrotopia.org] > Sent: Montag, 19. Juli 2021 10:13 > To: Adrian Schmutzler > Cc: 'Luiz Angelo Daros de Luca'; 'Hauke Mehrtens'; 'Rich Brown'; 'OpenWrt > Development List'; 'Jo-Philipp Wich'; 'Kevin 'ldir' Darbyshire-Bryant'; 'John > Crispin'; 'Rafał Miłecki' > Subject: Re: OpenWrt 21.02 status > > On Sun, Jul 18, 2021 at 10:30:20PM +0200, Adrian Schmutzler wrote: > > > The last time I tried it was very confusing. When I first read about > > > "new fresh installation", I thought: "install without keeping settings". > > > However, OpenWrt returned an image check failure, even when I did > > > not keep the settings (sysupgrade -n). It was the same type of error > > > (image validation failed) that would happen if I selected the wrong > > > firmware (but maybe with a different content). The only way to > > > install it was forcing the operation, which might also allow an > > > incompatible image to be installed (bricking the device). Please > > > reconsider some form of upgrade path that validates the image and > > > allows the user to upgrade without a force or going back to factory > > > before reinstalling OpenWrt with DSA. Something like "update package > > > foo to version n.m.z or upgrade to 19.07.9 before installing > > > 21.02 for proper image validation". Most users will not be confident to > apply > > > a forced installation. > > > > That would be nice, but unfortunately it's not so easy. The problem is that > the upgrade mechanism is baked into the _old_ image. > > Any upgrade can only do what the old firmware supported. Thus, I was > really glad that I was able to hack this message into the device detection > mechanism at all. Otherwise, we would not have any message at all for old > installations. > > I believe what he meant to say was to make another 19.07.x point release > with an updated sysupgrade mechanism which would improve the situation > when upgrading to 21.02.x and, for example, allow flashing with non- > matching DEVICE_COMPAT_VERSION already when specifying the '-n' flag to > not keep configuration, but not require the '-F' flag which is scary for > regular > users (for good reasons). I see the point of this approach, and I also considered it already when I started this thing. It should work like that if done properly. However, I really do not like to backport fundamental features/feature changes like that. It probably wouldn't even be much work as the code changes itself are few; but changing the sysupgrade mechanism in a .8 point release that might be the last one really does not feel right to me. I will give it a few days of thought... Best Adrian > > > > > > > > > From wiki upgrading to 21.02 page: > > > > > > "Don't worry - If you try to upgrade with the wrong target, > > > sysupgrade will refuse to proceed with an error message like this: > > > Image version mismatch. image 1.1 device 1.0 Please wipe config > > > during upgrade (force required) or reinstall. Config cannot be > > > migrated from swconfig to DSA Image check failed" > > > > > > My experience and the message content indicates that it will show > > > for all migrations from "swconfig" to "DSA" and not only for "wrong > target". > > > > Yes. For the old sysupgrade, we simply match two strings (the board name > from the device against SUPPORTED_DEVICES from the image). Either it's > successful, or it's not. If it's not, the message displays the name of the > SUPPORTED_DEVICES. That's what we got. So I have to hack all of the > message into the SUPPORTED_DEVICES string. > > > > > > > > I tried to start a discussion about it in an email "Usability issues > > > for DSA upgrade" (jun/28) but I got no answer. > > > > We can discuss this for the future, i.e. for updates starting at 21.xx, and > > we > can discuss the exact wording of the message. > > Not saying that I'm fond of it, neither that I'm volunteering to do it, but we > **could** also update 19.07.x > > > > > > > > > It would also be great if we could detect a config from a pre-dsa > > > system and restore everything but skipping or renaming DSA relevant > > > files (nework, > > > wifi?) DSA) with a suffix like '.pre-dsa'. > > > > We had a very long delay due to DSA and nobody was even slightly > interested in creating a migration script. > > For partial migration, I suspect that implementing something here that is >
RE: OpenWrt 21.02 status
> The last time I tried it was very confusing. When I first read about "new > fresh > installation", I thought: "install without keeping settings". > However, OpenWrt returned an image check failure, even when I did not > keep the settings (sysupgrade -n). It was the same type of error (image > validation failed) that would happen if I selected the wrong firmware (but > maybe with a different content). The only way to install it was forcing the > operation, which might also allow an incompatible image to be installed > (bricking the device). Please reconsider some form of upgrade path that > validates the image and allows the user to upgrade without a force or going > back to factory before reinstalling OpenWrt with DSA. Something like > "update package foo to version n.m.z or upgrade to 19.07.9 before installing > 21.02 for proper image validation". Most users will not be confident to apply > a forced installation. That would be nice, but unfortunately it's not so easy. The problem is that the upgrade mechanism is baked into the _old_ image. Any upgrade can only do what the old firmware supported. Thus, I was really glad that I was able to hack this message into the device detection mechanism at all. Otherwise, we would not have any message at all for old installations. > > From wiki upgrading to 21.02 page: > > "Don't worry - If you try to upgrade with the wrong target, sysupgrade will > refuse to proceed with an error message like this: > Image version mismatch. image 1.1 device 1.0 Please wipe config during > upgrade (force required) or reinstall. Config cannot be migrated from > swconfig to DSA Image check failed" > > My experience and the message content indicates that it will show for all > migrations from "swconfig" to "DSA" and not only for "wrong target". Yes. For the old sysupgrade, we simply match two strings (the board name from the device against SUPPORTED_DEVICES from the image). Either it's successful, or it's not. If it's not, the message displays the name of the SUPPORTED_DEVICES. That's what we got. So I have to hack all of the message into the SUPPORTED_DEVICES string. > > I tried to start a discussion about it in an email "Usability issues for DSA > upgrade" (jun/28) but I got no answer. We can discuss this for the future, i.e. for updates starting at 21.xx, and we can discuss the exact wording of the message. > > It would also be great if we could detect a config from a pre-dsa system and > restore everything but skipping or renaming DSA relevant files (nework, > wifi?) DSA) with a suffix like '.pre-dsa'. We had a very long delay due to DSA and nobody was even slightly interested in creating a migration script. For partial migration, I suspect that implementing something here that is general will be much more complicated than just having the user select what he wants/needs. Best Adrian > > DSA is missing a lot of docs. For example: is there a simple, secure way to > detect a system is using DSA for a specific switch (or device)? > Is it possible to exist a device with two switches and only one of them uses > DSA? > > Regards, > > ___ > 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
RE: [PATCH 3/3] at91: add support for sama5d27-wlsom1-ek board
Hi,
> diff --git a/target/linux/at91/image/sama5.mk
> b/target/linux/at91/image/sama5.mk
> index d02d09e835ec..af1ef44dc83a 100644
> --- a/target/linux/at91/image/sama5.mk
> +++ b/target/linux/at91/image/sama5.mk
> @@ -87,6 +87,17 @@ define Device/microchip_sama5d27-som1-ek endef
> TARGET_DEVICES += microchip_sama5d27-som1-ek
>
> +define Device/microchip_sama5d27-wlsom1-ek
> + $(Device/evaluation-dtb)
> + DEVICE_VENDOR := Microchip
> + DEVICE_MODEL := SAMA5D27 WSOM1 Ek
> + DEVICE_DTS := at91-sama5d27_wlsom1_ek
> + SUPPORTED_DEVICES := microchip,sama5d27-wlsom1-ek
SUPPORTED_DEVICES can be dropped here as well, see my other e-mail.
[...]
> ++pinctrl_qspi1_default: qspi1_default {
> ++pinmux = ,
> ++ ,
> ++ ,
> ++ ,
> ++ ,
> ++ ;
> ++bias-pull-up;
> ++};
> ++};
> ++
> +--- /dev/null
> b/arch/arm/boot/dts/at91-sama5d27_wlsom1_ek.dts
Please don't add empty lines at EOF. Just a new line.
Best
Adrian
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: [PATCH 2/3] at91: add support for sama5d2 icp board
Hi, > --- a/target/linux/at91/image/sama5.mk > +++ b/target/linux/at91/image/sama5.mk > @@ -54,6 +54,17 @@ define Build/at91-sdcard >rm -f $@.img $@.boot $@-uboot.env $@-uboot-env.txt) endef > > +define Device/microchip_sama5d2-icp > + $(Device/evaluation-dtb) > + DEVICE_VENDOR := Microchip > + DEVICE_MODEL := SAMA5D2 ICP > + DEVICE_DTS := at91-sama5d2_icp > + SUPPORTED_DEVICES := microchip,sama5d2-icp SUPPORTED_DEVICES can be dropped in this specific case, since it matches the global default: Device node name with "_" -> "," Best Adrian 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: [PATCH v4] mvebu: add support for iEi Puzzle-M901/Puzzle-M902
Hi,
thanks, a few minor cosmetic comments below, since you need to resend anyway.
> diff --git a/target/linux/mvebu/cortexa72/base-files/lib/upgrade/emmc.sh
> b/target/linux/mvebu/cortexa72/base-files/lib/upgrade/emmc.sh
> new file mode 100644
> index 00..90ed7ae79a
> --- /dev/null
> +++ b/target/linux/mvebu/cortexa72/base-files/lib/upgrade/emmc.sh
> @@ -0,0 +1,36 @@
> +platform_do_upgrade_emmc() {
> + local board=$(board_name)
> + local diskdev partdev
> +
> + export_bootdevice && export_partdevice diskdev 0 || {
> + v "Unable to determine upgrade device"
> + return 1
Broken indent.
> + }
> + sync
> + if [ "$UPGRADE_OPT_SAVE_PARTITIONS" = "1" ]; then
> + get_partitions "/dev/$diskdev" bootdisk
> + v "Extract boot sector from the image"
> + get_image_dd "$1" of=/tmp/image.bs count=1 bs=512b
> + get_partitions /tmp/image.bs image
> + fi
> +
> + #iterate over each partition from the image and write it to the boot
> disk
> + while read part start size; do
> + if export_partdevice partdev $part; then
> + if [ "$partdev" = "mmcblk0p2" ]; then
> + v "Writing image mmcblk0p3 for
> /dev/$partdev $start $size"
> + get_image_dd "$1" of="/dev/mmcblk0p3"
> ibs="512" obs=1M skip="$start" count="$size" conv=fsync
> + elif [ "$partdev" = "mmcblk0p1" ]; then
> + v "Writing image mmcblk0p1 for
> /dev/$partdev $start $size"
> + get_image_dd "$1" of="/dev/$partdev"
> ibs="512" obs=1M skip="$start" count="$size" conv=fsync
> + fi
> + else
> + v "Unable to find partition $part device, skipped."
> + fi
> + done < /tmp/partmap.image
> +
> + v "Writing new UUID to /dev/$diskdev..."
> + get_image_dd "$1" of="/dev/$diskdev" bs=1 skip=440 count=4
> seek=440
> +conv=fsync
> +
> + sleep 1
> +}
[...]
> diff --git a/target/linux/mvebu/files/arch/arm64/boot/dts/marvell/cn9131-
> puzzle-m901.dts
> b/target/linux/mvebu/files/arch/arm64/boot/dts/marvell/cn9131-puzzle-
> m901.dts
> new file mode 100644
> index 00..d010b7cc0b
> --- /dev/null
> +++ b/target/linux/mvebu/files/arch/arm64/boot/dts/marvell/cn9131-
> puzzle
> +++ -m901.dts
> @@ -0,0 +1,326 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
(GPL-2.0-or-later OR MIT)
Same for the other DTS file.
> +/*
> + * Copyright (C) 2019 Marvell International Ltd.
> + *
> + * Device tree for the CN9131-DB board.
> + */
> +
> +#include "cn9130.dtsi"
> +
> +#include
> +
[...]
> +_usb3_1 {
> + status = "okay";
> + phys = <_comphy3 1>;
> + phy-names = "usb";
> +};
> +
Unneeded empty line at EOF (same for the other DTS file). Add a newline, but no
empty line.
Best
Adrian
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: [PATCH v7 2/2] dnsmasq: add config option for connmark DNS filtering
> -Original Message- > From: Etan Kissling [mailto:etan.kissl...@gmail.com] > Sent: Sonntag, 11. Juli 2021 00:48 > To: Adrian Schmutzler ; openwrt- > de...@lists.openwrt.org > Cc: 'Kevin Darbyshire-Bryant' ; 'Simon Kelley' > > Subject: Re: [PATCH v7 2/2] dnsmasq: add config option for connmark DNS > filtering > > > > On 11.07.21, 00:40, "Adrian Schmutzler" wrote: > > > is there a special reason why you repeatedly post with multiple > > Signed-off-by? > > This second part of the patch depends on dnsmasq being updated to a new > version. The dnsmasq update revealed some problems which needed to be > addressed, and once resolved, this patch was bundled with new dnsmasq > versions. So, while the final patch of the series stays same, the other ones > keep changing, and I submit all parts so that it shows up cleanly in > Patchwork. But why can't you just decide for one e-mail address and use that for a single signed-off-by line per patch? > > Etan 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: [PATCH v7 2/2] dnsmasq: add config option for connmark DNS filtering
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Etan Kissling
> Sent: Samstag, 10. Juli 2021 00:04
> To: openwrt-devel@lists.openwrt.org
> Cc: Kevin Darbyshire-Bryant ; Simon Kelley
>
> Subject: [PATCH v7 2/2] dnsmasq: add config option for connmark DNS
> filtering
>
> This adds uci support to configure connmark based DNS filtering.
>
> Signed-off-by: Etan Kissling (See
> https://lists.thekelleys.org.uk/pipermail/dnsmasq-
> discuss/2021q2/015151.html)
> Signed-off-by: Etan Kissling
is there a special reason why you repeatedly post with multiple
Signed-off-by?
Best
Adrian
> ---
> v2: Bundle with patch to update dnsmasq.
>
> package/network/services/dnsmasq/files/dnsmasq.init | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/package/network/services/dnsmasq/files/dnsmasq.init
> b/package/network/services/dnsmasq/files/dnsmasq.init
> index f86b4b04f3..d77780f7d5 100644
> --- a/package/network/services/dnsmasq/files/dnsmasq.init
> +++ b/package/network/services/dnsmasq/files/dnsmasq.init
> @@ -172,6 +172,10 @@ append_ipset() {
> xappend "--ipset=$1"
> }
>
> +append_connmark_allowlist() {
> + xappend "--connmark-allowlist=$1"
> +}
> +
> append_interface() {
> network_get_device ifname "$1" || ifname="$1"
> xappend "--interface=$ifname"
> @@ -921,6 +925,14 @@ dnsmasq_start()
> config_list_foreach "$cfg" "rev_server" append_rev_server
> config_list_foreach "$cfg" "address" append_address
> config_list_foreach "$cfg" "ipset" append_ipset
> +
> + local connmark_allowlist_enable
> + config_get connmark_allowlist_enable "$cfg"
> connmark_allowlist_enable 0
> + [ "$connmark_allowlist_enable" -gt 0 ] && {
> + append_parm "$cfg" "connmark_allowlist_enable" "--
> connmark-allowlist-enable"
> + config_list_foreach "$cfg" "connmark_allowlist"
> append_connmark_allowlist
> + }
> +
> [ -n "$BOOT" ] || {
> config_list_foreach "$cfg" "interface" append_interface
> config_list_foreach "$cfg" "notinterface"
> append_notinterface
> --
> 2.30.1 (Apple Git-130)
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH 19.07 4/4] treewide: mark selected packages nonshared
> -Original Message- > From: Giovanni Giacobbi [mailto:giova...@giacobbi.net] > Sent: Freitag, 9. Juli 2021 09:37 > To: Adrian Schmutzler ; 'Paul Spooren' > ; 'Petr Štetiar' ; openwrt- > de...@lists.openwrt.org > Cc: 'Hannu Nyman' > Subject: Re: [PATCH 19.07 4/4] treewide: mark selected packages nonshared > > On 04/07/2021 14:46, Adrian Schmutzler wrote: > >>>PKG_NAME:=json-c > >>>PKG_VERSION:=0.12.1 > >>> -PKG_RELEASE:=3.1 > >>> +PKG_RELEASE:=3.2 > >> I've never seen a non integer release, is there a special reason for this? > > I've also used this as standard scheme for changes in stable branches. The > advantage is that you immediately see up to which version the changes are > shared with master, and when it starts to deviate. > > What would you do then if the upstream version is bumped, but the > patchset/Makefile would still differ between the master and branch? In this I'd have to think about that. But changing PKG_VERSION or PKG_SOURCE_DATE is rare in release branches. Best Adrian > case, you bump PKG_VERSION to 0.12.2, but if you restart the PKG_RELEASE > from 1 for both the branch and the master you end up with two different > "0.12.2-1" packages in let's say 21.02 and 19.07. > 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: [PATCH] gemini: Add hdparm setting
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Linus Walleij > Sent: Montag, 5. Juli 2021 00:01 > To: Sebastian Luft ; Hans Ulli Kroll > ; Hauke Mehrtens ; > Christian Lamparter > Cc: Florian Fainelli ; openwrt-devel@lists.openwrt.org; > Linus Walleij > Subject: [PATCH] gemini: Add hdparm setting > > This uses "hdparm" (if present) to get the harddisk into low power mode on > NAS set-ups. > > Signed-off-by: Linus Walleij > --- > .../linux/gemini/base-files/etc/board.d/03_hdparm | 15 +++ > 1 file changed, 15 insertions(+) > create mode 100755 target/linux/gemini/base-files/etc/board.d/03_hdparm > > diff --git a/target/linux/gemini/base-files/etc/board.d/03_hdparm > b/target/linux/gemini/base-files/etc/board.d/03_hdparm > new file mode 100755 > index ..68d76f0acdf8 > --- /dev/null > +++ b/target/linux/gemini/base-files/etc/board.d/03_hdparm > @@ -0,0 +1,15 @@ > +#!/bin/sh board.d files are not executable anymore. Please remove shebang and execute bit. Please add an SPDX license identifier instead. > +# Spin down drives after one minute if inactive > + > +which hdparm > /dev/null I think using which has been discouraged lately in favor of command -v ... > +if [ ! $? -eq 0 ] ; then "$?" != 0 ? > + exit 0 > +fi > + > +DISKS=`find /dev/sd[a-z] 2>/dev/null` Please use $() instead of backticks. Best Adrian > +for DISK in $DISKS > +do > + if [ -b $DISK ] ; then > + hdparm -S 12 /dev/sda > /dev/null > + fi > +done > -- > 2.31.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
RE: [PATCH v3] cn913x: add support for iEi Puzzle-M901/Puzzle-M902
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of eveans2...@gmail.com
> Sent: Freitag, 2. Juli 2021 13:16
> To: openwrt-devel@lists.openwrt.org
> Cc: Ian Chang
> Subject: [PATCH v3] cn913x: add support for iEi Puzzle-M901/Puzzle-M902
This goes into mvebu target, so the commit title prefix should be "mvebu:"!
Further comments below.
>
> From: Ian Chang
>
> Hardware specification
> --
> * CN9130 SoC, Quad-core ARMv8 Cortex-72 @ 2200 MHz
> * 4 GB DDR
> * 4 GB eMMC
> * mmcblk0
> - mmcblk0p164M kernel_1
> - mmcblk0p264M kernel_2
> - mmcblk0p3 512M rootfs_1
> - mmcblk0p4 512M rootfs_2
> - mmcblk0p5 512M Reserved
> - mmcblk0p664M Reserved
> - mmcblk0p7 1.8G rootfs_data
>
> * 4 MB (SPI Flash)
> * 6 x 2.5 Gigabit ports (Puzzle-M901)
> - External PHY with 6 ports (AQR112R)
> * 6 x 2.5 Gigabit ports (Puzzle-M902)
> - External PHY with 6 ports (AQR112R)
>3 x 10 Gigabit ports (Puzzle-M902)
> - External PHY with 3 ports (AQR113R)
>
> * 4 x Front panel LED
> * 1 x USB 3.0
> * Reset button on Rear panel
> * UART (115200 8N1,header on PCB)
>
> Flash instructions:
> The original firmware is based on OpenWrt.
> Flash firmware using LuCI and CLI
>
> Signed-off-by: Ian Chang
> ---
> .../base-files/etc/board.d/02_network | 6 +
> .../cortexa72/base-files/lib/upgrade/emmc.sh | 40 +++
> .../base-files/lib/upgrade/platform.sh| 8 +
> .../boot/dts/marvell/cn9130-puzzle-m901.dts | 216
> .../boot/dts/marvell/cn9130-puzzle-m902.dts | 236 ++
> .../arm64/boot/dts/marvell/cn9130-puzzle.dtsi | 37 +++
> .../boot/dts/marvell/cn9131-puzzle-m901.dts | 153
> .../boot/dts/marvell/cn9131-puzzle-m902.dts | 136 ++
> .../boot/dts/marvell/cn9132-puzzle-m902.dts | 209
> target/linux/mvebu/image/cortexa72.mk | 20 ++
> 10 files changed, 1061 insertions(+)
> create mode 100644 target/linux/mvebu/cortexa72/base-
> files/lib/upgrade/emmc.sh
> create mode 100644
> target/linux/mvebu/files/arch/arm64/boot/dts/marvell/cn9130-puzzle-
> m901.dts
> create mode 100644
> target/linux/mvebu/files/arch/arm64/boot/dts/marvell/cn9130-puzzle-
> m902.dts
> create mode 100644
> target/linux/mvebu/files/arch/arm64/boot/dts/marvell/cn9130-puzzle.dtsi
> create mode 100644
> target/linux/mvebu/files/arch/arm64/boot/dts/marvell/cn9131-puzzle-
> m901.dts
> create mode 100644
> target/linux/mvebu/files/arch/arm64/boot/dts/marvell/cn9131-puzzle-
> m902.dts
> create mode 100644
> target/linux/mvebu/files/arch/arm64/boot/dts/marvell/cn9132-puzzle-
> m902.dts
>
> diff --git a/target/linux/mvebu/cortexa72/base-
> files/etc/board.d/02_network b/target/linux/mvebu/cortexa72/base-
> files/etc/board.d/02_network
> index 9ab3c8174d..f3c3cda977 100755
> --- a/target/linux/mvebu/cortexa72/base-files/etc/board.d/02_network
> +++ b/target/linux/mvebu/cortexa72/base-files/etc/board.d/02_network
> @@ -21,6 +21,12 @@ marvell,armada8040-db)
> marvell,armada7040-db)
> ucidef_set_interfaces_lan_wan "eth0 eth2" "eth1"
> ;;
> +iei,cn9131-puzzle-m901)
> + ucidef_set_interfaces_lan_wan "eth1 eth2 eth3 eth4 eth5" "eth0"
> + ;;
> +iei,cn9132-puzzle-m902)
> + ucidef_set_interfaces_lan_wan "eth1 eth2 eth3 eth4 eth5 eth10
> eth11 eth12" "eth0"
> + ;;
Please take care of alphabetic sorting. These should be moved before the
various marvell... entries.
> *)
> ucidef_set_interface_lan "eth0"
> ;;
> diff --git a/target/linux/mvebu/cortexa72/base-files/lib/upgrade/emmc.sh
> b/target/linux/mvebu/cortexa72/base-files/lib/upgrade/emmc.sh
> new file mode 100644
> index 00..bd7eea5c22
> --- /dev/null
> +++ b/target/linux/mvebu/cortexa72/base-files/lib/upgrade/emmc.sh
> @@ -0,0 +1,40 @@
> +platform_do_upgrade_emmc() {
> + local board=$(board_name)
> + local diskdev partdev
> +
> + export_bootdevice && export_partdevice diskdev 0 || {
> + v "Unable to determine upgrade device"
> + return 1
Broken indent
> + }
> +
> + sync
> +
> + if [ "$UPGRADE_OPT_SAVE_PARTITIONS" = "1" ]; then
> + get_partitions "/dev/$diskdev" bootdisk
> +
> + v "Extract boot sector from the image"
> + get_image_dd "$1" of=/tmp/image.bs count=1 bs=512b
> +
> + get_partitions /tmp/image.bs image
> + fi
> +
> + #iterate over each partition from the image and write it to the boot
> disk
> + while read part start size; do
> + if export_partdevice partdev $part; then
> + if [ "$partdev" = "mmcblk0p2" ]; then
> + v "Writing image mmcblk0p3 for
> /dev/$partdev $start $size"
> + get_image_dd "$1" of="/dev/mmcblk0p3"
> ibs="512" obs=1M skip="$start" count="$size" conv=fsync
> +
RE: [PATCH 19.07 4/4] treewide: mark selected packages nonshared
> > PKG_NAME:=json-c > > PKG_VERSION:=0.12.1 > > -PKG_RELEASE:=3.1 > > +PKG_RELEASE:=3.2 > I've never seen a non integer release, is there a special reason for this? I've also used this as standard scheme for changes in stable branches. The advantage is that you immediately see up to which version the changes are shared with master, and when it starts to deviate. Best Adrian 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: [PATCH] This patch adds supports for GL-B2200-EMMC.
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Li Zhang
> Sent: Freitag, 2. Juli 2021 10:25
> To: openwrt-devel@lists.openwrt.org
> Cc: Li Zhang
> Subject: [PATCH] This patch adds supports for GL-B2200-EMMC.
this patch has multiple formal issues.
Please visit https://openwrt.org/submitting-patches
and also consider checking out
https://openwrt.org/docs/guide-developer/device-support-policies
Some quick additional content-related comments below.
>
> Specifications:
> - SOC: Qualcomm IPQ4019 ARM Quad-Core
> - RAM: 512 MiB
> - Flash: 16 MiB NOR - SPI0
> - EMMC: 8GB EMMC
> - ETH: Qualcomm QCA8075
> - WLAN1: Qualcomm Atheros QCA4019 2.4GHz 802.11b/g/n 2x2
> - WLAN2: Qualcomm Atheros QCA4019 5GHz 802.11n/ac W2 2x2
> - WLAN3: Qualcomm Atheros QCA9886 5GHz 802.11n/ac W2 2x2
> - INPUT: Reset, WPS
> - LED: Power, Internet
> - UART1: On board pin header near to LED (3.3V, TX, RX, GND), 3.3V
> without pin - 115200 8N1
> - UART2: On board with BLE module
> - SPI1: On board socket for Zigbee module
>
> Update firmware instructions
>
> Pleae update firmware on uboot web(default 192.168.1.1).
> ---
> package/firmware/ipq-wifi/Makefile | 2 +
> .../ipq-wifi/board-glinet_gl-b2200-emmc.qca4019| Bin 0 -> 24316 bytes
> .../ipq-wifi/board-glinet_gl-b2200-emmc.qca9888| Bin 0 -> 12168 bytes
> target/linux/ipq40xx/Makefile | 2 +-
> .../ipq40xx/base-files/etc/board.d/02_network | 5 +
> .../etc/hotplug.d/firmware/11-ath10k-caldata | 3 +
> .../arm/boot/dts/qcom-ipq4019-gl-b2200-emmc.dts| 366
> +
> .../arch/arm/boot/dts/qcom-ipq4029-gl-s1300.dts| 7 -
> target/linux/ipq40xx/image/generic.mk | 27 ++
> .../patches-5.4/901-arm-boot-add-dts-files.patch | 3 +-
> 10 files changed, 406 insertions(+), 9 deletions(-) create mode 100644
> package/firmware/ipq-wifi/board-glinet_gl-b2200-emmc.qca4019
> create mode 100644 package/firmware/ipq-wifi/board-glinet_gl-b2200-
> emmc.qca9888
> create mode 100644 target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-
> ipq4019-gl-b2200-emmc.dts
>
> diff --git a/package/firmware/ipq-wifi/Makefile b/package/firmware/ipq-
> wifi/Makefile
> index e63e3b3..3d02048 100644
> --- a/package/firmware/ipq-wifi/Makefile
> +++ b/package/firmware/ipq-wifi/Makefile
> @@ -39,6 +39,7 @@ ALLWIFIBOARDS:= \
> engenius_emr3500 \
> ezviz_cs-w3-wd1200g-eup \
> glinet_gl-ap1300 \
> + glinet_gl-b2200-emmc \
> glinet_gl-s1300 \
> linksys_ea8300 \
> linksys_mr8300-v0 \
> @@ -125,6 +126,7 @@ $(eval $(call generate-ipq-wifi-
> package,engenius_emd1,EnGenius EMD1)) $(eval $(call generate-ipq-wifi-
> package,engenius_emr3500,EnGenius EMR3500)) $(eval $(call generate-ipq-
> wifi-package,ezviz_cs-w3-wd1200g-eup,EZVIZ CS-W3-WD1200G EUP)) $(eval
> $(call generate-ipq-wifi-package,glinet_gl-ap1300,GL.iNet GL-AP1300))
> +$(eval $(call generate-ipq-wifi-package,glinet_gl-b2200-emmc,GL.iNet
> +GL-B2200-EMMC))
> $(eval $(call generate-ipq-wifi-package,glinet_gl-s1300,GL.iNet GL-S1300))
> $(eval $(call generate-ipq-wifi-package,linksys_ea8300,Linksys EA8300))
> $(eval $(call generate-ipq-wifi-package,linksys_mr8300-v0,Linksys MR8300))
> diff --git a/package/firmware/ipq-wifi/board-glinet_gl-b2200-emmc.qca4019
> b/package/firmware/ipq-wifi/board-glinet_gl-b2200-emmc.qca4019
> new file mode 100644
> index
> ..c4721328e1bbaad8722b3b5f7
> 4c88af6c8c5214d
> GIT binary patch
> literal 24316
> zcmeHPdr(tX8b1jj>SE!BfCzXAAv{7MK%g2V@)iR`u&79YB2YzgYm|rKVdz3TJ}5
> *)
> zpcV`fv<%9lDI(+Ii&(6!ol>>oS(N88y)cV^wS9qmp#v%9$G-
> sD0Ei6#PD9`_69
> zobR0bedm1VcTbXgbAH@66XJs7c8kJ7Q-kBv<1!L~OeO 308ua%%FDMF6c+{+
> z%A~<>7fVZmrTe#r61Bo31!ep3DnB%+qM%G#aQNuf?c(5gK0h=xc-
> xL02{Ib=XTiQ$
> zA);a$4cOE~NxQ1G{0C55QV`C#V3x1mLxBLNlFlxoo^E0K=e|q|qCS x?@3
> z44G_T2d^l1js2Q+BZ22o;4ytoZ`EULP1YR=<=#UF;G}<%NAMU)eY%W!^@yiCf
> !bQ4
> zhL6kAzhDE4Xw+v+hG8v+X>V_DXJ=<)AOPIKXKJCiKs&?a3hRc+!fvL_9HC5Am
> bg;V
> zG>9)7z091<*r2Mh`apJSvS93*s lQ_@}{u?sFh1IlHd3R%Kb07
> z{$T7ARYP@Qb}~FTq-
> w5~X75an9_z!+V4DCsG<6@WhX?+FVC<^uG#p_^a^%>j
> z&;cVHdSNHU*{Om6*j-C?Np^-HRPW$FGrpJ9s-
> e8ZWaeSYVJ04?Ys(=%IItv!te
> zm5~ShGd)wsTgz@pt-5JCaTXl)2@14CHh~o??|d7xXq1$Ri8=c5O_)-
> F&!a
> zn=~lLCHjlL>W|V-
> @ya*8eRH6)V@G3frDxH|>Ef#B1Kdm`@)op9#CSQ*(U*Ir?V^U)
> zD?N{WUBQtMUXoWHbCqM{`cu(MzDn{|$ev&;Go9vjIIe1j7IjD3;7e&7W
> Wp3&)a
> z8lKzOz^~<1da=J!mlf*v;N6{kl*93Xf4*#QZy+US~u42dci5P__$j5Ide
> z3y$#f!qy1YBPqUE6 2BRpZ#{?DF0d91Ttz;KDK
> zO9tWf2-
> Heyn+EZOHwNk@0E!<6m_O6EMmU6hY$9I3x@WLrUbwYL9==)Y?8<0Ybg
> p
> zwn|~33?Abl193;)dG2B-)CqAz MM1=BDK9B#9k8DA=@V1CU
> z(NIKyP6eU9WLlkyNhq9(ic)8tA4?!{MxCEHBOa&+<%QqfdisyG}Ce-
> e
> zp;5djvF;=o=EP7s=odW4mu<-
> h>OsTgJ4Z42YB8xAy;bH^T@Kfz)Eq2X0u)LVN@ftC
> zmWCN%W;Cxzlx846RVV}~1SkY31SkY31XeHt>-
>
[PATCH] treewide: call check-size before append-metadata
sysupgrade metadata is not flashed to the device, so check-size should be called _before_ adding metadata to the image. While at it, do some obvious wrapping improvements. Signed-off-by: Adrian Schmutzler --- target/linux/ath79/image/Makefile | 2 +- target/linux/ath79/image/common-mikrotik.mk | 2 +- target/linux/ath79/image/common-netgear.mk | 10 +++--- target/linux/ath79/image/common-tp-link.mk | 5 ++- target/linux/ath79/image/generic-tp-link.mk | 2 +- target/linux/ath79/image/generic-ubnt.mk| 4 +-- target/linux/ath79/image/generic.mk | 36 + target/linux/ath79/image/nand.mk| 3 +- target/linux/ath79/image/tiny.mk| 3 +- target/linux/ipq40xx/image/generic.mk | 8 ++--- target/linux/ipq40xx/image/mikrotik.mk | 2 +- target/linux/ipq806x/image/Makefile | 2 +- target/linux/lantiq/image/Makefile | 4 +-- target/linux/lantiq/image/ar9.mk| 6 ++-- target/linux/lantiq/image/tp-link.mk| 2 +- target/linux/lantiq/image/vr9.mk| 2 +- target/linux/ramips/image/Makefile | 6 ++-- target/linux/ramips/image/common-tp-link.mk | 10 +++--- target/linux/ramips/image/mt7620.mk | 10 +++--- target/linux/ramips/image/mt7621.mk | 10 +++--- target/linux/ramips/image/rt305x.mk | 6 ++-- target/linux/ramips/image/rt3883.mk | 2 +- target/linux/realtek/image/Makefile | 2 +- 23 files changed, 64 insertions(+), 75 deletions(-) diff --git a/target/linux/ath79/image/Makefile b/target/linux/ath79/image/Makefile index aa8665fbb2..aee4ddf963 100644 --- a/target/linux/ath79/image/Makefile +++ b/target/linux/ath79/image/Makefile @@ -81,7 +81,7 @@ define Device/Default COMPILE := IMAGES := sysupgrade.bin IMAGE/sysupgrade.bin = append-kernel | pad-to (BLOCKSIZE) | \ - append-rootfs | pad-rootfs | append-metadata | check-size + append-rootfs | pad-rootfs | check-size | append-metadata endef include $(SUBTARGET).mk diff --git a/target/linux/ath79/image/common-mikrotik.mk b/target/linux/ath79/image/common-mikrotik.mk index 6e739f2d85..5f5fa7899a 100644 --- a/target/linux/ath79/image/common-mikrotik.mk +++ b/target/linux/ath79/image/common-mikrotik.mk @@ -9,7 +9,7 @@ define Device/mikrotik_nor $(Device/mikrotik) IMAGE/sysupgrade.bin := append-kernel | kernel2minor -s 1024 -e | \ pad-to (BLOCKSIZE) | append-rootfs | pad-rootfs | \ - append-metadata | check-size + check-size | append-metadata endef define Device/mikrotik_nand diff --git a/target/linux/ath79/image/common-netgear.mk b/target/linux/ath79/image/common-netgear.mk index 8a74fdc0c9..5a61caf1f6 100644 --- a/target/linux/ath79/image/common-netgear.mk +++ b/target/linux/ath79/image/common-netgear.mk @@ -32,10 +32,8 @@ define Device/netgear_generic KERNEL := kernel-bin | append-dtb | lzma -d20 | uImage lzma KERNEL_INITRAMFS := kernel-bin | append-dtb | lzma -d20 | uImage lzma IMAGES += factory.img - IMAGE/default := append-kernel | pad-to (BLOCKSIZE) | netgear-squashfs | \ - append-rootfs | pad-rootfs - IMAGE/sysupgrade.bin := $$(IMAGE/default) | append-metadata | \ - check-size - IMAGE/factory.img := $$(IMAGE/default) | netgear-dni | \ - check-size + IMAGE/default := append-kernel | pad-to (BLOCKSIZE) | \ + netgear-squashfs | append-rootfs | pad-rootfs + IMAGE/sysupgrade.bin := $$(IMAGE/default) | check-size | append-metadata + IMAGE/factory.img := $$(IMAGE/default) | netgear-dni | check-size endef diff --git a/target/linux/ath79/image/common-tp-link.mk b/target/linux/ath79/image/common-tp-link.mk index 0b7b0e1935..f1d5614aa7 100644 --- a/target/linux/ath79/image/common-tp-link.mk +++ b/target/linux/ath79/image/common-tp-link.mk @@ -22,8 +22,7 @@ define Device/tplink-v2 TPLINK_HVERSION := 3 KERNEL := kernel-bin | append-dtb | lzma KERNEL_INITRAMFS := kernel-bin | append-dtb | lzma | tplink-v2-header - IMAGE/sysupgrade.bin := tplink-v2-image -s | append-metadata | \ - check-size + IMAGE/sysupgrade.bin := tplink-v2-image -s | check-size | append-metadata endef define Device/tplink-nolzma @@ -74,7 +73,7 @@ define Device/tplink-safeloader KERNEL := kernel-bin | append-dtb | lzma | tplink-v1-header -O KERNEL_INITRAMFS := $$(KERNEL) IMAGE/sysupgrade.bin := append-rootfs | tplink-safeloader sysupgrade | \ - append-metadata | check-size + check-size | append-metadata IMAGE/factory.bin := append-rootfs | tplink-safeloader factory endef diff --git a/target/linux/ath79/image/generic-tp-link.mk b/target/linux/ath79/image/generic-tp-link.mk index 8b228a73d2..99fe86f592 100644 --- a/target/linux/ath79/image/generic-tp-link.mk +++ b/target/linux/ath79/image/generic-tp-link.mk @@ -692,7 +692,7 @@ define Device/tplink_tl-wr2543-v1 DEVICE_PACKAGES := kmod-usb2 kmod-usb-ledtrig-usbport TPLINK_HWID := 0x25430001 IMAGE/sysupgrade.bin
RE: [PATCH] kernel: bpi-r2 uses kmod-ata-ahci for block access
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Pablo Pita > Sent: Dienstag, 15. Juni 2021 16:45 > To: openwrt-devel@lists.openwrt.org > Cc: Pablo Pita > Subject: [PATCH] kernel: bpi-r2 uses kmod-ata-ahci for block access > this is target-specific, so the commit title prefix should be "mediatek:" Best Adrian > Fixes accessing block devices. > kmod-ata-ahci-mtk is used only on R64 board. > > Signed-off-by: Pablo Pita > --- > target/linux/mediatek/image/mt7623.mk | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/target/linux/mediatek/image/mt7623.mk > b/target/linux/mediatek/image/mt7623.mk > index 72758ddbaa..132b603b31 100644 > --- a/target/linux/mediatek/image/mt7623.mk > +++ b/target/linux/mediatek/image/mt7623.mk > @@ -42,7 +42,7 @@ define Device/bpi_bananapi-r2 >DEVICE_MODEL := Banana Pi R2 >DEVICE_DTS := mt7623n-bananapi-bpi-r2 >DEVICE_PACKAGES := kmod-fs-vfat kmod-nls-cp437 kmod-nls-iso8859-1 > kmod-mmc \ > - mkf2fs e2fsprogs kmod-usb-ohci kmod-usb2 kmod-usb3 kmod-ata- > ahci-mtk > + mkf2fs e2fsprogs kmod-usb-ohci kmod-usb2 kmod-usb3 kmod-ata- > ahci >UBOOT_ENVSIZE := 0x2000 >UBOOT_OFFSET := 320k >UBOOT_TARGET := mt7623n_bpir2 > -- > 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
RE: [PATCH 3/3] ath79: add support for MikroTik RouterBOARD 912UAG-2HPnD
Hi,
a few remaining comments below.
> + gpio-export {
> + compatible = "gpio-export";
> +
> + usb_power {
> + label = "power:usb";
gpio-export nodes normally don't have a label property. We have
gpio-export,name instead.
> + gpio-export,name = "power-usb";
> + gpio-export,output = <1>;
> + gpios = < 6 GPIO_ACTIVE_HIGH>;
> + };
> +
> + pcie_power {
> + label = "power:pcie";
> + gpio-export,name = "power-pcie";
> + gpio-export,output = <0>;
> + gpios = < 7 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> +
> + compatible = "qca,ar7100-spi";
> +
> + cs-gpios = <0>, <_latch 0 GPIO_ACTIVE_LOW>;
I still don't think this belongs here. Why would it be the only device
requiring this, while we removed it everywhere else?
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <8000>;
Typically, speeds > 50 MHz require m25p,fast-read?
Best
Adrian
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: [PATCH 21.02 00/11] ramips: mt7621: backport support for 9 devices
Hi again, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Adrian Schmutzler > Sent: Dienstag, 8. Juni 2021 21:25 > To: 'Petr Štetiar' ; openwrt-devel@lists.openwrt.org > Subject: RE: [PATCH 21.02 00/11] ramips: mt7621: backport support for 9 > devices > > Hi Petr, > > > -Original Message- > > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > > On Behalf Of Petr Štetiar > > Sent: Dienstag, 8. Juni 2021 11:45 > > To: openwrt-devel@lists.openwrt.org > > Cc: Petr Štetiar > > Subject: [PATCH 21.02 00/11] ramips: mt7621: backport support for 9 > > devices > > > > Hi, > > > > Tee has asked today about backport for Linksys EA8100v1 on IRC, I've > > noticed another such request in PR#4236[1] and decided to backport > > most of the new devices as it saves time during rebasing/cherry-picks, > review etc. > > > > All those backports are straight and clean cherry picks from master, > > no modifications has been done, just simple Makefile merge conflict > > has been resolved on "firmware-utils: zytrx: Add util for ZyXEL specific > header". > > > > I've just build tested[2] that testing/mt7621-21.02-rc2-backports[3] > > branch and provided all build artifacts like firmware images and > > packages for download[4] to make testing easier. > > > > Would be nice to get some feedback and ideally your `Tested-by:` for > > particular device. Thanks! > > > > Thanks for taking of this. > > I've not kept track of the backport-relevant changes over the last months. > However, I did a quick scan of /target/linux/ramips's git history. The only > config-wise thing I found was the selective dependency for kmod-usb-serial: > https://github.com/openwrt/openwrt/commit/9397b22df1473f315552578b5 > 8322db7f7750361 Since it was applying without any issues, I've just quickly cherry-picked the commit, so the kmod-usb-serial issue is resolved. Best Adrian > > This was only added in master and affects ZyXEL NR7101 as far as I can tell, > which will lack kmod-usb-serial in 21.02 unless added manually. > Of course, we might as well just cherry-pick the referenced commit if it > applies without too much work. In any case, not a big problem. > > Note that I only checked config-/DTS-related patches, I don't know if there > are any driver- or kernel-related changes that would cause problems. > > Best > > Adrian > > > > > > 1. https://github.com/openwrt/openwrt/pull/4236 > > 2. https://gitlab.com/ynezz/openwrt/-/jobs/1326795722 > > 3. > > https://git.openwrt.org/?p=openwrt/staging/ynezz.git;a=shortlog;h=refs > > /he ads/testing/mt7621-21.02-rc2-backports > > 4. > > https://foo.true.cz/minio/openwrt/staging-builds/testing-mt7621-21-02- > > rc2-backports/2c462a29/ramips-mt7621/bin > > > > > > Cheers, > > > > Petr > > > > Aashish Kulkarni (1): > > ramips: add support for Linksys E5600 > > > > Andreas Böhler (1): > > ramips: Add support for SERCOMM NA502 > > > > Bjørn Mork (2): > > firmware-utils: zytrx: Add util for ZyXEL specific header > > ramips: mt7621: Add support for ZyXEL NR7101 > > > > Chukun Pan (1): > > ramips: add support for JCG Q20 > > > > Georgi Vlaev (1): > > ramips: add support for TP-Link Archer C6U v1 (EU) > > > > Jonathan Sturges (1): > > ramips: add support for Amped Wireless ALLY router and extender > > > > Kevin Darbyshire-Bryant (1): > > firmware-utils: fix coverity zytrx.c resource leak > > > > Leon M. George (1): > > ramips: add support for cudy WR2100 > > > > Tee Hao Wei (1): > > ramips: add support for Linksys EA8100 v1 > > > > Vinay Patil (1): > > ramips: add support for TP-Link Archer A6 v3 > > > > package/boot/uboot-envtools/files/ramips | 13 + > > .../dts/mt7621_ampedwireless_ally-00x19k.dts | 21 ++ > > .../dts/mt7621_ampedwireless_ally-r1900k.dts | 32 +++ > > .../ramips/dts/mt7621_ampedwireless_ally.dtsi | 179 ++ > > .../linux/ramips/dts/mt7621_cudy_wr2100.dts | 201 +++ > > target/linux/ramips/dts/mt7621_jcg_q20.dts| 175 ++ > > .../linux/ramips/dts/mt7621_linksys_e5600.dts | 182 ++ > > .../ramips/dts/mt7621_linksys_ea8100-v1.dts | 8 + > > .../linux/ramips/dts/mt7621_sercomm_na502.dts | 212 > > > .../ramips/dts/mt7621_tplink_archer-a6-v3.dts | 188 +++ > > .../dts/mt7621_tplink_arche
RE: [PATCH 21.02 00/11] ramips: mt7621: backport support for 9 devices
Hi Petr, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Petr Štetiar > Sent: Dienstag, 8. Juni 2021 11:45 > To: openwrt-devel@lists.openwrt.org > Cc: Petr Štetiar > Subject: [PATCH 21.02 00/11] ramips: mt7621: backport support for 9 devices > > Hi, > > Tee has asked today about backport for Linksys EA8100v1 on IRC, I've noticed > another such request in PR#4236[1] and decided to backport most of the > new devices as it saves time during rebasing/cherry-picks, review etc. > > All those backports are straight and clean cherry picks from master, no > modifications has been done, just simple Makefile merge conflict has been > resolved on "firmware-utils: zytrx: Add util for ZyXEL specific header". > > I've just build tested[2] that testing/mt7621-21.02-rc2-backports[3] branch > and provided all build artifacts like firmware images and packages for > download[4] to make testing easier. > > Would be nice to get some feedback and ideally your `Tested-by:` for > particular device. Thanks! > Thanks for taking of this. I've not kept track of the backport-relevant changes over the last months. However, I did a quick scan of /target/linux/ramips's git history. The only config-wise thing I found was the selective dependency for kmod-usb-serial: https://github.com/openwrt/openwrt/commit/9397b22df1473f315552578b58322db7f7750361 This was only added in master and affects ZyXEL NR7101 as far as I can tell, which will lack kmod-usb-serial in 21.02 unless added manually. Of course, we might as well just cherry-pick the referenced commit if it applies without too much work. In any case, not a big problem. Note that I only checked config-/DTS-related patches, I don't know if there are any driver- or kernel-related changes that would cause problems. Best Adrian > > 1. https://github.com/openwrt/openwrt/pull/4236 > 2. https://gitlab.com/ynezz/openwrt/-/jobs/1326795722 > 3. > https://git.openwrt.org/?p=openwrt/staging/ynezz.git;a=shortlog;h=refs/he > ads/testing/mt7621-21.02-rc2-backports > 4. https://foo.true.cz/minio/openwrt/staging-builds/testing-mt7621-21-02- > rc2-backports/2c462a29/ramips-mt7621/bin > > > Cheers, > > Petr > > Aashish Kulkarni (1): > ramips: add support for Linksys E5600 > > Andreas Böhler (1): > ramips: Add support for SERCOMM NA502 > > Bjørn Mork (2): > firmware-utils: zytrx: Add util for ZyXEL specific header > ramips: mt7621: Add support for ZyXEL NR7101 > > Chukun Pan (1): > ramips: add support for JCG Q20 > > Georgi Vlaev (1): > ramips: add support for TP-Link Archer C6U v1 (EU) > > Jonathan Sturges (1): > ramips: add support for Amped Wireless ALLY router and extender > > Kevin Darbyshire-Bryant (1): > firmware-utils: fix coverity zytrx.c resource leak > > Leon M. George (1): > ramips: add support for cudy WR2100 > > Tee Hao Wei (1): > ramips: add support for Linksys EA8100 v1 > > Vinay Patil (1): > ramips: add support for TP-Link Archer A6 v3 > > package/boot/uboot-envtools/files/ramips | 13 + > .../dts/mt7621_ampedwireless_ally-00x19k.dts | 21 ++ > .../dts/mt7621_ampedwireless_ally-r1900k.dts | 32 +++ > .../ramips/dts/mt7621_ampedwireless_ally.dtsi | 179 ++ > .../linux/ramips/dts/mt7621_cudy_wr2100.dts | 201 +++ > target/linux/ramips/dts/mt7621_jcg_q20.dts| 175 ++ > .../linux/ramips/dts/mt7621_linksys_e5600.dts | 182 ++ > .../ramips/dts/mt7621_linksys_ea8100-v1.dts | 8 + > .../linux/ramips/dts/mt7621_sercomm_na502.dts | 212 > .../ramips/dts/mt7621_tplink_archer-a6-v3.dts | 188 +++ > .../dts/mt7621_tplink_archer-c6u-v1.dts | 213 > .../linux/ramips/dts/mt7621_zyxel_nr7101.dts | 164 + > target/linux/ramips/image/mt7621.mk | 148 > .../mt7621/base-files/etc/board.d/01_leds | 18 +- > .../mt7621/base-files/etc/board.d/02_network | 48 ++-- > .../base-files/etc/board.d/03_gpio_switches | 3 + > .../etc/hotplug.d/ieee80211/10_fix_wifi_mac | 8 +- > .../mt7621/base-files/etc/init.d/bootcount| 9 +- > .../mt7621/base-files/lib/upgrade/platform.sh | 18 ++ > tools/firmware-utils/Makefile | 1 + > tools/firmware-utils/src/tplink-safeloader.c | 75 +- > tools/firmware-utils/src/zytrx.c | 228 ++ > 22 files changed, 2125 insertions(+), 19 deletions(-) create mode 100644 > target/linux/ramips/dts/mt7621_ampedwireless_ally-00x19k.dts > create mode 100644 target/linux/ramips/dts/mt7621_ampedwireless_ally- > r1900k.dts > create mode 100644 > target/linux/ramips/dts/mt7621_ampedwireless_ally.dtsi > create mode 100644 target/linux/ramips/dts/mt7621_cudy_wr2100.dts > create mode 100644 target/linux/ramips/dts/mt7621_jcg_q20.dts > create mode 100644 target/linux/ramips/dts/mt7621_linksys_e5600.dts > create mode 100644
RE: [PATCH] cn913x: add support for iEi Puzzle-M901/Puzzle-M902
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of eveans2...@gmail.com
> Sent: Sonntag, 6. Juni 2021 23:56
> To: openwrt-devel@lists.openwrt.org
> Cc: Ian Chang
> Subject: [PATCH] cn913x: add support for iEi Puzzle-M901/Puzzle-M902
Looks like you sent in an early alpha-state patch.
Please remove all the unfinished/debugging stuff from the DTS and/or label this
as RFC.
A few selected comments below.
>
> From: Ian Chang
>
> Hardware specification
> --
> * CN9130 SoC, Quad-core ARMv8 Cortex-72 @ 2200 MHz
> * 4 GB DDR
> * 4 GB eMMC
> mmcblk0
> ├─mmcblk0p164M kernel_1
> ├─mmcblk0p264M kernel_2
> ├─mmcblk0p3 512M rootfs_1
> ├─mmcblk0p4 512M rootfs_2
> ├─mmcblk0p5 512M Reserved
> ├─mmcblk0p664M Reserved
> └─mmcblk0p7 1.8G rootfs_data
>
> * 4 MB (SPI Flash)
> * 6 x 2.5 Gigabit ports (Puzzle-M901)
> - External PHY with 6 ports (AQR112R)
> * 6 x 2.5 Gigabit ports (Puzzle-M902)
> - External PHY with 6 ports (AQR112R)
>3 x 10 Gigabit ports (Puzzle-M902)
> - External PHY with 3 ports (AQR113R)
>
> * 4 x Front panel LED
> * 1 x USB 3.0
> * Reset button on Rear panel
> * UART (115200 8N1,header on PCB)
Commit message lacks flashing instructions.
[...]
> --- /dev/null
> +++ b/target/linux/mvebu/files/arch/arm64/boot/dts/marvell/puzzle-
> armada
> +++ -common.dtsi
> @@ -0,0 +1,11 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
It's "GPL-2.0-or-later OR MIT".
> + cp0_sfp_eth0: sfp-eth@0 {
> +
> + /*
> + * SFP cages are unconnected on early PCBs because of an
> the I2C
> + * lanes not being connected. Prevent the port for being
> + * unusable by disabling the SFP node.
> + */
> +/* status = "disabled"; */
Remove debugging stuff like this.
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> +_uart0 {
> +status = "okay";
Indent should be only tabs in DTS.
> + cp0_spi0_pins: cp0-spi-pins-0 {
> + marvell,pins = "mpp13", "mpp14", "mpp15", "mpp16";
> + marvell,function = "spi1";
> + };
> + };
> +};
> \ No newline at end of file
Please add the newlines ...
> diff --git a/target/linux/mvebu/files/arch/arm64/boot/dts/marvell/puzzle-
> m901-cn9131-db.dts
> b/target/linux/mvebu/files/arch/arm64/boot/dts/marvell/puzzle-m901-
> cn9131-db.dts
> new file mode 100644
> index 00..d6879613b6
> --- /dev/null
> +++ b/target/linux/mvebu/files/arch/arm64/boot/dts/marvell/puzzle-m901-
> c
> +++ n9131-db.dts
> @@ -0,0 +1,182 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (C) 2019 Marvell International Ltd.
> + *
> + * Device tree for the CN9131-DB board.
> + */
> +
> +#include "puzzle-m901-cn9130-db.dts"
Deriving one dts from another is bad practice. That's what DTSI files are for.
> +
> +/ {
> + model = "Puzzle-M901";
> + compatible = "marvell,cn9131", "marvell,cn9130",
> + "marvell,armada-ap807-quad", "marvell,armada-ap807";
Why is model and compatible completely different. Please decide for one name
and then use it consistently.
> +
> + aliases {
> + i2c0 = _i2c0;
> + ethernet3 = _eth0;
> + ethernet4 = _eth1;
> + ethernet5 = _eth2;
> + gpio3 = _gpio1;
> +gpio4 = _gpio2;
Indent .
> diff --git a/target/linux/mvebu/image/cortexa72.mk
> b/target/linux/mvebu/image/cortexa72.mk
> index 1440c07a0b..c04ad2ae9e 100644
> --- a/target/linux/mvebu/image/cortexa72.mk
> +++ b/target/linux/mvebu/image/cortexa72.mk
> @@ -43,3 +43,27 @@ define Device/marvell_macchiatobin-singleshot
>SUPPORTED_DEVICES := marvell,armada8040-mcbin-singleshot
> endef
> TARGET_DEVICES += marvell_macchiatobin-singleshot
> +
> +define Device/marvell_puzzle-m901-cn9131-db
> + $(call Device/Default-arm64)
> + DEVICE_VENDOR := iEi
> + DEVICE_MODEL := Puzzle-M901
> + DEVICE_DTS := puzzle-m901-cn9131-db
Please name the DTS file properly so the default DEVICE_DTS can be used (and
the one in device definition dropped).
> + IMAGE/sdcard.img.gz := boot-img-ext4 | sdcard-img-ext4 | gzip |
> +append-metadata
> + IMAGES += factory.bin
> + IMAGE/factory.bin := append-kernel | pad-to 64k
> + SUPPORTED_DEVICES :=marvell,cn9131 marvell,puzzle-m901-cn9131-db
One should be enough. It should be the one autoassigned, i.e. the device node
name with "," instead of "_".
Best
Adrian
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: Inconsistencies in include/image.mk
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Philip Prindeville > Sent: Donnerstag, 3. Juni 2021 07:23 > To: OpenWrt Development List > Subject: Inconsistencies in include/image.mk > > Hi, > > I was looking at this with Paul this afternoon, and noticed a few issues worth > fixing in include/image.mk after reviewing the DEVICE_PACKAGES PR he sent > out. I've not checked it in detail, but it looks to me like you are mixing TARGET and DEVICE variables here. IIRC IMG_PREFIX is a target-based, device-independent variable, so it should not be set based on a device-dependent PROFILE_something variable. Best Adrian > > The first part is how IMG_PREFIX is derived: > > IMG_PREFIX_EXTRA:=$(if $(EXTRA_IMAGE_NAME),$(call > sanitize,$(EXTRA_IMAGE_NAME))-) IMG_PREFIX_VERNUM:=$(if > $(CONFIG_VERSION_FILENAMES),$(call sanitize,$(VERSION_NUMBER))-) > IMG_PREFIX_VERCODE:=$(if $(CONFIG_VERSION_CODE_FILENAMES),$(call > sanitize,$(VERSION_CODE))-) > > IMG_PREFIX:=$(VERSION_DIST_SANITIZED)- > $(IMG_PREFIX_VERNUM)$(IMG_PREFIX_VERCODE)$(IMG_PREFIX_EXTRA)$ > (BOARD)$(if $(SUBTARGET),-$(SUBTARGET)) IMG_ROOTFS:=$(IMG_PREFIX)- > rootfs IMG_COMBINED:=$(IMG_PREFIX)-combined > > But we don't append -$(PROFILE_SANITIZED) to it (if set), adding it later > here: > > define Image/Manifest > $(call opkg,$(TARGET_DIR_ORIG)) list-installed > \ > $(BIN_DIR)/$(IMG_PREFIX)$(if $(PROFILE_SANITIZED),- > $(PROFILE_SANITIZED)).manifest > endef > > And here: > > ifdef CONFIG_TARGET_ROOTFS_TARGZ > define Image/Build/targz > $(TAR) -cp --numeric-owner --owner=0 --group=0 --mode=a-s -- > sort=name \ > $(if $(SOURCE_DATE_EPOCH),-- > mtime="@$(SOURCE_DATE_EPOCH)") \ > -C $(TARGET_DIR)/ . | gzip -9n > > $(BIN_DIR)/$(IMG_PREFIX)$(if $(PROFILE_SANITIZED),- > $(PROFILE_SANITIZED))-rootfs.tar.gz > endef > endif > > Note that we're also adding the suffix -rootfs, but not using the > $(IMG_ROOTFS) definition made up at the top. > > Conversely, here: > > ifdef CONFIG_TARGET_ROOTFS_CPIOGZ > define Image/Build/cpiogz > ( cd $(TARGET_DIR); find . | $(STAGING_DIR_HOST)/bin/cpio -o -H > newc -R 0:0 | gzip -9n >$(BIN_DIR)/$(IMG_ROOTFS).cpio.gz ) > endef > endif > > We use $(IMG_ROOTFS) which doesn't include $(PROFILE_SANITIZED)... but > we do use $(PROFILE_SANITIZED) in Image/Build/targz. I don't see why the > two cases aren't handled in the same way. > > Either $(PROFILE_SANITIZED) is important enough to be included in > everything (including cpio.gz images and manifests) or it's not. > > Creating a PR to address this: > > https://github.com/openwrt/openwrt/pull/4223 > > I don't know how to get good coverage of this change with CI/CD since that > seems to only happen with PR's for "packages", but not "openwrt". > > Any suggestions? > > Thanks, > > -Philip > > > > ___ > 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
RE: [RFC v2 3/3] ath79: add support for Mikrotik RouterBoard 912G
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Koen Vandeputte > Sent: Donnerstag, 27. Mai 2021 13:52 > To: Adrian Schmutzler ; 'Denis Kalashnikov' > ; openwrt-devel@lists.openwrt.org > Cc: 'Gabor Juhos' ; 'Sergey Ryazanov' > > Subject: Re: [RFC v2 3/3] ath79: add support for Mikrotik RouterBoard 912G > > > On 23.05.21 11:01, Adrian Schmutzler wrote: > > ... > >> diff --git a/target/linux/ath79/image/mikrotik.mk > >> b/target/linux/ath79/image/mikrotik.mk > >> index 74f8603b5a..0072ec527d 100644 > >> --- a/target/linux/ath79/image/mikrotik.mk > >> +++ b/target/linux/ath79/image/mikrotik.mk > >> @@ -9,6 +9,15 @@ define Device/mikrotik_routerboard-493g endef > >> TARGET_DEVICES += mikrotik_routerboard-493g > >> > >> +define Device/mikrotik_routerboard-912g > >> + $(Device/mikrotik_nand) > >> + SOC := ar9342 > >> + DEVICE_MODEL := RouterBOARD 912G > >> + DEVICE_PACKAGES += kmod-usb-ehci kmod-usb2 kmod-gpio-beeper > >> + SUPPORTED_DEVICES += rb-912uag-5hpnd rb-912uag-2hpnd endef > > So, both have exactly the same setup as implemented here? > > > > Best > > > > Adrian > > > yes. > > I personally use rb-912uag-5hpnd board. > The hardware is identical with the exception of the band used. > > What's your 2 cents to get both supported using a single target? I do not have any problems with the presented solution, this was just a question. The naming and organization of the Mikrotik devices in OpenWrt has been an open discussion for quite some time now, and I have given up any hope of finding a solution that will be satisfying all competing requirements. (The only thing that I try to keep consistent for now is having "routerboard-" instead of "rb-" for the "new" names.) So, no objections for the choice made here. Best Adrian > > Thanks, > > Koen > > > ___ > 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
RE: [RFC v2 3/3] ath79: add support for Mikrotik RouterBoard 912G
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Sergey Ryazanov
> Sent: Montag, 24. Mai 2021 01:07
> To: Adrian Schmutzler ; Denis Kalashnikov
>
> Cc: OpenWrt Development List ; Gabor
> Juhos ; Koen Vandeputte
>
> Subject: Re: [RFC v2 3/3] ath79: add support for Mikrotik RouterBoard 912G
>
> Hello Adrian and Denis,
>
> sorry for interfering with your conversation, I would like to discuss the best
> way to document not yet finished functionality. Please find my question and
> proposal below.
>
> On Sun, May 23, 2021 at 12:01 PM Adrian Schmutzler
> wrote:
>
> [skipped]
>
> >> + beeper {
> >> + status = "disabled";
> >> + compatible = "gpio-beeper";
> >> + gpios = < 5 GPIO_ACTIVE_HIGH>;
> >> + };
> >
> > If it's broken, I'd not add it here but just name the correct GPIO number in
> the commit message.
> >
> >> +
> >> + keys {
> >> + status = "disabled";
> >
> > Like above: If it's broken, remove it, so nobody enables it accidentally and
> causes harm.
> > (But document how to set it up in the commit message, as you mostly
> > did already ...)
>
> Factoring out realization details to the commit message is quite unusual, I
> personally assume that the commit message is a place where a committer
> should describe reasons for a particular change. While hard to understand
> things should be commented on in the code themself.
>
> I agree with Adrian that a not yet finished code should not be committed to
> the master branch. But the device tree has a dualistic nature, on one hand it
> is a place for driver configuration, on the other hand it is a way to document
> board stuff interconnections. So maybe we should combine Denise's
> approach to document even a not yet fully supported component in the DTS
> with Adrian's suggestion to document why a component is not supported yet
> and place the reason to disable DTS node as comment inside the node? E.g.:
My main motivation is preventing too much bloat in the DTS files.
Nevertheless, typically, if stuff is not working it will either not be resolved
ever or the solution will deviate from what people were thinking it would be
initially (otherwise, they would have solved it back then). Thus, the DTS
"implementation" of that part is either irrelevant (first case) or
wrong/subject to change (second case) later. In both cases, I don't think it
really makes sense to add it to the DTS in the first place.
Hovewer, I'm relatively flexible here. So if you really think it would be
necessary to have this broken part of configuration in the DTS, I won't stop
you because of that.
Best
Adrian
>
> 8< --- keys {
> compatible = "gpio-keys-polled";
>
> reset {
> ...
> gpios = < 15 GPIO_ACTIVE_LOW>;
> /*
> * GPIO line #15 is shared between the reset button on input and
> * the NAND ALE (via the latch) on output. We are unable to just
> * enable the reset button. So, this node here is for
> * documentation purposes only.
> *
> * [Here should be a text describing the possible ways to
> * overcome shared line issues]
> */
> status = "disabled";
> };
> };
> 8< ---
>
> This way we will keep all interconnection documentation in DTS and at the
> same time we will make sure that no sane user enables this node.
>
> > > + compatible = "gpio-keys";
> > > + reset {
> > > + label = "reset";
> > > + linux,code = ;
> > > + gpios = < 15 GPIO_ACTIVE_LOW>;
> > > + debounce-interval = <60>;
> > > + };
> > > + };
>
> --
> Sergey
>
> ___
> 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
RE: [PATCH v2] ath79: add support for Ubiquiti PowerBeam M (XW)
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Vincent Wiemann
> Sent: Sonntag, 23. Mai 2021 14:20
> To: Russell Senior ; openwrt-
> de...@lists.openwrt.org
> Subject: Re: [PATCH v2] ath79: add support for Ubiquiti PowerBeam M (XW)
>
> Just as a side-note:
> There are 5 different versions of the PowerBeam with different device IDs...
>
> Source:
> https://github.com/freifunk-gluon/gluon/issues/94#issuecomment-
> 510831878
> -- PowerBeam M5
> -- ERP 26 dBm according to datasheet
> 'e3e5' = { -- PBE-M5-300
> pa_gain = 4
> ant_gain = 22
> },
> 'e4e5' = { -- PBE-M5-400
> pa_gain = 4
> ant_gain = 25
> },
> 'e6e5' = { -- PBE-M5-400 ISO!!
> pa_gain = 4
> ant_gain = 25
> },
> 'e885' = { -- PBE-M5-620
> pa_gain = 4
> ant_gain = 29
> },
>
> -- Powerbeam M2 400?
> -- ERP 28 dBm according to datasheet
> 'e6c2' = { -- PBE-M2-400
> pa_gain = 6
> ant_gain = 18 dBi
> },
>
> While I think there shouldn't be different DTS files for them, there is a
> script
> missing that respects the antenna and external PA gain of these devices.
So far, we have not cared about this at device-support level (at all) as far as
I remember.
I'm not sure whether we apply antenna gain for ath79 Ubiquiti _at all_ by
default. (From what I remember we don't).
So, I tend to not care about this for this particular PR.
Best
Adrian
>
> Best,
>
> Vincent
>
>
>
> On 5/23/21 1:59 PM, Russell Senior wrote:
> > This patch adds support for the Ubiquiti PowerBeam M (XW), e.g.
> > PBE-M5-400, a 802.11n wireless with a feed+dish form factor. This
> > device was previously supported by the ar71xx loco-m-xw firmware.
> >
> > Specifications:
> > - Atheros AR9342 SoC
> > - 64 MB RAM
> > - 8 MB SPI flash
> > - 1x 10/100 Mbps Ethernet port, 24 Vdc PoE-in
> > - Power and LAN green LEDs
> > - 4x RSSI LEDs (red, orange, green, green)
> > - UART (115200 8N1)
> >
> > Flashing via stock GUI:
> > - WARNING: flashing OpenWrt from AirOS v5.6 or newer will brick your
> > device! Read the wiki for more info.
> > - Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first.
> > - Upload the factory image via AirOS web GUI.
> >
> > Flashing via TFTP:
> > - WARNING: flashing OpenWrt from AirOS v5.6 or newer will brick your
> > device! Read the wiki for more info.
> > - Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first.
> > - Use a pointy tool (e.g., unbent paperclip) to keep the
> > reset button pressed.
> > - Power on the device (keep reset button pressed).
> > - Keep pressing until LEDs flash alternatively LED1+LED3 =>
> > LED2+LED4 => LED1+LED3, etc.
> > - Release reset button.
> > - The device starts a TFTP server at 192.168.1.20.
> > - Set a static IP on the computer (e.g., 192.168.1.21/24).
> > - Upload via tftp the factory image:
> > $ tftp 192.168.1.20
> > tftp> bin
> > tftp> trace
> > tftp> put
> > openwrt-ath79-generic-x-ubnt_powerbeam-m-xw-squashfs-
> factory.bin
> >
> > WARNING: so far, no non-destructive method has been discovered for
> > opening the enclosure to reach the serial console. Internal photos are
> > available here: https://fcc.io/SWX-NBM5HP
> >
> > Changes since v1:
> > * renamed from ubnt,powerbeam-m to ubnt,powerbeam-m-xw
> >
> > Signed-off-by: Russell Senior
> > ---
> > .../ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts | 36
> +++
> > .../generic/base-files/etc/board.d/01_leds| 1 +
> > .../generic/base-files/etc/board.d/02_network | 1 +
> > target/linux/ath79/image/generic-ubnt.mk | 8 +
> > 4 files changed, 46 insertions(+)
> > create mode 100644
> > target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
> >
> > diff --git a/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
> > b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
> > new file mode 100644
> > index 00..edcb06acef
> > --- /dev/null
> > +++ b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
> > @@ -0,0 +1,36 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> > +
> > +#include "ar9342_ubnt_xw.dtsi"
> > +
> > +/ {
> > + compatible = "ubnt,powerbeam-m-xw", "ubnt,xw", "qca,ar9342";
> > + model = "Ubiquiti PowerBeam M (XW)"; };
> > +
> > + {
> > + status = "okay";
> > +
> > + phy-mask = <4>;
> > +
> > + phy4: ethernet-phy@4 {
> > + reg = <4>;
> > + };
> > +};
> > +
> > + {
> > + status = "okay";
> > +
> > + /* default for ar934x, except for 1000M and 10M */
> > + pll-data = <0x0200 0x0101
RE: [PATCH 2/2] octeon: add EdgeRouter Lite specific network config
Hi again, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Adrian Schmutzler > Sent: Sonntag, 23. Mai 2021 12:05 > To: 'Stijn Segers' > Cc: openwrt-devel@lists.openwrt.org > Subject: RE: [PATCH 2/2] octeon: add EdgeRouter Lite specific network config > > Hi, > > > -Original Message- > > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > > On Behalf Of Stijn Segers > > Sent: Freitag, 8. Januar 2021 17:30 > > To: Adrian Schmutzler > > Cc: openwrt-devel@lists.openwrt.org > > Subject: RE: [PATCH 2/2] octeon: add EdgeRouter Lite specific network > > config > > > > Hi Adrian, > > > > Op vrijdag 8 januari 2021 om 13u30 schreef Adrian Schmutzler > > : > > > Hi, > > > > > >> -Original Message- > > >> From: openwrt-devel [mailto:openwrt-devel- > > boun...@lists.openwrt.org] > > >> On Behalf Of Stijn Segers > > >> Sent: Freitag, 8. Januar 2021 11:28 > > >> To: openwrt-devel@lists.openwrt.org > > >> Subject: [PATCH 2/2] octeon: add EdgeRouter Lite specific network > > >> config > > >> > > >> The Ubiquiti EdgeRouter Lite has three network interfaces. Add a > > >> specific match in /etc/board.d/01_network so they all get set up. > > >> Default to eth0 for WAN and an eth1 + eth2 bridge for LAN. > > > > > > Why this particular assignment? > > > > > > The EdgeRouter 4 (same Octeon target) uses a similar set-up; the PC > > Engines APU has a similar setup as well: 3 Ethernet ports, eth0 being > > set as WAN - see [2]. > > > > I can invert it and set eth2 as WAN port, if you'd like. The fallback > > setup for Octeon at this point is just as weird, to set eth0 as LAN > > (which is logical) and > > eth1 as WAN, and leave other ports unconfigured. > > > > There's no perfect solution, but I think leaving a port unused makes > > even less sense than this. > > Coming back to this old discussion as well. > > From the generic config, we have eth1 as WAN port. Changing that to eth0 > now could break some existing configurations (though I doubt this will affect > many people). So, in order to have all three ports working, I'd prefer: > > ucidef_set_interfaces_lan_wan "eth0 eth2" "eth1" > > I'm aware this is not nice, but it won't break anything. If you think having > eth0 > or eth2 as WAN is superior, please prepare a patch where compat_version is > set to 1.1 to enforce config wiping. If we decide to stick to eth1 now on the > other hand, I'm not really inclined to reorder it again in half a year ... Please ignore my previous mail, it's pure nonsense. board.d will only affect _new_ installations or those which are reset, so existing users are completely irrelevant here as nothing will change for them. Therefore, just resend your patch (with wan as you wish) bundled with the compatible rename. Best Adrian > > Best > > Adrian > > > > > Stijn > > > > [1] > > https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/o > > ct > > eon/base- > > > files/etc/board.d/01_network;h=749d99be1d11802fbc442a11b1d3312b806ea > > 9fb;hb=HEAD > > [2] > > https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/x > > 86 > > /base- > > > files/etc/board.d/02_network;h=c6e381b946d03887cb941e90db2ccbb2f918fc > > a4;hb=HEAD > > > > > > > > Best > > > > > > Adrian > > > > > >> > > >> Signed-off-by: Stijn Segers > > >> --- > > >> target/linux/octeon/base-files/etc/board.d/01_network | 3 +++ > > >> 1 file changed, 3 insertions(+) > > >> > > >> diff --git a/target/linux/octeon/base-files/etc/board.d/01_network > > >> b/target/linux/octeon/base-files/etc/board.d/01_network > > >> index 749d99be1d..4ad5f95598 100755 > > >> --- a/target/linux/octeon/base-files/etc/board.d/01_network > > >> +++ b/target/linux/octeon/base-files/etc/board.d/01_network > > >> @@ -14,6 +14,9 @@ itus,shield-router) > > >> ubnt,edgerouter-4) > > >> ucidef_set_interfaces_lan_wan "lan1 lan2 lan3" "lan0" > > >> ;; > > >> +ubnt,erlite) > > >> + ucidef_set_interfaces_lan_wan "eth1 eth2" "eth0" > > >> + ;; > > >> *) > > >> ucidef
RE: [PATCH 2/2] octeon: add EdgeRouter Lite specific network config
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Stijn Segers > Sent: Freitag, 8. Januar 2021 17:30 > To: Adrian Schmutzler > Cc: openwrt-devel@lists.openwrt.org > Subject: RE: [PATCH 2/2] octeon: add EdgeRouter Lite specific network config > > Hi Adrian, > > Op vrijdag 8 januari 2021 om 13u30 schreef Adrian Schmutzler > : > > Hi, > > > >> -Original Message- > >> From: openwrt-devel [mailto:openwrt-devel- > boun...@lists.openwrt.org] > >> On Behalf Of Stijn Segers > >> Sent: Freitag, 8. Januar 2021 11:28 > >> To: openwrt-devel@lists.openwrt.org > >> Subject: [PATCH 2/2] octeon: add EdgeRouter Lite specific network > >> config > >> > >> The Ubiquiti EdgeRouter Lite has three network interfaces. Add a > >> specific match in /etc/board.d/01_network so they all get set up. > >> Default to eth0 for WAN and an eth1 + eth2 bridge for LAN. > > > > Why this particular assignment? > > > The EdgeRouter 4 (same Octeon target) uses a similar set-up; the PC Engines > APU has a similar setup as well: 3 Ethernet ports, eth0 being set as WAN - see > [2]. > > I can invert it and set eth2 as WAN port, if you'd like. The fallback setup > for > Octeon at this point is just as weird, to set eth0 as LAN (which is logical) > and > eth1 as WAN, and leave other ports unconfigured. > > There's no perfect solution, but I think leaving a port unused makes even less > sense than this. Coming back to this old discussion as well. From the generic config, we have eth1 as WAN port. Changing that to eth0 now could break some existing configurations (though I doubt this will affect many people). So, in order to have all three ports working, I'd prefer: ucidef_set_interfaces_lan_wan "eth0 eth2" "eth1" I'm aware this is not nice, but it won't break anything. If you think having eth0 or eth2 as WAN is superior, please prepare a patch where compat_version is set to 1.1 to enforce config wiping. If we decide to stick to eth1 now on the other hand, I'm not really inclined to reorder it again in half a year ... Best Adrian > > Stijn > > [1] > https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/oct > eon/base- > files/etc/board.d/01_network;h=749d99be1d11802fbc442a11b1d3312b806ea > 9fb;hb=HEAD > [2] > https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/x86 > /base- > files/etc/board.d/02_network;h=c6e381b946d03887cb941e90db2ccbb2f918fc > a4;hb=HEAD > > > > > Best > > > > Adrian > > > >> > >> Signed-off-by: Stijn Segers > >> --- > >> target/linux/octeon/base-files/etc/board.d/01_network | 3 +++ > >> 1 file changed, 3 insertions(+) > >> > >> diff --git a/target/linux/octeon/base-files/etc/board.d/01_network > >> b/target/linux/octeon/base-files/etc/board.d/01_network > >> index 749d99be1d..4ad5f95598 100755 > >> --- a/target/linux/octeon/base-files/etc/board.d/01_network > >> +++ b/target/linux/octeon/base-files/etc/board.d/01_network > >> @@ -14,6 +14,9 @@ itus,shield-router) > >> ubnt,edgerouter-4) > >>ucidef_set_interfaces_lan_wan "lan1 lan2 lan3" "lan0" > >>;; > >> +ubnt,erlite) > >> + ucidef_set_interfaces_lan_wan "eth1 eth2" "eth0" > >> + ;; > >> *) > >>ucidef_set_interfaces_lan_wan "eth0" "eth1" > >>;; > >> -- > >> 2.20.1 > >> > >> > >> ___ > >> openwrt-devel mailing list > >> openwrt-devel@lists.openwrt.org > >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > ___ > > openwrt-devel mailing list > > openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel 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: [PATCH v2] octeon: rename erlite to ubnt,edgerouter-lite
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Stijn Segers
> Sent: Freitag, 8. Januar 2021 22:08
> To: openwrt-devel@lists.openwrt.org
> Subject: [PATCH v2] octeon: rename erlite to ubnt,edgerouter-lite
>
> Rename EdgeRouter Lite board_name value and prefix it with vendor
> abbreviation UBNT, as done for other Ubiquiti devices in the tree. Ensure
> backward sysupgrade compatibility as well.
Just found this "old" patch on patchwork. Comments below.
>
> Signed-off-by: Stijn Segers
> ---
> .../octeon/base-files/lib/preinit/01_sysinfo | 2 +-
> .../octeon/base-files/lib/preinit/79_move_config | 2 +-
> .../octeon/base-files/lib/upgrade/platform.sh| 16
> target/linux/octeon/image/Makefile | 1 +
> 4 files changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/target/linux/octeon/base-files/lib/preinit/01_sysinfo
> b/target/linux/octeon/base-files/lib/preinit/01_sysinfo
> index d66618b0cf..3512bd7321 100644
> --- a/target/linux/octeon/base-files/lib/preinit/01_sysinfo
> +++ b/target/linux/octeon/base-files/lib/preinit/01_sysinfo
> @@ -6,7 +6,7 @@ do_sysinfo_octeon() {
>
> case "$machine" in
> "UBNT_E100"*)
> - name="erlite"
> + name="ubnt,edgerouter-lite"
> ;;
>
> "UBNT_E200"*)
> diff --git a/target/linux/octeon/base-files/lib/preinit/79_move_config
> b/target/linux/octeon/base-files/lib/preinit/79_move_config
> index 5a84e6f18a..07b6585470 100644
> --- a/target/linux/octeon/base-files/lib/preinit/79_move_config
> +++ b/target/linux/octeon/base-files/lib/preinit/79_move_config
> @@ -15,7 +15,7 @@ octeon_move_config() {
> . /lib/functions.sh
>
> case "$(board_name)" in
> - erlite)
> + ubnt,edgerouter-lite)
> move_config "/dev/sda1"
> ;;
> itus,shield-router)
> diff --git a/target/linux/octeon/base-files/lib/upgrade/platform.sh
> b/target/linux/octeon/base-files/lib/upgrade/platform.sh
> index ad5baef4a1..11e598c10b 100755
> --- a/target/linux/octeon/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/octeon/base-files/lib/upgrade/platform.sh
> @@ -19,11 +19,6 @@ platform_get_rootfs() {
>
> platform_copy_config() {
> case "$(board_name)" in
> - erlite)
> - mount -t vfat /dev/sda1 /mnt
> - cp -af "$UPGRADE_BACKUP" "/mnt/$BACKUP_FILE"
> - umount /mnt
> - ;;
> itus,shield-router)
> mount -t vfat /dev/mmcblk1p1 /mnt
> cp -af "$UPGRADE_BACKUP" "/mnt/$BACKUP_FILE"
> @@ -34,6 +29,11 @@ platform_copy_config() {
> cp -af "$UPGRADE_BACKUP" "/mnt/$BACKUP_FILE"
> umount /mnt
> ;;
> + ubnt,edgerouter-lite)
> + mount -t vfat /dev/sda1 /mnt
> + cp -af "$UPGRADE_BACKUP" "/mnt/$BACKUP_FILE"
> + umount /mnt
> + ;;
This needs to be rebased due to my recent patch.
> esac
> }
>
> @@ -87,7 +87,7 @@ platform_do_upgrade() {
> ubnt,edgerouter-4)
> kernel=mmcblk0p1
> ;;
> - erlite)
> + ubnt,edgerouter-lite)
> kernel=sda1
> ;;
> itus,shield-router)
> @@ -112,9 +112,9 @@ platform_check_image() {
>
> case "$board" in
> er | \
> - erlite | \
> itus,shield-router | \
> - ubnt,edgerouter-4)
> + ubnt,edgerouter-4 | \
> + ubnt,edgerouter-lite)
> local kernel_length=$(tar xf $tar_file $board_dir/kernel -O |
> wc -c 2> /dev/null)
> local rootfs_length=$(tar xf $tar_file $board_dir/root -O | wc
> -c 2> /dev/null)
> [ "$kernel_length" = 0 -o "$rootfs_length" = 0 ] && { diff --git
> a/target/linux/octeon/image/Makefile
> b/target/linux/octeon/image/Makefile
> index b91c262447..83a3274587 100644
> --- a/target/linux/octeon/image/Makefile
> +++ b/target/linux/octeon/image/Makefile
> @@ -71,6 +71,7 @@ define Device/ubnt_edgerouter-lite
>DEVICE_MODEL := EdgeRouter Lite
>BOARD_NAME := erlite
>CMDLINE := $(ERLITE_CMDLINE)
> +SUPPORTED_DEVICES := erlite ubnt,edgerouter-lite
This can be simplified to
SUPPORTED_DEVICES += erlite
since the other value is the global default now. Note that indent is broken
here as well.
If this is properly tested, I'm inclined to merge an updated version. Consider
combining this into a patchset with the ethX patch for which I will write
comments in just a minute.
Best
Adrian
> endef
> TARGET_DEVICES += ubnt_edgerouter-lite
>
> --
> 2.20.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
RE: [PATCH v3 2/2] ramips: mt7621: Add support for ZyXEL LTE3301-Plus
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of André Valentin
> Sent: Dienstag, 18. Mai 2021 22:45
> To: openwrt-devel@lists.openwrt.org; a.valen...@ddimension.net
> Cc: avalen...@marcant.net
> Subject: [PATCH v3 2/2] ramips: mt7621: Add support for ZyXEL LTE3301-Plus
Thanks for updating. Still a few comments below.
>
> The ZyXEL LTE3301-Plus is an 4G indoor CPE with 2 external LTE antennas.
>
> Specifications:
>
> - SoC: MediaTek MT7621AT
> - RAM: 256 MB
> - Flash: 128 MB MB NAND (MX30LF1G18AC)
> - WiFi: MediaTek MT7615E
> - Switch: 4 LAN ports (Gigabit)
> - LTE: Quectel EG506 connected by USB3 to SoC
> - SIM: 1 micro-SIM slot
> - USB: USB3 port
> - Buttons: Reset, WPS
> - LEDs: Multicolour power, internet, LTE, signal, Wifi, USB
> - Power: 12V, 1.5A
>
> The device is built as an indoor ethernet to LTE bridge or router with Wifi.
>
> UART Serial:
>
> 57600N1
> Located on populated 5 pin header J5:
>
> [o] GND
> [ ] key - no pin
> [o] 3.3V Vcc
> [o] RX
> [o] TX
>
> MAC assignment:
> lan: 98:0d:67:ee:85:54 (base, on the device back)
> wlan: 98:0d:67:ee:85:55
>
> For more details about flashing see commit
> 2449a632084b29632605e5a79ce5d73028eb15dd .
You don't provide _any_ details about flashing, so "for more details" is a bit
of irony here.
Jokes aside, please provide a very condensed flashing info here, and then it's
perfectly fine to link to the other commit.
But the user should get a general idea about flashing without following any
links (you may choose whether you prefer just providing one method and then use
the link for the other, or just give an overview of available methods etc.).
>
> Signed-off-by: André Valentin
> ---
> package/boot/uboot-envtools/files/ramips | 1 +
> .../ramips/dts/mt7621_zyxel_lte3301-plus.dts | 213 ++
> target/linux/ramips/image/mt7621.mk | 19 ++
> .../mt7621/base-files/etc/board.d/01_leds | 3 +
> .../mt7621/base-files/etc/board.d/02_network | 3 +-
> .../base-files/etc/board.d/03_gpio_switches | 4 +
> .../mt7621/base-files/etc/init.d/bootcount| 1 +
> .../mt7621/base-files/lib/upgrade/platform.sh | 1 +
> 8 files changed, 244 insertions(+), 1 deletion(-) create mode 100644
> target/linux/ramips/dts/mt7621_zyxel_lte3301-plus.dts
>
> diff --git a/package/boot/uboot-envtools/files/ramips
> b/package/boot/uboot-envtools/files/ramips
> index bce2e5f0fb..4d0e608911 100644
> --- a/package/boot/uboot-envtools/files/ramips
> +++ b/package/boot/uboot-envtools/files/ramips
> @@ -53,6 +53,7 @@ xiaomi,mi-router-ac2100|\
> xiaomi,redmi-router-ac2100)
> ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x1000" "0x2"
> ;;
> +zyxel,lte3301-plus|\
> zyxel,nr7101)
> idx="$(find_mtd_index Config)"
> [ -n "$idx" ] && \
> diff --git a/target/linux/ramips/dts/mt7621_zyxel_lte3301-plus.dts
> b/target/linux/ramips/dts/mt7621_zyxel_lte3301-plus.dts
> new file mode 100644
> index 00..af2e792cb8
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7621_zyxel_lte3301-plus.dts
> @@ -0,0 +1,213 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +
> +#include "mt7621.dtsi"
> +
> +#include
> +#include
> +
> +/ {
> + compatible = "zyxel,lte3301-plus", "mediatek,mt7621-soc";
> + model = "ZyXEL LTE3301-PLUS";
> +
> + aliases {
> + label-mac-device =
> + led-boot = _power;
> + led-failsafe = _power;
> + led-running = _power;
> + led-upgrade = _power;
> + };
> +
> + gpio_export {
> + compatible = "gpio-export";
> +
> + lte_power {
> + gpio-export,name = "lte_power";
> + gpio-export,output = <1>;
> + gpios = < 27 GPIO_ACTIVE_LOW>;
> + };
> +
> + usb_power {
> + gpio-export,name = "usb_power";
> + gpio-export,output = <1>;
> + gpios = < 7 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led_power: power {
> + label = "white:power";
> + gpios = < 5 GPIO_ACTIVE_HIGH>;
> + };
> +
> + wifi {
> + label = "white:wifi";
> + gpios = < 13 GPIO_ACTIVE_LOW>;
> + };
> +
> + internet {
> + label = "white:internet";
> + gpios = < 23 GPIO_ACTIVE_LOW>;
> + };
> +
> + usb {
> + label = "white:usb";
> + gpios = < 24 GPIO_ACTIVE_LOW>;
> + trigger-sources = <_ehci_port1>,
> <_port2>;
> + linux,default-trigger = "usbport";
> + };
> +
> + lte {
> + label = "white:lte";
> +
RE: [PATCH] ath79/zyxel_nbg6716: resize kernel partition to 6MiB and reenable again
Hi, the 3rd,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of André Valentin
> Sent: Samstag, 22. Mai 2021 17:01
> To: openwrt-devel@lists.openwrt.org
> Cc: André Valentin
> Subject: [PATCH] ath79/zyxel_nbg6716: resize kernel partition to 6MiB and
> reenable again
proper commit title requires just "ath79:" prefix, e.g. "ath79: increase ZyXEL
NBG6716 kernel to 6M" ...
Best
Adrian
>
> The bootloader happily accepts this.
> But devices need a fresh reinstall because of resulting ubi partition changes.
> Therefore a sysupgrade will brick your device.
>
> Please install a fresh factory image via bootloader.
> Alternatively, you can flash sysupgrade-6M-Kernel.bin with zcat sysupgrade-
> 6M-Kernel.bin | mtd -r -e /dev/mtd 3 write - /dev/mtd3
>
> This may thow an error, because it is a 256M image. There are devices out
> there with this flash size.
>
> Notice that you will always loose configuration.
>
> Signed-off-by: André Valentin
> ---
> .../linux/ath79/dts/qca9558_zyxel_nbg6716.dts | 4 ++--
> target/linux/ath79/image/nand.mk | 24 +--
> 2 files changed, 19 insertions(+), 9 deletions(-)
>
> diff --git a/target/linux/ath79/dts/qca9558_zyxel_nbg6716.dts
> b/target/linux/ath79/dts/qca9558_zyxel_nbg6716.dts
> index 9aee8c362c..411b086188 100644
> --- a/target/linux/ath79/dts/qca9558_zyxel_nbg6716.dts
> +++ b/target/linux/ath79/dts/qca9558_zyxel_nbg6716.dts
> @@ -147,12 +147,12 @@
>
> partition@50 {
> label = "kernel";
> - reg = <0x50 0x40>;
> + reg = <0x50 0x60>;
> };
>
> partition@90 {
> label = "ubi";
> - reg = <0x90 0x770>;
> + reg = <0xb0 0x750>;
> };
> };
> };
> diff --git a/target/linux/ath79/image/nand.mk
> b/target/linux/ath79/image/nand.mk
> index caaa01c92d..37a5713ff1 100644
> --- a/target/linux/ath79/image/nand.mk
> +++ b/target/linux/ath79/image/nand.mk
> @@ -236,6 +236,15 @@ TARGET_DEVICES += netgear_wndr4500-v3
>
> define Device/zyxel_nbg6716
>SOC := qca9558
> + DEVICE_COMPAT_VERSION := 2.0
> + DEVICE_COMPAT_MESSAGE := Kernel partition has been resized to 6M. \
> + A sysupgrade will brick your device. \
> + Please install a fresh factory image via bootloader. \
> + Alternatively, you can flash sysupgrade-6M-Kernel.bin with \
> + zcat sysupgrade-6M-Kernel.bin | mtd -r -e /dev/mtd3 write -
> /dev/mtd3 .\
> + This may thow an error, because it is a 256M image. There are \
> + devices out there with this flash size. \
> + Notice that you will always loose configuration.
>DEVICE_VENDOR := ZyXEL
>DEVICE_MODEL := NBG6716
>DEVICE_PACKAGES := kmod-usb2 kmod-usb-ledtrig-usbport kmod-ath10k-
> ct \ @@ -243,19 +252,20 @@ define Device/zyxel_nbg6716
>RAS_BOARD := NBG6716
>RAS_ROOTFS_SIZE := 29696k
>RAS_VERSION := "OpenWrt Linux-$(LINUX_VERSION)"
> - KERNEL_SIZE := 4096k
> + KERNEL_SIZE := 6144k
>BLOCKSIZE := 128k
>PAGESIZE := 2048
>KERNEL := kernel-bin | append-dtb | uImage none | zyxel-buildkerneljffs |
> \
> - check-size 4096k
> - IMAGES := sysupgrade.tar sysupgrade-4M-Kernel.bin factory.bin
> + check-size 6144k
> + KERNEL_INITRAMFS := kernel-bin | append-dtb | uImage none | \
> + zyxel-buildkerneljffs | zyxel-factory
> + IMAGES := sysupgrade.tar sysupgrade-6M-Kernel.bin factory.bin
>IMAGE/sysupgrade.tar/squashfs := append-rootfs | pad-to
> (BLOCKSIZE) | \
> sysupgrade-tar rootfs=@ | append-metadata
> - IMAGE/sysupgrade-4M-Kernel.bin/squashfs := append-kernel | \
> + IMAGE/sysupgrade-6M-Kernel.bin/squashfs := append-kernel | \
> pad-to (KERNEL_SIZE) | append-ubi | pad-to 263192576 | gzip
> - IMAGE/factory.bin := append-kernel | pad-to (KERNEL_SIZE) |
> append-ubi | \
> - zyxel-factory
> + IMAGE/factory.bin := append-kernel | pad-to (KERNEL_SIZE) | \
> + append-ubi | zyxel-factory
>UBINIZE_OPTS := -E 5
> - DEFAULT := n
> endef
> TARGET_DEVICES += zyxel_nbg6716
> --
> 2.20.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
RE: [PATCH] base-files: migrate old UCI network sections defining bridges
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Rafal Milecki
> Sent: Dienstag, 18. Mai 2021 23:42
> To: Jo-Philipp Wich ; Hans Dedecker ;
> John Crispin ; Felix Fietkau ;
> openwrt-devel@lists.openwrt.org
> Cc: Rafał Miłecki
> Subject: [PATCH] base-files: migrate old UCI network sections defining
> bridges
>
> From: Rafał Miłecki
>
> Old "interface" sections for bridges were mixing layer 2 and layer 3.
> That syntax got deprecated and UCI section "device" is used for bridge
> configuration now.
>
> Backward compatibility may be dropped from netifd soon now so migrate old
> configs using uci-defaults script.
>
> Signed-off-by: Rafał Miłecki
> ---
> That "soon" is relative, I'm not planning to push this patch yet. We may give
> updated /etc/config/network few months to receive proper testing.
> ---
> .../uci-defaults/11_network-migrate-bridges | 24 +++
> 1 file changed, 24 insertions(+)
>
> diff --git a/package/base-files/files/etc/uci-defaults/11_network-migrate-
> bridges b/package/base-files/files/etc/uci-defaults/11_network-migrate-
> bridges
> index 745648531f..7188c06ce3 100644
> --- a/package/base-files/files/etc/uci-defaults/11_network-migrate-bridges
> +++ b/package/base-files/files/etc/uci-defaults/11_network-migrate-bridg
> +++ es
> @@ -17,7 +17,31 @@ migrate_ports() {
> uci delete network.$config.ifname
> }
>
> +migrate_bridge() {
> + local config="$1"
> + local type ifname
> +
> + config_get type "$config" type
> + [ "$type" != "bridge" ] && return
> +
> + config_get ifname "$config" ifname
> +
> + uci -q batch <<-EOF
> + add network device
> + set network.@device[-1].name='br-$config'
> + set network.@device[-1].type='bridge'
> + EOF
> + for port in $ifname; do uci add_list
> +network.@device[-1].ports="$port"; done
> +
> + uci -q batch <<-EOF
> + delete network.$config.type
> + set network.$config.ifname='br-$config'
> + EOF
> +}
> +
> config_load network
> config_foreach migrate_ports device
> +config_foreach migrate_bridge interface uci commit network
>
> exit 1
Just to document it somewhere on the list as well:
I don't think putting "exit 1" here is a good solution. The uci-defaults script
are by design meant to be run only once and then deleted.
We should either choose a "big" number for the uci-defaults file name, so the
script is run _after_ the others and deals with custom config, or use some
init.d/rc.d-based script instead that runs for every boot.
From a conceptual perspective, I'd prefer uci-defaults since we should be able
to do the migration "in one step" for practical reasons and consistency.
Apart from that, thanks for taking care of this subject and trying to make
network config more understandable.
Best
Adrian
> --
> 2.26.2
>
>
> ___
> 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
RE: Resize of ath79 / ZyXEL NBG6716 kernel partition
Hi, > -Original Message- > From: Andre Valentin [mailto:a.valen...@ddimension.net] > Sent: Dienstag, 18. Mai 2021 20:11 > To: OpenWrt Development List > Subject: Resize of ath79 / ZyXEL NBG6716 kernel partition > > Hi! > > The NBG6716 has recently been disabled because of size problems with the > kernel partition. > I'm thinking about extending it to 8MB, shouldn't be a problem. Interesting. https://github.com/openwrt/openwrt/commit/5d8ea6d34f9f23d4dfff4ffcac8c9599d842c3a8 I was not aware that we are > 4 MiB for kernel already. Is there anything special about this device (or probably ath79/nand) that causes bigger kernel? Best Adrian > > But I'm afraid users will brick their device when doing a sysupgrade to the > new flash layout. > First time / in upgrade case it must be installed via manufacturer webif or > via > bootloader. > > What do you propose in these cases? > > Kind regards, > > André 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: [RFC v2 3/3] ath79: add support for Mikrotik RouterBoard 912G
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Denis Kalashnikov
> Sent: Freitag, 21. Mai 2021 13:05
> To: openwrt-devel@lists.openwrt.org
> Cc: Gabor Juhos ; Koen Vandeputte
> ; Sergey Ryazanov
>
> Subject: [RFC v2 3/3] ath79: add support for Mikrotik RouterBoard 912G
Thanks for the update. Some additional comments below.
>
> This board has been supported in the ar71xx.
>
> Links:
> * https://mikrotik.com/product/RB912UAG-2HPnD
> * https://mikrotik.com/product/RB912UAG-5HPnD
> * https://openwrt.org/toh/hwdata/mikrotik/mikrotik_rb912uag-2hpnd
> * https://openwrt.org/toh/hwdata/mikrotik/mikrotik_rb912uag-5hpnd
>
> Hardware:
> * SoC: Atheros AR9342,
> * RAM: DDR 64MB,
> * SPI NOR: 64KB,
> * NAND: 128MB,
> * Ethernet: x1 10/100/1000 port with passive POE in,
> * Wi-Fi: 802.11bgn,
> * PCIe,
> * USB: 2.0 EHCI controller, connected to mPCIe slot and a Type-A
> port -- both can be used for LTE modem. But only one can be used.
> * LEDs: 5 general purpose LEDs (led1..led5), power LED, user LED,
> Ethernet phy LED,
> * Button,
> * Beeper.
>
> Not working:
> * Button: it shares gpio line 15 with NAND ALE and NAND IO7,
> and current drivers doesn't easily support this configuration,
> * Beeper: it is connected to bit 5 of a serial shift register
> (tested with sysfs led trigger timer). But kmod-gpio-beeper
> doesn't work -- we left this as is for now.
>
> You can flash image by sysupgrade utility or load it by net (by DHCP/TFTP,
> hold the button while booting).
>
> Co-Developed-by: Koen Vandeputte
> Signed-off-by: Denis Kalashnikov
> ---
>
> Changelog:
>
> v1->v2:
> - Delete uneeded comments from DTS,
> - Delete ascii-art of board scheme near NAND latch from DTS,
> - Rewrite gpio_latch and nand_gpio nodes to be consistent with the
> new versions of drivers,
> - Fix SPI NOR flash and SPI serial shift register maximum speeds
> (thanks to Koen Vandeputte),
> - Add UART, PCIe, USB support and gpio exports (thanks to Koen
> Vandeputte),
> - Fix Ethernet node (thanks to Koen Vandeputte),
> - Add key and beeper nodes in disabled state just to be documented.
>
> ---
> .../dts/ar9342_mikrotik_routerboard-912g.dts | 233 ++
> target/linux/ath79/image/mikrotik.mk | 9 +
> .../base-files/etc/board.d/02_network | 2 +
> .../etc/hotplug.d/firmware/10-ath9k-eeprom| 1 +
> .../base-files/lib/upgrade/platform.sh| 1 +
> 5 files changed, 246 insertions(+)
> create mode 100644 target/linux/ath79/dts/ar9342_mikrotik_routerboard-
> 912g.dts
>
> diff --git a/target/linux/ath79/dts/ar9342_mikrotik_routerboard-912g.dts
> b/target/linux/ath79/dts/ar9342_mikrotik_routerboard-912g.dts
> new file mode 100644
> index 00..a23fc04a99
> --- /dev/null
> +++ b/target/linux/ath79/dts/ar9342_mikrotik_routerboard-912g.dts
> @@ -0,0 +1,233 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +
> +#include "ar9344.dtsi"
> +
> +#include
> +#include
> +
> +/ {
> + compatible = "mikrotik,routerboard-912g", "qca,ar9342";
> + model = "Mikrotik RouterBoard 912G";
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led_power {
> + label = "green:power";
> + gpios = <_latch 1 GPIO_ACTIVE_HIGH>;
> + default-state = "on";
> + };
Since you have a GPIO-controlled power-led, you should use the led-* aliases in
the aliases block to indicate boot states (just look into one of the other
ath79 DTS files.)
> +
> + led_user {
> + label = "green:user";
> + gpios = <_latch 2 GPIO_ACTIVE_HIGH>;
> + };
> +
> + led1 {
> + label = "green:led1";
> + gpios = < 0 GPIO_ACTIVE_HIGH>;
> + };
> +
> + led2 {
> + label = "green:led2";
> + gpios = < 1 GPIO_ACTIVE_HIGH>;
> + };
> +
> + led3 {
> + label = "green:led3";
> + gpios = < 2 GPIO_ACTIVE_HIGH>;
> + };
> +
> + led4 {
> + label = "green:led4";
> + gpios = < 3 GPIO_ACTIVE_HIGH>;
> + };
> +
> + led5 {
> + label = "green:led5";
> + gpios = < 4 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +
> + beeper {
> + status = "disabled";
> + compatible = "gpio-beeper";
> + gpios = < 5 GPIO_ACTIVE_HIGH>;
> + };
If it's broken, I'd not add it here but just name the correct GPIO number in
the commit message.
> +
> + keys {
> + status = "disabled";
Like above: If it's broken, remove it, so nobody enables it accidentally and
causes harm.
(But document how to set it up in the commit message, as you mostly did already
...)
> +
RE: [PATCH] ath79: add support for Ubiquiti PowerBeam M (XW)
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Russell Senior
> Sent: Sonntag, 23. Mai 2021 07:24
> To: openwrt-devel@lists.openwrt.org
> Cc: Russell Senior
> Subject: [PATCH] ath79: add support for Ubiquiti PowerBeam M (XW)
>
> This patch adds support for the Ubiquiti PowerBeam M (XW), e.g. PBE-M5-
> 400, a 802.11n wireless with a feed+dish form factor. This device was
> previously supported by the ar71xx loco-m-xw firmware.
this looks good in general. Somebody else should have a look at the network
config, as this is the first non-wa ubnt device set up with rgmii-id.
Apart from that, please use "ubnt-powerbeam-m-xw" for the compatible. This is
in line with the other xw devices, and actually it would have been better for
the xm devices as well in the first place, so I don't count "There is no 'xm'
powerbeam" as an argument :-)
Best
Adrian
>
> Specifications:
> - Atheros AR9342 SoC
> - 64 MB RAM
> - 8 MB SPI flash
> - 1x 10/100 Mbps Ethernet port, 24 Vdc PoE-in
> - Power and LAN green LEDs
> - 4x RSSI LEDs (red, orange, green, green)
> - UART (115200 8N1)
>
> Flashing via stock GUI:
> - WARNING: flashing OpenWrt from AirOS v5.6 or newer will brick your
>device! Read the wiki for more info.
> - Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first.
> - Upload the factory image via AirOS web GUI.
>
> Flashing via TFTP:
> - WARNING: flashing OpenWrt from AirOS v5.6 or newer will brick your
>device! Read the wiki for more info.
> - Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first.
> - Use a pointy tool (e.g., unbent paperclip) to keep the
>reset button pressed.
> - Power on the device (keep reset button pressed).
> - Keep pressing until LEDs flash alternatively LED1+LED3 =>
>LED2+LED4 => LED1+LED3, etc.
> - Release reset button.
> - The device starts a TFTP server at 192.168.1.20.
> - Set a static IP on the computer (e.g., 192.168.1.21/24).
> - Upload via tftp the factory image:
> $ tftp 192.168.1.20
> tftp> bin
> tftp> trace
> tftp> put openwrt-ath79-generic-x-ubnt_powerbeam-m-squashfs-
> factory.bin
>
> WARNING: so far, no non-destructive method has been discovered for
> opening the enclosure to reach the serial console. Internal photos are
> available here: https://fcc.io/SWX-NBM5HP
>
> Signed-off-by: Russell Senior
> ---
> .../ath79/dts/ar9342_ubnt_powerbeam-m.dts | 36
> +++
> .../generic/base-files/etc/board.d/01_leds| 1 +
> .../generic/base-files/etc/board.d/02_network | 1 +
> target/linux/ath79/image/generic-ubnt.mk | 8 +
> 4 files changed, 46 insertions(+)
> create mode 100644 target/linux/ath79/dts/ar9342_ubnt_powerbeam-
> m.dts
>
> diff --git a/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m.dts
> b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m.dts
> new file mode 100644
> index 00..1a2ce428f2
> --- /dev/null
> +++ b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m.dts
> @@ -0,0 +1,36 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +
> +#include "ar9342_ubnt_xw.dtsi"
> +
> +/ {
> + compatible = "ubnt,powerbeam-m", "ubnt,xw", "qca,ar9342";
> + model = "Ubiquiti PowerBeam M (XW)";
> +};
> +
> + {
> + status = "okay";
> +
> + phy-mask = <4>;
> +
> + phy4: ethernet-phy@4 {
> + reg = <4>;
> + };
> +};
> +
> + {
> + status = "okay";
> +
> + /* default for ar934x, except for 1000M and 10M */
> + pll-data = <0x0200 0x0101 0x1313>;
> +
> + mtd-mac-address = < 0x0>;
> +
> + phy-mode = "rgmii-id";
> + phy-handle = <>;
> +
> + gmac-config {
> + device = <>;
> + rxd-delay = <3>;
> + rxdv-delay = <3>;
> + };
> +};
> diff --git a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
> b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
> index 1990353394..3bf120b92b 100644
> --- a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
> +++ b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
> @@ -383,6 +383,7 @@ ubnt,nanostation-loco-m-xw|\ ubnt,nanostation-
> m|\ ubnt,nanostation-m-xw|\ ubnt,picostation-m|\
> +ubnt,powerbeam-m|\
> ubnt,powerbridge-m|\
> ubnt,rocket-m)
> ucidef_set_rssimon "wlan0" "20" "1"
> diff --git a/target/linux/ath79/generic/base-files/etc/board.d/02_network
> b/target/linux/ath79/generic/base-files/etc/board.d/02_network
> index 4133b9d7d3..2b4ab946e1 100644
> --- a/target/linux/ath79/generic/base-files/etc/board.d/02_network
> +++ b/target/linux/ath79/generic/base-files/etc/board.d/02_network
> @@ -85,6 +85,7 @@ ath79_setup_interfaces()
> ubnt,picostation-m|\
> ubnt,powerbeam-5ac-500|\
> ubnt,powerbeam-5ac-gen2|\
> + ubnt,powerbeam-m|\
> ubnt,powerbridge-m|\
> ubnt,rocket-m|\
> ubnt,unifiac-lite|\
> diff --git a/target/linux/ath79/image/generic-ubnt.mk
>
RE: [PATCH] ath79/zyxel_nbg6716: resize kernel partition to 6MiB and reenable again
Hi again, >KERNEL := kernel-bin | append-dtb | uImage none | zyxel-buildkerneljffs | > \ > - check-size 4096k > - IMAGES := sysupgrade.tar sysupgrade-4M-Kernel.bin factory.bin > + check-size 6144k One should use (KERNEL_SIZE) here instead of a literal value. Best Adrian 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: [PATCH] ath79/zyxel_nbg6716: resize kernel partition to 6MiB and reenable again
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of André Valentin
> Sent: Samstag, 22. Mai 2021 17:01
> To: openwrt-devel@lists.openwrt.org
> Cc: André Valentin
> Subject: [PATCH] ath79/zyxel_nbg6716: resize kernel partition to 6MiB and
> reenable again
>
> The bootloader happily accepts this.
> But devices need a fresh reinstall because of resulting ubi partition changes.
> Therefore a sysupgrade will brick your device.
>
> Please install a fresh factory image via bootloader.
> Alternatively, you can flash sysupgrade-6M-Kernel.bin with zcat sysupgrade-
> 6M-Kernel.bin | mtd -r -e /dev/mtd 3 write - /dev/mtd3
>
> This may thow an error, because it is a 256M image. There are devices out
> there with this flash size.
>
> Notice that you will always loose configuration.
>
> Signed-off-by: André Valentin
> ---
> .../linux/ath79/dts/qca9558_zyxel_nbg6716.dts | 4 ++--
> target/linux/ath79/image/nand.mk | 24 +--
> 2 files changed, 19 insertions(+), 9 deletions(-)
>
> diff --git a/target/linux/ath79/dts/qca9558_zyxel_nbg6716.dts
> b/target/linux/ath79/dts/qca9558_zyxel_nbg6716.dts
> index 9aee8c362c..411b086188 100644
> --- a/target/linux/ath79/dts/qca9558_zyxel_nbg6716.dts
> +++ b/target/linux/ath79/dts/qca9558_zyxel_nbg6716.dts
> @@ -147,12 +147,12 @@
>
> partition@50 {
> label = "kernel";
> - reg = <0x50 0x40>;
> + reg = <0x50 0x60>;
> };
>
> partition@90 {
> label = "ubi";
> - reg = <0x90 0x770>;
> + reg = <0xb0 0x750>;
> };
> };
> };
> diff --git a/target/linux/ath79/image/nand.mk
> b/target/linux/ath79/image/nand.mk
> index caaa01c92d..37a5713ff1 100644
> --- a/target/linux/ath79/image/nand.mk
> +++ b/target/linux/ath79/image/nand.mk
> @@ -236,6 +236,15 @@ TARGET_DEVICES += netgear_wndr4500-v3
>
> define Device/zyxel_nbg6716
>SOC := qca9558
> + DEVICE_COMPAT_VERSION := 2.0
In order for this to work, you will need to also set the compat_version _on
device_ either with board.d or uci-default.
In case of fresh install typically the uci-defaults method provides a better
experience.
Examples:
board.d:
https://github.com/openwrt/openwrt/blob/master/target/linux/kirkwood/base-files/etc/board.d/05_compat-version
uci-defaults (at the bottom):
https://github.com/openwrt/openwrt/commit/07aa858a73e6e855fc62a37ae275518fa4db5e50
Best
Adrian
> + DEVICE_COMPAT_MESSAGE := Kernel partition has been resized to 6M. \
> + A sysupgrade will brick your device. \
> + Please install a fresh factory image via bootloader. \
> + Alternatively, you can flash sysupgrade-6M-Kernel.bin with \
> + zcat sysupgrade-6M-Kernel.bin | mtd -r -e /dev/mtd3 write -
> /dev/mtd3 .\
> + This may thow an error, because it is a 256M image. There are \
> + devices out there with this flash size. \
> + Notice that you will always loose configuration.
>DEVICE_VENDOR := ZyXEL
>DEVICE_MODEL := NBG6716
>DEVICE_PACKAGES := kmod-usb2 kmod-usb-ledtrig-usbport kmod-ath10k-
> ct \ @@ -243,19 +252,20 @@ define Device/zyxel_nbg6716
>RAS_BOARD := NBG6716
>RAS_ROOTFS_SIZE := 29696k
>RAS_VERSION := "OpenWrt Linux-$(LINUX_VERSION)"
> - KERNEL_SIZE := 4096k
> + KERNEL_SIZE := 6144k
>BLOCKSIZE := 128k
>PAGESIZE := 2048
>KERNEL := kernel-bin | append-dtb | uImage none | zyxel-buildkerneljffs |
> \
> - check-size 4096k
> - IMAGES := sysupgrade.tar sysupgrade-4M-Kernel.bin factory.bin
> + check-size 6144k
> + KERNEL_INITRAMFS := kernel-bin | append-dtb | uImage none | \
> + zyxel-buildkerneljffs | zyxel-factory
> + IMAGES := sysupgrade.tar sysupgrade-6M-Kernel.bin factory.bin
>IMAGE/sysupgrade.tar/squashfs := append-rootfs | pad-to
> (BLOCKSIZE) | \
> sysupgrade-tar rootfs=@ | append-metadata
> - IMAGE/sysupgrade-4M-Kernel.bin/squashfs := append-kernel | \
> + IMAGE/sysupgrade-6M-Kernel.bin/squashfs := append-kernel | \
> pad-to (KERNEL_SIZE) | append-ubi | pad-to 263192576 | gzip
> - IMAGE/factory.bin := append-kernel | pad-to (KERNEL_SIZE) |
> append-ubi | \
> - zyxel-factory
> + IMAGE/factory.bin := append-kernel | pad-to (KERNEL_SIZE) | \
> + append-ubi | zyxel-factory
>UBINIZE_OPTS := -E 5
> - DEFAULT := n
> endef
> TARGET_DEVICES += zyxel_nbg6716
> --
> 2.20.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
RE: [PATCH 2/2] ramips: mt7621: Add support for ZyXEL LTE3301-Plus
Hi,
> >
> > What's in 0x200 to 0x214? Or did I miscalculate?
>
> No, no miscalculation. This was taken from factory.
>
> But please wait, I'm working on an alternative!
If this stays empty please just add a brief comment about that fact into the
DTS.
> > That's a very unusual location. Nothing in 0x4, 0x8004, 0x28, 0x2e, 0xe000
> > or
> 0xe006?
> Yepp. I verified it before. But it's correct.
Please provide details about mac assignment in the commit message...
> > Wrong indent. Use tabs.
> Thanks, fixed!
> >
> > "link tx rx" should be standard and can be removed.
> Thanks, fixed!
> >
> >> +ucidef_set_led_usbport "usb" "USB" "$boardname:white:usb"
> >> + "usb1-
> >> port2"
> >
> > This can probably replaced by a DT trigger.
> You you give me a hint?
https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/dts/mt7621_netgear_sercomm_ayx.dtsi#L52
> >
> >> +;;
> >> esac
> >>
> >> board_config_flush
> >> diff --git
> >> a/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
> >> b/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
> >> index cde3cba9bc..01a4faf3cc 100644
> >> --- a/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
> >> +++ b/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
> >> @@ -63,6 +63,9 @@ ramips_setup_interfaces()
> >>ubnt,edgerouter-x-sfp)
> >>ucidef_set_interfaces_lan_wan "eth1 eth2 eth3 eth4 eth5"
> >> "eth0"
> >>;;
> >> +zyxel,lte3301-plus)
> >> +ucidef_set_interface_lan "lan1 lan2 lan3 lan4"
> >> + ;;
> >
> > This can be merged with linksys,re6500 etc. Note that indent is wrong here,
> too.
> Thanks, fixed!
> >
> >>zyxel,nr7101)
> >>ucidef_set_interfaces_lan_wan "lan" "wan"
> >>;;
> >> diff --git a/target/linux/ramips/mt7621/base-
> >> files/etc/board.d/03_gpio_switches b/target/linux/ramips/mt7621/base-
> >> files/etc/board.d/03_gpio_switches
> >> index ed728b07c4..1959d8c9d2 100644
> >> ---
> >> a/target/linux/ramips/mt7621/base-files/etc/board.d/03_gpio_switches
> >> +++ b/target/linux/ramips/mt7621/base-files/etc/board.d/03_gpio_switc
> >> +++ hes
> >> @@ -22,6 +22,9 @@ ubnt,edgerouter-x-sfp)
> >>ucidef_add_gpio_switch "poe_power_port3" "PoE Power Port3"
> >> "403"
> >>ucidef_add_gpio_switch "poe_power_port4" "PoE Power Port4"
> >> "404"
> >>;;
> >> +zyxel,lte3301-plus)
> >> + ucidef_add_gpio_switch "lte_power" "Power LTE modem" "507"
> >> + ;;
> >
> > Is this redundant with the lte_power hog? If yes, please decide for one of
> the two settings.
> I've got some questions here.
> Personnally I use a special scripts for this modem, taking use of the
> lte_power line.
> I.E., reset the modem if it does not work anymore.
>
> So I do not want to set the GPIO alway to on. It should default to on, but be
> changable from userspace.
> What would be the correct implementation?
gpio-hogs cannot be changed be the user.
Other options are gpio-export (in DTS) and 03_gpio_switches. If you want to set
the default value, just add a fourth parameter:
ucidef_add_gpio_switch "lte_power" "Power LTE modem" "507" "1"
There is not an obvious best choice, so you have some kind of liberty here. But
you should not use more than one for the same parameter.
Best
Adrian
>
>
> >
> > Best
> >
> > Adrian
> >
> >> zyxel,nr7101)
> >>ucidef_add_gpio_switch "lte_reset" "Reset LTE/5G modem" "483"
> >>;;
> >> diff --git
> >> a/target/linux/ramips/mt7621/base-files/etc/init.d/bootcount
> >> b/target/linux/ramips/mt7621/base-files/etc/init.d/bootcount
> >> index a155458d3f..03c6d8eea7 100755
> >> --- a/target/linux/ramips/mt7621/base-files/etc/init.d/bootcount
> >> +++ b/target/linux/ramips/mt7621/base-files/etc/init.d/bootcount
> >> @@ -16,6 +16,7 @@ boot() {
> >>samknows,whitebox-v8)
> >>fw_setenv bootcount 0
> >>;;
> >> + zyxel,lte3301-plus|\
> >>zyxel,nr7101)
> >>[ $(printf %d $(fw_printenv -n DebugFlag)) -gt 0 ] ||
> fw_setenv
> >> DebugFlag 0x1
> >>[ $(printf %d $(fw_printenv -n Image1Stable)) -gt 0 ] ||
> fw_setenv
> >> Image1Stable 1 diff --git a/target/linux/ramips/mt7621/base-
> >> files/lib/upgrade/platform.sh b/target/linux/ramips/mt7621/base-
> >> files/lib/upgrade/platform.sh
> >> index d30bc3db2e..88a92cf624 100755
> >> --- a/target/linux/ramips/mt7621/base-files/lib/upgrade/platform.sh
> >> +++ b/target/linux/ramips/mt7621/base-files/lib/upgrade/platform.sh
> >> @@ -82,6 +82,7 @@ platform_do_upgrade() {
> >>ubnt,edgerouter-x-sfp)
> >>platform_upgrade_ubnt_erx
>
> Thank you very much for taking a look at this.
>
> Kind regards,
>
> André
>
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: [PATCH 2/2] ramips: mt7621: Add support for ZyXEL LTE3301-Plus
Hi,
comments below.
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of André Valentin
> Sent: Samstag, 15. Mai 2021 02:12
> To: openwrt-devel@lists.openwrt.org
> Cc: avalen...@marcant.net
> Subject: [PATCH 2/2] ramips: mt7621: Add support for ZyXEL LTE3301-Plus
>
> The ZyXEL LTE3301-Plus is an 4G indoor CPE with 2 external LTE antennas.
>
> Specifications:
>
> - SoC: MediaTek MT7621AT
> - RAM: 256 MB
> - Flash: 128 MB MB NAND (MX30LF1G18AC)
> - WiFi: MediaTek MT7615E
> - Switch: 4 LAN ports (Gigabit)
> - LTE: Quectel EG506 connected by USB3 to SoC
> - SIM: 1 micro-SIM slot
> - USB: USB3 port
> - Buttons: Reset, WPS
> - LEDs: Multicolour power, internet, LTE, signal, Wifi, USB
> - Power: 12V, 1.5A
>
> The device is built as an indoor ethernet to LTE bridge or router with Wifi.
>
> UART Serial:
>
> 57600N1
> Located on populated 5 pin header J5:
>
> [o] GND
> [ ] key - no pin
> [o] 3.3V Vcc
> [o] RX
> [o] TX
>
> For more details about flashing see commit
> 2449a632084b29632605e5a79ce5d73028eb15dd .
>
> Signed-off-by: André Valentin
> ---
> .../ramips/dts/mt7621_zyxel_lte3301-plus.dts | 213 ++
> target/linux/ramips/image/mt7621.mk | 16 ++
> .../mt7621/base-files/etc/board.d/01_leds | 4 +
> .../mt7621/base-files/etc/board.d/02_network | 3 +
> .../base-files/etc/board.d/03_gpio_switches | 3 +
> .../mt7621/base-files/etc/init.d/bootcount| 1 +
> .../mt7621/base-files/lib/upgrade/platform.sh | 1 +
> 7 files changed, 241 insertions(+)
> create mode 100644 target/linux/ramips/dts/mt7621_zyxel_lte3301-plus.dts
>
> diff --git a/target/linux/ramips/dts/mt7621_zyxel_lte3301-plus.dts
> b/target/linux/ramips/dts/mt7621_zyxel_lte3301-plus.dts
> new file mode 100644
> index 00..9f2939bb2b
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7621_zyxel_lte3301-plus.dts
> @@ -0,0 +1,213 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +
> +#include "mt7621.dtsi"
> +
> +#include
> +#include
> +
> +/ {
> + compatible = "zyxel,lte3301-plus", "mediatek,mt7621-soc";
> + model = "ZyXEL LTE3301-Plus";
> +
> + aliases {
> + label-mac-device =
> + led-boot = _power;
> + led-failsafe = _power;
> + led-running = _power;
> + led-upgrade = _power;
> + };
> +
> + chosen {
> + bootargs = "console=ttyS0,57600";
> + };
IIRC, this is already in the DTSI and can be dropped.
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led_power: power {
> + label = "lte3301-plus:white:power";
drop model from LED labels, keeping just "white:power" etc.
> + gpios = < 5 GPIO_ACTIVE_HIGH>;
> + };
> +
> + wifi {
> + label = "lte3301-plus:white:wifi";
> + gpios = < 13 GPIO_ACTIVE_LOW>;
> + };
> +
> + internet {
> + label = "lte3301-plus:white:internet";
> + gpios = < 23 GPIO_ACTIVE_LOW>;
> + };
> +
> + usb {
> + label = "lte3301-plus:white:usb";
> + gpios = < 24 GPIO_ACTIVE_LOW>;
> + };
> +
> + lte {
> + label = "lte3301-plus:white:lte";
> + gpios = < 26 GPIO_ACTIVE_LOW>;
> + };
> +
> + mobile_green {
> + label = "lte3301-plus:green:mobile";
> + gpios = < 31 GPIO_ACTIVE_LOW>;
> + };
> +
> + mobile_orange {
> + label = "lte3301-plus:orange:mobile";
> + gpios = < 22 GPIO_ACTIVE_LOW>;
> + };
Missing empty line between nodes.
> + mobile_red {
> + label = "lte3301-plus:red:mobile";
> + gpios = < 14 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + keys {
> + compatible = "gpio-keys";
> +
> + reset {
> + label = "reset";
> + gpios = < 18 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + wps {
> + label = "wps";
> + gpios = < 6 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> +
> + lte_power {
> + gpio-hog;
> + gpios = <27 GPIO_ACTIVE_LOW>;
> + output-high;
> + line-name = "lte-power";
> + };
> +
> + usb_power {
> + gpio-hog;
> + gpios = <7 GPIO_ACTIVE_HIGH>;
> + output-high;
> + line-name = "usb-power";
> + };
> +};
> +
> + {
> + status = "okay";
> +
> + partitions {
> + compatible = "fixed-partitions";
> +
RE: [PATCH 4/4] ath79: add support of Mikrotik RouterBoard 91xG series
Hi,
nitpick, but if this is only for 912G, it should also say that in the commit
title.
Other comments below.
> .../dts/ar9342_mikrotik_routerboard-912g.dts | 314 ++
> target/linux/ath79/image/mikrotik.mk | 9 +
> .../base-files/etc/board.d/02_network | 2 +
> .../etc/hotplug.d/firmware/10-ath9k-eeprom| 1 +
> .../base-files/lib/upgrade/platform.sh| 1 +
> 5 files changed, 327 insertions(+)
> create mode 100644 target/linux/ath79/dts/ar9342_mikrotik_routerboard-
> 912g.dts
>
> diff --git a/target/linux/ath79/dts/ar9342_mikrotik_routerboard-912g.dts
> b/target/linux/ath79/dts/ar9342_mikrotik_routerboard-912g.dts
> new file mode 100644
> index 00..bc4aeeb6d0
> --- /dev/null
> +++ b/target/linux/ath79/dts/ar9342_mikrotik_routerboard-912g.dts
> @@ -0,0 +1,314 @@
> +#include "ar9344.dtsi"
Please add an SPDX license header.
> +
> +#include
> +#include
> +
> +/*
> + * TODO list:
> + * - Enable beeper/buzzer,
> + * - Enable button/key,
> + * - Enable usb EHCI and export GPIOs for
> + * turning on/off power for USB port and mPCIe slot,
> + * - Test Wi-Fi working,
> + * - Test Gigabit Ethernet working (see pll settings),
> + */
> +
> +/ {
> + compatible = "mikrotik,routerboard-912g";
> + model = "Mikrotik RB912G";
Please be consistent and also call it "Mikrotik RouterBOARD 912G" here.
> +};
> +
> + {
> + /*
> + * MFD: NAND plus GPIO-controller. They use/share SoC GPIO lines.
> Some of the
> + * GPIO lines are multiplexed by a 8-bit latch (LVC573).
> + * NAND is controlled by GPIO lines (bitbang), also some NAND
> control lines
> + * (nCE, ALE, CLE, READ) and data lines are multiplexed by a latch. So
> driver
> + * set control lines, enable latch ("latched them") and then transfer
> data.
> + * Several lines of the latch (not used for NAND control lines) are
> used
> + * as general-purpose GPIO. NAND ECC format is Mikrotik specific.
> + */
> + /*
> +
> +---+
> +
> | |
> ++-+
> | |
> +| |
> | |
> +| |
> | |
> +| |
> | | 3-4 lines
> +| |
> | +
> +| G | 8 lines
> | 8-bit |GPIO
> +| P
> +---+-+ |
> (leds,
> SSR nCS)
> +| I | |
> | Latch |
> +| O | |
> | |
> +| s | |
> | LVC573 | 4 lines
> +| | |
> | +---+
> +| | |
> | | |
> +| | |
> | | |
> +| | |
> | | |
> +| | |
> | | |
> +| | |
> | | |
> +| | | 8
> +---+ |
> +| | |
>|
> +| | | l
>|
> +| | | i
>|
> +| SoC| | n
>|
> +| | | e
>|
> +| | | s
> +--+|
> +| | | |
> ||
> +| | | |
> C ||
> +| | | |
> | nCE, CLE, ALE, |
> +| | | |
> O ++
> +|
RE: [PATCH] ipq40xx: add support for GL.iNet GL-B2200-EMMC
Hi,
a few comment below.
> --- /dev/null
> +++ b/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-gl-b2200
> +++ -emmc.dts
> @@ -0,0 +1,366 @@
> +// SPDX-License-Identifier: GPL-2.0-only OR MIT
> +
> +#include "qcom-ipq4019.dtsi"
> +#include
> +#include
> +#include
> +
> +/ {
> + model = "GL.iNet GL-B2200-EMMC";
> + compatible = "glinet,gl-b2200-emmc";
> +
> + memory {
> + device_type = "memory";
> + reg = <0x8000 0x1000>;
> + };
> +
> + chosen {
> + bootargs-append = " root=/dev/mmcblk0p2 rw rootwait
> clk_ignore_unused";
> + };
> +
> + soc {
> + rng@22000 {
> + status = "okay";
> + };
> +
> + mdio@9 {
> + status = "okay";
> + };
> +
> + ess-psgmii@98000 {
> + status = "okay";
> + };
> +
> + tcsr@1949000 {
> + compatible = "qcom,tcsr";
> + reg = <0x1949000 0x100>;
> + qcom,wifi_glb_cfg = ;
> + };
> +
> + tcsr@194b000 {
> + /* select hostmode */
> + compatible = "qcom,tcsr";
> + reg = <0x194b000 0x100>;
> + qcom,usb-hsphy-mode-select =
> ;
> + status = "okay";
> + };
> +
> + ess_tcsr@1953000 {
> + compatible = "qcom,tcsr";
> + reg = <0x1953000 0x1000>;
> + qcom,ess-interface-select = ;
> + };
> +
> + tcsr@1957000 {
> + compatible = "qcom,tcsr";
> + reg = <0x1957000 0x100>;
> + qcom,wifi_noc_memtype_m0_m2 =
> ;
> + };
> +
> + crypto@8e3a000 {
> + status = "okay";
> + };
> +
> + ess-switch@c00 {
> + status = "okay";
> + switch_lan_bmp = <0x2e>;
> + switch_wan_bmp = <0x10>;
> + };
> +
> + edma@c08 {
> + status = "okay";
> + };
> + };
> +
> + keys {
> + compatible = "gpio-keys";
> +
> + wps {
> + label = "wps";
> + gpios = < 18 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + linux,input-type = <1>;
> + };
> +
> + reset {
> + label = "reset";
> + gpios = < 43 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + linux,input-type = <1>;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + blue_power {
> + label = "blue:power";
> + gpios = < 57 GPIO_ACTIVE_HIGH>;
> + default-state = "on";
> + };
These block should be separated by empty lines like all the others.
> + blue_internet {
> + label = "blue:internet";
> + gpios = < 60 GPIO_ACTIVE_HIGH>;
> + };
> + white_power {
> + label = "white:power";
> + gpios = < 61 GPIO_ACTIVE_LOW>;
> + default-state = "off";
Please remove _all_ default-state=off statement, they are default.
> + };
> + white_internet {
> + label = "white:internet";
> + gpios = < 66 GPIO_ACTIVE_LOW>;
> + default-state = "off";
> + };
> + };
> +};
> +
> + {
> + qcom,phy_mdio_addr = <3>;
> + qcom,poll_required = <1>;
> + qcom,forced_speed = <1000>;
> + qcom,forced_duplex = <1>;
> + vlan_tag = <2 0x10>;
> +};
> +
> + {
> + vlan_tag = <1 0x2e>;
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
status should be followed by an empty line.
> + pinctrl-0 = <_pins>;
> + pinctrl-names = "default";
> + cd-gpios = < 3 GPIO_ACTIVE_LOW>;
> + vqmmc-supply = <>;
> +};
> +
> +_dma {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> +_spi1 {
> + pinctrl-0 = <_0_pins>;
> + pinctrl-names = "default";
> + status = "okay";
> + cs-gpios = < 12 GPIO_ACTIVE_HIGH>;
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <2400>;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "SBL1";
> + reg = <0x0 0x4>;
> + read-only;
> + };
RE: [PATCH 3/4] ath79: add NAND driver for Mikrotik RB91xG
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Denis Kalashnikov
> Sent: Donnerstag, 6. Mai 2021 18:25
> To: openwrt-devel@lists.openwrt.org
> Cc: Gabor Juhos
> Subject: [PATCH 3/4] ath79: add NAND driver for Mikrotik RB91xG
>
> Mikrotik guys doesn't use a NAND controller embedded in SoC on this board.
> Instead they control NAND through SoC gpio lines.
> Also NAND data and control lines are multiplexed by a latch.
> More painful is that the latch lines that are not used for NAND control lines,
> are used for two LEDs and a serial register nCS.
> So, we need a MFD driver that control access to these shared lines.
>
> Signed-off-by: Denis Kalashnikov
> ---
> .../files/drivers/mtd/nand/raw/nand_rb91x.c | 432 ++
> target/linux/ath79/mikrotik/config-default| 1 +
> .../patches-5.4/939-mikrotik-rb91x.patch | 21 +
again, please include 5.10 here.
> 3 files changed, 454 insertions(+)
> create mode 100644
> target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb91x.c
>
> diff --git a/target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb91x.c
> b/target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb91x.c
> new file mode 100644
> index 00..c9d5072547
> --- /dev/null
> +++ b/target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb91x.c
> @@ -0,0 +1,432 @@
> +/*
> + * NAND flash driver for the MikroTik RouterBOARD 91x series
> + *
> + * Main part is copied from original driver written by Gabor Juhos.
> + *
> + * Copyright (C) 2013-2014 Gabor Juhos
> + *
> + * This program is free software; you can redistribute it and/or
> +modify it
> + * under the terms of the GNU General Public License version 2 as
> +published
> + * by the Free Software Foundation.
> + */
If you create new files, please use SPDX license identifiers instead of this
"long-but-incomplete" license plate.
This of course also applies to the other patches.
Best
Adrian
> +
> +/*
> + * WARNING: to speed up NAND reading/writing we are working with SoC
> +GPIO
> + * controller registers directly -- not through standard GPIO API.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* TODO: ar71xx regs (SoC GPIO controller ones) should be get from DTS?
> +*/ #include //#include
> +
> +
> +#include
> +
> +#define DRIVER_NAME "rb91x-nand"
> +
> +static void __iomem *ath79_gpio_base;
> +
> +#define DRV_DESC "MikrotTik RB91x NAND flash driver"
> +
> +#define NAND_LOW_DATA_MASK 0x1f
> +#define NAND_HIGH_DATA_MASK 0xe0
> +#define NAND_HIGH_DATA_SHIFT 8
> +
> +struct drvdata {
> + struct nand_chip chip;
> + struct device *dev;
> + struct rb91x_ngl *ngl;
> +
> + /* Bit masks */
> + u32 nand_rdy_bit;
> + u32 nand_nrw_bit;
> + u32 nand_data_bits;
> + u32 nand_input_bits;
> + u32 nand_output_bits;
> +};
> +
> +static inline struct drvdata *mtd_to_drvdata(struct mtd_info *mtd) {
> + struct nand_chip *chip = mtd_to_nand(mtd);
> +
> + return container_of(chip, struct drvdata, chip); }
> +
> +static struct mtd_info *drvdata_to_mtd(struct drvdata *p) {
> + return nand_to_mtd(>chip);
> +}
> +
> +static int ooblayout_ecc(struct mtd_info *mtd, int section,
> + struct mtd_oob_region *oobregion)
> +{
> + switch (section) {
> + case 0:
> + oobregion->offset = 8;
> + oobregion->length = 3;
> + return 0;
> + case 1:
> + oobregion->offset = 13;
> + oobregion->length = 3;
> + return 0;
> + default:
> + return -ERANGE;
> + }
> +}
> +
> +static int ooblayout_free(struct mtd_info *mtd, int section,
> + struct mtd_oob_region *oobregion)
> +{
> + switch (section) {
> + case 0:
> + oobregion->offset = 0;
> + oobregion->length = 4;
> + return 0;
> + case 1:
> + oobregion->offset = 4;
> + oobregion->length = 1;
> + return 0;
> + case 2:
> + oobregion->offset = 6;
> + oobregion->length = 2;
> + return 0;
> + case 3:
> + oobregion->offset = 11;
> + oobregion->length = 2;
> + return 0;
> + default:
> + return -ERANGE;
> + }
> +}
> +
> +static const struct mtd_ooblayout_ops nand_ecclayout_ops = {
> + .ecc = ooblayout_ecc,
> + .free = ooblayout_free,
> +};
> +
> +/* TODO: Should be in DTS */
> +static struct mtd_partition nand_partitions[] = {
> + {
> + .name = "booter",
> + .offset = 0,
> + .size = (256 * 1024),
> + .mask_flags = MTD_WRITEABLE,
> + }, {
> + .name = "kernel",
> + .offset = (256 * 1024),
> + .size = (4 * 1024 * 1024) - (256 * 1024),
> + }, {
> +
RE: [PATCH 1/4] ath79: add MFD driver (NAND and GPIO) for Mikrotik RB91xG
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Denis Kalashnikov
> Sent: Donnerstag, 6. Mai 2021 18:25
> To: openwrt-devel@lists.openwrt.org
> Cc: Gabor Juhos
> Subject: [PATCH 1/4] ath79: add MFD driver (NAND and GPIO) for Mikrotik
> RB91xG
>
> rb91x-ngl (nand-gpio-latch) requests and controls SoC GPIO lines that are
> used for NAND control and data lines multiplexed with a latch. Lines of the
> latch that are not used for NAND control lines, are used for power LED and
> user LED and a Shift Register nCS.
>
> Like rb4xx-cpld driver rb91x-ngl provides API for separate NAND driver and
> latch-GPIO driver.
>
> This driver is used in place of the ar71xx gpio-latch driver.
>
> Signed-off-by: Denis Kalashnikov
> ---
> .../linux/ath79/files/drivers/mfd/rb91x-ngl.c | 331 ++
> .../linux/ath79/files/include/mfd/rb91x-ngl.h | 59
> target/linux/ath79/mikrotik/config-default| 1 +
> .../patches-5.4/939-mikrotik-rb91x.patch | 21 ++
> 4 files changed, 412 insertions(+)
> create mode 100644 target/linux/ath79/files/drivers/mfd/rb91x-ngl.c
> create mode 100644 target/linux/ath79/files/include/mfd/rb91x-ngl.h
> create mode 100644 target/linux/ath79/patches-5.4/939-mikrotik-
> rb91x.patch
Please also take care of 5.10.
Best
Adrian
>
> diff --git a/target/linux/ath79/files/drivers/mfd/rb91x-ngl.c
> b/target/linux/ath79/files/drivers/mfd/rb91x-ngl.c
> new file mode 100644
> index 00..c6ab4631f5
> --- /dev/null
> +++ b/target/linux/ath79/files/drivers/mfd/rb91x-ngl.c
> @@ -0,0 +1,331 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * MFD driver for the MikroTik RouterBoard NAND controlled through GPIO
> + * multiplexed with latch. Why MFD, not pure NAND driver? Since the
> +latch
> + * lines, that are not used for NAND control lines, are used for GPIO
> + * output function -- for leds and other.
> + *
> + * Copyright (C) 2021 Denis Kalashnikov
> + *
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#define DRIVER_NAME "rb91x-nand-gpio-latch"
> +
> +#define NAND_DATAS 8
> +#define LATCH_GPIOS 3
> +
> +static int nand_datas_count(struct rb91x_ngl *ngl) {
> + return NAND_DATAS;
> +}
> +
> +static int latch_gpios_count(struct rb91x_ngl *ngl) {
> + return LATCH_GPIOS;
> +}
> +
> +static void latch_lock(struct rb91x_ngl *ngl) {
> + mutex_lock(>mutex);
> +
> + gpio_set_value_cansleep(ngl->gpio[RB91X_NGL_NLE], 0); }
> +
> +static void latch_unlock(struct rb91x_ngl *ngl) {
> + gpio_set_value_cansleep(ngl->gpio[RB91X_NGL_NLE], 1);
> +
> + mutex_unlock(>mutex);
> +}
> +
> +#define OFFSET_INVAL(offset) ((offset) < 0 || (offset) >=
> +RB91X_NGL_GPIOS)
> +
> +static void rb91x_ngl_gpio_set_value(struct rb91x_ngl *ngl, int offset,
> +int val) {
> + if (OFFSET_INVAL(offset))
> + return;
> +
> + gpio_set_value_cansleep(ngl->gpio[offset], val); }
> +
> +static void latch_gpio_set_value(struct rb91x_ngl *ngl, int offset, int
> +val) {
> + if (offset >= LATCH_GPIOS)
> + return;
> +
> + mutex_lock(>mutex);
> +
> + gpio_set_value_cansleep(ngl->gpio[RB91X_NGL_LATCH_GPIO0 +
> offset],
> +val);
> +
> + mutex_unlock(>mutex);
> +}
> +
> +static int rb91x_ngl_gpio_get_value(struct rb91x_ngl *ngl, int offset)
> +{
> + if (OFFSET_INVAL(offset))
> + return -EINVAL;
> +
> + return gpio_get_value(ngl->gpio[offset]);
> +}
> +
> +static void rb91x_ngl_gpio_direction_output(struct rb91x_ngl *ngl, int
> offset,
> +int val)
> +{
> + if (OFFSET_INVAL(offset))
> + return;
> +
> + gpio_direction_output(ngl->gpio[offset], val); }
> +
> +static void rb91x_ngl_gpio_direction_input(struct rb91x_ngl *ngl, int
> +offset) {
> + if (OFFSET_INVAL(offset))
> + return;
> +
> + gpio_direction_input(ngl->gpio[offset]);
> +}
> +
> +static const struct mfd_cell mfd_cells[] = {
> + {
> + .name = "mikrotik,rb91x-nand",
> + .of_compatible = "mikrotik,rb91x-nand",
> + }, {
> + .name = "mikrotik,rb91x-gpio-latch",
> + .of_compatible = "mikrotik,rb91x-gpio-latch",
> + },
> +};
> +
> +static int get_gpios(struct device *dev, const char *prop_name) {
> + int n;
> +
> + n = of_get_named_gpio(dev->of_node, prop_name, 0);
> + if (n < 0)
> + dev_err(dev, "Could not read required '%s' property: %d\n",
> prop_name, n);
> + //pr_info(DRIVER_NAME ": %s = %d\n", prop_name, n);
> +
> + return n;
> +}
> +
> +/*
> + * NOTE: all gpios are labeled with driver name, not with @name.
> + * @name is used only in error message. Since we failed to choose
> + * a good names for multiplexed gpios.
> + */
> +static int req_gpio(struct device *dev, int gpio, const char *name) {
> + int ret;
> +
> + ret = devm_gpio_request(dev, gpio, DRIVER_NAME);
> + if (ret) {
RE: [PATCH] ipq806x: fix product_name of TP-Link AD7200
Hi,
> -Original Message-
> From: Alex Henrie [mailto:alexhenri...@gmail.com]
> Sent: Sonntag, 2. Mai 2021 23:33
> To: openwrt-devel@lists.openwrt.org; f...@volatilesystems.org; devel-
> s...@geroedel.de; yn...@true.cz; m...@adrianschmutzler.de;
> g...@bitmessage.de; fercer...@gmail.com
> Cc: Alex Henrie
> Subject: [PATCH] ipq806x: fix product_name of TP-Link AD7200
Since we actually change tplink-safeloader here, a proper/better title would be
"tplink-safeloader: fix product_name of TP-Link AD7200"
>
> The stock firmware does not accept firmware with "Talon" in the name.
Please add the following line here:
Fixes: 1a775a4fd033 ("ipq806x: add support for TP-Link Talon AD7200")
Best
Adrian
>
> Signed-off-by: Alex Henrie
> ---
> tools/firmware-utils/src/tplink-safeloader.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/firmware-utils/src/tplink-safeloader.c b/tools/firmware-
> utils/src/tplink-safeloader.c
> index b3d5c9151d..8a47e6a58f 100644
> --- a/tools/firmware-utils/src/tplink-safeloader.c
> +++ b/tools/firmware-utils/src/tplink-safeloader.c
> @@ -676,7 +676,7 @@ static struct device_info boards[] = {
> .vendor = "",
> .support_list =
> "SupportList:\r\n"
> - "{product_name:Talon
> AD7200,product_ver:1.0.0,special_id:}\r\n",
> +
> "{product_name:AD7200,product_ver:1.0.0,special_id:}\r\n
> ",
> .part_trail = 0x00,
> .soft_ver = NULL,
>
> --
> 2.31.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: Installing OpenWrt 21.02 on the TP-Link AD7200
Hi, now where you say it, I remember: http://lists.openwrt.org/pipermail/openwrt-devel/2021-January/033149.html IIRC correctly this device was merged in a generally poorly reviewed state ... Best Adrian > -Original Message- > From: Alex Henrie [mailto:alexhenri...@gmail.com] > Sent: Sonntag, 2. Mai 2021 22:57 > To: Petr Štetiar > Cc: Sven Roederer ; OpenWrt Development List > ; Stijn Segers > ; g...@bitmessage.de; dan...@makrotopia.org; > freif...@adrianschmutzler.de > Subject: Re: Installing OpenWrt 21.02 on the TP-Link AD7200 > > Eureka! I changed "product_name:Talon AD7200" to > "product_name:AD7200" > in tplink-safeloader.c and then the router accepted the OpenWrt firmware! > So it seems that we just need to split the AD7200 target into a "Talon" target > and a regular target :-) > > -Alex 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: [PATCH] ramips: add support for Wavlink WL-WN578A2
Hi, > -Original Message- > From: Thomas Aldrian [mailto:dev.aldr...@gmail.com] > Sent: Montag, 26. April 2021 20:41 > To: Adrian Schmutzler ; openwrt- > de...@lists.openwrt.org > Subject: Re: [PATCH] ramips: add support for Wavlink WL-WN578A2 > > On Sun, 2021-04-25 at 22:27 +0200, Adrian Schmutzler wrote: > > Why wlan1? Is this chosen arbitrarily (than please drop the default > > setup), or is the vendor really also using only one specific radio for > > the RSSI leds? > > > > Best > > > > Adrian > > Hi Adrian, > > The stock firmware does use some sort of RSSI LEDs, but I was unable to > properly test this. The choice of wlan1 is rather arbitrary, yes. I would have > changed the default config to use both radios as this makes the most sense > to me, but I am unsure how to do so. Is there a way to set both? or should I > drop the rssileds setup entirely? Linking one set of LEDs to two interfaces is not possible (with usual means). In cases like this, I typically prefer to drop the setup, since anything else is likely to cause confusion to the users. Anybody who wants to configure rssileds can still do it, with the added benefit that he will know what he configured afterwards. Best Adrian > > As for the other changes, I will send a new patch soon. > > Best, > Thomas > > 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: [PATCH] ramips: add support for Wavlink WL-WN578A2
Hi,
comments inline. Nothing really serious ...
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of dev.aldr...@gmail.com
> Sent: Donnerstag, 22. April 2021 21:24
> To: openwrt-devel@lists.openwrt.org
> Cc: Thomas Aldrian
> Subject: [PATCH] ramips: add support for Wavlink WL-WN578A2
>
> From: Thomas Aldrian
>
> This commit adds support for the Wavlink WL-WN578A2 dual-band wall-plug
> wireless router. This device is also sold under the name SilverCrest SWV 733
> A2.
>
> Device Specifications:
>
> - CPU: MediaTek MT7628AN (580MHz)
> - Flash: 8MB
> - RAM: 64MB
> - Bootloader: U-Boot
> - Ethernet: 2x 10/100 Mbps
> - 2.4 GHz: 802.11b/g/n SoC
> - 5 GHz: 802.11a/n/ac MT7610E
> - Antennas: internal
> - 4 green LEDs: WPS/Power, LAN, WAN, wifi-low, wifi-med, wifi-high
> - Buttons: Reset, WPS
> - Sliding mode switch: AP, repeater, client
> - Small sliding power switch
>
> Flashing instructions:
>
> U-Boot launches TFTP client if WPS button is pressed during power-on.
> Configure as follows:
>
> - Server IP: 192.168.10.100
> - Filename (rename sysupgrade file to this): firmware.bin
>
> Flashing should not take more than a minute, device will reboot
> automatically.
>
> Signed-off-by: Thomas Aldrian
> ---
> .../dts/mt7628an_wavlink_wl-wn578a2.dts | 165 ++
> target/linux/ramips/image/mt76x8.mk | 10 ++
> .../mt76x8/base-files/etc/board.d/01_leds | 8 +
> .../mt76x8/base-files/etc/board.d/02_network | 6 +-
> 4 files changed, 187 insertions(+), 2 deletions(-) create mode 100644
> target/linux/ramips/dts/mt7628an_wavlink_wl-wn578a2.dts
>
> diff --git a/target/linux/ramips/dts/mt7628an_wavlink_wl-wn578a2.dts
> b/target/linux/ramips/dts/mt7628an_wavlink_wl-wn578a2.dts
> new file mode 100644
> index 00..69a54c297b
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7628an_wavlink_wl-wn578a2.dts
> @@ -0,0 +1,165 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +
> +#include "mt7628an.dtsi"
> +
> +#include
> +#include
> +
> +/ {
> + compatible = "wavlink,wl-wn578a2", "mediatek,mt7628an-soc";
> + model = "Wavlink WL-WN578A2";
> +
> + aliases {
> + led-boot = _wps;
> + led-failsafe = _wps;
> + led-running = _wps;
> + led-upgrade = _wps;
> + };
> +
> + keys {
> + compatible = "gpio-keys";
> +
> + reset {
> + label = "reset";
> + gpios = < 43 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + wps {
> + label = "wps";
> + gpios = < 38 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + ap {
> + label = "ap";
> + gpios = < 41 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + linux,input-type = ;
> + };
> +
> + repeater {
> + label = "repeater";
> + gpios = < 42 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + linux,input-type = ;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + wifi-high {
> + label = "green:wifi-high";
> + gpios = < 37 GPIO_ACTIVE_LOW>;
> + };
> +
> + wifi-med {
> + label = "green:wifi-med";
> + gpios = < 11 GPIO_ACTIVE_LOW>;
> + };
> +
> + wifi-low {
> + label = "green:wifi-low";
> + gpios = < 44 GPIO_ACTIVE_LOW>;
> + };
> +
> + lan {
> + label = "green:lan";
> + gpios = < 40 GPIO_ACTIVE_LOW>;
> + };
> +
> + wan {
> + label = "green:wan";
> + gpios = < 39 GPIO_ACTIVE_LOW>;
> + };
> +
> + led_wps: wps {
> + label = "green:wps";
> + gpios = < 4 GPIO_ACTIVE_LOW>;
> + };
> + };
> +};
> +
> +_default {
> + gpio {
> + groups = "i2c", "wdt", "wled_an", "p0led_an", "p1led_an",
> "p2_led", "p3led_an", "p4led_an", "refclk";
> + function = "gpio";
> + };
p2led_an (typo)
Apart from that, gpio 11 is missing ...
And please wrap this long line.
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + mt76@0,0 {
wifi@0,0
> + reg = <0x 0 0 0 0>;
> + mediatek,mtd-eeprom = < 0x8000>;
> + ieee80211-freq-limit = <500 600>;
> + };
> +};
> +
> + {
> + status = "okay";
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <4000>;
> +
> + partitions {
> +
RE: [PATCH v2] imagebuilder, sdk: unset BINARY_FOLDER and DOWNLOAD_FOLDER in final archives
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Sven Roederer
> Sent: Samstag, 24. April 2021 23:48
> To: openwrt-devel@lists.openwrt.org
> Subject: [PATCH v2] imagebuilder, sdk: unset BINARY_FOLDER and
> DOWNLOAD_FOLDER in final archives
>
> Using these config-options to customize the folders used at build-time
> makes these folder settings appear in generated archives. This causes the
> archives to be not portable, as they going to use the build-time folders on
> the new systems. Errors look like for the imagebuilder:
>
> mkdir: cannot create directory '/mnt/build': Permission denied
> Makefile:116: recipe for target '_call_image' failed
> make[2]: *** [_call_image] Error 1
> Makefile:241: recipe for target 'image' failed
> make[1]: *** [image] Error 2
>
> The build-time settings of these folders are passed into the archives via
> .config for the imagebuilder and via Config.in and Config.build for the sdk.
> The expected behavior is that after unpacking sdk and imagebuilder act like
> these settings have the default, using intree folders. So unset or filter out
> the build- time settings.
Consider breaking this down into separate patches for imagebuilder and sdk.
Best
Adrian
>
> Signed-off-by: Sven Roederer
> ---
>
> This is an rewrite and extension of the patch send on 11. April.
>
>
> target/imagebuilder/Makefile | 2 ++
> target/sdk/Makefile | 1 +
> target/sdk/convert-config.pl | 9 -
> 3 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/target/imagebuilder/Makefile b/target/imagebuilder/Makefile
> index f9c08776a8..ef7fd3f25e 100644
> --- a/target/imagebuilder/Makefile
> +++ b/target/imagebuilder/Makefile
> @@ -29,6 +29,8 @@ $(BIN_DIR)/$(IB_NAME).tar.xz: clean
> mkdir -p $(IB_KDIR) $(IB_LDIR)
> $(PKG_BUILD_DIR)/staging_dir/host/lib \
> $(PKG_BUILD_DIR)/target $(PKG_BUILD_DIR)/scripts
> $(IB_DTSDIR)
> -cp $(TOPDIR)/.config $(PKG_BUILD_DIR)/.config
> + $(SED) 's/^CONFIG_BINARY_FOLDER=.*/# CONFIG_BINARY_FOLDER
> was reset by Imagebuilder/' $(PKG_BUILD_DIR)/.config
> + $(SED) 's/^CONFIG_DOWNLOAD_FOLDER=.*/#
> CONFIG_DOWNLOAD_FOLDER was
> +reset by Imagebuilder/' $(PKG_BUILD_DIR)/.config
> $(CP) -L \
> $(INCLUDE_DIR) $(SCRIPT_DIR) \
> $(TOPDIR)/rules.mk \
> diff --git a/target/sdk/Makefile b/target/sdk/Makefile index
> 0606621192..5330d14955 100644
> --- a/target/sdk/Makefile
> +++ b/target/sdk/Makefile
> @@ -159,6 +159,7 @@ $(BIN_DIR)/$(SDK_NAME).tar.xz: clean
> $(SED) 's,^# REVISION:=.*,REVISION:=$(REVISION),g'
> $(SDK_BUILD_DIR)/include/version.mk
> $(SED) 's,^#
> SOURCE_DATE_EPOCH:=.*,SOURCE_DATE_EPOCH:=$(SOURCE_DATE_EPOC
> H),g' $(SDK_BUILD_DIR)/include/version.mk
> $(SED) '/LINUX_VERMAGIC:=/ { s,unknown,$(LINUX_VERMAGIC),g }'
> $(SDK_BUILD_DIR)/include/kernel.mk
> + $(SED) 's,default "$(CONFIG_DOWNLOAD_FOLDER)",default "",'
> +$(SDK_BUILD_DIR)/Config.in
> find $(SDK_BUILD_DIR) -name .git | $(XARGS) rm -rf
> find $(SDK_BUILD_DIR) -name .svn | $(XARGS) rm -rf
> find $(SDK_BUILD_DIR) -name CVS | $(XARGS) rm -rf diff --git
> a/target/sdk/convert-config.pl b/target/sdk/convert-config.pl index
> f73744af09..f6bc831d3a 100755
> --- a/target/sdk/convert-config.pl
> +++ b/target/sdk/convert-config.pl
> @@ -9,7 +9,14 @@ while (<>) {
> chomp;
> next if /^CONFIG_SIGNED_PACKAGES/;
>
> - if (/^CONFIG_([^=]+)=(.*)$/) {
> + if (/^CONFIG_((BINARY)|(DOWNLOAD))_FOLDER=(.*)$/) {
> + # We don't want to preserve the build setting of
> + # BINARY_FOLDER and DOWNLOAD_FOLDER.
> + $var = "$1_FOLDER";
> + $val = '""';
> + $type = "string";
> +#warn "DEBUG: type: $type found for symbol
> CONFIG_$var=$val\n";
> + } elsif (/^CONFIG_([^=]+)=(.*)$/) {
> $var = $1;
> $val = $2;
>
> --
> 2.17.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
