Re: [PATCH] gmp: compile with -DPIC to use correct asm code
> On Mar 19, 2021, at 4:06 PM, Eneas U de Queiroz wrote: > > On Fri, Mar 19, 2021 at 5:08 PM Philip Prindeville > wrote: >> >> >> Maybe I'm missing something, but why not just fix rules.mk: >> >> >> ifneq (,$(findstring $(ARCH) , aarch64 aarch64_be powerpc )) >> FPIC:=-fPIC >> else >> FPIC:=-fpic >> endif >> >> HOST_FPIC:=-fPIC >> >> >> To have the FPIC and HOST_FPIC definitions include -DPIC? > > I think it would be the proper way to handle this. I was initially > fearful of changing too much and breaking things, but I think it > should be expected behaviour. What else would you use a 'PIC' > definition for? I will resend a patch changing rules.mk instead. Just saw this... Turns out that this would break a couple of packages (both in openwrt and in packages), so I've included those as well. -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/1] build: make sure asm gets built with -DPIC
From: Philip Prindeville Fixes issue #14921, whereby inline ASM wasn't getting built as PIC; look at gmp-6.2.1/mpn/x86/pentium/popcount.asm for example: ifdef(`PIC',` ... for a routine that exists in both PIC and non-PIC versions. Make sure that wherever $(FPIC) gets passed as a variable expansion that it gets quoted where necessary (such as setting environment variables in shell commands). Signed-off-by: Philip Prindeville --- package/libs/libnfnetlink/Makefile | 4 ++-- rules.mk | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/package/libs/libnfnetlink/Makefile b/package/libs/libnfnetlink/Makefile index 7d65d6385784e3d418f714386efe505b905c3b3e..bc64ff111d1f37e64463d519736d013679ccebf0 100644 --- a/package/libs/libnfnetlink/Makefile +++ b/package/libs/libnfnetlink/Makefile @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=libnfnetlink PKG_VERSION:=1.0.1 -PKG_RELEASE:=3 +PKG_RELEASE:=4 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2 PKG_SOURCE_URL:= \ @@ -45,7 +45,7 @@ CONFIGURE_ARGS += \ --enable-shared CONFIGURE_VARS += \ - lt_prog_compiler_pic=$(FPIC) + lt_prog_compiler_pic="$(FPIC)" define Build/InstallDev $(INSTALL_DIR) $(1)/usr/include/libnfnetlink diff --git a/rules.mk b/rules.mk index 8dee9e8489ac81ee524ca096e38355cea9730368..cb165f954892578f7c11e872d1ff921c96df90da 100644 --- a/rules.mk +++ b/rules.mk @@ -76,12 +76,12 @@ IS_PACKAGE_BUILD := $(if $(filter package/%,$(BUILD_SUBDIR)),1) OPTIMIZE_FOR_CPU=$(subst i386,i486,$(ARCH)) ifneq (,$(findstring $(ARCH) , aarch64 aarch64_be powerpc )) - FPIC:=-fPIC + FPIC:=-DPIC -fPIC else - FPIC:=-fpic + FPIC:=-DPIC -fpic endif -HOST_FPIC:=-fPIC +HOST_FPIC:=-DPIC -fPIC ARCH_SUFFIX:=$(call qstrip,$(CONFIG_CPU_TYPE)) GCC_ARCH:= -- 2.25.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] gmp: compile with -DPIC to use correct asm code
On Fri, Mar 19, 2021 at 5:08 PM Philip Prindeville wrote: > > > Maybe I'm missing something, but why not just fix rules.mk: > > > ifneq (,$(findstring $(ARCH) , aarch64 aarch64_be powerpc )) > FPIC:=-fPIC > else > FPIC:=-fpic > endif > > HOST_FPIC:=-fPIC > > > To have the FPIC and HOST_FPIC definitions include -DPIC? I think it would be the proper way to handle this. I was initially fearful of changing too much and breaking things, but I think it should be expected behaviour. What else would you use a 'PIC' definition for? I will resend a patch changing rules.mk instead. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] gmp: compile with -DPIC to use correct asm code
> On Mar 12, 2021, at 6:25 AM, Felix Fietkau wrote: > > > On 2021-03-12 11:34, Stijn Tintel wrote: >> On 11/03/2021 23:46, Eneas U de Queiroz wrote: >>> The library is always compiled with $(FPIC) (-fPIC or -fpic), even for >>> the static library. >>> >>> There are some assembly sources that decide whether or not to enable >>> PIC code by checking if PIC is defined. It counts on libtool to define >>> it, but libtool does it only when producing code for the dynamic >>> library, while we need it for both. >>> >>> Ensure it is defined by adding it to CFLAGS next to $(FPIC). >>> >>> It avoids linking errors with strongswan on x86_64: >>> >>> ld: libgmp.a(bdiv_q_1.o): relocation R_X86_64_PC32 against symbol >>> `__gmp_binvert_limb_table' can not be used when making a shared object; >>> recompile with -fPIC >>> >>> Cc: Stijn Tintel >>> Signed-off-by: Eneas U de Queiroz >>> --- >>> >>> There's an error on one architecture, and all others work fine without >>> this, so I'm uneasy changing this and then breaking stuff that was >>> working fine otherwise. However, it feels wrong to me to generate PIC >>> code from C files, but not use it in asm sources, which is essentially >>> what I am changing here. >>> >>> I've looked at asm sources for different chitectures, and there are >>> checks for PIC in: arm64, arm, x86_64, x86, and ppc asm sources, but the >>> error only appears on x86_64. >>> >>> For most CPUs, ifdef(`PIC'), is just used to do different definitions of >>> LEA (Load Effective Address). However, both x86 and x86_64 have many >>> other checks. >>> >>> I've looked at bdiv_q_1.asm for different CPUs, and they all do some >>> form of LEA(binvert_limb_table), except for x86, where it will do it >>> only when PIC is defined. That may explain why x86_64 is affected, and >>> x86 is not. >>> >>> I have not investigated further details. >>> >>> Alternatively, we can define it only for x86_64, which is where we know >>> there's a build failure with the linker asking to recompile with -fPIC. >>> >> I'm sorry, but I lack the knowledge to review this. > > I think the patch makes sense and -DPIC should be used along with -fPIC. > I don't see any reason to make it x86_64 specific. > > - Felix Maybe I'm missing something, but why not just fix rules.mk: ifneq (,$(findstring $(ARCH) , aarch64 aarch64_be powerpc )) FPIC:=-fPIC else FPIC:=-fpic endif HOST_FPIC:=-fPIC To have the FPIC and HOST_FPIC definitions include -DPIC? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Bumping firewall3 to latest
David, Yousong: Can we get a bump of firewall3 to HEAD again please? Thanks ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: RT3662 NAND support
On 2021-03-19 12:06, Andreas Böhler wrote: Hey Mika, On 19/03/2021 11:12, Mika Laitio wrote: I'm trying to add support for an older ZWave bridge, the MiCasaVerde Vera Lite (similar or equal to SERCOMM NA300). It's based on RT3662, 64MB RAM and 32MB NAND flash - and this is where I'm currently stuck. The rt3883.dtsi does not define a NAND controller and I'm unsure whether there actually is a suitable driver. Hi little of topic but are there some z-wave bridges that are already supported by the openwrt? And if you boot openwrt to vera lite via USB, are you able to see/use the z-wave controller from that device? I can give you a partial answer: I'm also working on the SERCOMM NA502 and NA502s that are also sold as Vera Secure, Smart Home by Hornbach, A1 Smart Home Gateway and a few other brands (I have the A1 branded version). Basically, I've got ZWave running, you can track the status here: https://forum.openwrt.org/t/adding-support-for-sercomms-na502/22495 Regarding the Vera Lite, I'm still investigating the possibilities and have not yet booted any custom firmware. I don't see a reason why the ZWave controller shouldn't be visible (it's attached to a UART). However, I found only limited information in whether this particular controller is supported by OpenZWave or Z-Wave JS. My ultimate goal with both SERCOMM devices is getting ZWaveJS2MQTT running so that a home automation software can talk to the gateway. Or you can also just buy an usb based aoetech z-stick or similar and use that instead, for example on a pi. It is already working well with zwavejs2mqtt plus home assistant and doesn't need any hw/sw hacking to get it working so probably less effort but of course costs a little compared to something you might already have. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] fstools/overlay: allow forced zstd compression
While forced zlib compression is already supported, zstd is much faster at the same compression ratios. Prepare fstools to mount the overlay with forced zstd compression, This is already supported in ubifs, while there's a pending patch for jffs2 [1]. [1] https://lore.kernel.org/linux-mtd/20210316141916.447493-1-rsalvate...@gmail.com/ Signed-off-by: Rui Salvaterra --- CMakeLists.txt | 2 ++ libfstools/overlay.c | 2 ++ 2 files changed, 4 insertions(+) diff --git a/CMakeLists.txt b/CMakeLists.txt index 422f27d..3dbc1da 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -58,6 +58,8 @@ INSTALL(FILES libubi/libubi-tiny.h libubi/libubi.h libubi/ubi-media.h IF(DEFINED CMAKE_OVL_MOUNT_COMPRESS_ZLIB) ADD_DEFINITIONS(-DOVL_MOUNT_COMPRESS_ZLIB) +ELSEIF(DEFINED CMAKE_OVL_MOUNT_COMPRESS_ZSTD) + ADD_DEFINITIONS(-DOVL_MOUNT_COMPRESS_ZSTD) ENDIF(DEFINED CMAKE_OVL_MOUNT_COMPRESS_ZLIB) IF(DEFINED CMAKE_OVL_MOUNT_FULL_ACCESS_TIME) diff --git a/libfstools/overlay.c b/libfstools/overlay.c index eadafcf..db083d4 100644 --- a/libfstools/overlay.c +++ b/libfstools/overlay.c @@ -355,6 +355,8 @@ static int overlay_mount_fs(struct volume *v) #endif #ifdef OVL_MOUNT_COMPRESS_ZLIB "compr=zlib" +#elif OVL_MOUNT_COMPRESS_ZSTD + "compr=zstd" #else NULL #endif -- 2.31.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: RT3662 NAND support
Hey Mika, On 19/03/2021 11:12, Mika Laitio wrote: I'm trying to add support for an older ZWave bridge, the MiCasaVerde Vera Lite (similar or equal to SERCOMM NA300). It's based on RT3662, 64MB RAM and 32MB NAND flash - and this is where I'm currently stuck. The rt3883.dtsi does not define a NAND controller and I'm unsure whether there actually is a suitable driver. Hi little of topic but are there some z-wave bridges that are already supported by the openwrt? And if you boot openwrt to vera lite via USB, are you able to see/use the z-wave controller from that device? I can give you a partial answer: I'm also working on the SERCOMM NA502 and NA502s that are also sold as Vera Secure, Smart Home by Hornbach, A1 Smart Home Gateway and a few other brands (I have the A1 branded version). Basically, I've got ZWave running, you can track the status here: https://forum.openwrt.org/t/adding-support-for-sercomms-na502/22495 Regarding the Vera Lite, I'm still investigating the possibilities and have not yet booted any custom firmware. I don't see a reason why the ZWave controller shouldn't be visible (it's attached to a UART). However, I found only limited information in whether this particular controller is supported by OpenZWave or Z-Wave JS. My ultimate goal with both SERCOMM devices is getting ZWaveJS2MQTT running so that a home automation software can talk to the gateway. Andreas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: RT3662 NAND support
I'm trying to add support for an older ZWave bridge, the MiCasaVerde Vera Lite (similar or equal to SERCOMM NA300). It's based on RT3662, 64MB RAM and 32MB NAND flash - and this is where I'm currently stuck. The rt3883.dtsi does not define a NAND controller and I'm unsure whether there actually is a suitable driver. Hi little of topic but are there some z-wave bridges that are already supported by the openwrt? And if you boot openwrt to vera lite via USB, are you able to see/use the z-wave controller from that device? Mika ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: RT3662 NAND support
Hi Daniel, On 19/03/2021 01:52, Daniel Golle wrote: Hi Andreas, On Thu, Mar 18, 2021 at 10:42:35PM +0100, Andreas Böhler wrote: How can I best find/add a NAND driver for RT3662, or is it not worth the effort? Good question, especially without the datasheet or any piece of code to look at. If you are up for a lot of hard work, a starting point could be here: https://github.com/openwrt/openwrt/pull/597 MT7620 was the successor of those SoCs, I would guess the NAND controller is probably very similar to this one. MT7621 is a more different design of NAND controller which came after, and as you can see in the PR, the "old" MT7620 NAND was never cleaned up nor merged into OpenWrt. For you it could still be worth the shot, if you find the full datasheet of RT3662 somewhere you can compare with MT7620 (which is easy to find). Unfortunately, you just confirmed my suspicion that there is no easy way to have NAND support. My impression is that there is very little interest in these older Vera devices, so I'll go for initramfs + extroot for now (fortunately, there is a USB port). Regards, Andreas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Buildbot infrastructure upgrade
Petr Štetiar kirjoitti 19.3.2021 klo 8.39: Hannu Nyman [2021-03-18 19:52:18]: Petr Štetiar kirjoitti 18.3.2021 klo 12.12: I'm still not that happy with the round-robin scheduler[1], but it's better then the previous state, so I'm going to deploy it soon to all masters. ... 1. https://github.com/buildbot/buildbot/issues/4592#issuecomment-801163587 I noticed that the master packages buildbot just started a new mips64_octeonplus build, but only removed one of the pending build requests (9 hours old) from the queue. The newer buildrequest 1344 that is 41 minutes old, is still in the queue. https://buildbot.openwrt.org/master/packages/#/builders/4 https://buildbot.openwrt.org/master/packages/#/pendingbuildrequests The same seems to have happened to i386_pentium-mmx (while I was writing this). So, a started build for a target does not always clear the build request queue, as intended. it looks like the issue in the scheduler/database update I've referenced and reported: 2021-03-18 17:32:12+ [-] prioritizeBuilders:mips64_octeonplus complete_at: 2021-03-16 12:50:30+00:00 2021-03-18 17:32:13+ [-] starting build using worker 2021-03-18 17:32:18+ [-] starting build .. pinging the worker 2021-03-18 17:56:30+ [-] prioritizeBuilders:mips64_octeonplus complete_at: 2021-03-16 12:50:30+00:00 2021-03-19 00:23:21+ [-] : build finished here previous build finishes, so the next complete_at should return time of 00:23:21, but it actually still returns the old timestamp: 2021-03-19 00:23:22+ [-] prioritizeBuilders:mips64_octeonplus complete_at: 2021-03-16 12:50:30+00:00 so the build is considered oldest and scheduled for build: 2021-03-19 00:23:24+ [-] starting build using worker 2021-03-19 00:23:31+ [-] starting build .. pinging the worker Cheers, Petr I think that this might the problem that rjarry tried to overcome with "cooldown_seconds" defined and set to 4 seconds in the discussion in the upstream buildbot issue you referenced. I think that he made the queue evaluation to wait for 4 seconds before actually starting, so that all asynchronous updates would have been written first. (I didn't look into logic too deeply, but that was my impression at the first glance.) We might try something similar, even set a bit longer waiting time. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Buildbot infrastructure upgrade
Hannu Nyman [2021-03-18 19:52:18]: > Petr Štetiar kirjoitti 18.3.2021 klo 12.12: > > > > I'm still not that happy with the round-robin scheduler[1], but it's > > better then the previous state, so I'm going to deploy it soon to all > > masters. > > > > ... > > > > 1. https://github.com/buildbot/buildbot/issues/4592#issuecomment-801163587 > > I noticed that the master packages buildbot just started a new > mips64_octeonplus build, but only removed one of the pending build requests > (9 hours old) from the queue. The newer buildrequest 1344 that is 41 minutes > old, is still in the queue. > > https://buildbot.openwrt.org/master/packages/#/builders/4 > https://buildbot.openwrt.org/master/packages/#/pendingbuildrequests > > The same seems to have happened to i386_pentium-mmx (while I was writing > this). > > So, a started build for a target does not always clear the build request > queue, as intended. it looks like the issue in the scheduler/database update I've referenced and reported: 2021-03-18 17:32:12+ [-] prioritizeBuilders:mips64_octeonplus complete_at: 2021-03-16 12:50:30+00:00 2021-03-18 17:32:13+ [-] starting build using worker 2021-03-18 17:32:18+ [-] starting build .. pinging the worker 2021-03-18 17:56:30+ [-] prioritizeBuilders:mips64_octeonplus complete_at: 2021-03-16 12:50:30+00:00 2021-03-19 00:23:21+ [-] : build finished here previous build finishes, so the next complete_at should return time of 00:23:21, but it actually still returns the old timestamp: 2021-03-19 00:23:22+ [-] prioritizeBuilders:mips64_octeonplus complete_at: 2021-03-16 12:50:30+00:00 so the build is considered oldest and scheduled for build: 2021-03-19 00:23:24+ [-] starting build using worker 2021-03-19 00:23:31+ [-] starting build .. pinging the worker Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
