[OpenWrt-Devel] [PATCH] mvebu: fix the cortex-a9 fpu configure

2018-08-29 Thread ayaka
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

2018-08-29 Thread Lech Perczak

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

2018-08-29 Thread Lev
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

2018-08-29 Thread Daniel Engberg

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