Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 3/5] tools: add iucode-tool

2018-01-17 Thread Syrone Wong 
There is another intel ucode generator in Archlinux repo, it seems the
code is more elegant and don't require additional dependency. Do you
have any idea?

https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/intel-ucode


Best Regards,
Syrone Wong


On Thu, Jan 18, 2018 at 3:41 AM, Zoltan HERPAI  wrote:
> Add tool to "compile" Intel microcode files. The tool will be
> compiled for host (to split the microcode.dat) and for target
> (to forcibly reload the microcode or scan the system if required).
>
> Signed-off-by: Zoltan HERPAI 
> ---
>  package/system/iucode-tool/Makefile | 47 
> +
>  1 file changed, 47 insertions(+)
>  create mode 100644 package/system/iucode-tool/Makefile
>
> diff --git a/package/system/iucode-tool/Makefile 
> b/package/system/iucode-tool/Makefile
> new file mode 100644
> index 000..4381a3a
> --- /dev/null
> +++ b/package/system/iucode-tool/Makefile
> @@ -0,0 +1,47 @@
> +#
> +# Copyright (C) 2018 OpenWrt.org
> +#
> +# This is free software, licensed under the GNU General Public License v2.
> +# See /LICENSE for more information.
> +#
> +
> +include $(TOPDIR)/rules.mk
> +
> +PKG_NAME:=iucode-tool
> +PKG_VERSION:=2.2
> +PKG_RELEASE:=1
> +
> +PKG_SOURCE:=iucode-tool_$(PKG_VERSION).tar.xz
> +PKG_SOURCE_URL:=https://gitlab.com/iucode-tool/releases/raw/latest
> +PKG_HASH:=9810daf925b8a9ca244adc4e1916bcab65601c9ebe87e91c2281f78055982971
> +
> +PKG_BUILD_DEPENDS:=USE_UCLIBC:argp-standalone USE_MUSL:argp-standalone
> +
> +PKG_MAINTAINER:=Zoltan HERPAI 
> +PKG_LICENSE:=GPL-2.0
> +
> +PKG_INSTALL:=1
> +
> +include $(INCLUDE_DIR)/package.mk
> +include $(INCLUDE_DIR)/host-build.mk
> +
> +define Package/iucode-tool
> +  SECTION:=utils
> +  CATEGORY:=Base system
> +  URL:=$(PKG_SOURCE_URL)
> +  DEPENDS:=@TARGET_x86
> +  TITLE:=Intel microcode loader
> +endef
> +
> +define Package/iucode-tool/install
> +   $(INSTALL_DIR) $(1)/lib/firmware
> +   $(INSTALL_DIR) $(1)/usr/bin
> +   $(INSTALL_BIN) $(PKG_BUILD_DIR)/iucode_tool $(1)/usr/bin/
> +endef
> +
> +define Host/Install
> +   $(INSTALL_BIN) $(HOST_BUILD_DIR)/iucode_tool 
> $(STAGING_DIR_HOST)/bin/iucode_tool
> +endef
> +
> +$(eval $(call HostBuild))
> +$(eval $(call BuildPackage,iucode-tool))
> --
> 1.9.1
> ___
> openwrt-devel mailing list
> openwrt-de...@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/5] x86: add support for microcode update

2018-01-17 Thread Florian Fainelli 
On January 17, 2018 11:41:01 AM PST, Zoltan HERPAI  wrote:
>Hi,
>
>This series will add support for microcode update on x86 targets,
>in light of the recent security issues.
>
>While other distributions use an early initramfs approach to update 
>the microcode as early as possible, in OpenWrt the earliest place
>where we can do this is preinit.
>
>The Intel microcode package is using the source package by Debian,
>the AMD microcode package is downloaded from the linux-firmware 
>git repository.
>
>This was tested on various Intel-based desktops with ancient BIOSes.
>
>Once the series is merged into trunk, this could/should be backported
>into 17.01 and 15.05 without too much hassle.

FWIW:

Reviewed-by: Florian Fainelli 

-- 
Florian

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] TDR / VeriPHY

2018-01-17 Thread Florian Fainelli 
On January 17, 2018 6:06:54 PM PST, "Denis Periša"  wrote:
>Hi all,
>
>I've searched three days in a row and I cannot find any more info on
>software cable tester for linux/openwrt.
>
>Many my devices support this feature as in original firmware (Mikrotik
>for example) I can see cable pairs and which cable wire is not
>connected and such. Even length of the cable. Airlive devices have as
>low as 2mb firmware space and they have this included in web gui.
>
>How come none openwrt/lede is capable of doing this? too hardware
>specific or?

Yes, too hardware specific, and most often no reference code and documentation 
to implement it. TDR in the PHY products that I am familiar with require a ton 
of register reads and writes. Do you know what kind of PHYs they use? Most PHYs 
have a simple cable diagnostics register set which give you basic stuff: 
length, pair status etc. doing actual TDR is more complicated and involved.
Let
-- 
Florian

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] TDR / VeriPHY

2018-01-17 Thread Denis Periša 
Hi all,

I've searched three days in a row and I cannot find any more info on
software cable tester for linux/openwrt.

Many my devices support this feature as in original firmware (Mikrotik
for example) I can see cable pairs and which cable wire is not
connected and such. Even length of the cable. Airlive devices have as
low as 2mb firmware space and they have this included in web gui.

How come none openwrt/lede is capable of doing this? too hardware specific or?

Thank you.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] ipq806x Netgear R7500 uboot

2018-01-17 Thread Matthew McClintock 
On Wed, Jan 17, 2018 at 4:28 AM, Thomas Reifferscheid
 wrote:
> Hi, I've lost my original uboot environment settings and would like to ask
> for your help.
> Since it's been a while from when I was playing with the hardware the uboot
> env is all messed up and I'd like to start over from scratch.
>
> Would someone please send me "env print" from within the bootloader from any
> ipq806x, preferrably Netgear R7500 but anything close would probably do.

Does resetting it to default not work? What are you trying to do? Most
IPQ boards have a custom u-boot command callde bootipq that will boot
the board from some semi-default flash configuration assuming all
other things are sane.

-M

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] DDNS for ipv6

2018-01-17 Thread Christian Schoenebeck 


Am 16.01.2018 um 21:07 schrieb e9hack:
> Hi Christian,
> 
> I revert all ddns related changes. It looks like that the changes are not the 
> root cause. I check my old log files. The
> issue did start with my build from 16th of December.
> 
> Independently of this, I'm the opinion, ddns for ipv6 can't work with a 
> deal-in or modem connection. My wan interface is
> pppoe-wan. If the logical interface wan_6 is started, it (or pppoe-wan) 
> doesn't have a global ipv6 address. It does only
> have a link local address. The global address is assigned later. If the ddns 
> script is started before the global address
> is assigned, the script will be stopped and never restart.

Is the an event (reported in syslog) when glocal IPv6 assigned which possibly 
can be used to (re)activate ddns-scripts?
Is the IPv6 assigned by the provider via dhcpv6 request?

> 
> Regards,
> Hartmut
> 
> Am 15.01.2018 um 21:44 schrieb Christian Schoenebeck:
>> Hi Hartmut,
>>
>> either try newest scripts from github (updated last weekend)
>>
>> or insert "network_flush_cache" at about line 900 inside 
>> dynamic_dns_functions.sh function get_local_ip()
>>
>>  while : ; do
>>  if [ -n "$ip_network" ]; then
>>  # set correct program
>> -->> network_flush_cache # force re-read data from ubus
>>  [ $use_ipv6 -eq 0 ] && __RUNPROG="network_get_ipaddr" \
>>  || __RUNPROG="network_get_ipaddr6"
>>
>> or set option ip_source  "interface" instead of "network"
>>
>> Christian
>>
>>
>> Am 15.01.2018 um 18:39 schrieb e9hack:
>>> Hi,
>>>
>>> ddns for ipv6 doesn't work since the last few updates related to the ddns 
>>> package. From log file:
>>>
>>> Mon Jan 15 17:35:21 2018 user.notice DEBUG: hotplug igmpproxy: device 
>>> 'wan_6' action 'ifup'
>>> Mon Jan 15 17:35:22 2018 user.notice ddns-scripts[7394]: dynv6_ipv6: PID 
>>> '7394' started at 2018-01-15 17:35
>>> Mon Jan 15 17:35:23 2018 user.err ddns-scripts[7394]: dynv6_ipv6: Can not 
>>> detect local IP using network_get_ipaddr6
>>> 'wan_6' - Error: '1' - TERMINATE
>>> Mon Jan 15 17:35:23 2018 user.warn ddns-scripts[7394]: dynv6_ipv6: PID 
>>> '7394' exit WITH ERROR '1' at 2018-01-15 17:35
>>>
>>> This is immediately after a sysupgrade. Restarting of the service brings it 
>>> back.
>>>
>>> Ddns provider is dynv6.com.
>>>
>>> Regards,
>>> Hartmut
>>>
>>
> 
> 

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH 4/5] firmware: add microcode package for Intel

2018-01-17 Thread Zoltan HERPAI 
Compiling the Intel microcode package results in a
microcode.bin and a microcode-64.bin. As we can
decide based on the subtarget which should be used,
we'll only split the required .bin file with
iucode-tool.

Instead of using the large microcode.bin/microcode-64.bin, the
splitted ucode files (separate for CPU families) will be
installed.
 
The microcodes are updated from preinit - that's the
earliest place where we can do it.

Signed-off-by: Zoltan HERPAI 
---
 package/firmware/intel-microcode/Makefile  | 51 ++
 .../intel-microcode/files/intel-microcode.preinit  |  8 
 2 files changed, 59 insertions(+)
 create mode 100644 package/firmware/intel-microcode/Makefile
 create mode 100644 
package/firmware/intel-microcode/files/intel-microcode.preinit

