Re: [OpenWrt-Devel] [PATCH] mvebu: fix the cortex-a9 fpu configure
On 30 August 2018 at 04:31, ayaka wrote: > Both Marvell Armada 37x and 38x support NEON and VFPv3, > so we enable the NEON FPU with the SIMD aliases. But the Armada XP doesn't, so this would break devices based on it (like the WRT1900AC v1). Regards Jonas > > Signed-off-by: ayaka > --- > include/target.mk | 1 + > target/linux/mvebu/cortexa9/target.mk | 2 +- > 2 files changed, 2 insertions(+), 1 deletion(-) > > diff --git a/include/target.mk b/include/target.mk > index 53d7436311..330eb175cc 100644 > --- a/include/target.mk > +++ b/include/target.mk > @@ -201,6 +201,7 @@ ifeq ($(DUMP),1) >CPU_CFLAGS_neon = -mfpu=neon >CPU_CFLAGS_vfp = -mfpu=vfp >CPU_CFLAGS_vfpv3 = -mfpu=vfpv3-d16 > + CPU_CFLAGS_simd = -mfpu=neon-vfpv3 >CPU_CFLAGS_neon-vfpv4 = -mfpu=neon-vfpv4 > endif >endif > diff --git a/target/linux/mvebu/cortexa9/target.mk > b/target/linux/mvebu/cortexa9/target.mk > index 2a75599bc9..9e6119bf6b 100644 > --- a/target/linux/mvebu/cortexa9/target.mk > +++ b/target/linux/mvebu/cortexa9/target.mk > @@ -10,5 +10,5 @@ include $(TOPDIR)/rules.mk > ARCH:=arm > BOARDNAME:=Marvell Armada 37x/38x/XP > CPU_TYPE:=cortex-a9 > -CPU_SUBTYPE:=vfpv3 > +CPU_SUBTYPE:=simd > KERNELNAME:=zImage dtbs > -- > 2.14.4 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] mvebu: fix the cortex-a9 fpu configure
Both Marvell Armada 37x and 38x support NEON and VFPv3, so we enable the NEON FPU with the SIMD aliases. Signed-off-by: ayaka --- include/target.mk | 1 + target/linux/mvebu/cortexa9/target.mk | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/include/target.mk b/include/target.mk index 53d7436311..330eb175cc 100644 --- a/include/target.mk +++ b/include/target.mk @@ -201,6 +201,7 @@ ifeq ($(DUMP),1) CPU_CFLAGS_neon = -mfpu=neon CPU_CFLAGS_vfp = -mfpu=vfp CPU_CFLAGS_vfpv3 = -mfpu=vfpv3-d16 + CPU_CFLAGS_simd = -mfpu=neon-vfpv3 CPU_CFLAGS_neon-vfpv4 = -mfpu=neon-vfpv4 endif endif diff --git a/target/linux/mvebu/cortexa9/target.mk b/target/linux/mvebu/cortexa9/target.mk index 2a75599bc9..9e6119bf6b 100644 --- a/target/linux/mvebu/cortexa9/target.mk +++ b/target/linux/mvebu/cortexa9/target.mk @@ -10,5 +10,5 @@ include $(TOPDIR)/rules.mk ARCH:=arm BOARDNAME:=Marvell Armada 37x/38x/XP CPU_TYPE:=cortex-a9 -CPU_SUBTYPE:=vfpv3 +CPU_SUBTYPE:=simd KERNELNAME:=zImage dtbs -- 2.14.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Use DHCP by default on single port devices
Hi, W dniu 2018-08-28 o 22:29, Michael Heimpold pisze: Hi, "DHCP Client", even with an alternative static IP address, might not work for some home users. to make this work better, some companies are choosing the static fallback IP address in the AutoIP range 169.254.x.x/16. At least Windows will fallback to this range if it does not find a DHCP server on this link; so it should at least possible to browse to the web gui and/or open a SSH connection... without reconfiguring your Windows system. I don't know whether this works out-of-the-box on Mac or usual Linux distros, too. At least on my Debian boxen, using NetworkManager, it does not. I have to select this type of autoconfiguration manually first. Regards, Michael ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel To me, adding of 2 separate mechanisms (mDNS, UPnP) on top of fixed IP address or APIPA sounds like a horrendous feature creep, just to replace one mechanism that works (DHCP). On my machines, I use none of the mechanisms. I don't like the idea of installing Avahi on Linux boxen, or enabling UPnP on Windows ones, just to get to my router/bridge/AP/whatever-runs-OpenWrt for initial configuration. When configuring the Ubiquiti bridges (for example Nanobridge M5) for the first time, while sitting on rooftop with my laptop only, DHCP works quite well - it is not a big effort to just disable it at the end of configuration. When doing testing on the ground, I usually have a router with DHCP server already available, so using it to assign IP to newly configured device might be useful, but it usually is not a big problem to temporarily connect Ethernet to the newly configured device, still having Wi-Fi connectivity. Also, there is another class of devices, beside "bridges". Travel routers, such as TP-Link WR703N. Having only one USB port it is clearly a router, having USB port dedicated for mobile broadband modem. Yet this is the most typical scenario. One might use it as an access point, or as weather station as well. Those configurations suit different types of address assignment method. Do we really need to make the distinction between them? Actually, when writing the above, one idea struck me. When starting, dnsmasq checks if there are no other DHCP servers present on the network, and if they are, it bails out. Maybe it would be possible to use IP assigned by authoritative DHCP server, if one is already present, otherwise startup DHCP as before. Still, this would be quite unusual behaviour, and this might have flaws I have yet to think of -- With kind regards, Lech ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] detecting liblua in CMake
Hi, I'm currently developing an application for OpenWRT. IT is written in C, and uses the LUA libraries. The C code is configured by CMake. The question is how can I detect, packages with CMake. At the host system, the application builds fine using CMake, and I have something similar in my CMakeLists: find_package(Lua 5.1) if (LUA_FOUND) include_directories("${LUA_INCLUDE_DIR}") target_link_libraries (${PROJECT_NAME} ${LUA_LIBRARIES}) endif () but this doesn't seem to work with the build system of OpenWRT. How can I detect liblua (libraries and include path, linker options, etc)? Thanks, Levente -- Levente Kovacs Senior Electronic Engineer W: http://levente.logonex.eu ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Use DHCP by default on single port devices
Hi, I've added a PR for a small mDNS daemon https://github.com/openwrt/openwrt/pull/1339 The init.d script is hackish and has race condition issues, suggestions to improve it would be highly appreciated. For some reason it doesn't seem to work during boot up :/ Best regards, Daniel On 2018-08-27 16:00, Alberto Bursi wrote: On 8/27/2018 12:37 PM, Daniel Engberg wrote: As per request, Fine as long as we fix mdns in some way? https://github.com/openwrt/openwrt/pull/1062 Not subscribed, so CC Best regards, Daniel Engberg ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel I agree with the proposal as phrased in the mailing list. it's either mdns installed by default + dhcp so people can reach the device by writing "OpenWrt.local" or something in the browser or it has to stay static IP. Just going to DHCP without any other easy mean to reach the device will only be annoying. Devices with a single port and low flash can stay with static IP to save space imho. -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel