[PATCH 1/2] ipq806x: chromium: Disable kernel's CONFIG_QCOM_SPM
The qcom spm driver is currently broken for IPQ8064 OnHub devices on
kernel 6.1, such that it hangs the system when booting, much to the
consternation of users. This is especially bad as these devices don't
yet have a fully-supported release branch, and are still sometimes
landing on snapshot builds.
OnHub devices have their own kernel config, so it's not that wide of an
impact to disable this.
I haven't fully gotten to the bottom of this, but:
(a) The vendor kernel didn't have any SPM driver at all, and didn't
utilize cpuidle.
(b) The device tree has never included any (non-disabled) cpuidle
states, so even when this driver was present on 5.15 (last
known-working kernel), it didn't actually do anything -- it bailed
early, before ever doing any SPM initialization.
(c) Refactoring in Linux 5.16 [1] caused the SPM driver to be activated
unconditionally, including setting us into standby mode
(PM_SLEEP_MODE_STBY) by default.
Removing the one PM_SLEEP_MODE_STBY line from drivers/soc/qcom/spm.c
seems to fix the problem, but that isn't much different than simply
disabling the driver, so I go with that for now.
I also disable CONFIG_ARM_QCOM_SPM_CPUIDLE, becuase it 'select's
QCOM_SPM.
NB: it's possible there's some other deeper root cause involved in here.
For one, I notice that CPU hotplug (e.g., echo 0 >
/sys/devices/system/cpu/cpu1/online, echo 1 > ...) doesn't work right
either. Perhaps there's some mismatch on upstream Linux qcom-scm
behavior and the old boot firmware used for these systems? It wouldn't
be the first time, as we've had some similar incompatibilities on the
next generation of these devices, Google WiFi [2].
[1] Commit 60f3692b5f0b ("cpuidle: qcom_spm: Detach state machine from
main SPM handling")
[2] [RFC] qcom_scm: IPQ4019 firmware does not support atomic API?
https://lore.kernel.org/linux-arm-kernel/20200913201608.GA3162100@bDebian/
Signed-off-by: Brian Norris
---
target/linux/ipq806x/chromium/config-default | 2 ++
1 file changed, 2 insertions(+)
diff --git a/target/linux/ipq806x/chromium/config-default
b/target/linux/ipq806x/chromium/config-default
index d7db9f7db35a..927aba360f4a 100644
--- a/target/linux/ipq806x/chromium/config-default
+++ b/target/linux/ipq806x/chromium/config-default
@@ -1,7 +1,9 @@
+# CONFIG_ARM_QCOM_SPM_CPUIDLE is not set
CONFIG_BLK_DEV_SD=y
CONFIG_LEDS_LP5523=y
CONFIG_LEDS_LP55XX_COMMON=y
CONFIG_PHY_QCOM_IPQ806X_USB=y
+# CONFIG_QCOM_SPM is not set
CONFIG_SCSI=y
CONFIG_SCSI_COMMON=y
CONFIG_SG_POOL=y
--
2.40.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/2] ipq806x: onhub: Enable adm_dma node
One of our SPI devices references this node, but we never enabled it.
This clutters up probe deferral logs.
(NB: this SPI device still doesn't have a real driver, so it's just here
for documentation and/or tinkering.)
Signed-off-by: Brian Norris
---
.../ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-onhub.dtsi | 4
1 file changed, 4 insertions(+)
diff --git
a/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-onhub.dtsi
b/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-onhub.dtsi
index 549c46202619..536610595474 100644
--- a/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-onhub.dtsi
+++ b/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-onhub.dtsi
@@ -288,6 +288,10 @@
};
};
+&adm_dma {
+ status = "okay";
+};
+
&gmac0 {
status = "okay";
phy-mode = "rgmii";
--
2.40.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Hostapd won't build after rebase yesterday
> On Aug 11, 2023, at 10:02 AM, Felix Fietkau wrote: > > On 11.08.23 17:58, Philip Prindeville wrote: >> I'm seeing the following breakage in hostapd: >> ../src/ap/ucode.c: In function 'uc_hostapd_iface_start': >> ../src/ap/ucode.c:337:23: error: 'struct hostapd_config' has no member named >> 'he_oper_centr_freq_seg0_idx'; did you mean 'vht_oper_centr_freq_seg0_idx'? >> 337 | conf->he_oper_centr_freq_seg0_idx = intval; >> | ^~~ >> | vht_oper_centr_freq_seg0_idx >> ../src/ap/ucode.c:344:23: error: 'struct hostapd_config' has no member named >> 'he_oper_centr_freq_seg1_idx'; did you mean 'vht_oper_centr_freq_seg1_idx'? >> 344 | conf->he_oper_centr_freq_seg1_idx = intval; >> | ^~~ >> | vht_oper_centr_freq_seg1_idx >> ../src/ap/ucode.c:352:23: error: 'struct hostapd_config' has no member named >> 'he_oper_chwidth'; did you mean 'vht_oper_chwidth'? >> 352 | conf->he_oper_chwidth = intval; >> | ^~~ >> | vht_oper_chwidth >> After rebasing yesterday. Anyone else seeing something similar? >> What's odd is that the package version didn't change in the rebasing. >> Is some code not properly gated by CONFIG_IEEE80211AX #ifdef's? > > Should already be fixed in 9c2c6d19f35708bb97462bb8902c54d2ec23001d > > Sorry for the noise, > > - Felix I fetched and that fixed it, thanks! I also got into my .config and enabled CONFIG_DRIVER_11AX_SUPPORT=y ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Reserving USERID
> On Aug 11, 2023, at 10:11 AM, Paul Spooren wrote: > > Hi, > >> Is explicit better or not? And if it is better, how do I go about reserving >> values that won't get stepped on? Who is our Numbers Czar, who is our IANA? > > I always used Gentoos numbers[1] whenever I added something. Since Clixon is > not part of that list, maybe use something that’s not yet in the list? >> >> And if the packaging requires that files be owned by a certain user, how is >> that handled in the Makefiles? > > Look for PKG_FILE_MODES in the repositories, i.e. busybox[2]. > > :Paul Awesome, thanks! On an unrelated note, where is a discussion of what OpenWRT represents configuration state as? Do we use JSON internally? How do I dump the "raw" state? -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Reserving USERID
Hi, > Is explicit better or not? And if it is better, how do I go about reserving > values that won't get stepped on? Who is our Numbers Czar, who is our IANA? I always used Gentoos numbers[1] whenever I added something. Since Clixon is not part of that list, maybe use something that’s not yet in the list? > > And if the packaging requires that files be owned by a certain user, how is > that handled in the Makefiles? Look for PKG_FILE_MODES in the repositories, i.e. busybox[2]. :paul [1]: https://wiki.gentoo.org/wiki/UID_GID_Assignment_Table [2]: https://github.com/openwrt/openwrt/blob/c5988f4c01ff2e74a9588507b621d0ea5986cabe/package/utils/busybox/Makefile#L30 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Hostapd won't build after rebase yesterday
On 11.08.23 17:58, Philip Prindeville wrote: I'm seeing the following breakage in hostapd: ../src/ap/ucode.c: In function 'uc_hostapd_iface_start': ../src/ap/ucode.c:337:23: error: 'struct hostapd_config' has no member named 'he_oper_centr_freq_seg0_idx'; did you mean 'vht_oper_centr_freq_seg0_idx'? 337 | conf->he_oper_centr_freq_seg0_idx = intval; | ^~~ | vht_oper_centr_freq_seg0_idx ../src/ap/ucode.c:344:23: error: 'struct hostapd_config' has no member named 'he_oper_centr_freq_seg1_idx'; did you mean 'vht_oper_centr_freq_seg1_idx'? 344 | conf->he_oper_centr_freq_seg1_idx = intval; | ^~~ | vht_oper_centr_freq_seg1_idx ../src/ap/ucode.c:352:23: error: 'struct hostapd_config' has no member named 'he_oper_chwidth'; did you mean 'vht_oper_chwidth'? 352 | conf->he_oper_chwidth = intval; | ^~~ | vht_oper_chwidth After rebasing yesterday. Anyone else seeing something similar? What's odd is that the package version didn't change in the rebasing. Is some code not properly gated by CONFIG_IEEE80211AX #ifdef's? Should already be fixed in 9c2c6d19f35708bb97462bb8902c54d2ec23001d Sorry for the noise, - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Hostapd won't build after rebase yesterday
I'm seeing the following breakage in hostapd: ../src/ap/ucode.c: In function 'uc_hostapd_iface_start': ../src/ap/ucode.c:337:23: error: 'struct hostapd_config' has no member named 'he_oper_centr_freq_seg0_idx'; did you mean 'vht_oper_centr_freq_seg0_idx'? 337 | conf->he_oper_centr_freq_seg0_idx = intval; | ^~~ | vht_oper_centr_freq_seg0_idx ../src/ap/ucode.c:344:23: error: 'struct hostapd_config' has no member named 'he_oper_centr_freq_seg1_idx'; did you mean 'vht_oper_centr_freq_seg1_idx'? 344 | conf->he_oper_centr_freq_seg1_idx = intval; | ^~~ | vht_oper_centr_freq_seg1_idx ../src/ap/ucode.c:352:23: error: 'struct hostapd_config' has no member named 'he_oper_chwidth'; did you mean 'vht_oper_chwidth'? 352 | conf->he_oper_chwidth = intval; | ^~~ | vht_oper_chwidth After rebasing yesterday. Anyone else seeing something similar? What's odd is that the package version didn't change in the rebasing. Is some code not properly gated by CONFIG_IEEE80211AX #ifdef's? -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v1 2/5] ixp4xx: Resurrect IXP4xx support using device tree
On 6/19/23 13:31, Linus Walleij wrote: 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. +# Please add a SPDX header and remove the OpenWrt copyright. + +include $(TOPDIR)/rules.mk + +PKG_NAME:=ixp4xx-microcode +PKG_VERSION:=2.4 > +PKG_RELEASE:=2 Start with pkg release 1 + +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/ Are all these FW files always needed, or do you need them depending on the use case or device? If they are not always needed maybe add them into seperate packages. + $(INSTALL_DATA) $(PKG_BUILD_DIR)/LICENSE.IPL $(1)/usr/share/doc/ +endef + +$(eval $(call BuildPackage,ixp4xx-microcode)) diff --git a/target/linux/ixp4xx/Makefile b/target/linux/ixp4xx/Makefile new file mode 100644 index ..546964a6a876 --- /dev/null +++ b/target/linux/ixp4xx/Makefile @@ -0,0 +1,28 @@ +# SPDX-License-Identifier: GPL-2.0-only +# +# Copyright (C) 2006-2023 OpenWrt.org +
Re: [PATCH 1/5] boot/apex: Restore the APEX boot loader
On 6/19/23 13:31, Linus Walleij wrote: 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 I do not like it when a package is default y. This will always activate it by default. Maybe should also also mark this none shared. + 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 This will build a OpenWrt package with these files. Do you really need these files in the root file system? I do not know how the boot process works, this just looks strange to me. + +define Build/InstallDev + $(INSTALL_DIR) $(STAGING_DIR_IMAGE) + $(CP) $(PKG_BUILD_DIR)/out/*.bin $(STAGING_DIR_IMAGE)/ +endef + +$(eval $(call BuildPackage,apex)) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