diff --git a/package/firmware/intel-microcode/Makefile 
b/package/firmware/intel-microcode/Makefile
new file mode 100644
index 000..0af900c
--- /dev/null
+++ b/package/firmware/intel-microcode/Makefile
@@ -0,0 +1,51 @@
+#
+# Copyright (C) 2018 OpenWrt.org
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=intel-microcode
+PKG_VERSION:=20171215
+PKG_RELEASE:=1
+
+PKG_SOURCE:=intel-microcode_3.$(PKG_VERSION).$(PKG_RELEASE).tar.xz
+PKG_SOURCE_URL:=http://ftp.debian.org/debian/pool/non-free/i/intel-microcode/
+PKG_HASH:=eca8efc0a6dc456a8723204477e229577c1079fa5c1a10b6ba95d11e261ffa4d
+PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)-3.$(PKG_VERSION).$(PKG_RELEASE)
+
+PKG_BUILD_DEPENDS:=iucode-tool/host
+
+ifdef CONFIG_TARGET_x86_64
+   MICROCODE:="intel-microcode-64"
+else
+   MICROCODE:="intel-microcode"
+endif
+
+include $(INCLUDE_DIR)/package.mk
+
+define Package/intel-microcode
+  SECTION:=firmware
+  CATEGORY:=Firmware
+  URL:=$(PKG_SOURCE_URL)
+  DEPENDS:=@TARGET_x86 +iucode-tool
+  TITLE:=Intel x86 CPU microcode
+endef
+
+define Build/Compile
+   IUCODE_TOOL=$(STAGING_DIR)/../host/bin/iucode_tool $(MAKE) -C 
$(PKG_BUILD_DIR)
+   mkdir $(PKG_BUILD_DIR)/intel-ucode
+   $(STAGING_DIR)/../host/bin/iucode_tool -q \
+   --write-firmware=$(PKG_BUILD_DIR)/intel-ucode 
$(PKG_BUILD_DIR)/$(MICROCODE).bin
+endef
+
+define Package/intel-microcode/install
+   $(INSTALL_DIR) $(1)/lib/firmware/intel-ucode
+   $(INSTALL_DATA) $(PKG_BUILD_DIR)/intel-ucode/* 
$(1)/lib/firmware/intel-ucode
+   $(INSTALL_DIR) $(1)/lib/preinit
+   $(INSTALL_BIN) ./files/intel-microcode.preinit 
$(1)/lib/preinit/02_load_intel_ucode
+endef
+
+$(eval $(call BuildPackage,intel-microcode))
diff --git a/package/firmware/intel-microcode/files/intel-microcode.preinit 
b/package/firmware/intel-microcode/files/intel-microcode.preinit
new file mode 100644
index 000..7f9279c
--- /dev/null
+++ b/package/firmware/intel-microcode/files/intel-microcode.preinit
@@ -0,0 +1,8 @@
+#!/bin/sh
+# Copyright (C) 2018 OpenWrt.org
+
+do_load_intel_ucode() {
+   echo 1 > /sys/devices/system/cpu/microcode/reload
+}
+
+boot_hook_add preinit_main do_load_intel_ucode
-- 
1.9.1


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH 0/5] x86: add support for microcode update

2018-01-17 Thread Zoltan HERPAI 
Hi,

This series will add support for microcode update on x86 targets,
in light of the recent security issues.

While other distributions use an early initramfs approach to update 
the microcode as early as possible, in OpenWrt the earliest place
where we can do this is preinit.

The Intel microcode package is using the source package by Debian,
the AMD microcode package is downloaded from the linux-firmware 
git repository.

This was tested on various Intel-based desktops with ancient BIOSes.

Once the series is merged into trunk, this could/should be backported
into 17.01 and 15.05 without too much hassle.

Thanks,
Zoltan H


Zoltan HERPAI (5):
  x86: enable microcode loading for Intel and AMD
  firmware: add microcode package for AMD64
  tools: add iucode-tool
  firmware: add microcode package for Intel
  packages: intel-microcode: update to 20180108

 package/firmware/intel-microcode/Makefile  | 51 ++
 .../intel-microcode/files/intel-microcode.preinit  |  8 
 package/firmware/linux-firmware/x86.mk |  9 
 package/system/iucode-tool/Makefile| 47 
 target/linux/x86/config-4.14   |  5 ++-
 target/linux/x86/config-4.9|  5 ++-
 6 files changed, 123 insertions(+), 2 deletions(-)
 create mode 100644 package/firmware/intel-microcode/Makefile
 create mode 100644 
package/firmware/intel-microcode/files/intel-microcode.preinit
 create mode 100644 package/firmware/linux-firmware/x86.mk
 create mode 100644 package/system/iucode-tool/Makefile

-- 
1.9.1


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH 1/5] x86: enable microcode loading for Intel and AMD

2018-01-17 Thread Zoltan HERPAI 
Enable for 4.9 and 4.14.

Signed-off-by: Zoltan HERPAI 
---
 target/linux/x86/config-4.14 | 5 -
 target/linux/x86/config-4.9  | 5 -
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/target/linux/x86/config-4.14 b/target/linux/x86/config-4.14
index b88fa77..9ea0d90 100644
--- a/target/linux/x86/config-4.14
+++ b/target/linux/x86/config-4.14
@@ -313,7 +313,10 @@ CONFIG_M586MMX=y
 # CONFIG_MFD_INTEL_LPSS_PCI is not set
 # CONFIG_MGEODEGX1 is not set
 # CONFIG_MGEODE_LX is not set
-# CONFIG_MICROCODE is not set
+CONFIG_MICROCODE=y
+CONFIG_MICROCODE_AMD=y
+CONFIG_MICROCODE_INTEL=y
+CONFIG_MICROCODE_OLD_INTERFACE=y
 # CONFIG_MK6 is not set
 # CONFIG_MK7 is not set
 # CONFIG_MK8 is not set
diff --git a/target/linux/x86/config-4.9 b/target/linux/x86/config-4.9
index b500354..554e696 100644
--- a/target/linux/x86/config-4.9
+++ b/target/linux/x86/config-4.9
@@ -290,7 +290,10 @@ CONFIG_M586MMX=y
 # CONFIG_MFD_INTEL_LPSS_PCI is not set
 # CONFIG_MGEODEGX1 is not set
 # CONFIG_MGEODE_LX is not set
-# CONFIG_MICROCODE is not set
+CONFIG_MICROCODE=y
+CONFIG_MICROCODE_AMD=y
+CONFIG_MICROCODE_INTEL=y
+CONFIG_MICROCODE_OLD_INTERFACE=y
 # CONFIG_MK6 is not set
 # CONFIG_MK7 is not set
 # CONFIG_MK8 is not set
-- 
1.9.1


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH 3/5] tools: add iucode-tool

2018-01-17 Thread Zoltan HERPAI 
Add tool to "compile" Intel microcode files. The tool will be
compiled for host (to split the microcode.dat) and for target
(to forcibly reload the microcode or scan the system if required).

Signed-off-by: Zoltan HERPAI 
---
 package/system/iucode-tool/Makefile | 47 +
 1 file changed, 47 insertions(+)
 create mode 100644 package/system/iucode-tool/Makefile

diff --git a/package/system/iucode-tool/Makefile 
b/package/system/iucode-tool/Makefile
new file mode 100644
index 000..4381a3a
--- /dev/null
+++ b/package/system/iucode-tool/Makefile
@@ -0,0 +1,47 @@
+#
+# Copyright (C) 2018 OpenWrt.org
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=iucode-tool
+PKG_VERSION:=2.2
+PKG_RELEASE:=1
+
+PKG_SOURCE:=iucode-tool_$(PKG_VERSION).tar.xz
+PKG_SOURCE_URL:=https://gitlab.com/iucode-tool/releases/raw/latest
+PKG_HASH:=9810daf925b8a9ca244adc4e1916bcab65601c9ebe87e91c2281f78055982971
+
+PKG_BUILD_DEPENDS:=USE_UCLIBC:argp-standalone USE_MUSL:argp-standalone
+
+PKG_MAINTAINER:=Zoltan HERPAI 
+PKG_LICENSE:=GPL-2.0
+
+PKG_INSTALL:=1
+
+include $(INCLUDE_DIR)/package.mk
+include $(INCLUDE_DIR)/host-build.mk
+
+define Package/iucode-tool
+  SECTION:=utils
+  CATEGORY:=Base system
+  URL:=$(PKG_SOURCE_URL)
+  DEPENDS:=@TARGET_x86
+  TITLE:=Intel microcode loader
+endef
+
+define Package/iucode-tool/install
+   $(INSTALL_DIR) $(1)/lib/firmware
+   $(INSTALL_DIR) $(1)/usr/bin
+   $(INSTALL_BIN) $(PKG_BUILD_DIR)/iucode_tool $(1)/usr/bin/
+endef
+
+define Host/Install
+   $(INSTALL_BIN) $(HOST_BUILD_DIR)/iucode_tool 
$(STAGING_DIR_HOST)/bin/iucode_tool
+endef
+
+$(eval $(call HostBuild))
+$(eval $(call BuildPackage,iucode-tool))
-- 
1.9.1


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH 2/5] firmware: add microcode package for AMD64

2018-01-17 Thread Zoltan HERPAI 
Signed-off-by: Zoltan HERPAI 
---
 package/firmware/linux-firmware/x86.mk | 9 +
 1 file changed, 9 insertions(+)
 create mode 100644 package/firmware/linux-firmware/x86.mk

diff --git a/package/firmware/linux-firmware/x86.mk 
b/package/firmware/linux-firmware/x86.mk
new file mode 100644
index 000..2dfe7b0
--- /dev/null
+++ b/package/firmware/linux-firmware/x86.mk
@@ -0,0 +1,9 @@
+Package/amd64-microcode = $(call Package/firmware-default,AMD64 CPU microcode)
+define Package/amd64-microcode/install
+   $(INSTALL_DIR) $(1)/lib/firmware/amd-ucode
+   $(INSTALL_DATA) $(PKG_BUILD_DIR)/amd-ucode/microcode_amd.bin 
$(1)/lib/firmware/amd-ucode
+   $(INSTALL_DATA) $(PKG_BUILD_DIR)/amd-ucode/microcode_amd_fam15h.bin 
$(1)/lib/firmware/amd-ucode
+   $(INSTALL_DATA) $(PKG_BUILD_DIR)/amd-ucode/microcode_amd_fam16h.bin 
$(1)/lib/firmware/amd-ucode
+endef
+$(eval $(call BuildPackage,amd64-microcode))
+
-- 
1.9.1


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] A state of network acceleration

2018-01-17 Thread Pablo Neira Ayuso 
Hi Rafal,

On Wed, Jan 17, 2018 at 04:25:10PM +0100, Rafał Miłecki wrote:
> Getting better network performance (mostly for NAT) using some kind of
> acceleration was always a hot topic and people are still
> looking/asking for it. I'd like to write a short summary and share my
> understanding of current state so that:
> 1) People can undesrtand it better
> 2) We can have some rough plan
> 
> First of all there are two possible ways of accelerating network
> traffic: in software and in hardware. Software solution is independent
> of architecture/device and is mostly just bypassing in-kernel packets
> flow. It still uses device's CPU which can be a bottleneck. Various
> software implementations are reported to be faster from 2x to 5x.

This is what I've been observing for the software acceleration here,
see slide 19 at:

https://www.netdevconf.org/2.1/slides/apr8/ayuso-netdev-netfilter-updates-canada-2017.pdf

The flowtable representation, in software, is providing a faster
forwarding path between two nics. So it's basically an alternative to
the classic forwarding path, that is faster. Packets kick in at the
Netfilter ingress hook (right at the same location as 'tc' ingress),
if there is a hit in the software flowtable, ttl gets decremented,
NATs are done and the packet is placed in the destination NIC via
neigh_xmit() - through the neighbour layer.

> Hardware acceleration requires hw-specific implementation and can
> offload device's CPU.
> 
> Of course handling network traffic out of the networking subsystem
> means some features like QoS / throughput limits / advanced firewall
> rules may not/won't work.
> 
> The hardest task (for both methods) was always a Linux kernel
> integration. Drivers had to somehow:
> 1) Get/build a table with rules for packets flow
> 2) Update in-kernel state to e.g. avoid connection timeout & its removal
> 
> The problem with all existing implementations was they used various
> non-upstream patches for kernel integration. Some were less invasive,
> some a bit more. They weren't properly reviewed by kernel developers
> and usually were using hacks/solutions that couldn't be accepted.
> 
> The rescue to this was Pablo's work on offloading infrastructure. He
> worked on this hard by developing & sending his patchset for upstream
> kernel:
> [1] [PATCH RFC,WIP 0/5] Flow offload infrastructure
> [2] [PATCH nf-next RFC,v2 0/6] Flow offload infrastructure
> [3] [PATCH nf-next,v3 0/7] Flow offload infrastructure
> 
> The best news is that his final patchset version was accepted and sits
> now in the net-next [4] (and should become part of kernel 4.16).
> 
> Now, what does it mean for LEDE project:
> 1) There is upstream infrastructure that should be ready to use
> 2) It's based on & requires nftables
> 3) LEDE's firewall3 uses iptables (& friends) C API
> 4) There aren't any drivers for offloading hardware (switches?) yet

Yes, there is no drivers using the hardware offload infrastructure. So
the patch to add the ndo_flow_offload hook to struct net_device has
been kept back by now [1] until there is an initial driver client for
this. I'll be sending a new version for [1] asap. Will push it to a
branch in my nf-next.git tree [2] and will rebase it on top of my
master so people developing a driver that uses this doesn't need to
deal with this extra work.

[1] http://patchwork.ozlabs.org/patch/852537/
[2] https://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git

> One thing I'm not sure about is if software accelerator is ready or not.
> Pablo is his e-mail wrote:
> > So far, this is a generic software flow table representation, that
> > matches basic flow table hardware semantics but that also provides a
> > software faster path. So you can use it to purely forward packets
> > between two nics even if they come with no hardware offload support.
>
> which could suggest software path is already there.

Yes, software acceleration is working in my testbed, other than that,
it's a bug that needs to be fixed ;-).

I'm still finishing the userspace bits for libnftnl and nft, to
provide the control plane to users to configure this. Will post this
patchset asap, so these userspace bits can follow their path to
upstream repositories.

> So there is my idea of what is needed by LEDE to get it working:
> 1) Rewrite firewall3 to use nftables

There's a tentative C API for nftables:

http://git.netfilter.org/nftables/tree/include/nftables/nftables.h
http://git.netfilter.org/nftables/tree/src/libnftables.c

There are plans to add an API to support batching too, ie. add several
rules into the kernel in one go - using the nftables transaction
infrastructure- this is almost done since it was part of original work
done by Eric Leblond.

I can see firewall3 builds strings that are passed to iptables/ipset,
this approach matches the existing C API that we're providing.

At this stage the high-level libnftables library is not yet exposed as
shared object, there is a static library under

Re: [LEDE-DEV] A state of network acceleration

2018-01-17 Thread Rafał Miłecki 
On 17 January 2018 at 16:25, Rafał Miłecki  wrote:
> The problem with all existing implementations was they used various
> non-upstream patches for kernel integration. Some were less invasive,
> some a bit more. They weren't properly reviewed by kernel developers
> and usually were using hacks/solutions that couldn't be accepted.

If someone is interested in these existing implementations, there is a
list of these I'm aware of.

One of the earliest ones was Broadcom's CTF (Cut-Through Forwarding).
For BCM4706-based device it could bump NAT from 120 Mb/s to 850 Mb/s.
It was described by me in:
[1] Understanding/reimplementing forwarding acceleration used by Broadcom (ctf)
e-mail thread. It consisted of kernel modification (see ctf.diff in
above thread) and closed source ctf.ko.

Marvell announced their own "fastpath" implementation in 2014 in e-mail thread:
[2] Introducing "fastpath" - Kernel module for speeding up IP forwarding
They referenced a nice article on embedded.com [3].
AFAIU a year or two later they released it as the OpenFastPath project
[3] [4] under the BSD 3-clause license. Noone tried integrating it
with OpenWrt/LEDE AFAIK.

Finally there is Qualcomm's Shortcut Forwarding Engine. It's open
source and it's reported to increase NAT performance on AR9132-based
device from ~235 Mb/s to ~525 Mb/s. It's ported to LEDE as set of
patches to be applied on top of cloned repo [6] by a gwlim user.

[1] https://lists.openwrt.org/pipermail/openwrt-devel/2013-August/021112.html
[2] https://lists.openwrt.org/pipermail/openwrt-devel/2014-December/030179.html
[3] 
https://www.embedded.com/design/operating-systems/4403058/Accelerating-network-packet-processing-in-Linux
[4] https://openfastpath.org/
[5] https://github.com/MarvellEmbeddedProcessors/ofp-marvell
[6] https://github.com/gwlim/Fast-Path-LEDE-OpenWRT

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] A state of network acceleration

2018-01-17 Thread Rafał Miłecki 
Getting better network performance (mostly for NAT) using some kind of
acceleration was always a hot topic and people are still
looking/asking for it. I'd like to write a short summary and share my
understanding of current state so that:
1) People can undesrtand it better
2) We can have some rough plan

First of all there are two possible ways of accelerating network
traffic: in software and in hardware. Software solution is independent
of architecture/device and is mostly just bypassing in-kernel packets
flow. It still uses device's CPU which can be a bottleneck. Various
software implementations are reported to be faster from 2x to 5x.
Hardware acceleration requires hw-specific implementation and can
offload device's CPU.

Of course handling network traffic out of the networking subsystem
means some features like QoS / throughput limits / advanced firewall
rules may not/won't work.

The hardest task (for both methods) was always a Linux kernel
integration. Drivers had to somehow:
1) Get/build a table with rules for packets flow
2) Update in-kernel state to e.g. avoid connection timeout & its removal

The problem with all existing implementations was they used various
non-upstream patches for kernel integration. Some were less invasive,
some a bit more. They weren't properly reviewed by kernel developers
and usually were using hacks/solutions that couldn't be accepted.

The rescue to this was Pablo's work on offloading infrastructure. He
worked on this hard by developing & sending his patchset for upstream
kernel:
[1] [PATCH RFC,WIP 0/5] Flow offload infrastructure
[2] [PATCH nf-next RFC,v2 0/6] Flow offload infrastructure
[3] [PATCH nf-next,v3 0/7] Flow offload infrastructure

The best news is that his final patchset version was accepted and sits
now in the net-next [4] (and should become part of kernel 4.16).

Now, what does it mean for LEDE project:
1) There is upstream infrastructure that should be ready to use
2) It's based on & requires nftables
3) LEDE's firewall3 uses iptables (& friends) C API
4) There aren't any drivers for offloading hardware (switches?) yet

One thing I'm not sure about is if software accelerator is ready or not.
Pablo is his e-mail wrote:
> So far, this is a generic software flow table representation, that
> matches basic flow table hardware semantics but that also provides a
> software faster path. So you can use it to purely forward packets
> between two nics even if they come with no hardware offload support.

which could suggest software path is already there.

So there is my idea of what is needed by LEDE to get it working:
1) Rewrite firewall3 to use nftables
2) Switch to kernel 4.16 or backport offloading to 4.14
3) Work on implementing/enabling software acceleration path

Let me know if above description makes sense to you or correct me if
you think I misunderstood something :)


[1] https://www.spinics.net/lists/netfilter-devel/msg50141.html
[2] https://www.spinics.net/lists/netfilter-devel/msg50555.html
[3] https://www.spinics.net/lists/netfilter-devel/msg50759.html
[4] https://www.spinics.net/lists/netfilter-devel/msg50973.html

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH v2] ar71xx: add support for Ubiquiti Litebeam M5

2018-01-17 Thread Arne Zachlod 
Specification:
- SoC: Atheros AR9342
- Flash: 8 MiB
- RAM: 64 MiB
- UART: 1x UART on PCB - 115200 8N1
- Ethernet: 1 x 100 Mbit with passive PoE (24V/0.2A)

Doesn't work:
* Flash via TFTP with Uiquiti Uboot

Installation via vendor firmware:
- upload factory image via webinterface

Signed-off-by: Arne Zachlod 
---
 target/linux/ar71xx/base-files/etc/board.d/01_leds |  4 ++
 .../linux/ar71xx/base-files/etc/board.d/02_network |  1 +
 target/linux/ar71xx/base-files/etc/diag.sh |  3 ++
 target/linux/ar71xx/base-files/lib/ar71xx.sh   |  3 ++
 .../ar71xx/base-files/lib/upgrade/platform.sh  |  1 +
 .../ar71xx/files/arch/mips/ath79/mach-ubnt-xm.c| 58 ++
 .../linux/ar71xx/files/arch/mips/ath79/machtypes.h |  1 +
 target/linux/ar71xx/image/ubnt.mk  |  7 +++
 8 files changed, 78 insertions(+)

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 150ef91b48..ebdfb142d4 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -363,6 +363,10 @@ hornet-ub-x2)
ucidef_set_led_wlan "wlan" "WLAN" "alfa:blue:wlan" "phy0tpt"
ucidef_set_led_usbdev "usb" "USB" "alfa:blue:usb" "1-1"
;;
+lbe-m5)
+   ucidef_set_led_netdev "lan" "LAN" "ubnt:green:lan" "eth0"
+   ucidef_set_led_wlan "wlan" "WLAN" "ubnt:green:wlan" "phy0tpt"
+   ;;
 mc-mac1200r)
ucidef_set_led_wlan "wlan2g" "WLAN2G" "mercury:green:wlan2g" "phy1tpt"
ucidef_set_led_wlan "wlan5g" "WLAN5G" "mercury:green:wlan5g" "phy0tpt"
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 fb61792bf4..86d6ffd91d 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -78,6 +78,7 @@ ar71xx_setup_interfaces()
fritz300e|\
gl-usb150|\
hiveap-121|\
+   lbe-m5|\
loco-m-xw|\
mr12|\
mr16|\
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh 
b/target/linux/ar71xx/base-files/etc/diag.sh
index 5c60ebd6a8..5042e7a008 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -236,6 +236,9 @@ get_status_led() {
jwap230)
status_led="$board:green:led1"
;;
+   lbe-m5)
+   status_led="ubnt:green:sys"
+   ;;
ls-sr71)
status_led="ubnt:green:d22"
;;
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh 
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index b5440230a5..00a4acc6e0 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -711,6 +711,9 @@ ar71xx_board_detect() {
*"Lima"*)
name="lima"
;;
+   *"Litebeam M5"*)
+   name="lbe-m5"
+   ;;
*"Loco M XW")
name="loco-m-xw"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh 
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index ecf6820a2b..4e839f12c1 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -248,6 +248,7 @@ platform_check_image() {
hiwifi-hc6361|\
hornet-ub-x2|\
jwap230|\
+   lbe-m5|\
lima|\
loco-m-xw|\
mzk-w04nu|\
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-ubnt-xm.c 
b/target/linux/ar71xx/files/arch/mips/ath79/mach-ubnt-xm.c
index 55cf52d19e..8afb3ad054 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-ubnt-xm.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-ubnt-xm.c
@@ -12,6 +12,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -503,6 +504,60 @@ static void __init ubnt_loco_m_xw_setup(void)
ath79_register_eth(0);
 }
 
+#define UBNT_LBE_M5_GPIO_LED_LAN   13
+#define UBNT_LBE_M5_GPIO_LED_WLAN  14
+#define UBNT_LBE_M5_GPIO_LED_SYS   16
+
+static struct gpio_led ubnt_lbe_m5_leds_gpio[] __initdata = {
+   {
+   .name   = "ubnt:green:lan",
+   .gpio   = UBNT_LBE_M5_GPIO_LED_LAN,
+   .active_low = 1,
+   }, {
+   .name   = "ubnt:green:wlan",
+   .gpio   = UBNT_LBE_M5_GPIO_LED_WLAN,
+   .active_low = 1,
+   }, {
+   .name   = "ubnt:green:sys",
+   .gpio   = UBNT_LBE_M5_GPIO_LED_SYS,
+   .active_low = 1,
+   },
+};
+
+static void __init ubnt_lbe_m5_setup(void)
+{
+   u8 *eeprom = (u8 *) KSEG1ADDR(0x1fff);
+
+   ath79_register_m25p80(NULL);
+
+   ath79_register_wmac(eeprom + UAP_PRO_WMAC_CALDATA_OFFSET, NULL);
+

[LEDE-DEV] [PATCH] ar71xx: Orders the names of the devices alphabetically.

2018-01-17 Thread Arne Zachlod 
Signed-off-by: Arne Zachlod 
---
 target/linux/ar71xx/base-files/etc/board.d/01_leds | 236 ++---
 .../ar71xx/base-files/etc/board.d/03_gpio_switches |  12 +-
 target/linux/ar71xx/base-files/etc/diag.sh |  40 ++--
 3 files changed, 144 insertions(+), 144 deletions(-)

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 e5baa90db8..150ef91b48 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -59,6 +59,27 @@ sc450)
ucidef_set_led_wlan "wlan" "WLAN" "$board:green:wlan" "phy0tpt"
;;
 archer-c25-v1|\
+archer-c58-v1|\
+archer-c59-v1|\
+archer-c60-v1)
+   ucidef_set_led_switch "lan" "LAN" "$board:green:lan" "switch0" "0x1E"
+   ucidef_set_led_netdev "wan" "WAN" "$board:green:wan" "eth0"
+   ucidef_set_led_wlan "wlan" "WLAN" "$board:green:wlan2g" "phy1tpt"
+   ucidef_set_led_wlan "wlan5g" "WLAN5G" "$board:green:wlan5g" "phy0tpt"
+
+   case "$board" in
+   archer-c59-v1)
+   ucidef_set_led_usbdev "usb" "USB" "$board:green:usb" "1-1"
+   ;;
+   esac
+   ;;
+archer-c5|\
+archer-c7)
+   ucidef_set_led_usbdev "usb1" "USB1" "tp-link:green:usb1" "1-1"
+   ucidef_set_led_usbdev "usb2" "USB2" "tp-link:green:usb2" "2-1"
+   ucidef_set_led_wlan "wlan2g" "WLAN2G" "tp-link:blue:wlan2g" "phy1tpt"
+   ucidef_set_led_wlan "wlan5g" "WLAN5G" "tp-link:blue:wlan5g" "phy0tpt"
+   ;;
 archer-c7-v4)
ucidef_set_led_netdev "wan" "WAN" "$board:green:wan" "eth0"
ucidef_set_led_wlan "wlan" "WLAN" "$board:green:wlan2g" "phy1tpt"
@@ -74,20 +95,6 @@ archer-c7-v4)
;;
esac
;;
-archer-c58-v1|\
-archer-c59-v1|\
-archer-c60-v1)
-   ucidef_set_led_switch "lan" "LAN" "$board:green:lan" "switch0" "0x1E"
-   ucidef_set_led_netdev "wan" "WAN" "$board:green:wan" "eth0"
-   ucidef_set_led_wlan "wlan" "WLAN" "$board:green:wlan2g" "phy1tpt"
-   ucidef_set_led_wlan "wlan5g" "WLAN5G" "$board:green:wlan5g" "phy0tpt"
-
-   case "$board" in
-   archer-c59-v1)
-   ucidef_set_led_usbdev "usb" "USB" "$board:green:usb" "1-1"
-   ;;
-   esac
-   ;;
 arduino-yun)
ucidef_set_led_wlan "wlan" "WLAN" "arduino:blue:wlan" "phy0tpt"
ucidef_set_led_usbdev "usb" "USB" "arduino:white:usb" "1-1.1"
@@ -147,22 +154,9 @@ rocket-m-xw)
ucidef_set_led_rssi "rssimediumhigh" "RSSIMEDIUMHIGH" 
"ubnt:green:link3" "wlan0" "51" "100" "-50" "13"
ucidef_set_led_rssi "rssihigh" "RSSIHIGH" "ubnt:green:link4" "wlan0" 
"76" "100" "-75" "13"
;;
-rocket-m-ti)
-   ucidef_set_led_rssi "rssiverylow" "RSSIVERYLOW" "ubnt:green:link1" 
"wlan0" "1" "100" "0" "13"
-   ucidef_set_led_rssi "rssilow" "RSSILOW" "ubnt:green:link2" "wlan0" "26" 
"100" "-25" "13"
-   ucidef_set_led_rssi "rssimediumlow" "RSSIMEDIUMLOW" "ubnt:green:link3" 
"wlan0" "51" "100" "-50" "13"
-   ucidef_set_led_rssi "rssimediumhigh" "RSSIMEDIUMHIGH" 
"ubnt:green:link4" "wlan0" "76" "100" "-75" "13"
-   ucidef_set_led_rssi "rssihigh" "RSSIHIGH" "ubnt:green:link5" "wlan0" 
"76" "100" "-75" "13"
-   ucidef_set_led_rssi "rssiveryhigh" "RSSIVERYHIGH" "ubnt:green:link4" 
"wlan0" "76" "100" "-75" "13"
-   ;;
 bxu2000n-2-a1)
ucidef_set_led_wlan "wlan" "WLAN" "bhu:green:wlan" "phy0tpt"
;;
-cap324)
-   ucidef_set_led_netdev "lan" "LAN" "pcs:green:lan" "eth0"
-   ucidef_set_led_wlan "wlan_amber" "WLAN_AMBER" "pcs:amber:wlan" "phy0tpt"
-   ucidef_set_led_wlan "wlan_green" "WLAN_GREEN" "pcs:green:wlan" "phy1tpt"
-   ;;
 c-55)
ucidef_set_led_netdev "lan_green" "LAN_GREEN" "$board:green:lan" "eth0"
ucidef_set_led_wlan "wlan_amber" "WLAN_AMBER" "$board:amber:wlan" 
"phy0tpt"
@@ -172,6 +166,11 @@ c-60)
ucidef_set_led_wlan "wlan1_green" "WLAN1_GREEN" "$board:green:wlan1" 
"phy0tpt"
ucidef_set_led_wlan "wlan2_green" "WLAN2_GREEN" "$board:green:wlan2" 
"phy1tpt"
;;
+cap324)
+   ucidef_set_led_netdev "lan" "LAN" "pcs:green:lan" "eth0"
+   ucidef_set_led_wlan "wlan_amber" "WLAN_AMBER" "pcs:amber:wlan" "phy0tpt"
+   ucidef_set_led_wlan "wlan_green" "WLAN_GREEN" "pcs:green:wlan" "phy1tpt"
+   ;;
 cap4200ag)
ucidef_set_led_default "lan_green" "LAN_GREEN" "senao:green:lan" "1"
ucidef_set_led_wlan "wlan_amber" "WLAN_AMBER" "senao:amber:wlan" 
"phy0tpt"
@@ -265,76 +264,6 @@ fritz300e)
ucidef_set_led_rssi "rssimediumhigh" "RSSIMEDIUMHIGH" 
"$board:green:rssi3" "wlan0" "60" "100"
ucidef_set_led_rssi "rssihigh" "RSSIHIGH" "$board:green:rssi4" "wlan0" 
"80" "100"
;;
-rb-750)
-   ucidef_set_led_default "act" "act" "rb750:green:act" "1"
-   ucidef_set_led_netdev "port1" "port1" "rb750:green:port1" "eth1"
-   ucidef_set_led_switch "port2" "port2" "rb750:green:port2" "switch0" 
"0x10"
-

[LEDE-DEV] [PATCH v3] procd: add timing to start/stop logging

2018-01-17 Thread Karl Vogel 
Shows how long an initd task took, for example:

 procd: stop /etc/init.d/dropbear running - took 0.088824s
 procd: Update service dnsmasq
 procd: Update instance dnsmasq::dnsmasq
 procd: running /etc/init.d/dnsmasq running
 procd: start /etc/init.d/dnsmasq running
 procd: stop /etc/init.d/dnsmasq running - took 0.092586s

 v2: rename variables, correct time unit
 v3: use CLOCK_MONOTONIC_RAW to prevent issues with NTP and adjtime

Signed-off-by: Karl Vogel 
---
 rcS.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/rcS.c b/rcS.c
index dd3b76d..c2e1abb 100644
--- a/rcS.c
+++ b/rcS.c
@@ -37,6 +37,7 @@ static struct runqueue q, r;
 struct initd {
struct ustream_fd fd;
struct runqueue_process proc;
+   struct timespec ts_start;
char *file;
char *param;
 };
@@ -70,6 +71,7 @@ static void q_initd_run(struct runqueue *q, struct 
runqueue_task *t)
int pipefd[2];
pid_t pid;
 
+   clock_gettime(CLOCK_MONOTONIC_RAW, >ts_start);
DEBUG(2, "start %s %s \n", s->file, s->param);
if (pipe(pipefd) == -1) {
ERROR("Failed to create pipe: %m\n");
@@ -106,8 +108,17 @@ static void q_initd_run(struct runqueue *q, struct 
runqueue_task *t)
 static void q_initd_complete(struct runqueue *q, struct runqueue_task *p)
 {
struct initd *s = container_of(p, struct initd, proc.task);
+   struct timespec ts_stop, ts_res;
+
+   clock_gettime(CLOCK_MONOTONIC_RAW, _stop);
+   ts_res.tv_sec = ts_stop.tv_sec - s->ts_start.tv_sec;
+   ts_res.tv_nsec = ts_stop.tv_nsec - s->ts_start.tv_nsec;
+   if (ts_res.tv_nsec < 0) {
+   --ts_res.tv_sec;
+   ts_res.tv_nsec += 10;
+   }
 
-   DEBUG(2, "stop %s %s \n", s->file, s->param);
+   DEBUG(2, "stop %s %s - took %lu.%09lus\n", s->file, s->param, 
ts_res.tv_sec, ts_res.tv_nsec);
ustream_free(>fd.stream);
close(s->fd.fd.fd);
free(s);
-- 
2.15.1


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] ipq806x Netgear R7500 uboot

2018-01-17 Thread Thomas Reifferscheid 
Hi, I've lost my original uboot environment settings and would like to 
ask for your help.
Since it's been a while from when I was playing with the hardware the 
uboot env is all messed up and I'd like to start over from scratch.


Would someone please send me "env print" from within the bootloader from 
any ipq806x, preferrably Netgear R7500 but anything close would probably do.


Thank you
Thomas



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v2] procd: add timing to start/stop logging

2018-01-17 Thread Koen Vandeputte 



On 2018-01-17 11:11, Karl Vogel wrote:

John Crispin  writes:


On 17/01/18 10:54, Koen Vandeputte wrote:


On 2018-01-17 10:43, Karl Vogel wrote:

Shows how long an initd task took, for example:

  procd: stop /etc/init.d/dropbear running - took 0.088824s
  procd: Update service dnsmasq
  procd: Update instance dnsmasq::dnsmasq
  procd: running /etc/init.d/dnsmasq running
  procd: start /etc/init.d/dnsmasq running
  procd: stop /etc/init.d/dnsmasq running - took 0.092586s

Signed-off-by: Karl Vogel 
---
  rcS.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/rcS.c b/rcS.c
index dd3b76d..acfb6a0 100644
--- a/rcS.c
+++ b/rcS.c
@@ -37,6 +37,7 @@ static struct runqueue q, r;
  struct initd {
  struct ustream_fd fd;
  struct runqueue_process proc;
+ struct timeval tv_start;
  char *file;
  char *param;
  };
@@ -70,6 +71,7 @@ static void q_initd_run(struct runqueue *q, struct
runqueue_task *t)
  int pipefd[2];
  pid_t pid;
  + gettimeofday(>tv_start, NULL);
  DEBUG(2, "start %s %s \n", s->file, s->param);
  if (pipe(pipefd) == -1) {
  ERROR("Failed to create pipe: %m\n");
@@ -106,8 +108,11 @@ static void q_initd_run(struct runqueue *q,
struct runqueue_task *t)
  static void q_initd_complete(struct runqueue *q, struct
runqueue_task *p)
  {
  struct initd *s = container_of(p, struct initd, proc.task);
+ struct timeval tv_stop, tv_res;
  - DEBUG(2, "stop %s %s \n", s->file, s->param);
+ gettimeofday(_stop, NULL);
+ timersub(_stop, >tv_start, _res);
+ DEBUG(2, "stop %s %s - took %lu.%06lus\n", s->file, s->param,
tv_res.tv_sec, tv_res.tv_usec);
  ustream_free(>fd.stream);
  close(s->fd.fd.fd);
  free(s);

Isn't it better to use a monotonic time source here to measure elapsed
time?
|This way you avoid racing issues should NTP sync kick in during
execution.


|||clock_gettime(CLOCK_MONOTONIC, ...)

that occurred to me aswell as i was just testing the patch inside a vm :-)

   John

I considered that, but then it would require a bit more logic to do the
subtract, as clock_gettime uses a timespec not a timeval. Nothing
impossible ofcourse, but didn't want to increase the size too much for
debug output that isn't active in 99.9% of the installations.

clock_gettime(CLOCK_MONOTONIC, ... ) is also affected by NTP and
adjtime(), so even that won't be 100% when the clock is adjusted.
True,  but CLOCK_MONOTONIC_RAW is not available afaics, and it's at 
least a lot better than a clocksource

which can jump from year 1970 to year 2018 in a split second :)
(especially for devices using battery powered RTC where it's battery 
depleted)


Koen

Karl



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v2] procd: add timing to start/stop logging

2018-01-17 Thread Karl Vogel 

John Crispin  writes:

> On 17/01/18 10:54, Koen Vandeputte wrote:
>>
>>
>> On 2018-01-17 10:43, Karl Vogel wrote:
>>> Shows how long an initd task took, for example:
>>>
>>>  procd: stop /etc/init.d/dropbear running - took 0.088824s
>>>  procd: Update service dnsmasq
>>>  procd: Update instance dnsmasq::dnsmasq
>>>  procd: running /etc/init.d/dnsmasq running
>>>  procd: start /etc/init.d/dnsmasq running
>>>  procd: stop /etc/init.d/dnsmasq running - took 0.092586s
>>>
>>> Signed-off-by: Karl Vogel 
>>> ---
>>>  rcS.c | 7 ++-
>>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/rcS.c b/rcS.c
>>> index dd3b76d..acfb6a0 100644
>>> --- a/rcS.c
>>> +++ b/rcS.c
>>> @@ -37,6 +37,7 @@ static struct runqueue q, r;
>>>  struct initd {
>>>  struct ustream_fd fd;
>>>  struct runqueue_process proc;
>>> + struct timeval tv_start;
>>>  char *file;
>>>  char *param;
>>>  };
>>> @@ -70,6 +71,7 @@ static void q_initd_run(struct runqueue *q, struct 
>>> runqueue_task *t)
>>>  int pipefd[2];
>>>  pid_t pid;
>>>  + gettimeofday(>tv_start, NULL);
>>>  DEBUG(2, "start %s %s \n", s->file, s->param);
>>>  if (pipe(pipefd) == -1) {
>>>  ERROR("Failed to create pipe: %m\n");
>>> @@ -106,8 +108,11 @@ static void q_initd_run(struct runqueue *q, 
>>> struct runqueue_task *t)
>>>  static void q_initd_complete(struct runqueue *q, struct 
>>> runqueue_task *p)
>>>  {
>>>  struct initd *s = container_of(p, struct initd, proc.task);
>>> + struct timeval tv_stop, tv_res;
>>>  - DEBUG(2, "stop %s %s \n", s->file, s->param);
>>> + gettimeofday(_stop, NULL);
>>> + timersub(_stop, >tv_start, _res);
>>> + DEBUG(2, "stop %s %s - took %lu.%06lus\n", s->file, s->param, 
>>> tv_res.tv_sec, tv_res.tv_usec);
>>>  ustream_free(>fd.stream);
>>>  close(s->fd.fd.fd);
>>>  free(s);
>> Isn't it better to use a monotonic time source here to measure elapsed 
>> time?
>> |This way you avoid racing issues should NTP sync kick in during 
>> execution.
>>
>>
>> |||clock_gettime(CLOCK_MONOTONIC, ...)
>
> that occurred to me aswell as i was just testing the patch inside a vm :-)
>
>   John

I considered that, but then it would require a bit more logic to do the
subtract, as clock_gettime uses a timespec not a timeval. Nothing
impossible ofcourse, but didn't want to increase the size too much for
debug output that isn't active in 99.9% of the installations.

clock_gettime(CLOCK_MONOTONIC, ... ) is also affected by NTP and
adjtime(), so even that won't be 100% when the clock is adjusted.

Karl

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] ar71xx: add support for Ubiquiti Litebeam M5

2018-01-17 Thread Piotr Dymacz 

Hello Arne,

Minor thing inline, below.

On 16.01.2018 21:43, Arne Zachlod wrote:

[...]


+lbe-m5)
+   ucidef_set_led_netdev "lan" "LAN" "ubnt:green:lan" "eth0"
+   ucidef_set_led_wlan "wlan" "WLAN" "ubnt:green:wlan" "phy0tpt"
+   ucidef_set_led_default "sys" "SYS" "ubnt:green:sys" "1"


There is no need to setup "ubnt:green:sys" LED here as it's already 
handled in diag.sh (below). If the LED doesn't light up after boot then 
probably polarity is wrong (active_low).


[...]


+   lbe-m5)
+   status_led="ubnt:green:sys"
+   ;;


[...]

--
Cheers,
Piotr

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v2] procd: add timing to start/stop logging

2018-01-17 Thread John Crispin 



On 17/01/18 10:54, Koen Vandeputte wrote:



On 2018-01-17 10:43, Karl Vogel wrote:

Shows how long an initd task took, for example:

  procd: stop /etc/init.d/dropbear running - took 0.088824s
  procd: Update service dnsmasq
  procd: Update instance dnsmasq::dnsmasq
  procd: running /etc/init.d/dnsmasq running
  procd: start /etc/init.d/dnsmasq running
  procd: stop /etc/init.d/dnsmasq running - took 0.092586s

Signed-off-by: Karl Vogel 
---
  rcS.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/rcS.c b/rcS.c
index dd3b76d..acfb6a0 100644
--- a/rcS.c
+++ b/rcS.c
@@ -37,6 +37,7 @@ static struct runqueue q, r;
  struct initd {
  struct ustream_fd fd;
  struct runqueue_process proc;
+    struct timeval tv_start;
  char *file;
  char *param;
  };
@@ -70,6 +71,7 @@ static void q_initd_run(struct runqueue *q, struct 
runqueue_task *t)

  int pipefd[2];
  pid_t pid;
  +    gettimeofday(>tv_start, NULL);
  DEBUG(2, "start %s %s \n", s->file, s->param);
  if (pipe(pipefd) == -1) {
  ERROR("Failed to create pipe: %m\n");
@@ -106,8 +108,11 @@ static void q_initd_run(struct runqueue *q, 
struct runqueue_task *t)
  static void q_initd_complete(struct runqueue *q, struct 
runqueue_task *p)

  {
  struct initd *s = container_of(p, struct initd, proc.task);
+    struct timeval tv_stop, tv_res;
  -    DEBUG(2, "stop %s %s \n", s->file, s->param);
+    gettimeofday(_stop, NULL);
+    timersub(_stop, >tv_start, _res);
+    DEBUG(2, "stop %s %s - took %lu.%06lus\n", s->file, s->param, 
tv_res.tv_sec, tv_res.tv_usec);

  ustream_free(>fd.stream);
  close(s->fd.fd.fd);
  free(s);
Isn't it better to use a monotonic time source here to measure elapsed 
time?
|This way you avoid racing issues should NTP sync kick in during 
execution.



|||clock_gettime(CLOCK_MONOTONIC, ...)


that occurred to me aswell as i was just testing the patch inside a vm :-)

    John


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] jshn: add functionality to read big JSON

2018-01-17 Thread John Crispin 



On 17/01/18 10:44, Arjen de Korte wrote:

Citeren John Crispin :


On 07/01/18 18:08, Christian Beier wrote:

The existing read functionality feeds the complete JSON to jshn as a
cmdline argument, leading to `-ash: jshn: Argument list too long`
errors for JSONs bigger than ca. 100KB.

This commit adds the ability to read the JSON directly from a file if
wanted, removing this shell-imposed size limit.

Tested on x86-64 and ar71xx. An mmap()-based solution was also 
evaluated,

but found to make no performance difference on either platform.

Signed-off-by: Christian Beier 


Hi Christian,

comment inline ...


---
 jshn.c | 30 --
 sh/jshn.sh |  4 
 2 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/jshn.c b/jshn.c
index 3188af5..eb72fb7 100644
--- a/jshn.c
+++ b/jshn.c
@@ -25,6 +25,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include "list.h"
   #include "avl.h"
@@ -305,7 +307,7 @@ out:
   static int usage(const char *progname)
 {
-    fprintf(stderr, "Usage: %s [-n] [-i] -r |-w\n", 
progname);
+    fprintf(stderr, "Usage: %s [-n] [-i] -r |-R 
|-w\n", progname);

 return 2;
 }
 @@ -338,6 +340,10 @@ int main(int argc, char **argv)
 struct env_var *vars;
 int i;
 int ch;
+    int fd;
+    struct stat sb;
+    char *fbuf;
+    int ret;
   avl_init(_vars, avl_strcmp_var, false, NULL);
 for (i = 0; environ[i]; i++);
@@ -359,7 +365,7 @@ int main(int argc, char **argv)
 avl_insert(_vars, [i].avl);
 }
 -    while ((ch = getopt(argc, argv, "p:nir:w")) != -1) {
+    while ((ch = getopt(argc, argv, "p:nir:R:w")) != -1) {
 switch(ch) {
 case 'p':
 var_prefix = optarg;
@@ -367,6 +373,26 @@ int main(int argc, char **argv)
 break;
 case 'r':
 return jshn_parse(optarg);
+    case 'R':
+    if ((fd = open(optarg, O_RDONLY)) == -1) {
+    fprintf(stderr, "Error opening %s\n", optarg);
+    return 3;
+    }
+    if (fstat(fd, ) == -1) {
+    fprintf(stderr, "Error getting size of %s\n", optarg);
+    close(fd);
+    return 3;
+    }
+    if (!(fbuf = malloc(sb.st_size)) || read(fd, fbuf, 
sb.st_size) != sb.st_size) {

+    fprintf(stderr, "Error reading %s\n", optarg);
+    free(fbuf);


this will blow up if the malloc fails.


How would it? If the malloc fails and returns a NULL pointer, the read 
will not be performed. Free'ing a NULL pointer is allowed, so although 
assigning a value in an if() statement is considered a no-no by some 
(including me), there is no reason for it to blow up.


ok, point taken 




please spli the if clause up into 2 blocks


Agreed (but for a different reason). A memory allocation error is 
different from failure to read from a file and error handlers should 
not treat them the same.



    John


+    close(fd);
+    return 3;
+    }
+    ret = jshn_parse(fbuf);
+    free(fbuf);
+    close(fd);
+    return ret;
 case 'w':
 return jshn_format(no_newline, indent);
 case 'n':
diff --git a/sh/jshn.sh b/sh/jshn.sh
index 1090814..66baccb 100644
--- a/sh/jshn.sh
+++ b/sh/jshn.sh
@@ -180,6 +180,10 @@ json_load() {
 eval "`jshn -r "$1"`"
 }
 +json_load_file() {
+    eval "`jshn -R "$1"`"
+}
+
 json_dump() {
 jshn "$@" ${JSON_PREFIX:+-p "$JSON_PREFIX"} -w
 }



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev





___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v2] procd: add timing to start/stop logging

2018-01-17 Thread Koen Vandeputte 



On 2018-01-17 10:43, Karl Vogel wrote:

Shows how long an initd task took, for example:

  procd: stop /etc/init.d/dropbear running - took 0.088824s
  procd: Update service dnsmasq
  procd: Update instance dnsmasq::dnsmasq
  procd: running /etc/init.d/dnsmasq running
  procd: start /etc/init.d/dnsmasq running
  procd: stop /etc/init.d/dnsmasq running - took 0.092586s

Signed-off-by: Karl Vogel 
---
  rcS.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/rcS.c b/rcS.c
index dd3b76d..acfb6a0 100644
--- a/rcS.c
+++ b/rcS.c
@@ -37,6 +37,7 @@ static struct runqueue q, r;
  struct initd {
struct ustream_fd fd;
struct runqueue_process proc;
+   struct timeval tv_start;
char *file;
char *param;
  };
@@ -70,6 +71,7 @@ static void q_initd_run(struct runqueue *q, struct 
runqueue_task *t)
int pipefd[2];
pid_t pid;
  
+	gettimeofday(>tv_start, NULL);

DEBUG(2, "start %s %s \n", s->file, s->param);
if (pipe(pipefd) == -1) {
ERROR("Failed to create pipe: %m\n");
@@ -106,8 +108,11 @@ static void q_initd_run(struct runqueue *q, struct 
runqueue_task *t)
  static void q_initd_complete(struct runqueue *q, struct runqueue_task *p)
  {
struct initd *s = container_of(p, struct initd, proc.task);
+   struct timeval tv_stop, tv_res;
  
-	DEBUG(2, "stop %s %s \n", s->file, s->param);

+   gettimeofday(_stop, NULL);
+   timersub(_stop, >tv_start, _res);
+   DEBUG(2, "stop %s %s - took %lu.%06lus\n", s->file, s->param, 
tv_res.tv_sec, tv_res.tv_usec);
ustream_free(>fd.stream);
close(s->fd.fd.fd);
free(s);

Isn't it better to use a monotonic time source here to measure elapsed time?
|This way you avoid racing issues should NTP sync kick in during execution.


|||clock_gettime(CLOCK_MONOTONIC, ...)

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] jshn: add functionality to read big JSON

2018-01-17 Thread Arjen de Korte 

Citeren John Crispin :


On 07/01/18 18:08, Christian Beier wrote:

The existing read functionality feeds the complete JSON to jshn as a
cmdline argument, leading to `-ash: jshn: Argument list too long`
errors for JSONs bigger than ca. 100KB.

This commit adds the ability to read the JSON directly from a file if
wanted, removing this shell-imposed size limit.

Tested on x86-64 and ar71xx. An mmap()-based solution was also evaluated,
but found to make no performance difference on either platform.

Signed-off-by: Christian Beier 


Hi Christian,

comment inline ...


---
 jshn.c | 30 --
 sh/jshn.sh |  4 
 2 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/jshn.c b/jshn.c
index 3188af5..eb72fb7 100644
--- a/jshn.c
+++ b/jshn.c
@@ -25,6 +25,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include "list.h"
   #include "avl.h"
@@ -305,7 +307,7 @@ out:
   static int usage(const char *progname)
 {
-   fprintf(stderr, "Usage: %s [-n] [-i] -r |-w\n", progname);
+	fprintf(stderr, "Usage: %s [-n] [-i] -r |-R  
|-w\n", progname);

return 2;
 }
 @@ -338,6 +340,10 @@ int main(int argc, char **argv)
struct env_var *vars;
int i;
int ch;
+   int fd;
+   struct stat sb;
+   char *fbuf;
+   int ret;
avl_init(_vars, avl_strcmp_var, false, NULL);
for (i = 0; environ[i]; i++);
@@ -359,7 +365,7 @@ int main(int argc, char **argv)
avl_insert(_vars, [i].avl);
}
 -  while ((ch = getopt(argc, argv, "p:nir:w")) != -1) {
+   while ((ch = getopt(argc, argv, "p:nir:R:w")) != -1) {
switch(ch) {
case 'p':
var_prefix = optarg;
@@ -367,6 +373,26 @@ int main(int argc, char **argv)
break;
case 'r':
return jshn_parse(optarg);
+   case 'R':
+   if ((fd = open(optarg, O_RDONLY)) == -1) {
+   fprintf(stderr, "Error opening %s\n", optarg);
+   return 3;
+   }
+   if (fstat(fd, ) == -1) {
+   fprintf(stderr, "Error getting size of %s\n", 
optarg);
+   close(fd);
+   return 3;
+   }
+			if (!(fbuf = malloc(sb.st_size)) || read(fd, fbuf, sb.st_size)  
!= sb.st_size) {

+   fprintf(stderr, "Error reading %s\n", optarg);
+   free(fbuf);


this will blow up if the malloc fails.


How would it? If the malloc fails and returns a NULL pointer, the read  
will not be performed. Free'ing a NULL pointer is allowed, so although  
assigning a value in an if() statement is considered a no-no by some  
(including me), there is no reason for it to blow up.



please spli the if clause up into 2 blocks


Agreed (but for a different reason). A memory allocation error is  
different from failure to read from a file and error handlers should  
not treat them the same.



    John


+   close(fd);
+   return 3;
+   }
+   ret = jshn_parse(fbuf);
+   free(fbuf);
+   close(fd);
+   return ret;
case 'w':
return jshn_format(no_newline, indent);
case 'n':
diff --git a/sh/jshn.sh b/sh/jshn.sh
index 1090814..66baccb 100644
--- a/sh/jshn.sh
+++ b/sh/jshn.sh
@@ -180,6 +180,10 @@ json_load() {
eval "`jshn -r "$1"`"
 }
 +json_load_file() {
+   eval "`jshn -R "$1"`"
+}
+
 json_dump() {
jshn "$@" ${JSON_PREFIX:+-p "$JSON_PREFIX"} -w
 }



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev





___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH v2] procd: add timing to start/stop logging

2018-01-17 Thread Karl Vogel 
Shows how long an initd task took, for example:

 procd: stop /etc/init.d/dropbear running - took 0.088824s
 procd: Update service dnsmasq
 procd: Update instance dnsmasq::dnsmasq
 procd: running /etc/init.d/dnsmasq running
 procd: start /etc/init.d/dnsmasq running
 procd: stop /etc/init.d/dnsmasq running - took 0.092586s

Signed-off-by: Karl Vogel 
---
 rcS.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/rcS.c b/rcS.c
index dd3b76d..acfb6a0 100644
--- a/rcS.c
+++ b/rcS.c
@@ -37,6 +37,7 @@ static struct runqueue q, r;
 struct initd {
struct ustream_fd fd;
struct runqueue_process proc;
+   struct timeval tv_start;
char *file;
char *param;
 };
@@ -70,6 +71,7 @@ static void q_initd_run(struct runqueue *q, struct 
runqueue_task *t)
int pipefd[2];
pid_t pid;
 
+   gettimeofday(>tv_start, NULL);
DEBUG(2, "start %s %s \n", s->file, s->param);
if (pipe(pipefd) == -1) {
ERROR("Failed to create pipe: %m\n");
@@ -106,8 +108,11 @@ static void q_initd_run(struct runqueue *q, struct 
runqueue_task *t)
 static void q_initd_complete(struct runqueue *q, struct runqueue_task *p)
 {
struct initd *s = container_of(p, struct initd, proc.task);
+   struct timeval tv_stop, tv_res;
 
-   DEBUG(2, "stop %s %s \n", s->file, s->param);
+   gettimeofday(_stop, NULL);
+   timersub(_stop, >tv_start, _res);
+   DEBUG(2, "stop %s %s - took %lu.%06lus\n", s->file, s->param, 
tv_res.tv_sec, tv_res.tv_usec);
ustream_free(>fd.stream);
close(s->fd.fd.fd);
free(s);
-- 
2.15.1


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] ar71xx: add support for Ubiquiti Litebeam M5

2018-01-17 Thread Arne Zachlod 
Hi John,

I ordered the device between the already existing bullet and the
rocket-ti. To me this looks like the order already in place and the
right spot because it is alphabetical for the manufacturer. In case that
this is not the right thing to do maybe we should refactor the whole
file, because at the moment it looks like its ordered per manufacturer
and then alphabetical for that manufacturer.

Bye
Arne

On 01/17/2018 10:06 AM, John Crispin wrote:
> 
> 
> On 16/01/18 21:43, Arne Zachlod wrote:
>> Specification:
>> - SoC: Atheros AR9342
>> - Flash: 8 MiB
>> - RAM: 64 MiB
>> - UART: 1x UART on PCB - 115200 8N1
>> - Ethernet: 1 x 100 Mbit with passive PoE (24V/0.2A)
>>
>> Doesn't work:
>> * Flash via TFTP with Uiquiti Uboot
>>
>> Installation via vendor firmware:
>> - upload factory image via webinterface
>>
>> Signed-off-by: Arne Zachlod 
> 
> Hi Arne,
> 
> comments inline ...
> 
>> ---
>>   target/linux/ar71xx/base-files/etc/board.d/01_leds |  5 ++
>>   .../linux/ar71xx/base-files/etc/board.d/02_network |  1 +
>>   target/linux/ar71xx/base-files/etc/diag.sh |  3 ++
>>   target/linux/ar71xx/base-files/lib/ar71xx.sh   |  3 ++
>>   .../ar71xx/base-files/lib/upgrade/platform.sh  |  1 +
>>   .../ar71xx/files/arch/mips/ath79/mach-ubnt-xm.c    | 58
>> ++
>>   .../linux/ar71xx/files/arch/mips/ath79/machtypes.h |  1 +
>>   target/linux/ar71xx/image/ubnt.mk  |  7 +++
>>   8 files changed, 79 insertions(+)
>>
>> 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 e5baa90db8..79fc8ec5e2 100755
>> --- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
>> +++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
>> @@ -147,6 +147,11 @@ rocket-m-xw)
>>   ucidef_set_led_rssi "rssimediumhigh" "RSSIMEDIUMHIGH"
>> "ubnt:green:link3" "wlan0" "51" "100" "-50" "13"
>>   ucidef_set_led_rssi "rssihigh" "RSSIHIGH" "ubnt:green:link4"
>> "wlan0" "76" "100" "-75" "13"
>>   ;;
>> +lbe-m5)
>> +    ucidef_set_led_netdev "lan" "LAN" "ubnt:green:lan" "eth0"
>> +    ucidef_set_led_wlan "wlan" "WLAN" "ubnt:green:wlan" "phy0tpt"
>> +    ucidef_set_led_default "sys" "SYS" "ubnt:green:sys" "1"
>> +    ;;
> 
> alphabetical ordering please
> 
>>   rocket-m-ti)
>>   ucidef_set_led_rssi "rssiverylow" "RSSIVERYLOW"
>> "ubnt:green:link1" "wlan0" "1" "100" "0" "13"
>>   ucidef_set_led_rssi "rssilow" "RSSILOW" "ubnt:green:link2"
>> "wlan0" "26" "100" "-25" "13"
>> 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 fb61792bf4..86d6ffd91d 100755
>> --- a/target/linux/ar71xx/base-files/etc/board.d/02_network
>> +++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
>> @@ -78,6 +78,7 @@ ar71xx_setup_interfaces()
>>   fritz300e|\
>>   gl-usb150|\
>>   hiveap-121|\
>> +    lbe-m5|\
>>   loco-m-xw|\
>>   mr12|\
>>   mr16|\
>> diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
>> b/target/linux/ar71xx/base-files/etc/diag.sh
>> index 6cbb3576d8..f37541c75f 100644
>> --- a/target/linux/ar71xx/base-files/etc/diag.sh
>> +++ b/target/linux/ar71xx/base-files/etc/diag.sh
>> @@ -103,6 +103,9 @@ get_status_led() {
>>   rocket-m-xw)
>>   status_led="ubnt:green:link4"
>>   ;;
>> +    lbe-m5)
>> +    status_led="ubnt:green:sys"
>> +    ;;
> 
> 
> alphabetical ordering please
>>   rocket-m-ti)
>>   status_led="ubnt:green:link6"
>>   ;;
>> diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
>> b/target/linux/ar71xx/base-files/lib/ar71xx.sh
>> index b5440230a5..00a4acc6e0 100755
>> --- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
>> +++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
>> @@ -711,6 +711,9 @@ ar71xx_board_detect() {
>>   *"Lima"*)
>>   name="lima"
>>   ;;
>> +    *"Litebeam M5"*)
>> +    name="lbe-m5"
>> +    ;;
>>   *"Loco M XW")
>>   name="loco-m-xw"
>>   ;;
>> diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
>> b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
>> index ecf6820a2b..4e839f12c1 100755
>> --- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
>> +++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
>> @@ -248,6 +248,7 @@ platform_check_image() {
>>   hiwifi-hc6361|\
>>   hornet-ub-x2|\
>>   jwap230|\
>> +    lbe-m5|\
>>   lima|\
>>   loco-m-xw|\
>>   mzk-w04nu|\
>> diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-ubnt-xm.c
>> b/target/linux/ar71xx/files/arch/mips/ath79/mach-ubnt-xm.c
>> index 55cf52d19e..8afb3ad054 100644
>> --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-ubnt-xm.c
>> +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-ubnt-xm.c
>> @@ -12,6 +12,7 @@
>>     #include 
>>   #include 
>> +#include 
>>   #include 
>>   #include 
>>   #include 
>> @@ -503,6 +504,60

Re: [LEDE-DEV] [PATCH] jshn: add functionality to read big JSON

2018-01-17 Thread John Crispin 



On 07/01/18 18:08, Christian Beier wrote:

The existing read functionality feeds the complete JSON to jshn as a
cmdline argument, leading to `-ash: jshn: Argument list too long`
errors for JSONs bigger than ca. 100KB.

This commit adds the ability to read the JSON directly from a file if
wanted, removing this shell-imposed size limit.

Tested on x86-64 and ar71xx. An mmap()-based solution was also evaluated,
but found to make no performance difference on either platform.

Signed-off-by: Christian Beier 


Hi Christian,

comment inline ...


---
  jshn.c | 30 --
  sh/jshn.sh |  4 
  2 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/jshn.c b/jshn.c
index 3188af5..eb72fb7 100644
--- a/jshn.c
+++ b/jshn.c
@@ -25,6 +25,8 @@
  #include 
  #include 
  #include 
+#include 
+#include 
  #include "list.h"
  
  #include "avl.h"

@@ -305,7 +307,7 @@ out:
  
  static int usage(const char *progname)

  {
-   fprintf(stderr, "Usage: %s [-n] [-i] -r |-w\n", progname);
+   fprintf(stderr, "Usage: %s [-n] [-i] -r |-R |-w\n", 
progname);
return 2;
  }
  
@@ -338,6 +340,10 @@ int main(int argc, char **argv)

struct env_var *vars;
int i;
int ch;
+   int fd;
+   struct stat sb;
+   char *fbuf;
+   int ret;
  
  	avl_init(_vars, avl_strcmp_var, false, NULL);

for (i = 0; environ[i]; i++);
@@ -359,7 +365,7 @@ int main(int argc, char **argv)
avl_insert(_vars, [i].avl);
}
  
-	while ((ch = getopt(argc, argv, "p:nir:w")) != -1) {

+   while ((ch = getopt(argc, argv, "p:nir:R:w")) != -1) {
switch(ch) {
case 'p':
var_prefix = optarg;
@@ -367,6 +373,26 @@ int main(int argc, char **argv)
break;
case 'r':
return jshn_parse(optarg);
+   case 'R':
+   if ((fd = open(optarg, O_RDONLY)) == -1) {
+   fprintf(stderr, "Error opening %s\n", optarg);
+   return 3;
+   }
+   if (fstat(fd, ) == -1) {
+   fprintf(stderr, "Error getting size of %s\n", 
optarg);
+   close(fd);
+   return 3;
+   }
+   if (!(fbuf = malloc(sb.st_size)) || read(fd, fbuf, 
sb.st_size) != sb.st_size) {
+   fprintf(stderr, "Error reading %s\n", optarg);
+   free(fbuf);


this will blow up if the malloc fails. please spli the if clause up into 
2 blocks


    John


+   close(fd);
+   return 3;
+   }
+   ret = jshn_parse(fbuf);
+   free(fbuf);
+   close(fd);
+   return ret;
case 'w':
return jshn_format(no_newline, indent);
case 'n':
diff --git a/sh/jshn.sh b/sh/jshn.sh
index 1090814..66baccb 100644
--- a/sh/jshn.sh
+++ b/sh/jshn.sh
@@ -180,6 +180,10 @@ json_load() {
eval "`jshn -r "$1"`"
  }
  
+json_load_file() {

+   eval "`jshn -R "$1"`"
+}
+
  json_dump() {
jshn "$@" ${JSON_PREFIX:+-p "$JSON_PREFIX"} -w
  }



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] ipq806x: replace linux, part-probe with a proper partitions subnode

2018-01-17 Thread John Crispin 



On 16/01/18 20:34, Stefan Lippers-Hollmann wrote:

Hi

On 2018-01-11, Rafał Miłecki wrote:

From: Rafał Miłecki 

This solution is more upstream compatible as it only requires specifying
of_match_table in the parser code and doesn't depend on linux,part-probe
which is solution made generic by a LEDE downstream patch that can't be
upstreamed.

[...]

Tested-by: Stefan Lippers-Hollmann 


Acked-by: John Crispin 


[0.00] OF: fdt:Machine model: ZyXEL NBG6817
...
[0.00] Kernel command line: rootfstype=squashfs,ext4 rootwait noinitrd 
root=/dev/mmcblk0p8
[0.00] Bootloader command line (ignored): board=NBG6817 
root=/dev/mmcblk0p8 rootwait zld_ver=2.04 console=ttyHSL1,115200n8 
mtdparts=m25p80:0xC(SBL)ro,0x4(TZ)ro,0x4(RPM)ro,0x8(u-boot)ro,0x1(env)ro,0x1(ART)ro,0x1(dualflag),0x21(reserved)
...
[1.136985] spi_qup 1a28.spi: IN:block:16, fifo:64, OUT:block:16, fifo:64
[1.138996] m25p80 spi32766.0: mx25u3235f (4096 Kbytes)
[1.144963] 13 qcom-smem partitions found on MTD device spi32766.0
[1.149927] Creating 13 MTD partitions on "spi32766.0":
[1.156097] 0x-0x0002 : "0:SBL1"
[1.162380] 0x0002-0x0004 : "0:MIBIB"
[1.167429] 0x0004-0x0006 : "0:SBL2"
[1.172427] 0x0006-0x000a : "0:SBL3"
[1.177536] 0x000a-0x000b : "0:DDRCONFIG"
[1.182473] 0x000b-0x000c : "0:SSD"
[1.187679] 0x000c-0x0010 : "0:TZ"
[1.192342] 0x0010-0x0014 : "0:RPM"
[1.197190] 0x0014-0x001c : "0:APPSBL"
[1.202027] 0x001c-0x001d : "0:APPSBLENV"
[1.207300] 0x001d-0x001e : "0:ART"
[1.212693] 0x001e-0x001f : "0:DUAL_FLAG"
[1.217453] 0x001f-0x0040 : "0:RESERVED"

Regards
Stefan Lippers-Hollmann

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] ar71xx: add support for Ubiquiti Litebeam M5

2018-01-17 Thread John Crispin 



On 16/01/18 21:43, Arne Zachlod wrote:

Specification:
- SoC: Atheros AR9342
- Flash: 8 MiB
- RAM: 64 MiB
- UART: 1x UART on PCB - 115200 8N1
- Ethernet: 1 x 100 Mbit with passive PoE (24V/0.2A)

Doesn't work:
* Flash via TFTP with Uiquiti Uboot

Installation via vendor firmware:
- upload factory image via webinterface

Signed-off-by: Arne Zachlod 


Hi Arne,

comments inline ...


---
  target/linux/ar71xx/base-files/etc/board.d/01_leds |  5 ++
  .../linux/ar71xx/base-files/etc/board.d/02_network |  1 +
  target/linux/ar71xx/base-files/etc/diag.sh |  3 ++
  target/linux/ar71xx/base-files/lib/ar71xx.sh   |  3 ++
  .../ar71xx/base-files/lib/upgrade/platform.sh  |  1 +
  .../ar71xx/files/arch/mips/ath79/mach-ubnt-xm.c| 58 ++
  .../linux/ar71xx/files/arch/mips/ath79/machtypes.h |  1 +
  target/linux/ar71xx/image/ubnt.mk  |  7 +++
  8 files changed, 79 insertions(+)

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 e5baa90db8..79fc8ec5e2 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -147,6 +147,11 @@ rocket-m-xw)
ucidef_set_led_rssi "rssimediumhigh" "RSSIMEDIUMHIGH" "ubnt:green:link3" "wlan0" "51" "100" 
"-50" "13"
ucidef_set_led_rssi "rssihigh" "RSSIHIGH" "ubnt:green:link4" "wlan0" "76" "100" 
"-75" "13"
;;
+lbe-m5)
+   ucidef_set_led_netdev "lan" "LAN" "ubnt:green:lan" "eth0"
+   ucidef_set_led_wlan "wlan" "WLAN" "ubnt:green:wlan" "phy0tpt"
+   ucidef_set_led_default "sys" "SYS" "ubnt:green:sys" "1"
+   ;;


alphabetical ordering please


  rocket-m-ti)
ucidef_set_led_rssi "rssiverylow" "RSSIVERYLOW" "ubnt:green:link1" "wlan0" "1" "100" 
"0" "13"
ucidef_set_led_rssi "rssilow" "RSSILOW" "ubnt:green:link2" "wlan0" "26" "100" 
"-25" "13"
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 fb61792bf4..86d6ffd91d 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -78,6 +78,7 @@ ar71xx_setup_interfaces()
fritz300e|\
gl-usb150|\
hiveap-121|\
+   lbe-m5|\
loco-m-xw|\
mr12|\
mr16|\
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh 
b/target/linux/ar71xx/base-files/etc/diag.sh
index 6cbb3576d8..f37541c75f 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -103,6 +103,9 @@ get_status_led() {
rocket-m-xw)
status_led="ubnt:green:link4"
;;
+   lbe-m5)
+   status_led="ubnt:green:sys"
+   ;;



alphabetical ordering please

rocket-m-ti)
status_led="ubnt:green:link6"
;;
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh 
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index b5440230a5..00a4acc6e0 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -711,6 +711,9 @@ ar71xx_board_detect() {
*"Lima"*)
name="lima"
;;
+   *"Litebeam M5"*)
+   name="lbe-m5"
+   ;;
*"Loco M XW")
name="loco-m-xw"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh 
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index ecf6820a2b..4e839f12c1 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -248,6 +248,7 @@ platform_check_image() {
hiwifi-hc6361|\
hornet-ub-x2|\
jwap230|\
+   lbe-m5|\
lima|\
loco-m-xw|\
mzk-w04nu|\
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-ubnt-xm.c 
b/target/linux/ar71xx/files/arch/mips/ath79/mach-ubnt-xm.c
index 55cf52d19e..8afb3ad054 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-ubnt-xm.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-ubnt-xm.c
@@ -12,6 +12,7 @@
  
  #include 

  #include 
+#include 
  #include 
  #include 
  #include 
@@ -503,6 +504,60 @@ static void __init ubnt_loco_m_xw_setup(void)
ath79_register_eth(0);
  }
  
+#define UBNT_LBE_M5_GPIO_LED_LAN		13

+#define UBNT_LBE_M5_GPIO_LED_WLAN  14
+#define UBNT_LBE_M5_GPIO_LED_SYS   16
+
+static struct gpio_led ubnt_lbe_m5_leds_gpio[] __initdata = {
+   {
+   .name   = "ubnt:green:lan",
+   .gpio   = UBNT_LBE_M5_GPIO_LED_LAN,
+   .active_low = 1,
+   }, {
+   .name   = "ubnt:green:wlan",
+   .gpio   = UBNT_LBE_M5_GPIO_LED_WLAN,
+   .active_low = 1,
+   }, {
+   .name   =

Re: [LEDE-DEV] [PATCH] procd: add timing to start/stop logging

2018-01-17 Thread John Crispin 



On 16/01/18 10:49, Karl Vogel wrote:

Shows how long an initd task took, for example:

  procd: stop /etc/init.d/dropbear running - took 0.088824 us
  procd: Update service dnsmasq
  procd: Update instance dnsmasq::dnsmasq
  procd: running /etc/init.d/dnsmasq running
  procd: start /etc/init.d/dnsmasq running
  procd: stop /etc/init.d/dnsmasq running - took 0.092586 us

Hi Karl,

nitpicks inline...


Signed-off-by: Karl Vogel 
---
  rcS.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/rcS.c b/rcS.c
index dd3b76d..59c9038 100644
--- a/rcS.c
+++ b/rcS.c
@@ -37,6 +37,7 @@ static struct runqueue q, r;
  struct initd {
struct ustream_fd fd;
struct runqueue_process proc;
+   struct timeval tstart;


call it tv_start please


char *file;
char *param;
  };
@@ -70,6 +71,7 @@ static void q_initd_run(struct runqueue *q, struct 
runqueue_task *t)
int pipefd[2];
pid_t pid;
  
+	gettimeofday(>tstart, NULL);

DEBUG(2, "start %s %s \n", s->file, s->param);
if (pipe(pipefd) == -1) {
ERROR("Failed to create pipe: %m\n");
@@ -106,8 +108,11 @@ static void q_initd_run(struct runqueue *q, struct 
runqueue_task *t)
  static void q_initd_complete(struct runqueue *q, struct runqueue_task *p)
  {
struct initd *s = container_of(p, struct initd, proc.task);
+   struct timeval tstop, tres;


tv_stop and tv_res

  
-	DEBUG(2, "stop %s %s \n", s->file, s->param);

+   gettimeofday(, NULL);
+   timersub(, >tstart, );
+   DEBUG(2, "stop %s %s - took %lu.%06lu us\n", s->file, s->param, 
tres.tv_sec, tres.tv_usec);


the unit should be seconds and not usecs ?!

    John



ustream_free(>fd.stream);
close(s->fd.fd.fd);
free(s);



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev