Re: OpenWrt add dependency to swig for U-Boot builds
On 31.01.2021 20:43, Hauke Mehrtens wrote: The U-Boot build for more and more SoCs is using binman by default to combine the images (SPL, U-Boot, ...). Binman is build from the U-Boot project and it needs swig to build. We have multiple patches in OpenWrt to remove this dependency from U-Boot, but it costs more and more time to revert back to the old code. We have them in sunxi and rockchip U-Boot, the Mediatek U-Boot build failed some time ago because of missing swig in build bots. I was just trying to update sunxi U-Boot to 2021.01 and the binman usage changed again, so it needs more adaptations. Building swig in OpenWrt tools will not be easy. We needs swig with python bindings and this version needs the python development headers to build. I would like to add swig as an official dependency to OpenWrt, we could make it depend on the target if this is possible. Does anyone have an opinion on this topic? Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel Hi, Please do so, it's a small inconvenience oppose to always patch the u-boot sources Regards, Lucian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ramips: mt7621: HW-NAT typo fix
This fixes Hardware Offload on MT7621
Signed-off-by: Lucian Cristian
diff --git
a/target/linux/generic/backport-5.10/610-v5.13-33-net-ethernet-mtk_eth_soc-add-flow-offloading-support.patch
b/target/linux/generic/backport-5.10/610-v5.13-33-net-ethernet-mtk_eth_soc-add-flow-offloading-support.patch
index 82e3ddec3f..660ac77dce 100644
---
a/target/linux/generic/backport-5.10/610-v5.13-33-net-ethernet-mtk_eth_soc-add-flow-offloading-support.patch
+++
b/target/linux/generic/backport-5.10/610-v5.13-33-net-ethernet-mtk_eth_soc-add-flow-offloading-support.patch
@@ -127,7 +127,7 @@ Signed-off-by: Pablo Neira Ayuso
+
+static const struct rhashtable_params mtk_flow_ht_params = {
+ .head_offset = offsetof(struct mtk_flow_entry, node),
-+ .head_offset = offsetof(struct mtk_flow_entry, cookie),
++ .key_offset = offsetof(struct mtk_flow_entry, cookie),
+ .key_len = sizeof(unsigned long),
+ .automatic_shrinking = true,
+};
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Enable ATIIXP on x64
Also support ATI PATA on x64 target Signed-off-by: Lucian Cristian --- diff --git a/target/linux/x86/64/config-default b/target/linux/x86/64/config-default index a5947a2..b4c8b98 100644 --- a/target/linux/x86/64/config-default +++ b/target/linux/x86/64/config-default @@ -39,7 +39,8 @@ CONFIG_ARCH_SUPPORTS_INT128=y CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y -# CONFIG_ATA_SFF is not set +CONFIG_ATA_SFF=y +CONFIG_PATA_ATIIXP=y CONFIG_AUDIT_ARCH=y CONFIG_BLK_DEV_INTEGRITY=y CONFIG_CALGARY_IOMMU=y ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Enable ATIIXP on x64
On 16.01.2016 04:31, Felix Kaechele wrote: On 15/01/16 03:25, Lucian Cristian wrote: Also support ATI PATA on x64 target Signed-off-by: Lucian Cristian Has already been NACKd before: https://lists.openwrt.org/pipermail/openwrt-devel/2015-September/036155.html Not entirely sure the situation has changed since then. Regards, Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel it's just that default x86 will not use all 2gb ram Regards ! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] x64 - crypto-rng drbg.ko missing
crypto-rng, enable prerequisite for drbg.ko, fixes #21596 Signed-off-by: Lucian Cristian --- diff --git a/package/kernel/linux/modules/crypto.mk b/package/kernel/linux/modules/crypto.mk index 604be9f..d84c802 100644 --- a/package/kernel/linux/modules/crypto.mk +++ b/package/kernel/linux/modules/crypto.mk @@ -102,6 +102,7 @@ define KernelPackage/crypto-rng TITLE:=CryptoAPI random number generation DEPENDS:=+kmod-crypto-hash KCONFIG:= \ + CONFIG_CRYPTO_DRBG_MENU \ CONFIG_CRYPTO_DRBG \ CONFIG_CRYPTO_JITTERENTROPY \ CONFIG_CRYPTO_RNG2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] netifd: wireless: Add support for GCMP cipher
On 14.03.2019 13:30, txt.file wrote:
Which other drivers implement this cipher? Is this cipher in the IEEE 802.11
documents standardized?
On March 14, 2019 10:03:16 AM UTC, Robert Marko wrote:
This patch will add support for using GCMP as cipher suite.
This is not a strong cipher but is only one supported by
wil6210 driver in order to have encrypted traffic.
Signed-off-by: Robert Marko
---
scripts/netifd-wireless.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts/netifd-wireless.sh b/scripts/netifd-wireless.sh
index 424b3ad..6bc48c6 100644
--- a/scripts/netifd-wireless.sh
+++ b/scripts/netifd-wireless.sh
@@ -200,6 +200,7 @@ wireless_vif_parse_encryption() {
*tkip+aes|*tkip+ccmp|*aes+tkip|*ccmp+tkip) wpa_cipher="CCMP
TKIP";;
*aes|*ccmp) wpa_cipher="CCMP";;
*tkip) wpa_cipher="TKIP";;
+ *gcmp) wpa_cipher="GCMP";;
esac
# 802.11n requires CCMP for WPA
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
https://www.wi-fi.org/discover-wi-fi/security
in wpa3
* *Authenticated encryption**:* 256-bit Galois/Counter Mode Protocol
(GCMP-256)
Regards
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Meson/Ninja build system
On 16.03.2019 19:52, W. Michael Petullo wrote: A number of upstream projects are beginning to use the Meson/Ninja build system. OpenWrt's sound/mpc and libs/libmpdclient kludge around this, and I would like to update the glib2 package. The latest version of glib2 uses Meson/Ninja. Is there any plan to build the Meson/Ninja environment into the OpenWrt build system? fyi https://github.com/openwrt/openwrt/pull/1912 Regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] x86: disable kmod-drm-radeon and kmod-drm-amdgpu for geode
On 08.04.2019 20:19, Tomasz Maciej Nowak wrote: Hi Petr, Alberto, W dniu 08.04.2019 o 14:34, Alberto Bursi pisze: On 08/04/19 11:42, Petr Štetiar wrote: Tomasz Maciej Nowak [2019-04-07 18:35:01]: Hi, thanks for trying to unbreak currently failing Geode builds. Building images for geode has been failing because of missing dependencies: backlight.ko drm_kms_helper.ko fb.ko ttm.ko Being geode a speciffic hardware, where drm-radeon and drm-amdgpu modules will probably never be used, disable both. Fixing the kernel module dependencies is PITA, I know, but this simply doesn't look like a proper fix to me, rather just like a workaround. Yes, adding those modules to dependencies would solve the issue, but for how long? If AMD people would decide to add another module to dependencies, we would need to fix it again and fix something not one would ever use on this target, only for the sake of it? -- ynezz It is indeed a workaround, but is it worth to spend time troubleshooting something that is never going to be used? I don't see why these modules were built at all. It's pretty hard or even impossible to run any addon graphics card on a Geode system. At most they have PCI slots, many (the networking alix boards from PCEngines) only have mini PCI slots. drm-amdgpu will 100% never be used as it runs modern PCIe cards. I don't find any good reason to mount an ancient AMD card over a PCI slot (or mini pci slot + adapter) as they have their own integrated graphics with a VGA port already. -Alberto Thanks, this is more or less what I had in mind deciding how to approach this, and form this POV calling it workaround is debatable. I'll leave patch in this form, if anyone wants to take different approach, please do. Regards Because I crashed that, if your approach is not accepted I'll add the module dependencies, I didn't put them in the generic config because I also thought it will only be used on modern hardware Regards Lucian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] x86: disable kmod-drm-radeon and kmod-drm-amdgpu for geode
On 09.04.2019 01:28, Tomasz Maciej Nowak wrote: W dniu 08.04.2019 o 23:56, Lucian Cristian pisze: On 08.04.2019 20:19, Tomasz Maciej Nowak wrote: Hi Petr, Alberto, W dniu 08.04.2019 o 14:34, Alberto Bursi pisze: On 08/04/19 11:42, Petr Štetiar wrote: Tomasz Maciej Nowak [2019-04-07 18:35:01]: Hi, thanks for trying to unbreak currently failing Geode builds. Building images for geode has been failing because of missing dependencies: backlight.ko drm_kms_helper.ko fb.ko ttm.ko Being geode a speciffic hardware, where drm-radeon and drm-amdgpu modules will probably never be used, disable both. Fixing the kernel module dependencies is PITA, I know, but this simply doesn't look like a proper fix to me, rather just like a workaround. Yes, adding those modules to dependencies would solve the issue, but for how long? If AMD people would decide to add another module to dependencies, we would need to fix it again and fix something not one would ever use on this target, only for the sake of it? Sorry, I may have sounded harsh and triggered here, that was not my intention. I'm fine with either, but please do consider that with other solution that may not be the final one for the future. -- ynezz It is indeed a workaround, but is it worth to spend time troubleshooting something that is never going to be used? I don't see why these modules were built at all. It's pretty hard or even impossible to run any addon graphics card on a Geode system. At most they have PCI slots, many (the networking alix boards from PCEngines) only have mini PCI slots. drm-amdgpu will 100% never be used as it runs modern PCIe cards. I don't find any good reason to mount an ancient AMD card over a PCI slot (or mini pci slot + adapter) as they have their own integrated graphics with a VGA port already. -Alberto Thanks, this is more or less what I had in mind deciding how to approach this, and form this POV calling it workaround is debatable. I'll leave patch in this form, if anyone wants to take different approach, please do. Regards Because I crashed that, if your approach is not accepted I'll add the module dependencies, I didn't put them in the generic config because I also thought it will only be used on modern hardware Thanks, please do. Regards Lucian Regards FYI https://github.com/openwrt/openwrt/pull/1981 Regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4] add μrngd: true RNG based on timing jitter
On 28.05.2019 12:37, Petr Štetiar wrote: Rosen Penev [2019-05-27 19:19:53]: Hi, Tested this on both mt7621 and Turris Omnia. Works pretty well. Init gets done fast. thanks a lot for testing, can you please reply with your Tested-by next time so the patchwork could add this tag automatically to this patch? The Turris people might want something like this or they need to fix haveged to run earlier. I've been recommended haveged many times (by someone from nic.cz as well), so my initial idea was to simply give it a go and create uhaveged, but I quickly came to the conclusion, that it won't work for OpenWrt for many reasons, which I've already forget, but I think it wasn't truly multiplatform solution due to some compiler/assembly magic. Then I've simply found out, that haveged is no longer considered good enough[1] by the security community: Also the use of `haveged` is recommended, which is a bad idea as this daemon can create blocking situations during key generation effectively creating a deadlock and thus security problems. haveged's design is from 2002, it has never been audited, there're only papers by the original authors available. Even Andre Seznec, one of the main HAVEGE authors stated following[2]: He also pointed out a security warning: with some VMs, the hardware cycles counter is emulated and deterministic, and thus predictible[3]. He therefore does not recommend using HAVEGE on those systems. so I started looking at other options and luckily enough, I've found out about this KISS jitter RNG. 1. https://lists.cert.at/pipermail/ach/2017-May/002251.html 2. https://github.com/BetterCrypto/Applied-Crypto-Hardening/commit/cf7cef7a870c1b77089b1bd6209ded6525b5a4e0#commitcomment-23006392 3. https://tls.mbed.org/tech-updates/security-advisories/polarssl-security-advisory-2011-02 -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel works good on Atom 330 first boot dmesg | grep random before [ 29.043097] random: fast init done [ 76.467115] random: crng init done after [ 0.00] random: get_random_bytes called from start_kernel+0x6d/0x3df with crng_init=0 [ 5.899674] random: jshn: uninitialized urandom read (4 bytes read) [ 5.933012] random: jshn: uninitialized urandom read (4 bytes read) [ 5.957578] random: jshn: uninitialized urandom read (4 bytes read) [ 6.969902] urandom_read: 4 callbacks suppressed [ 6.969907] random: jshn: uninitialized urandom read (4 bytes read) [ 10.043998] random: jshn: uninitialized urandom read (4 bytes read) [ 10.550301] random: mkfs.f2fs: uninitialized urandom read (16 bytes read) [ 11.420925] urandom-seed: Seed file not found (/etc/urandom.seed) [ 13.321222] random: crng init done Regards Tested-by Lucian Cristian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] wireless-regdb: fix build when python2 from package feeds exists
On 31.07.2019 23:31, Petr Štetiar wrote: wireless-regdb fails to build if there is python2 installed from package feeds, as staging_dir/hostpkg/bin/python is python2 and staging_dir/hostpkg/bin takes precedence over staging_dir/host/bin (proper place with python -> python3 symlink) which leads to the build failure of wireless-regdb, so this patch makes it explicit which python should be used. Reported-by: Hauke Mehrtens Tested-by: Kevin Darbyshire-Bryant Signed-off-by: Petr Štetiar --- package/firmware/wireless-regdb/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/firmware/wireless-regdb/Makefile b/package/firmware/wireless-regdb/Makefile index 88a8d0bd9c3b..26f470af44c4 100644 --- a/package/firmware/wireless-regdb/Makefile +++ b/package/firmware/wireless-regdb/Makefile @@ -20,7 +20,7 @@ define Package/wireless-regdb endef define Build/Compile - $(PYTHON) $(PKG_BUILD_DIR)/db2fw.py $(PKG_BUILD_DIR)/regulatory.db $(PKG_BUILD_DIR)/db.txt + $(STAGING_DIR_HOST)/bin/$(PYTHON) $(PKG_BUILD_DIR)/db2fw.py $(PKG_BUILD_DIR)/regulatory.db $(PKG_BUILD_DIR)/db.txt endef define Package/wireless-regdb/install ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel tested on debian 8, mvebu Tested-by: Lucian Cristian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 18.06 bug: Flow Offload Active Connections
On 29.05.2018 19:55, Jaap Buurman wrote: Dear all, Whenever flow offload is enabled (either software or hardware) I can see many many active connections on the Luci overview page. It can go up to thousands of active connections. Looking in the "connections" part of the "realtime graphs" in Luci shows me that even connections with devices that turned off hours ago are still active. So for some reasons old connections are not leaving the conntrack table. Turning off flow offload fixes these issues right away. I am currently running the latest 18.06 snapshot on a dir-860l. Hopefully this is useful information for debugging. Yours sincerely, Jaap Buurman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel I also saw this yesterday but on mwan3 scenario, people where complaining and didn't understand why this happened but I fixed it by rising the conntrack table, by a *lot and I mean a lot!* Regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] wireguard: bump to 0.0.20181006
On 08.10.2018 11:56, Andre Heider wrote: Hi Jason, On 06/10/2018 05:09, Jason A. Donenfeld wrote: diff --git a/package/network/services/wireguard/Makefile b/package/network/services/wireguard/Makefile index 29c7447..3544e34 100644 --- a/package/network/services/wireguard/Makefile +++ b/package/network/services/wireguard/Makefile @@ -11,12 +11,12 @@ include $(INCLUDE_DIR)/kernel.mk PKG_NAME:=wireguard -PKG_VERSION:=0.0.20180925 +PKG_VERSION:=0.0.20181006 with this version I get a build error on arm: CC [M] /home/andre/src/openwrt/build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/linux-sunxi_cortexa7/WireGuard-0.0.20181006/src/main.o In file included from /home/andre/src/openwrt/build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/linux-sunxi_cortexa7/WireGuard-0.0.20181006/src/crypto/include/zinc/chacha20poly1305.h:9:0, from /home/andre/src/openwrt/build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/linux-sunxi_cortexa7/WireGuard-0.0.20181006/src/messages.h:10, from /home/andre/src/openwrt/build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/linux-sunxi_cortexa7/WireGuard-0.0.20181006/src/noise.h:8, from /home/andre/src/openwrt/build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/linux-sunxi_cortexa7/WireGuard-0.0.20181006/src/device.h:9, from /home/andre/src/openwrt/build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/linux-sunxi_cortexa7/WireGuard-0.0.20181006/src/main.c:7: /home/andre/src/openwrt/build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/linux-sunxi_cortexa7/WireGuard-0.0.20181006/src/compat/simd/include/linux/simd.h: In function 'simd_get': /home/andre/src/openwrt/build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/linux-sunxi_cortexa7/WireGuard-0.0.20181006/src/compat/simd/include/linux/simd.h:29:48: error: implicit declaration of function 'may_use_simd'; did you mean 'cap_settime'? [-Werror=implicit-function-declaration] *ctx = !IS_ENABLED(CONFIG_PREEMPT_RT_BASE) && may_use_simd() ? HAVE_FULL_SIMD : HAVE_NO_SIMD; ^~~~ cap_settime Thanks, Andre ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel there's a new one 07, it's about this problem Regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v4 0/6] intel-microcode: load as early as possible
On 20.11.2018 18:20, Tomasz Maciej Nowak wrote: This small series addresses current problem with late loading of Intel microcode in OpenWrt. Following the commit messages [1] and later discussion, late loading off the microcode can be ineffective for some processors [2] and for others disabled [3]. Also it is discouraged for any processor starting from Haswell and Silvermont. Therefore this series converts the Intel microcode bundle to an initial ram disk which is loaded with grub, so kernel has access to it as early as possible. Previous patch series: https://patchwork.ozlabs.org/project/lede/list/?series=39372 1. https://lore.kernel.org/patchwork/cover/348236 2. https://lore.kernel.org/patchwork/cover/348236/#508603 3. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=723f2828a98c8ca19842042f418fb30dd8cfc0f7 Changes in v4: - copy also hidden files: x86: add packages files to image bootfs - no changes: 1) include/rootfs.mk: remove boot directory 2) x86: mount writable bootfs 3) intel-microcode: remove dependency on iucode-tool 4) x86: add intel microcode entries to grub config 5) intel-microcode: create early load microcode image Change suggested by Philip Prindeville. Changes in v3: - replaced "include/rootfs.mk: move boot directory for later use" with "include/rootfs.mk: remove boot directory"; the final rootfs is always created after targets rootfs, so there's no need to save files for later use, also there was side effect to this approach, it kept the old files if packages version changed and buildroot wasn't cleaned beforehand - reflect the changes in "include/rootfs.mk: remove boot directory": x86: add packages files to image bootfs - expand commit message, narrow down the test in grub config: x86: add intel microcode entries to grub config - no changes: 1) x86: mount writable bootfs 2) intel-microcode: remove dependency on iucode-tool 3) intel-microcode: create early load microcode image Changes in v2: - three new commits allowing buildsystem to properly handle packages installing files to /boot directory, mainly for x86 target: 1) include/rootfs.mk: move boot directory for later use 2) x86: mount writable bootfs 3) x86: add packages files to image bootfs - uncomplicate test for AMD processors in: x86: add intel microcode entries to grub config - remove package specific hook in x86 image Makefile, remove postinst/prerm scripts and install microcode directly to /boot: intel-microcode: create early load microcode image - no changes: intel-microcode: remove dependency on iucode-tool All changes in v2 suggested by Matthias Schiffer and Philip Prindeville. Tomasz Maciej Nowak (6): include/rootfs.mk: remove boot directory x86: mount writable bootfs x86: add packages files to image bootfs intel-microcode: remove dependency on iucode-tool x86: add intel microcode entries to grub config intel-microcode: create early load microcode image include/rootfs.mk| 1 + package/firmware/intel-microcode/Makefile| 16 +--- .../x86/base-files/lib/preinit/02_load_x86_ucode | 6 -- .../x86/base-files/lib/preinit/79_move_config| 12 target/linux/x86/image/Makefile | 6 -- target/linux/x86/image/grub-iso.cfg | 3 +++ target/linux/x86/image/grub.cfg | 3 +++ 7 files changed, 28 insertions(+), 19 deletions(-) this series I think are braking the boot on Via CPU's grub complains with error: can't find command '['. error: file '/boot/amd-ucode.img' not found. error: can't find command '['. error: file '/boot/intel-ucode.img' not found. Press any key to continue... And you have to press any key.. Regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v4 0/6] intel-microcode: load as early as possible
On 26.11.2018 23:11, Tomasz Maciej Nowak wrote: W dniu 26.11.2018 o 21:44, Lucian Cristian pisze: On 20.11.2018 18:20, Tomasz Maciej Nowak wrote: This small series addresses current problem with late loading of Intel microcode in OpenWrt. Following the commit messages [1] and later discussion, late loading off the microcode can be ineffective for some processors [2] and for others disabled [3]. Also it is discouraged for any processor starting from Haswell and Silvermont. Therefore this series converts the Intel microcode bundle to an initial ram disk which is loaded with grub, so kernel has access to it as early as possible. Previous patch series: https://patchwork.ozlabs.org/project/lede/list/?series=39372 1. https://lore.kernel.org/patchwork/cover/348236 2. https://lore.kernel.org/patchwork/cover/348236/#508603 3. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=723f2828a98c8ca19842042f418fb30dd8cfc0f7 Changes in v4: - copy also hidden files: x86: add packages files to image bootfs - no changes: 1) include/rootfs.mk: remove boot directory 2) x86: mount writable bootfs 3) intel-microcode: remove dependency on iucode-tool 4) x86: add intel microcode entries to grub config 5) intel-microcode: create early load microcode image Change suggested by Philip Prindeville. Changes in v3: - replaced "include/rootfs.mk: move boot directory for later use" with "include/rootfs.mk: remove boot directory"; the final rootfs is always created after targets rootfs, so there's no need to save files for later use, also there was side effect to this approach, it kept the old files if packages version changed and buildroot wasn't cleaned beforehand - reflect the changes in "include/rootfs.mk: remove boot directory": x86: add packages files to image bootfs - expand commit message, narrow down the test in grub config: x86: add intel microcode entries to grub config - no changes: 1) x86: mount writable bootfs 2) intel-microcode: remove dependency on iucode-tool 3) intel-microcode: create early load microcode image Changes in v2: - three new commits allowing buildsystem to properly handle packages installing files to /boot directory, mainly for x86 target: 1) include/rootfs.mk: move boot directory for later use 2) x86: mount writable bootfs 3) x86: add packages files to image bootfs - uncomplicate test for AMD processors in: x86: add intel microcode entries to grub config - remove package specific hook in x86 image Makefile, remove postinst/prerm scripts and install microcode directly to /boot: intel-microcode: create early load microcode image - no changes: intel-microcode: remove dependency on iucode-tool All changes in v2 suggested by Matthias Schiffer and Philip Prindeville. Tomasz Maciej Nowak (6): include/rootfs.mk: remove boot directory x86: mount writable bootfs x86: add packages files to image bootfs intel-microcode: remove dependency on iucode-tool x86: add intel microcode entries to grub config intel-microcode: create early load microcode image include/rootfs.mk | 1 + package/firmware/intel-microcode/Makefile | 16 +--- .../x86/base-files/lib/preinit/02_load_x86_ucode | 6 -- .../x86/base-files/lib/preinit/79_move_config | 12 target/linux/x86/image/Makefile | 6 -- target/linux/x86/image/grub-iso.cfg | 3 +++ target/linux/x86/image/grub.cfg | 3 +++ 7 files changed, 28 insertions(+), 19 deletions(-) this series I think are braking the boot on Via CPU's grub complains with error: can't find command '['. error: file '/boot/amd-ucode.img' not found. error: can't find command '['. error: file '/boot/intel-ucode.img' not found. Press any key to continue... And you have to press any key.. Damn, one case I didn't test. To be sure is this after sysupgrade? If yes please revert these commits: 546fced2a23557e95dd34246744c3aa6cad92fe6 x86: add intel microcode entries to grub config 022ffb56b2491fd7d8051ac6e6c7622ecc313d8f intel-microcode: create early load microcode image a822283c7e56bb3b409712e0eb9af5a91aac247d x86: add amd microcode entries to grub config 975019b3a755ec3b91864b60b45e5ee104075096 amd64-microcode: create early load microcode image I'll try to come up with better transition. Regards I think that you must enforce the microcode selection but for me this error persists if I select the cpu microcode (any, tested on hyper-v intel cpu) error: can't find command '['. error: can't find command '['. Press any key to continue... Regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v4 0/6] intel-microcode: load as early as possible
On 26.11.2018 23:58, Tomasz Maciej Nowak wrote: W dniu 26.11.2018 o 22:47, Lucian Cristian pisze: On 26.11.2018 23:11, Tomasz Maciej Nowak wrote: W dniu 26.11.2018 o 21:44, Lucian Cristian pisze: On 20.11.2018 18:20, Tomasz Maciej Nowak wrote: This small series addresses current problem with late loading of Intel microcode in OpenWrt. Following the commit messages [1] and later discussion, late loading off the microcode can be ineffective for some processors [2] and for others disabled [3]. Also it is discouraged for any processor starting from Haswell and Silvermont. Therefore this series converts the Intel microcode bundle to an initial ram disk which is loaded with grub, so kernel has access to it as early as possible. Previous patch series: https://patchwork.ozlabs.org/project/lede/list/?series=39372 1. https://lore.kernel.org/patchwork/cover/348236 2. https://lore.kernel.org/patchwork/cover/348236/#508603 3. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=723f2828a98c8ca19842042f418fb30dd8cfc0f7 [...] No, Your grub doesn't understand *if* command because it's old an doesn't have "test" module enabled. It's left there because sysupgrade doesn't upgrade grub, it updates only boot and root partitions. If You'll write the created image not by sysupgrade but by dd'ing to boot medium, It'll start properly without interruptions. BTW thank You for the report. error: can't find command '['. error: can't find command '['. Press any key to continue... Regards Can I repair this somehow without writing the full image ? only by reversing the commits ? Regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v4 0/6] intel-microcode: load as early as possible
On 27.11.2018 19:04, John Crispin wrote: On 27/11/2018 16:11, Tomasz Maciej Nowak wrote: W dniu 27.11.2018 o 14:47, Lucian Cristian pisze: On 26.11.2018 23:58, Tomasz Maciej Nowak wrote: W dniu 26.11.2018 o 22:47, Lucian Cristian pisze: On 26.11.2018 23:11, Tomasz Maciej Nowak wrote: W dniu 26.11.2018 o 21:44, Lucian Cristian pisze: On 20.11.2018 18:20, Tomasz Maciej Nowak wrote: This small series addresses current problem with late loading of Intel microcode in OpenWrt. Following the commit messages [1] and later discussion, late loading off the microcode can be ineffective for some processors [2] and for others disabled [3]. Also it is discouraged for any processor starting from Haswell and Silvermont. Therefore this series converts the Intel microcode bundle to an initial ram disk which is loaded with grub, so kernel has access to it as early as possible. Previous patch series: https://patchwork.ozlabs.org/project/lede/list/?series=39372 1. https://lore.kernel.org/patchwork/cover/348236 2. https://lore.kernel.org/patchwork/cover/348236/#508603 3. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=723f2828a98c8ca19842042f418fb30dd8cfc0f7 [...] No, Your grub doesn't understand *if* command because it's old an doesn't have "test" module enabled. It's left there because sysupgrade doesn't upgrade grub, it updates only boot and root partitions. If You'll write the created image not by sysupgrade but by dd'ing to boot medium, It'll start properly without interruptions. BTW thank You for the report. error: can't find command '['. error: can't find command '['. Press any key to continue... Regards Can I repair this somehow without writing the full image ? only by reversing the commits ? No, not at the moment. I'm trying to figure out best way to update grub on sysupgrade, until then reverting the mentioned commits will bring back old behavior, and no manual intervention on boot will be necessary. shall we revert the series ? John Regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel sysupgrade will break things bad if you can't press any key on reboot, so it's better to revert for the moment Regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v4 0/6] intel-microcode: load as early as possible
On 27.11.2018 19:59, John Crispin wrote: On 27/11/2018 18:15, Tomasz Maciej Nowak wrote: W dniu 27.11.2018 o 18:04, John Crispin pisze: On 27/11/2018 16:11, Tomasz Maciej Nowak wrote: W dniu 27.11.2018 o 14:47, Lucian Cristian pisze: On 26.11.2018 23:58, Tomasz Maciej Nowak wrote: W dniu 26.11.2018 o 22:47, Lucian Cristian pisze: On 26.11.2018 23:11, Tomasz Maciej Nowak wrote: W dniu 26.11.2018 o 21:44, Lucian Cristian pisze: On 20.11.2018 18:20, Tomasz Maciej Nowak wrote: This small series addresses current problem with late loading of Intel microcode in OpenWrt. Following the commit messages [1] and later discussion, late loading off the microcode can be ineffective for some processors [2] and for others disabled [3]. Also it is discouraged for any processor starting from Haswell and Silvermont. Therefore this series converts the Intel microcode bundle to an initial ram disk which is loaded with grub, so kernel has access to it as early as possible. Previous patch series: https://patchwork.ozlabs.org/project/lede/list/?series=39372 1. https://lore.kernel.org/patchwork/cover/348236 2. https://lore.kernel.org/patchwork/cover/348236/#508603 3. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=723f2828a98c8ca19842042f418fb30dd8cfc0f7 [...] No, Your grub doesn't understand *if* command because it's old an doesn't have "test" module enabled. It's left there because sysupgrade doesn't upgrade grub, it updates only boot and root partitions. If You'll write the created image not by sysupgrade but by dd'ing to boot medium, It'll start properly without interruptions. BTW thank You for the report. error: can't find command '['. error: can't find command '['. Press any key to continue... Regards Can I repair this somehow without writing the full image ? only by reversing the commits ? No, not at the moment. I'm trying to figure out best way to update grub on sysupgrade, until then reverting the mentioned commits will bring back old behavior, and no manual intervention on boot will be necessary. shall we revert the series ? Yes, but not the whole series only these commits: 546fced2a23557e95dd34246744c3aa6cad92fe6 x86: add intel microcode entries to grub config 022ffb56b2491fd7d8051ac6e6c7622ecc313d8f intel-microcode: create early load microcode image a822283c7e56bb3b409712e0eb9af5a91aac247d x86: add amd microcode entries to grub config 975019b3a755ec3b91864b60b45e5ee104075096 amd64-microcode: create early load microcode image The rest is okay, won't cause any regressions and will save the effort. Thank You. done ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel turns out that grub will boot automatically after a time out despite the errors (some seconds), but there was another problem that didn't kept the sysupgrade settings and that made my system ureachable Regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] x86: make sysupgrade.tgz reachable again
On 28.11.2018 21:44, Tomasz Maciej Nowak wrote:
Moving binding mount before check for saved sysupgrade configuration
made it unreachable. Fix it by moving binding mount after the check.
Fixes: f78b2616 (x86: mount writable bootfs)
Reported-by: Lucian Cristian
Signed-off-by: Tomasz Maciej Nowak
---
target/linux/x86/base-files/lib/preinit/79_move_config | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/x86/base-files/lib/preinit/79_move_config
b/target/linux/x86/base-files/lib/preinit/79_move_config
index debce43557..aff720a52c 100644
--- a/target/linux/x86/base-files/lib/preinit/79_move_config
+++ b/target/linux/x86/base-files/lib/preinit/79_move_config
@@ -9,10 +9,10 @@ move_config() {
if export_bootdevice && export_partdevice partdev 1; then
mkdir -p /boot
mount -t ext4 -o rw,noatime "/dev/$partdev" /boot
- mount --bind /boot/boot /boot
if [ -f /boot/sysupgrade.tgz ]; then
mv -f /boot/sysupgrade.tgz /
fi
+ mount --bind /boot/boot /boot
fi
}
Can we have this merged ?
Regards
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC] ca-certificates python/host
I would like to propose a patch for ca-certificate to fix the following
error
Traceback (most recent call last):
File "certdata2pem.py", line 150, in
encoded = base64.b64encode(obj['CKA_VALUE']).decode('utf-8')
File "/usr/lib64/python2.6/base64.py", line 53, in b64encode
encoded = binascii.b2a_base64(s)[:-1]
TypeError: b2a_base64() argument 1 must be string or read-only buffer,
not bytearray
and I tried something like this
ifeq ($(CONFIG_PACKAGE_python3),y)
PKG_BUILD_DEPENDS:=python3/host
else
PKG_BUILD_DEPENDS:=python/host
endif
but the test always fail, for this setting is there another approach ?
but not this one PKG_BUILD_DEPENDS:=PACKAGE_python:python/host
PACKAGE_python3:python3/host
because this one assumes that you have selected one or the other and I
would like to reuse python3/host if it was already selected
Regards
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] ca-certificates python/host
On 10.12.2018 11:10, Yousong Zhou wrote:
On Mon, 10 Dec 2018 at 04:35, Lucian Cristian wrote:
I would like to propose a patch for ca-certificate to fix the following
error
Traceback (most recent call last):
File "certdata2pem.py", line 150, in
encoded = base64.b64encode(obj['CKA_VALUE']).decode('utf-8')
File "/usr/lib64/python2.6/base64.py", line 53, in b64encode
encoded = binascii.b2a_base64(s)[:-1]
TypeError: b2a_base64() argument 1 must be string or read-only buffer,
not bytearray
and I tried something like this
ifeq ($(CONFIG_PACKAGE_python3),y)
PKG_BUILD_DEPENDS:=python3/host
else
PKG_BUILD_DEPENDS:=python/host
endif
but the test always fail, for this setting is there another approach ?
Probably because the shebang line of certdata2pem.py is hardcoded as
/usr/bin/python.
OpenWrt ca-certificates package does not have a dependency on this
python script, right? Even if it does, python2.6 is considered to be
deprecated upstream and not recommended by many downstream projects.
Regards,
yousong
but not this one PKG_BUILD_DEPENDS:=PACKAGE_python:python/host
PACKAGE_python3:python3/host
because this one assumes that you have selected one or the other and I
would like to reuse python3/host if it was already selected
Regards
___
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
the problem appears on a centos 6 machine and that's why I want to use
the self build python/host, or this fix is too troublesome to be included ?
Regards
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC 0/6] x86: switch to generic image generation code and
On 13.01.2019 23:49, Tomasz Maciej Nowak wrote:
This is aftermath of partially failed series [1].
When I was searching for ways to upgrade of bootloader on existing
OpenWrt installations, I noticed that it'll be difficult to add this
feature within existing code creating x86 target images. I decided to
switch this code to generic one, wich is used in most of the OpenWrt
targets. Both of the chages are rather intrusive hence te RFC tag.
Please voice Your concerns and opinions.
https://patchwork.ozlabs.org/cover/1000625
Tomasz Maciej Nowak (6):
x86/grub2: move grub2 image creation to grub2 package
x86: switch image generation to new code
x86: remove obsolete profiles
x86: geode: shrink amount of default packages
x86/grub2: add bootloader upgrade on sysupgrade
grub2: add preinit hook for bootloader upgrade
config/Config-images.in | 22 +-
include/image.mk | 1 -
package/boot/grub2/Makefile | 79 ++-
.../boot/grub2/files/81_upgrade_bootloader| 20 ++
.../boot/grub2/files}/grub-early.cfg | 0
target/linux/x86/64/profiles/000-Generic.mk | 15 --
target/linux/x86/64/target.mk | 2 +-
target/linux/x86/Makefile | 4 +-
.../x86/base-files/lib/upgrade/platform.sh| 27 ++-
.../linux/x86/generic/profiles/000-Generic.mk | 18 --
target/linux/x86/generic/target.mk| 2 +-
.../linux/x86/geode/profiles/000-Generic.mk | 20 --
target/linux/x86/geode/profiles/100-Geos.mk | 19 --
target/linux/x86/geode/target.mk | 14 +-
target/linux/x86/image/64.mk | 5 +
target/linux/x86/image/Makefile | 199 +++---
target/linux/x86/image/generic.mk | 8 +
target/linux/x86/image/geode.mk | 16 ++
target/linux/x86/image/grub-iso.cfg | 2 +-
.../linux/x86/image/{grub.cfg => grub-pc.cfg} | 4 +-
target/linux/x86/image/legacy.mk | 8 +
.../linux/x86/legacy/profiles/000-Generic.mk | 18 --
target/linux/x86/legacy/target.mk | 1 +
23 files changed, 255 insertions(+), 249 deletions(-)
create mode 100644 package/boot/grub2/files/81_upgrade_bootloader
rename {target/linux/x86/image => package/boot/grub2/files}/grub-early.cfg
(100%)
delete mode 100644 target/linux/x86/64/profiles/000-Generic.mk
delete mode 100644 target/linux/x86/generic/profiles/000-Generic.mk
delete mode 100644 target/linux/x86/geode/profiles/000-Generic.mk
delete mode 100644 target/linux/x86/geode/profiles/100-Geos.mk
create mode 100644 target/linux/x86/image/64.mk
create mode 100644 target/linux/x86/image/generic.mk
create mode 100644 target/linux/x86/image/geode.mk
rename target/linux/x86/image/{grub.cfg => grub-pc.cfg} (57%)
create mode 100644 target/linux/x86/image/legacy.mk
delete mode 100644 target/linux/x86/legacy/profiles/000-Generic.mk
tested on systems with multiple drives and multiple partitions, the only
thing is that the target images will always be gziped, this is annoying
on other targets too, also needs a rebase
Regards
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC 0/6] x86: switch to generic image generation code and
On 06.02.2019 16:08, Tomasz Maciej Nowak wrote:
W dniu 04.02.2019 o 09:29, Lucian Cristian pisze:
On 13.01.2019 23:49, Tomasz Maciej Nowak wrote:
This is aftermath of partially failed series [1].
When I was searching for ways to upgrade of bootloader on existing
OpenWrt installations, I noticed that it'll be difficult to add this
feature within existing code creating x86 target images. I decided to
switch this code to generic one, wich is used in most of the OpenWrt
targets. Both of the chages are rather intrusive hence te RFC tag.
[...]
rename target/linux/x86/image/{grub.cfg => grub-pc.cfg} (57%)
create mode 100644 target/linux/x86/image/legacy.mk
delete mode 100644 target/linux/x86/legacy/profiles/000-Generic.mk
tested on systems with multiple drives and multiple partitions, the only thing
is that the target images will always be gziped, this is annoying on other
targets too, also needs a rebase
Thank You for testing.
The generated images are gziped because they are built by default and this will
save space and bandwidth, maybe this can be turned off by default and enabling
it would be responsibility of buildbots, this would need some input of someone
responsible for infrastructure.
I'll rebase and add minor improvements to this series after sorting out some of
my pending patches.
Regards
Regards, Tomasz.
selecting ext4, gzip option will appear and deselecting gzip images has
no effect, before the option was available for squashfs also, anyway
this is another issue that is seen on other targets and if I remember
there was recently a PR related to this option on some target
Regards
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Slow DNSMasq with > 100, 000 entries in additional addresses file
On 26.12.2016 19:32, TheWerthFam wrote: Using the adblock set of scripts to block malware and porn sites. The porn sites list is 800,000 entries, about 10x the number of sites adblock normally uses. With the full list of malware and porn domains loaded, dnsmasq takes 115M of memory and normally sits around 50% CPU usage with moderate browsing usage. CPU and RAM usage isn't really a problem other than lookups are slow now. Platform is cc 15.05.1 r49389 on banana pi r1. The adblock script takes the different lists, creates files in /tmp/dnsmasq.d/ entries looking like local=/domainnottogoto.com/ one entry per line. The goal is to return NXDOMAIN to entries in the lists. Lists are sorted and with unique entries. I've tried increasing the cachesize to 10,000 but that made no change. Tried neg-ttl=3600 with default negative caching enabled with no change. Are there dnsmasq setting that will improve the performance? or should it be configured differently to achieve this goal? Perhaps unbound would be better suited? Cheers Derek ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel use squid and squidguard regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Slow DNSMasq with > 100, 000 entries in additional addresses file
On 27.12.2016 04:54, TheWerthFam wrote: Problem with this method is that it misses lots of HTTPS based sites. I do already run squid though. Am I wrong that it will not proxy https sites unless you use MITM type setup? Thanks On 12/26/2016 08:47 PM, Lucian Cristian wrote: On 26.12.2016 19:32, TheWerthFam wrote: Using the adblock set of scripts to block malware and porn sites. The porn sites list is 800,000 entries, about 10x the number of sites adblock normally uses. With the full list of malware and porn domains loaded, dnsmasq takes 115M of memory and normally sits around 50% CPU usage with moderate browsing usage. CPU and RAM usage isn't really a problem other than lookups are slow now. Platform is cc 15.05.1 r49389 on banana pi r1. The adblock script takes the different lists, creates files in /tmp/dnsmasq.d/ entries looking like local=/domainnottogoto.com/ one entry per line. The goal is to return NXDOMAIN to entries in the lists. Lists are sorted and with unique entries. I've tried increasing the cachesize to 10,000 but that made no change. Tried neg-ttl=3600 with default negative caching enabled with no change. Are there dnsmasq setting that will improve the performance? or should it be configured differently to achieve this goal? Perhaps unbound would be better suited? Cheers Derek ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel use squid and squidguard regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel I'm guessing that if you implement those restrictions I think that every client has the proxy enforced into the browser so https would be processed by squidguard too, for transparent https proxy you would need to do sslbump regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Support for BTHomeHub5
On 13.01.2017 20:16, Mauro M. wrote: Hello Mathias, 2 workarounds were suggested: One was not acceptable as is defeated the purpose of a router asking to configure static routes on EVERY host in a LAN The second might work with some careful re-configuration of the firewall. It did not in my case because the complexity of the network involved required more effort than it makes sense to provide on my end, again it defeats the purpose of a router. Currently I am using a SNAT workaround, however this works only for networks directly connected to a second router, with more hops (as it happens with VPNs) it does not work. I have been banging on to this issue since I moved to LEDE 4 weeks ago, driven by a better BtHomeHub5 support. I tried to solve the issue myself as in most cases, but I could find only workarounds. The workarounds were acceptable until I started adding VPNs with other sites and that is were the workarounds show their cracks. For a while I wondered how could this have not been noticed. Perhaps most people use a single router that does very little routing after all. At which point I reported it first through the LEDE mailing list as a question (I received no reply, I wonder if the message got through in the first place), and then via a bug report once I saw no reply through the list. The replies through the bug report lead me to believe that there was not an appetite to revert to a proper router capability as in OpenWrt. Previously I had not totally positive experiences when I reported issues, or contributed changes (like IP Virtual Server Load balancer: I still apply my patches and build my own version because the change was never accepted in OpenWRT, or BtHomeHub5 LEDs no longer working, on that I was told "it is by design"). So I expressed my frustration, dusted off OpenWrt trunk and now I am running Designated Driver 50078 built with IP Virtual Server for Load Balancing on my Netgear router (also manually reconfigured with a 128MB flash filesystem because the patch to make it so large was never included in the mainstream) Please note that I make little distinction between OpenWrt and LEDE. I understand any conversation about free, etc. I am very grateful. I would be happy to contribute if it somebody could accept an hand over of the Load Balancer project. Best regards, Mauro On 13/01/17 17:42, Mathias Kresin wrote: 2017-01-13 18:35 GMT+01:00 Martin Blumenstingl : On Fri, Jan 13, 2017 at 6:30 PM, Mauro M. wrote: Hello, Is OpenWRT going to backport support for BtHomeHub5 from LEDE? This router is very well supported in LEDE, whilst support is only basic in OpenWrt, LEDE implemented some broken changes in the firewall that prevent basic routing (it defeats the primary purpose of a router!), so I would like to use OpenWrt where routing works as expected, but I need to run it on BT Home Hub 5 routers. have you reported this to the LEDE guys? Yes, the bug is reported[0] and it's being worked on. No idea why Mauro is that eager. Time between providing the full config files and a proposed fix was <2h. And as usual everything for free. Mathias [0] https://bugs.lede-project.org/index.php?do=details&task_id=382 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel jow pushed a fix about a hour ago https://github.com/lede-project/source/commit/920170a27fe9a3b66d5a857d70408dbac3720e0f regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH 0/5] x86: add support for microcode update
On 19.01.2018 00:41, Zoltan HERPAI wrote: On Thu, 18 Jan 2018, Hauke Mehrtens wrote: On 01/18/2018 01:51 PM, Nick Lowe wrote: Does an update to the Kernel, 4.9.77 and 4.14.14 need to be made to properly address this? There are fixes to mitigate Spectre. We even need a patch for GCC which will be in GCC 8 and 7.3. For master we should backport it to GCC 5.5, but what do we want to do with 17.01 and 15.05 ? I'll speak only of CC - there is no microcode updater in it at all, so while 3.18 contains partial patches and GCC 4.8 is unlikely to get fixed, we should add this facility into it anyway. The AMD microcoded updater needs at least kernel 4.15, 4.14.13, 4.9.76, 4.4.111 which we already have. That's only for the fam17h (Zen) CPUs, earlier CPU types should work with earlier kernels, and this can likely be backported into 3.18. (I don't have a Zen-based box to test, hands up whoever has one.) Regards, -w- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel I do have an R5 1600, but can't test until Monday night Regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] kernel version status
On 19.02.2018 08:41, John Crispin wrote: On 18/02/18 22:43, Hauke Mehrtens wrote: The next OpenWrt release will use kernel 4.9 and kernel 4.14 depending on the target. All targets that are *not* on either kernel 4.9 or 4.14 will not be included in the next release. I did some overview of the kernel version some months ago here: http://lists.infradead.org/pipermail/lede-dev/2017-October/009446.html Here is the current situation as of today: The following targets are on kernel 4.14 and are fine: * apm821xx * archs38 * armvirt * cns3xxx * malta * mediatek * octeon * octeontx * sunxi * x86 The following targets are on kernel 4.9 and are fine: * ar71xx * ar7 * arc770 * at91 There are some patches for kernel 4.14 on the mailing list waiting for response from author * ath25 * bcm53xx patches for 4.14 are available in master * brcm2708 * brcm47xx * brcm63xx patches for 4.14 are available in master * imx6 There are some patches for kernel 4.14 on the mailing list which is being worked on * ipq806x * ixp4xx * kirkwood * lantiq patches for 4.14 are in Mathias Kresin's staging tree. * layerscape * mpc85xx * mvebu patches for 4.14 are available in master I would like to get this to kernel 4.14 by default soon. * mxs * omap * orion * pistachio * ramips patches for 4.14 are available in master * rb532 * uml The following targets are on kernel 4.4 and will probably not be included in the next release: * gemini * oxnas * zynq The following targets are on kernel 3.18 and will probably not be included in the next release: * adm5120 * adm8668 * au1000 * mcs814x I have patches which port this target to 4.4 in my tree, but nobody tested them. https://git.lede-project.org/?p=lede/hauke/staging.git;a=shortlog;h=refs/heads/kernel-4.4 * ppc40x * ppc44x * xburst I have patches which port this target to 4.4 in my tree, but nobody tested them https://git.lede-project.org/?p=lede/hauke/staging.git;a=shortlog;h=refs/heads/kernel-4.4 This target is on kernel 4.1 (WTF): * omap24xx All the targets which are not on kernel 4.9 or 4.14 will probably not be included in the next release, I also haven't seen any activity for any of them to get support for more recent kernel versions, if you need them please take care now. Hauke Hi Hauke, I planned to make that list today, thanks for taking care of it !. I would like to see ar71xx and ramips stay on v4.9, regardless of there being patches for v4.14. I would also like to see ar71xx never being bumped to v4.14, I spent a few days last week revamping my old ath79 port and would like to see a hard cut, moving QCA mips target to OF only post release. John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel Omap is working by just changing the kernel version (tested on beagle bone black) Regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] 18.03/4 -> GCC 5 or 7
On 04.03.2018 17:15, Hauke Mehrtens wrote: On 02/16/2018 01:46 PM, John Crispin wrote: Hi, whats on the critical todo list for the upcoming release ? i still have a few minor things that I'll be adding shortly, apart from that I am currently not aware of any huge problems. the release will be a mix between 4.9 and 4.14 afaik !? I think the kernel situation is ok now and not blocking a release, we will have a mixed kernel 4.9 and 4.14 release. All important targets are on one of these two kernel versions by now. The patches for the gemini target will probably get included soon. Some targets will probably be updated from 4.9 to 4.14, but this is not blocking. What do we want to do with GCC 5.5 versus 7.3? GCC 5.5 is getting old, we have multiple problems with it, the big blocker for GCC 7 was just fixed upstream and we backported that fix. see: http://git.openwrt.org/25aaff9100065dba881be71b9dcab1e9cc8a7b5f The x86 and x86_64 architectures are already on GCC 7.3, the ARC architecture uses their own GCC fork based on version 7.X all other architectures are on GCC 5.5. We have the following problems with GCC 5.5: * U-Boot depends on GCC 6 or higher since version 2018.01 on ARM and ARM64 * GCC 5 and older are producing too big binaries, e.g. the SPL on the Allwinner A64 (sunxi, ARM64) is getting too big starting with U-Boot 2017.09 and does not fit into the SRAM any more, GCC 7 solves this problem. * busybox on the gemini target updated to kernel 4.14 does not work correctly. * GCC 5.5 only has out of tree fixes for Spectre, GCC 7.3 already has the retpoline fixes against Spectre included As the x86 target use GCC 7.3 now, there are multiple pull requests fixing some build problems in some packages with GCC 7. I am not aware of any regressions in GCC 7 compared to GCC 5. Changing the default compiler from GCC 5 to GCC 7 is no big problem, the problems are the regressions we are not aware of by now, if we change the default compiler for all architectures to GCC 7 we should probably wait 4 weeks before doing an RC release to be sure most of the runtime problems with GCC 7 are found. If we do the switch to GCC 7 I think we should also change binutils from 2.28 to 2.28.1 or 2.29.1. I found this problem with binutils 2.28 which was already fixed in 2.28.1: https://git.openwrt.org/bcd17ce9a3308accc30d99f4dd43f2062bb3fabc The minor versions contains more bugfixes. There is also a pull request for busybox 2.28.1 at github, this will probably also introduce some more regressions, so I am not sure if we should take it before or after the release. https://github.com/openwrt/openwrt/pull/733 I do not have a real opinion on this and I am probably the wrong person to judge this. I do not know what the status of the software fast path patches are, but they are looking interesting. My proposal would be to update all targets to GCC 7.3 and also use binutils 2.29.1 and musl 1.1.19. This change would be done as soon as possible and then we branch of end of March or beginning of April for 18.X and do a RC1 one week after creating the branch. Hauke ___ Lede-dev mailing list lede-...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev testing r6395-6c194078db on a ramips Ralink RT5350 with 4.14 and GCC 7.3 gives this error in luci daemon.err uhttpd[873]: /usr/bin/lua: /usr/lib/lua/luci/debug.lua:6: attempt to call a number value daemon.err uhttpd[873]: stack traceback: daemon.err uhttpd[873]: /usr/lib/lua/luci/debug.lua:6: in main chunk daemon.err uhttpd[873]: [C]: in function 'require' daemon.err uhttpd[873]: /usr/lib/lua/luci/util.lua:8: in main chunk daemon.err uhttpd[873]: [C]: in function 'require' daemon.err uhttpd[873]: /usr/lib/lua/luci/config.lua:4: in main chunk daemon.err uhttpd[873]: [C]: in function 'require' daemon.err uhttpd[873]: /usr/lib/lua/luci/cacheloader.lua:5: in main chunk daemon.err uhttpd[873]: [C]: in function 'require' daemon.err uhttpd[873]: /www/cgi-bin/luci:2: in main chunk daemon.err uhttpd[873]: [C]: ? Regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LEDE 17.01.5 release planning
On 24.05.2018 22:40, Martin Tippmann wrote: On Thu, May 24, 2018 at 9:06 PM, Hauke Mehrtens wrote: Please do not hesitate to re report some request that something should be backported from master or some regression compared to lede-17.01, if it looks like they got ignored and didn't got a response. Hi, would be great if the recent wireguard version bump with MIPS assembly could be included: https://git.openwrt.org/aa30eb5b073c93ad00742a5a4046ac42e15b4b7a thanks, Martin ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.infradead.org/mailman/listinfo/openwrt-devel maybe omap fixes ? currently only ext4 images are working with this https://github.com/openwrt/openwrt/pull/869, the squashfs and sysupgrade is also working Regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.infradead.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v3] ar71xx: add support for GL.iNet GL-AR750S
On 25.05.2018 13:06, Luochongjun wrote:
This patch adds supports for GL-AR750S.
Specification:
- SOC: QCA9563 (775MHz)
- Flash: 16 MiB (W25Q128FVSG)
- RAM: 128 MiB DDR2
- Ethernet: 2x 1Gbps LAN + 1x 1Gbps WAN
- Wireless: 2.4GHz (bgn) and 5GHz (ac)
- USB: 1x USB 2.0 port
- Button: 1x switch button, 1x reset button
- LED: 3x LEDS (green)
Flash instruction:
Apply factory image via web-gui.
Signed-off-by: Luo chongjun
---
target/linux/ar71xx/base-files/etc/board.d/01_leds | 4 +
.../linux/ar71xx/base-files/etc/board.d/02_network | 4 +
.../etc/hotplug.d/firmware/11-ath10k-caldata | 1 +
target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 +
.../ar71xx/base-files/lib/upgrade/platform.sh | 1 +
target/linux/ar71xx/config-4.9 | 1 +
.../ar71xx/files/arch/mips/ath79/Kconfig.openwrt | 11 ++
target/linux/ar71xx/files/arch/mips/ath79/Makefile | 1 +
.../ar71xx/files/arch/mips/ath79/mach-gl-ar750s.c | 193 +
.../linux/ar71xx/files/arch/mips/ath79/machtypes.h | 1 +
target/linux/ar71xx/generic/config-default | 1 +
target/linux/ar71xx/image/generic.mk | 13 ++
12 files changed, 234 insertions(+)
create mode 100755 target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar750s.c
diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds
b/target/linux/ar71xx/base-files/etc/board.d/01_leds
index 52f1ac3..f436854 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -385,6 +385,10 @@ gl-ar750)
ucidef_set_led_wlan "wlan2g" "WLAN2G" "$board:white:wlan2g" "phy1tpt"
ucidef_set_led_wlan "wlan5g" "WLAN5G" "$board:white:wlan5g" "phy0tpt"
;;
+gl-ar750s)
+ ucidef_set_led_wlan "wlan2g" "WLAN2G" "$board:green:wlan2g" "phy1tpt"
+ ucidef_set_led_wlan "wlan5g" "WLAN5G" "$board:green:wlan5g" "phy0tpt"
+ ;;
gl-mifi)
ucidef_set_led_wlan "wlan" "WLAN" "$board:green:wlan" "phy0tpt"
ucidef_set_led_netdev "wan" "WAN" "$board:green:wan" "eth0"
diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network
b/target/linux/ar71xx/base-files/etc/board.d/02_network
index 5898261..5f87ab1 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -432,6 +432,10 @@ ar71xx_setup_interfaces()
ucidef_add_switch "switch0" \
"0@eth1" "1:lan" "2:lan"
;;
+ gl-ar750s)
+ ucidef_add_switch "switch0" \
+ "0@eth0" "2:lan:2" "3:lan:1" "1:wan"
+ ;;
jwap230)
ucidef_set_interfaces_lan_wan "eth0.1" "eth1.2"
ucidef_add_switch "switch0" \
diff --git
a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 5d01701..f82026c 100644
--- a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -99,6 +99,7 @@ case "$FIRMWARE" in
ath10kcal_extract "caldata" 20480 2116
ath10kcal_patch_mac $(macaddr_add $(cat
/sys/class/net/eth0/address) +1)
;;
+ gl-ar750s|\
gl-ar750|\
tl-wpa8630)
ath10kcal_extract "art" 20480 2116
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 42bd80d..74aa21b 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -727,6 +727,9 @@ ar71xx_board_detect() {
*"GL-AR750")
name="gl-ar750"
;;
+ *"GL-AR750S")
+ name="gl-ar750s"
+ ;;
*"GL-CONNECT INET v1")
name="gl-inet"
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 284582f..d0a3f30 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -260,6 +260,7 @@ platform_check_image() {
gl-ar300m|\
gl-ar300|\
gl-ar750|\
+ gl-ar750s|\
gl-domino|\
gl-mifi|\
gl-usb150|\
diff --git a/target/linux/ar71xx/config-4.9 b/target/linux/ar71xx/config-4.9
index 35efd17..a453e10 100644
--- a/target/linux/ar71xx/config-4.9
+++ b/target/linux/ar71xx/config-4.9
@@ -120,6 +120,7 @@ CONFIG_ATH79=y
# CONFIG_ATH79_MACH_GL_AR300 is not set
# CONFIG_ATH79_MACH_GL_AR300M is not set
# CONFIG_ATH79_MACH_GL_AR750 is not set
+# CONFIG_ATH79_MACH_GL_AR750S is not set
# CONFIG_ATH79_MACH_GL_DOMINO is not set
# CONFIG_ATH79_MACH_GL_INET is not set
# CONFIG_ATH79_MACH_GL_MIFI is not set
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
b/target
Re: [OpenWrt-Devel] Bug: HW Flow Offload + Wireguard Bug
On 22.05.2018 13:53, Jaap Buurman wrote: Dear Felix & others, I am currently running a 18.06 snapshot image to start testing the stability of the firmware and new features, including the lovely hardware flow offload. While it is working extremely well (I am finally able to max out my connection, but with hardly any CPU load!), pushing data through Wireguard instantly crashes my router whenever hw flow offload is enabled. There is another report of this issue on the forum, including a call trace: https://forum.lede-project.org/t/netfilter-flow-offload-hw-nat/10237/44?u=mushoz If you need any additional information or require my help testing, please do not hesitate to contact me. Yours sincerely, Jaap Buurman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.infradead.org/mailman/listinfo/openwrt-devel but did you tried on wireguard mailinglist ? Jason usually tries to fix all the scenarios Regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.infradead.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4 RFCv2] Realtek SMI RTL836x DSA driver
On 28.05.2018 20:47, Linus Walleij wrote: This is a second RFC version of the DSA driver for Realtek RTL8366x especially RTL8366RB. I've been beating my head against this one and I'm not really clear on why my ethernet frames are not coming through to the CPU port on the chip. It appears when using ethtool -S on the ports that packets are passing fine into the router fabric and through to the CPU port but the ethernet driver where the fixed link is connected refuse to accept the packages. Of course packages needs VLAN tagging/untagging, this is not the problem as it seems. The OpenWRT userspace even kicks the interface in promiscuous mode so all packages should be accepted, I also tried tcpdump on the interface to no avail: the ethernet frames are so broken that they do not even make it through the fixed link. The do cause error statistics on the ethernet port on the system side. It might very well be that the problem is on the ethernet driver side, and this driver "just works" with other routers, so reposting it along with the DTS example so others can try it while I keep banging my head against it. Maybe I should just try to obtain another router with this chip so as to establish that it is not the DSA router driver that is wrong. I did try this hardware with the present OpenWRT driver (not DSA) and that failed too. Anyways check out the new DT bindings etc. Linus Walleij (4): net: phy: realtek: Support RTL8366RB variant net: dsa: Add bindings for Realtek SMI DSAs net: dsa: realtek-smi: Add Realtek SMI driver ARM: dts: Add ethernet and switch to D-Link DIR-685 .../bindings/net/dsa/realtek-smi.txt | 153 ++ arch/arm/boot/dts/gemini-dlink-dir-685.dts| 153 +- drivers/net/dsa/Kconfig | 12 + drivers/net/dsa/Makefile |2 + drivers/net/dsa/realtek-smi.c | 488 ++ drivers/net/dsa/realtek-smi.h | 146 ++ drivers/net/dsa/rtl8366.c | 524 ++ drivers/net/dsa/rtl8366rb.c | 1411 + drivers/net/phy/realtek.c | 33 + 9 files changed, 2921 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/net/dsa/realtek-smi.txt create mode 100644 drivers/net/dsa/realtek-smi.c create mode 100644 drivers/net/dsa/realtek-smi.h create mode 100644 drivers/net/dsa/rtl8366.c create mode 100644 drivers/net/dsa/rtl8366rb.c I have a very strange problem with this switch too, porting the 1043nd-v1 ar71xx target to ath79 dts using the *standard* drivers (John validated that they work in that config), I can see the packets on the interface but no actual traffic routed or accepted, from time to time, after a power off, the exact image is working, then after 2-3 reboots is not working anymore. I'll try the dsa drivers on the new ath79 target and come back at you Regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.infradead.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 4/5] ath79: add TP-Link TL-WR740N/ND v2 port
On 29.05.2018 21:08, Alex Maclean wrote: + ucidef_set_led_wlan "wlan" "WLAN" "$boardname:green:wlan" "phy0tpt" thank you for the tiny split, you can trigger this in dts, please have a look at the PR's on github ! Regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] config: extend small_flash feature
On 30.05.2018 20:22, Martin Tippmann wrote: find /usr | xargs md5sum I made the test on tl-wr841n-v9 with luci selected these are the changes to squashfs --- a/config/Config-images.in +++ b/config/Config-images.in @@ -149,8 +149,15 @@ menu "Target Images" int "Block size (in KiB)" depends on TARGET_ROOTFS_SQUASHFS default 64 if LOW_MEMORY_FOOTPRINT + default 1024 if (SMALL_FLASH && !LOW_MEMORY_FOOTPRINT) default 256 + config SQUASHFS_FRAGMENT_CACHE_SIZE + int "Number of fragments cached" + depends on TARGET_ROOTFS_SQUASHFS + default 1 if (SMALL_FLASH && !LOW_MEMORY_FOOTPRINT) + default 3 + menuconfig TARGET_ROOTFS_UBIFS bool "ubifs" default y if USES_UBIFS the results: after boot root@OpenWrt:/# df -h Filesystem Size Used Available Use% Mounted on /dev/root 3.0M 3.0M 0 100% /rom tmpfs 13.4M 76.0K 13.4M 1% /tmp tmpfs 13.4M 48.0K 13.4M 0% /tmp/root tmpfs 512.0K 0 512.0K 0% /dev /dev/mtdblock4 320.0K 220.0K 100.0K 69% /overlay overlayfs:/overlay 320.0K 220.0K 100.0K 69% / root@OpenWrt:/# free total used free shared buffers cached Mem: 27520 23920 3600 124 2112 5748 -/+ buffers/cache: 16060 11460 Swap: 0 0 0 root@OpenWrt:/# cat /proc/meminfo MemTotal: 27520 kB MemFree: 3536 kB MemAvailable: 9064 kB Buffers: 2112 kB Cached: 5748 kB SwapCached: 0 kB Active: 5892 kB Inactive: 3120 kB Active(anon): 1252 kB Inactive(anon): 24 kB Active(file): 4640 kB Inactive(file): 3096 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 0 kB Writeback: 0 kB AnonPages: 1160 kB Mapped: 1784 kB Shmem: 124 kB Slab: 8876 kB SReclaimable: 1216 kB SUnreclaim: 7660 kB KernelStack: 304 kB PageTables: 208 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 13760 kB Committed_AS: 3916 kB VmallocTotal: 1048372 kB VmallocUsed: 0 kB VmallocChunk: 0 kB after, ran 3 times MemTotal: 27520 kB MemFree: 1548 kB MemAvailable: 8880 kB Buffers: 2112 kB Cached: 7268 kB SwapCached: 0 kB Active: 9612 kB Inactive: 832 kB Active(anon): 1164 kB Inactive(anon): 24 kB Active(file): 8448 kB Inactive(file): 808 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 0 kB Writeback: 0 kB AnonPages: 1072 kB Mapped: 1688 kB Shmem: 124 kB Slab: 9508 kB SReclaimable: 1784 kB SUnreclaim: 7724 kB KernelStack: 288 kB PageTables: 184 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 13760 kB Committed_AS: 3572 kB VmallocTotal: 1048372 kB VmallocUsed: 0 kB VmallocChunk: 0 kB root@OpenWrt:/# free total used free shared buffers cached Mem: 27520 25940 1580 124 2112 7268 -/+ buffers/cache: 16560 10960 Swap: 0 0 0 Regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/4] ath79: add Netgear WNR612 v2
On 13.06.2018 11:51, Zoltan HERPAI wrote: + ucidef_set_led_wlan "wlan" "WLAN" "netgear:green:wlan" "phy0tpt" is this needed ? @juppin just made a cleanup for wifi triggers https://github.com/openwrt/openwrt/commit/14cb05909a8dc6e42008697b4fe47b8fa00789d8 Regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
[OpenWrt-Devel] ath79: DSA with qca8k
I tried the example found in bindings and in qca8k staging but I don't have any output when the device starts or when the module is loaded, if is built as module. Tried with a qca9563+qca8337n switch and also with a qca9558+qca8327n switch with id added to qca8k driver, I also enabled printk on every function in the driver but nothing is printed. I added a new dsa subtarget with this kernel options # CONFIG_AG71XX is not set # CONFIG_AG71XX_DEBUG is not set # CONFIG_AG71XX_DEBUG_FS is not set # CONFIG_AR8216_PHY is not set # CONFIG_AR8216_PHY_LEDS is not set # CONFIG_RTL8366RB_PHY is not set # CONFIG_RTL8366S_PHY is not set # CONFIG_RTL8366_SMI is not set # CONFIG_SWCONFIG is not set # CONFIG_SWCONFIG_LEDS is not set CONFIG_NET_DSA=y CONFIG_NET_DSA_RTK_SMI=y CONFIG_NET_DSA_QCA8K=y CONFIG_NET_NS=y CONFIG_NET_PACKET_ENGINE=y CONFIG_NET_SWITCHDEV=y Is there something missing or the problem should be in dts file ? Regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath79: DSA with qca8k
On 20.06.2018 11:26, Robert Marko wrote: You are missing CONFIG_NET_DSA_TAG_QCA Thanks but it doesn't help ! Regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath79: DSA with qca8k
On 20.06.2018 12:02, John Crispin wrote:
On 20/06/18 10:39, Lucian Cristian wrote:
On 20.06.2018 11:26, Robert Marko wrote:
You are missing CONFIG_NET_DSA_TAG_QCA
Thanks but it doesn't help !
Regards
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/listinfo/openwrt-devel
which HW are you using for this ?
John
wr1043nd-v3 (8327N) or wr1043nd-v4 (8337N)
for 8327N I patched like this:
--- a/drivers/net/dsa/qca8k.c 2018-05-10 22:19:15.885054832 +0300
+++ b/drivers/net/dsa/qca8k.c 2018-05-10 22:19:41.911438171 +0300
@@ -868,8 +868,9 @@
id = qca8k_read(priv, QCA8K_REG_MASK_CTRL);
id >>= QCA8K_MASK_CTRL_ID_S;
id &= QCA8K_MASK_CTRL_ID_M;
- if (id != QCA8K_ID_QCA8337)
- return -ENODEV;
+ pr_info ("qca8k detect: \n");
+ if (id != QCA8K_ID_QCA8337 || id != QCA8K_ID_QCA8327N)
+ return -ENODEV;
priv->ds = dsa_switch_alloc(&mdiodev->dev, DSA_MAX_PORTS);
if (!priv->ds)
--- a/drivers/net/dsa/qca8k.h 2018-06-02 17:08:44.783407224 +0300
+++ b/drivers/net/dsa/qca8k.h 2018-06-02 17:11:33.339463372 +0300
@@ -23,6 +23,8 @@
#define PHY_ID_QCA8337 0x004dd036
#define QCA8K_ID_QCA8337 0x13
+#define PHY_ID_QCA8327N 0x004dd034
+#define QCA8K_ID_QCA8327N 0x12
#define QCA8K_NUM_FDB_RECORDS 2048
Regards
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Archer C7 v2 with Target System "Atheros ATH79 (DTS)" or "Atheros AR7xxx/AR9xxx"
On 28.06.2018 00:56, e9hack wrote: Hi, I'm using an Archer C7 v2 from TP-Link. Usually I build the image for Target System "Atheros AR7xxx/AR9xxx". If I switch over to "Atheros ATH79 (DTS)" and try to update my router, I got the following error message: root@:~# sysupgrade /tmp/openwrt-ath79-generic-tl-archer-c7-v2-squashfs-sysupgrade-d180627.bin & root@:~# Device archer-c7 not supported by this image Supported devices: tplink,tl-archer-c7-v2 Image check 'fwtool_check_image' failed. Is Target System "Atheros ATH79 (DTS)" for Target Profile "TP-LINK Archer C7 v2" not compatible with Target System "Atheros AR7xxx/AR9xxx" for the same Target Profile? Regards, Hartmut ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel It may be that board name has changed, what's your cat /tmp/sysinfo/board_name ? Now on ath79 should be tplink,tl-archer-c7-v2 so if doesn't match this is the problem You can safely try with -F, but you'll be needed to recreate the /etc/config/wifreless file Regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] verbose.mk: quote SUBMAKE options
On 06.07.2018 13:03, 李国 wrote:
build openwrt on centos 6 I should use devtoolset-3 to get gcc 4.9, but
it fail when make menuconfig. so I have to give option HOSTCC='gcc
-Wl,--copy-dt-needed-entries' to make. But it passed to sub make to
HOSTCC=gcc as micro SUBMAKE expand to HOSTCC=gcc
-Wl,--copy-dt-needed-entries. This patch fix this issue.
make -C build menuconfig HOSTCC='gcc -Wl,--copy-dt-needed-entries' V='1'
make: Entering directory `/work/openwrt/openwrt/build'
/opt/rh/devtoolset-3/root/usr/libexec/gcc/x86_64-redhat-linux/4.9.2/ld:
lxdialog/checklist.o: undefined reference to symbol 'acs_map'
//lib64/libtinfo.so.5: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[1]: *** [mconf] Error 1
make -s -C scripts/config all CC=gcc -Wl,--copy-dt-needed-entries: build
failed. Please re-run make with -j1 V=s to see what's going on
make: *** [scripts/config/mconf] Error 1
make: Leaving directory `/work/openwrt/openwrt/build'
Signed-off-by: 李国
---
include/verbose.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/verbose.mk b/include/verbose.mk
index b7e43f7430..e02aefe8dd 100644
--- a/include/verbose.mk
+++ b/include/verbose.mk
@@ -54,7 +54,7 @@ ifeq ($(findstring s,$(OPENWRT_VERBOSE)),)
else
SILENT:=>/dev/null $(if $(findstring w,$(OPENWRT_VERBOSE)),,2>&1)
export QUIET:=1
-SUBMAKE=cmd() { $(SILENT) $(MAKE) -s $$* < /dev/null || { echo "make $$*: build failed.
Please re-run make with -j1 V=s to see what's going on"; false; } } 8>&1 9>&2; cmd
+SUBMAKE=cmd() { $(SILENT) $(MAKE) -s "$$@" < /dev/null || { echo "make $$*: build failed.
Please re-run make with -j1 V=s to see what's going on"; false; } } 8>&1 9>&2; cmd
endif
.SILENT: $(MAKECMDGOALS)
I've just successfully ran make menuconfig on centos 6 with devtoolset-3
$ rpm -qa | grep devtoolset
devtoolset-3-runtime-3.1-12.el6.x86_64
devtoolset-3-libstdc++-devel-4.9.2-6.2.el6.x86_64
devtoolset-3-gcc-4.9.2-6.2.el6.x86_64
devtoolset-3-binutils-2.24-18.el6.x86_64
devtoolset-3-gcc-c++-4.9.2-6.2.el6.x86_64
$ scl enable devtoolset-3 bash
$ make menuconfig
*** End of the configuration.
*** Execute 'make' to start the build or try 'make help'.
Regards
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] verbose.mk: quote SUBMAKE options
On 06.07.2018 14:09, Lucian Cristian wrote:
On 06.07.2018 13:03, 李国 wrote:
build openwrt on centos 6 I should use devtoolset-3 to get gcc 4.9, but
it fail when make menuconfig. so I have to give option HOSTCC='gcc
-Wl,--copy-dt-needed-entries' to make. But it passed to sub make to
HOSTCC=gcc as micro SUBMAKE expand to HOSTCC=gcc
-Wl,--copy-dt-needed-entries. This patch fix this issue.
make -C build menuconfig HOSTCC='gcc -Wl,--copy-dt-needed-entries' V='1'
make: Entering directory `/work/openwrt/openwrt/build'
/opt/rh/devtoolset-3/root/usr/libexec/gcc/x86_64-redhat-linux/4.9.2/ld:
lxdialog/checklist.o: undefined reference to symbol 'acs_map'
//lib64/libtinfo.so.5: error adding symbols: DSO missing from command
line
collect2: error: ld returned 1 exit status
make[1]: *** [mconf] Error 1
make -s -C scripts/config all CC=gcc -Wl,--copy-dt-needed-entries: build
failed. Please re-run make with -j1 V=s to see what's going on
make: *** [scripts/config/mconf] Error 1
make: Leaving directory `/work/openwrt/openwrt/build'
Signed-off-by: 李国
---
include/verbose.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/verbose.mk b/include/verbose.mk
index b7e43f7430..e02aefe8dd 100644
--- a/include/verbose.mk
+++ b/include/verbose.mk
@@ -54,7 +54,7 @@ ifeq ($(findstring s,$(OPENWRT_VERBOSE)),)
else
SILENT:=>/dev/null $(if $(findstring w,$(OPENWRT_VERBOSE)),,2>&1)
export QUIET:=1
- SUBMAKE=cmd() { $(SILENT) $(MAKE) -s $$* < /dev/null || { echo
"make $$*: build failed. Please re-run make with -j1 V=s to see
what's going on"; false; } } 8>&1 9>&2; cmd
+ SUBMAKE=cmd() { $(SILENT) $(MAKE) -s "$$@" < /dev/null || { echo
"make $$*: build failed. Please re-run make with -j1 V=s to see
what's going on"; false; } } 8>&1 9>&2; cmd
endif
.SILENT: $(MAKECMDGOALS)
I've just successfully ran make menuconfig on centos 6 with devtoolset-3
$ rpm -qa | grep devtoolset
devtoolset-3-runtime-3.1-12.el6.x86_64
devtoolset-3-libstdc++-devel-4.9.2-6.2.el6.x86_64
devtoolset-3-gcc-4.9.2-6.2.el6.x86_64
devtoolset-3-binutils-2.24-18.el6.x86_64
devtoolset-3-gcc-c++-4.9.2-6.2.el6.x86_64
$ scl enable devtoolset-3 bash
$ make menuconfig
*** End of the configuration.
*** Execute 'make' to start the build or try 'make help'.
Regards
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
I meant to say I've successfully built a target on centos 6 with
devtoolset-3
Regards
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] verbose.mk: quote SUBMAKE options
On 06.07.2018 17:23, guo li wrote: Hi Lucian Cristian you may try run command $ scl enable devtoolset-3 bash $ make menuconfig with clean source. gcc has linked to staging_dir/host/bin when you first run make and mconf has built when you first run make menuconfig. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel you are right, tried a new clean tree and /opt/rh/devtoolset-3/root/usr/libexec/gcc/x86_64-redhat-linux/4.9.2/ld: lxdialog/checklist.o: undefined reference to symbol 'acs_map' Regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] time command detect fail on centos
On 07.07.2018 11:23, 李国 wrote: maybe $(shell which time) --version 2>&1 | grep GNU works good on centos6 Regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[patch] elfutils: enable host build
frr 8.0 needs host libelf dev add option for host build tested on x86, ramips, kirkwood Signed-off-by: Lucian Cristian diff --git a/package/libs/elfutils/Makefile b/package/libs/elfutils/Makefile index d595e4caf2..b0c9b8bd8c 100644 --- a/package/libs/elfutils/Makefile +++ b/package/libs/elfutils/Makefile @@ -26,6 +26,7 @@ PKG_BUILD_DEPENDS:=!USE_GLIBC:argp-standalone include $(INCLUDE_DIR)/package.mk include $(INCLUDE_DIR)/nls.mk +include $(INCLUDE_DIR)/host-build.mk define Package/elfutils/Default SECTION:=libs @@ -60,6 +61,12 @@ else CONFIGURE_ARGS += --disable-nls endif +HOST_CONFIGURE_ARGS += \ + --disable-debuginfod \ + --disable-libdebuginfod \ + --without-lzma \ + --without-zstd + CONFIGURE_ARGS += \ --program-prefix=eu- \ --disable-debuginfod \ @@ -97,6 +104,7 @@ define Package/libelf/install endef # these lines need to be ordered by dependency because of ABI versioning +$(eval $(call HostBuild)) $(eval $(call BuildPackage,libelf)) $(eval $(call BuildPackage,libdw)) $(eval $(call BuildPackage,libasm)) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [patch] elfutils: enable host build
On 31.08.2021 10:04, Lucian Cristian wrote: frr 8.0 needs host libelf dev add option for host build tested on x86, ramips, kirkwood Signed-off-by: Lucian Cristian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel Bump for this basic patch Regards, Lucian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Kernel hang on rk3328 at branch master
On 02.05.2020 14:46, b.l.huang wrote: Hi all, Hi all, I am trying to run openwrt on rk3328, but the kernel hanged when booting, below is the log. Any hints will be appreciated. U-Boot 2020.01 (Apr 07 2020 - 11:55:14 +) Model: Radxa Rockpi E DRAM: 1022 MiB PMIC: RK8050 (on=0x40, off=0x00) MMC: rksdmmc@ff50: 1, rksdmmc@ff52: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment In: serial@ff13 Out: serial@ff13 Err: serial@ff13 Model: Radxa Rockpi E Net: eth0: ethernet@ff54 Hit any key to stop autoboot: 0 Card did not respond to voltage select! switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... Found /extlinux/extlinux.conf Retrieving file: /extlinux/extlinux.conf 205 bytes read in 7 ms (28.3 KiB/s) 1: kernel-5.4 Retrieving file: /Image 7485448 bytes read in 330 ms (21.6 MiB/s) append: earlycon=uart8250,mmio32,0xff13 console=ttyS2,150n8 rw root=PARTUUID=b921b045-1d rootwait rootfstype=ext4 init=/sbin/init Retrieving file: /rk3328-rockpi-e.dtb 33554 bytes read in 8 ms (4 MiB/s) ## Flattened Device Tree blob at 01f0 Booting using the fdt blob at 0x1f0 Loading Device Tree to 3df1d000, end 3df28311 ... OK Starting kernel ... [ 0.00] Booting Linux on physical CPU 0x00 [0x410fd034] [ 0.00] Linux version 5.4.28 (rockpi@rockpi-dev) (gcc version 8.4.0 (OpenWrt GCC 8.4.0 r12776-437eb41f23)) #0 SMP Tue Apr 7 11:55:14 2020 [ 0.00] Machine model: Radxa ROCK Pi E [ 0.00] earlycon: uart8250 at MMIO32 0xff13 (options '') [ 0.00] printk: bootconsole [uart8250] enabled [ 0.00] psci: probing for conduit method from DT. [ 0.00] psci: PSCIv1.0 detected in firmware. [ 0.00] psci: Using standard PSCI v0.2 function IDs [ 0.00] psci: MIGRATE_INFO_TYPE not supported. [ 0.00] psci: SMC Calling Convention v1.0 [ 0.00] percpu: Embedded 19 pages/cpu s38424 r8192 d31208 u77824 [ 0.00] Detected VIPT I-cache on CPU0 [ 0.00] Built 1 zonelists, mobility grouping on. Total pages: 257544 [ 0.00] Kernel command line: earlycon=uart8250,mmio32,0xff13 console=ttyS2,150n8 rw root=PARTUUID=b921b045-1d rootwait rootfstype=ext4 init=/sbin/init [ 0.00] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear) [ 0.00] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes, linear) [ 0.00] mem auto-init: stack:off, heap alloc:off, heap free:off [ 0.00] Memory: 1018444K/1046528K available (5054K kernel code, 334K rwdata, 1244K rodata, 640K init, 281K bss, 28084K reserved, 0K cma-reserved) [ 0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [ 0.00] rcu: Hierarchical RCU implementation. [ 0.00] rcu: CONFIG_RCU_FANOUT set to non-default value of 32. [ 0.00] rcu: RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=4. [ 0.00] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies. [ 0.00] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 [ 0.00] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0 [ 0.00] GIC: Using split EOI/Deactivate mode [ 0.00] random: get_random_bytes called from start_kernel+0x2dc/0x450 with crng_init=0 [ 0.00] arch_timer: cp15 timer(s) running at 24.00MHz (phys). [ 0.00] clocksource: arch_sys_counter: mask: 0xff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns [ 0.07] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns [ 0.001345] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=96000) [ 0.002323] pid_max: default: 32768 minimum: 301 [ 0.002957] Mount-cache hash table entries: 2048 (order: 2, 16384 bytes, linear) [ 0.003632] Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes, linear) [ 0.006152] ASID allocator initialised with 32768 entries [ 0.006805] rcu: Hierarchical SRCU implementation. [ 0.008023] smp: Bringing up secondary CPUs ... [ 0.009010] Detected VIPT I-cache on CPU1 [ 0.009084] CPU1: Booted secondary processor 0x01 [0x410fd034] [ 0.009735] Detected VIPT I-cache on CPU2 [ 0.009789] CPU2: Booted secondary processor 0x02 [0x410fd034] [ 0.010386] Detected VIPT I-cache on CPU3 [ 0.010435] CPU3: Booted secondary processor 0x03 [0x410fd034] [ 0.010530] smp: Brought up 1 node, 4 CPUs [ 0.013785] SMP: Total of 4 processors activated. [ 0.014213] CPU features: detected: 32-bit EL0 Support [ 0.014680] CPU features: detected: CRC32 instructions [ 0.015226] CPU features: emulated: Privileged Access Never (PAN) using TTBR0_EL1 switching [ 0.015980] CPU: All CPU(s) started at EL2 [ 0.016372] alternatives: patching kernel code [ 0.027185] clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 764504178510 ns [ 0.028128] futex hash table entries: 1024 (order: 4, 65536 bytes, linear) [ 0.028981] pinctrl core: in
Re: [OpenWrt-Devel] [PATCH] gemini: Add samba4 to the NAS images
On 18.05.2020 16:04, Linus Walleij wrote: We used to have samba36 as a package in the NAS images but that was retired in commit 73fa1aba94f5 "samba36: Remove" however it is nice to have a fileserver so put samba4 in the package instead. Signed-off-by: Linus Walleij --- target/linux/gemini/image/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/gemini/image/Makefile b/target/linux/gemini/image/Makefile index a155939b8cd6..17e07897af04 100644 --- a/target/linux/gemini/image/Makefile +++ b/target/linux/gemini/image/Makefile @@ -141,7 +141,7 @@ GEMINI_NAS_PACKAGES := $(DEFAULT_PACKAGES.nas) \ kmod-fs-btrfs kmod-fs-cifs kmod-fs-nfs \ kmod-fs-nfsd kmod-fs-ntfs kmod-fs-reiserfs kmod-fs-vfat \ kmod-nls-utf8 kmod-usb-storage-extras kmod-hwmon-drivetemp \ - cfdisk e2fsprogs badblocks \ + cfdisk e2fsprogs badblocks samba4-server \ partx-utils # The DIR-685 flash layout is kernel in WRGG format, padded and followed Hi, samba4 is not in the main repo and there was an attempt for ksmbd-tools to be ported on main repo, it's faster and smaller Regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Remove x86/generic target
On 03.05.2025 23:48, Stefan Lippers-Hollmann via openwrt-devel wrote: 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. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel Mainly for Via CPUs on some industrial or Wyse systems that have AES hardware acceleration Regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
