Re: [PATCH v1 0/5] Resurrect IXP4xx
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- > On Jun 19, 2023, at 7:31 AM, Linus Walleij wrote: > > IXP4xx was deleted because of lack of maintenance in 2020. > > In the years since, the upstream Linux support for IXP4xx has > been rewritten from scratch. It is not pretty well supported > using device tree and such. > > With the switch to kernel v6.1, OpenWrt has the required > baseline to bring IXP4xx back. > > I have heard that the v6.1 target can still not be used by > default, but let's start reviewing, so we can merge this > as soon as v6.1 builds are ripe! > > This is a reimplementation of the IXP4xx support which is > using all the contemporary abstractions, the only thing > actually resurrected is the APEX boot loader. The port is > thus "slim" and not patching a lot on the mainline kernel > as pretty much everything is upstream. > > As a starter, we bring back two Gateworks reference designs, > one for IXP42x and one for IXP43x, and the classic NSLU2 > NAS. > > Here you find binaries and illustrations if you want to check > out how the support works right now, if you have an NSLU2 > you can flash the binary and rootfs and it "just works", > though NSLU2 is not a default build: > https://dflund.se/~triad/krad/ixp4xx/ > > Thanks to Imre Kaloz add Krzysztof Halasa for all cheering > and reference designs :) > > I am pretty back any IXP4xx can be brought online with this, > they just need some time and focus. I will add more routers > as time permits. > > Linus Walleij (5): I see that the ADI Coyote was included, but not the ADI Pronghorn which actually has sufficient RAM (64MB) and flash (16MB) to run OpenWrt. I’ll be looking at using the ADI Coyote as a base to eventually create a pull request to get the ADI Pronghorn supported! I can also test the D-Link DSM-G600 and Gateworks GW2348 support. Thanks for starting this effort. Ray signature.asc Description: Message signed with OpenPGP --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Recall: mwan3 memory usage
Ravi Paluri would like to recall the message, "mwan3 memory usage". ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
mwan3 memory usage
Thanks, Florian for the reply. In our opinion, having single process to cater to both IPv4 and IPv6 would help in memory reduction, the same way as handled in mwan3 (version 2.8.16). This would reduce the memory footprint from 4 processes to 2 processes. Do you recommend we making changes to mwan3rtmon script as per above suggestion in OpenWRT version 22.03 or do you see any design flaws because of which handling for IPv4/IPv6 is separated? Any insight as to why we have separate process for monitoring IPv4 and IPv6 would be helpful. Thanks, Ravi -Original Message- From: Florian Eckert Sent: Thursday, June 15, 2023 6:00 PM To: Ravi Paluri (QUIC) Cc: openwrt-devel@lists.openwrt.org Subject: Re: mwan3 memory usage WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hello, > Hi, > We have enabled mwan3 (version 2.11.4) functionality with OpenWRT > version 22.03 and we see that four mwan3rtmon processes are running, > two each for IPv4 and IPv6. We made the change with the following commit: https://github.com/openwrt/packages/commit/566293d228a48d21a04ecbc815a7ae97e26eb319 I'm not sure, but I think we had before also two mwan3rtmon process one for ipv4 and the other for ipv6 so there is no difference. But during the change we switched to procd to control the rtmon services. > Whereas with mwan3 (version 2.8.16) that came with OpenWRT version > 19.07, has only one process for mwan3rtmon running for both IPv4 and > IPv6. Sure? Or did only use the proto ipv4. > This has caused an increased memory usage on OpenWRT version 22.03 by > 3 times when compared to OpenWRT version 19.07. > This is a huge concern for us as we have limited memory on our router > product. Because of the fact, that mwan3 is written in shell I would not recommend to use this on small devices. > On debugging further, we see that mwan3rtmon script is invoking a > child process, the reason behind observing two processes per each IP > type. > Refer(line number 155) at > https://github.com/openwrt/packages/blob/master/net/mwan3/files/usr/sb > in/mwan3rtmon Can we know the reason behind creating child processes? Before that we polled for changes in the routing table. Now we use a event driven patter to update the routing table on routing changes. Because of this we need a subshell to get the events. > To reduce memory usage, if we disable creation of child process, what > functionality of mwan3 will be affected? This is not recommended. However, you can use the old mwan3rtmon for an older version to poll for changes. So you do not have a subshell for event handling. > Also, is it recommended to use mwan3 (version 2.8.16) with OpenWRT > version 22.03 as this has no child processes and only one mwan3rtmon > process for both IPv4 and IPv6? I can't say anything about that because I haven't tried it yet. --- Kind regards Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v1 2/5] ixp4xx: Resurrect IXP4xx support using device tree
This resurrects the support for IXP4xx using device tree rather than the old (deleted) board files. The final pieces of IXP4xx board files were deleted in Linux v5.19. Ext4 root filesystems on CF and USB are supported by the default config. We support these three initial targets: - The Gateworks Avila GW2348 reference design has 64MB of RAM and 32MB of flash and also supports USB and CompactFlash. - The Gateworks Cambria GW2358 reference design has 128MB of RAM and 32MB of flash and also supports USB and CompactFlash. - The old and stable Linksys NSLU2 works fine as well, albeit it only has 32MB of RAM so it has been marked as non-default. The 8MB of flash can only fit the kernel, so it has been patched to boot from exteral media on USB. I have used it successfully as a NAS with ksmbd and LUCI web API, see: https://dflund.se/~triad/krad/ixp4xx/ Signed-off-by: Linus Walleij --- package/firmware/ixp4xx-microcode/Makefile| 59 + .../ixp4xx-microcode/src/IxNpeMicrocode.h | 148 +++ .../firmware/ixp4xx-microcode/src/LICENSE.IPL | 27 ++ target/linux/ixp4xx/Makefile | 28 ++ .../ixp4xx/base-files/etc/board.d/02_network | 21 ++ .../lib/preinit/05_set_ether_mac_ixp4xx | 45 target/linux/ixp4xx/config-6.1| 246 ++ target/linux/ixp4xx/image/Makefile| 73 ++ ...d-cfi_cmdset_0001-Byte-swap-OTP-info.patch | 74 ++ ...dts-ixp4xx-Boot-NSLU2-from-harddrive.patch | 24 ++ 10 files changed, 745 insertions(+) create mode 100644 package/firmware/ixp4xx-microcode/Makefile create mode 100644 package/firmware/ixp4xx-microcode/src/IxNpeMicrocode.h create mode 100644 package/firmware/ixp4xx-microcode/src/LICENSE.IPL create mode 100644 target/linux/ixp4xx/Makefile create mode 100644 target/linux/ixp4xx/base-files/etc/board.d/02_network create mode 100644 target/linux/ixp4xx/base-files/lib/preinit/05_set_ether_mac_ixp4xx create mode 100644 target/linux/ixp4xx/config-6.1 create mode 100644 target/linux/ixp4xx/image/Makefile create mode 100644 target/linux/ixp4xx/patches-6.1/0001-mtd-cfi_cmdset_0001-Byte-swap-OTP-info.patch create mode 100644 target/linux/ixp4xx/patches-6.1/301-ARM-dts-ixp4xx-Boot-NSLU2-from-harddrive.patch diff --git a/package/firmware/ixp4xx-microcode/Makefile b/package/firmware/ixp4xx-microcode/Makefile new file mode 100644 index ..78fedfd1aaf1 --- /dev/null +++ b/package/firmware/ixp4xx-microcode/Makefile @@ -0,0 +1,59 @@ +# +# Copyright (C) 2007 OpenWrt.org +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +include $(TOPDIR)/rules.mk + +PKG_NAME:=ixp4xx-microcode +PKG_VERSION:=2.4 +PKG_RELEASE:=2 + +PKG_SOURCE:=IPL_ixp400NpeLibraryWithCrypto-2_4.zip +PKG_SOURCE_URL:=http://downloads.openwrt.org/sources +PKG_HASH:=1b1170d0657847248589d946048c0aeaa9cd671966fc5bec5933283309485eaa + +PKG_FLAGS:=nonshared + +include $(INCLUDE_DIR)/package.mk + +define Package/ixp4xx-microcode + SECTION:=net + CATEGORY:=Network + TITLE:=Microcode for the IXP4xx network engines + DEPENDS:=@TARGET_ixp4xx +endef + +define Package/ixp4xx-microcode/description + This package contains the microcode needed to use the network engines in IXP4xx CPUs +endef + +define Build/Prepare + rm -rf $(PKG_BUILD_DIR) + mkdir -p $(PKG_BUILD_DIR) + unzip -d $(PKG_BUILD_DIR)/ $(DL_DIR)/$(PKG_SOURCE) + mv $(PKG_BUILD_DIR)/ixp400_xscale_sw/src/npeDl/IxNpeMicrocode.c $(PKG_BUILD_DIR)/ + rm -rf $(PKG_BUILD_DIR)/ixp400_xscale_sw + $(CP) ./src/* $(PKG_BUILD_DIR)/ +endef + +define Build/Compile + (cd $(PKG_BUILD_DIR); \ + $(HOSTCC) -Wall -I$(STAGING_DIR_HOST)/include IxNpeMicrocode.c -o IxNpeMicrocode; \ + ./IxNpeMicrocode -be \ + ) +endef + +define Package/ixp4xx-microcode/install + $(INSTALL_DIR) $(1)/lib/firmware + $(INSTALL_DIR) $(1)/usr/share/doc + $(INSTALL_BIN) $(PKG_BUILD_DIR)/NPE-A $(1)/lib/firmware/ + $(INSTALL_BIN) $(PKG_BUILD_DIR)/NPE-A-HSS $(1)/lib/firmware/ + $(INSTALL_BIN) $(PKG_BUILD_DIR)/NPE-B $(1)/lib/firmware/ + $(INSTALL_BIN) $(PKG_BUILD_DIR)/NPE-C $(1)/lib/firmware/ + $(INSTALL_DATA) $(PKG_BUILD_DIR)/LICENSE.IPL $(1)/usr/share/doc/ +endef + +$(eval $(call BuildPackage,ixp4xx-microcode)) diff --git a/package/firmware/ixp4xx-microcode/src/IxNpeMicrocode.h b/package/firmware/ixp4xx-microcode/src/IxNpeMicrocode.h new file mode 100644 index ..4a843db104f9 --- /dev/null +++ b/package/firmware/ixp4xx-microcode/src/IxNpeMicrocode.h @@ -0,0 +1,148 @@ +/* + * IxNpeMicrocode.h - Headerfile for compiling the Intel microcode C file + * + * Copyright (C) 2006 Christian Hohnstaedt + * + * This file is released under the GPLv2 + * + * + * compile with + * + * gcc -Wall IxNpeMicrocode.c -o IxNpeMicrocode + * + * Executing the resulting binary on your build-host creates the + * "NPE-[ABC]." f
[PATCH v1 0/5] Resurrect IXP4xx
IXP4xx was deleted because of lack of maintenance in 2020. In the years since, the upstream Linux support for IXP4xx has been rewritten from scratch. It is not pretty well supported using device tree and such. With the switch to kernel v6.1, OpenWrt has the required baseline to bring IXP4xx back. I have heard that the v6.1 target can still not be used by default, but let's start reviewing, so we can merge this as soon as v6.1 builds are ripe! This is a reimplementation of the IXP4xx support which is using all the contemporary abstractions, the only thing actually resurrected is the APEX boot loader. The port is thus "slim" and not patching a lot on the mainline kernel as pretty much everything is upstream. As a starter, we bring back two Gateworks reference designs, one for IXP42x and one for IXP43x, and the classic NSLU2 NAS. Here you find binaries and illustrations if you want to check out how the support works right now, if you have an NSLU2 you can flash the binary and rootfs and it "just works", though NSLU2 is not a default build: https://dflund.se/~triad/krad/ixp4xx/ Thanks to Imre Kaloz add Krzysztof Halasa for all cheering and reference designs :) I am pretty back any IXP4xx can be brought online with this, they just need some time and focus. I will add more routers as time permits. Linus Walleij (5): boot/apex: Restore the APEX boot loader ixp4xx: Resurrect IXP4xx support using device tree ixp4xx: Add a ixp4xx hardware crypto kernel module ixp4xx: Add hdparm script Delete arm-magic script package/boot/apex/Makefile| 61 + package/firmware/ixp4xx-microcode/Makefile| 59 + .../ixp4xx-microcode/src/IxNpeMicrocode.h | 148 +++ .../firmware/ixp4xx-microcode/src/LICENSE.IPL | 27 ++ package/kernel/linux/modules/crypto.mk| 13 + scripts/arm-magic.sh | 42 --- target/linux/ixp4xx/Makefile | 29 +++ .../ixp4xx/base-files/etc/board.d/02_network | 21 ++ .../ixp4xx/base-files/etc/board.d/03_hdparm | 14 + .../lib/preinit/05_set_ether_mac_ixp4xx | 45 target/linux/ixp4xx/config-6.1| 246 ++ target/linux/ixp4xx/image/Makefile| 73 ++ ...d-cfi_cmdset_0001-Byte-swap-OTP-info.patch | 74 ++ ...dts-ixp4xx-Boot-NSLU2-from-harddrive.patch | 24 ++ 14 files changed, 834 insertions(+), 42 deletions(-) create mode 100644 package/boot/apex/Makefile create mode 100644 package/firmware/ixp4xx-microcode/Makefile create mode 100644 package/firmware/ixp4xx-microcode/src/IxNpeMicrocode.h create mode 100644 package/firmware/ixp4xx-microcode/src/LICENSE.IPL delete mode 100755 scripts/arm-magic.sh create mode 100644 target/linux/ixp4xx/Makefile create mode 100644 target/linux/ixp4xx/base-files/etc/board.d/02_network create mode 100644 target/linux/ixp4xx/base-files/etc/board.d/03_hdparm create mode 100644 target/linux/ixp4xx/base-files/lib/preinit/05_set_ether_mac_ixp4xx create mode 100644 target/linux/ixp4xx/config-6.1 create mode 100644 target/linux/ixp4xx/image/Makefile create mode 100644 target/linux/ixp4xx/patches-6.1/0001-mtd-cfi_cmdset_0001-Byte-swap-OTP-info.patch create mode 100644 target/linux/ixp4xx/patches-6.1/301-ARM-dts-ixp4xx-Boot-NSLU2-from-harddrive.patch -- 2.34.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/5] boot/apex: Restore the APEX boot loader
This is a partial revert of the deletion of the IXP4xx target: we restore the APEX boot loader so we can use it for the NSLU2 and related targets. The APEX upstream is as dead as it gets so I have applied OpenWrts old patches on top of the never released v1.6.10 version and forked it into an OpenWrt variant on GitHub. If the upstream comes back alive I will happily switch over to it. The file refers to the external GitHub, I suppose when integrating this patch the file should be copied to OpenWrts file repository and the file link changed. Signed-off-by: Linus Walleij --- package/boot/apex/Makefile | 61 ++ 1 file changed, 61 insertions(+) create mode 100644 package/boot/apex/Makefile diff --git a/package/boot/apex/Makefile b/package/boot/apex/Makefile new file mode 100644 index ..f4ce5811b024 --- /dev/null +++ b/package/boot/apex/Makefile @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: GPL-2.0-only +# +# Copyright (C) 2006-2023 OpenWrt.org + +include $(TOPDIR)/rules.mk +include $(INCLUDE_DIR)/kernel.mk + +PKG_NAME:=apex +# This version was created from the stalled and unreleased v1.6.10 +# with some patches on top. +PKG_VERSION:=1.6.10-openwrt +PKG_RELEASE:=1 + +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz +PKG_SOURCE_URL:=https://github.com/linusw/apex/releases/download/v1.6.10-openwrt/ +PKG_HASH:=034baa99574014f4bcb8d36baf830fa942bef816b22e228eabd7c5663612c640 +PKG_TARGETS:=bin + +include $(INCLUDE_DIR)/package.mk + +export GCC_HONOUR_COPTS=s + +define Package/apex + SECTION:=boot + CATEGORY:=Boot Loaders + DEPENDS:=@TARGET_ixp4xx + DEFAULT:=y + TITLE:=Boot loader for NSLU2, FSG3, NAS100D and others +endef + +define build_apex + $(MAKE) -C $(PKG_BUILD_DIR) \ + ARCH=arm \ + $(1)_config + $(MAKE) -C $(PKG_BUILD_DIR) \ + $(TARGET_CONFIGURE_OPTS) \ + KBUILD_HAVE_NLS=no \ + ARCH=arm \ + clean all + $(INSTALL_BIN) $(PKG_BUILD_DIR)/apex.bin $(PKG_BUILD_DIR)/out/apex-$(2).bin +endef + +define Build/Compile + $(INSTALL_DIR) $(PKG_BUILD_DIR)/out + $(call build_apex,openwrt-nslu2-armeb,nslu2-armeb) + $(call build_apex,openwrt-nslu2-16mb-armeb,nslu2-16mb-armeb) + $(call build_apex,openwrt-fsg3-armeb,fsg3-armeb) + $(call build_apex,openwrt-nas100d-armeb,nas100d-armeb) +endef + +define Package/apex/install + $(INSTALL_DIR) $(STAGING_DIR)/apex + $(CP) $(PKG_BUILD_DIR)/out/*.bin $(1)/ +endef + +define Build/InstallDev + $(INSTALL_DIR) $(STAGING_DIR_IMAGE) + $(CP) $(PKG_BUILD_DIR)/out/*.bin $(STAGING_DIR_IMAGE)/ +endef + +$(eval $(call BuildPackage,apex)) -- 2.34.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v1 3/5] ixp4xx: Add a ixp4xx hardware crypto kernel module
The IXP4xx crypto module must be loaded after the rootfs is up as it depends on loading some NPE microcode from the file system. Signed-off-by: Linus Walleij --- package/kernel/linux/modules/crypto.mk | 13 + target/linux/ixp4xx/Makefile | 1 + 2 files changed, 14 insertions(+) diff --git a/package/kernel/linux/modules/crypto.mk b/package/kernel/linux/modules/crypto.mk index 248b4d68f9e1..1c83f07330a5 100644 --- a/package/kernel/linux/modules/crypto.mk +++ b/package/kernel/linux/modules/crypto.mk @@ -399,6 +399,19 @@ endef $(eval $(call KernelPackage,crypto-hw-hifn-795x)) +define KernelPackage/crypto-hw-ixp4xx + TITLE:=Intel IXP4xx crypto accelerator + DEPENDS:=@TARGET_ixp4xx +kmod-random-core +kmod-crypto-manager +kmod-crypto-authenc +kmod-crypto-des + KCONFIG:= \ + CONFIG_CRYPTO_HW=y \ + CONFIG_CRYPTO_DEV_IXP4XX + FILES:=$(LINUX_DIR)/drivers/crypto/ixp4xx_crypto.ko + AUTOLOAD:=$(call AutoLoad,09,ixp4xx_crypto) + $(call AddDepends/crypto) +endef + +$(eval $(call KernelPackage,crypto-hw-ixp4xx)) + define KernelPackage/crypto-hw-padlock TITLE:=VIA PadLock ACE with AES/SHA hw crypto module diff --git a/target/linux/ixp4xx/Makefile b/target/linux/ixp4xx/Makefile index 546964a6a876..080576beb237 100644 --- a/target/linux/ixp4xx/Makefile +++ b/target/linux/ixp4xx/Makefile @@ -22,6 +22,7 @@ include $(INCLUDE_DIR)/target.mk DEFAULT_PACKAGES += ixp4xx-microcode \ fconfig \ + kmod-crypto-hw-ixp4xx \ kmod-usb-ledtrig-usbport \ kmod-leds-gpio -- 2.34.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v1 5/5] Delete arm-magic script
This script was used to modify the wrong machine type passed from the boot loader to the kernel. The device tree kernels does not use the machine type so this script is no longer needed. Signed-off-by: Linus Walleij --- scripts/arm-magic.sh | 42 -- 1 file changed, 42 deletions(-) delete mode 100755 scripts/arm-magic.sh diff --git a/scripts/arm-magic.sh b/scripts/arm-magic.sh deleted file mode 100755 index b4b0fa94f574.. --- a/scripts/arm-magic.sh +++ /dev/null @@ -1,42 +0,0 @@ -#!/bin/sh -# -# Empty/wrong machtype-workaround generator -# -# Copyright (C) 2006-2012 Imre Kaloz -# based on linux/arch/arm/boot/compressed/head-xscale.S -# -# This program is free software; you can redistribute it and/or modify -# it under the terms of the GNU General Public License as published by -# the Free Software Foundation; either version 2 of the License, or -# (at your option) any later version. -# -# This program is distributed in the hope that it will be useful, -# but WITHOUT ANY WARRANTY; without even the implied warranty of -# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -# GNU General Public License for more details. -# -# You should have received a copy of the GNU General Public License -# along with this program; if not, write to the Free Software -# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA - -# NOTE: for now it's for only IXP4xx in big endian mode - -# list of supported boards, in "boardname machtypeid" format -for board in "avila 526" "gateway7001 731" "nslu2 597" "nas100d 865" "wg302v1 889" "wg302v2 890" "pronghorn 928" "pronghornmetro 1040" "compex 1273" "wrt300nv2 1077" "loft 849" "dsmg600 964" "fsg3 1091" "ap1000 1543" "tw2662 1658" "tw5334 1664" "ixdpg425 604" "cambria 1468" "sidewinder 1041" "ap42x 4418" -do - set -- $board - hexid=$(printf %x\\n $2) - if [ "$2" -lt "256" ]; then -# we have a low machtypeid, we just need a "mov" (e3a) -printf "\xe3\xa0\x10\x$hexid" > $BIN_DIR/$IMG_PREFIX-$1-zImage - else -# we have a high machtypeid, we need a "mov" (e3a) and an "orr" (e38) -if [ "$2" -lt "4096" ]; then - printf "\xe3\xa0\x10\x$(echo $hexid|cut -b "2 3")\xe3\x81\x1c\x$(echo $hexid|cut -b 1)" > $BIN_DIR/$IMG_PREFIX-$1-zImage -else - printf "\xe3\xa0\x10\x$(echo $hexid|cut -b "3 4")\xe3\x81\x1c\x$(echo $hexid|cut -b "1 2")" > $BIN_DIR/$IMG_PREFIX-$1-zImage -fi - fi -# generate the image -cat $BIN_DIR/$IMG_PREFIX-zImage >> $BIN_DIR/$IMG_PREFIX-$1-zImage -done -- 2.34.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v1 4/5] ixp4xx: Add hdparm script
This script will make sure to spin down harddrives on IXP4xx NAS devices such as the NSLU2 and siblings after 1 minute of inactivity. Signed-off-by: Linus Walleij --- .../linux/ixp4xx/base-files/etc/board.d/03_hdparm | 14 ++ 1 file changed, 14 insertions(+) create mode 100644 target/linux/ixp4xx/base-files/etc/board.d/03_hdparm diff --git a/target/linux/ixp4xx/base-files/etc/board.d/03_hdparm b/target/linux/ixp4xx/base-files/etc/board.d/03_hdparm new file mode 100644 index ..27f2b760420e --- /dev/null +++ b/target/linux/ixp4xx/base-files/etc/board.d/03_hdparm @@ -0,0 +1,14 @@ +# SPDX-License-Identifier: GPL-2.0-only +# Spin down drives after one minute if inactive + +if [ ! -n "$(command -v hdparm)" ]; then + exit 0 +fi + +DISKS=$(find /dev/sd[a-z] 2>/dev/null) +for DISK in $DISKS +do + if [ -b $DISK ] ; then + hdparm -S 12 $DISK > /dev/null + fi +done -- 2.34.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH-22.03 01/10] ipq40xx: Support Chromium OS image-type creation
open...@aiyionpri.me [2023-04-07 15:23:39]:
Hi Jan,
> This series intends to support Google WiFi device 'Gale'.
IMHO it screams "a lot of regressions" in exchange for adding support for a
_single_ device into sixth stable release of 22.03, and considering that we've
23.05 already in the works, I'm sorry, but I'm going to reject this
contribution.
> I think I found all relevant commits and testing looked promising.
Looking at the ipq-wifi fallout, it looks like you've made some backports into
22.03 already?
> diff --git a/package/base-files/files/lib/upgrade/common.sh
> b/package/base-files/files/lib/upgrade/common.sh
> index 24ff77a8b3..5af061f6a4 100644
> --- a/package/base-files/files/lib/upgrade/common.sh
> +++ b/package/base-files/files/lib/upgrade/common.sh
> @@ -155,9 +155,11 @@ export_bootdevice() {
> fi
> done
> ;;
> + PARTUUID=----??0?/PARTNROFF=1 | \
> PARTUUID=----??02)
> uuid="${rootpart#PARTUUID=}"
> - uuid="${uuid%02}00"
> + uuid="${uuid%/PARTNROFF=1}"
> + uuid="${uuid%0?}00"
> for disk in $(find /dev -type b); do
> set -- $(dd if=$disk bs=1 skip=568 count=16
> 2>/dev/null | hexdump -v -e '8/1 "%02x "" "2/1 "%02x""-"6/1 "%02x"')
> if [ "$4$3$2$1-$6$5-$8$7-$9" = "$uuid" ]; then
sysupgrade path, very high regression potential, not a bugfix, so not going to
consider merging it.
> diff --git a/package/firmware/ipq-wifi/Makefile
> b/package/firmware/ipq-wifi/Makefile
> index be9b547cd0..74d789bdf6 100644
> --- a/package/firmware/ipq-wifi/Makefile
> +++ b/package/firmware/ipq-wifi/Makefile
> @@ -43,6 +43,7 @@ ALLWIFIBOARDS:= \
> glinet_gl-ap1300 \
> glinet_gl-b2200 \
> glinet_gl-s1300 \
> + google_wifi \
> linksys_ea8300 \
> linksys_mr8300-v0 \
> luma_wrtq-329acn \
This doesn't apply, looks like you're not even using 22.03 as a base for this
contribution?
> This effectively reverts upstream Linux commit 13e77747800e ("firmware:
> qcom: scm: Use atomic SCM for cold boot"), because Google WiFi boot
> firmwares don't support the atomic variant.
>
> This fixes SMP support for Google WiFi.
This is actually a fix, but needed just for the device being added, but still
might bring in some regression potential.
Cheers,
Petr
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: mwan3 memory usage
Thanks, Florian for the reply. In our opinion, having single process to cater to both IPv4 and IPv6 would help in memory reduction, the same way as handled in mwan3 (version 2.8.16). This would reduce the memory footprint from 4 processes to 2 processes. Do you recommend we making changes to mwan3rtmon script as per above suggestion in OpenWRT version 22.03 or do you see any design flaws because of which handling for IPv4/IPv6 is separated? Any insight as to why we have separate process for monitoring IPv4 and IPv6 would be helpful. Thanks, Ravi -Original Message- From: Florian Eckert Sent: Thursday, June 15, 2023 6:00 PM To: Ravi Paluri (QUIC) Cc: openwrt-devel@lists.openwrt.org Subject: Re: mwan3 memory usage WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hello, > Hi, > We have enabled mwan3 (version 2.11.4) functionality with OpenWRT > version 22.03 and we see that four mwan3rtmon processes are running, > two each for IPv4 and IPv6. We made the change with the following commit: https://github.com/openwrt/packages/commit/566293d228a48d21a04ecbc815a7ae97e26eb319 I'm not sure, but I think we had before also two mwan3rtmon process one for ipv4 and the other for ipv6 so there is no difference. But during the change we switched to procd to control the rtmon services. > Whereas with mwan3 (version 2.8.16) that came with OpenWRT version > 19.07, has only one process for mwan3rtmon running for both IPv4 and > IPv6. Sure? Or did only use the proto ipv4. > This has caused an increased memory usage on OpenWRT version 22.03 by > 3 times when compared to OpenWRT version 19.07. > This is a huge concern for us as we have limited memory on our router > product. Because of the fact, that mwan3 is written in shell I would not recommend to use this on small devices. > On debugging further, we see that mwan3rtmon script is invoking a > child process, the reason behind observing two processes per each IP > type. > Refer(line number 155) at > https://github.com/openwrt/packages/blob/master/net/mwan3/files/usr/sb > in/mwan3rtmon Can we know the reason behind creating child processes? Before that we polled for changes in the routing table. Now we use a event driven patter to update the routing table on routing changes. Because of this we need a subshell to get the events. > To reduce memory usage, if we disable creation of child process, what > functionality of mwan3 will be affected? This is not recommended. However, you can use the old mwan3rtmon for an older version to poll for changes. So you do not have a subshell for event handling. > Also, is it recommended to use mwan3 (version 2.8.16) with OpenWRT > version 22.03 as this has no child processes and only one mwan3rtmon > process for both IPv4 and IPv6? I can't say anything about that because I haven't tried it yet. --- Kind regards Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
