From Alexey.Brodkin at synopsys.com  Wed Jun  1 00:56:32 2016
From: Alexey.Brodkin at synopsys.com (Alexey Brodkin)
Date: Wed, 1 Jun 2016 07:56:32 +0000
Subject: [LEDE-DEV] [PATCH] package/util-linux: Fix libmount build under
	uClibc
In-Reply-To: <1464606749.3125.16.camel@synopsys.com>
References: <1464014781-25347-1-git-send-email-abrodkin@synopsys.com>
 <1464263742.4578.22.camel@synopsys.com>
 <1464606749.3125.16.camel@synopsys.com>
Message-ID: <1464767753.3171.18.camel@synopsys.com>

Hi Waldemar,

On Mon, 2016-05-30 at 14:12 +0300, Alexey Brodkin wrote:
> Hello,
> 
> On Thu, 2016-05-26 at 14:55 +0300, Alexey Brodkin wrote:
> > 
> > Hello,
> > 
> > On Mon, 2016-05-23 at 17:46 +0300, Alexey Brodkin wrote:
> > > 
> > > 
> > > This fixes util-linux building with uClibc.
> > > Patch is taken as it is from Buildroot:
> > > https://git.busybox.net/buildroot/plain/package/util-linux/0001-Fix-libmount-build-under-uClibc.patch?id=baccb506a
> > > 6f
> > > ea
> > > bf114623866568121f49712f5df
> > > 
> > > Signed-off-by: Alexey Brodkin <abrodkin at synopsys.com>
> > > ---
> > > ?.../004-Fix-libmount-build-under-uClibc.patch??????| 153 +++++++++++++++++++++
> > > ?1 file changed, 153 insertions(+)
> > > ?create mode 100644 package/utils/util-linux/patches/004-Fix-libmount-build-under-uClibc.patch

We are discussing one issue with "util-linux" package building.
The problem is in "util-linux" wants to use alloc modifier (either "%as"
or "%ms") in scanf().

Looks like uClibc still doesn't support neither "%ms" nor "%as" (this one
is obsolete glibc-specific so let's not bother with it anyways).

Now to work-around this missing requirement we used to use
an off-the-tree patch like this one in Buildroot:
https://git.busybox.net/buildroot/tree/package/util-linux/0001-Fix-libmount-build-under-uClibc.patch

OpenWRT:
https://git.lede-project.org/?p=source.git;a=blob;f=package/utils/util-linux/patches/001-no-printf-alloc.patch;h=ad9eef0
959bf0c8ce269e8039d4d05ef58e1d527;hb=8a7b28071fba84e297796c46d46e12b0967804e8

Gentoo:
https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-apps/util-linux/files/util-linux-2.21.1-no-printf-alloc.pat
ch?revision=1.2

The question to you is where do you think we should fix mentioned problem:
?1) In uClibc-ng with addition of "%ms" support in scanf or
?2) Try to upstream mentioned patch in "util-linux"?

Regards,
Alexey

From dirk.feytons at gmail.com  Wed Jun  1 01:43:10 2016
From: dirk.feytons at gmail.com (Dirk Feytons)
Date: Wed, 1 Jun 2016 10:43:10 +0200
Subject: [LEDE-DEV] [OpenWrt]  TR-069 for OpenWrt
In-Reply-To: <BL2PR02MB20352048D4C5325CE07E286B91450@BL2PR02MB2035.namprd02.prod.outlook.com>
References: <SN1PR02MB2048BABBC48A9B5510BC1E8191410@SN1PR02MB2048.namprd02.prod.outlook.com>
 <264724c0-8778-1f31-f054-3a0375103ba2@nbd.name>
 <BL2PR02MB20352048D4C5325CE07E286B91450@BL2PR02MB2035.namprd02.prod.outlook.com>
Message-ID: <CAEdzpzesiT-HdQUJ+Vvih3Yxq+Zbs49YVPvzPY86PO7G48VuZQ@mail.gmail.com>

On 30 May 2016 at 11:58, Delbar Jos <Jos.Delbar at technicolor.com> wrote:
>
> Felix Fietkau <mailto:nbd at nbd.name> wrote:
> > > We are conscious of the fact that together with the proposals made by
> > > Felix, Luka and Wojtek we are now looking at many "competing" proposals.
> > > As a next step, we recommend to organize a workshop, at a practical
> > > location and time, where we put everything on the table and define the
> > > most appropriate path forward to the benefit of OpenWrt as a whole.
> > I think such a workshop would be a great idea. It would be nice to have the
> > code available for review some time before that workshop, so we can all take
> > a detailed look at the various proposals before we sit down and decide how
> > to move forward with this.
>
> I agree that would be helpful. In our case it will take us some weeks before we can formally release sources. We will be able to share documentation on architecture, API, features, etc. up front to get the discussions going.

At the Lua Workshop last year I presented how we're using Lua in our
gateways. One of the items is how we implement the TR-069 datamodels
in OpenWrt. The talk was recorded and is available at
https://www.youtube.com/watch?v=zVzEmewJG8I


Dirk F.


From jo at mein.io  Wed Jun  1 06:49:24 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Wed, 1 Jun 2016 15:49:24 +0200
Subject: [LEDE-DEV] [PATCH] netifd: Add option to configure
 gc_stale_time for each device
In-Reply-To: <1464102140-1439-1-git-send-email-alin.nastac@gmail.com>
References: <1464102140-1439-1-git-send-email-alin.nastac@gmail.com>
Message-ID: <a145a246-bfc9-3fb8-69f0-01676c16eb90@mein.io>

Hi Alin,

pulled into netifd.git after some slight rebasing:
http://git.openwrt.org/?p=project/netifd.git;a=commitdiff;h=fef10041f3a495d79f03f99bdf416a68a0ee91aa

Please verify whether the change is still correct before we bump the
netifd package. Thanks!

~ Jow


From jo at mein.io  Wed Jun  1 07:32:47 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Wed,  1 Jun 2016 16:32:47 +0200
Subject: [LEDE-DEV] [RFC 0/3] x86: populate sysinfo from DMI data
Message-ID: <1464791570-22519-1-git-send-email-jo@mein.io>

This is a simple patch series I use locally to better identify x86 devices,
I'd appreciate any opinions and testing feedback on it.

Jo-Philipp Wich (3):
  x86: enable CONFIG_DEVMEM
  packages: import dmidecode
  x86: include dmidecode by default and use it to populate sysinfo

 package/utils/dmidecode/Makefile                   | 48 ++++++++++++++++++++++
 target/linux/x86/Makefile                          |  2 +-
 target/linux/x86/base-files/lib/preinit/20_sysinfo | 18 ++++++++
 target/linux/x86/config-4.4                        |  1 +
 4 files changed, 68 insertions(+), 1 deletion(-)
 create mode 100644 package/utils/dmidecode/Makefile
 create mode 100644 target/linux/x86/base-files/lib/preinit/20_sysinfo

-- 
2.1.4



From jo at mein.io  Wed Jun  1 07:32:49 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Wed,  1 Jun 2016 16:32:49 +0200
Subject: [LEDE-DEV] [RFC 2/3] packages: import dmidecode
In-Reply-To: <1464791570-22519-1-git-send-email-jo@mein.io>
References: <1464791570-22519-1-git-send-email-jo@mein.io>
Message-ID: <1464791570-22519-3-git-send-email-jo@mein.io>

Import the dmidecode utility from the packages feed so that we can include it
by default on x86 builds.

Signed-off-by: Jo-Philipp Wich <jo at mein.io>
---
 package/utils/dmidecode/Makefile | 48 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 48 insertions(+)
 create mode 100644 package/utils/dmidecode/Makefile

diff --git a/package/utils/dmidecode/Makefile b/package/utils/dmidecode/Makefile
new file mode 100644
index 0000000..2dda5a0
--- /dev/null
+++ b/package/utils/dmidecode/Makefile
@@ -0,0 +1,48 @@
+#
+# Copyright (C) 2007-2015 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:=dmidecode
+PKG_VERSION:=3.0
+PKG_RELEASE:=1
+
+PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
+PKG_SOURCE_URL:=http://download.savannah.gnu.org/releases/dmidecode
+PKG_MD5SUM:=be7501ad0f844e875976b96106afaa3c
+PKG_MAINTAINER:=?lvaro Fern?ndez Rojas <noltari at gmail.com>
+
+PKG_LICENSE:=GPL-2.0
+PKG_LICENSE_FILES:=LICENSE
+
+PKG_INSTALL:=1
+
+include $(INCLUDE_DIR)/package.mk
+
+define Package/dmidecode
+  SECTION:=utils
+  CATEGORY:=Utilities
+  DEPENDS:=@(TARGET_x86||TARGET_x86_64)
+  TITLE:=Displays BIOS informations.
+  URL:=http://www.nongnu.org/dmidecode/
+endef
+
+define Package/dmidecode/description
+	Dmidecode reports information about your system's hardware
+	as described in your system BIOS according to the SMBIOS/DMI
+	standard.
+endef
+
+MAKE_FLAGS += \
+	prefix="/usr"
+
+define Package/dmidecode/install
+	$(INSTALL_DIR) $(1)/usr/sbin
+	$(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/sbin/$(PKG_NAME) $(1)/usr/sbin/
+endef
+
+$(eval $(call BuildPackage,dmidecode))
-- 
2.1.4



From jo at mein.io  Wed Jun  1 07:32:48 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Wed,  1 Jun 2016 16:32:48 +0200
Subject: [LEDE-DEV] [RFC 1/3] x86: enable CONFIG_DEVMEM
In-Reply-To: <1464791570-22519-1-git-send-email-jo@mein.io>
References: <1464791570-22519-1-git-send-email-jo@mein.io>
Message-ID: <1464791570-22519-2-git-send-email-jo@mein.io>

Enable support for /dev/mem in the kernel since it is required by the
dmidecode utility.

Signed-off-by: Jo-Philipp Wich <jo at mein.io>
---
 target/linux/x86/config-4.4 | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/linux/x86/config-4.4 b/target/linux/x86/config-4.4
index 5b54031..f1a3218 100644
--- a/target/linux/x86/config-4.4
+++ b/target/linux/x86/config-4.4
@@ -98,6 +98,7 @@ CONFIG_DECOMPRESS_BZIP2=y
 CONFIG_DECOMPRESS_GZIP=y
 CONFIG_DEFAULT_IO_DELAY_TYPE=0
 # CONFIG_DELL_RBU is not set
+CONFIG_DEVMEM=y
 # CONFIG_DMI is not set
 CONFIG_DNOTIFY=y
 CONFIG_DUMMY_CONSOLE=y
-- 
2.1.4



From jo at mein.io  Wed Jun  1 07:32:50 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Wed,  1 Jun 2016 16:32:50 +0200
Subject: [LEDE-DEV] [RFC 3/3] x86: include dmidecode by default and use it
	to populate sysinfo
In-Reply-To: <1464791570-22519-1-git-send-email-jo@mein.io>
References: <1464791570-22519-1-git-send-email-jo@mein.io>
Message-ID: <1464791570-22519-4-git-send-email-jo@mein.io>

Use the dmidecode utility to extract manufacturer and model info from the
system DMI data and write it to /tmp/sysinfo/.

The data will be picked up by board_detect and can be used by e.g. LuCI to
display a more appropriate model description.

On an APU board the files will contain the following values:

    # cat /tmp/sysinfo/model
    PC Engines APU

    # cat /tmp/sysinfo/board_name
    pc-engines-apu

Signed-off-by: Jo-Philipp Wich <jo at mein.io>
---
 target/linux/x86/Makefile                          |  2 +-
 target/linux/x86/base-files/lib/preinit/20_sysinfo | 18 ++++++++++++++++++
 2 files changed, 19 insertions(+), 1 deletion(-)
 create mode 100644 target/linux/x86/base-files/lib/preinit/20_sysinfo

diff --git a/target/linux/x86/Makefile b/target/linux/x86/Makefile
index 1eae227..7e397ab 100644
--- a/target/linux/x86/Makefile
+++ b/target/linux/x86/Makefile
@@ -13,7 +13,7 @@ FEATURES:=squashfs ext4 vdi vmdk pcmcia targz
 SUBTARGETS=generic xen_domu geode 64
 MAINTAINER:=Felix Fietkau <nbd at openwrt.org>
 
-DEFAULT_PACKAGES += partx-utils
+DEFAULT_PACKAGES += partx-utils dmidecode
 
 KERNEL_PATCHVER:=4.4
 
diff --git a/target/linux/x86/base-files/lib/preinit/20_sysinfo b/target/linux/x86/base-files/lib/preinit/20_sysinfo
new file mode 100644
index 0000000..ab2fbeb
--- /dev/null
+++ b/target/linux/x86/base-files/lib/preinit/20_sysinfo
@@ -0,0 +1,18 @@
+do_sysinfo_x86() {
+	local manufacturer productname boardname
+
+	[ -x /usr/sbin/dmidecode ] || return
+
+	manufacturer="$(dmidecode -s system-manufacturer 2>/dev/null)"
+	productname="$(dmidecode -s system-product-name 2>/dev/null)"
+
+	[ -n "$manufacturer" -a -n "$productname" ] || return
+
+	boardname="$(printf "%s %s" "$manufacturer" "$productname" | tr 'A-Z' 'a-z' | tr -cs 'a-z0-9_-' '-')"
+
+	mkdir -p /tmp/sysinfo
+	echo "$boardname" > /tmp/sysinfo/board_name
+	echo "$manufacturer $productname" > /tmp/sysinfo/model
+}
+
+boot_hook_add preinit_main do_sysinfo_x86
-- 
2.1.4



From lynxis at fe80.eu  Wed Jun  1 07:51:47 2016
From: lynxis at fe80.eu (Alexander Couzens)
Date: Wed, 1 Jun 2016 16:51:47 +0200
Subject: [LEDE-DEV] [RFC 0/3] x86: populate sysinfo from DMI data
In-Reply-To: <1464791570-22519-1-git-send-email-jo@mein.io>
References: <1464791570-22519-1-git-send-email-jo@mein.io>
Message-ID: <20160601165147.73561c86@lazus.yip>

On Wed,  1 Jun 2016 16:32:47 +0200
Jo-Philipp Wich <jo at mein.io> wrote:

> This is a simple patch series I use locally to better identify x86
> devices, I'd appreciate any opinions and testing feedback on it.
> 
> Jo-Philipp Wich (3):
>   x86: enable CONFIG_DEVMEM
>   packages: import dmidecode
>   x86: include dmidecode by default and use it to populate sysinfo

You can use sysfs instead of devmem.

config DMI_SYSFS
        tristate "DMI table support in sysfs"
        depends on SYSFS && DMI
        default n
        help
          Say Y or M here to enable the exporting of the raw DMI table
          data via sysfs.  This is useful for consuming the data without
          requiring any access to /dev/mem at all.  Tables are found
          under /sys/firmware/dmi when this option is enabled and
          loaded.

There is also an dmi parser, because some drivers depend on DMI
informations.

/sys/devices/virtual/dmi/id
bios_date
bios_vendor
bios_version
board_asset_tag
board_name
board_serial
board_vendor
board_version
chassis_asset_tag
chassis_serial
chassis_type
chassis_vendor
chassis_version
modalias
power
product_name
product_serial
product_uuid
product_version
subsystem
sys_vendor
uevent

Best,
lynxis
-- 
Alexander Couzens

mail: lynxis at fe80.eu
jabber: lynxis at fe80.eu
mobile: +4915123277221
gpg: 390D CF78 8BF9 AA50 4F8F  F1E2 C29E 9DA6 A0DF 8604
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20160601/c39661b0/attachment.sig>

From jo at mein.io  Wed Jun  1 08:09:45 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Wed,  1 Jun 2016 17:09:45 +0200
Subject: [LEDE-DEV] [RFC v2 1/2] x86: enable DMI and DMI_SYSFS
In-Reply-To: <1464793786-27075-1-git-send-email-jo@mein.io>
References: <1464793786-27075-1-git-send-email-jo@mein.io>
Message-ID: <1464793786-27075-2-git-send-email-jo@mein.io>

Enable support for DMI decoding in the kernel so that we can access
manufacturer and model information via sysfs.

Signed-off-by: Jo-Philipp Wich <jo at mein.io>
---
 target/linux/x86/config-4.4 | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/target/linux/x86/config-4.4 b/target/linux/x86/config-4.4
index 5b54031..bb6ef65 100644
--- a/target/linux/x86/config-4.4
+++ b/target/linux/x86/config-4.4
@@ -98,7 +98,8 @@ CONFIG_DECOMPRESS_BZIP2=y
 CONFIG_DECOMPRESS_GZIP=y
 CONFIG_DEFAULT_IO_DELAY_TYPE=0
 # CONFIG_DELL_RBU is not set
-# CONFIG_DMI is not set
+CONFIG_DMI=y
+CONFIG_DMI_SYSFS=y
 CONFIG_DNOTIFY=y
 CONFIG_DUMMY_CONSOLE=y
 CONFIG_EARLY_PRINTK=y
-- 
2.1.4



From jo at mein.io  Wed Jun  1 08:09:46 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Wed,  1 Jun 2016 17:09:46 +0200
Subject: [LEDE-DEV] [RFC v2 2/2] x86: use sysfs DMI information to populate
	sysinfo
In-Reply-To: <1464793786-27075-1-git-send-email-jo@mein.io>
References: <1464793786-27075-1-git-send-email-jo@mein.io>
Message-ID: <1464793786-27075-3-git-send-email-jo@mein.io>

Use the DMI data available in sysfs to extract manufacturer and model info
and write it to /tmp/sysinfo/.

The data will be picked up by board_detect and can be used by e.g. LuCI to
display a more appropriate model description.

On an APU board the files will contain the following values:

    # cat /tmp/sysinfo/model
    PC Engines APU

    # cat /tmp/sysinfo/board_name
    pc-engines-apu

Signed-off-by: Jo-Philipp Wich <jo at mein.io>
---
 target/linux/x86/Makefile                          |  2 +-
 target/linux/x86/base-files/lib/preinit/20_sysinfo | 18 ++++++++++++++++++
 2 files changed, 19 insertions(+), 1 deletion(-)
 create mode 100644 target/linux/x86/base-files/lib/preinit/20_sysinfo

diff --git a/target/linux/x86/Makefile b/target/linux/x86/Makefile
index 1eae227..7e397ab 100644
--- a/target/linux/x86/Makefile
+++ b/target/linux/x86/Makefile
@@ -13,7 +13,7 @@ FEATURES:=squashfs ext4 vdi vmdk pcmcia targz
 SUBTARGETS=generic xen_domu geode 64
 MAINTAINER:=Felix Fietkau <nbd at openwrt.org>
 
-DEFAULT_PACKAGES += partx-utils
+DEFAULT_PACKAGES += partx-utils dmidecode
 
 KERNEL_PATCHVER:=4.4
 
diff --git a/target/linux/x86/base-files/lib/preinit/20_sysinfo b/target/linux/x86/base-files/lib/preinit/20_sysinfo
new file mode 100644
index 0000000..ab2fbeb
--- /dev/null
+++ b/target/linux/x86/base-files/lib/preinit/20_sysinfo
@@ -0,0 +1,18 @@
+do_sysinfo_x86() {
+	local manufacturer productname boardname
+
+	[ -x /usr/sbin/dmidecode ] || return
+
+	manufacturer="$(dmidecode -s system-manufacturer 2>/dev/null)"
+	productname="$(dmidecode -s system-product-name 2>/dev/null)"
+
+	[ -n "$manufacturer" -a -n "$productname" ] || return
+
+	boardname="$(printf "%s %s" "$manufacturer" "$productname" | tr 'A-Z' 'a-z' | tr -cs 'a-z0-9_-' '-')"
+
+	mkdir -p /tmp/sysinfo
+	echo "$boardname" > /tmp/sysinfo/board_name
+	echo "$manufacturer $productname" > /tmp/sysinfo/model
+}
+
+boot_hook_add preinit_main do_sysinfo_x86
-- 
2.1.4



From jo at mein.io  Wed Jun  1 08:09:44 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Wed,  1 Jun 2016 17:09:44 +0200
Subject: [LEDE-DEV] [RFC v2 0/2] x86: populate sysinfo from DMI data
Message-ID: <1464793786-27075-1-git-send-email-jo@mein.io>

This is a simple patch series I use locally to better identify x86 devices,
I'd appreciate any opinions and testing feedback on it.

Changes in v2:
Use sysfs instead of dmidecode

Jo-Philipp Wich (2):
  x86: enable DMI and DMI_SYSFS
  x86: use sysfs DMI information to populate sysinfo

 target/linux/x86/Makefile                          |  2 +-
 target/linux/x86/base-files/lib/preinit/20_sysinfo | 18 ++++++++++++++++++
 target/linux/x86/config-4.4                        |  3 ++-
 3 files changed, 21 insertions(+), 2 deletions(-)
 create mode 100644 target/linux/x86/base-files/lib/preinit/20_sysinfo

-- 
2.1.4



From jo at wwsnet.net  Wed Jun  1 08:10:50 2016
From: jo at wwsnet.net (Jo-Philipp Wich)
Date: Wed, 1 Jun 2016 17:10:50 +0200
Subject: [LEDE-DEV] [RFC v2 2/2] x86: use sysfs DMI information to
	populate sysinfo
In-Reply-To: <1464793786-27075-3-git-send-email-jo@mein.io>
References: <1464793786-27075-1-git-send-email-jo@mein.io>
 <1464793786-27075-3-git-send-email-jo@mein.io>
Message-ID: <359beaee-e3d5-5f02-0174-e1cf26be3716@wwsnet.net>

Please ignore, I exported the wrong series.


From jo at mein.io  Wed Jun  1 08:14:33 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Wed,  1 Jun 2016 17:14:33 +0200
Subject: [LEDE-DEV] [RFC v3 1/2] x86: enable DMI and DMI_SYSFS
In-Reply-To: <1464794074-27276-1-git-send-email-jo@mein.io>
References: <1464794074-27276-1-git-send-email-jo@mein.io>
Message-ID: <1464794074-27276-2-git-send-email-jo@mein.io>

Enable support for DMI decoding in the kernel so that we can access
manufacturer and model information via sysfs.

Signed-off-by: Jo-Philipp Wich <jo at mein.io>
---
 target/linux/x86/config-4.4 | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/target/linux/x86/config-4.4 b/target/linux/x86/config-4.4
index 5b54031..bb6ef65 100644
--- a/target/linux/x86/config-4.4
+++ b/target/linux/x86/config-4.4
@@ -98,7 +98,8 @@ CONFIG_DECOMPRESS_BZIP2=y
 CONFIG_DECOMPRESS_GZIP=y
 CONFIG_DEFAULT_IO_DELAY_TYPE=0
 # CONFIG_DELL_RBU is not set
-# CONFIG_DMI is not set
+CONFIG_DMI=y
+CONFIG_DMI_SYSFS=y
 CONFIG_DNOTIFY=y
 CONFIG_DUMMY_CONSOLE=y
 CONFIG_EARLY_PRINTK=y
-- 
2.1.4



From jo at mein.io  Wed Jun  1 08:14:32 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Wed,  1 Jun 2016 17:14:32 +0200
Subject: [LEDE-DEV] [RFC v3 0/2] x86: populate sysinfo from DMI data
Message-ID: <1464794074-27276-1-git-send-email-jo@mein.io>

This is a simple patch series I use locally to better identify x86 devices,
I'd appreciate any opinions and testing feedback on it.

Changes in v3:
Use sysfs instead of dmidecode

Jo-Philipp Wich (2):
  x86: enable DMI and DMI_SYSFS
  x86: use sysfs DMI information to populate sysinfo

 target/linux/x86/base-files/lib/preinit/20_sysinfo | 16 ++++++++++++++++
 target/linux/x86/config-4.4                        |  3 ++-
 2 files changed, 18 insertions(+), 1 deletion(-)
 create mode 100644 target/linux/x86/base-files/lib/preinit/20_sysinfo

-- 
2.1.4



From jo at mein.io  Wed Jun  1 08:14:34 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Wed,  1 Jun 2016 17:14:34 +0200
Subject: [LEDE-DEV] [RFC v3 2/2] x86: use sysfs DMI information to populate
	sysinfo
In-Reply-To: <1464794074-27276-1-git-send-email-jo@mein.io>
References: <1464794074-27276-1-git-send-email-jo@mein.io>
Message-ID: <1464794074-27276-3-git-send-email-jo@mein.io>

Use the DMI data available in sysfs to extract manufacturer and model info
and write it to /tmp/sysinfo/.

The data will be picked up by board_detect and can be used by e.g. LuCI to
display a more appropriate model description.

On an APU board the files will contain the following values:

    # cat /tmp/sysinfo/model
    PC Engines APU

    # cat /tmp/sysinfo/board_name
    pc-engines-apu

Signed-off-by: Jo-Philipp Wich <jo at mein.io>
---
 target/linux/x86/base-files/lib/preinit/20_sysinfo | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)
 create mode 100644 target/linux/x86/base-files/lib/preinit/20_sysinfo

diff --git a/target/linux/x86/base-files/lib/preinit/20_sysinfo b/target/linux/x86/base-files/lib/preinit/20_sysinfo
new file mode 100644
index 0000000..0b836ce
--- /dev/null
+++ b/target/linux/x86/base-files/lib/preinit/20_sysinfo
@@ -0,0 +1,16 @@
+do_sysinfo_x86() {
+	local vendor product boardname
+
+	vendor="$(cat /sys/devices/virtual/dmi/id/sys_vendor 2>/dev/null)"
+	product="$(cat /sys/devices/virtual/dmi/id/product_name 2>/dev/null)"
+
+	[ -n "$vendor" -a -n "$product" ] || return
+
+	boardname="$(printf "%s %s" "$vendor" "$product" | tr 'A-Z' 'a-z' | tr -cs 'a-z0-9_-' '-')"
+
+	mkdir -p /tmp/sysinfo
+	echo "$boardname" > /tmp/sysinfo/board_name
+	echo "$vendor $product" > /tmp/sysinfo/model
+}
+
+boot_hook_add preinit_main do_sysinfo_x86
-- 
2.1.4



From Alexey.Brodkin at synopsys.com  Wed Jun  1 08:32:38 2016
From: Alexey.Brodkin at synopsys.com (Alexey Brodkin)
Date: Wed,  1 Jun 2016 18:32:38 +0300
Subject: [LEDE-DEV] [PATCH] package/devel/gdb: Add support of ARC gdb
Message-ID: <1464795158-4753-1-git-send-email-abrodkin@synopsys.com>

As of today gdb port for ARC is not yet in upstream even though
we're working hard on that.

Still to allow ARC users to debug user-space apps on top of
Linux kernel we're adding here support for building GDB from
sources hosted on our GitHub here:
https://github.com/foss-for-synopsys-dwc-arc-processors/binutils-gdb/releases/tag/arc-2016.03-gdb

Likewise for host GDB sources that come from unified git repository
(which is the case for upstream binutils/gdb today) we need to disable
building of binutils in gdb:
------>8------
--disable-binutils
--disable-ld
--disable-gas
------>8------

Also we disable sim because if the following breakage while
building with it:
------------>8------------
/usr/bin/env bash ./../common/genmloop.sh -shell /usr/bin/env bash \
    -mono -fast -pbb -switch sem5-switch.c \
    -cpu a5f -infile ./mloop5.in \
    -outfile-suffix 5
unknown option: bash
Makefile:699: recipe for target 'stamp-5mloop' failed
make[7]: *** [stamp-5mloop] Error 1
------------>8------------

Signed-off-by: Alexey Brodkin <abrodkin at synopsys.com>
Cc: John Crispin <john at phrozen.org>
Cc: Felix Fietkau <nbd at nbd.name>
---
 package/devel/gdb/Makefile                         | 23 ++++++++++++++--
 .../001-gdb-pr14523-mips-signal-number.patch       |  0
 .../gdb/patches/{ => 7.11}/100-musl_fix.patch      |  0
 .../patches/arc-2016.03/100-no_extern_inline.patch | 32 ++++++++++++++++++++++
 .../gdb/patches/arc-2016.03/110-no_testsuite.patch | 21 ++++++++++++++
 .../120-fix-compile-flag-mismatch.patch            | 11 ++++++++
 .../arc-2016.03/200-arc-fix-target-mask.patch      | 13 +++++++++
 7 files changed, 98 insertions(+), 2 deletions(-)
 rename package/devel/gdb/patches/{ => 7.11}/001-gdb-pr14523-mips-signal-number.patch (100%)
 rename package/devel/gdb/patches/{ => 7.11}/100-musl_fix.patch (100%)
 create mode 100644 package/devel/gdb/patches/arc-2016.03/100-no_extern_inline.patch
 create mode 100644 package/devel/gdb/patches/arc-2016.03/110-no_testsuite.patch
 create mode 100644 package/devel/gdb/patches/arc-2016.03/120-fix-compile-flag-mismatch.patch
 create mode 100644 package/devel/gdb/patches/arc-2016.03/200-arc-fix-target-mask.patch

diff --git a/package/devel/gdb/Makefile b/package/devel/gdb/Makefile
index f6d5fec..2e6b332 100644
--- a/package/devel/gdb/Makefile
+++ b/package/devel/gdb/Makefile
@@ -8,12 +8,27 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=gdb
+
+ifeq ($(CONFIG_arc),y)
+PKG_VERSION:=arc-2016.03-gdb
+
+PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
+PKG_SOURCE_URL:=https://github.com/foss-for-synopsys-dwc-arc-processors/binutils-gdb/archive/$(PKG_VERSION)
+PKG_MD5SUM:=775caaf6385c16f20b6f53c0a2b95f79
+GDB_DIR:=binutils-$(PKG_NAME)-$(PKG_VERSION)
+else
 PKG_VERSION:=7.11
-PKG_RELEASE:=1
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 PKG_SOURCE_URL:=@GNU/gdb
 PKG_MD5SUM:=b5c784685e1cde65ba135feea86b6d75
+GDB_DIR:=$(PKG_NAME)-$(PKG_VERSION)
+endif
+
+PKG_RELEASE:=1
+
+PATCH_DIR:=./patches/$(PKG_VERSION)
+PKG_BUILD_DIR:=$(BUILD_DIR)/$(GDB_DIR)
 
 PKG_BUILD_PARALLEL:=1
 PKG_INSTALL:=1
@@ -55,7 +70,11 @@ CONFIGURE_ARGS+= \
 	--with-system-readline \
 	--without-expat \
 	--without-lzma \
-	--disable-werror
+	--disable-werror \
+	--disable-binutils \
+	--disable-ld \
+	--disable-gas \
+	--disable-sim
 
 CONFIGURE_VARS+= \
 	ac_cv_search_tgetent="$(TARGET_LDFLAGS) -lncurses -lreadline"
diff --git a/package/devel/gdb/patches/001-gdb-pr14523-mips-signal-number.patch b/package/devel/gdb/patches/7.11/001-gdb-pr14523-mips-signal-number.patch
similarity index 100%
rename from package/devel/gdb/patches/001-gdb-pr14523-mips-signal-number.patch
rename to package/devel/gdb/patches/7.11/001-gdb-pr14523-mips-signal-number.patch
diff --git a/package/devel/gdb/patches/100-musl_fix.patch b/package/devel/gdb/patches/7.11/100-musl_fix.patch
similarity index 100%
rename from package/devel/gdb/patches/100-musl_fix.patch
rename to package/devel/gdb/patches/7.11/100-musl_fix.patch
diff --git a/package/devel/gdb/patches/arc-2016.03/100-no_extern_inline.patch b/package/devel/gdb/patches/arc-2016.03/100-no_extern_inline.patch
new file mode 100644
index 0000000..8c18c6e
--- /dev/null
+++ b/package/devel/gdb/patches/arc-2016.03/100-no_extern_inline.patch
@@ -0,0 +1,32 @@
+--- a/sim/common/sim-arange.c
++++ b/sim/common/sim-arange.c
+@@ -280,11 +280,7 @@ sim_addr_range_delete (ADDR_RANGE *ar, a
+   build_search_tree (ar);
+ }
+ 
+-#endif /* DEFINE_NON_INLINE_P */
+-
+-#if DEFINE_INLINE_P
+-
+-SIM_ARANGE_INLINE int
++int
+ sim_addr_range_hit_p (ADDR_RANGE *ar, address_word addr)
+ {
+   ADDR_RANGE_TREE *t = ar->range_tree;
+@@ -301,4 +297,4 @@ sim_addr_range_hit_p (ADDR_RANGE *ar, ad
+   return 0;
+ }
+ 
+-#endif /* DEFINE_INLINE_P */
++#endif /* DEFINE_NON_INLINE_P */
+--- a/sim/common/sim-arange.h
++++ b/sim/common/sim-arange.h
+@@ -73,7 +73,7 @@ extern void sim_addr_range_delete (ADDR_
+ 
+ /* Return non-zero if ADDR is in range AR, traversing the entire tree.
+    If no range is specified, that is defined to mean "everything".  */
+-SIM_ARANGE_INLINE int
++extern int
+ sim_addr_range_hit_p (ADDR_RANGE * /*ar*/, address_word /*addr*/);
+ #define ADDR_RANGE_HIT_P(ar, addr) \
+   ((ar)->range_tree == NULL || sim_addr_range_hit_p ((ar), (addr)))
diff --git a/package/devel/gdb/patches/arc-2016.03/110-no_testsuite.patch b/package/devel/gdb/patches/arc-2016.03/110-no_testsuite.patch
new file mode 100644
index 0000000..1b284ea
--- /dev/null
+++ b/package/devel/gdb/patches/arc-2016.03/110-no_testsuite.patch
@@ -0,0 +1,21 @@
+--- a/gdb/configure
++++ b/gdb/configure
+@@ -870,8 +870,7 @@ MAKEINFOFLAGS
+ YACC
+ YFLAGS
+ XMKMF'
+-ac_subdirs_all='testsuite
+-gdbtk
++ac_subdirs_all='gdbtk
+ multi-ice
+ gdbserver'
+ 
+@@ -5610,7 +5610,7 @@ $as_echo "$with_auto_load_safe_path" >&6
+ 
+ 
+ 
+-subdirs="$subdirs testsuite"
++subdirs="$subdirs"
+ 
+ 
+ # Check whether to support alternative target configurations
diff --git a/package/devel/gdb/patches/arc-2016.03/120-fix-compile-flag-mismatch.patch b/package/devel/gdb/patches/arc-2016.03/120-fix-compile-flag-mismatch.patch
new file mode 100644
index 0000000..c8b41f2
--- /dev/null
+++ b/package/devel/gdb/patches/arc-2016.03/120-fix-compile-flag-mismatch.patch
@@ -0,0 +1,11 @@
+--- a/gdb/gdbserver/configure
++++ b/gdb/gdbserver/configure
+@@ -2468,7 +2468,7 @@ $as_echo "$as_me: error: \`$ac_var' was
+       ac_cache_corrupted=: ;;
+     ,);;
+     *)
+-      if test "x$ac_old_val" != "x$ac_new_val"; then
++      if test "`echo x$ac_old_val`" != "`echo x$ac_new_val`"; then
+ 	# differences in whitespace do not lead to failure.
+ 	ac_old_val_w=`echo x $ac_old_val`
+ 	ac_new_val_w=`echo x $ac_new_val`
diff --git a/package/devel/gdb/patches/arc-2016.03/200-arc-fix-target-mask.patch b/package/devel/gdb/patches/arc-2016.03/200-arc-fix-target-mask.patch
new file mode 100644
index 0000000..7e51d58
--- /dev/null
+++ b/package/devel/gdb/patches/arc-2016.03/200-arc-fix-target-mask.patch
@@ -0,0 +1,13 @@
+diff --git a/bfd/config.bfd b/bfd/config.bfd
+index 5145d4a..a9c9c99 100644
+--- a/bfd/config.bfd
++++ b/bfd/config.bfd
+@@ -275,7 +275,7 @@ case "${targ}" in
+     targ_defvec=am33_elf32_linux_vec
+     ;;
+ 
+-  arc*-*-elf* | arc*-*-linux-uclibc*)
++  arc*-*-elf* | arc*-*-linux-*)
+     targ_defvec=arc_elf32_le_vec
+     targ_selvecs=arc_elf32_be_vec
+     ;;
-- 
2.5.5



From karlp at tweak.net.au  Wed Jun  1 09:01:44 2016
From: karlp at tweak.net.au (Karl Palsson)
Date: Wed, 01 Jun 2016 16:01:44 -0000
Subject: [LEDE-DEV] [PATCH] _GNU_SOURCE should be defined for building
 vs uClibc
In-Reply-To: <618582be-6dab-c1a4-cbca-73318011cf24@phrozen.org>
References: <618582be-6dab-c1a4-cbca-73318011cf24@phrozen.org>
Message-ID: <JWLTiNjvPvpj6z3KReiT3wgTbJKwn3c64FQG8zXU211c@mailpile>


John Crispin <john at phrozen.org> wrote:
> 
> 
> On 23/05/2016 20:12, Waldemar Brodkorb wrote:
> > Hi John,
> > John Crispin wrote,
> > 
> >> Hi,
> >> is it really a gnu extension or is uclibc b0rked for these symbols ?
> > 
> > I think it isn't b0rked.
> > It was added for ARM GNU libc here under #ifdef __USE_GNU:
> > https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=sysdeps/unix/sysv/linux/arm/bits/fcntl.h;h=aa2d36ca80f0ca4c5793b28b3852ce60b5fe57ef;hp=6a5f89ad1f8bdf8a825fc1e55a84679a86349a6c;hb=adb252daea96e7e160553703d477b76ff6a7781e;hpb=01b5049d107460f5eca797eda983958d1a410ffd
> > 
> > And later moved to generic fcntl.h file. So we are correct here or
> > at least compatible to GNU libc.
> > 
> > best regards
> >  Waldemar
> >  
> 
> ok, i'll merge it later today or in the morning
> 

This still doesn't work on the uclibc in openwrt-CC branch. The
O_PATH definitions are in asm-generic/fcntl.h, which can be
included via linux/fcntl.h, _GNU_SOURCE doesn't get this pulled
in though.

I attempted to add includes for linux/fcntl, but it just gives me
redeclaration errors for struct flock.

Cheers,
Karl P
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP Digital Signature
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20160601/d3c96e4f/attachment.sig>

From dirkneukirchen at web.de  Wed Jun  1 09:13:11 2016
From: dirkneukirchen at web.de (Dirk Neukirchen)
Date: Wed, 1 Jun 2016 18:13:11 +0200
Subject: [LEDE-DEV] [RFC v3 2/2] x86: use sysfs DMI information to
 populate sysinfo
In-Reply-To: <1464794074-27276-3-git-send-email-jo@mein.io>
References: <1464794074-27276-1-git-send-email-jo@mein.io>
 <1464794074-27276-3-git-send-email-jo@mein.io>
Message-ID: <78be9794-1918-e370-1712-8e9cb8ccddd0@web.de>

On 01.06.2016 17:14, Jo-Philipp Wich wrote:
> Use the DMI data available in sysfs to extract manufacturer and model info
> and write it to /tmp/sysinfo/.
> 
> The data will be picked up by board_detect and can be used by e.g. LuCI to
> display a more appropriate model description.
> 
> On an APU board the files will contain the following values:
> 
>     # cat /tmp/sysinfo/model
>     PC Engines APU
> 
>     # cat /tmp/sysinfo/board_name
>     pc-engines-apu
> 
> Signed-off-by: Jo-Philipp Wich <jo at mein.io>
> ---
>  target/linux/x86/base-files/lib/preinit/20_sysinfo | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
>  create mode 100644 target/linux/x86/base-files/lib/preinit/20_sysinfo
> 
> diff --git a/target/linux/x86/base-files/lib/preinit/20_sysinfo b/target/linux/x86/base-files/lib/preinit/20_sysinfo
> new file mode 100644
> index 0000000..0b836ce
> --- /dev/null
> +++ b/target/linux/x86/base-files/lib/preinit/20_sysinfo
> @@ -0,0 +1,16 @@
> +do_sysinfo_x86() {
> +	local vendor product boardname
> +
> +	vendor="$(cat /sys/devices/virtual/dmi/id/sys_vendor 2>/dev/null)"
> +	product="$(cat /sys/devices/virtual/dmi/id/product_name 2>/dev/null)"
> +
> +	[ -n "$vendor" -a -n "$product" ] || return
> +
> +	boardname="$(printf "%s %s" "$vendor" "$product" | tr 'A-Z' 'a-z' | tr -cs 'a-z0-9_-' '-')"
> +
> +	mkdir -p /tmp/sysinfo
> +	echo "$boardname" > /tmp/sysinfo/board_name
> +	echo "$vendor $product" > /tmp/sysinfo/model

Issue 1:
Maybe change up variable naming to keep more in line with sysfs/DMI standards ?
as future reference: [1]

on my normal(?) Intel ATX motherboard both sysfs entries are empty
but board_name & board_vendor exist: I might expect to get /tmp/sysinfo/board_name
from board_* and not from the sys_* or product* domain

cat /sys/devices/virtual/dmi/id/board_vendor 
Intel Corporation
cat /sys/devices/virtual/dmi/id/board_name 
DZ77RE-75K

Issue 2:
boardname can end with a dash in QEMU:
cat /sys/devices/virtual/dmi/id/product_name
Standard PC (i440FX + PIIX, 1996)

[1] http://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.0.0.pdf


From dirkneukirchen at web.de  Wed Jun  1 09:21:42 2016
From: dirkneukirchen at web.de (Dirk Neukirchen)
Date: Wed, 1 Jun 2016 18:21:42 +0200
Subject: [LEDE-DEV] [OpenWrt-Devel] [PATCH] package/devel/gdb: Add
	support of ARC gdb
In-Reply-To: <1464795158-4753-1-git-send-email-abrodkin@synopsys.com>
References: <1464795158-4753-1-git-send-email-abrodkin@synopsys.com>
Message-ID: <629ba347-c350-4780-edc1-c25c86d5fd42@web.de>

On 01.06.2016 17:32, Alexey Brodkin wrote:
> Also we disable sim because if the following breakage while
> building with it:
> ------------>8------------
> /usr/bin/env bash ./../common/genmloop.sh -shell /usr/bin/env bash \
>     -mono -fast -pbb -switch sem5-switch.c \
>     -cpu a5f -infile ./mloop5.in \
>     -outfile-suffix 5
> unknown option: bash
> Makefile:699: recipe for target 'stamp-5mloop' failed
> make[7]: *** [stamp-5mloop] Error 1
> ------------>8------------

rules.mk with its SHELL:=/usr/bin/env bash is the culprit

I had some issues when I set CONFIG_SHELL in the same  way
- using SHELL:=/bin/bash probably fixes this but might have
other side effects or breakage (globally/for other packages)



From Alexey.Brodkin at synopsys.com  Wed Jun  1 09:28:57 2016
From: Alexey.Brodkin at synopsys.com (Alexey Brodkin)
Date: Wed, 1 Jun 2016 16:28:57 +0000
Subject: [LEDE-DEV] [OpenWrt-Devel] [PATCH] package/devel/gdb: Add
 support of ARC gdb
In-Reply-To: <629ba347-c350-4780-edc1-c25c86d5fd42@web.de>
References: <1464795158-4753-1-git-send-email-abrodkin@synopsys.com>
 <629ba347-c350-4780-edc1-c25c86d5fd42@web.de>
Message-ID: <1464798497.3171.70.camel@synopsys.com>

Hi Dirk,

On Wed, 2016-06-01 at 18:21 +0200, Dirk Neukirchen wrote:
> On 01.06.2016 17:32, Alexey Brodkin wrote:
> > 
> > Also we disable sim because if the following breakage while
> > building with it:
> > ------------>8------------
> > /usr/bin/env bash ./../common/genmloop.sh -shell /usr/bin/env bash \
> > ????-mono -fast -pbb -switch sem5-switch.c \
> > ????-cpu a5f -infile ./mloop5.in \
> > ????-outfile-suffix 5
> > unknown option: bash
> > Makefile:699: recipe for target 'stamp-5mloop' failed
> > make[7]: *** [stamp-5mloop] Error 1
> > ------------>8------------
> rules.mk with its SHELL:=/usr/bin/env bash is the culprit

I think so.

> I had some issues when I set CONFIG_SHELL in the same??way
> - using SHELL:=/bin/bash probably fixes this but might have
> other side effects or breakage (globally/for other packages)

Indeed.

But anyways we don't need GDB's simulator to be built here,
so change itself is pretty sane.

-Alexey

From wbx at uclibc-ng.org  Wed Jun  1 10:28:27 2016
From: wbx at uclibc-ng.org (Waldemar Brodkorb)
Date: Wed, 1 Jun 2016 19:28:27 +0200
Subject: [LEDE-DEV] [PATCH] package/util-linux: Fix libmount build under
	uClibc
In-Reply-To: <1464767753.3171.18.camel@synopsys.com>
References: <1464014781-25347-1-git-send-email-abrodkin@synopsys.com>
 <1464263742.4578.22.camel@synopsys.com>
 <1464606749.3125.16.camel@synopsys.com>
 <1464767753.3171.18.camel@synopsys.com>
Message-ID: <20160601172827.GG6825@waldemar-brodkorb.de>

Hi Alexey,

Alexey Brodkin wrote,

> Hi Waldemar,
> 
> On Mon, 2016-05-30 at 14:12 +0300, Alexey Brodkin wrote:
> > Hello,
> > 
> > On Thu, 2016-05-26 at 14:55 +0300, Alexey Brodkin wrote:
> > > 
> > > Hello,
> > > 
> > > On Mon, 2016-05-23 at 17:46 +0300, Alexey Brodkin wrote:
> > > > 
> > > > 
> > > > This fixes util-linux building with uClibc.
> > > > Patch is taken as it is from Buildroot:
> > > > https://git.busybox.net/buildroot/plain/package/util-linux/0001-Fix-libmount-build-under-uClibc.patch?id=baccb506a
> > > > 6f
> > > > ea
> > > > bf114623866568121f49712f5df
> > > > 
> > > > Signed-off-by: Alexey Brodkin <abrodkin at synopsys.com>
> > > > ---
> > > > ?.../004-Fix-libmount-build-under-uClibc.patch??????| 153 +++++++++++++++++++++
> > > > ?1 file changed, 153 insertions(+)
> > > > ?create mode 100644 package/utils/util-linux/patches/004-Fix-libmount-build-under-uClibc.patch
> 
> We are discussing one issue with "util-linux" package building.
> The problem is in "util-linux" wants to use alloc modifier (either "%as"
> or "%ms") in scanf().
> 
> Looks like uClibc still doesn't support neither "%ms" nor "%as" (this one
> is obsolete glibc-specific so let's not bother with it anyways).
> 
> Now to work-around this missing requirement we used to use
> an off-the-tree patch like this one in Buildroot:
> https://git.busybox.net/buildroot/tree/package/util-linux/0001-Fix-libmount-build-under-uClibc.patch
> 
> OpenWRT:
> https://git.lede-project.org/?p=source.git;a=blob;f=package/utils/util-linux/patches/001-no-printf-alloc.patch;h=ad9eef0
> 959bf0c8ce269e8039d4d05ef58e1d527;hb=8a7b28071fba84e297796c46d46e12b0967804e8
> 
> Gentoo:
> https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-apps/util-linux/files/util-linux-2.21.1-no-printf-alloc.pat
> ch?revision=1.2
> 
> The question to you is where do you think we should fix mentioned problem:
> ?1) In uClibc-ng with addition of "%ms" support in scanf or

I would prefer this solution. I have started reading the code, but I
can't give you any guarantee when I can work on this.
Do you have free resources to cook up a patch? :)

> ?2) Try to upstream mentioned patch in "util-linux"?

best regards
 Waldemar


From p.wassi at gmx.at  Wed Jun  1 10:32:17 2016
From: p.wassi at gmx.at (p.wassi at gmx.at)
Date: Wed, 1 Jun 2016 19:32:17 +0200
Subject: [LEDE-DEV] brcm47xx legacy broken in trunk?
In-Reply-To: <CACna6rzp-hJiOC_vA3YJyVfriQ+OKoDLsOT+3GvJaM_uVP1d+w@mail.gmail.com>
References: <trinity-27231f9f-e864-4fb1-bc91-260b4cdb8aed-1464679354294@3capp-gmx-bs48>, 
 <CACna6rzp-hJiOC_vA3YJyVfriQ+OKoDLsOT+3GvJaM_uVP1d+w@mail.gmail.com>
Message-ID: <trinity-d118ede2-fb65-4c29-a2f2-358d8e0154b9-1464802337141@3capp-gmx-bs52>

There's been a similar issue 6 years ago (seems to be related to Kernel+CFE+NVRAM)
https://dev.openwrt.org/ticket/7693

Any hints on where to start debugging? (Adding some printk statements, etc.)
Kernel and especially the boot process (handover from CFE to kernel) is
pretty new stuff for me.

Thanks,
P.Wassi


From wbx at openadk.org  Wed Jun  1 10:32:55 2016
From: wbx at openadk.org (Waldemar Brodkorb)
Date: Wed, 1 Jun 2016 19:32:55 +0200
Subject: [LEDE-DEV] [PATCH] _GNU_SOURCE should be defined for building
 vs uClibc
In-Reply-To: <JWLTiNjvPvpj6z3KReiT3wgTbJKwn3c64FQG8zXU211c@mailpile>
References: <618582be-6dab-c1a4-cbca-73318011cf24@phrozen.org>
 <JWLTiNjvPvpj6z3KReiT3wgTbJKwn3c64FQG8zXU211c@mailpile>
Message-ID: <20160601173255.GH6825@waldemar-brodkorb.de>

Hi Karl,
Karl Palsson wrote,

> 
> John Crispin <john at phrozen.org> wrote:
> > 
> > 
> > On 23/05/2016 20:12, Waldemar Brodkorb wrote:
> > > Hi John,
> > > John Crispin wrote,
> > > 
> > >> Hi,
> > >> is it really a gnu extension or is uclibc b0rked for these symbols ?
> > > 
> > > I think it isn't b0rked.
> > > It was added for ARM GNU libc here under #ifdef __USE_GNU:
> > > https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=sysdeps/unix/sysv/linux/arm/bits/fcntl.h;h=aa2d36ca80f0ca4c5793b28b3852ce60b5fe57ef;hp=6a5f89ad1f8bdf8a825fc1e55a84679a86349a6c;hb=adb252daea96e7e160553703d477b76ff6a7781e;hpb=01b5049d107460f5eca797eda983958d1a410ffd
> > > 
> > > And later moved to generic fcntl.h file. So we are correct here or
> > > at least compatible to GNU libc.
> > > 
> > > best regards
> > >  Waldemar
> > >  
> > 
> > ok, i'll merge it later today or in the morning
> > 
> 
> This still doesn't work on the uclibc in openwrt-CC branch. The
> O_PATH definitions are in asm-generic/fcntl.h, which can be
> included via linux/fcntl.h, _GNU_SOURCE doesn't get this pulled
> in though.
> 
> I attempted to add includes for linux/fcntl, but it just gives me
> redeclaration errors for struct flock.

The definition where added to uClibc-ng after 1.0.9 release.
LEDE included 1.0.14 recently. You need to update.

best regards
 Waldemar


From dave.taht at gmail.com  Wed Jun  1 10:33:43 2016
From: dave.taht at gmail.com (Dave Taht)
Date: Wed, 1 Jun 2016 10:33:43 -0700
Subject: [LEDE-DEV] TR-069, bufferbloat, and BQL
In-Reply-To: <ca7696a5-6a30-bb28-6ccf-aa693eb68ff4@phrozen.org>
References: <CAA93jw4MDLvScQJN8xubS4WMfFw9tXDeM76zx9z-+BX73QhjCA@mail.gmail.com>
 <5749A4D8.6040802@hauke-m.de>
 <ca7696a5-6a30-bb28-6ccf-aa693eb68ff4@phrozen.org>
Message-ID: <CAA93jw4SrA9QKeHQyU=0vPu689HpZufny12VAfKbjH3RBYaXtQ@mail.gmail.com>

On Sat, May 28, 2016 at 7:05 AM, John Crispin <john at phrozen.org> wrote:
>
>
> On 28/05/2016 16:02, Hauke Mehrtens wrote:
>> On 05/28/2016 03:36 PM, Dave Taht wrote:
>>> On Sat, May 28, 2016 at 5:34 AM, Hauke Mehrtens <hauke at hauke-m.de> wrote:
>>>> On 05/27/2016 12:43 PM, David Lang wrote:
>>>>> On Thu, 26 May 2016, Delbar Jos wrote:
>>>>>
>>>>>> We are conscious of the fact that together with the proposals made by
>>>>>> Felix, Luka and Wojtek we are now looking at many "competing"
>>>>>> proposals. As a next step, we recommend to organize a workshop, at a
>>>>>> practical location and time, where we put everything on the table and
>>>>>> define the most appropriate path forward to the benefit of OpenWrt as
>>>>>> a whole.
>>>>>
>>>>> nothing wrong with supporting many different remote management daemons.
>>>>>
>>>>>> TR-069 is a complicated remote management system and in order to make
>>>>>> this initiative a success, we must ensure that the complexity is
>>>>>> handled in an elegant way and with respect for OpenWrt's core
>>>>>> architecture. More than on the protocol itself, we believe that we
>>>>>> should focus on the architectural enhancements required to support
>>>>>> remote management in general.
>>>>>
>>>>> What is it that you think is needed to "support remote management in
>>>>> general"?
>>>
>>> I am curious if TR-069 has any ability to set parameters for upload
>>> and download speeds, so they could be leveraged by sqm-scripts to
>>> manage the bufferbloat that DSL modems and dslams have?

My original question here remains unanswered. Being thus far unable to
convince a single DSL firmware maker that they've been screwing up,
despite proving how to do it right (free.fr 4+ years back), showing
the problem in innumerable public tests and papers, describing how
easy it would be to fix (given source code and a few six-packs of beer
with a dev that grokked the blob), getting the cable industry to
recognise and fix the bufferbloat problem in DOCSIS 3.1 - and even
going so far as talking to the top people in the FCC as to how simply
and cheaply they could help make the internet better for everyone,
particularly on DSL... has been quite frustrating.

It would be *so* straightforward to fix the dsl binary firmware to add
in BQL-like techniques and then manage it dynamically on top with
fq_codel.

doing it with a software rate limiter (htb+fq_codel) instead is
fraught with problems in getting the framing right - which, of course,
an ISP (as opposed to a typical user) *could* easily get right with a
clean interface between tr-069 and sqm-scripts and/or cake. (And is
probably still necessary to do on inbound traffic in a world that has
not seen much improvement in dslam/bras technology.)

Asking users to get the framing right for software shaping on dsl or
ppoe has been a PITA.

>>> Also:
>>>
>>> I have been hoping for nearly 4 years now that we'd see *someone*
>>> actually produce a BQL enabled dsl driver for their modem interface so
>>> advanced QoS techniques wouldn't be needed on outbound, where we could
>>> just enable fq-codel on top of a tightly written driver and be done
>>> with it. 100 million modems, all exhibiting 100s of ms of extra,
>>> unneeded latency, under load:
>>>
>>> http://www.dslreports.com/speedtest/results/bufferbloat?up=1
>>>
>>> sadly, aside from the freebox revolution v6, I'm not aware of anyone
>>> actually doing dsl more right yet. (?)
>>>
>>
>> The Lantiq / Intel DSL drivers are open source and integrated in
>> OpenWrt, but I haven't checked if BQL is implemented there. They are
>> also using a big firmware which does all the PHY related stuff.
>>
>> You can get some statistics from the device like this. These information
>> are from the DSL PHY layer, so it does not show when your ISP would
>> limit your rate somewhere else in the internal network, but these
>> information are available on all DSL lines.
>
>
> there is no BQL and there is a 256 packet buffer in the driver.

sigh. Even if BQL was there, the firmware has...

> if i am not mistaken, there is a secondary 64 packet ring handled by the
> firmware blob.

bytes, not packets, is easier to manage, and two full size packets
(3k) is more than enough at nearly any DSL rate to get sane network
performance and latency. So the default blob has 62 packets too many
in it for full size packets, and were they acks only (66 bytes each),
I'd bet that 10 in the firmware blob would more than suffice for
upload speeds up to 10Mbits on most hardware.

but the right answer is to count bytes, not packets, in the firmware.

>         John
>
>>
>> root at lede:~# /etc/init.d/dsl_control status
>> ATU-C Vendor ID:                          Broadcom 176.15
>> ATU-C System Vendor ID:                   Broadcom
>> Chipset:                                  Lantiq-VRX200 Unknown
>> Firmware Version:                         5.7.3.3.0.6
>> API Version:                              4.16.6.3
>> XTSE Capabilities:                        0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
>> 0x0, 0x2
>> Annex:                                    B
>> Line Mode:                                G.993.2 (VDSL2)
>> Profile:                                  17a
>> Line State:                               UP [0x801: showtime_tc_sync]
>> Forward Error Correction Seconds (FECS):  Near: 0 / Far: 2116802
>> Errored seconds (ES):                     Near: 0 / Far: 2938
>> Severely Errored Seconds (SES):           Near: 0 / Far: 50
>> Loss of Signal Seconds (LOSS):            Near: 0 / Far: 0
>> Unavailable Seconds (UAS):                Near: 31 / Far: 31
>> Header Error Code Errors (HEC):           Near: 0 / Far: 0
>> Non Pre-emtive CRC errors (CRC_P):        Near: 0 / Far: 0
>> Pre-emtive CRC errors (CRCP_P):           Near: 0 / Far: 0
>> Power Management Mode:                    L0 - Synchronized
>> Latency / Interleave Delay:               Down: Interleave (8.0 ms) /
>> Up: Interleave (4.0 ms)
>> Data Rate:                                Down: 51.391 Mb/s / Up: 10.046
>> Mb/s
>> Line Attenuation (LATN):                  Down: 10.6dB / Up: 10.6dB
>> Signal Attenuation (SATN):                Down: 10.6dB / Up: 10.2dB
>> Noise Margin (SNR):                       Down: 7.7dB / Up: 13.9dB
>> Aggregate Transmit Power (ACTATP):        Down: -11.6dB / Up: 12.5dB
>> Max. Attainable Data Rate (ATTNDR):       Down: 61.928 Mb/s / Up: 23.355
>> Mb/s
>> Line Uptime Seconds:                      62
>> Line Uptime:                              1m 2s
>> root at lede:~#
>>
>> Hauke
>>
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>



-- 
Dave T?ht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org


From john at phrozen.org  Wed Jun  1 10:37:36 2016
From: john at phrozen.org (John Crispin)
Date: Wed, 1 Jun 2016 19:37:36 +0200
Subject: [LEDE-DEV] [PATCH] package/util-linux: Fix libmount build under
	uClibc
In-Reply-To: <20160601172827.GG6825@waldemar-brodkorb.de>
References: <1464014781-25347-1-git-send-email-abrodkin@synopsys.com>
 <1464263742.4578.22.camel@synopsys.com>
 <1464606749.3125.16.camel@synopsys.com>
 <1464767753.3171.18.camel@synopsys.com>
 <20160601172827.GG6825@waldemar-brodkorb.de>
Message-ID: <d99da974-9090-60fd-4652-a52208058e53@phrozen.org>



On 01/06/2016 19:28, Waldemar Brodkorb wrote:
>> The question to you is where do you think we should fix mentioned problem:
>> >  1) In uClibc-ng with addition of "%ms" support in scanf or
> I would prefer this solution. I have started reading the code, but I
> can't give you any guarantee when I can work on this.
> Do you have free resources to cook up a patch? :)
> 

I agree that this needs to be fixed in uclibc

	John


From dave.taht at gmail.com  Wed Jun  1 10:44:32 2016
From: dave.taht at gmail.com (Dave Taht)
Date: Wed, 1 Jun 2016 10:44:32 -0700
Subject: [LEDE-DEV] TR-069, bufferbloat, and BQL
In-Reply-To: <CAA93jw4SrA9QKeHQyU=0vPu689HpZufny12VAfKbjH3RBYaXtQ@mail.gmail.com>
References: <CAA93jw4MDLvScQJN8xubS4WMfFw9tXDeM76zx9z-+BX73QhjCA@mail.gmail.com>
 <5749A4D8.6040802@hauke-m.de>
 <ca7696a5-6a30-bb28-6ccf-aa693eb68ff4@phrozen.org>
 <CAA93jw4SrA9QKeHQyU=0vPu689HpZufny12VAfKbjH3RBYaXtQ@mail.gmail.com>
Message-ID: <CAA93jw7gpXzj2WAv_0rO6nCCqBxjMEpKqAPo2=L903XwYECvig@mail.gmail.com>

An example of the futility of applying advanced fq and aqm techniques
to overbuffered firmware or device drivers is here:

http://blog.cerowrt.org/post/dql_on_wifi_2/

You'd think removing a "feature" like overbuffering in the firmware
would be easy... I do not know how dsl works well enough to understand
why you would need more than 2 packets in the device in the first
place. Does interleave require it? Certainly "bonding" might need
more....

-- 
Dave T?ht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org


From john at phrozen.org  Wed Jun  1 11:04:54 2016
From: john at phrozen.org (John Crispin)
Date: Wed, 1 Jun 2016 20:04:54 +0200
Subject: [LEDE-DEV] [PATCH 1/2] Add some common packages for x86-64
 target.
In-Reply-To: <1464307053-20531-1-git-send-email-greearb@candelatech.com>
References: <1464307053-20531-1-git-send-email-greearb@candelatech.com>
Message-ID: <f2124133-4860-a39d-3afd-b73b1f26cea9@phrozen.org>

Hi Ben,

i am inclined to reject this one. i understand the reasoning behind the
patch but the general concept is to keep images minimal. the tools might
make sense to you for your use case but others will want a different
selection of tools/drivers. we will never be able to find a set suitable
for everyone which is why it was decided ages ago to keep the list minimal.

	John

On 27/05/2016 01:57, greearb at candelatech.com wrote:
> From: Ben Greear <greearb at candelatech.com>
> 
> This should make x86-64 targets more useable out of the box.
> The assumption is that most x86-64 users have adequate storage,
> and those that do not can still config away the options they
> do not need.
> 
> Signed-off-by: Ben Greear <greearb at candelatech.com>
> ---
>  target/linux/x86/64/target.mk | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/target/linux/x86/64/target.mk b/target/linux/x86/64/target.mk
> index 6497698..95bd378 100644
> --- a/target/linux/x86/64/target.mk
> +++ b/target/linux/x86/64/target.mk
> @@ -1,6 +1,14 @@
>  ARCH:=x86_64
>  BOARDNAME:=x86_64
> -DEFAULT_PACKAGES += kmod-button-hotplug kmod-e1000e kmod-e1000 kmod-r8169
> +DEFAULT_PACKAGES += kmod-button-hotplug kmod-e1000e kmod-e1000 kmod-r8169 kmod-8139cp kmod-8139too
> +DEFAULT_PACKAGES += kmod-i2c-core kmod-i2c-algo-bit kmod-igb
> +# Add some drivers for common wifi NICs
> +DEFAULT_PACKAGES += kmod-ath9k kmod-ath10k kmod-ath9k-htc kmod-ath5k
> +# Add some firmware
> +DEFAULT_PACKAGES += ath10k-firmware-qca988x ath10k-firmware-qca99x0 ath9k-htc-firmware ath10k-firmware-qca6174
> +# Useful general OS packages
> +DEFAULT_PACKAGES += bzip2 curl dmesg ethtool getopt hostapd ip-full iperf3 iputils-ping iputils-tracepath iw
> +DEFAULT_PACKAGES += nstat relayd tcpdump wpa-cli wpa-supplicant wpa-supplicant-mesh
>  
>  define Target/Description
>          Build images for 64 bit systems including virtualized guests.
> 


From john at phrozen.org  Wed Jun  1 11:07:07 2016
From: john at phrozen.org (John Crispin)
Date: Wed, 1 Jun 2016 20:07:07 +0200
Subject: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.
In-Reply-To: <1464307053-20531-2-git-send-email-greearb@candelatech.com>
References: <1464307053-20531-1-git-send-email-greearb@candelatech.com>
 <1464307053-20531-2-git-send-email-greearb@candelatech.com>
Message-ID: <f599b26c-5b9c-f527-ef35-fa75997e2c9c@phrozen.org>

Hi Ben,

also inclined to reject this one. it will open up the pandoras box and
we will end up maintaining piles of diffconfig files. it would make
morse sense to document what the script does inside web.git as a "how to
build" or "getting started" page

	John

On 27/05/2016 01:57, greearb at candelatech.com wrote:
> From: Ben Greear <greearb at candelatech.com>
> 
> The idea is to be able to allow newbies to easily build images
> for common hardware.  These images should be user-friendly, including
> luci and other tools that may aid debugging and use of the platform.
> 
> Signed-off-by: Ben Greear <greearb at candelatech.com>
> ---
>  buildme.sh                            | 76 +++++++++++++++++++++++++++++++++++
>  buildme_targets/x86_64/diffconfig.txt | 26 ++++++++++++
>  2 files changed, 102 insertions(+)
>  create mode 100755 buildme.sh
>  create mode 100644 buildme_targets/x86_64/diffconfig.txt
> 
> diff --git a/buildme.sh b/buildme.sh
> new file mode 100755
> index 0000000..83644fa
> --- /dev/null
> +++ b/buildme.sh
> @@ -0,0 +1,76 @@
> +#!/usr/bin/env bash
> +
> +USAGE=$( cat <<EOF
> +Usage:\n
> +# -t:  Target\n
> +# -l:  List available targets.\n
> +# -f:  Skip feeds (useful on rebuild)\n
> +# -j:  Compile jobs (default is 8)\n
> +# -h:  Show help and exit\n
> +#\n
> +#\n
> +# Example:  Build an image for x86_64
> +#  ./buildme.sh -t x86_64\n
> +EOF
> +)
> +
> +BMT=buildme_targets
> +TARGET=UNKNOWN
> +LIST_TARGETS=0
> +SKIP_FEEDS=0
> +JOBS=8
> +
> +while getopts "t:j:lfh" flag
> +  do
> +  case $flag in
> +      t) TARGET=$OPTARG;;
> +      l) LIST_TARGETS=1;;
> +      f) SKIP_FEEDS=1;;
> +      j) JOBS=$OPTARG;;
> +      h) echo -e USAGE && exit 0;;
> +
> +      *) echo "Un-known option: $flag"; echo -e $USAGE;exit 1;;
> +  esac
> +done
> +
> +if [ $LIST_TARGETS == 1 ]
> +then
> +    ls $BMT
> +    exit 0
> +fi
> +
> +echo "Target dir: $BMT/$TARGET"
> +
> +if [ ! -d $BMT/$TARGET ]
> +then
> +    echo "ERROR:  Unknown target, try -l option?"
> +    exit 1;
> +fi
> +
> +set -x
> +
> +if [ $SKIP_FEEDS != 1 ]
> +then
> +    # Update feeds
> +    ./scripts/feeds update -a || exit 1
> +
> +    # Enable luci web interface
> +    ./scripts/feeds install -d y luci || exit 1
> +
> +    # Enable ethtool for driver info and stats and such
> +    ./scripts/feeds install -d y ethtool || exit 1
> +fi
> +
> +# Copy default config into place
> +cp $BMT/$TARGET/diffconfig.txt .config || exit 1
> +
> +# Build complate .config file based on whatever is latest, etc.
> +make defconfig || exit 1
> +
> +# Build
> +make v=S -j $JOBS || exit 1
> +
> +# Try to figure out where the images are at.
> +set +x
> +. .config > /dev/null 2>&1
> +echo "Images may be found at: bin/targets/$CONFIG_TARGET_BOARD/$CONFIG_TARGET_SUBTARGET/"
> diff --git a/buildme_targets/x86_64/diffconfig.txt b/buildme_targets/x86_64/diffconfig.txt
> new file mode 100644
> index 0000000..d3db402
> --- /dev/null
> +++ b/buildme_targets/x86_64/diffconfig.txt
> @@ -0,0 +1,26 @@
> +CONFIG_TARGET_x86=y
> +CONFIG_TARGET_x86_64=y
> +CONFIG_TARGET_x86_64_Generic=y
> +CONFIG_ALL_NONSHARED=y
> +CONFIG_BUSYBOX_CUSTOM=y
> +CONFIG_BUSYBOX_CONFIG_ARP=y
> +CONFIG_BUSYBOX_CONFIG_FEATURE_TELNET_AUTOLOGIN=y
> +CONFIG_BUSYBOX_CONFIG_FEATURE_TELNET_TTYPE=y
> +CONFIG_BUSYBOX_CONFIG_LSPCI=y
> +CONFIG_BUSYBOX_CONFIG_LSUSB=y
> +CONFIG_BUSYBOX_CONFIG_MORE=y
> +CONFIG_BUSYBOX_CONFIG_TELNET=y
> +CONFIG_IMAGEOPT=y
> +CONFIG_PACKAGE_hostapd-common-old=y
> +CONFIG_PACKAGE_hostapd-utils=y
> +CONFIG_PACKAGE_kmod-hwmon-core=y
> +CONFIG_PACKAGE_kmod-i2c-algo-bit=y
> +CONFIG_PACKAGE_kmod-i2c-core=y
> +CONFIG_PACKAGE_kmod-igb=y
> +CONFIG_PACKAGE_kmod-libphy=y
> +CONFIG_PACKAGE_kmod-skge=y
> +CONFIG_PACKAGE_kmod-sky2=y
> +CONFIG_PACKAGE_kmod-tg3=y
> +# CONFIG_PER_FEED_REPO is not set
> +CONFIG_TARGET_KERNEL_PARTSIZE=64
> +CONFIG_TARGET_ROOTFS_PARTSIZE=1024
> 


From jo at mein.io  Wed Jun  1 11:10:48 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Wed, 1 Jun 2016 20:10:48 +0200
Subject: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.
In-Reply-To: <f599b26c-5b9c-f527-ef35-fa75997e2c9c@phrozen.org>
References: <1464307053-20531-1-git-send-email-greearb@candelatech.com>
 <1464307053-20531-2-git-send-email-greearb@candelatech.com>
 <f599b26c-5b9c-f527-ef35-fa75997e2c9c@phrozen.org>
Message-ID: <e42e313a-cc58-c6a7-c9ac-6a0c7dfb28e3@mein.io>

Hi,

maybe we can add a well annotated variant of this script into web.git as
part of the documentation tree and do some kind of build script example
page?

~ Jo?


From greearb at candelatech.com  Wed Jun  1 11:21:05 2016
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 1 Jun 2016 11:21:05 -0700
Subject: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.
In-Reply-To: <f599b26c-5b9c-f527-ef35-fa75997e2c9c@phrozen.org>
References: <1464307053-20531-1-git-send-email-greearb@candelatech.com>
 <1464307053-20531-2-git-send-email-greearb@candelatech.com>
 <f599b26c-5b9c-f527-ef35-fa75997e2c9c@phrozen.org>
Message-ID: <574F2791.3020500@candelatech.com>

On 06/01/2016 11:07 AM, John Crispin wrote:
> Hi Ben,
>
> also inclined to reject this one. it will open up the pandoras box and
> we will end up maintaining piles of diffconfig files. it would make
> morse sense to document what the script does inside web.git as a "how to
> build" or "getting started" page

I do not have much history with LEDE/WRT, but is the diffconfig output
really that fragile?

I will be willing to maintain the x86-64 and probably Ventana
diffconfigs, and even if it totally fails, you have not lost
any functionality since the main infrastructure is unchanged.

I think I could further improve the buildme.sh to automatically
pull in the feeds based on the packages in the diffconfig too,
which should further automate building and make the buildme.sh
more generic for different platforms.

For jow's idea, putting it in a web page may be better than nothing,
but then it just means anyone wanting to use this type of thing
has more work to do, and for newbies, that can be all the difference
between success and failure.

I still think you should consider letting this patch in.  I can
re-do it based on removing the 1/2 patch, so the diffconfig gets
bigger, but we can still build usable apu2 images out of the box.

Either way, thanks for considering the patch.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From dave.taht at gmail.com  Wed Jun  1 11:24:32 2016
From: dave.taht at gmail.com (Dave Taht)
Date: Wed, 1 Jun 2016 11:24:32 -0700
Subject: [LEDE-DEV] [PATCH 1/2] Add some common packages for x86-64
	target.
In-Reply-To: <f2124133-4860-a39d-3afd-b73b1f26cea9@phrozen.org>
References: <1464307053-20531-1-git-send-email-greearb@candelatech.com>
 <f2124133-4860-a39d-3afd-b73b1f26cea9@phrozen.org>
Message-ID: <CAA93jw7FfJyGsZiBMX1u=+xotc-TxesJBdqLTjv58PSXuZsOzg@mail.gmail.com>

To fork this discussion mildly, I would like to see a fuller build,
including the luci gui, available, somehow, somewhere, so that newer
users can get a working config "out of the box" from the daily builds.

Also, at least on the archer c7v2, the ath10k kmod and firmware were
not included in the default build.


From john at phrozen.org  Wed Jun  1 11:27:17 2016
From: john at phrozen.org (John Crispin)
Date: Wed, 1 Jun 2016 20:27:17 +0200
Subject: [LEDE-DEV] [PATCH 1/2] Add some common packages for x86-64
 target.
In-Reply-To: <CAA93jw7FfJyGsZiBMX1u=+xotc-TxesJBdqLTjv58PSXuZsOzg@mail.gmail.com>
References: <1464307053-20531-1-git-send-email-greearb@candelatech.com>
 <f2124133-4860-a39d-3afd-b73b1f26cea9@phrozen.org>
 <CAA93jw7FfJyGsZiBMX1u=+xotc-TxesJBdqLTjv58PSXuZsOzg@mail.gmail.com>
Message-ID: <6110e920-15f8-c941-2296-3fc94e078b46@phrozen.org>



On 01/06/2016 20:24, Dave Taht wrote:
> To fork this discussion mildly, I would like to see a fuller build,
> including the luci gui, available, somehow, somewhere, so that newer
> users can get a working config "out of the box" from the daily builds.
> 
> Also, at least on the archer c7v2, the ath10k kmod and firmware were
> not included in the default build.
> 

we are currently adding multiprofile build support. so that a buildjob
will produce images for all profiles with the corresponding default
package selection. i would like to see luci added. that will in effect
be what you just described.

	John


From mschiffer at universe-factory.net  Wed Jun  1 13:27:58 2016
From: mschiffer at universe-factory.net (Matthias Schiffer)
Date: Wed,  1 Jun 2016 22:27:58 +0200
Subject: [LEDE-DEV] [PATCH libubox] blobmsg_json: add new functions
	blobmsg_format_json_value*
Message-ID: <dbc90f6d05a606753e2576bd6fc3569c5958885a.1464812878.git.mschiffer@universe-factory.net>

The current blobmsg_format_json* functions will return invalid JSON when
the "list" argument is given as false (blobmsg_format_element() will
output the name of the blob_attr as if the value is printed as part of a
JSON object).

To avoid breaking software relying on this behaviour, introduce new
functions which will never print the blob_attr name and thus always
produce valid JSON.

Signed-off-by: Matthias Schiffer <mschiffer at universe-factory.net>
---
 blobmsg_json.c | 49 ++++++++++++++++++++++++++++++++++++-------------
 blobmsg_json.h | 14 ++++++++++++++
 2 files changed, 50 insertions(+), 13 deletions(-)

diff --git a/blobmsg_json.c b/blobmsg_json.c
index 5713948..538c816 100644
--- a/blobmsg_json.c
+++ b/blobmsg_json.c
@@ -207,7 +207,7 @@ static void blobmsg_format_string(struct strbuf *s, const char *str)
 
 static void blobmsg_format_json_list(struct strbuf *s, struct blob_attr *attr, int len, bool array);
 
-static void blobmsg_format_element(struct strbuf *s, struct blob_attr *attr, bool array, bool head)
+static void blobmsg_format_element(struct strbuf *s, struct blob_attr *attr, bool without_name, bool head)
 {
 	const char *data_str;
 	char buf[32];
@@ -217,7 +217,7 @@ static void blobmsg_format_element(struct strbuf *s, struct blob_attr *attr, boo
 	if (!blobmsg_check_attr(attr, false))
 		return;
 
-	if (!array && blobmsg_name(attr)[0]) {
+	if (!without_name && blobmsg_name(attr)[0]) {
 		blobmsg_format_string(s, blobmsg_name(attr));
 		blobmsg_puts(s, ": ", s->indent ? 2 : 1);
 	}
@@ -286,22 +286,26 @@ static void blobmsg_format_json_list(struct strbuf *s, struct blob_attr *attr, i
 	blobmsg_puts(s, (array ? "]" : "}"), 1);
 }
 
+static void setup_strbuf(struct strbuf *s, struct blob_attr *attr, blobmsg_json_format_t cb, void *priv, int indent) {
+	s->len = blob_len(attr);
+	s->buf = malloc(s->len);
+	s->pos = 0;
+	s->custom_format = cb;
+	s->priv = priv;
+	s->indent = false;
+
+	if (indent >= 0) {
+		s->indent = true;
+		s->indent_level = indent;
+	}
+}
+
 char *blobmsg_format_json_with_cb(struct blob_attr *attr, bool list, blobmsg_json_format_t cb, void *priv, int indent)
 {
 	struct strbuf s;
 	bool array;
 
-	s.len = blob_len(attr);
-	s.buf = malloc(s.len);
-	s.pos = 0;
-	s.custom_format = cb;
-	s.priv = priv;
-	s.indent = false;
-
-	if (indent >= 0) {
-		s.indent = true;
-		s.indent_level = indent;
-	}
+	setup_strbuf(&s, attr, cb, priv, indent);
 
 	array = blob_is_extended(attr) &&
 		blobmsg_type(attr) == BLOBMSG_TYPE_ARRAY;
@@ -321,3 +325,22 @@ char *blobmsg_format_json_with_cb(struct blob_attr *attr, bool list, blobmsg_jso
 
 	return s.buf;
 }
+
+char *blobmsg_format_json_value_with_cb(struct blob_attr *attr, blobmsg_json_format_t cb, void *priv, int indent)
+{
+	struct strbuf s;
+
+	setup_strbuf(&s, attr, cb, priv, indent);
+
+	blobmsg_format_element(&s, attr, true, false);
+
+	if (!s.len) {
+		free(s.buf);
+		return NULL;
+	}
+
+	s.buf = realloc(s.buf, s.pos + 1);
+	s.buf[s.pos] = 0;
+
+	return s.buf;
+}
diff --git a/blobmsg_json.h b/blobmsg_json.h
index cd9ed33..9dfc02d 100644
--- a/blobmsg_json.h
+++ b/blobmsg_json.h
@@ -42,4 +42,18 @@ static inline char *blobmsg_format_json_indent(struct blob_attr *attr, bool list
 	return blobmsg_format_json_with_cb(attr, list, NULL, NULL, indent);
 }
 
+char *blobmsg_format_json_value_with_cb(struct blob_attr *attr,
+					blobmsg_json_format_t cb, void *priv,
+					int indent);
+
+static inline char *blobmsg_format_json_value(struct blob_attr *attr)
+{
+	return blobmsg_format_json_value_with_cb(attr, NULL, NULL, -1);
+}
+
+static inline char *blobmsg_format_json_value_indent(struct blob_attr *attr, int indent)
+{
+	return blobmsg_format_json_value_with_cb(attr, NULL, NULL, indent);
+}
+
 #endif
-- 
2.8.3



From champetier.etienne at gmail.com  Wed Jun  1 13:54:06 2016
From: champetier.etienne at gmail.com (Etienne CHAMPETIER)
Date: Wed,  1 Jun 2016 20:54:06 +0000
Subject: [LEDE-DEV] [PATCH procd] jail: don't always CLONE_NEWUTS
Message-ID: <1464814446-122273-1-git-send-email-champetier.etienne@gmail.com>

no -h => no CLONE_NEWUTS
-h "" => CLONE_NEWUTS
-h "newjailhostname" => CLONE_NEWUTS + sethostname

Signed-off-by: Etienne CHAMPETIER <champetier.etienne at gmail.com>
---
 jail/jail.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/jail/jail.c b/jail/jail.c
index e425254..c442847 100644
--- a/jail/jail.c
+++ b/jail/jail.c
@@ -244,7 +244,7 @@ static int exec_jail(void *_notused)
 		exit(EXIT_FAILURE);
 	}
 
-	if (opts.namespace && opts.hostname
+	if (opts.namespace && opts.hostname && strlen(opts.hostname) > 0
 			&& sethostname(opts.hostname, strlen(opts.hostname))) {
 		ERROR("sethostname(%s) failed: %s\n", opts.hostname, strerror(errno));
 		exit(EXIT_FAILURE);
@@ -386,9 +386,10 @@ int main(int argc, char **argv)
 
 	uloop_init();
 	if (opts.namespace) {
-		jail_process.pid = clone(exec_jail,
-			child_stack + STACK_SIZE,
-			CLONE_NEWUTS | CLONE_NEWPID | CLONE_NEWNS | CLONE_NEWIPC | SIGCHLD, NULL);
+		int flags = CLONE_NEWPID | CLONE_NEWNS | CLONE_NEWIPC | SIGCHLD;
+		if (opts.hostname)
+			flags |= CLONE_NEWUTS;
+		jail_process.pid = clone(exec_jail, child_stack + STACK_SIZE, flags, NULL);
 	} else {
 		jail_process.pid = fork();
 	}
-- 
1.9.1



From champetier.etienne at gmail.com  Wed Jun  1 14:39:30 2016
From: champetier.etienne at gmail.com (Etienne Champetier)
Date: Wed, 1 Jun 2016 23:39:30 +0200
Subject: [LEDE-DEV] urandom seed & /etc mount time
Message-ID: <CAOdf3gryFQVkrDwQ3USL3dk+KkOYUOGHJLvpGmAnA++9appLKQ@mail.gmail.com>

Hi,

i'm thinking about adding a urandom seed like any distro do,
just need to know when /etc is first monted (inside procd or via init scripts?)

Regards
Etienne


From gareth41 at orcon.net.nz  Wed Jun  1 16:45:56 2016
From: gareth41 at orcon.net.nz (Gareth Parker)
Date: Thu, 2 Jun 2016 11:45:56 +1200
Subject: [LEDE-DEV] Supported device list and documentation over at
	openwrt.org
Message-ID: <002701d1bc5f$bde12920$39a37b60$@orcon.net.nz>

There is a lot of very useful specific router documentation still over at
openwrt.org, technical details, de-bricking info, device mods, plus loads
more info and photos relating to lots of individual devices.? Would it not
be wise to also bring this over to the lede website? ?I quite often refer
back to a lot of this documentation.? With the openwrt problems and changes
recently and people leaving openwrt for lede, I?m worried this documentation
is in jeopardy of being lost.? I?ve seen this happen with other websites.?
If this were to happen it would certainly make life very difficult for some
people, I often refer back to the openwrt website for quite a few things
from time to time. ?This plus the forum history is not mirrored anywhere
else I?m aware of, correct me if I?m wrong though.

Gareth




From ianchi74 at outlook.com  Wed Jun  1 20:41:40 2016
From: ianchi74 at outlook.com (Adrian Panella)
Date: Wed, 1 Jun 2016 22:41:40 -0500
Subject: [LEDE-DEV] [PATCH 1/2] Add some common packages for
	x86-64	target.
In-Reply-To: <CAA93jw7FfJyGsZiBMX1u=+xotc-TxesJBdqLTjv58PSXuZsOzg@mail.gmail.com>
References: <1464307053-20531-1-git-send-email-greearb@candelatech.com>
 <f2124133-4860-a39d-3afd-b73b1f26cea9@phrozen.org>
 <CAA93jw7FfJyGsZiBMX1u=+xotc-TxesJBdqLTjv58PSXuZsOzg@mail.gmail.com>
Message-ID: <BLU405-EAS802021C2DBFD98A41C1ECADB580@phx.gbl>

I agree with having somehow a full build available for new users.
Now that "market" seems to be catered by custom images published by some in the Owrt forum and consumed by many who want a better router firmware but don't know how to build it, and most probably don't even want to know or take the time to set up all the environment to just build an image only once to flash the router and forget about it (for all this many end up using other "friendlier" projects, like I did myself for quite some time - without realizing what I was missing!).

As I see it the "buildme" script doesn't address that problem, as you still need to build.

I would take a different approach:

+ for the ones willing to actually build themselves I think than jow's idea of a good "how to" should do
+ for the rest (I'm assuming it's the majority) I would do a "full" or "moded" metapackage for each target with the most important extras (assuming a fair agreement can be reached on which are those).
That way anyone can just flash a nightly build and with just one "opkg" upgrade to a full build, closer to an "out of the box" experience without sacrificing much of the spirit, and with much less need for maintenance, and very little code.

The idea could be further elaborated - and perhaps it already was, and was discarded :).
Factory images (the entry point to LEDE for newcomers) could have at least a basic LUCI so that the "full" opkg installation could be easily done without needing to ssh into the router (in Windows even for that you need to install additional software to your PC).
For sysupgrade, once you are already with LEDE, I would add an option "download and reinstall currently installed packages" to complement the keep settings option. If one wants a really quick upgrade.

Sorry for the long mail. I found Owrt/LEDE a great product and easing its adoption is really worth. 


> El 01/06/2016, a las 1:26 p.m., Dave Taht <dave.taht at gmail.com> escribi?:
> 
> To fork this discussion mildly, I would like to see a fuller build,
> including the luci gui, available, somehow, somewhere, so that newer
> users can get a working config "out of the box" from the daily builds.
> 
> Also, at least on the archer c7v2, the ath10k kmod and firmware were
> not included in the default build.
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

From john at phrozen.org  Wed Jun  1 22:02:24 2016
From: john at phrozen.org (John Crispin)
Date: Thu, 2 Jun 2016 07:02:24 +0200
Subject: [LEDE-DEV] urandom seed & /etc mount time
In-Reply-To: <CAOdf3gryFQVkrDwQ3USL3dk+KkOYUOGHJLvpGmAnA++9appLKQ@mail.gmail.com>
References: <CAOdf3gryFQVkrDwQ3USL3dk+KkOYUOGHJLvpGmAnA++9appLKQ@mail.gmail.com>
Message-ID: <0fb6a77d-2029-25e4-619f-cd910bb3967f@phrozen.org>



On 01/06/2016 23:39, Etienne Champetier wrote:
> Hi,
> 
> i'm thinking about adding a urandom seed like any distro do,
> just need to know when /etc is first monted (inside procd or via init scripts?)
> 
> Regards
> Etienne

from within mount_root

	John


> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 


From john at phrozen.org  Thu Jun  2 00:10:23 2016
From: john at phrozen.org (John Crispin)
Date: Thu, 2 Jun 2016 09:10:23 +0200
Subject: [LEDE-DEV] urandom seed & /etc mount time
In-Reply-To: <CAOdf3gq1diKcv8HG7sjLrzGwVo8s-UjeavoDH0SB37zubjWMRA@mail.gmail.com>
References: <CAOdf3gryFQVkrDwQ3USL3dk+KkOYUOGHJLvpGmAnA++9appLKQ@mail.gmail.com>
 <0fb6a77d-2029-25e4-619f-cd910bb3967f@phrozen.org>
 <CAOdf3gq1diKcv8HG7sjLrzGwVo8s-UjeavoDH0SB37zubjWMRA@mail.gmail.com>
Message-ID: <a93755f5-767a-81c8-084c-dd2e762a67e9@phrozen.org>



On 02/06/2016 09:04, Etienne Champetier wrote:
> Hi John,
> 
> Le 2 juin 2016 07:04, "John Crispin" <john at phrozen.org
> <mailto:john at phrozen.org>> a ?crit :
>>
>>
>> On 01/06/2016 23:39, Etienne Champetier wrote:
>> > Hi,
>> >
>> > i'm thinking about adding a urandom seed like any distro do,
>> > just need to know when /etc is first monted (inside procd or via
> init scripts?)
>> >
>> > Regards
>> > Etienne
>>
>> from within mount_root
> 
> First called in "boot" init script? After ubus has started?
> 
>>
>>         John
>>
> 

i was not telling the truth

package/base-files/files/lib/preinit/80_mount_root

it depends on what kind of setup you have. on a !overlay setup /etc will
be available earlier. however after the 80_mount_root script executed,
/etc should be available on all setups, so probably best to hook it int
preinit as 81_urandom_seed ?

	John


From lede at daniel.thecshore.com  Thu Jun  2 00:17:01 2016
From: lede at daniel.thecshore.com (Daniel Dickinson)
Date: Thu, 02 Jun 2016 03:17:01 -0400
Subject: [LEDE-DEV] Multi-Profile selection support
In-Reply-To: <b0baae6e-6c57-680f-3ea3-6c2b9cb34a69@nbd.name>
References: <b0baae6e-6c57-680f-3ea3-6c2b9cb34a69@nbd.name>
Message-ID: <1464851821.2664.1.camel@homehost>

On Mon, 2016-05-23 at 13:38 +0200, Felix Fietkau wrote: 
> Hi Daniel et al.
> 
> after a long delay, I finally got around to looking into multi profile
> selection again. After reviewing your code and thinking about it some
> more, I decided to go with a slightly different approach from the one
> that you took.
> 

Just to let you know I haven't forgotten about this, and hope to get to
it soon.  I've been sidetracked by some development I needed to do to
get some desktop/laptop system things I wanted working right.

Regards,

Daniel


From karlp at tweak.net.au  Thu Jun  2 03:08:31 2016
From: karlp at tweak.net.au (Karl Palsson)
Date: Thu, 02 Jun 2016 10:08:31 -0000
Subject: [LEDE-DEV] [RFC v3 2/2] x86: use sysfs DMI information to
 populate sysinfo
In-Reply-To: <78be9794-1918-e370-1712-8e9cb8ccddd0@web.de>
References: <78be9794-1918-e370-1712-8e9cb8ccddd0@web.de>
Message-ID: <aSWPySYFKFYBQn5FPF2VEdo42IQcrDi7FtXWC9BW211d@mailpile>


Dirk Neukirchen <dirkneukirchen at web.de> wrote:
> On 01.06.2016 17:14, Jo-Philipp Wich wrote:
> > Use the DMI data available in sysfs to extract manufacturer and model info
> > and write it to /tmp/sysinfo/.
> > 
> > The data will be picked up by board_detect and can be used by e.g. LuCI to
> > display a more appropriate model description.
> > 
> > On an APU board the files will contain the following values:
> > 
> >     # cat /tmp/sysinfo/model
> >     PC Engines APU
> > 
> >     # cat /tmp/sysinfo/board_name
> >     pc-engines-apu
> > 
> > Signed-off-by: Jo-Philipp Wich <jo at mein.io>
> > ---
> >  target/linux/x86/base-files/lib/preinit/20_sysinfo | 16 ++++++++++++++++
> >  1 file changed, 16 insertions(+)
> >  create mode 100644 target/linux/x86/base-files/lib/preinit/20_sysinfo
> > 
> > diff --git a/target/linux/x86/base-files/lib/preinit/20_sysinfo b/target/linux/x86/base-files/lib/preinit/20_sysinfo
> > new file mode 100644
> > index 0000000..0b836ce
> > --- /dev/null
> > +++ b/target/linux/x86/base-files/lib/preinit/20_sysinfo
> > @@ -0,0 +1,16 @@
> > +do_sysinfo_x86() {
> > +	local vendor product boardname
> > +
> > +	vendor="$(cat /sys/devices/virtual/dmi/id/sys_vendor 2>/dev/null)"
> > +	product="$(cat /sys/devices/virtual/dmi/id/product_name 2>/dev/null)"
> > +
> > +	[ -n "$vendor" -a -n "$product" ] || return
> > +
> > +	boardname="$(printf "%s %s" "$vendor" "$product" | tr 'A-Z' 'a-z' | tr -cs 'a-z0-9_-' '-')"
> > +
> > +	mkdir -p /tmp/sysinfo
> > +	echo "$boardname" > /tmp/sysinfo/board_name
> > +	echo "$vendor $product" > /tmp/sysinfo/model
> 
> Issue 1:
> Maybe change up variable naming to keep more in line with
> sysfs/DMI standards ? as future reference: [1]
> 
> on my normal(?) Intel ATX motherboard both sysfs entries are
> empty but board_name & board_vendor exist: I might expect to
> get /tmp/sysinfo/board_name from board_* and not from the sys_*
> or product* domain
> 
> cat /sys/devices/virtual/dmi/id/board_vendor 
> Intel Corporation
> cat /sys/devices/virtual/dmi/id/board_name 
> DZ77RE-75K
> 

fwiw, my hp laptop (and a colleagues other, newer HP) has both
sys_vendor and product_name (and they're sane...)
sys_vendor:Hewlett-Packard (board_vendor also exists, and is the
same as sys_vendor) product_name:HP EliteBook 8470p

It also has board_name, but it's "useless" 
board_name:179B

I generally like the patch though, it seems like a clear
improvement, even if there turn out to be edge cases.

Cheers,
Karl P
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP Digital Signature
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20160602/48bd5929/attachment.sig>

From Alexey.Brodkin at synopsys.com  Thu Jun  2 04:00:29 2016
From: Alexey.Brodkin at synopsys.com (Alexey Brodkin)
Date: Thu, 2 Jun 2016 11:00:29 +0000
Subject: [LEDE-DEV] [PATCH] package/util-linux: Fix libmount build under
	uClibc
In-Reply-To: <20160601172827.GG6825@waldemar-brodkorb.de>
References: <1464014781-25347-1-git-send-email-abrodkin@synopsys.com>
 <1464263742.4578.22.camel@synopsys.com>
 <1464606749.3125.16.camel@synopsys.com>
 <1464767753.3171.18.camel@synopsys.com>
 <20160601172827.GG6825@waldemar-brodkorb.de>
Message-ID: <1464865189.3047.16.camel@synopsys.com>

Hi Waldemar,

On Wed, 2016-06-01 at 19:28 +0200, Waldemar Brodkorb wrote:
> Hi Alexey,
> 
> Alexey Brodkin wrote,
> 
> > 
> > Hi Waldemar,
> > 
> > On Mon, 2016-05-30 at 14:12 +0300, Alexey Brodkin wrote:
> > > 
> > > Hello,
> > > 
> > > On Thu, 2016-05-26 at 14:55 +0300, Alexey Brodkin wrote:
> > > > 
> > > > 
> > > > Hello,
> > > > 
> > > > On Mon, 2016-05-23 at 17:46 +0300, Alexey Brodkin wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > This fixes util-linux building with uClibc.
> > > > > Patch is taken as it is from Buildroot:
> > > > > https://git.busybox.net/buildroot/plain/package/util-linux/0001-Fix-libmount-build-under-uClibc.patch?id=baccb
> > > > > 506a
> > > > > 6f
> > > > > ea
> > > > > bf114623866568121f49712f5df
> > > > > 
> > > > > Signed-off-by: Alexey Brodkin <abrodkin at synopsys.com>
> > > > > ---
> > > > > ?.../004-Fix-libmount-build-under-uClibc.patch??????| 153 +++++++++++++++++++++
> > > > > ?1 file changed, 153 insertions(+)
> > > > > ?create mode 100644 package/utils/util-linux/patches/004-Fix-libmount-build-under-uClibc.patch
> > We are discussing one issue with "util-linux" package building.
> > The problem is in "util-linux" wants to use alloc modifier (either "%as"
> > or "%ms") in scanf().
> > 
> > Looks like uClibc still doesn't support neither "%ms" nor "%as" (this one
> > is obsolete glibc-specific so let's not bother with it anyways).
> > 
> > Now to work-around this missing requirement we used to use
> > an off-the-tree patch like this one in Buildroot:
> > https://git.busybox.net/buildroot/tree/package/util-linux/0001-Fix-libmount-build-under-uClibc.patch
> > 
> > OpenWRT:
> > https://git.lede-project.org/?p=source.git;a=blob;f=package/utils/util-linux/patches/001-no-printf-alloc.patch;h=ad9
> > eef0
> > 959bf0c8ce269e8039d4d05ef58e1d527;hb=8a7b28071fba84e297796c46d46e12b0967804e8
> > 
> > Gentoo:
> > https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-apps/util-linux/files/util-linux-2.21.1-no-printf-alloc
> > .pat
> > ch?revision=1.2
> > 
> > The question to you is where do you think we should fix mentioned problem:
> > ?1) In uClibc-ng with addition of "%ms" support in scanf or
> I would prefer this solution. I have started reading the code, but I
> can't give you any guarantee when I can work on this.
> Do you have free resources to cook up a patch? :)

You mean if I'm up to implement this missing feature in uClibc?
Well I'd like to but as well not sure if and when I have time for that :)

For now we have a work-around with mentioned patches. So that's not a showstopper.

-Alexey

From karlp at tweak.net.au  Thu Jun  2 04:03:00 2016
From: karlp at tweak.net.au (Karl Palsson)
Date: Thu, 02 Jun 2016 11:03:00 -0000
Subject: [LEDE-DEV] [PATCH] _GNU_SOURCE should be defined for building
 vs uClibc
In-Reply-To: <20160601173255.GH6825@waldemar-brodkorb.de>
References: <20160601173255.GH6825@waldemar-brodkorb.de>
Message-ID: <uhWo4L7ACTD8be4ub8dPtCgUi3fouPY3YfANfi6r211d@mailpile>


Waldemar Brodkorb <wbx at openadk.org> wrote:
> > 
> > This still doesn't work on the uclibc in openwrt-CC branch. The
> > O_PATH definitions are in asm-generic/fcntl.h, which can be
> > included via linux/fcntl.h, _GNU_SOURCE doesn't get this pulled
> > in though.
> > 
> > I attempted to add includes for linux/fcntl, but it just gives me
> > redeclaration errors for struct flock.
> 
> The definition where added to uClibc-ng after 1.0.9 release.
> LEDE included 1.0.14 recently. You need to update.
> 

I'm well aware that it would work if I was on living on the
bleeding edge of latest LEDE. [1] I'm just reporting that, up
until this O_PATH landed, procd fixes were still backportable to
the last _released_ version of openwrt/lede. (uclibc 0.9.33.2)
That is no longer the case.

Sincerely,
Karl P


[1] Everything always works, you just haven't pulled the latest!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP Digital Signature
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20160602/3295c979/attachment.sig>

From john at phrozen.org  Thu Jun  2 04:04:28 2016
From: john at phrozen.org (John Crispin)
Date: Thu, 2 Jun 2016 13:04:28 +0200
Subject: [LEDE-DEV] [PATCH] package/util-linux: Fix libmount build under
	uClibc
In-Reply-To: <1464865189.3047.16.camel@synopsys.com>
References: <1464014781-25347-1-git-send-email-abrodkin@synopsys.com>
 <1464263742.4578.22.camel@synopsys.com>
 <1464606749.3125.16.camel@synopsys.com>
 <1464767753.3171.18.camel@synopsys.com>
 <20160601172827.GG6825@waldemar-brodkorb.de>
 <1464865189.3047.16.camel@synopsys.com>
Message-ID: <78ca4db7-b737-078b-dc59-5bb8eaed4dbd@phrozen.org>



On 02/06/2016 13:00, Alexey Brodkin wrote:
> Hi Waldemar,
> 
> On Wed, 2016-06-01 at 19:28 +0200, Waldemar Brodkorb wrote:
>> Hi Alexey,
>>
>> Alexey Brodkin wrote,
>>
>>>
>>> Hi Waldemar,
>>>
>>> On Mon, 2016-05-30 at 14:12 +0300, Alexey Brodkin wrote:
>>>>
>>>> Hello,
>>>>
>>>> On Thu, 2016-05-26 at 14:55 +0300, Alexey Brodkin wrote:
>>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>> On Mon, 2016-05-23 at 17:46 +0300, Alexey Brodkin wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> This fixes util-linux building with uClibc.
>>>>>> Patch is taken as it is from Buildroot:
>>>>>> https://git.busybox.net/buildroot/plain/package/util-linux/0001-Fix-libmount-build-under-uClibc.patch?id=baccb
>>>>>> 506a
>>>>>> 6f
>>>>>> ea
>>>>>> bf114623866568121f49712f5df
>>>>>>
>>>>>> Signed-off-by: Alexey Brodkin <abrodkin at synopsys.com>
>>>>>> ---
>>>>>>  .../004-Fix-libmount-build-under-uClibc.patch      | 153 +++++++++++++++++++++
>>>>>>  1 file changed, 153 insertions(+)
>>>>>>  create mode 100644 package/utils/util-linux/patches/004-Fix-libmount-build-under-uClibc.patch
>>> We are discussing one issue with "util-linux" package building.
>>> The problem is in "util-linux" wants to use alloc modifier (either "%as"
>>> or "%ms") in scanf().
>>>
>>> Looks like uClibc still doesn't support neither "%ms" nor "%as" (this one
>>> is obsolete glibc-specific so let's not bother with it anyways).
>>>
>>> Now to work-around this missing requirement we used to use
>>> an off-the-tree patch like this one in Buildroot:
>>> https://git.busybox.net/buildroot/tree/package/util-linux/0001-Fix-libmount-build-under-uClibc.patch
>>>
>>> OpenWRT:
>>> https://git.lede-project.org/?p=source.git;a=blob;f=package/utils/util-linux/patches/001-no-printf-alloc.patch;h=ad9
>>> eef0
>>> 959bf0c8ce269e8039d4d05ef58e1d527;hb=8a7b28071fba84e297796c46d46e12b0967804e8
>>>
>>> Gentoo:
>>> https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-apps/util-linux/files/util-linux-2.21.1-no-printf-alloc
>>> .pat
>>> ch?revision=1.2
>>>
>>> The question to you is where do you think we should fix mentioned problem:
>>>  1) In uClibc-ng with addition of "%ms" support in scanf or
>> I would prefer this solution. I have started reading the code, but I
>> can't give you any guarantee when I can work on this.
>> Do you have free resources to cook up a patch? :)
> 
> You mean if I'm up to implement this missing feature in uClibc?
> Well I'd like to but as well not sure if and when I have time for that :)
> 
> For now we have a work-around with mentioned patches. So that's not a showstopper.
> 
> -Alexey
> 

well,t he requirement for keeping uclibc support in the tree is that
people fix uclibc issues. so someone has to fix it. waldemar promised to
address uclibc issues if we use his ng tree.

	John



From john at phrozen.org  Thu Jun  2 04:05:42 2016
From: john at phrozen.org (John Crispin)
Date: Thu, 2 Jun 2016 13:05:42 +0200
Subject: [LEDE-DEV] [PATCH] _GNU_SOURCE should be defined for building
 vs uClibc
In-Reply-To: <uhWo4L7ACTD8be4ub8dPtCgUi3fouPY3YfANfi6r211d@mailpile>
References: <20160601173255.GH6825@waldemar-brodkorb.de>
 <uhWo4L7ACTD8be4ub8dPtCgUi3fouPY3YfANfi6r211d@mailpile>
Message-ID: <eac79fa8-5f99-f719-a108-3986ffe95c64@phrozen.org>



On 02/06/2016 13:03, Karl Palsson wrote:
> 
> Waldemar Brodkorb <wbx at openadk.org> wrote:
>>>
>>> This still doesn't work on the uclibc in openwrt-CC branch. The
>>> O_PATH definitions are in asm-generic/fcntl.h, which can be
>>> included via linux/fcntl.h, _GNU_SOURCE doesn't get this pulled
>>> in though.
>>>
>>> I attempted to add includes for linux/fcntl, but it just gives me
>>> redeclaration errors for struct flock.
>>
>> The definition where added to uClibc-ng after 1.0.9 release.
>> LEDE included 1.0.14 recently. You need to update.
>>
> 
> I'm well aware that it would work if I was on living on the
> bleeding edge of latest LEDE. [1] I'm just reporting that, up
> until this O_PATH landed, procd fixes were still backportable to
> the last _released_ version of openwrt/lede. (uclibc 0.9.33.2)
> That is no longer the case.
> 
> Sincerely,
> Karl P
> 
> 
> [1] Everything always works, you just haven't pulled the latest!
> 

send a patch for procd ala

#ifndef O_PATH
#define O_PATH
#endif

drama solved

	John


From champetier.etienne at gmail.com  Thu Jun  2 04:20:25 2016
From: champetier.etienne at gmail.com (Etienne Champetier)
Date: Thu, 2 Jun 2016 13:20:25 +0200
Subject: [LEDE-DEV] git.openwrt.org site half broken
Message-ID: <CAOdf3grR_GG1st2yUx=DrKVS0WBc037g0D5+vRu9O1vwdaqKYQ@mail.gmail.com>

Hi,

someone messed with git.openwrt.org nginx config, i can't get the js and css.

see https://git.openwrt.org/project/static/gitweb.css (doesn't look
like a css :) )

Cheers
Etienne


From Alexey.Brodkin at synopsys.com  Thu Jun  2 06:41:03 2016
From: Alexey.Brodkin at synopsys.com (Alexey Brodkin)
Date: Thu, 2 Jun 2016 13:41:03 +0000
Subject: [LEDE-DEV] Add info about git URLs in Lede Git Web
Message-ID: <1464874823.3047.45.camel@synopsys.com>

Hello,

I think it would be quite convenient to add info about URLs
that could be used for accessing Lede repos via git.

In OpenWRT Git Web we had something like that:
----------------------->8-------------------
URL??http://git.openwrt.org/openwrt.git
? ? ?https://git.openwrt.org/openwrt.git
? ? ?git://git.openwrt.org/openwrt.git
----------------------->8-------------------

In case of Lede we don't have this information for example here:
https://git.lede-project.org/?p=source.git;a=summary

and every time one needs to figure out what is a correct URL that
should be passed to git. And it's not only URL itself but what
could be even more important what protocols could be used: git, http, https?

-Alexey

From bjorn at mork.no  Thu Jun  2 08:09:17 2016
From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=)
Date: Thu, 02 Jun 2016 17:09:17 +0200
Subject: [LEDE-DEV] Add info about git URLs in Lede Git Web
In-Reply-To: <1464874823.3047.45.camel@synopsys.com> (Alexey Brodkin's message
 of "Thu, 2 Jun 2016 13:41:03 +0000")
References: <1464874823.3047.45.camel@synopsys.com>
Message-ID: <87zir3wrtu.fsf@nemi.mork.no>

Alexey Brodkin <Alexey.Brodkin at synopsys.com> writes:

> Hello,
>
> I think it would be quite convenient to add info about URLs
> that could be used for accessing Lede repos via git.
>
> In OpenWRT Git Web we had something like that:
> ----------------------->8-------------------
> URL??http://git.openwrt.org/openwrt.git
> ? ? ?https://git.openwrt.org/openwrt.git
> ? ? ?git://git.openwrt.org/openwrt.git
> ----------------------->8-------------------
>
> In case of Lede we don't have this information for example here:
> https://git.lede-project.org/?p=source.git;a=summary
>
> and every time one needs to figure out what is a correct URL that
> should be passed to git. And it's not only URL itself but what
> could be even more important what protocols could be used: git, http, https?

+1


This should be as easy as setting

  @git_base_url_list = ('http://git.lede-project.org', 'git://git.lede-project.org');

in gitweb.conf



Bj?rn


From fhfrediani at gmail.com  Thu Jun  2 08:34:13 2016
From: fhfrediani at gmail.com (Fernando Frediani)
Date: Thu, 2 Jun 2016 12:34:13 -0300
Subject: [LEDE-DEV] Supported device list and documentation over at
	openwrt.org
In-Reply-To: <002701d1bc5f$bde12920$39a37b60$@orcon.net.nz>
References: <002701d1bc5f$bde12920$39a37b60$@orcon.net.nz>
Message-ID: <CAEHShq_4sBuQtZhdEDHk-QZh15_n_0WQkgd922TVKpRek8xCzA@mail.gmail.com>

This is a fantastic thing in OpenWrt and very helpful and I think
should be ported to LEDEas is. And I made myself available to help
with this once a Wiki is defined. However, if I understood correctlly,
someone pointed that "we" don't want specific device page which is
strange in my point of view.

Fernando

On 1 June 2016 at 20:45, Gareth Parker <gareth41 at orcon.net.nz> wrote:
> There is a lot of very useful specific router documentation still over at
> openwrt.org, technical details, de-bricking info, device mods, plus loads
> more info and photos relating to lots of individual devices.  Would it not
> be wise to also bring this over to the lede website?  I quite often refer
> back to a lot of this documentation.  With the openwrt problems and changes
> recently and people leaving openwrt for lede, I?m worried this documentation
> is in jeopardy of being lost.  I?ve seen this happen with other websites.
> If this were to happen it would certainly make life very difficult for some
> people, I often refer back to the openwrt website for quite a few things
> from time to time.  This plus the forum history is not mirrored anywhere
> else I?m aware of, correct me if I?m wrong though.
>
> Gareth
>
>
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


From jcmvbkbc at gmail.com  Thu Jun  2 09:31:44 2016
From: jcmvbkbc at gmail.com (Max Filippov)
Date: Thu, 2 Jun 2016 19:31:44 +0300
Subject: [LEDE-DEV] [uclibc-ng-devel] [PATCH] package/util-linux: Fix
 libmount build under uClibc
In-Reply-To: <1464767753.3171.18.camel@synopsys.com>
References: <1464014781-25347-1-git-send-email-abrodkin@synopsys.com>
 <1464263742.4578.22.camel@synopsys.com>
 <1464606749.3125.16.camel@synopsys.com>
 <1464767753.3171.18.camel@synopsys.com>
Message-ID: <CAMo8BfKboDoohwd_QPGicRai5a+6q9djxq6csFhO2SFZ0tXgfg@mail.gmail.com>

Hi Alexey,

On Wed, Jun 1, 2016 at 10:56 AM, Alexey Brodkin
<Alexey.Brodkin at synopsys.com> wrote:
> We are discussing one issue with "util-linux" package building.
> The problem is in "util-linux" wants to use alloc modifier (either "%as"
> or "%ms") in scanf().
>
> Looks like uClibc still doesn't support neither "%ms" nor "%as" (this one
> is obsolete glibc-specific so let's not bother with it anyways).

a while ago I touched %m support for %c and %[...] in uclibc
(b2d27c71bd13820a4263fa7ebda4c1a4a95b501c),
I've got an impression that %ms was working. I've expanded
test/stdio/scanf_m.c a bit (attached) and it appears to work.
So I'm curious, how the issue manifests itself.

-- 
Thanks.
-- Max
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-tests-add-ms-scanf-format-test.patch
Type: text/x-patch
Size: 1278 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20160602/a2396600/attachment.bin>

From lede at kitschensync.net  Thu Jun  2 10:02:02 2016
From: lede at kitschensync.net (Ted Hess)
Date: Thu, 02 Jun 2016 13:02:02 -0400
Subject: [LEDE-DEV] Add info about git URLs in Lede Git Web
In-Reply-To: <1464874823.3047.45.camel@synopsys.com>
References: <1464874823.3047.45.camel@synopsys.com>
Message-ID: <1464886922.2984.2.camel@kitschensync.net>

Check it out now...

/ted

On Thu, 2016-06-02 at 13:41 +0000, Alexey Brodkin wrote:
> Hello,
> 
> I think it would be quite convenient to add info about URLs
> that could be used for accessing Lede repos via git.
> 
> In OpenWRT Git Web we had something like that:
> ----------------------->8-------------------
> URL??http://git.openwrt.org/openwrt.git
> ? ? ?https://git.openwrt.org/openwrt.git
> ? ? ?git://git.openwrt.org/openwrt.git
> ----------------------->8-------------------
> 
> In case of Lede we don't have this information for example here:
> https://git.lede-project.org/?p=source.git;a=summary
> 
> and every time one needs to figure out what is a correct URL that
> should be passed to git. And it's not only URL itself but what
> could be even more important what protocols could be used: git, http, https?
> 
> -Alexey
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev



From john at phrozen.org  Thu Jun  2 10:18:44 2016
From: john at phrozen.org (John Crispin)
Date: Thu, 2 Jun 2016 19:18:44 +0200
Subject: [LEDE-DEV] Add info about git URLs in Lede Git Web
In-Reply-To: <1464886922.2984.2.camel@kitschensync.net>
References: <1464874823.3047.45.camel@synopsys.com>
 <1464886922.2984.2.camel@kitschensync.net>
Message-ID: <882df163-e404-4f62-5c0e-6f617aaa394b@phrozen.org>



On 02/06/2016 19:02, Ted Hess wrote:
> Check it out now...
> 

.... the funk soul brothers

> /ted
> 
> On Thu, 2016-06-02 at 13:41 +0000, Alexey Brodkin wrote:
>> Hello,
>>
>> I think it would be quite convenient to add info about URLs
>> that could be used for accessing Lede repos via git.
>>
>> In OpenWRT Git Web we had something like that:
>> ----------------------->8-------------------
>> URL  http://git.openwrt.org/openwrt.git
>>      https://git.openwrt.org/openwrt.git
>>      git://git.openwrt.org/openwrt.git
>> ----------------------->8-------------------
>>
>> In case of Lede we don't have this information for example here:
>> https://git.lede-project.org/?p=source.git;a=summary
>>
>> and every time one needs to figure out what is a correct URL that
>> should be passed to git. And it's not only URL itself but what
>> could be even more important what protocols could be used: git, http, https?
>>
>> -Alexey
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
> 
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 


From Alexey.Brodkin at synopsys.com  Thu Jun  2 10:22:48 2016
From: Alexey.Brodkin at synopsys.com (Alexey Brodkin)
Date: Thu, 2 Jun 2016 17:22:48 +0000
Subject: [LEDE-DEV] Add info about git URLs in Lede Git Web
In-Reply-To: <1464886922.2984.2.camel@kitschensync.net>
References: <1464874823.3047.45.camel@synopsys.com>
 <1464886922.2984.2.camel@kitschensync.net>
Message-ID: <1464888127.3047.76.camel@synopsys.com>

Hi Ted,

On Thu, 2016-06-02 at 13:02 -0400, Ted Hess wrote:
> Check it out now...

Indeed it's there!

Thanks a bunch!

-Alexey

From Alexey.Brodkin at synopsys.com  Thu Jun  2 10:23:47 2016
From: Alexey.Brodkin at synopsys.com (Alexey Brodkin)
Date: Thu, 2 Jun 2016 17:23:47 +0000
Subject: [LEDE-DEV] [uclibc-ng-devel] [PATCH] package/util-linux: Fix
 libmount build under uClibc
In-Reply-To: <CAMo8BfKboDoohwd_QPGicRai5a+6q9djxq6csFhO2SFZ0tXgfg@mail.gmail.com>
References: <1464014781-25347-1-git-send-email-abrodkin@synopsys.com>
 <1464263742.4578.22.camel@synopsys.com>
 <1464606749.3125.16.camel@synopsys.com>
 <1464767753.3171.18.camel@synopsys.com>
 <CAMo8BfKboDoohwd_QPGicRai5a+6q9djxq6csFhO2SFZ0tXgfg@mail.gmail.com>
Message-ID: <1464888187.3047.77.camel@synopsys.com>

Hi Max,

On Thu, 2016-06-02 at 19:31 +0300, Max Filippov wrote:
> Hi Alexey,
> 
> On Wed, Jun 1, 2016 at 10:56 AM, Alexey Brodkin
> <Alexey.Brodkin at synopsys.com> wrote:
> > 
> > We are discussing one issue with "util-linux" package building.
> > The problem is in "util-linux" wants to use alloc modifier (either "%as"
> > or "%ms") in scanf().
> > 
> > Looks like uClibc still doesn't support neither "%ms" nor "%as" (this one
> > is obsolete glibc-specific so let's not bother with it anyways).
> a while ago I touched %m support for %c and %[...] in uclibc
> (b2d27c71bd13820a4263fa7ebda4c1a4a95b501c),
> I've got an impression that %ms was working. I've expanded
> test/stdio/scanf_m.c a bit (attached) and it appears to work.
> So I'm curious, how the issue manifests itself.

During configuration of "util-linux" it tests if "%as" or "ms" could
be used when compiling a simple test. If not then "libmount" gets disabled.

Then in OpenWRT/Lede on installation of "util-linux" to staging folder
explicit "cp" is executed for copying some of "libmount" build artifacts and
since "libmount" was never built "cp" fails and so entire build stops.

-Alexey

From stijn at linux-ipv6.be  Thu Jun  2 10:26:10 2016
From: stijn at linux-ipv6.be (Stijn Tintel)
Date: Thu, 2 Jun 2016 19:26:10 +0200
Subject: [LEDE-DEV] [RFC v3 1/2] x86: enable DMI and DMI_SYSFS
In-Reply-To: <1464794074-27276-2-git-send-email-jo@mein.io>
References: <1464794074-27276-1-git-send-email-jo@mein.io>
 <1464794074-27276-2-git-send-email-jo@mein.io>
Message-ID: <7baf5252-f559-3340-d82d-31f2004eabad@linux-ipv6.be>

On 01-06-16 17:14, Jo-Philipp Wich wrote:
> Enable support for DMI decoding in the kernel so that we can access
> manufacturer and model information via sysfs.
>
> Signed-off-by: Jo-Philipp Wich <jo at mein.io>
> ---
>  target/linux/x86/config-4.4 | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/target/linux/x86/config-4.4 b/target/linux/x86/config-4.4
> index 5b54031..bb6ef65 100644
> --- a/target/linux/x86/config-4.4
> +++ b/target/linux/x86/config-4.4
> @@ -98,7 +98,8 @@ CONFIG_DECOMPRESS_BZIP2=y
>  CONFIG_DECOMPRESS_GZIP=y
>  CONFIG_DEFAULT_IO_DELAY_TYPE=0
>  # CONFIG_DELL_RBU is not set
> -# CONFIG_DMI is not set
> +CONFIG_DMI=y
> +CONFIG_DMI_SYSFS=y
>  CONFIG_DNOTIFY=y
>  CONFIG_DUMMY_CONSOLE=y
>  CONFIG_EARLY_PRINTK=y
This change causes missing symbols for x86/64, possibly other subtargets:
DMIID
LEDS_CLEVO_MAIL

And I think we should enable this for all x86 subtargets.

Stijn


From jcmvbkbc at gmail.com  Thu Jun  2 13:50:16 2016
From: jcmvbkbc at gmail.com (Max Filippov)
Date: Thu, 2 Jun 2016 23:50:16 +0300
Subject: [LEDE-DEV] [uclibc-ng-devel] [PATCH] package/util-linux: Fix
 libmount build under uClibc
In-Reply-To: <20160602164638.GM6825@waldemar-brodkorb.de>
References: <1464014781-25347-1-git-send-email-abrodkin@synopsys.com>
 <1464263742.4578.22.camel@synopsys.com>
 <1464606749.3125.16.camel@synopsys.com>
 <1464767753.3171.18.camel@synopsys.com>
 <CAMo8BfKboDoohwd_QPGicRai5a+6q9djxq6csFhO2SFZ0tXgfg@mail.gmail.com>
 <20160602164638.GM6825@waldemar-brodkorb.de>
Message-ID: <CAMo8BfK_K8hNPdLChc-nN9zNvJV_MpecWoAqDhoa9_jR4Ma26A@mail.gmail.com>

On Thu, Jun 2, 2016 at 7:46 PM, Waldemar Brodkorb <wbx at uclibc-ng.org> wrote:
> Hi,
> Max Filippov wrote,
>
>> Hi Alexey,
>>
>> On Wed, Jun 1, 2016 at 10:56 AM, Alexey Brodkin
>> <Alexey.Brodkin at synopsys.com> wrote:
>> > We are discussing one issue with "util-linux" package building.
>> > The problem is in "util-linux" wants to use alloc modifier (either "%as"
>> > or "%ms") in scanf().
>> >
>> > Looks like uClibc still doesn't support neither "%ms" nor "%as" (this one
>> > is obsolete glibc-specific so let's not bother with it anyways).
>>
>> a while ago I touched %m support for %c and %[...] in uclibc
>> (b2d27c71bd13820a4263fa7ebda4c1a4a95b501c),
>> I've got an impression that %ms was working. I've expanded
>> test/stdio/scanf_m.c a bit (attached) and it appears to work.
>> So I'm curious, how the issue manifests itself.
>
> Thanks for the patch.
> Indeed I was wondering why I have no patch included
> in OpenADK. I am overriding the configure check:
> CONFIGURE_ENV+=         have_scanf_alloc_modifier=yes \
>                         scanf_cv_alloc_modifier=ms
>
> So either the autoconf check is faulty or uClibc-ng implementation
> is somehow not correct.
>
> We need to check the autoconf configure check.

The check looks like this:

|      #include <stdio.h>
|      #include <unistd.h>
|
|      #ifdef __GLIBC__
|
|      #if !(__GLIBC_PREREQ(2, 7))
|      #error %m is not available
|      #endif
|
|      #elif defined(_POSIX_VERSION)
|
|      #if _POSIX_VERSION < 200809L
|      #error %m is not available
|      #endif
|
|      #else
|      #error Your C-library is not supported.
|      #endif


And its result with uClibc-ng is the following:

conftest.c:136:7: error: #error %m is not available
      #error %m is not available

Because we have the following definition in features.h:

/* Major and minor version number of the GNU C library package.  Use
   these macros to test for features in specific releases.  */
/* Don't do it, if you want to keep uClibc happy.  */
#define __GLIBC__       2
#define __GLIBC_MINOR__ 2

-- 
Thanks.
-- Max


From hauke at hauke-m.de  Thu Jun  2 13:57:24 2016
From: hauke at hauke-m.de (Hauke Mehrtens)
Date: Thu, 2 Jun 2016 22:57:24 +0200
Subject: [LEDE-DEV] [PATCH v2 1/2] lantiq: unmacro tp-link boards
In-Reply-To: <20160601003058.2efb511a@lazus.yip>
References: <20160530095406.17056-1-lynxis@fe80.eu>
 <20160531204611.GA18981@ugly.lan> <20160601003058.2efb511a@lazus.yip>
Message-ID: <a304e03a-8395-a5c0-39c9-33bd51b83294@hauke-m.de>

On 06/01/2016 12:30 AM, Alexander Couzens wrote:
> On Tue, 31 May 2016 22:46:11 +0200
> Oswald Buddenhagen <oswald.buddenhagen at gmx.de> wrote:
> 
>> you're undoing work by hauke et. al from just a few weeks ago. ;)
> ooops. ;P

Not really, I was converting this to the new image build system. This is
just a minor change.

I think this is ok.

Hauke



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20160602/178f5650/attachment.sig>

From john at phrozen.org  Thu Jun  2 14:06:06 2016
From: john at phrozen.org (John Crispin)
Date: Thu, 2 Jun 2016 23:06:06 +0200
Subject: [LEDE-DEV] [PATCH v2 1/2] lantiq: unmacro tp-link boards
In-Reply-To: <a304e03a-8395-a5c0-39c9-33bd51b83294@hauke-m.de>
References: <20160530095406.17056-1-lynxis@fe80.eu>
 <20160531204611.GA18981@ugly.lan> <20160601003058.2efb511a@lazus.yip>
 <a304e03a-8395-a5c0-39c9-33bd51b83294@hauke-m.de>
Message-ID: <774da52f-b198-f379-53b3-93cfd34e95c1@phrozen.org>



On 02/06/2016 22:57, Hauke Mehrtens wrote:
> On 06/01/2016 12:30 AM, Alexander Couzens wrote:
>> On Tue, 31 May 2016 22:46:11 +0200
>> Oswald Buddenhagen <oswald.buddenhagen at gmx.de> wrote:
>>
>>> you're undoing work by hauke et. al from just a few weeks ago. ;)
>> ooops. ;P
> 
> Not really, I was converting this to the new image build system. This is
> just a minor change.
> 
> I think this is ok.
> 
> Hauke
> 

indeed, i unmacroed it even more

https://git.lede-project.org/?p=lede/blogic/staging.git;a=commit;h=016e2677b2670a3ccd14c5deaa7c2ace9209eac3


From champetier.etienne at gmail.com  Thu Jun  2 14:21:33 2016
From: champetier.etienne at gmail.com (Etienne CHAMPETIER)
Date: Thu,  2 Jun 2016 21:21:33 +0000
Subject: [LEDE-DEV] [PATCH] urandom-seed: add initial implementation
Message-ID: <1464902493-25779-1-git-send-email-champetier.etienne@gmail.com>

This package:
1) seed /dev/urandom with a saved seed as early as possible
    (using /lib/preinit/81_urandom_seed)
2) save a new seed using getrandom() so we are sure /dev/urandom
   pool is initialized (using /etc/init.d/urandom_seed)

seed size is 512 bytes (ie /proc/sys/kernel/random/poolsize / 8)
it's the same size as in ubuntu 14.04 and all systemd systems

seed file is /etc/urandom.seed (need a writable path)

seeding /dev/urandom doesn't change entropy estimation, so we still have
"random: ubus urandom read with 4 bits of entropy available"
messages in the logs, but we can now ignore them

Once tested on enough configuration (jffs2/ext4/ubifs/...)
this package should be added to DEFAULT_PACKAGES

We could also add an urandom.seed at build time to improve first boot

Signed-off-by: Etienne CHAMPETIER <champetier.etienne at gmail.com>
---
 package/utils/urandom-seed/Makefile                | 53 ++++++++++++++++++++
 .../urandom-seed/files/81_urandom_seed.preinit     | 15 ++++++
 package/utils/urandom-seed/files/getrandom.c       | 58 ++++++++++++++++++++++
 package/utils/urandom-seed/files/urandom_seed.init | 19 +++++++
 4 files changed, 145 insertions(+)
 create mode 100644 package/utils/urandom-seed/Makefile
 create mode 100644 package/utils/urandom-seed/files/81_urandom_seed.preinit
 create mode 100644 package/utils/urandom-seed/files/getrandom.c
 create mode 100644 package/utils/urandom-seed/files/urandom_seed.init

diff --git a/package/utils/urandom-seed/Makefile b/package/utils/urandom-seed/Makefile
new file mode 100644
index 0000000..ac58bfc
--- /dev/null
+++ b/package/utils/urandom-seed/Makefile
@@ -0,0 +1,53 @@
+#
+# Copyright (C) 2016 Etienne CHAMPETIER <champetier.etienne at gmail.com>
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=urandom-seed
+PKG_RELEASE:=1
+PKG_LICENSE:=GPL-2.0
+PKG_LICENSE_FILES:=COPYING
+PKG_BUILD_DIR := $(BUILD_DIR)/$(PKG_NAME)_$(PKG_RELEASE)
+PKG_FLAGS:=nonshared
+
+include $(INCLUDE_DIR)/package.mk
+
+define Package/urandom-seed
+  SECTION:=utils
+  CATEGORY:=Base system
+  TITLE:=Seed /dev/urandom on startup
+  MAINTAINER:=Etienne CHAMPETIER <champetier.etienne at gmail.com>
+endef
+
+define Package/urandom-seed/description
+This package takes care of loading a previously saved seed into /dev/urandom,
+and save a new seed from getrandom()
+endef
+
+define Build/Prepare
+	mkdir -p $(PKG_BUILD_DIR)
+endef
+
+define Build/Configure
+endef
+
+define Build/Compile
+	$(TARGET_CC) $(TARGET_CFLAGS) ./files/getrandom.c -o $(PKG_BUILD_DIR)/getrandom
+endef
+
+define Package/urandom-seed/install
+	$(INSTALL_DIR) $(1)/usr/bin
+	$(INSTALL_BIN) $(PKG_BUILD_DIR)/getrandom $(1)/usr/bin/
+
+	$(INSTALL_DIR) $(1)/lib/preinit
+	$(INSTALL_DATA) ./files/81_urandom_seed.preinit $(1)/lib/preinit/81_urandom_seed
+
+	$(INSTALL_DIR) $(1)/etc/init.d
+	$(INSTALL_BIN) ./files/urandom_seed.init $(1)/etc/init.d/urandom_seed
+endef
+
+$(eval $(call BuildPackage,urandom-seed))
diff --git a/package/utils/urandom-seed/files/81_urandom_seed.preinit b/package/utils/urandom-seed/files/81_urandom_seed.preinit
new file mode 100644
index 0000000..27ff587
--- /dev/null
+++ b/package/utils/urandom-seed/files/81_urandom_seed.preinit
@@ -0,0 +1,15 @@
+#!/bin/sh
+
+do_urandom_seed() {
+    S=/etc/urandom.seed
+    U=/dev/urandom
+
+    [ -c $U ] || { echo "Something is wrong with $U"; return; }
+    [ -f $S ] || { echo "Seed file not found: $S"; return; }
+    [ -O $S -a -G $S -a ! -x $S ] || { echo "Wrong owner / permissions for $S"; return; }
+
+    echo "Seeding $U with $S"
+    cat $S > $U
+}
+
+boot_hook_add preinit_main do_urandom_seed
diff --git a/package/utils/urandom-seed/files/getrandom.c b/package/utils/urandom-seed/files/getrandom.c
new file mode 100644
index 0000000..2093ef8
--- /dev/null
+++ b/package/utils/urandom-seed/files/getrandom.c
@@ -0,0 +1,58 @@
+/*
+ * Copyright (C) 2016 Etienne Champetier <champetier.etienne at gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#define _GNU_SOURCE
+#include <errno.h>
+#include <linux/random.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <sys/syscall.h>
+#include <unistd.h>
+
+#define ERROR_EXIT(fmt, ...) do { \
+        fprintf(stderr, fmt, ## __VA_ARGS__); \
+        return EXIT_FAILURE; \
+        } while (0)
+
+int usage(char *name)
+{
+    fprintf(stderr, "Usage: %s <nb>\n", name);
+    fprintf(stderr, " => return <nb> bytes from getrandom()\n");
+    return EXIT_FAILURE;
+}
+
+int main(int argc, char *argv[])
+{
+    if (argc != 2)
+        return usage(argv[0]);
+
+    if (isatty(STDOUT_FILENO))
+        ERROR_EXIT("Not outputting random to a tty\n");
+
+    int nbtot = atoi(argv[1]);
+    if (nbtot < 1)
+        ERROR_EXIT("Invalid <nb> param (must be > 0)\n");
+
+    char buf[256];
+    int len = sizeof(buf);
+    while (nbtot > 0) {
+        if (nbtot <= sizeof(buf))
+            len = nbtot;
+        if (syscall(SYS_getrandom, buf, len, 0) == -1)
+            ERROR_EXIT("getrandom() failed: %s\n", strerror(errno));
+        if (write(STDOUT_FILENO, buf, len) != len)
+            ERROR_EXIT("write() failed: %s\n", strerror(errno));
+        nbtot -= sizeof(buf);
+    }
+}
diff --git a/package/utils/urandom-seed/files/urandom_seed.init b/package/utils/urandom-seed/files/urandom_seed.init
new file mode 100644
index 0000000..b2aba28
--- /dev/null
+++ b/package/utils/urandom-seed/files/urandom_seed.init
@@ -0,0 +1,19 @@
+#!/bin/sh /etc/rc.common
+
+START=99
+
+SEED=/etc/urandom.seed
+
+save_seed() {
+    touch $SEED.tmp
+    chown root:root $SEED.tmp
+    chmod 600 $SEED.tmp
+    getrandom 512 > $SEED.tmp
+
+    logger "Saving urandom seed to $SEED"
+    mv $SEED.tmp $SEED
+}
+
+boot() {
+    save_seed
+}
-- 
1.9.1



From kaleb at wolfssl.com  Thu Jun  2 14:56:51 2016
From: kaleb at wolfssl.com (Kaleb Himes)
Date: Thu, 2 Jun 2016 15:56:51 -0600
Subject: [LEDE-DEV]  [PATCH] cyassl/wolfssl: update to 3.9.0
Message-ID: <CAMB3dQXwHEpuKMOTR_jgS4Fwd_LagsdsbnqOAp-BfPa7_-9nMQ@mail.gmail.com>

Hi Dirk and LEDE members,

We noticed this is a reboot of the OpenWRT project whom we actively
supported in the past. We wanted to reach out to the community today
and let you know we are aware of the restructuring going on and look
forward to actively supporting LEDE as we did OpenWRT. As fans of open
source software we provide free support to all open source projects!

Could you tell us a little more about what is new in this community
and what we have missed out on during the reboot? We are excited to
see someone is consciously making an effort to drive development of an
embedded linux distribution.

Could you let us know how our embedded ssl / tls library is working for you?

We try to put out 7-8 releases per year and the latest can always be
retrieved here: https://wolfssl.com/wolfSSL/download/downloadForm.php

Alternatively you can clone our development branch from github here:
https://github.com/wolfSSL/wolfssl

Thank you for your time, we look forward to an ongoing relationship
with the LEDE community and are always eager to collaborate.

Feel free to contact us anytime info at wolfssl.com or support at wolfssl.com.


Kind Regards,

The wolfSSL Team
www.wolfssl.com
Kaleb Himes


From wbx at uclibc-ng.org  Thu Jun  2 19:23:28 2016
From: wbx at uclibc-ng.org (Waldemar Brodkorb)
Date: Fri, 3 Jun 2016 04:23:28 +0200
Subject: [LEDE-DEV] [PATCH] fix uClibc-ng scanf check
Message-ID: <20160603022328.GA24494@waldemar-brodkorb.de>

uClibc-ng tries to be compatible with GNU libc and defines
__GLIBC__ and pretend to be version 2.2.
We once changed it to 2.10, but then some hard to fix problems
in different software packages (gcc) occured.
It would be better if we disable the special GNU libc checks
for uClibc-ng here. uClibc-ng implements the required scanf
functionality.

Signed-off-by: Waldemar Brodkorb <wbx at uclibc-ng.org>
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index f36b18c..4661c0d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -581,7 +581,7 @@ AC_CACHE_VAL([scanf_cv_alloc_modifier],
      #include <stdio.h>
      #include <unistd.h>
 
-     #ifdef __GLIBC__
+     #if defined(__GLIBC__) && !defined(__UCLIBC__)
 
      #if !(__GLIBC_PREREQ(2, 7))
      #error %m is not available
-- 
2.1.4



From john at phrozen.org  Fri Jun  3 01:54:57 2016
From: john at phrozen.org (John Crispin)
Date: Fri, 3 Jun 2016 10:54:57 +0200
Subject: [LEDE-DEV] [PATCH] fix uClibc-ng scanf check
In-Reply-To: <20160603022328.GA24494@waldemar-brodkorb.de>
References: <20160603022328.GA24494@waldemar-brodkorb.de>
Message-ID: <9e2695e1-1cb7-38bc-c1da-0fdbd1f1af3f@phrozen.org>

Hi Waldemar

On 03/06/2016 04:23, Waldemar Brodkorb wrote:
> uClibc-ng tries to be compatible with GNU libc and defines
> __GLIBC__ and pretend to be version 2.2.
> We once changed it to 2.10, but then some hard to fix problems
> in different software packages (gcc) occured.
> It would be better if we disable the special GNU libc checks
> for uClibc-ng here. uClibc-ng implements the required scanf
> functionality.
> 
> Signed-off-by: Waldemar Brodkorb <wbx at uclibc-ng.org>
> ---
>  configure.ac | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/configure.ac b/configure.ac
> index f36b18c..4661c0d 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -581,7 +581,7 @@ AC_CACHE_VAL([scanf_cv_alloc_modifier],
>       #include <stdio.h>
>       #include <unistd.h>
>  
> -     #ifdef __GLIBC__
> +     #if defined(__GLIBC__) && !defined(__UCLIBC__)
>  
>       #if !(__GLIBC_PREREQ(2, 7))
>       #error %m is not available
> 


this is the raw patch. please send a patch that adds this patch at the
right place inside the tree.

	John


From john at phrozen.org  Fri Jun  3 02:00:03 2016
From: john at phrozen.org (John Crispin)
Date: Fri, 3 Jun 2016 11:00:03 +0200
Subject: [LEDE-DEV] [PATCH] urandom-seed: add initial implementation
In-Reply-To: <1464902493-25779-1-git-send-email-champetier.etienne@gmail.com>
References: <1464902493-25779-1-git-send-email-champetier.etienne@gmail.com>
Message-ID: <ef5ec979-8a79-299e-0491-c4181e0fb0a9@phrozen.org>

Hi Etienne,

comment inline ...

On 02/06/2016 23:21, Etienne CHAMPETIER wrote:
> This package:
> 1) seed /dev/urandom with a saved seed as early as possible
>     (using /lib/preinit/81_urandom_seed)
> 2) save a new seed using getrandom() so we are sure /dev/urandom
>    pool is initialized (using /etc/init.d/urandom_seed)
> 
> seed size is 512 bytes (ie /proc/sys/kernel/random/poolsize / 8)
> it's the same size as in ubuntu 14.04 and all systemd systems
> 
> seed file is /etc/urandom.seed (need a writable path)
> 
> seeding /dev/urandom doesn't change entropy estimation, so we still have
> "random: ubus urandom read with 4 bits of entropy available"
> messages in the logs, but we can now ignore them
> 
> Once tested on enough configuration (jffs2/ext4/ubifs/...)
> this package should be added to DEFAULT_PACKAGES
> 
> We could also add an urandom.seed at build time to improve first boot
> 
> Signed-off-by: Etienne CHAMPETIER <champetier.etienne at gmail.com>
> ---
>  package/utils/urandom-seed/Makefile                | 53 ++++++++++++++++++++
>  .../urandom-seed/files/81_urandom_seed.preinit     | 15 ++++++
>  package/utils/urandom-seed/files/getrandom.c       | 58 ++++++++++++++++++++++
>  package/utils/urandom-seed/files/urandom_seed.init | 19 +++++++
>  4 files changed, 145 insertions(+)
>  create mode 100644 package/utils/urandom-seed/Makefile
>  create mode 100644 package/utils/urandom-seed/files/81_urandom_seed.preinit
>  create mode 100644 package/utils/urandom-seed/files/getrandom.c
>  create mode 100644 package/utils/urandom-seed/files/urandom_seed.init
> 
> diff --git a/package/utils/urandom-seed/Makefile b/package/utils/urandom-seed/Makefile
> new file mode 100644
> index 0000000..ac58bfc
> --- /dev/null
> +++ b/package/utils/urandom-seed/Makefile
> @@ -0,0 +1,53 @@
> +#
> +# Copyright (C) 2016 Etienne CHAMPETIER <champetier.etienne at gmail.com>
> +#
> +# This is free software, licensed under the GNU General Public License v2.
> +# See /LICENSE for more information.
> +#
> +
> +include $(TOPDIR)/rules.mk
> +
> +PKG_NAME:=urandom-seed
> +PKG_RELEASE:=1
> +PKG_LICENSE:=GPL-2.0
> +PKG_LICENSE_FILES:=COPYING
> +PKG_BUILD_DIR := $(BUILD_DIR)/$(PKG_NAME)_$(PKG_RELEASE)
> +PKG_FLAGS:=nonshared
> +
> +include $(INCLUDE_DIR)/package.mk
> +
> +define Package/urandom-seed
> +  SECTION:=utils
> +  CATEGORY:=Base system
> +  TITLE:=Seed /dev/urandom on startup
> +  MAINTAINER:=Etienne CHAMPETIER <champetier.etienne at gmail.com>
> +endef
> +
> +define Package/urandom-seed/description
> +This package takes care of loading a previously saved seed into /dev/urandom,
> +and save a new seed from getrandom()
> +endef
> +
> +define Build/Prepare
> +	mkdir -p $(PKG_BUILD_DIR)
> +endef
> +
> +define Build/Configure
> +endef
> +
> +define Build/Compile
> +	$(TARGET_CC) $(TARGET_CFLAGS) ./files/getrandom.c -o $(PKG_BUILD_DIR)/getrandom
> +endef
> +
> +define Package/urandom-seed/install
> +	$(INSTALL_DIR) $(1)/usr/bin
> +	$(INSTALL_BIN) $(PKG_BUILD_DIR)/getrandom $(1)/usr/bin/
> +
> +	$(INSTALL_DIR) $(1)/lib/preinit
> +	$(INSTALL_DATA) ./files/81_urandom_seed.preinit $(1)/lib/preinit/81_urandom_seed
> +
> +	$(INSTALL_DIR) $(1)/etc/init.d
> +	$(INSTALL_BIN) ./files/urandom_seed.init $(1)/etc/init.d/urandom_seed
> +endef
> +
> +$(eval $(call BuildPackage,urandom-seed))
> diff --git a/package/utils/urandom-seed/files/81_urandom_seed.preinit b/package/utils/urandom-seed/files/81_urandom_seed.preinit
> new file mode 100644
> index 0000000..27ff587
> --- /dev/null
> +++ b/package/utils/urandom-seed/files/81_urandom_seed.preinit
> @@ -0,0 +1,15 @@
> +#!/bin/sh
> +
> +do_urandom_seed() {
> +    S=/etc/urandom.seed
> +    U=/dev/urandom
> +
> +    [ -c $U ] || { echo "Something is wrong with $U"; return; }
> +    [ -f $S ] || { echo "Seed file not found: $S"; return; }
> +    [ -O $S -a -G $S -a ! -x $S ] || { echo "Wrong owner / permissions for $S"; return; }
> +
> +    echo "Seeding $U with $S"
> +    cat $S > $U
> +}
> +
> +boot_hook_add preinit_main do_urandom_seed
> diff --git a/package/utils/urandom-seed/files/getrandom.c b/package/utils/urandom-seed/files/getrandom.c
> new file mode 100644
> index 0000000..2093ef8
> --- /dev/null
> +++ b/package/utils/urandom-seed/files/getrandom.c
> @@ -0,0 +1,58 @@
> +/*
> + * Copyright (C) 2016 Etienne Champetier <champetier.etienne at gmail.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +#define _GNU_SOURCE
> +#include <errno.h>
> +#include <linux/random.h>
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <string.h>
> +#include <sys/syscall.h>
> +#include <unistd.h>
> +
> +#define ERROR_EXIT(fmt, ...) do { \
> +        fprintf(stderr, fmt, ## __VA_ARGS__); \
> +        return EXIT_FAILURE; \
> +        } while (0)
> +
> +int usage(char *name)
> +{
> +    fprintf(stderr, "Usage: %s <nb>\n", name);
> +    fprintf(stderr, " => return <nb> bytes from getrandom()\n");
> +    return EXIT_FAILURE;
> +}
> +
> +int main(int argc, char *argv[])
> +{
> +    if (argc != 2)
> +        return usage(argv[0]);
> +
> +    if (isatty(STDOUT_FILENO))
> +        ERROR_EXIT("Not outputting random to a tty\n");
> +
> +    int nbtot = atoi(argv[1]);
> +    if (nbtot < 1)
> +        ERROR_EXIT("Invalid <nb> param (must be > 0)\n");
> +
> +    char buf[256];
> +    int len = sizeof(buf);
> +    while (nbtot > 0) {
> +        if (nbtot <= sizeof(buf))
> +            len = nbtot;
> +        if (syscall(SYS_getrandom, buf, len, 0) == -1)
> +            ERROR_EXIT("getrandom() failed: %s\n", strerror(errno));
> +        if (write(STDOUT_FILENO, buf, len) != len)
> +            ERROR_EXIT("write() failed: %s\n", strerror(errno));
> +        nbtot -= sizeof(buf);
> +    }
> +}

i was wondering if we really need this extra tool to do the job. i see
you are using the new get_random syscall. i assume there is no other way
to get that randomness from the userland using a script ? normally i
would go for /dev/(u)random but obvioulsy that is not possible here.

if we really need this tool, i would prefer to just integrate it into
the procd.git tree to avoid having an extra package. we would want to
always install it anyhow.

rest looks good on first glance, thanks for the effort.

	John



> diff --git a/package/utils/urandom-seed/files/urandom_seed.init b/package/utils/urandom-seed/files/urandom_seed.init
> new file mode 100644
> index 0000000..b2aba28
> --- /dev/null
> +++ b/package/utils/urandom-seed/files/urandom_seed.init
> @@ -0,0 +1,19 @@
> +#!/bin/sh /etc/rc.common
> +
> +START=99
> +
> +SEED=/etc/urandom.seed
> +
> +save_seed() {
> +    touch $SEED.tmp
> +    chown root:root $SEED.tmp
> +    chmod 600 $SEED.tmp
> +    getrandom 512 > $SEED.tmp
> +
> +    logger "Saving urandom seed to $SEED"
> +    mv $SEED.tmp $SEED
> +}
> +
> +boot() {
> +    save_seed
> +}
> 


From john at phrozen.org  Fri Jun  3 02:05:09 2016
From: john at phrozen.org (John Crispin)
Date: Fri, 3 Jun 2016 11:05:09 +0200
Subject: [LEDE-DEV] [PATCH libubox] blobmsg_json: add new functions
 blobmsg_format_json_value*
In-Reply-To: <dbc90f6d05a606753e2576bd6fc3569c5958885a.1464812878.git.mschiffer@universe-factory.net>
References: <dbc90f6d05a606753e2576bd6fc3569c5958885a.1464812878.git.mschiffer@universe-factory.net>
Message-ID: <e63ded11-8ba8-c0da-78ee-a5be70eca1fd@phrozen.org>



On 01/06/2016 22:27, Matthias Schiffer wrote:
> The current blobmsg_format_json* functions will return invalid JSON when
> the "list" argument is given as false (blobmsg_format_element() will
> output the name of the blob_attr as if the value is printed as part of a
> JSON object).
> 
> To avoid breaking software relying on this behaviour, introduce new
> functions which will never print the blob_attr name and thus always
> produce valid JSON.

what software relies on this function/behaviour ? maybe we should mark
the current implementation as deprected and drop support in time X.
producing broken json syntax seems very fragile.

	John

> 
> Signed-off-by: Matthias Schiffer <mschiffer at universe-factory.net>
> ---
>  blobmsg_json.c | 49 ++++++++++++++++++++++++++++++++++++-------------
>  blobmsg_json.h | 14 ++++++++++++++
>  2 files changed, 50 insertions(+), 13 deletions(-)
> 
> diff --git a/blobmsg_json.c b/blobmsg_json.c
> index 5713948..538c816 100644
> --- a/blobmsg_json.c
> +++ b/blobmsg_json.c
> @@ -207,7 +207,7 @@ static void blobmsg_format_string(struct strbuf *s, const char *str)
>  
>  static void blobmsg_format_json_list(struct strbuf *s, struct blob_attr *attr, int len, bool array);
>  
> -static void blobmsg_format_element(struct strbuf *s, struct blob_attr *attr, bool array, bool head)
> +static void blobmsg_format_element(struct strbuf *s, struct blob_attr *attr, bool without_name, bool head)
>  {
>  	const char *data_str;
>  	char buf[32];
> @@ -217,7 +217,7 @@ static void blobmsg_format_element(struct strbuf *s, struct blob_attr *attr, boo
>  	if (!blobmsg_check_attr(attr, false))
>  		return;
>  
> -	if (!array && blobmsg_name(attr)[0]) {
> +	if (!without_name && blobmsg_name(attr)[0]) {
>  		blobmsg_format_string(s, blobmsg_name(attr));
>  		blobmsg_puts(s, ": ", s->indent ? 2 : 1);
>  	}
> @@ -286,22 +286,26 @@ static void blobmsg_format_json_list(struct strbuf *s, struct blob_attr *attr, i
>  	blobmsg_puts(s, (array ? "]" : "}"), 1);
>  }
>  
> +static void setup_strbuf(struct strbuf *s, struct blob_attr *attr, blobmsg_json_format_t cb, void *priv, int indent) {
> +	s->len = blob_len(attr);
> +	s->buf = malloc(s->len);
> +	s->pos = 0;
> +	s->custom_format = cb;
> +	s->priv = priv;
> +	s->indent = false;
> +
> +	if (indent >= 0) {
> +		s->indent = true;
> +		s->indent_level = indent;
> +	}
> +}
> +
>  char *blobmsg_format_json_with_cb(struct blob_attr *attr, bool list, blobmsg_json_format_t cb, void *priv, int indent)
>  {
>  	struct strbuf s;
>  	bool array;
>  
> -	s.len = blob_len(attr);
> -	s.buf = malloc(s.len);
> -	s.pos = 0;
> -	s.custom_format = cb;
> -	s.priv = priv;
> -	s.indent = false;
> -
> -	if (indent >= 0) {
> -		s.indent = true;
> -		s.indent_level = indent;
> -	}
> +	setup_strbuf(&s, attr, cb, priv, indent);
>  
>  	array = blob_is_extended(attr) &&
>  		blobmsg_type(attr) == BLOBMSG_TYPE_ARRAY;
> @@ -321,3 +325,22 @@ char *blobmsg_format_json_with_cb(struct blob_attr *attr, bool list, blobmsg_jso
>  
>  	return s.buf;
>  }
> +
> +char *blobmsg_format_json_value_with_cb(struct blob_attr *attr, blobmsg_json_format_t cb, void *priv, int indent)
> +{
> +	struct strbuf s;
> +
> +	setup_strbuf(&s, attr, cb, priv, indent);
> +
> +	blobmsg_format_element(&s, attr, true, false);
> +
> +	if (!s.len) {
> +		free(s.buf);
> +		return NULL;
> +	}
> +
> +	s.buf = realloc(s.buf, s.pos + 1);
> +	s.buf[s.pos] = 0;
> +
> +	return s.buf;
> +}
> diff --git a/blobmsg_json.h b/blobmsg_json.h
> index cd9ed33..9dfc02d 100644
> --- a/blobmsg_json.h
> +++ b/blobmsg_json.h
> @@ -42,4 +42,18 @@ static inline char *blobmsg_format_json_indent(struct blob_attr *attr, bool list
>  	return blobmsg_format_json_with_cb(attr, list, NULL, NULL, indent);
>  }
>  
> +char *blobmsg_format_json_value_with_cb(struct blob_attr *attr,
> +					blobmsg_json_format_t cb, void *priv,
> +					int indent);
> +
> +static inline char *blobmsg_format_json_value(struct blob_attr *attr)
> +{
> +	return blobmsg_format_json_value_with_cb(attr, NULL, NULL, -1);
> +}
> +
> +static inline char *blobmsg_format_json_value_indent(struct blob_attr *attr, int indent)
> +{
> +	return blobmsg_format_json_value_with_cb(attr, NULL, NULL, indent);
> +}
> +
>  #endif
> 


From john at phrozen.org  Fri Jun  3 02:09:28 2016
From: john at phrozen.org (John Crispin)
Date: Fri, 3 Jun 2016 11:09:28 +0200
Subject: [LEDE-DEV] [PATCH] package/devel/gdb: Add support of ARC gdb
In-Reply-To: <1464795158-4753-1-git-send-email-abrodkin@synopsys.com>
References: <1464795158-4753-1-git-send-email-abrodkin@synopsys.com>
Message-ID: <3b23b081-1df6-1a11-2162-b7ff223a44ec@phrozen.org>

Hi,

On 01/06/2016 17:32, Alexey Brodkin wrote:
> As of today gdb port for ARC is not yet in upstream even though
> we're working hard on that.
> 
> Still to allow ARC users to debug user-space apps on top of
> Linux kernel we're adding here support for building GDB from
> sources hosted on our GitHub here:
> https://github.com/foss-for-synopsys-dwc-arc-processors/binutils-gdb/releases/tag/arc-2016.03-gdb
> 
> Likewise for host GDB sources that come from unified git repository
> (which is the case for upstream binutils/gdb today) we need to disable
> building of binutils in gdb:
> ------>8------
> --disable-binutils
> --disable-ld
> --disable-gas
> ------>8------
> 

these work for !arc targets. disabling them for all targets because they
are broken on arc seem weird even if they might not be used.

rather than cluttering the makefile how about marking the packahe broken
for arc and adding a new one called gdb-arc that depends on arc only.
this will allow us to keep gdb clean and just drop the gdb-arc package
once the fixes treacled down the tree.

	John


> Also we disable sim because if the following breakage while
> building with it:
> ------------>8------------
> /usr/bin/env bash ./../common/genmloop.sh -shell /usr/bin/env bash \
>     -mono -fast -pbb -switch sem5-switch.c \
>     -cpu a5f -infile ./mloop5.in \
>     -outfile-suffix 5
> unknown option: bash
> Makefile:699: recipe for target 'stamp-5mloop' failed
> make[7]: *** [stamp-5mloop] Error 1
> ------------>8------------
> 
> Signed-off-by: Alexey Brodkin <abrodkin at synopsys.com>
> Cc: John Crispin <john at phrozen.org>
> Cc: Felix Fietkau <nbd at nbd.name>
> ---
>  package/devel/gdb/Makefile                         | 23 ++++++++++++++--
>  .../001-gdb-pr14523-mips-signal-number.patch       |  0
>  .../gdb/patches/{ => 7.11}/100-musl_fix.patch      |  0
>  .../patches/arc-2016.03/100-no_extern_inline.patch | 32 ++++++++++++++++++++++
>  .../gdb/patches/arc-2016.03/110-no_testsuite.patch | 21 ++++++++++++++
>  .../120-fix-compile-flag-mismatch.patch            | 11 ++++++++
>  .../arc-2016.03/200-arc-fix-target-mask.patch      | 13 +++++++++
>  7 files changed, 98 insertions(+), 2 deletions(-)
>  rename package/devel/gdb/patches/{ => 7.11}/001-gdb-pr14523-mips-signal-number.patch (100%)
>  rename package/devel/gdb/patches/{ => 7.11}/100-musl_fix.patch (100%)
>  create mode 100644 package/devel/gdb/patches/arc-2016.03/100-no_extern_inline.patch
>  create mode 100644 package/devel/gdb/patches/arc-2016.03/110-no_testsuite.patch
>  create mode 100644 package/devel/gdb/patches/arc-2016.03/120-fix-compile-flag-mismatch.patch
>  create mode 100644 package/devel/gdb/patches/arc-2016.03/200-arc-fix-target-mask.patch
> 
> diff --git a/package/devel/gdb/Makefile b/package/devel/gdb/Makefile
> index f6d5fec..2e6b332 100644
> --- a/package/devel/gdb/Makefile
> +++ b/package/devel/gdb/Makefile
> @@ -8,12 +8,27 @@
>  include $(TOPDIR)/rules.mk
>  
>  PKG_NAME:=gdb
> +
> +ifeq ($(CONFIG_arc),y)
> +PKG_VERSION:=arc-2016.03-gdb
> +
> +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
> +PKG_SOURCE_URL:=https://github.com/foss-for-synopsys-dwc-arc-processors/binutils-gdb/archive/$(PKG_VERSION)
> +PKG_MD5SUM:=775caaf6385c16f20b6f53c0a2b95f79
> +GDB_DIR:=binutils-$(PKG_NAME)-$(PKG_VERSION)
> +else
>  PKG_VERSION:=7.11
> -PKG_RELEASE:=1
>  
>  PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
>  PKG_SOURCE_URL:=@GNU/gdb
>  PKG_MD5SUM:=b5c784685e1cde65ba135feea86b6d75
> +GDB_DIR:=$(PKG_NAME)-$(PKG_VERSION)
> +endif
> +
> +PKG_RELEASE:=1
> +
> +PATCH_DIR:=./patches/$(PKG_VERSION)
> +PKG_BUILD_DIR:=$(BUILD_DIR)/$(GDB_DIR)
>  
>  PKG_BUILD_PARALLEL:=1
>  PKG_INSTALL:=1
> @@ -55,7 +70,11 @@ CONFIGURE_ARGS+= \
>  	--with-system-readline \
>  	--without-expat \
>  	--without-lzma \
> -	--disable-werror
> +	--disable-werror \
> +	--disable-binutils \
> +	--disable-ld \
> +	--disable-gas \
> +	--disable-sim
>  
>  CONFIGURE_VARS+= \
>  	ac_cv_search_tgetent="$(TARGET_LDFLAGS) -lncurses -lreadline"
> diff --git a/package/devel/gdb/patches/001-gdb-pr14523-mips-signal-number.patch b/package/devel/gdb/patches/7.11/001-gdb-pr14523-mips-signal-number.patch
> similarity index 100%
> rename from package/devel/gdb/patches/001-gdb-pr14523-mips-signal-number.patch
> rename to package/devel/gdb/patches/7.11/001-gdb-pr14523-mips-signal-number.patch
> diff --git a/package/devel/gdb/patches/100-musl_fix.patch b/package/devel/gdb/patches/7.11/100-musl_fix.patch
> similarity index 100%
> rename from package/devel/gdb/patches/100-musl_fix.patch
> rename to package/devel/gdb/patches/7.11/100-musl_fix.patch
> diff --git a/package/devel/gdb/patches/arc-2016.03/100-no_extern_inline.patch b/package/devel/gdb/patches/arc-2016.03/100-no_extern_inline.patch
> new file mode 100644
> index 0000000..8c18c6e
> --- /dev/null
> +++ b/package/devel/gdb/patches/arc-2016.03/100-no_extern_inline.patch
> @@ -0,0 +1,32 @@
> +--- a/sim/common/sim-arange.c
> ++++ b/sim/common/sim-arange.c
> +@@ -280,11 +280,7 @@ sim_addr_range_delete (ADDR_RANGE *ar, a
> +   build_search_tree (ar);
> + }
> + 
> +-#endif /* DEFINE_NON_INLINE_P */
> +-
> +-#if DEFINE_INLINE_P
> +-
> +-SIM_ARANGE_INLINE int
> ++int
> + sim_addr_range_hit_p (ADDR_RANGE *ar, address_word addr)
> + {
> +   ADDR_RANGE_TREE *t = ar->range_tree;
> +@@ -301,4 +297,4 @@ sim_addr_range_hit_p (ADDR_RANGE *ar, ad
> +   return 0;
> + }
> + 
> +-#endif /* DEFINE_INLINE_P */
> ++#endif /* DEFINE_NON_INLINE_P */
> +--- a/sim/common/sim-arange.h
> ++++ b/sim/common/sim-arange.h
> +@@ -73,7 +73,7 @@ extern void sim_addr_range_delete (ADDR_
> + 
> + /* Return non-zero if ADDR is in range AR, traversing the entire tree.
> +    If no range is specified, that is defined to mean "everything".  */
> +-SIM_ARANGE_INLINE int
> ++extern int
> + sim_addr_range_hit_p (ADDR_RANGE * /*ar*/, address_word /*addr*/);
> + #define ADDR_RANGE_HIT_P(ar, addr) \
> +   ((ar)->range_tree == NULL || sim_addr_range_hit_p ((ar), (addr)))
> diff --git a/package/devel/gdb/patches/arc-2016.03/110-no_testsuite.patch b/package/devel/gdb/patches/arc-2016.03/110-no_testsuite.patch
> new file mode 100644
> index 0000000..1b284ea
> --- /dev/null
> +++ b/package/devel/gdb/patches/arc-2016.03/110-no_testsuite.patch
> @@ -0,0 +1,21 @@
> +--- a/gdb/configure
> ++++ b/gdb/configure
> +@@ -870,8 +870,7 @@ MAKEINFOFLAGS
> + YACC
> + YFLAGS
> + XMKMF'
> +-ac_subdirs_all='testsuite
> +-gdbtk
> ++ac_subdirs_all='gdbtk
> + multi-ice
> + gdbserver'
> + 
> +@@ -5610,7 +5610,7 @@ $as_echo "$with_auto_load_safe_path" >&6
> + 
> + 
> + 
> +-subdirs="$subdirs testsuite"
> ++subdirs="$subdirs"
> + 
> + 
> + # Check whether to support alternative target configurations
> diff --git a/package/devel/gdb/patches/arc-2016.03/120-fix-compile-flag-mismatch.patch b/package/devel/gdb/patches/arc-2016.03/120-fix-compile-flag-mismatch.patch
> new file mode 100644
> index 0000000..c8b41f2
> --- /dev/null
> +++ b/package/devel/gdb/patches/arc-2016.03/120-fix-compile-flag-mismatch.patch
> @@ -0,0 +1,11 @@
> +--- a/gdb/gdbserver/configure
> ++++ b/gdb/gdbserver/configure
> +@@ -2468,7 +2468,7 @@ $as_echo "$as_me: error: \`$ac_var' was
> +       ac_cache_corrupted=: ;;
> +     ,);;
> +     *)
> +-      if test "x$ac_old_val" != "x$ac_new_val"; then
> ++      if test "`echo x$ac_old_val`" != "`echo x$ac_new_val`"; then
> + 	# differences in whitespace do not lead to failure.
> + 	ac_old_val_w=`echo x $ac_old_val`
> + 	ac_new_val_w=`echo x $ac_new_val`
> diff --git a/package/devel/gdb/patches/arc-2016.03/200-arc-fix-target-mask.patch b/package/devel/gdb/patches/arc-2016.03/200-arc-fix-target-mask.patch
> new file mode 100644
> index 0000000..7e51d58
> --- /dev/null
> +++ b/package/devel/gdb/patches/arc-2016.03/200-arc-fix-target-mask.patch
> @@ -0,0 +1,13 @@
> +diff --git a/bfd/config.bfd b/bfd/config.bfd
> +index 5145d4a..a9c9c99 100644
> +--- a/bfd/config.bfd
> ++++ b/bfd/config.bfd
> +@@ -275,7 +275,7 @@ case "${targ}" in
> +     targ_defvec=am33_elf32_linux_vec
> +     ;;
> + 
> +-  arc*-*-elf* | arc*-*-linux-uclibc*)
> ++  arc*-*-elf* | arc*-*-linux-*)
> +     targ_defvec=arc_elf32_le_vec
> +     targ_selvecs=arc_elf32_be_vec
> +     ;;
> 


From john at phrozen.org  Fri Jun  3 02:13:11 2016
From: john at phrozen.org (John Crispin)
Date: Fri, 3 Jun 2016 11:13:11 +0200
Subject: [LEDE-DEV] git.openwrt.org site half broken
In-Reply-To: <CAOdf3grR_GG1st2yUx=DrKVS0WBc037g0D5+vRu9O1vwdaqKYQ@mail.gmail.com>
References: <CAOdf3grR_GG1st2yUx=DrKVS0WBc037g0D5+vRu9O1vwdaqKYQ@mail.gmail.com>
Message-ID: <4ca6857a-1fb4-e32a-dac2-3b4becf574c1@phrozen.org>



On 02/06/2016 13:20, Etienne Champetier wrote:
> Hi,
> 
> someone messed with git.openwrt.org nginx config, i can't get the js and css.
> 
> see https://git.openwrt.org/project/static/gitweb.css (doesn't look
> like a css :) )
> 
> Cheers
> Etienne
> 

that url looks weird.
-> https://git.openwrt.org/static/gitweb.css
works and for me the service seems to be functional.

	John


> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 


From john at phrozen.org  Fri Jun  3 02:17:15 2016
From: john at phrozen.org (John Crispin)
Date: Fri, 3 Jun 2016 11:17:15 +0200
Subject: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.
In-Reply-To: <574F2791.3020500@candelatech.com>
References: <1464307053-20531-1-git-send-email-greearb@candelatech.com>
 <1464307053-20531-2-git-send-email-greearb@candelatech.com>
 <f599b26c-5b9c-f527-ef35-fa75997e2c9c@phrozen.org>
 <574F2791.3020500@candelatech.com>
Message-ID: <cd40c3e7-eae6-8b3a-86cc-4254b0d43a1e@phrozen.org>



On 01/06/2016 20:21, Ben Greear wrote:
> On 06/01/2016 11:07 AM, John Crispin wrote:
>> Hi Ben,
>>
>> also inclined to reject this one. it will open up the pandoras box and
>> we will end up maintaining piles of diffconfig files. it would make
>> morse sense to document what the script does inside web.git as a "how to
>> build" or "getting started" page
> 
> I do not have much history with LEDE/WRT, but is the diffconfig output
> really that fragile?
> 
> I will be willing to maintain the x86-64 and probably Ventana
> diffconfigs, and even if it totally fails, you have not lost
> any functionality since the main infrastructure is unchanged.

for how long and will all the other people submitting these files also
provide LTS ? normally activism fades after a few months. we can see
this will board support and package maintenance. i think this will be a
burden.

adding a "how to build" page to web.git is a good idea and we can
consider to put all the diffconfig files some place. but i think that
source.git is not the right place.

	John


> 
> I think I could further improve the buildme.sh to automatically
> pull in the feeds based on the packages in the diffconfig too,
> which should further automate building and make the buildme.sh
> more generic for different platforms.
> 
> For jow's idea, putting it in a web page may be better than nothing,
> but then it just means anyone wanting to use this type of thing
> has more work to do, and for newbies, that can be all the difference
> between success and failure.
> 
> I still think you should consider letting this patch in.  I can
> re-do it based on removing the 1/2 patch, so the diffconfig gets
> bigger, but we can still build usable apu2 images out of the box.
> 
> Either way, thanks for considering the patch.
> 
> Thanks,
> Ben
> 


From noltari at gmail.com  Fri Jun  3 02:27:05 2016
From: noltari at gmail.com (=?UTF-8?Q?=c3=81lvaro_Fern=c3=a1ndez_Rojas?=)
Date: Fri, 3 Jun 2016 11:27:05 +0200
Subject: [LEDE-DEV] [PATCHv4 1/1] [brcm63xx] Fix the logged CPU variant
In-Reply-To: <1463957186-8417-1-git-send-email-xotic750@gmail.com>
References: <1463957186-8417-1-git-send-email-xotic750@gmail.com>
Message-ID: <57514D69.7080009@gmail.com>

NACK, this doesn't add any funcionality and original firmwares show 
these SoCs as their generic CPU IDs (e.g: 6368 for the 6369).

El 23/5/16 a las 0:46, Xotic750 escribi?:
> From: Graham Fairweather <xotic750 at gmail.com>
>
> This patch fixes the logged detected CPU ID when an equivalent is used,
> like in the case where we have a bcm6369 and configuration for a
> bcm6368 is used.
> So, it will display 'Detected Broadcom 0x6369 CPU revision b2' instead of
> 'Detected Broadcom 0x6368 CPU revision b2'.
> More info can be found at:
> https://forum.openwrt.org/viewtopic.php?id=64621
> https://github.com/Xotic750/mirror-lede/tree/fix_cpu_id
> Signed-off-by: Graham Fairweather <xotic750 at gmail.com>
> ---
>   .../330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch          | 9 +++++++++
>   .../330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch          | 9 +++++++++
>   2 files changed, 18 insertions(+)
>
> diff --git a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
> index 661abf6..23491aa 100644
> --- a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
> +++ b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
> @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant helper
>    	bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT;
>    
>    	switch (bcm63xx_cpu_id) {
> +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void)
> + 	bcm63xx_memory_size = detect_memory_size();
> +
> + 	printk(KERN_INFO "Detected Broadcom 0x%04x CPU revision %02x\n",
> +-	       bcm63xx_cpu_id, bcm63xx_cpu_rev);
> ++	       bcm63xx_cpu_variant, bcm63xx_cpu_rev);
> + 	printk(KERN_INFO "CPU frequency is %u MHz\n",
> + 	       bcm63xx_cpu_freq / 1000000);
> + 	printk(KERN_INFO "%uMB of RAM installed\n",
>   --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h
>   +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h
>   @@ -19,6 +19,7 @@
> diff --git a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
> index 661abf6..330a9e6 100644
> --- a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
> +++ b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
> @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu variant helper
>    	bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT;
>    
>    	switch (bcm63xx_cpu_id) {
> +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void)
> + 	bcm63xx_memory_size = detect_memory_size();
> +
> + 	pr_info("Detected Broadcom 0x%04x CPU revision %02x\n",
> +-		bcm63xx_cpu_id, bcm63xx_cpu_rev);
> ++		bcm63xx_cpu_variant, bcm63xx_cpu_rev);
> + 	pr_info("CPU frequency is %u MHz\n",
> + 		bcm63xx_cpu_freq / 1000000);
> + 	pr_info("%uMB of RAM installed\n",
>   --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h
>   +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h
>   @@ -19,6 +19,7 @@



From champetier.etienne at gmail.com  Fri Jun  3 02:39:07 2016
From: champetier.etienne at gmail.com (Etienne Champetier)
Date: Fri, 3 Jun 2016 11:39:07 +0200
Subject: [LEDE-DEV] git.openwrt.org site half broken
In-Reply-To: <4ca6857a-1fb4-e32a-dac2-3b4becf574c1@phrozen.org>
References: <CAOdf3grR_GG1st2yUx=DrKVS0WBc037g0D5+vRu9O1vwdaqKYQ@mail.gmail.com>
 <4ca6857a-1fb4-e32a-dac2-3b4becf574c1@phrozen.org>
Message-ID: <CAOdf3gqaTyKw1xnmq1AEP_1cQJ_WXfeXW2yjj2aBD6acxYSFGQ@mail.gmail.com>

2016-06-03 11:13 GMT+02:00 John Crispin <john at phrozen.org>:
>
>
> On 02/06/2016 13:20, Etienne Champetier wrote:
>> Hi,
>>
>> someone messed with git.openwrt.org nginx config, i can't get the js and css.
>>
>> see https://git.openwrt.org/project/static/gitweb.css (doesn't look
>> like a css :) )
>>
>> Cheers
>> Etienne
>>
>
> that url looks weird.
> -> https://git.openwrt.org/static/gitweb.css
> works and for me the service seems to be functional.

Indeed, i don't know were i found
https://git.openwrt.org/project/
right url is
https://git.openwrt.org/

>
>         John


From Alexey.Brodkin at synopsys.com  Fri Jun  3 02:58:19 2016
From: Alexey.Brodkin at synopsys.com (Alexey Brodkin)
Date: Fri, 3 Jun 2016 09:58:19 +0000
Subject: [LEDE-DEV] [PATCH] fix uClibc-ng scanf check
In-Reply-To: <20160603022328.GA24494@waldemar-brodkorb.de>
References: <20160603022328.GA24494@waldemar-brodkorb.de>
Message-ID: <1464947857.8682.3.camel@synopsys.com>

Hi Waldemar,

On Fri, 2016-06-03 at 04:23 +0200, Waldemar Brodkorb wrote:
> uClibc-ng tries to be compatible with GNU libc and defines
> __GLIBC__ and pretend to be version 2.2.
> We once changed it to 2.10, but then some hard to fix problems
> in different software packages (gcc) occured.
> It would be better if we disable the special GNU libc checks
> for uClibc-ng here. uClibc-ng implements the required scanf
> functionality.
> 
> Signed-off-by: Waldemar Brodkorb <wbx at uclibc-ng.org>
> ---
> ?configure.ac | 2 +-
> ?1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/configure.ac b/configure.ac
> index f36b18c..4661c0d 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -581,7 +581,7 @@ AC_CACHE_VAL([scanf_cv_alloc_modifier],
> ??????#include <stdio.h>
> ??????#include <unistd.h>
> ?
> -?????#ifdef __GLIBC__
> +?????#if defined(__GLIBC__) && !defined(__UCLIBC__)
> ?
> ??????#if !(__GLIBC_PREREQ(2, 7))
> ??????#error %m is not available

Even though this is a very minor and clean change I don't like this
approach. We're again implicitly assume something.

IMHO much better approach would be to include a compile test for
small source that uses scanf() with "%as"/"%ms".

That way we may remove all dependencies on either GLIBC/UCLIBC/MUSL etc.

-Alexey

From noltari at gmail.com  Fri Jun  3 03:07:20 2016
From: noltari at gmail.com (=?UTF-8?Q?=c3=81lvaro_Fern=c3=a1ndez_Rojas?=)
Date: Fri, 3 Jun 2016 12:07:20 +0200
Subject: [LEDE-DEV] [PATCHv3 1/1] [brcm63xx] Add initial support for
 EVG2000
In-Reply-To: <1463957783-9346-1-git-send-email-xotic750@gmail.com>
References: <1463957783-9346-1-git-send-email-xotic750@gmail.com>
Message-ID: <575156D8.5020602@gmail.com>

Hello Graham,

Pulled into my staging tree with some changes (whitespace fixes, cleanups...):
https://git.lede-project.org/?p=lede/noltari/staging.git;a=shortlog;h=refs/heads/brcm63xx-next

Regards,
?lvaro.

El 23/5/16 a las 0:56, Xotic750 escribi?:
> From: Graham Fairweather <xotic750 at gmail.com>
>
> This patch adds support for the Netgear EVG2000 VoIP Gateway to the
> bcm63xx targets.
> Ran 'make target/linux/refresh V=s' after update to kernel 4.4.10 from
> 4.4.8 where the initial patch was added.
> This device was not sold to the general public, but rather is/was
> provided by telcos to customers in Sweden, Australia, Singapore and
> other parts of asia.
> System-On-Chip: Broadcom BCM6369 (2 * BMIPS4350 v3.1 / 400 MHz)
> Flash size: 16 MiB
> RAM size: 64 MiB
> Wireless: BCM4322 802.11b/g/n (onboard)
> Ethernet: Broadcom BCM53115
> USB: 2 x USB 2.0
> Known issues:
>  - Unable to detect 53115 switch. This appear to be a problem with
> probing for the PHY using MDIO and results in error 5. Doesn't seem to
> be a problem with the configuration, and could use someone with
> experience to have a look at it.
>  - Uses the b43 driver as using the OpenWRT/LEDE broadcom-wl driver
> fails to load the firmware for the 4322, so 802.11n is not supported.
> The factory build uses a newer broadcom-wl driver.
>  - No support for the 2 VoIP ports (not attempted)
> More info on the device and the research can be found at:
> https://wiki.openwrt.org/toh/netgear/evg2000
> https://wikidevi.com/wiki/Netgear_EVG2000
> https://github.com/Xotic750/mirror-lede/tree/evg2000
> https://forum.openwrt.org/viewtopic.php?id=63950
> Signed-off-by: Graham Fairweather <xotic750 at gmail.com>
> ---
>  .../linux/brcm63xx/base-files/etc/board.d/01_leds  |   7 ++
>  .../brcm63xx/base-files/etc/board.d/02_network     |   1 +
>  target/linux/brcm63xx/base-files/etc/diag.sh       |   3 +
>  .../base-files/etc/uci-defaults/09_fix_crc         |   2 +-
>  target/linux/brcm63xx/base-files/lib/brcm63xx.sh   |   3 +
>  .../lib/preinit/05_init_interfaces_brcm63xx        |   1 +
>  target/linux/brcm63xx/dts/evg2000.dts              | 103 +++++++++++++++++++++
>  target/linux/brcm63xx/image/Makefile               |   2 +
>  .../brcm63xx/patches-4.1/575-board_EVG2000.patch   |  62 +++++++++++++
>  ...-m25p80-use-parsers-if-provided-in-flash-.patch |   2 +-
>  ...CES-m25p80-add-support-for-limiting-reads.patch |   4 +-
>  .../414-MTD-m25p80-allow-passing-pp_data.patch     |   2 +-
>  .../brcm63xx/patches-4.4/575-board_EVG2000.patch   |  62 +++++++++++++
>  target/linux/brcm63xx/profiles/netgear.mk          |  10 ++
>  14 files changed, 259 insertions(+), 5 deletions(-)
>  create mode 100644 target/linux/brcm63xx/dts/evg2000.dts
>  create mode 100644 target/linux/brcm63xx/patches-4.1/575-board_EVG2000.patch
>  create mode 100644 target/linux/brcm63xx/patches-4.4/575-board_EVG2000.patch
>
> diff --git a/target/linux/brcm63xx/base-files/etc/board.d/01_leds b/target/linux/brcm63xx/base-files/etc/board.d/01_leds
> index 8339254..4163214 100755
> --- a/target/linux/brcm63xx/base-files/etc/board.d/01_leds
> +++ b/target/linux/brcm63xx/base-files/etc/board.d/01_leds
> @@ -24,6 +24,13 @@ dgnd3700v1_dgnd3800b)
>  	ucidef_set_led_usbdev "usb1" "USB1" "DGND3700v1_3800B:green:usb-back" "1-1"
>  	ucidef_set_led_usbdev "usb2" "USB2" "DGND3700v1_3800B:green:usb-front" "1-2"
>  	;;
> +evg2000)
> +	ucidef_set_led_netdev "lan" "LAN" "EVG2000:green:lan" "eth0"
> +	ucidef_set_led_netdev "wan" "WAN" "EVG2000:green:wan" "eth1"
> +	ucidef_set_led_netdev "wlan0" "WIFI" "EVG2000:green:wireless" "wlan0"
> +	ucidef_set_led_usbdev "usb1" "USB1" "EVG2000:green:voip1" "1-1"
> +	ucidef_set_led_usbdev "usb2" "USB2" "EVG2000:green:voip2" "1-2"
> +	;;
>  fast2704n)
>  	ucidef_set_led_netdev "wan" "WAN" "F at ST2704N:green:inet" "eth0.2"
>  	;;
> diff --git a/target/linux/brcm63xx/base-files/etc/board.d/02_network b/target/linux/brcm63xx/base-files/etc/board.d/02_network
> index f96da08..83367c1 100755
> --- a/target/linux/brcm63xx/base-files/etc/board.d/02_network
> +++ b/target/linux/brcm63xx/base-files/etc/board.d/02_network
> @@ -11,6 +11,7 @@ board_config_update
>  case "$(brcm63xx_board_name)" in
>  
>  cvg834g |\
> +evg2000 |\
>  rta770bw |\
>  rta770w |\
>  spw303v |\
> diff --git a/target/linux/brcm63xx/base-files/etc/diag.sh b/target/linux/brcm63xx/base-files/etc/diag.sh
> index b864964..6ac2459 100644
> --- a/target/linux/brcm63xx/base-files/etc/diag.sh
> +++ b/target/linux/brcm63xx/base-files/etc/diag.sh
> @@ -70,6 +70,9 @@ set_state() {
>  	dgnd3700v1_dgnd3800b)
>  		status_led="DGND3700v1_3800B:green:power"
>  		;;
> +	evg2000)
> +		status_led="EVG2000:green:power"
> +		;;
>  	fast2504n)
>  		status_led="fast2504n:green:ok"
>  		;;
> diff --git a/target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc b/target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc
> index 70dbe2a..1201168 100644
> --- a/target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc
> +++ b/target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc
> @@ -21,6 +21,7 @@ case "$(brcm63xx_board_name)" in
>  	cpva642 |\
>  	ct-6373 |\
>  	dsl-274xb-f |\
> +	evg2000 |\
>  	hg622 |\
>  	magic |\
>  	p870hw-51a_v2 |\
> @@ -37,4 +38,3 @@ case "$(brcm63xx_board_name)" in
>  		do_fixcrc
>  		;;
>  esac
> -
> diff --git a/target/linux/brcm63xx/base-files/lib/brcm63xx.sh b/target/linux/brcm63xx/base-files/lib/brcm63xx.sh
> index a2d6519..9cc0b2b 100755
> --- a/target/linux/brcm63xx/base-files/lib/brcm63xx.sh
> +++ b/target/linux/brcm63xx/base-files/lib/brcm63xx.sh
> @@ -183,6 +183,9 @@ brcm63xx_dt_detect() {
>  	"Netgear DGND3700v1/DGND3800B")
>  		board_name="dgnd3700v1_dgnd3800b"
>  		;;
> +	"Netgear EVG2000")
> +		board_name="evg2000"
> +		;;
>  	"NuCom R5010UN v2")
>  		board_name="r5010un_v2"
>  		;;
> diff --git a/target/linux/brcm63xx/base-files/lib/preinit/05_init_interfaces_brcm63xx b/target/linux/brcm63xx/base-files/lib/preinit/05_init_interfaces_brcm63xx
> index 7e4dfcb..1e3fc14 100644
> --- a/target/linux/brcm63xx/base-files/lib/preinit/05_init_interfaces_brcm63xx
> +++ b/target/linux/brcm63xx/base-files/lib/preinit/05_init_interfaces_brcm63xx
> @@ -18,6 +18,7 @@ set_preinit_iface() {
>  	dsl-274xb-c |\
>  	dsl-274xb-f |\
>  	dsl-275xb-d |\
> +	evg2000 |\
>  	fast2504n |\
>  	fast2704v2 |\
>  	hg553 |\
> diff --git a/target/linux/brcm63xx/dts/evg2000.dts b/target/linux/brcm63xx/dts/evg2000.dts
> new file mode 100644
> index 0000000..04f7b84
> --- /dev/null
> +++ b/target/linux/brcm63xx/dts/evg2000.dts
> @@ -0,0 +1,103 @@
> +/dts-v1/;
> +
> +#include "bcm6368.dtsi"
> +
> +#include <dt-bindings/input/input.h>
> +
> +/ {
> +	model = "Netgear EVG2000";
> +	compatible = "netgear,evg2000", "brcm,bcm6368";
> +
> +	gpio-keys-polled {
> +		compatible = "gpio-keys-polled";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		poll-interval = <20>;
> +		debounce-interval = <60>;
> +
> +		reset {
> +			label = "reset";
> +			gpios = <&gpio0 25 1>;
> +			linux,code = <KEY_RESTART>;
> +		};
> +		wps {
> +			label = "wps";
> +			gpios = <&gpio0 26 1>;
> +			linux,code = <KEY_WPS_BUTTON>;
> +		};
> +	};
> +
> +	gpio-leds {
> +		compatible = "gpio-leds";
> +
> +		voip1_green {
> +			label = "EVG2000:green:voip1";
> +			gpios = <&gpio0 14 1>;
> +		};
> +		voip2_green {
> +			label = "EVG2000:green:voip2";
> +			gpios = <&gpio0 2 1>;
> +		};
> +		inet_red {
> +			label = "EVG2000:red:inet";
> +			gpios = <&gpio0 4 1>;
> +		};
> +		inet_green {
> +			label = "EVG2000:green:inet";
> +			gpios = <&gpio0 5 1>;
> +		};
> +		usb_green {
> +			label = "EVG2000:green:usb";
> +			gpios = <&gpio0 15 1>;
> +		};
> +		power_green {
> +			label = "EVG2000:green:power";
> +			gpios = <&gpio0 22 1>;
> +			default-state = "on";
> +		};
> +		power_red {
> +			label = "EVG2000:red:power";
> +			gpios = <&gpio0 23 1>;
> +		};
> +		lan_green {
> +			label = "EVG2000:green:lan";
> +			gpios = <&gpio0 24 1>;
> +		};
> +		wireless_green {
> +			label = "EVG2000:green:wireless";
> +			gpios = <&gpio0 26 1>;
> +		};
> +		wan_green {
> +			label = "EVG2000:green:wan";
> +			gpios = <&gpio0 27 1>;
> +		};
> +	};
> +};
> +
> +&pflash {
> +	status = "ok";
> +
> +	linux,part-probe = "bcm63xxpart";
> +
> +	cfe at 0 {
> +			label = "CFE";
> +			reg = <0x00000000 0x00020000>;
> +			read-only;
> +	};
> +
> +	linux at 20000 {
> +			label = "linux";
> +			reg = <0x00020000 0x00f40000>;
> +	};
> +
> +	board_data at f60000 {
> +			label = "board_data";
> +			reg = <0x00f60000 0x00080000>;
> +			read-only;
> +	};
> +
> +	nvram at fe0000 {
> +			label = "nvram";
> +			reg = <0x00fe0000 0x00020000>;
> +	};
> +};
> diff --git a/target/linux/brcm63xx/image/Makefile b/target/linux/brcm63xx/image/Makefile
> index e00b6fb..f1fb86b 100644
> --- a/target/linux/brcm63xx/image/Makefile
> +++ b/target/linux/brcm63xx/image/Makefile
> @@ -593,6 +593,8 @@ $(eval $(call bcm63xxCfeRamdisk,DG834GV4,DG834GTv4,dg834g_v4,96348W3,6348))
>  $(eval $(call bcm63xxCfeNetgear,DGND3700v1_3800B,DGND3700v1,dgnd3700v1,96368MVWG,6368,--image-offset 0x20000 --block-size 0x20000,U12L144T01_NETGEAR_NEWLED,1))
>  # Netgear DGND3800B
>  $(eval $(call bcm63xxCfeNetgear,DGND3700v1_3800B,DGND3800B,dgnd3700v1,96368MVWG,6368,--image-offset 0x20000 --block-size 0x20000,U12L144T11_NETGEAR_NEWLED,1))
> +# Netgear EVG2000
> +$(eval $(call bcm63xxCfeNetgear,EVG2000,EVG2000,evg2000,96369PVG,6369,--image-offset 0x20000 --block-size 0x20000,U12H154T90_NETGEAR,1))
>  # NuCom R5010UNv2
>  $(eval $(call bcm63xxCfe,R5010UNV2,R5010UNv2,r5010unv2,96328ang,6328,--pad 8))
>  # Pirelli Alice Gate VoIP 2 Plus Wi-Fi AGPF-S0
> diff --git a/target/linux/brcm63xx/patches-4.1/575-board_EVG2000.patch b/target/linux/brcm63xx/patches-4.1/575-board_EVG2000.patch
> new file mode 100644
> index 0000000..9339085
> --- /dev/null
> +++ b/target/linux/brcm63xx/patches-4.1/575-board_EVG2000.patch
> @@ -0,0 +1,62 @@
> +--- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
> ++++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c
> +@@ -2010,6 +2010,43 @@ static struct board_info __initdata boar
> + 	.num_spis = ARRAY_SIZE(DGND3700v1_3800B_spi_devices),
> + };
> + 
> ++static struct sprom_fixup __initdata EVG2000_fixups[] = {
> ++  { .offset = 219, .value = 0xec08 },
> ++};
> ++
> ++static struct board_info __initdata board_EVG2000 = {
> ++	.name				= "96369PVG",
> ++	.expected_cpu_id		= 0x6368,
> ++
> ++	.has_uart0			= 1,
> ++	.has_pci			= 1,
> ++	.has_ohci0			= 1,
> ++	.has_ehci0			= 1,
> ++	.num_usbh_ports			= 2,
> ++
> ++	.has_enetsw			= 1,
> ++	.enetsw = {
> ++		.used_ports = {
> ++			[5] = {
> ++				.used  = 1,
> ++				.phy_id  = 0xff,
> ++				.bypass_link = 1,
> ++				.force_speed = 1000,
> ++				.force_duplex_full = 1,
> ++				.name  = "RGMII",
> ++			},
> ++		},
> ++	},
> ++	.use_fallback_sprom     = 1,
> ++	.fallback_sprom = {
> ++			.type               = SPROM_BCM4322,
> ++			.pci_bus            = 0,
> ++			.pci_dev            = 1,
> ++			.board_fixups			= EVG2000_fixups,
> ++			.num_board_fixups		= ARRAY_SIZE(EVG2000_fixups),
> ++	},
> ++};
> ++
> + static struct board_info __initdata board_HG655b = {
> + 	.name				= "HW65x",
> + 	.expected_cpu_id		= 0x6368,
> +@@ -2610,6 +2647,7 @@ static const struct board_info __initcon
> + 	&board_96368mvwg,
> + 	&board_96368mvngr,
> + 	&board_DGND3700v1_3800B,
> ++	&board_EVG2000,
> + 	&board_HG622,
> + 	&board_HG655b,
> + 	&board_P870HW51A_V2,
> +@@ -2722,6 +2760,7 @@ static struct of_device_id const bcm963x
> + 	{ .compatible = "huawei,hg622", .data = &board_HG622, },
> + 	{ .compatible = "huawei,hg655b", .data = &board_HG655b, },
> + 	{ .compatible = "netgear,dgnd3700v1", .data = &board_DGND3700v1_3800B, },
> ++	{ .compatible = "netgear,evg2000", .data = &board_EVG2000, },
> + 	{ .compatible = "zyxel,p870hw-51a-v2", .data = &board_P870HW51A_V2, },
> + #endif
> + #ifdef CONFIG_BCM63XX_CPU_63268
> diff --git a/target/linux/brcm63xx/patches-4.4/202-MTD-DEVICES-m25p80-use-parsers-if-provided-in-flash-.patch b/target/linux/brcm63xx/patches-4.4/202-MTD-DEVICES-m25p80-use-parsers-if-provided-in-flash-.patch
> index be62e67..4793836 100644
> --- a/target/linux/brcm63xx/patches-4.4/202-MTD-DEVICES-m25p80-use-parsers-if-provided-in-flash-.patch
> +++ b/target/linux/brcm63xx/patches-4.4/202-MTD-DEVICES-m25p80-use-parsers-if-provided-in-flash-.patch
> @@ -11,7 +11,7 @@ Signed-off-by: Jonas Gorski <jonas.gorski at gmail.com>
>  
>  --- a/drivers/mtd/devices/m25p80.c
>  +++ b/drivers/mtd/devices/m25p80.c
> -@@ -229,7 +229,8 @@ static int m25p_probe(struct spi_device
> +@@ -251,7 +251,8 @@ static int m25p_probe(struct spi_device
>   
>   	ppdata.of_node = spi->dev.of_node;
>   
> diff --git a/target/linux/brcm63xx/patches-4.4/203-MTD-DEVICES-m25p80-add-support-for-limiting-reads.patch b/target/linux/brcm63xx/patches-4.4/203-MTD-DEVICES-m25p80-add-support-for-limiting-reads.patch
> index 3877442..75a874d 100644
> --- a/target/linux/brcm63xx/patches-4.4/203-MTD-DEVICES-m25p80-add-support-for-limiting-reads.patch
> +++ b/target/linux/brcm63xx/patches-4.4/203-MTD-DEVICES-m25p80-add-support-for-limiting-reads.patch
> @@ -28,7 +28,7 @@ Signed-off-by: Jonas Gorski <jonas.gorski at gmail.com>
>   			size_t *retlen, u_char *buf)
>   {
>   	struct m25p *flash = nor->priv;
> -@@ -152,6 +153,29 @@ static int m25p80_read(struct spi_nor *n
> +@@ -174,6 +175,29 @@ static int m25p80_read(struct spi_nor *n
>   	return 0;
>   }
>   
> @@ -58,7 +58,7 @@ Signed-off-by: Jonas Gorski <jonas.gorski at gmail.com>
>   static int m25p80_erase(struct spi_nor *nor, loff_t offset)
>   {
>   	struct m25p *flash = nor->priv;
> -@@ -223,6 +247,9 @@ static int m25p_probe(struct spi_device
> +@@ -245,6 +269,9 @@ static int m25p_probe(struct spi_device
>   	else
>   		flash_name = spi->modalias;
>   
> diff --git a/target/linux/brcm63xx/patches-4.4/414-MTD-m25p80-allow-passing-pp_data.patch b/target/linux/brcm63xx/patches-4.4/414-MTD-m25p80-allow-passing-pp_data.patch
> index e421e9a..bbb565e 100644
> --- a/target/linux/brcm63xx/patches-4.4/414-MTD-m25p80-allow-passing-pp_data.patch
> +++ b/target/linux/brcm63xx/patches-4.4/414-MTD-m25p80-allow-passing-pp_data.patch
> @@ -10,7 +10,7 @@ Subject: [PATCH 64/79] MTD: m25p80: allow passing pp_data
>  
>  --- a/drivers/mtd/devices/m25p80.c
>  +++ b/drivers/mtd/devices/m25p80.c
> -@@ -250,6 +250,9 @@ static int m25p_probe(struct spi_device
> +@@ -272,6 +272,9 @@ static int m25p_probe(struct spi_device
>   	if (data)
>   		flash->max_transfer_len = data->max_transfer_len;
>   
> diff --git a/target/linux/brcm63xx/patches-4.4/575-board_EVG2000.patch b/target/linux/brcm63xx/patches-4.4/575-board_EVG2000.patch
> new file mode 100644
> index 0000000..fc7afc7
> --- /dev/null
> +++ b/target/linux/brcm63xx/patches-4.4/575-board_EVG2000.patch
> @@ -0,0 +1,62 @@
> +--- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
> ++++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c
> +@@ -2011,6 +2011,43 @@ static struct board_info __initdata boar
> + 	.num_spis = ARRAY_SIZE(DGND3700v1_3800B_spi_devices),
> + };
> + 
> ++static struct sprom_fixup __initdata EVG2000_fixups[] = {
> ++  { .offset = 219, .value = 0xec08 },
> ++};
> ++
> ++static struct board_info __initdata board_EVG2000 = {
> ++	.name				= "96369PVG",
> ++	.expected_cpu_id		= 0x6368,
> ++
> ++	.has_uart0			= 1,
> ++	.has_pci			= 1,
> ++	.has_ohci0			= 1,
> ++	.has_ehci0			= 1,
> ++	.num_usbh_ports			= 2,
> ++
> ++	.has_enetsw			= 1,
> ++	.enetsw = {
> ++		.used_ports = {
> ++			[5] = {
> ++				.used  = 1,
> ++				.phy_id  = 0xff,
> ++				.bypass_link = 1,
> ++				.force_speed = 1000,
> ++				.force_duplex_full = 1,
> ++				.name  = "RGMII",
> ++			},
> ++		},
> ++	},
> ++	.use_fallback_sprom     = 1,
> ++	.fallback_sprom = {
> ++			.type               = SPROM_BCM4322,
> ++			.pci_bus            = 0,
> ++			.pci_dev            = 1,
> ++			.board_fixups			= EVG2000_fixups,
> ++			.num_board_fixups		= ARRAY_SIZE(EVG2000_fixups),
> ++	},
> ++};
> ++
> + static struct board_info __initdata board_HG655b = {
> + 	.name				= "HW65x",
> + 	.expected_cpu_id		= 0x6368,
> +@@ -2611,6 +2648,7 @@ static const struct board_info __initcon
> + 	&board_96368mvwg,
> + 	&board_96368mvngr,
> + 	&board_DGND3700v1_3800B,
> ++	&board_EVG2000,
> + 	&board_HG622,
> + 	&board_HG655b,
> + 	&board_P870HW51A_V2,
> +@@ -2723,6 +2761,7 @@ static struct of_device_id const bcm963x
> + 	{ .compatible = "huawei,hg622", .data = &board_HG622, },
> + 	{ .compatible = "huawei,hg655b", .data = &board_HG655b, },
> + 	{ .compatible = "netgear,dgnd3700v1", .data = &board_DGND3700v1_3800B, },
> ++	{ .compatible = "netgear,evg2000", .data = &board_EVG2000, },
> + 	{ .compatible = "zyxel,p870hw-51a-v2", .data = &board_P870HW51A_V2, },
> + #endif
> + #ifdef CONFIG_BCM63XX_CPU_63268
> diff --git a/target/linux/brcm63xx/profiles/netgear.mk b/target/linux/brcm63xx/profiles/netgear.mk
> index bc345bb..e3bc34a 100644
> --- a/target/linux/brcm63xx/profiles/netgear.mk
> +++ b/target/linux/brcm63xx/profiles/netgear.mk
> @@ -41,3 +41,13 @@ define Profile/DGND3700v1_3800B/Description
>    Package set optimized for DGND3700 v1 / DGND3800B.
>  endef
>  $(eval $(call Profile,DGND3700v1_3800B))
> +
> +define Profile/EVG2000
> +  NAME:=Netgear EVG2000
> +  PACKAGES:=kmod-b43 wpad-mini \
> +	kmod-usb2 kmod-usb-ohci kmod-ledtrig-usbdev
> +endef
> +define Profile/EVG2000/Description
> +  Package set optimized for EVG2000.
> +endef
> +$(eval $(call Profile,EVG2000))



From mschiffer at universe-factory.net  Fri Jun  3 03:11:06 2016
From: mschiffer at universe-factory.net (Matthias Schiffer)
Date: Fri, 3 Jun 2016 12:11:06 +0200
Subject: [LEDE-DEV] [PATCH libubox] blobmsg_json: add new functions
 blobmsg_format_json_value*
In-Reply-To: <e63ded11-8ba8-c0da-78ee-a5be70eca1fd@phrozen.org>
References: <dbc90f6d05a606753e2576bd6fc3569c5958885a.1464812878.git.mschiffer@universe-factory.net>
 <e63ded11-8ba8-c0da-78ee-a5be70eca1fd@phrozen.org>
Message-ID: <02fc8e5d-d737-58b0-e712-d0b9ebf58f9e@universe-factory.net>

On 06/03/2016 11:05 AM, John Crispin wrote:
> 
> 
> On 01/06/2016 22:27, Matthias Schiffer wrote:
>> The current blobmsg_format_json* functions will return invalid JSON when
>> the "list" argument is given as false (blobmsg_format_element() will
>> output the name of the blob_attr as if the value is printed as part of a
>> JSON object).
>>
>> To avoid breaking software relying on this behaviour, introduce new
>> functions which will never print the blob_attr name and thus always
>> produce valid JSON.
> 
> what software relies on this function/behaviour ? maybe we should mark
> the current implementation as deprected and drop support in time X.
> producing broken json syntax seems very fragile.
> 
> 	John

The most promiment usage is the output of `ubus list -v`, most other uses
seem to be just error messages.

I've found a number of other issues in blobmsg_json (more broken JSON
output, missing or broken allocation failure handling, ...). You can drop
this patch for now, I'll send a new version together with some other
patches next week.

Three more remarks/questions:

1) I'd like to add two more blobmsg datatypes, F32 and F64 for
single/double precision floating-point numbers, to complete the
JSON<->blobmsg mapping. I've already looked into possible platform-specific
encoding issues of floats, the only platform-specific part seems to be some
NaN encodings, which would need to be mapped to a generic NaN encoding.
(NaN is not valid JSON, so it wouldn't be important for blobmsg_json
anyways; json-c accepts NaN and +/- Infinity though).
Usecase: I'm currently implementing a configuration storage daemon as part
of my GSoC project. In particular, I think that geocoordinates would be
nice to store as floats.

2) blogmsg currently doesn't allow tables with empty keys. In JSON, the
empty string is not special and can be used as a key. I'd like to adjust
blobmsg to allow this.

3) Another thing I'm working on is a blobtree library. blobtrees are very
similar to blobmsg, but tables and arrays store just a list of pointers to
the child blobs. This allows efficient manipulation of such trees (for the
mentioned configuration storage daemon), while still making conversion from
and to blobmsg as simple as possible.

1) and 2) would allow blobmsg to store everything that json-c can (with the
caveat that json-c stores integers as int64 internally, while blobmsg_json
uses int32) - do you think these changes make sense?

Would there also be general interest in 3), so it might be integrated into
libubox?

Regards,
Matthias


> 
>>
>> Signed-off-by: Matthias Schiffer <mschiffer at universe-factory.net>
>> ---
>>  blobmsg_json.c | 49 ++++++++++++++++++++++++++++++++++++-------------
>>  blobmsg_json.h | 14 ++++++++++++++
>>  2 files changed, 50 insertions(+), 13 deletions(-)
>>
>> diff --git a/blobmsg_json.c b/blobmsg_json.c
>> index 5713948..538c816 100644
>> --- a/blobmsg_json.c
>> +++ b/blobmsg_json.c
>> @@ -207,7 +207,7 @@ static void blobmsg_format_string(struct strbuf *s, const char *str)
>>  
>>  static void blobmsg_format_json_list(struct strbuf *s, struct blob_attr *attr, int len, bool array);
>>  
>> -static void blobmsg_format_element(struct strbuf *s, struct blob_attr *attr, bool array, bool head)
>> +static void blobmsg_format_element(struct strbuf *s, struct blob_attr *attr, bool without_name, bool head)
>>  {
>>  	const char *data_str;
>>  	char buf[32];
>> @@ -217,7 +217,7 @@ static void blobmsg_format_element(struct strbuf *s, struct blob_attr *attr, boo
>>  	if (!blobmsg_check_attr(attr, false))
>>  		return;
>>  
>> -	if (!array && blobmsg_name(attr)[0]) {
>> +	if (!without_name && blobmsg_name(attr)[0]) {
>>  		blobmsg_format_string(s, blobmsg_name(attr));
>>  		blobmsg_puts(s, ": ", s->indent ? 2 : 1);
>>  	}
>> @@ -286,22 +286,26 @@ static void blobmsg_format_json_list(struct strbuf *s, struct blob_attr *attr, i
>>  	blobmsg_puts(s, (array ? "]" : "}"), 1);
>>  }
>>  
>> +static void setup_strbuf(struct strbuf *s, struct blob_attr *attr, blobmsg_json_format_t cb, void *priv, int indent) {
>> +	s->len = blob_len(attr);
>> +	s->buf = malloc(s->len);
>> +	s->pos = 0;
>> +	s->custom_format = cb;
>> +	s->priv = priv;
>> +	s->indent = false;
>> +
>> +	if (indent >= 0) {
>> +		s->indent = true;
>> +		s->indent_level = indent;
>> +	}
>> +}
>> +
>>  char *blobmsg_format_json_with_cb(struct blob_attr *attr, bool list, blobmsg_json_format_t cb, void *priv, int indent)
>>  {
>>  	struct strbuf s;
>>  	bool array;
>>  
>> -	s.len = blob_len(attr);
>> -	s.buf = malloc(s.len);
>> -	s.pos = 0;
>> -	s.custom_format = cb;
>> -	s.priv = priv;
>> -	s.indent = false;
>> -
>> -	if (indent >= 0) {
>> -		s.indent = true;
>> -		s.indent_level = indent;
>> -	}
>> +	setup_strbuf(&s, attr, cb, priv, indent);
>>  
>>  	array = blob_is_extended(attr) &&
>>  		blobmsg_type(attr) == BLOBMSG_TYPE_ARRAY;
>> @@ -321,3 +325,22 @@ char *blobmsg_format_json_with_cb(struct blob_attr *attr, bool list, blobmsg_jso
>>  
>>  	return s.buf;
>>  }
>> +
>> +char *blobmsg_format_json_value_with_cb(struct blob_attr *attr, blobmsg_json_format_t cb, void *priv, int indent)
>> +{
>> +	struct strbuf s;
>> +
>> +	setup_strbuf(&s, attr, cb, priv, indent);
>> +
>> +	blobmsg_format_element(&s, attr, true, false);
>> +
>> +	if (!s.len) {
>> +		free(s.buf);
>> +		return NULL;
>> +	}
>> +
>> +	s.buf = realloc(s.buf, s.pos + 1);
>> +	s.buf[s.pos] = 0;
>> +
>> +	return s.buf;
>> +}
>> diff --git a/blobmsg_json.h b/blobmsg_json.h
>> index cd9ed33..9dfc02d 100644
>> --- a/blobmsg_json.h
>> +++ b/blobmsg_json.h
>> @@ -42,4 +42,18 @@ static inline char *blobmsg_format_json_indent(struct blob_attr *attr, bool list
>>  	return blobmsg_format_json_with_cb(attr, list, NULL, NULL, indent);
>>  }
>>  
>> +char *blobmsg_format_json_value_with_cb(struct blob_attr *attr,
>> +					blobmsg_json_format_t cb, void *priv,
>> +					int indent);
>> +
>> +static inline char *blobmsg_format_json_value(struct blob_attr *attr)
>> +{
>> +	return blobmsg_format_json_value_with_cb(attr, NULL, NULL, -1);
>> +}
>> +
>> +static inline char *blobmsg_format_json_value_indent(struct blob_attr *attr, int indent)
>> +{
>> +	return blobmsg_format_json_value_with_cb(attr, NULL, NULL, indent);
>> +}
>> +
>>  #endif
>>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20160603/185ed164/attachment.sig>

From xotic750 at gmail.com  Fri Jun  3 03:44:34 2016
From: xotic750 at gmail.com (Graham Fairweather)
Date: Fri, 3 Jun 2016 12:44:34 +0200
Subject: [LEDE-DEV] [PATCHv4 1/1] [brcm63xx] Fix the logged CPU variant
In-Reply-To: <57514D69.7080009@gmail.com>
References: <1463957186-8417-1-git-send-email-xotic750@gmail.com>
 <57514D69.7080009@gmail.com>
Message-ID: <CAD2Yd_Yp=yoqQbS7Ve=dde8AfQKjiANc7ffaJAimoAnBx7sM-A@mail.gmail.com>

Ok. No it doesn't add functionality to the code but for me it feels
just wrong to report in dmesg (the human functionality) that a device
is a Broadcom 6368 variant 2 (which doesn't exist), but thanks.

On 3 June 2016 at 11:27, ?lvaro Fern?ndez Rojas <noltari at gmail.com> wrote:
> NACK, this doesn't add any funcionality and original firmwares show these
> SoCs as their generic CPU IDs (e.g: 6368 for the 6369).
>
> El 23/5/16 a las 0:46, Xotic750 escribi?:
>
>> From: Graham Fairweather <xotic750 at gmail.com>
>>
>> This patch fixes the logged detected CPU ID when an equivalent is used,
>> like in the case where we have a bcm6369 and configuration for a
>> bcm6368 is used.
>> So, it will display 'Detected Broadcom 0x6369 CPU revision b2' instead of
>> 'Detected Broadcom 0x6368 CPU revision b2'.
>> More info can be found at:
>> https://forum.openwrt.org/viewtopic.php?id=64621
>> https://github.com/Xotic750/mirror-lede/tree/fix_cpu_id
>> Signed-off-by: Graham Fairweather <xotic750 at gmail.com>
>> ---
>>   .../330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch          | 9
>> +++++++++
>>   .../330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch          | 9
>> +++++++++
>>   2 files changed, 18 insertions(+)
>>
>> diff --git
>> a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
>> b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
>> index 661abf6..23491aa 100644
>> ---
>> a/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
>> +++
>> b/target/linux/brcm63xx/patches-4.1/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
>> @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu
>> variant helper
>>         bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT;
>>         switch (bcm63xx_cpu_id) {
>> +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void)
>> +       bcm63xx_memory_size = detect_memory_size();
>> +
>> +       printk(KERN_INFO "Detected Broadcom 0x%04x CPU revision %02x\n",
>> +-             bcm63xx_cpu_id, bcm63xx_cpu_rev);
>> ++             bcm63xx_cpu_variant, bcm63xx_cpu_rev);
>> +       printk(KERN_INFO "CPU frequency is %u MHz\n",
>> +              bcm63xx_cpu_freq / 1000000);
>> +       printk(KERN_INFO "%uMB of RAM installed\n",
>>   --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h
>>   +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h
>>   @@ -19,6 +19,7 @@
>> diff --git
>> a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
>> b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
>> index 661abf6..330a9e6 100644
>> ---
>> a/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
>> +++
>> b/target/linux/brcm63xx/patches-4.4/330-MIPS-BCM63XX-add-a-new-cpu-variant-helper.patch
>> @@ -41,6 +41,15 @@ Subject: [PATCH 40/53] MIPS: BCM63XX: add a new cpu
>> variant helper
>>         bcm63xx_cpu_rev = (tmp & REV_REVID_MASK) >> REV_REVID_SHIFT;
>>         switch (bcm63xx_cpu_id) {
>> +@@ -377,7 +387,7 @@ void __init bcm63xx_cpu_init(void)
>> +       bcm63xx_memory_size = detect_memory_size();
>> +
>> +       pr_info("Detected Broadcom 0x%04x CPU revision %02x\n",
>> +-              bcm63xx_cpu_id, bcm63xx_cpu_rev);
>> ++              bcm63xx_cpu_variant, bcm63xx_cpu_rev);
>> +       pr_info("CPU frequency is %u MHz\n",
>> +               bcm63xx_cpu_freq / 1000000);
>> +       pr_info("%uMB of RAM installed\n",
>>   --- a/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h
>>   +++ b/arch/mips/include/asm/mach-bcm63xx/bcm63xx_cpu.h
>>   @@ -19,6 +19,7 @@
>
>


From xotic750 at gmail.com  Fri Jun  3 03:45:16 2016
From: xotic750 at gmail.com (Graham Fairweather)
Date: Fri, 3 Jun 2016 12:45:16 +0200
Subject: [LEDE-DEV] [PATCHv3 1/1] [brcm63xx] Add initial support for
	EVG2000
In-Reply-To: <575156D8.5020602@gmail.com>
References: <1463957783-9346-1-git-send-email-xotic750@gmail.com>
 <575156D8.5020602@gmail.com>
Message-ID: <CAD2Yd_ZPxL_68wykFiP1zCeVjsKFuO25oSoU9Kks3M0Km8ZCBA@mail.gmail.com>

Hi and thanks.

On 3 June 2016 at 12:07, ?lvaro Fern?ndez Rojas <noltari at gmail.com> wrote:
> Hello Graham,
>
> Pulled into my staging tree with some changes (whitespace fixes, cleanups...):
> https://git.lede-project.org/?p=lede/noltari/staging.git;a=shortlog;h=refs/heads/brcm63xx-next
>
> Regards,
> ?lvaro.
>
> El 23/5/16 a las 0:56, Xotic750 escribi?:
>> From: Graham Fairweather <xotic750 at gmail.com>
>>
>> This patch adds support for the Netgear EVG2000 VoIP Gateway to the
>> bcm63xx targets.
>> Ran 'make target/linux/refresh V=s' after update to kernel 4.4.10 from
>> 4.4.8 where the initial patch was added.
>> This device was not sold to the general public, but rather is/was
>> provided by telcos to customers in Sweden, Australia, Singapore and
>> other parts of asia.
>> System-On-Chip: Broadcom BCM6369 (2 * BMIPS4350 v3.1 / 400 MHz)
>> Flash size: 16 MiB
>> RAM size: 64 MiB
>> Wireless: BCM4322 802.11b/g/n (onboard)
>> Ethernet: Broadcom BCM53115
>> USB: 2 x USB 2.0
>> Known issues:
>>  - Unable to detect 53115 switch. This appear to be a problem with
>> probing for the PHY using MDIO and results in error 5. Doesn't seem to
>> be a problem with the configuration, and could use someone with
>> experience to have a look at it.
>>  - Uses the b43 driver as using the OpenWRT/LEDE broadcom-wl driver
>> fails to load the firmware for the 4322, so 802.11n is not supported.
>> The factory build uses a newer broadcom-wl driver.
>>  - No support for the 2 VoIP ports (not attempted)
>> More info on the device and the research can be found at:
>> https://wiki.openwrt.org/toh/netgear/evg2000
>> https://wikidevi.com/wiki/Netgear_EVG2000
>> https://github.com/Xotic750/mirror-lede/tree/evg2000
>> https://forum.openwrt.org/viewtopic.php?id=63950
>> Signed-off-by: Graham Fairweather <xotic750 at gmail.com>
>> ---
>>  .../linux/brcm63xx/base-files/etc/board.d/01_leds  |   7 ++
>>  .../brcm63xx/base-files/etc/board.d/02_network     |   1 +
>>  target/linux/brcm63xx/base-files/etc/diag.sh       |   3 +
>>  .../base-files/etc/uci-defaults/09_fix_crc         |   2 +-
>>  target/linux/brcm63xx/base-files/lib/brcm63xx.sh   |   3 +
>>  .../lib/preinit/05_init_interfaces_brcm63xx        |   1 +
>>  target/linux/brcm63xx/dts/evg2000.dts              | 103 +++++++++++++++++++++
>>  target/linux/brcm63xx/image/Makefile               |   2 +
>>  .../brcm63xx/patches-4.1/575-board_EVG2000.patch   |  62 +++++++++++++
>>  ...-m25p80-use-parsers-if-provided-in-flash-.patch |   2 +-
>>  ...CES-m25p80-add-support-for-limiting-reads.patch |   4 +-
>>  .../414-MTD-m25p80-allow-passing-pp_data.patch     |   2 +-
>>  .../brcm63xx/patches-4.4/575-board_EVG2000.patch   |  62 +++++++++++++
>>  target/linux/brcm63xx/profiles/netgear.mk          |  10 ++
>>  14 files changed, 259 insertions(+), 5 deletions(-)
>>  create mode 100644 target/linux/brcm63xx/dts/evg2000.dts
>>  create mode 100644 target/linux/brcm63xx/patches-4.1/575-board_EVG2000.patch
>>  create mode 100644 target/linux/brcm63xx/patches-4.4/575-board_EVG2000.patch
>>
>> diff --git a/target/linux/brcm63xx/base-files/etc/board.d/01_leds b/target/linux/brcm63xx/base-files/etc/board.d/01_leds
>> index 8339254..4163214 100755
>> --- a/target/linux/brcm63xx/base-files/etc/board.d/01_leds
>> +++ b/target/linux/brcm63xx/base-files/etc/board.d/01_leds
>> @@ -24,6 +24,13 @@ dgnd3700v1_dgnd3800b)
>>       ucidef_set_led_usbdev "usb1" "USB1" "DGND3700v1_3800B:green:usb-back" "1-1"
>>       ucidef_set_led_usbdev "usb2" "USB2" "DGND3700v1_3800B:green:usb-front" "1-2"
>>       ;;
>> +evg2000)
>> +     ucidef_set_led_netdev "lan" "LAN" "EVG2000:green:lan" "eth0"
>> +     ucidef_set_led_netdev "wan" "WAN" "EVG2000:green:wan" "eth1"
>> +     ucidef_set_led_netdev "wlan0" "WIFI" "EVG2000:green:wireless" "wlan0"
>> +     ucidef_set_led_usbdev "usb1" "USB1" "EVG2000:green:voip1" "1-1"
>> +     ucidef_set_led_usbdev "usb2" "USB2" "EVG2000:green:voip2" "1-2"
>> +     ;;
>>  fast2704n)
>>       ucidef_set_led_netdev "wan" "WAN" "F at ST2704N:green:inet" "eth0.2"
>>       ;;
>> diff --git a/target/linux/brcm63xx/base-files/etc/board.d/02_network b/target/linux/brcm63xx/base-files/etc/board.d/02_network
>> index f96da08..83367c1 100755
>> --- a/target/linux/brcm63xx/base-files/etc/board.d/02_network
>> +++ b/target/linux/brcm63xx/base-files/etc/board.d/02_network
>> @@ -11,6 +11,7 @@ board_config_update
>>  case "$(brcm63xx_board_name)" in
>>
>>  cvg834g |\
>> +evg2000 |\
>>  rta770bw |\
>>  rta770w |\
>>  spw303v |\
>> diff --git a/target/linux/brcm63xx/base-files/etc/diag.sh b/target/linux/brcm63xx/base-files/etc/diag.sh
>> index b864964..6ac2459 100644
>> --- a/target/linux/brcm63xx/base-files/etc/diag.sh
>> +++ b/target/linux/brcm63xx/base-files/etc/diag.sh
>> @@ -70,6 +70,9 @@ set_state() {
>>       dgnd3700v1_dgnd3800b)
>>               status_led="DGND3700v1_3800B:green:power"
>>               ;;
>> +     evg2000)
>> +             status_led="EVG2000:green:power"
>> +             ;;
>>       fast2504n)
>>               status_led="fast2504n:green:ok"
>>               ;;
>> diff --git a/target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc b/target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc
>> index 70dbe2a..1201168 100644
>> --- a/target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc
>> +++ b/target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc
>> @@ -21,6 +21,7 @@ case "$(brcm63xx_board_name)" in
>>       cpva642 |\
>>       ct-6373 |\
>>       dsl-274xb-f |\
>> +     evg2000 |\
>>       hg622 |\
>>       magic |\
>>       p870hw-51a_v2 |\
>> @@ -37,4 +38,3 @@ case "$(brcm63xx_board_name)" in
>>               do_fixcrc
>>               ;;
>>  esac
>> -
>> diff --git a/target/linux/brcm63xx/base-files/lib/brcm63xx.sh b/target/linux/brcm63xx/base-files/lib/brcm63xx.sh
>> index a2d6519..9cc0b2b 100755
>> --- a/target/linux/brcm63xx/base-files/lib/brcm63xx.sh
>> +++ b/target/linux/brcm63xx/base-files/lib/brcm63xx.sh
>> @@ -183,6 +183,9 @@ brcm63xx_dt_detect() {
>>       "Netgear DGND3700v1/DGND3800B")
>>               board_name="dgnd3700v1_dgnd3800b"
>>               ;;
>> +     "Netgear EVG2000")
>> +             board_name="evg2000"
>> +             ;;
>>       "NuCom R5010UN v2")
>>               board_name="r5010un_v2"
>>               ;;
>> diff --git a/target/linux/brcm63xx/base-files/lib/preinit/05_init_interfaces_brcm63xx b/target/linux/brcm63xx/base-files/lib/preinit/05_init_interfaces_brcm63xx
>> index 7e4dfcb..1e3fc14 100644
>> --- a/target/linux/brcm63xx/base-files/lib/preinit/05_init_interfaces_brcm63xx
>> +++ b/target/linux/brcm63xx/base-files/lib/preinit/05_init_interfaces_brcm63xx
>> @@ -18,6 +18,7 @@ set_preinit_iface() {
>>       dsl-274xb-c |\
>>       dsl-274xb-f |\
>>       dsl-275xb-d |\
>> +     evg2000 |\
>>       fast2504n |\
>>       fast2704v2 |\
>>       hg553 |\
>> diff --git a/target/linux/brcm63xx/dts/evg2000.dts b/target/linux/brcm63xx/dts/evg2000.dts
>> new file mode 100644
>> index 0000000..04f7b84
>> --- /dev/null
>> +++ b/target/linux/brcm63xx/dts/evg2000.dts
>> @@ -0,0 +1,103 @@
>> +/dts-v1/;
>> +
>> +#include "bcm6368.dtsi"
>> +
>> +#include <dt-bindings/input/input.h>
>> +
>> +/ {
>> +     model = "Netgear EVG2000";
>> +     compatible = "netgear,evg2000", "brcm,bcm6368";
>> +
>> +     gpio-keys-polled {
>> +             compatible = "gpio-keys-polled";
>> +             #address-cells = <1>;
>> +             #size-cells = <0>;
>> +             poll-interval = <20>;
>> +             debounce-interval = <60>;
>> +
>> +             reset {
>> +                     label = "reset";
>> +                     gpios = <&gpio0 25 1>;
>> +                     linux,code = <KEY_RESTART>;
>> +             };
>> +             wps {
>> +                     label = "wps";
>> +                     gpios = <&gpio0 26 1>;
>> +                     linux,code = <KEY_WPS_BUTTON>;
>> +             };
>> +     };
>> +
>> +     gpio-leds {
>> +             compatible = "gpio-leds";
>> +
>> +             voip1_green {
>> +                     label = "EVG2000:green:voip1";
>> +                     gpios = <&gpio0 14 1>;
>> +             };
>> +             voip2_green {
>> +                     label = "EVG2000:green:voip2";
>> +                     gpios = <&gpio0 2 1>;
>> +             };
>> +             inet_red {
>> +                     label = "EVG2000:red:inet";
>> +                     gpios = <&gpio0 4 1>;
>> +             };
>> +             inet_green {
>> +                     label = "EVG2000:green:inet";
>> +                     gpios = <&gpio0 5 1>;
>> +             };
>> +             usb_green {
>> +                     label = "EVG2000:green:usb";
>> +                     gpios = <&gpio0 15 1>;
>> +             };
>> +             power_green {
>> +                     label = "EVG2000:green:power";
>> +                     gpios = <&gpio0 22 1>;
>> +                     default-state = "on";
>> +             };
>> +             power_red {
>> +                     label = "EVG2000:red:power";
>> +                     gpios = <&gpio0 23 1>;
>> +             };
>> +             lan_green {
>> +                     label = "EVG2000:green:lan";
>> +                     gpios = <&gpio0 24 1>;
>> +             };
>> +             wireless_green {
>> +                     label = "EVG2000:green:wireless";
>> +                     gpios = <&gpio0 26 1>;
>> +             };
>> +             wan_green {
>> +                     label = "EVG2000:green:wan";
>> +                     gpios = <&gpio0 27 1>;
>> +             };
>> +     };
>> +};
>> +
>> +&pflash {
>> +     status = "ok";
>> +
>> +     linux,part-probe = "bcm63xxpart";
>> +
>> +     cfe at 0 {
>> +                     label = "CFE";
>> +                     reg = <0x00000000 0x00020000>;
>> +                     read-only;
>> +     };
>> +
>> +     linux at 20000 {
>> +                     label = "linux";
>> +                     reg = <0x00020000 0x00f40000>;
>> +     };
>> +
>> +     board_data at f60000 {
>> +                     label = "board_data";
>> +                     reg = <0x00f60000 0x00080000>;
>> +                     read-only;
>> +     };
>> +
>> +     nvram at fe0000 {
>> +                     label = "nvram";
>> +                     reg = <0x00fe0000 0x00020000>;
>> +     };
>> +};
>> diff --git a/target/linux/brcm63xx/image/Makefile b/target/linux/brcm63xx/image/Makefile
>> index e00b6fb..f1fb86b 100644
>> --- a/target/linux/brcm63xx/image/Makefile
>> +++ b/target/linux/brcm63xx/image/Makefile
>> @@ -593,6 +593,8 @@ $(eval $(call bcm63xxCfeRamdisk,DG834GV4,DG834GTv4,dg834g_v4,96348W3,6348))
>>  $(eval $(call bcm63xxCfeNetgear,DGND3700v1_3800B,DGND3700v1,dgnd3700v1,96368MVWG,6368,--image-offset 0x20000 --block-size 0x20000,U12L144T01_NETGEAR_NEWLED,1))
>>  # Netgear DGND3800B
>>  $(eval $(call bcm63xxCfeNetgear,DGND3700v1_3800B,DGND3800B,dgnd3700v1,96368MVWG,6368,--image-offset 0x20000 --block-size 0x20000,U12L144T11_NETGEAR_NEWLED,1))
>> +# Netgear EVG2000
>> +$(eval $(call bcm63xxCfeNetgear,EVG2000,EVG2000,evg2000,96369PVG,6369,--image-offset 0x20000 --block-size 0x20000,U12H154T90_NETGEAR,1))
>>  # NuCom R5010UNv2
>>  $(eval $(call bcm63xxCfe,R5010UNV2,R5010UNv2,r5010unv2,96328ang,6328,--pad 8))
>>  # Pirelli Alice Gate VoIP 2 Plus Wi-Fi AGPF-S0
>> diff --git a/target/linux/brcm63xx/patches-4.1/575-board_EVG2000.patch b/target/linux/brcm63xx/patches-4.1/575-board_EVG2000.patch
>> new file mode 100644
>> index 0000000..9339085
>> --- /dev/null
>> +++ b/target/linux/brcm63xx/patches-4.1/575-board_EVG2000.patch
>> @@ -0,0 +1,62 @@
>> +--- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
>> ++++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c
>> +@@ -2010,6 +2010,43 @@ static struct board_info __initdata boar
>> +     .num_spis = ARRAY_SIZE(DGND3700v1_3800B_spi_devices),
>> + };
>> +
>> ++static struct sprom_fixup __initdata EVG2000_fixups[] = {
>> ++  { .offset = 219, .value = 0xec08 },
>> ++};
>> ++
>> ++static struct board_info __initdata board_EVG2000 = {
>> ++    .name                           = "96369PVG",
>> ++    .expected_cpu_id                = 0x6368,
>> ++
>> ++    .has_uart0                      = 1,
>> ++    .has_pci                        = 1,
>> ++    .has_ohci0                      = 1,
>> ++    .has_ehci0                      = 1,
>> ++    .num_usbh_ports                 = 2,
>> ++
>> ++    .has_enetsw                     = 1,
>> ++    .enetsw = {
>> ++            .used_ports = {
>> ++                    [5] = {
>> ++                            .used  = 1,
>> ++                            .phy_id  = 0xff,
>> ++                            .bypass_link = 1,
>> ++                            .force_speed = 1000,
>> ++                            .force_duplex_full = 1,
>> ++                            .name  = "RGMII",
>> ++                    },
>> ++            },
>> ++    },
>> ++    .use_fallback_sprom     = 1,
>> ++    .fallback_sprom = {
>> ++                    .type               = SPROM_BCM4322,
>> ++                    .pci_bus            = 0,
>> ++                    .pci_dev            = 1,
>> ++                    .board_fixups                   = EVG2000_fixups,
>> ++                    .num_board_fixups               = ARRAY_SIZE(EVG2000_fixups),
>> ++    },
>> ++};
>> ++
>> + static struct board_info __initdata board_HG655b = {
>> +     .name                           = "HW65x",
>> +     .expected_cpu_id                = 0x6368,
>> +@@ -2610,6 +2647,7 @@ static const struct board_info __initcon
>> +     &board_96368mvwg,
>> +     &board_96368mvngr,
>> +     &board_DGND3700v1_3800B,
>> ++    &board_EVG2000,
>> +     &board_HG622,
>> +     &board_HG655b,
>> +     &board_P870HW51A_V2,
>> +@@ -2722,6 +2760,7 @@ static struct of_device_id const bcm963x
>> +     { .compatible = "huawei,hg622", .data = &board_HG622, },
>> +     { .compatible = "huawei,hg655b", .data = &board_HG655b, },
>> +     { .compatible = "netgear,dgnd3700v1", .data = &board_DGND3700v1_3800B, },
>> ++    { .compatible = "netgear,evg2000", .data = &board_EVG2000, },
>> +     { .compatible = "zyxel,p870hw-51a-v2", .data = &board_P870HW51A_V2, },
>> + #endif
>> + #ifdef CONFIG_BCM63XX_CPU_63268
>> diff --git a/target/linux/brcm63xx/patches-4.4/202-MTD-DEVICES-m25p80-use-parsers-if-provided-in-flash-.patch b/target/linux/brcm63xx/patches-4.4/202-MTD-DEVICES-m25p80-use-parsers-if-provided-in-flash-.patch
>> index be62e67..4793836 100644
>> --- a/target/linux/brcm63xx/patches-4.4/202-MTD-DEVICES-m25p80-use-parsers-if-provided-in-flash-.patch
>> +++ b/target/linux/brcm63xx/patches-4.4/202-MTD-DEVICES-m25p80-use-parsers-if-provided-in-flash-.patch
>> @@ -11,7 +11,7 @@ Signed-off-by: Jonas Gorski <jonas.gorski at gmail.com>
>>
>>  --- a/drivers/mtd/devices/m25p80.c
>>  +++ b/drivers/mtd/devices/m25p80.c
>> -@@ -229,7 +229,8 @@ static int m25p_probe(struct spi_device
>> +@@ -251,7 +251,8 @@ static int m25p_probe(struct spi_device
>>
>>       ppdata.of_node = spi->dev.of_node;
>>
>> diff --git a/target/linux/brcm63xx/patches-4.4/203-MTD-DEVICES-m25p80-add-support-for-limiting-reads.patch b/target/linux/brcm63xx/patches-4.4/203-MTD-DEVICES-m25p80-add-support-for-limiting-reads.patch
>> index 3877442..75a874d 100644
>> --- a/target/linux/brcm63xx/patches-4.4/203-MTD-DEVICES-m25p80-add-support-for-limiting-reads.patch
>> +++ b/target/linux/brcm63xx/patches-4.4/203-MTD-DEVICES-m25p80-add-support-for-limiting-reads.patch
>> @@ -28,7 +28,7 @@ Signed-off-by: Jonas Gorski <jonas.gorski at gmail.com>
>>                       size_t *retlen, u_char *buf)
>>   {
>>       struct m25p *flash = nor->priv;
>> -@@ -152,6 +153,29 @@ static int m25p80_read(struct spi_nor *n
>> +@@ -174,6 +175,29 @@ static int m25p80_read(struct spi_nor *n
>>       return 0;
>>   }
>>
>> @@ -58,7 +58,7 @@ Signed-off-by: Jonas Gorski <jonas.gorski at gmail.com>
>>   static int m25p80_erase(struct spi_nor *nor, loff_t offset)
>>   {
>>       struct m25p *flash = nor->priv;
>> -@@ -223,6 +247,9 @@ static int m25p_probe(struct spi_device
>> +@@ -245,6 +269,9 @@ static int m25p_probe(struct spi_device
>>       else
>>               flash_name = spi->modalias;
>>
>> diff --git a/target/linux/brcm63xx/patches-4.4/414-MTD-m25p80-allow-passing-pp_data.patch b/target/linux/brcm63xx/patches-4.4/414-MTD-m25p80-allow-passing-pp_data.patch
>> index e421e9a..bbb565e 100644
>> --- a/target/linux/brcm63xx/patches-4.4/414-MTD-m25p80-allow-passing-pp_data.patch
>> +++ b/target/linux/brcm63xx/patches-4.4/414-MTD-m25p80-allow-passing-pp_data.patch
>> @@ -10,7 +10,7 @@ Subject: [PATCH 64/79] MTD: m25p80: allow passing pp_data
>>
>>  --- a/drivers/mtd/devices/m25p80.c
>>  +++ b/drivers/mtd/devices/m25p80.c
>> -@@ -250,6 +250,9 @@ static int m25p_probe(struct spi_device
>> +@@ -272,6 +272,9 @@ static int m25p_probe(struct spi_device
>>       if (data)
>>               flash->max_transfer_len = data->max_transfer_len;
>>
>> diff --git a/target/linux/brcm63xx/patches-4.4/575-board_EVG2000.patch b/target/linux/brcm63xx/patches-4.4/575-board_EVG2000.patch
>> new file mode 100644
>> index 0000000..fc7afc7
>> --- /dev/null
>> +++ b/target/linux/brcm63xx/patches-4.4/575-board_EVG2000.patch
>> @@ -0,0 +1,62 @@
>> +--- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
>> ++++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c
>> +@@ -2011,6 +2011,43 @@ static struct board_info __initdata boar
>> +     .num_spis = ARRAY_SIZE(DGND3700v1_3800B_spi_devices),
>> + };
>> +
>> ++static struct sprom_fixup __initdata EVG2000_fixups[] = {
>> ++  { .offset = 219, .value = 0xec08 },
>> ++};
>> ++
>> ++static struct board_info __initdata board_EVG2000 = {
>> ++    .name                           = "96369PVG",
>> ++    .expected_cpu_id                = 0x6368,
>> ++
>> ++    .has_uart0                      = 1,
>> ++    .has_pci                        = 1,
>> ++    .has_ohci0                      = 1,
>> ++    .has_ehci0                      = 1,
>> ++    .num_usbh_ports                 = 2,
>> ++
>> ++    .has_enetsw                     = 1,
>> ++    .enetsw = {
>> ++            .used_ports = {
>> ++                    [5] = {
>> ++                            .used  = 1,
>> ++                            .phy_id  = 0xff,
>> ++                            .bypass_link = 1,
>> ++                            .force_speed = 1000,
>> ++                            .force_duplex_full = 1,
>> ++                            .name  = "RGMII",
>> ++                    },
>> ++            },
>> ++    },
>> ++    .use_fallback_sprom     = 1,
>> ++    .fallback_sprom = {
>> ++                    .type               = SPROM_BCM4322,
>> ++                    .pci_bus            = 0,
>> ++                    .pci_dev            = 1,
>> ++                    .board_fixups                   = EVG2000_fixups,
>> ++                    .num_board_fixups               = ARRAY_SIZE(EVG2000_fixups),
>> ++    },
>> ++};
>> ++
>> + static struct board_info __initdata board_HG655b = {
>> +     .name                           = "HW65x",
>> +     .expected_cpu_id                = 0x6368,
>> +@@ -2611,6 +2648,7 @@ static const struct board_info __initcon
>> +     &board_96368mvwg,
>> +     &board_96368mvngr,
>> +     &board_DGND3700v1_3800B,
>> ++    &board_EVG2000,
>> +     &board_HG622,
>> +     &board_HG655b,
>> +     &board_P870HW51A_V2,
>> +@@ -2723,6 +2761,7 @@ static struct of_device_id const bcm963x
>> +     { .compatible = "huawei,hg622", .data = &board_HG622, },
>> +     { .compatible = "huawei,hg655b", .data = &board_HG655b, },
>> +     { .compatible = "netgear,dgnd3700v1", .data = &board_DGND3700v1_3800B, },
>> ++    { .compatible = "netgear,evg2000", .data = &board_EVG2000, },
>> +     { .compatible = "zyxel,p870hw-51a-v2", .data = &board_P870HW51A_V2, },
>> + #endif
>> + #ifdef CONFIG_BCM63XX_CPU_63268
>> diff --git a/target/linux/brcm63xx/profiles/netgear.mk b/target/linux/brcm63xx/profiles/netgear.mk
>> index bc345bb..e3bc34a 100644
>> --- a/target/linux/brcm63xx/profiles/netgear.mk
>> +++ b/target/linux/brcm63xx/profiles/netgear.mk
>> @@ -41,3 +41,13 @@ define Profile/DGND3700v1_3800B/Description
>>    Package set optimized for DGND3700 v1 / DGND3800B.
>>  endef
>>  $(eval $(call Profile,DGND3700v1_3800B))
>> +
>> +define Profile/EVG2000
>> +  NAME:=Netgear EVG2000
>> +  PACKAGES:=kmod-b43 wpad-mini \
>> +     kmod-usb2 kmod-usb-ohci kmod-ledtrig-usbdev
>> +endef
>> +define Profile/EVG2000/Description
>> +  Package set optimized for EVG2000.
>> +endef
>> +$(eval $(call Profile,EVG2000))
>


From danutbug at gmail.com  Fri Jun  3 03:59:07 2016
From: danutbug at gmail.com (Dan Bugnar)
Date: Fri,  3 Jun 2016 13:59:07 +0300
Subject: [LEDE-DEV] [PATCH 1/3] [ubox] remove unnecessary size struct
	between messages
Message-ID: <1464951549-4152-1-git-send-email-danutbug@gmail.com>

From: Dan Bugnar <dnbugnar at ocedo.com>

The next message needs to be written after the data of current message.
This was adding "sizeof(struct log_head)" bytes between messages.

Signed-off-by: Dan Bugnar <danutbug at gmail.com>
---
 log/syslog.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/log/syslog.c b/log/syslog.c
index e8b6774..2042e93 100644
--- a/log/syslog.c
+++ b/log/syslog.c
@@ -51,7 +51,7 @@ static regex_t pat_tstamp;
 static struct log_head*
 log_next(struct log_head *h, int size)
 {
-	struct log_head *n = (struct log_head *) &h->data[PAD(sizeof(struct log_head) + size)];
+	struct log_head *n = (struct log_head *) &h->data[size];
 
 	return (n >= log_end) ? (log) : (n);
 }
-- 
2.8.1



From danutbug at gmail.com  Fri Jun  3 03:59:08 2016
From: danutbug at gmail.com (Dan Bugnar)
Date: Fri,  3 Jun 2016 13:59:08 +0300
Subject: [LEDE-DEV] [PATCH 2/3] [ubox] syslog: change log buffer size
In-Reply-To: <1464951549-4152-1-git-send-email-danutbug@gmail.com>
References: <1464951549-4152-1-git-send-email-danutbug@gmail.com>
Message-ID: <1464951549-4152-2-git-send-email-danutbug@gmail.com>

Change the log buffer size and copy the messages.
Copy the messages from the oldest to newest using the log_list.
First time we calculate the size of the all entries. The log_entries_size
calculates the size indifferent of the positions of the newest and oldest.

If we want to increase the log buffer size is simple, we just copy from the oldest
message to the newest all the messages into the new buffer.

In case we shrink the buffer we go over messages and decrease the entries size
with the size of each message until the entries size is less or equal to the new
size we allocate the new buffer.

Signed-off-by: Dan Bugnar <danutbug at gmail.com>
---
 log/syslog.c | 36 +++++++++++++++++++++++++++---------
 log/syslog.h |  2 +-
 2 files changed, 28 insertions(+), 10 deletions(-)

diff --git a/log/syslog.c b/log/syslog.c
index 2042e93..e24c678 100644
--- a/log/syslog.c
+++ b/log/syslog.c
@@ -42,7 +42,7 @@
 #define PAD(x) (x % 4) ? (((x) - (x % 4)) + 4) : (x)
 
 static char *log_dev = LOG_DEFAULT_SOCKET;
-static int log_size = LOG_DEFAULT_SIZE;
+static int log_size = 0;
 static struct log_head *log, *log_end, *oldest, *newest;
 static int current_id = 0;
 static regex_t pat_prio;
@@ -213,6 +213,15 @@ syslog_open(void)
 	return 0;
 }
 
+static inline int 
+log_entries_size()
+{
+	if (newest > oldest)
+		return (newest - oldest);
+	else
+		return (log_end - oldest + newest - log);
+}
+
 struct log_head*
 log_list(int count, struct log_head *h)
 {
@@ -237,26 +246,38 @@ log_list(int count, struct log_head *h)
 }
 
 int
-log_buffer_init(int size)
+log_buffer_reinit(int size)
 {
+	if (size <= 0)
+		size = LOG_DEFAULT_SIZE;
+	if (log_size == size)
+		return 0;
+
 	struct log_head *_log = malloc(size);
 
 	if (!_log) {
+		oldest = newest = log = NULL;
 		fprintf(stderr, "Failed to initialize log buffer with size %d\n", log_size);
 		return -1;
 	}
 
 	memset(_log, 0, size);
 
-	if (log && ((log_size + sizeof(struct log_head)) < size)) {
+	if (log) {
 		struct log_head *start = _log;
 		struct log_head *end = ((void*) _log) + size;
 		struct log_head *l;
+		int entries_size = log_entries_size();
 
 		l = log_list(0, NULL);
 		while ((start < end) && l && l->size) {
-			memcpy(start, l, PAD(sizeof(struct log_head) + l->size));
-			start = (struct log_head *) &l->data[PAD(l->size)];
+			int copy_len = PAD(sizeof(struct log_head)) + l->size;
+			if (entries_size < size) {
+				memcpy(start, l, copy_len);
+				start = (struct log_head *) &start->data[l->size];
+			} else{
+				entries_size -= copy_len;
+			}
 			l = log_list(0, l);
 		}
 		free(log);
@@ -276,13 +297,10 @@ log_buffer_init(int size)
 void
 log_init(int _log_size)
 {
-	if (_log_size > 0)
-		log_size = _log_size;
-
 	regcomp(&pat_prio, "^<([0-9]*)>(.*)", REG_EXTENDED);
 	regcomp(&pat_tstamp, "^\[[ 0]*([0-9]*).([0-9]*)] (.*)", REG_EXTENDED);
 
-	if (log_buffer_init(log_size)) {
+	if (log_buffer_reinit(_log_size)) {
 		fprintf(stderr, "Failed to allocate log memory\n");
 		exit(-1);
 	}
diff --git a/log/syslog.h b/log/syslog.h
index 81a039f..ed5a41b 100644
--- a/log/syslog.h
+++ b/log/syslog.h
@@ -35,7 +35,7 @@ void log_shutdown(void);
 
 typedef void (*log_list_cb)(struct log_head *h);
 struct log_head* log_list(int count, struct log_head *h);
-int log_buffer_init(int size);
+int log_buffer_reinit(int size);
 void log_add(char *buf, int size, int source);
 void ubus_notify_log(struct log_head *l);
 
-- 
2.8.1



From danutbug at gmail.com  Fri Jun  3 03:59:09 2016
From: danutbug at gmail.com (Dan Bugnar)
Date: Fri,  3 Jun 2016 13:59:09 +0300
Subject: [LEDE-DEV] [PATCH 3/3] [ubox] logd: add ubus reload method
In-Reply-To: <1464951549-4152-1-git-send-email-danutbug@gmail.com>
References: <1464951549-4152-1-git-send-email-danutbug@gmail.com>
Message-ID: <1464951549-4152-3-git-send-email-danutbug@gmail.com>

Add ubus method to set the buffer size.
Example:
	ubus call log reload "{\"log_buffer_size\":size}"

Signed-off-by: Dan Bugnar <danutbug at gmail.com>
---
 log/logd.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/log/logd.c b/log/logd.c
index 27d3cac..563c545 100644
--- a/log/logd.c
+++ b/log/logd.c
@@ -26,11 +26,16 @@
 
 #include "syslog.h"
 
+#define LOG_DEFAULT_SIZE 16 * 1024
+
 int debug = 0;
 static struct blob_buf b;
 static struct ubus_auto_conn conn;
 static LIST_HEAD(clients);
 
+static const struct blobmsg_policy reload_policy =
+	{ .name = "log_buffer_size", .type = BLOBMSG_TYPE_INT32 };
+
 static const struct blobmsg_policy read_policy =
 	{ .name = "lines", .type = BLOBMSG_TYPE_INT32 };
 
@@ -124,9 +129,29 @@ write_log(struct ubus_context *ctx, struct ubus_object *obj,
 	return 0;
 }
 
+static int
+reload_log(struct ubus_context *ctx, struct ubus_object *obj,
+		struct ubus_request_data *req, const char *method,
+		struct blob_attr *msg)
+{
+	struct blob_attr *tb;
+	int size = 0;
+
+	if (msg) {
+		blobmsg_parse(&reload_policy, 1, &tb, blob_data(msg), blob_len(msg));
+		if (tb) {
+			size = blobmsg_get_u32(tb);
+			log_buffer_reinit(size < 1 ? LOG_DEFAULT_SIZE : size * 1024);
+		}
+	}
+
+	return 0;
+}
+
 static const struct ubus_method log_methods[] = {
 	{ .name = "read", .handler = read_log, .policy = &read_policy, .n_policy = 1 },
 	{ .name = "write", .handler = write_log, .policy = &write_policy, .n_policy = 1 },
+	{ .name = "reload", .handler = reload_log, .policy = &reload_policy, .n_policy = 1 },
 };
 
 static struct ubus_object_type log_object_type =
-- 
2.8.1



From champetier.etienne at gmail.com  Fri Jun  3 04:15:12 2016
From: champetier.etienne at gmail.com (Etienne Champetier)
Date: Fri, 3 Jun 2016 13:15:12 +0200
Subject: [LEDE-DEV] [PATCH] urandom-seed: add initial implementation
In-Reply-To: <ef5ec979-8a79-299e-0491-c4181e0fb0a9@phrozen.org>
References: <1464902493-25779-1-git-send-email-champetier.etienne@gmail.com>
 <ef5ec979-8a79-299e-0491-c4181e0fb0a9@phrozen.org>
Message-ID: <CAOdf3gopy8LTLOEq7JpU6Bs=ZSg1fX-7FWLM6OdXF+9-SvHTow@mail.gmail.com>

Hi John,

2016-06-03 11:00 GMT+02:00 John Crispin <john at phrozen.org>:
> Hi Etienne,
>
> comment inline ...
>
> On 02/06/2016 23:21, Etienne CHAMPETIER wrote:
>> This package:
>> 1) seed /dev/urandom with a saved seed as early as possible
>>     (using /lib/preinit/81_urandom_seed)
>> 2) save a new seed using getrandom() so we are sure /dev/urandom
>>    pool is initialized (using /etc/init.d/urandom_seed)
>>
>> seed size is 512 bytes (ie /proc/sys/kernel/random/poolsize / 8)
>> it's the same size as in ubuntu 14.04 and all systemd systems
>>
>> seed file is /etc/urandom.seed (need a writable path)
>>
>> seeding /dev/urandom doesn't change entropy estimation, so we still have
>> "random: ubus urandom read with 4 bits of entropy available"
>> messages in the logs, but we can now ignore them
>>
>> Once tested on enough configuration (jffs2/ext4/ubifs/...)
>> this package should be added to DEFAULT_PACKAGES
>>
>> We could also add an urandom.seed at build time to improve first boot
>>
>> Signed-off-by: Etienne CHAMPETIER <champetier.etienne at gmail.com>
>> ---
>>  package/utils/urandom-seed/Makefile                | 53 ++++++++++++++++++++
>>  .../urandom-seed/files/81_urandom_seed.preinit     | 15 ++++++
>>  package/utils/urandom-seed/files/getrandom.c       | 58 ++++++++++++++++++++++
>>  package/utils/urandom-seed/files/urandom_seed.init | 19 +++++++
>>  4 files changed, 145 insertions(+)
>>  create mode 100644 package/utils/urandom-seed/Makefile
>>  create mode 100644 package/utils/urandom-seed/files/81_urandom_seed.preinit
>>  create mode 100644 package/utils/urandom-seed/files/getrandom.c
>>  create mode 100644 package/utils/urandom-seed/files/urandom_seed.init
>>
>> diff --git a/package/utils/urandom-seed/Makefile b/package/utils/urandom-seed/Makefile
>> new file mode 100644
>> index 0000000..ac58bfc
>> --- /dev/null
>> +++ b/package/utils/urandom-seed/Makefile
>> @@ -0,0 +1,53 @@
>> +#
>> +# Copyright (C) 2016 Etienne CHAMPETIER <champetier.etienne at gmail.com>
>> +#
>> +# This is free software, licensed under the GNU General Public License v2.
>> +# See /LICENSE for more information.
>> +#
>> +
>> +include $(TOPDIR)/rules.mk
>> +
>> +PKG_NAME:=urandom-seed
>> +PKG_RELEASE:=1
>> +PKG_LICENSE:=GPL-2.0
>> +PKG_LICENSE_FILES:=COPYING
>> +PKG_BUILD_DIR := $(BUILD_DIR)/$(PKG_NAME)_$(PKG_RELEASE)
>> +PKG_FLAGS:=nonshared
>> +
>> +include $(INCLUDE_DIR)/package.mk
>> +
>> +define Package/urandom-seed
>> +  SECTION:=utils
>> +  CATEGORY:=Base system
>> +  TITLE:=Seed /dev/urandom on startup
>> +  MAINTAINER:=Etienne CHAMPETIER <champetier.etienne at gmail.com>
>> +endef
>> +
>> +define Package/urandom-seed/description
>> +This package takes care of loading a previously saved seed into /dev/urandom,
>> +and save a new seed from getrandom()
>> +endef
>> +
>> +define Build/Prepare
>> +     mkdir -p $(PKG_BUILD_DIR)
>> +endef
>> +
>> +define Build/Configure
>> +endef
>> +
>> +define Build/Compile
>> +     $(TARGET_CC) $(TARGET_CFLAGS) ./files/getrandom.c -o $(PKG_BUILD_DIR)/getrandom
>> +endef
>> +
>> +define Package/urandom-seed/install
>> +     $(INSTALL_DIR) $(1)/usr/bin
>> +     $(INSTALL_BIN) $(PKG_BUILD_DIR)/getrandom $(1)/usr/bin/
>> +
>> +     $(INSTALL_DIR) $(1)/lib/preinit
>> +     $(INSTALL_DATA) ./files/81_urandom_seed.preinit $(1)/lib/preinit/81_urandom_seed
>> +
>> +     $(INSTALL_DIR) $(1)/etc/init.d
>> +     $(INSTALL_BIN) ./files/urandom_seed.init $(1)/etc/init.d/urandom_seed
>> +endef
>> +
>> +$(eval $(call BuildPackage,urandom-seed))
>> diff --git a/package/utils/urandom-seed/files/81_urandom_seed.preinit b/package/utils/urandom-seed/files/81_urandom_seed.preinit
>> new file mode 100644
>> index 0000000..27ff587
>> --- /dev/null
>> +++ b/package/utils/urandom-seed/files/81_urandom_seed.preinit
>> @@ -0,0 +1,15 @@
>> +#!/bin/sh
>> +
>> +do_urandom_seed() {
>> +    S=/etc/urandom.seed
>> +    U=/dev/urandom
>> +
>> +    [ -c $U ] || { echo "Something is wrong with $U"; return; }
>> +    [ -f $S ] || { echo "Seed file not found: $S"; return; }
>> +    [ -O $S -a -G $S -a ! -x $S ] || { echo "Wrong owner / permissions for $S"; return; }
>> +
>> +    echo "Seeding $U with $S"
>> +    cat $S > $U
>> +}
>> +
>> +boot_hook_add preinit_main do_urandom_seed
>> diff --git a/package/utils/urandom-seed/files/getrandom.c b/package/utils/urandom-seed/files/getrandom.c
>> new file mode 100644
>> index 0000000..2093ef8
>> --- /dev/null
>> +++ b/package/utils/urandom-seed/files/getrandom.c
>> @@ -0,0 +1,58 @@
>> +/*
>> + * Copyright (C) 2016 Etienne Champetier <champetier.etienne at gmail.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +#define _GNU_SOURCE
>> +#include <errno.h>
>> +#include <linux/random.h>
>> +#include <stdio.h>
>> +#include <stdlib.h>
>> +#include <string.h>
>> +#include <sys/syscall.h>
>> +#include <unistd.h>
>> +
>> +#define ERROR_EXIT(fmt, ...) do { \
>> +        fprintf(stderr, fmt, ## __VA_ARGS__); \
>> +        return EXIT_FAILURE; \
>> +        } while (0)
>> +
>> +int usage(char *name)
>> +{
>> +    fprintf(stderr, "Usage: %s <nb>\n", name);
>> +    fprintf(stderr, " => return <nb> bytes from getrandom()\n");
>> +    return EXIT_FAILURE;
>> +}
>> +
>> +int main(int argc, char *argv[])
>> +{
>> +    if (argc != 2)
>> +        return usage(argv[0]);
>> +
>> +    if (isatty(STDOUT_FILENO))
>> +        ERROR_EXIT("Not outputting random to a tty\n");
>> +
>> +    int nbtot = atoi(argv[1]);
>> +    if (nbtot < 1)
>> +        ERROR_EXIT("Invalid <nb> param (must be > 0)\n");
>> +
>> +    char buf[256];
>> +    int len = sizeof(buf);
>> +    while (nbtot > 0) {
>> +        if (nbtot <= sizeof(buf))
>> +            len = nbtot;
>> +        if (syscall(SYS_getrandom, buf, len, 0) == -1)
>> +            ERROR_EXIT("getrandom() failed: %s\n", strerror(errno));
>> +        if (write(STDOUT_FILENO, buf, len) != len)
>> +            ERROR_EXIT("write() failed: %s\n", strerror(errno));
>> +        nbtot -= sizeof(buf);
>> +    }
>> +}
>
> i was wondering if we really need this extra tool to do the job. i see
> you are using the new get_random syscall. i assume there is no other way
> to get that randomness from the userland using a script ? normally i
> would go for /dev/(u)random but obvioulsy that is not possible here.
>
see
https://github.com/jedisct1/libsodium/issues/374
and the link inside it
http://crypto.stackexchange.com/questions/34019/on-linux-does-dev-random-unblocking-imply-that-dev-urandom-is-seeded

apparently /dev/urandom is initialized first and then /dev/random, so
we can poll()/select() on /dev/random and when it returns it means
/dev/urandom is initialized, but is there any already available
command to poll/select a file? (also i haven't double checked these
findings)
At the end of the second link you also see that minimum read on
/dev/random is 64bits (so dd with size 1 bits will use 64bits)

getrandom() was created for multiple good reasons, has clearly defined
and safe behaviour so this is the way to go for me.
I think we can afford 4K of binary (uncompressed) for a big step up in
security :)

> if we really need this tool, i would prefer to just integrate it into
> the procd.git tree to avoid having an extra package. we would want to
> always install it anyhow.

what about ubox.git for getrandom, and base-files for the preinit and init?

if i have more time to kill i'll try to submit a getrandom like to
busybox (but no promise)

>
> rest looks good on first glance, thanks for the effort.

Your welcome, thanks for the review

>
>         John
>

Etienne

>
>
>> diff --git a/package/utils/urandom-seed/files/urandom_seed.init b/package/utils/urandom-seed/files/urandom_seed.init
>> new file mode 100644
>> index 0000000..b2aba28
>> --- /dev/null
>> +++ b/package/utils/urandom-seed/files/urandom_seed.init
>> @@ -0,0 +1,19 @@
>> +#!/bin/sh /etc/rc.common
>> +
>> +START=99
>> +
>> +SEED=/etc/urandom.seed
>> +
>> +save_seed() {
>> +    touch $SEED.tmp
>> +    chown root:root $SEED.tmp
>> +    chmod 600 $SEED.tmp
>> +    getrandom 512 > $SEED.tmp
>> +
>> +    logger "Saving urandom seed to $SEED"
>> +    mv $SEED.tmp $SEED
>> +}
>> +
>> +boot() {
>> +    save_seed
>> +}
>>


From john at phrozen.org  Fri Jun  3 04:19:07 2016
From: john at phrozen.org (John Crispin)
Date: Fri, 3 Jun 2016 13:19:07 +0200
Subject: [LEDE-DEV] [PATCH] urandom-seed: add initial implementation
In-Reply-To: <CAOdf3gopy8LTLOEq7JpU6Bs=ZSg1fX-7FWLM6OdXF+9-SvHTow@mail.gmail.com>
References: <1464902493-25779-1-git-send-email-champetier.etienne@gmail.com>
 <ef5ec979-8a79-299e-0491-c4181e0fb0a9@phrozen.org>
 <CAOdf3gopy8LTLOEq7JpU6Bs=ZSg1fX-7FWLM6OdXF+9-SvHTow@mail.gmail.com>
Message-ID: <b557a2ee-8f64-fdf3-d4f1-20eddd7dc91e@phrozen.org>



On 03/06/2016 13:15, Etienne Champetier wrote:
> Hi John,
> 
> 2016-06-03 11:00 GMT+02:00 John Crispin <john at phrozen.org>:
>> Hi Etienne,
>>
>> comment inline ...
>>
>> On 02/06/2016 23:21, Etienne CHAMPETIER wrote:
>>> This package:
>>> 1) seed /dev/urandom with a saved seed as early as possible
>>>     (using /lib/preinit/81_urandom_seed)
>>> 2) save a new seed using getrandom() so we are sure /dev/urandom
>>>    pool is initialized (using /etc/init.d/urandom_seed)
>>>
>>> seed size is 512 bytes (ie /proc/sys/kernel/random/poolsize / 8)
>>> it's the same size as in ubuntu 14.04 and all systemd systems
>>>
>>> seed file is /etc/urandom.seed (need a writable path)
>>>
>>> seeding /dev/urandom doesn't change entropy estimation, so we still have
>>> "random: ubus urandom read with 4 bits of entropy available"
>>> messages in the logs, but we can now ignore them
>>>
>>> Once tested on enough configuration (jffs2/ext4/ubifs/...)
>>> this package should be added to DEFAULT_PACKAGES
>>>
>>> We could also add an urandom.seed at build time to improve first boot
>>>
>>> Signed-off-by: Etienne CHAMPETIER <champetier.etienne at gmail.com>
>>> ---
>>>  package/utils/urandom-seed/Makefile                | 53 ++++++++++++++++++++
>>>  .../urandom-seed/files/81_urandom_seed.preinit     | 15 ++++++
>>>  package/utils/urandom-seed/files/getrandom.c       | 58 ++++++++++++++++++++++
>>>  package/utils/urandom-seed/files/urandom_seed.init | 19 +++++++
>>>  4 files changed, 145 insertions(+)
>>>  create mode 100644 package/utils/urandom-seed/Makefile
>>>  create mode 100644 package/utils/urandom-seed/files/81_urandom_seed.preinit
>>>  create mode 100644 package/utils/urandom-seed/files/getrandom.c
>>>  create mode 100644 package/utils/urandom-seed/files/urandom_seed.init
>>>
>>> diff --git a/package/utils/urandom-seed/Makefile b/package/utils/urandom-seed/Makefile
>>> new file mode 100644
>>> index 0000000..ac58bfc
>>> --- /dev/null
>>> +++ b/package/utils/urandom-seed/Makefile
>>> @@ -0,0 +1,53 @@
>>> +#
>>> +# Copyright (C) 2016 Etienne CHAMPETIER <champetier.etienne at gmail.com>
>>> +#
>>> +# This is free software, licensed under the GNU General Public License v2.
>>> +# See /LICENSE for more information.
>>> +#
>>> +
>>> +include $(TOPDIR)/rules.mk
>>> +
>>> +PKG_NAME:=urandom-seed
>>> +PKG_RELEASE:=1
>>> +PKG_LICENSE:=GPL-2.0
>>> +PKG_LICENSE_FILES:=COPYING
>>> +PKG_BUILD_DIR := $(BUILD_DIR)/$(PKG_NAME)_$(PKG_RELEASE)
>>> +PKG_FLAGS:=nonshared
>>> +
>>> +include $(INCLUDE_DIR)/package.mk
>>> +
>>> +define Package/urandom-seed
>>> +  SECTION:=utils
>>> +  CATEGORY:=Base system
>>> +  TITLE:=Seed /dev/urandom on startup
>>> +  MAINTAINER:=Etienne CHAMPETIER <champetier.etienne at gmail.com>
>>> +endef
>>> +
>>> +define Package/urandom-seed/description
>>> +This package takes care of loading a previously saved seed into /dev/urandom,
>>> +and save a new seed from getrandom()
>>> +endef
>>> +
>>> +define Build/Prepare
>>> +     mkdir -p $(PKG_BUILD_DIR)
>>> +endef
>>> +
>>> +define Build/Configure
>>> +endef
>>> +
>>> +define Build/Compile
>>> +     $(TARGET_CC) $(TARGET_CFLAGS) ./files/getrandom.c -o $(PKG_BUILD_DIR)/getrandom
>>> +endef
>>> +
>>> +define Package/urandom-seed/install
>>> +     $(INSTALL_DIR) $(1)/usr/bin
>>> +     $(INSTALL_BIN) $(PKG_BUILD_DIR)/getrandom $(1)/usr/bin/
>>> +
>>> +     $(INSTALL_DIR) $(1)/lib/preinit
>>> +     $(INSTALL_DATA) ./files/81_urandom_seed.preinit $(1)/lib/preinit/81_urandom_seed
>>> +
>>> +     $(INSTALL_DIR) $(1)/etc/init.d
>>> +     $(INSTALL_BIN) ./files/urandom_seed.init $(1)/etc/init.d/urandom_seed
>>> +endef
>>> +
>>> +$(eval $(call BuildPackage,urandom-seed))
>>> diff --git a/package/utils/urandom-seed/files/81_urandom_seed.preinit b/package/utils/urandom-seed/files/81_urandom_seed.preinit
>>> new file mode 100644
>>> index 0000000..27ff587
>>> --- /dev/null
>>> +++ b/package/utils/urandom-seed/files/81_urandom_seed.preinit
>>> @@ -0,0 +1,15 @@
>>> +#!/bin/sh
>>> +
>>> +do_urandom_seed() {
>>> +    S=/etc/urandom.seed
>>> +    U=/dev/urandom
>>> +
>>> +    [ -c $U ] || { echo "Something is wrong with $U"; return; }
>>> +    [ -f $S ] || { echo "Seed file not found: $S"; return; }
>>> +    [ -O $S -a -G $S -a ! -x $S ] || { echo "Wrong owner / permissions for $S"; return; }
>>> +
>>> +    echo "Seeding $U with $S"
>>> +    cat $S > $U
>>> +}
>>> +
>>> +boot_hook_add preinit_main do_urandom_seed
>>> diff --git a/package/utils/urandom-seed/files/getrandom.c b/package/utils/urandom-seed/files/getrandom.c
>>> new file mode 100644
>>> index 0000000..2093ef8
>>> --- /dev/null
>>> +++ b/package/utils/urandom-seed/files/getrandom.c
>>> @@ -0,0 +1,58 @@
>>> +/*
>>> + * Copyright (C) 2016 Etienne Champetier <champetier.etienne at gmail.com>
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License as published by
>>> + * the Free Software Foundation; either version 2 of the License, or
>>> + * (at your option) any later version.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>> + * GNU General Public License for more details.
>>> + */
>>> +#define _GNU_SOURCE
>>> +#include <errno.h>
>>> +#include <linux/random.h>
>>> +#include <stdio.h>
>>> +#include <stdlib.h>
>>> +#include <string.h>
>>> +#include <sys/syscall.h>
>>> +#include <unistd.h>
>>> +
>>> +#define ERROR_EXIT(fmt, ...) do { \
>>> +        fprintf(stderr, fmt, ## __VA_ARGS__); \
>>> +        return EXIT_FAILURE; \
>>> +        } while (0)
>>> +
>>> +int usage(char *name)
>>> +{
>>> +    fprintf(stderr, "Usage: %s <nb>\n", name);
>>> +    fprintf(stderr, " => return <nb> bytes from getrandom()\n");
>>> +    return EXIT_FAILURE;
>>> +}
>>> +
>>> +int main(int argc, char *argv[])
>>> +{
>>> +    if (argc != 2)
>>> +        return usage(argv[0]);
>>> +
>>> +    if (isatty(STDOUT_FILENO))
>>> +        ERROR_EXIT("Not outputting random to a tty\n");
>>> +
>>> +    int nbtot = atoi(argv[1]);
>>> +    if (nbtot < 1)
>>> +        ERROR_EXIT("Invalid <nb> param (must be > 0)\n");
>>> +
>>> +    char buf[256];
>>> +    int len = sizeof(buf);
>>> +    while (nbtot > 0) {
>>> +        if (nbtot <= sizeof(buf))
>>> +            len = nbtot;
>>> +        if (syscall(SYS_getrandom, buf, len, 0) == -1)
>>> +            ERROR_EXIT("getrandom() failed: %s\n", strerror(errno));
>>> +        if (write(STDOUT_FILENO, buf, len) != len)
>>> +            ERROR_EXIT("write() failed: %s\n", strerror(errno));
>>> +        nbtot -= sizeof(buf);
>>> +    }
>>> +}
>>
>> i was wondering if we really need this extra tool to do the job. i see
>> you are using the new get_random syscall. i assume there is no other way
>> to get that randomness from the userland using a script ? normally i
>> would go for /dev/(u)random but obvioulsy that is not possible here.
>>
> see
> https://github.com/jedisct1/libsodium/issues/374
> and the link inside it
> http://crypto.stackexchange.com/questions/34019/on-linux-does-dev-random-unblocking-imply-that-dev-urandom-is-seeded
> 
> apparently /dev/urandom is initialized first and then /dev/random, so
> we can poll()/select() on /dev/random and when it returns it means
> /dev/urandom is initialized, but is there any already available
> command to poll/select a file? (also i haven't double checked these
> findings)
> At the end of the second link you also see that minimum read on
> /dev/random is 64bits (so dd with size 1 bits will use 64bits)
> 
> getrandom() was created for multiple good reasons, has clearly defined
> and safe behaviour so this is the way to go for me.
> I think we can afford 4K of binary (uncompressed) for a big step up in
> security :)

ok at rat-tail of possible problems

> 
>> if we really need this tool, i would prefer to just integrate it into
>> the procd.git tree to avoid having an extra package. we would want to
>> always install it anyhow.
> 
> what about ubox.git for getrandom, and base-files for the preinit and init?
> 

ok, ubox.git is probably more appropriate

	John


> if i have more time to kill i'll try to submit a getrandom like to
> busybox (but no promise)
> 
>>
>> rest looks good on first glance, thanks for the effort.
> 
> Your welcome, thanks for the review
> 
>>
>>         John
>>
> 
> Etienne
> 
>>
>>
>>> diff --git a/package/utils/urandom-seed/files/urandom_seed.init b/package/utils/urandom-seed/files/urandom_seed.init
>>> new file mode 100644
>>> index 0000000..b2aba28
>>> --- /dev/null
>>> +++ b/package/utils/urandom-seed/files/urandom_seed.init
>>> @@ -0,0 +1,19 @@
>>> +#!/bin/sh /etc/rc.common
>>> +
>>> +START=99
>>> +
>>> +SEED=/etc/urandom.seed
>>> +
>>> +save_seed() {
>>> +    touch $SEED.tmp
>>> +    chown root:root $SEED.tmp
>>> +    chmod 600 $SEED.tmp
>>> +    getrandom 512 > $SEED.tmp
>>> +
>>> +    logger "Saving urandom seed to $SEED"
>>> +    mv $SEED.tmp $SEED
>>> +}
>>> +
>>> +boot() {
>>> +    save_seed
>>> +}
>>>


From i at conorogorman.net  Fri Jun  3 04:27:18 2016
From: i at conorogorman.net (Conor O'Gorman)
Date: Fri, 3 Jun 2016 12:27:18 +0100
Subject: [LEDE-DEV] [PATCH 1/3] [ubox] remove unnecessary size struct
 between messages
In-Reply-To: <1464951549-4152-1-git-send-email-danutbug@gmail.com>
References: <1464951549-4152-1-git-send-email-danutbug@gmail.com>
Message-ID: <57516996.5060603@conorogorman.net>

On 03/06/16 11:59, Dan Bugnar wrote:
> From: Dan Bugnar <dnbugnar at ocedo.com>
>
> The next message needs to be written after the data of current message.
> This was adding "sizeof(struct log_head)" bytes between messages.
>
> Signed-off-by: Dan Bugnar <danutbug at gmail.com>
> ---
>   log/syslog.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/log/syslog.c b/log/syslog.c
> index e8b6774..2042e93 100644
> --- a/log/syslog.c
> +++ b/log/syslog.c
> @@ -51,7 +51,7 @@ static regex_t pat_tstamp;
>   static struct log_head*
>   log_next(struct log_head *h, int size)
>   {
> -	struct log_head *n = (struct log_head *) &h->data[PAD(sizeof(struct log_head) + size)];
> +	struct log_head *n = (struct log_head *) &h->data[size];
>
You lost the PAD? Which is over the struct and size, not just the struct.

Conor


From i at conorogorman.net  Fri Jun  3 04:41:19 2016
From: i at conorogorman.net (Conor O'Gorman)
Date: Fri, 3 Jun 2016 12:41:19 +0100
Subject: [LEDE-DEV] [PATCH 2/3] [ubox] syslog: change log buffer size
In-Reply-To: <1464951549-4152-2-git-send-email-danutbug@gmail.com>
References: <1464951549-4152-1-git-send-email-danutbug@gmail.com>
 <1464951549-4152-2-git-send-email-danutbug@gmail.com>
Message-ID: <57516CDF.2080008@conorogorman.net>

On 03/06/16 11:59, Dan Bugnar wrote:
> Change the log buffer size and copy the messages.
> Copy the messages from the oldest to newest using the log_list.
> First time we calculate the size of the all entries. The log_entries_size
> calculates the size indifferent of the positions of the newest and oldest.
>
> If we want to increase the log buffer size is simple, we just copy from the oldest
> message to the newest all the messages into the new buffer.
>
> In case we shrink the buffer we go over messages and decrease the entries size
> with the size of each message until the entries size is less or equal to the new
> size we allocate the new buffer.
>
> Signed-off-by: Dan Bugnar <danutbug at gmail.com>
> ---
>   log/syslog.c | 36 +++++++++++++++++++++++++++---------
>   log/syslog.h |  2 +-
>   2 files changed, 28 insertions(+), 10 deletions(-)
>
> diff --git a/log/syslog.c b/log/syslog.c
> index 2042e93..e24c678 100644
> --- a/log/syslog.c
> +++ b/log/syslog.c
> @@ -42,7 +42,7 @@
>   #define PAD(x) (x % 4) ? (((x) - (x % 4)) + 4) : (x)
>   
>   static char *log_dev = LOG_DEFAULT_SOCKET;
> -static int log_size = LOG_DEFAULT_SIZE;
> +static int log_size = 0;
>   static struct log_head *log, *log_end, *oldest, *newest;
>   static int current_id = 0;
>   static regex_t pat_prio;
> @@ -213,6 +213,15 @@ syslog_open(void)
>   	return 0;
>   }
>   
> +static inline int
> +log_entries_size()
> +{
> +	if (newest > oldest)
> +		return (newest - oldest);
> +	else
> +		return (log_end - oldest + newest - log);
> +}
> +
>   struct log_head*
>   log_list(int count, struct log_head *h)
>   {
> @@ -237,26 +246,38 @@ log_list(int count, struct log_head *h)
>   }
>   
>   int
> -log_buffer_init(int size)
> +log_buffer_reinit(int size)
>   {
> +	if (size <= 0)
> +		size = LOG_DEFAULT_SIZE;
> +	if (log_size == size)
> +		return 0;
> +
>   	struct log_head *_log = malloc(size);
>   
>   	if (!_log) {
> +		oldest = newest = log = NULL;
>   		fprintf(stderr, "Failed to initialize log buffer with size %d\n", log_size);
>   		return -1;
>   	}
>   
>   	memset(_log, 0, size);
>   
> -	if (log && ((log_size + sizeof(struct log_head)) < size)) {
> +	if (log) {
>   		struct log_head *start = _log;
>   		struct log_head *end = ((void*) _log) + size;
>   		struct log_head *l;
> +		int entries_size = log_entries_size();
>   
>   		l = log_list(0, NULL);
>   		while ((start < end) && l && l->size) {
> -			memcpy(start, l, PAD(sizeof(struct log_head) + l->size));
> -			start = (struct log_head *) &l->data[PAD(l->size)];
> +			int copy_len = PAD(sizeof(struct log_head)) + l->size;
And here we see PAD jump around again.

> +			if (entries_size < size) {
> +				memcpy(start, l, copy_len);
> +				start = (struct log_head *) &start->data[l->size];
> +			} else{
> +				entries_size -= copy_len;
> +			}
I find this structure unpleasent, but it appears to work.
The code should eventually run in the first block, after possibly 
skipping entries via the second block?

Still a bit worried about lengths due to the PAD issue.

>   			l = log_list(0, l);
>   		}
>   		free(log);
> @@ -276,13 +297,10 @@ log_buffer_init(int size)
>   void
>   log_init(int _log_size)
>   {
> -	if (_log_size > 0)
> -		log_size = _log_size;
> -
>   	regcomp(&pat_prio, "^<([0-9]*)>(.*)", REG_EXTENDED);
>   	regcomp(&pat_tstamp, "^\[[ 0]*([0-9]*).([0-9]*)] (.*)", REG_EXTENDED);
>   
> -	if (log_buffer_init(log_size)) {
> +	if (log_buffer_reinit(_log_size)) {
>   		fprintf(stderr, "Failed to allocate log memory\n");
>   		exit(-1);
>   	}
> diff --git a/log/syslog.h b/log/syslog.h
> index 81a039f..ed5a41b 100644
> --- a/log/syslog.h
> +++ b/log/syslog.h
> @@ -35,7 +35,7 @@ void log_shutdown(void);
>   
>   typedef void (*log_list_cb)(struct log_head *h);
>   struct log_head* log_list(int count, struct log_head *h);
> -int log_buffer_init(int size);
> +int log_buffer_reinit(int size);
>   void log_add(char *buf, int size, int source);
>   void ubus_notify_log(struct log_head *l);
>   



From john at phrozen.org  Fri Jun  3 04:48:48 2016
From: john at phrozen.org (John Crispin)
Date: Fri, 3 Jun 2016 13:48:48 +0200
Subject: [LEDE-DEV] [PATCH 2/3] [ubox] syslog: change log buffer size
In-Reply-To: <1464951549-4152-2-git-send-email-danutbug@gmail.com>
References: <1464951549-4152-1-git-send-email-danutbug@gmail.com>
 <1464951549-4152-2-git-send-email-danutbug@gmail.com>
Message-ID: <18073257-4ff6-c15b-335b-47d2d11222bf@phrozen.org>



On 03/06/2016 12:59, Dan Bugnar wrote:
> Change the log buffer size and copy the messages.
> Copy the messages from the oldest to newest using the log_list.
> First time we calculate the size of the all entries. The log_entries_size
> calculates the size indifferent of the positions of the newest and oldest.
> 
> If we want to increase the log buffer size is simple, we just copy from the oldest
> message to the newest all the messages into the new buffer.
> 
> In case we shrink the buffer we go over messages and decrease the entries size
> with the size of each message until the entries size is less or equal to the new
> size we allocate the new buffer.
> 
> Signed-off-by: Dan Bugnar <danutbug at gmail.com>
> ---
>  log/syslog.c | 36 +++++++++++++++++++++++++++---------
>  log/syslog.h |  2 +-
>  2 files changed, 28 insertions(+), 10 deletions(-)
> 
> diff --git a/log/syslog.c b/log/syslog.c
> index 2042e93..e24c678 100644
> --- a/log/syslog.c
> +++ b/log/syslog.c
> @@ -42,7 +42,7 @@
>  #define PAD(x) (x % 4) ? (((x) - (x % 4)) + 4) : (x)
>  
>  static char *log_dev = LOG_DEFAULT_SOCKET;
> -static int log_size = LOG_DEFAULT_SIZE;
> +static int log_size = 0;

static dont get defined to 0

>  static struct log_head *log, *log_end, *oldest, *newest;
>  static int current_id = 0;
>  static regex_t pat_prio;
> @@ -213,6 +213,15 @@ syslog_open(void)
>  	return 0;
>  }
>  
> +static inline int 
> +log_entries_size()

void prototype ?

> +{
> +	if (newest > oldest)
> +		return (newest - oldest);
> +	else
> +		return (log_end - oldest + newest - log);
> +}
> +
>  struct log_head*
>  log_list(int count, struct log_head *h)
>  {
> @@ -237,26 +246,38 @@ log_list(int count, struct log_head *h)
>  }
>  
>  int
> -log_buffer_init(int size)
> +log_buffer_reinit(int size)
>  {
> +	if (size <= 0)
> +		size = LOG_DEFAULT_SIZE;
> +	if (log_size == size)
> +		return 0;
> +

code before variable declarations ? did this compile without warning ?

>  	struct log_head *_log = malloc(size);
>  
>  	if (!_log) {
> +		oldest = newest = log = NULL;
>  		fprintf(stderr, "Failed to initialize log buffer with size %d\n", log_size);
>  		return -1;
>  	}
>  
>  	memset(_log, 0, size);
>  
> -	if (log && ((log_size + sizeof(struct log_head)) < size)) {
> +	if (log) {
>  		struct log_head *start = _log;
>  		struct log_head *end = ((void*) _log) + size;
>  		struct log_head *l;
> +		int entries_size = log_entries_size();
>  
>  		l = log_list(0, NULL);
>  		while ((start < end) && l && l->size) {
> -			memcpy(start, l, PAD(sizeof(struct log_head) + l->size));
> -			start = (struct log_head *) &l->data[PAD(l->size)];
> +			int copy_len = PAD(sizeof(struct log_head)) + l->size;
> +			if (entries_size < size) {
> +				memcpy(start, l, copy_len);
> +				start = (struct log_head *) &start->data[l->size];
> +			} else{
> +				entries_size -= copy_len;
> +			}
>  			l = log_list(0, l);
>  		}
>  		free(log);
> @@ -276,13 +297,10 @@ log_buffer_init(int size)
>  void
>  log_init(int _log_size)
>  {
> -	if (_log_size > 0)
> -		log_size = _log_size;

what happened to log_size ? if you dont use it anymore remove it fully
please

> -
you are removing a blank like here


>  	regcomp(&pat_prio, "^<([0-9]*)>(.*)", REG_EXTENDED);
>  	regcomp(&pat_tstamp, "^\[[ 0]*([0-9]*).([0-9]*)] (.*)", REG_EXTENDED);
>  
> -	if (log_buffer_init(log_size)) {
> +	if (log_buffer_reinit(_log_size)) {
>  		fprintf(stderr, "Failed to allocate log memory\n");
>  		exit(-1);
>  	}
> diff --git a/log/syslog.h b/log/syslog.h
> index 81a039f..ed5a41b 100644
> --- a/log/syslog.h
> +++ b/log/syslog.h
> @@ -35,7 +35,7 @@ void log_shutdown(void);
>  
>  typedef void (*log_list_cb)(struct log_head *h);
>  struct log_head* log_list(int count, struct log_head *h);
> -int log_buffer_init(int size);
> +int log_buffer_reinit(int size);
>  void log_add(char *buf, int size, int source);
>  void ubus_notify_log(struct log_head *l);
>  
> 


From edgar.soldin at web.de  Fri Jun  3 05:19:05 2016
From: edgar.soldin at web.de (edgar.soldin at web.de)
Date: Fri, 3 Jun 2016 14:19:05 +0200
Subject: [LEDE-DEV] international keyboard layout support
Message-ID: <810e5bea-5baf-4cc5-5808-9301b2487293@web.de>

hey All,

i already posted this on openwrt-devel at lists.openwrt.org , but am currently unsure what the status is for LEDE vs. OpenWrt. so here i go again on this very ml.

while tinkering with Gluon the Openwrt based Freifunk firmware (currently on CC) on a x86 based thin client box i needed support for a german keyboard layout. i managed to realize that manually as i didn't find any prepared packages for this purpose.

is there any interest in a keyboardmaps package, holding busybox compatible binary kmaps and activating the needed busybox utilities? i imagine some devs/users especially on platforms with proper keyboard interfaces (usb/ps2) would appreciate that.

thanks ..ede


From greearb at candelatech.com  Fri Jun  3 05:27:48 2016
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 03 Jun 2016 05:27:48 -0700
Subject: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.
In-Reply-To: <cd40c3e7-eae6-8b3a-86cc-4254b0d43a1e@phrozen.org>
References: <1464307053-20531-1-git-send-email-greearb@candelatech.com>
 <1464307053-20531-2-git-send-email-greearb@candelatech.com>
 <f599b26c-5b9c-f527-ef35-fa75997e2c9c@phrozen.org>
 <574F2791.3020500@candelatech.com>
 <cd40c3e7-eae6-8b3a-86cc-4254b0d43a1e@phrozen.org>
Message-ID: <575177C4.1070504@candelatech.com>



On 06/03/2016 02:17 AM, John Crispin wrote:
>
>
> On 01/06/2016 20:21, Ben Greear wrote:
>> On 06/01/2016 11:07 AM, John Crispin wrote:
>>> Hi Ben,
>>>
>>> also inclined to reject this one. it will open up the pandoras box and
>>> we will end up maintaining piles of diffconfig files. it would make
>>> morse sense to document what the script does inside web.git as a "how to
>>> build" or "getting started" page
>>
>> I do not have much history with LEDE/WRT, but is the diffconfig output
>> really that fragile?
>>
>> I will be willing to maintain the x86-64 and probably Ventana
>> diffconfigs, and even if it totally fails, you have not lost
>> any functionality since the main infrastructure is unchanged.
>
> for how long and will all the other people submitting these files also
> provide LTS ? normally activism fades after a few months. we can see
> this will board support and package maintenance. i think this will be a
> burden.

Anything that makes it more easy for others to build images
should help bring in more newbies faster, which might keep the
activism going, especially for common platforms that will
constantly be getting new hardware (like x86-64).

Currently, a newbie with an x86-64 board is going to have a slow
and frustrating time trying to get any sort of useful 'AP' built
from LEDE.  I think I can help to fix that problem if you will
let me.

So, how about you accept a small number of diffconfig recipes, and the buildme
script, and then see how that works for a while.  I can update
buildme.sh to grab a diffconfig from a URL (using curl, or something)
and then folks wanting to provide out-of-tree diffconfigs need only
put their config in a public place and tell users how to use it:

./buildme.sh -T http://my.funkyplatform.com/board1

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From i at conorogorman.net  Fri Jun  3 05:37:59 2016
From: i at conorogorman.net (Conor O'Gorman)
Date: Fri, 3 Jun 2016 13:37:59 +0100
Subject: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.
In-Reply-To: <575177C4.1070504@candelatech.com>
References: <1464307053-20531-1-git-send-email-greearb@candelatech.com>
 <1464307053-20531-2-git-send-email-greearb@candelatech.com>
 <f599b26c-5b9c-f527-ef35-fa75997e2c9c@phrozen.org>
 <574F2791.3020500@candelatech.com>
 <cd40c3e7-eae6-8b3a-86cc-4254b0d43a1e@phrozen.org>
 <575177C4.1070504@candelatech.com>
Message-ID: <57517A27.1030200@conorogorman.net>



On 03/06/16 13:27, Ben Greear wrote:
>
>
> On 06/03/2016 02:17 AM, John Crispin wrote:
>>
>>
>> On 01/06/2016 20:21, Ben Greear wrote:
>>> On 06/01/2016 11:07 AM, John Crispin wrote:
>>>> Hi Ben,
>>>>
>>>> also inclined to reject this one. it will open up the pandoras box and
>>>> we will end up maintaining piles of diffconfig files. it would make
>>>> morse sense to document what the script does inside web.git as a 
>>>> "how to
>>>> build" or "getting started" page
>>>
>>> I do not have much history with LEDE/WRT, but is the diffconfig output
>>> really that fragile?
>>>
>>> I will be willing to maintain the x86-64 and probably Ventana
>>> diffconfigs, and even if it totally fails, you have not lost
>>> any functionality since the main infrastructure is unchanged.
>>
>> for how long and will all the other people submitting these files also
>> provide LTS ? normally activism fades after a few months. we can see
>> this will board support and package maintenance. i think this will be a
>> burden.
>
> Anything that makes it more easy for others to build images
> should help bring in more newbies faster, which might keep the
> activism going, especially for common platforms that will
> constantly be getting new hardware (like x86-64).
>
> Currently, a newbie with an x86-64 board is going to have a slow
> and frustrating time trying to get any sort of useful 'AP' built
> from LEDE.  I think I can help to fix that problem if you will
> let me.
>
> So, how about you accept a small number of diffconfig recipes, and the 
> buildme
> script, and then see how that works for a while.  I can update
> buildme.sh to grab a diffconfig from a URL (using curl, or something)
> and then folks wanting to provide out-of-tree diffconfigs need only
> put their config in a public place and tell users how to use it:
>
> ./buildme.sh -T http://my.funkyplatform.com/board1
>
> Thanks,
> Ben
>
This seems to duplicate the functionality of the sub-targets and 
profiles mechanism?



From greearb at candelatech.com  Fri Jun  3 05:54:43 2016
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 03 Jun 2016 05:54:43 -0700
Subject: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.
In-Reply-To: <57517A27.1030200@conorogorman.net>
References: <1464307053-20531-1-git-send-email-greearb@candelatech.com>
 <1464307053-20531-2-git-send-email-greearb@candelatech.com>
 <f599b26c-5b9c-f527-ef35-fa75997e2c9c@phrozen.org>
 <574F2791.3020500@candelatech.com>
 <cd40c3e7-eae6-8b3a-86cc-4254b0d43a1e@phrozen.org>
 <575177C4.1070504@candelatech.com> <57517A27.1030200@conorogorman.net>
Message-ID: <57517E13.6080202@candelatech.com>



On 06/03/2016 05:37 AM, Conor O'Gorman wrote:
>
>
> On 03/06/16 13:27, Ben Greear wrote:
>>
>>
>> On 06/03/2016 02:17 AM, John Crispin wrote:
>>>
>>>
>>> On 01/06/2016 20:21, Ben Greear wrote:
>>>> On 06/01/2016 11:07 AM, John Crispin wrote:
>>>>> Hi Ben,
>>>>>
>>>>> also inclined to reject this one. it will open up the pandoras box and
>>>>> we will end up maintaining piles of diffconfig files. it would make
>>>>> morse sense to document what the script does inside web.git as a "how to
>>>>> build" or "getting started" page
>>>>
>>>> I do not have much history with LEDE/WRT, but is the diffconfig output
>>>> really that fragile?
>>>>
>>>> I will be willing to maintain the x86-64 and probably Ventana
>>>> diffconfigs, and even if it totally fails, you have not lost
>>>> any functionality since the main infrastructure is unchanged.
>>>
>>> for how long and will all the other people submitting these files also
>>> provide LTS ? normally activism fades after a few months. we can see
>>> this will board support and package maintenance. i think this will be a
>>> burden.
>>
>> Anything that makes it more easy for others to build images
>> should help bring in more newbies faster, which might keep the
>> activism going, especially for common platforms that will
>> constantly be getting new hardware (like x86-64).
>>
>> Currently, a newbie with an x86-64 board is going to have a slow
>> and frustrating time trying to get any sort of useful 'AP' built
>> from LEDE.  I think I can help to fix that problem if you will
>> let me.
>>
>> So, how about you accept a small number of diffconfig recipes, and the buildme
>> script, and then see how that works for a while.  I can update
>> buildme.sh to grab a diffconfig from a URL (using curl, or something)
>> and then folks wanting to provide out-of-tree diffconfigs need only
>> put their config in a public place and tell users how to use it:
>>
>> ./buildme.sh -T http://my.funkyplatform.com/board1
>>
>> Thanks,
>> Ben
>>
> This seems to duplicate the functionality of the sub-targets and profiles mechanism?

Maybe some of it, but for more generic platforms, I am not sure sub-targets make
sense, and in general, it is more difficult to edit those than to change a diffconfig
as far as I can tell.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From jcmvbkbc at gmail.com  Fri Jun  3 06:43:46 2016
From: jcmvbkbc at gmail.com (Max Filippov)
Date: Fri, 3 Jun 2016 16:43:46 +0300
Subject: [LEDE-DEV] [PATCH] fix uClibc-ng scanf check
In-Reply-To: <1464947857.8682.3.camel@synopsys.com>
References: <20160603022328.GA24494@waldemar-brodkorb.de>
 <1464947857.8682.3.camel@synopsys.com>
Message-ID: <CAMo8BfJYoUrALib89abi1cCT=fcLyMSkXAfGJ=LpzgnrUveJCg@mail.gmail.com>

Hi Alexey,

On Fri, Jun 3, 2016 at 12:58 PM, Alexey Brodkin
<Alexey.Brodkin at synopsys.com> wrote:
> IMHO much better approach would be to include a compile test for
> small source that uses scanf() with "%as"/"%ms".

I doubt a direct compile test is possible here, one need to run scanf
code to find out whether %m is actually supported.

-- 
Thanks.
-- Max


From marco.castrovilli at gmail.com  Fri Jun  3 06:45:31 2016
From: marco.castrovilli at gmail.com (Marco Castrovilli)
Date: Fri, 3 Jun 2016 15:45:31 +0200
Subject: [LEDE-DEV] mmc driver for openwrt on fonera 2100
Message-ID: <56700383-6ffd-72a4-fca6-f46e582eff90@gmail.com>

hi all!
does anyone can help me to find mmc driver working on openwrt, installed 
on fonera 2100 (mips architectire)?
thank you in advance.


From Alexey.Brodkin at synopsys.com  Fri Jun  3 06:51:39 2016
From: Alexey.Brodkin at synopsys.com (Alexey Brodkin)
Date: Fri, 3 Jun 2016 13:51:39 +0000
Subject: [LEDE-DEV] [PATCH] fix uClibc-ng scanf check
In-Reply-To: <CAMo8BfJYoUrALib89abi1cCT=fcLyMSkXAfGJ=LpzgnrUveJCg@mail.gmail.com>
References: <20160603022328.GA24494@waldemar-brodkorb.de>
 <1464947857.8682.3.camel@synopsys.com>
 <CAMo8BfJYoUrALib89abi1cCT=fcLyMSkXAfGJ=LpzgnrUveJCg@mail.gmail.com>
Message-ID: <1464961857.8682.41.camel@synopsys.com>

Hi Max,

On Fri, 2016-06-03 at 16:43 +0300, Max Filippov wrote:
> Hi Alexey,
> 
> On Fri, Jun 3, 2016 at 12:58 PM, Alexey Brodkin
> <Alexey.Brodkin at synopsys.com> wrote:
> > 
> > IMHO much better approach would be to include a compile test for
> > small source that uses scanf() with "%as"/"%ms".
> I doubt a direct compile test is possible here, one need to run scanf
> code to find out whether %m is actually supported.

Right, I see now.
So then indeed Waldemar's patch looks good.

Sorry for the noise.

-Alexey

From me at ndoo.sg  Fri Jun  3 06:53:16 2016
From: me at ndoo.sg (Andrew Yong)
Date: Fri, 3 Jun 2016 21:53:16 +0800
Subject: [LEDE-DEV] mmc driver for openwrt on fonera 2100
In-Reply-To: <56700383-6ffd-72a4-fca6-f46e582eff90@gmail.com>
References: <56700383-6ffd-72a4-fca6-f46e582eff90@gmail.com>
Message-ID: <CA+yTfBCAbQgRO36WQX_uPO-OQQCLo+Sg4+pqAFOs_HrHv3ZPGA@mail.gmail.com>

https://wiki.openwrt.org/doc/hardware/port.gpio and see relevant
sections for bitbanging MMC over GPIO.

On 3 Jun 2016 21:46, "Marco Castrovilli" <marco.castrovilli at gmail.com> wrote:
>
> hi all!
> does anyone can help me to find mmc driver working on openwrt, installed on fonera 2100 (mips architectire)?
> thank you in advance.
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


From marco.castrovilli at gmail.com  Fri Jun  3 07:28:54 2016
From: marco.castrovilli at gmail.com (Marco Castrovilli)
Date: Fri, 3 Jun 2016 16:28:54 +0200
Subject: [LEDE-DEV] mmc driver for openwrt on fonera 2100
In-Reply-To: <13d21777-d42d-bcab-4831-542c87fa0a14@gmail.com>
References: <56700383-6ffd-72a4-fca6-f46e582eff90@gmail.com>
 <CA+yTfBBGrvy8r8yiZ+ZNf-4m1Ss1==fr95HvgEaQ4WrwB_XBTw@mail.gmail.com>
 <13d21777-d42d-bcab-4831-542c87fa0a14@gmail.com>
Message-ID: <25c7d7c5-a719-a79e-34b0-656268618492@gmail.com>

i send again in plain text format (not HTML).

sorry for my bad /Netiquette :(
/

thank you.

thanks a lot for your immediate answer.
i followed this guide to mod fonera adding an sd card:
http://www.wifi-ita.com/index.php?option=com_content&task=view&id=223
and this one:
http://www.nabuk.org/f/index.php?topic=1486.0
everything is ok but i can't find 26215-4pinfon2100Driver7143.ipk anywere.
i'm on kamikaze 7.09 and kernel:
Linux Legend 2.6.22.1 #5 Mon Aug 13 18:18:07 EDT 2007 mips unknown

i tried to update (with ipkg, not opkg) but i have problem with original 
openwrt feed:
root at Legend:~# ipkg update
Downloading 
http://downloads.openwrt.org/snapshots/atheros-2.6/packages/Packages
wget: server returned error: HTTP/1.1 404 Not Found
Downloading http://downloads.openwrt.org/kamikaze/packages/mips/Packages
wget: server returned error: HTTP/1.1 404 Not Found
Downloading 
http://downloads.x-wrt.org/xwrt/kamikaze/snapshots/atheros-2.6/packages/Packages
wget: server returned error: HTTP/1.1 404 Not Found
An error ocurred, return value: 3.
Collected errors:
ipkg_download: ERROR: Command failed with return value 1: `wget 
--passive-ftp    -q -P /tmp/ipkg-hCDHje 
http://downloads.openwrt.org/snapshots/atheros-2.6/packages/Packages'
ipkg_download: ERROR: Command failed with return value 1: `wget 
--passive-ftp    -q -P /tmp/ipkg-hCDHje 
http://downloads.openwrt.org/kamikaze/packages/mips/Packages'
ipkg_download: ERROR: Command failed with return value 1: `wget 
--passive-ftp    -q -P /tmp/ipkg-hCDHje 
http://downloads.x-wrt.org/xwrt/kamikaze/snapshots/atheros-2.6/packages/Packages'
root at Legend:~#

so i tried with other ones but:
root at Legend:~# ipkg update
Downloading 
https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
wget: not an http or ftp url: 
https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
Downloading 
https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
wget: not an http or ftp url: 
https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
Downloading 
https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
wget: not an http or ftp url: 
https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
An error ocurred, return value: 3.
Collected errors:
ipkg_download: ERROR: Command failed with return value 1: `wget 
--passive-ftp    -q -P /tmp/ipkg-nErUJo 
https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages'
ipkg_download: ERROR: Command failed with return value 1: `wget 
--passive-ftp    -q -P /tmp/ipkg-nErUJo 
https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages'
ipkg_download: ERROR: Command failed with return value 1: `wget 
--passive-ftp    -q -P /tmp/ipkg-nErUJo 
https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages'
root at Legend:~#

i got a more recent wget (wget_1.10.2-2_mips.ipk) but stil have problems 
with ssl.
anyway, browsing manually feeds i can't find driver.

perhaps i NEED to use kamikaze 8.09 and all troubles will run away?

again many thanks Andrew for your interest: this is my last chance to 
use a microSD on my fonera 2100 :)





From me at ndoo.sg  Fri Jun  3 07:32:35 2016
From: me at ndoo.sg (Andrew Yong)
Date: Fri, 3 Jun 2016 22:32:35 +0800
Subject: [LEDE-DEV] mmc driver for openwrt on fonera 2100
In-Reply-To: <13d21777-d42d-bcab-4831-542c87fa0a14@gmail.com>
References: <56700383-6ffd-72a4-fca6-f46e582eff90@gmail.com>
 <CA+yTfBBGrvy8r8yiZ+ZNf-4m1Ss1==fr95HvgEaQ4WrwB_XBTw@mail.gmail.com>
 <13d21777-d42d-bcab-4831-542c87fa0a14@gmail.com>
Message-ID: <CA+yTfBCViAFD=pOTmfro=S5vyEJcbsjZ8ijHbbTpkOGPyaH9hA@mail.gmail.com>

You'll want to use OpenWrt Kamikaze 8.09 and use the official package
manager opkg. Follow the linked wiki page
(https://wiki.openwrt.org/doc/howto/mmc_over_gpio) and you'll be fine.

The latest releases have deprecated kmod-mmc-over-gpio in favor of
just getting other generic $30 routers from AliExpress that have built
in TF/MMC ports (generally RT5350), or AR9311 routers with USB e.g.
TL-MR3020.



On Fri, Jun 3, 2016 at 10:15 PM, Marco Castrovilli
<marco.castrovilli at gmail.com> wrote:
> thanks a lot for your immediate answer.
> i followed this guide to mod fonera adding an sd card:
> http://www.wifi-ita.com/index.php?option=com_content&task=view&id=223
> and this one:
> http://www.nabuk.org/f/index.php?topic=1486.0
> everything is ok but i can't find 26215-4pinfon2100Driver7143.ipk anywere.
> i'm on kamikaze 7.09 and kernel:
> Linux Legend 2.6.22.1 #5 Mon Aug 13 18:18:07 EDT 2007 mips unknown
>
> i tried to update (with ipkg, not opkg) but i have problem with original
> openwrt feed:
> root at Legend:~# ipkg update
> Downloading
> http://downloads.openwrt.org/snapshots/atheros-2.6/packages/Packages
> wget: server returned error: HTTP/1.1 404 Not Found
> Downloading http://downloads.openwrt.org/kamikaze/packages/mips/Packages
> wget: server returned error: HTTP/1.1 404 Not Found
> Downloading
> http://downloads.x-wrt.org/xwrt/kamikaze/snapshots/atheros-2.6/packages/Packages
> wget: server returned error: HTTP/1.1 404 Not Found
> An error ocurred, return value: 3.
> Collected errors:
> ipkg_download: ERROR: Command failed with return value 1: `wget
> --passive-ftp    -q -P /tmp/ipkg-hCDHje
> http://downloads.openwrt.org/snapshots/atheros-2.6/packages/Packages'
> ipkg_download: ERROR: Command failed with return value 1: `wget
> --passive-ftp    -q -P /tmp/ipkg-hCDHje
> http://downloads.openwrt.org/kamikaze/packages/mips/Packages'
> ipkg_download: ERROR: Command failed with return value 1: `wget
> --passive-ftp    -q -P /tmp/ipkg-hCDHje
> http://downloads.x-wrt.org/xwrt/kamikaze/snapshots/atheros-2.6/packages/Packages'
> root at Legend:~#
>
> so i tried with other ones but:
> root at Legend:~# ipkg update
> Downloading
> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
> wget: not an http or ftp url:
> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
> Downloading
> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
> wget: not an http or ftp url:
> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
> Downloading
> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
> wget: not an http or ftp url:
> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
> An error ocurred, return value: 3.
> Collected errors:
> ipkg_download: ERROR: Command failed with return value 1: `wget
> --passive-ftp    -q -P /tmp/ipkg-nErUJo
> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages'
> ipkg_download: ERROR: Command failed with return value 1: `wget
> --passive-ftp    -q -P /tmp/ipkg-nErUJo
> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages'
> ipkg_download: ERROR: Command failed with return value 1: `wget
> --passive-ftp    -q -P /tmp/ipkg-nErUJo
> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages'
> root at Legend:~#
>
> i got a more recent wget (wget_1.10.2-2_mips.ipk) but stil have problems
> with ssl.
> anyway, browsing manually feeds i can't find driver.
>
> perhaps i NEED to use kamikaze 8.09 and all troubles will run away?
>
> again many thanks Andrew for your interest: this is my last chance to use a
> microSD on my fonera 2100 :)
>
>
>
> Il 03/06/2016 15:49, Andrew Yong ha scritto:
>
> https://wiki.openwrt.org/doc/hardware/port.gpio and see relevant sections
> for bitbanging MMC over GPIO.
>
> On 3 Jun 2016 21:46, "Marco Castrovilli" <marco.castrovilli at gmail.com>
> wrote:
>>
>> hi all!
>> does anyone can help me to find mmc driver working on openwrt, installed
>> on fonera 2100 (mips architectire)?
>> thank you in advance.
>>
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
>
>


From marco.castrovilli at gmail.com  Fri Jun  3 07:36:53 2016
From: marco.castrovilli at gmail.com (Marco Castrovilli)
Date: Fri, 3 Jun 2016 16:36:53 +0200
Subject: [LEDE-DEV] mmc driver for openwrt on fonera 2100
In-Reply-To: <CA+yTfBCViAFD=pOTmfro=S5vyEJcbsjZ8ijHbbTpkOGPyaH9hA@mail.gmail.com>
References: <56700383-6ffd-72a4-fca6-f46e582eff90@gmail.com>
 <CA+yTfBBGrvy8r8yiZ+ZNf-4m1Ss1==fr95HvgEaQ4WrwB_XBTw@mail.gmail.com>
 <13d21777-d42d-bcab-4831-542c87fa0a14@gmail.com>
 <CA+yTfBCViAFD=pOTmfro=S5vyEJcbsjZ8ijHbbTpkOGPyaH9hA@mail.gmail.com>
Message-ID: <ff541d7d-e86f-d1e6-1d5b-6a970c47ea3b@gmail.com>

thanks a lot.

tonight i have this task!

i'll give you a feedback.

regards,

marco.


Il 03/06/2016 16:32, Andrew Yong ha scritto:
> You'll want to use OpenWrt Kamikaze 8.09 and use the official package
> manager opkg. Follow the linked wiki page
> (https://wiki.openwrt.org/doc/howto/mmc_over_gpio) and you'll be fine.
>
> The latest releases have deprecated kmod-mmc-over-gpio in favor of
> just getting other generic $30 routers from AliExpress that have built
> in TF/MMC ports (generally RT5350), or AR9311 routers with USB e.g.
> TL-MR3020.
>
>
>
> On Fri, Jun 3, 2016 at 10:15 PM, Marco Castrovilli
> <marco.castrovilli at gmail.com> wrote:
>> thanks a lot for your immediate answer.
>> i followed this guide to mod fonera adding an sd card:
>> http://www.wifi-ita.com/index.php?option=com_content&task=view&id=223
>> and this one:
>> http://www.nabuk.org/f/index.php?topic=1486.0
>> everything is ok but i can't find 26215-4pinfon2100Driver7143.ipk anywere.
>> i'm on kamikaze 7.09 and kernel:
>> Linux Legend 2.6.22.1 #5 Mon Aug 13 18:18:07 EDT 2007 mips unknown
>>
>> i tried to update (with ipkg, not opkg) but i have problem with original
>> openwrt feed:
>> root at Legend:~# ipkg update
>> Downloading
>> http://downloads.openwrt.org/snapshots/atheros-2.6/packages/Packages
>> wget: server returned error: HTTP/1.1 404 Not Found
>> Downloading http://downloads.openwrt.org/kamikaze/packages/mips/Packages
>> wget: server returned error: HTTP/1.1 404 Not Found
>> Downloading
>> http://downloads.x-wrt.org/xwrt/kamikaze/snapshots/atheros-2.6/packages/Packages
>> wget: server returned error: HTTP/1.1 404 Not Found
>> An error ocurred, return value: 3.
>> Collected errors:
>> ipkg_download: ERROR: Command failed with return value 1: `wget
>> --passive-ftp    -q -P /tmp/ipkg-hCDHje
>> http://downloads.openwrt.org/snapshots/atheros-2.6/packages/Packages'
>> ipkg_download: ERROR: Command failed with return value 1: `wget
>> --passive-ftp    -q -P /tmp/ipkg-hCDHje
>> http://downloads.openwrt.org/kamikaze/packages/mips/Packages'
>> ipkg_download: ERROR: Command failed with return value 1: `wget
>> --passive-ftp    -q -P /tmp/ipkg-hCDHje
>> http://downloads.x-wrt.org/xwrt/kamikaze/snapshots/atheros-2.6/packages/Packages'
>> root at Legend:~#
>>
>> so i tried with other ones but:
>> root at Legend:~# ipkg update
>> Downloading
>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
>> wget: not an http or ftp url:
>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
>> Downloading
>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
>> wget: not an http or ftp url:
>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
>> Downloading
>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
>> wget: not an http or ftp url:
>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
>> An error ocurred, return value: 3.
>> Collected errors:
>> ipkg_download: ERROR: Command failed with return value 1: `wget
>> --passive-ftp    -q -P /tmp/ipkg-nErUJo
>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages'
>> ipkg_download: ERROR: Command failed with return value 1: `wget
>> --passive-ftp    -q -P /tmp/ipkg-nErUJo
>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages'
>> ipkg_download: ERROR: Command failed with return value 1: `wget
>> --passive-ftp    -q -P /tmp/ipkg-nErUJo
>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages'
>> root at Legend:~#
>>
>> i got a more recent wget (wget_1.10.2-2_mips.ipk) but stil have problems
>> with ssl.
>> anyway, browsing manually feeds i can't find driver.
>>
>> perhaps i NEED to use kamikaze 8.09 and all troubles will run away?
>>
>> again many thanks Andrew for your interest: this is my last chance to use a
>> microSD on my fonera 2100 :)
>>
>>
>>
>> Il 03/06/2016 15:49, Andrew Yong ha scritto:
>>
>> https://wiki.openwrt.org/doc/hardware/port.gpio and see relevant sections
>> for bitbanging MMC over GPIO.
>>
>> On 3 Jun 2016 21:46, "Marco Castrovilli" <marco.castrovilli at gmail.com>
>> wrote:
>>> hi all!
>>> does anyone can help me to find mmc driver working on openwrt, installed
>>> on fonera 2100 (mips architectire)?
>>> thank you in advance.
>>>
>>> _______________________________________________
>>> Lede-dev mailing list
>>> Lede-dev at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>



From Alexey.Brodkin at synopsys.com  Fri Jun  3 07:46:31 2016
From: Alexey.Brodkin at synopsys.com (Alexey Brodkin)
Date: Fri, 3 Jun 2016 14:46:31 +0000
Subject: [LEDE-DEV] [PATCH] package/devel/gdb: Add support of ARC gdb
In-Reply-To: <3b23b081-1df6-1a11-2162-b7ff223a44ec@phrozen.org>
References: <1464795158-4753-1-git-send-email-abrodkin@synopsys.com>
 <3b23b081-1df6-1a11-2162-b7ff223a44ec@phrozen.org>
Message-ID: <1464965148.8682.51.camel@synopsys.com>

Hi John,

On Fri, 2016-06-03 at 11:09 +0200, John Crispin wrote:
> Hi,
> 
> On 01/06/2016 17:32, Alexey Brodkin wrote:
> > 
> > As of today gdb port for ARC is not yet in upstream even though
> > we're working hard on that.
> > 
> > Still to allow ARC users to debug user-space apps on top of
> > Linux kernel we're adding here support for building GDB from
> > sources hosted on our GitHub here:
> > https://github.com/foss-for-synopsys-dwc-arc-processors/binutils-gdb/releases/tag/arc-2016.03-gdb
> > 
> > Likewise for host GDB sources that come from unified git repository
> > (which is the case for upstream binutils/gdb today) we need to disable
> > building of binutils in gdb:
> > ------>8------
> > --disable-binutils
> > --disable-ld
> > --disable-gas
> > ------>8------
> > 
> these work for !arc targets. disabling them for all targets because they
> are broken on arc seem weird even if they might not be used.
> 
> rather than cluttering the makefile how about marking the packahe broken
> for arc and adding a new one called gdb-arc that depends on arc only.
> this will allow us to keep gdb clean and just drop the gdb-arc package
> once the fixes treacled down the tree.

Well all 3 options except "--sim" are very valid because modern GDB sources
come from "unified" git repo where binutils co-exist with gdb.

That's done on purpose because a lot of stuff indeed is the same in both
projects. And there's really no point in building either binutils, ld or gas
when we're building GDB. Disabling those options we at least saving some time
and in some cases may escape build failures.

Mentioned build failures might happen with some even release versions of GDB
tarballs. Again that is because gdb comes from the same unified repo BUT
(and that's important) still from the separate branch and so some parts of
binutils might be taken from "binutils" branch in unstable state.

In other words disabling build of not used components is pretty safe and
future-proof. And simulator falls here as well - we don't need it anyways
for either arch/board.

As for adding a separate package... we'll need to propagate new Kconfig symbol in
other files and so instead of limiting changes to 1 file we'll spread our
contamination all over source tree. Do we really want it?

-Alexey


From john at phrozen.org  Fri Jun  3 07:48:50 2016
From: john at phrozen.org (John Crispin)
Date: Fri, 3 Jun 2016 16:48:50 +0200
Subject: [LEDE-DEV] international keyboard layout support
In-Reply-To: <810e5bea-5baf-4cc5-5808-9301b2487293@web.de>
References: <810e5bea-5baf-4cc5-5808-9301b2487293@web.de>
Message-ID: <4dbce99f-c232-1fb6-00fb-7a90659b2af4@phrozen.org>



On 03/06/2016 14:19, edgar.soldin at web.de wrote:
> hey All,
> 
> i already posted this on openwrt-devel at lists.openwrt.org , but am currently unsure what the status is for LEDE vs. OpenWrt. so here i go again on this very ml.
> 
> while tinkering with Gluon the Openwrt based Freifunk firmware (currently on CC) on a x86 based thin client box i needed support for a german keyboard layout. i managed to realize that manually as i didn't find any prepared packages for this purpose.
> 
> is there any interest in a keyboardmaps package, holding busybox compatible binary kmaps and activating the needed busybox utilities? i imagine some devs/users especially on platforms with proper keyboard interfaces (usb/ps2) would appreciate that.
> 
> thanks ..ede
> 


Hi,

generally not a bad idea. the problem is enabling extra uclibc applets.
can this be done using the normal gnu tools ? x86 will have enough space
to install extra full blown tools

	John

> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 


From john at phrozen.org  Fri Jun  3 07:50:51 2016
From: john at phrozen.org (John Crispin)
Date: Fri, 3 Jun 2016 16:50:51 +0200
Subject: [LEDE-DEV] [PATCH] package/devel/gdb: Add support of ARC gdb
In-Reply-To: <1464965148.8682.51.camel@synopsys.com>
References: <1464795158-4753-1-git-send-email-abrodkin@synopsys.com>
 <3b23b081-1df6-1a11-2162-b7ff223a44ec@phrozen.org>
 <1464965148.8682.51.camel@synopsys.com>
Message-ID: <d0430be0-24e0-1dc5-8122-9b49ecc0c9ee@phrozen.org>



On 03/06/2016 16:46, Alexey Brodkin wrote:
> Hi John,
> 
> On Fri, 2016-06-03 at 11:09 +0200, John Crispin wrote:
>> Hi,
>>
>> On 01/06/2016 17:32, Alexey Brodkin wrote:
>>>
>>> As of today gdb port for ARC is not yet in upstream even though
>>> we're working hard on that.
>>>
>>> Still to allow ARC users to debug user-space apps on top of
>>> Linux kernel we're adding here support for building GDB from
>>> sources hosted on our GitHub here:
>>> https://github.com/foss-for-synopsys-dwc-arc-processors/binutils-gdb/releases/tag/arc-2016.03-gdb
>>>
>>> Likewise for host GDB sources that come from unified git repository
>>> (which is the case for upstream binutils/gdb today) we need to disable
>>> building of binutils in gdb:
>>> ------>8------
>>> --disable-binutils
>>> --disable-ld
>>> --disable-gas
>>> ------>8------
>>>
>> these work for !arc targets. disabling them for all targets because they
>> are broken on arc seem weird even if they might not be used.
>>
>> rather than cluttering the makefile how about marking the packahe broken
>> for arc and adding a new one called gdb-arc that depends on arc only.
>> this will allow us to keep gdb clean and just drop the gdb-arc package
>> once the fixes treacled down the tree.
> 
> Well all 3 options except "--sim" are very valid because modern GDB sources
> come from "unified" git repo where binutils co-exist with gdb.
> 
> That's done on purpose because a lot of stuff indeed is the same in both
> projects. And there's really no point in building either binutils, ld or gas
> when we're building GDB. Disabling those options we at least saving some time
> and in some cases may escape build failures.
> 
> Mentioned build failures might happen with some even release versions of GDB
> tarballs. Again that is because gdb comes from the same unified repo BUT
> (and that's important) still from the separate branch and so some parts of
> binutils might be taken from "binutils" branch in unstable state.
> 
> In other words disabling build of not used components is pretty safe and
> future-proof. And simulator falls here as well - we don't need it anyways
> for either arch/board.
> 
> As for adding a separate package... we'll need to propagate new Kconfig symbol in
> other files and so instead of limiting changes to 1 file we'll spread our
> contamination all over source tree. Do we really want it?

which packages depend on gdbserver ?


> 
> -Alexey
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 


From eyal.birger at gmail.com  Fri Jun  3 07:55:11 2016
From: eyal.birger at gmail.com (Eyal Birger)
Date: Fri, 3 Jun 2016 17:55:11 +0300
Subject: [LEDE-DEV] [OpenWrt-Devel] [PATCH libubox] blobmsg_json: add
	new functions blobmsg_format_json_value*
In-Reply-To: <02fc8e5d-d737-58b0-e712-d0b9ebf58f9e@universe-factory.net>
References: <dbc90f6d05a606753e2576bd6fc3569c5958885a.1464812878.git.mschiffer@universe-factory.net>
 <e63ded11-8ba8-c0da-78ee-a5be70eca1fd@phrozen.org>
 <02fc8e5d-d737-58b0-e712-d0b9ebf58f9e@universe-factory.net>
Message-ID: <A597E23F-9BF7-4C47-8F36-AA527F32E669@gmail.com>


Hi,

> On 3 Jun 2016, at 13:11, Matthias Schiffer <mschiffer at universe-factory.net> wrote:
> 
(snip)
> 
> 1) and 2) would allow blobmsg to store everything that json-c can (with the
> caveat that json-c stores integers as int64 internally, while blobmsg_json
> uses int32) -

We also noticed this as a problem for us since when converting json strings to blobmsg, integers become signed and thus no more than INT32_MAX can be used.

Do you plans to approach this in your patchsets?

Eyal

> do you think these changes make sense?
> 
> Would there also be general interest in 3), so it might be integrated into
> libubox?
> 
> Regards,
> Matthias
> 
> 
>> 
>>> 
>>> Signed-off-by: Matthias Schiffer <mschiffer at universe-factory.net>
>>> ---
>>> blobmsg_json.c | 49 ++++++++++++++++++++++++++++++++++++-------------
>>> blobmsg_json.h | 14 ++++++++++++++
>>> 2 files changed, 50 insertions(+), 13 deletions(-)
>>> 
>>> diff --git a/blobmsg_json.c b/blobmsg_json.c
>>> index 5713948..538c816 100644
>>> --- a/blobmsg_json.c
>>> +++ b/blobmsg_json.c
>>> @@ -207,7 +207,7 @@ static void blobmsg_format_string(struct strbuf *s, const char *str)
>>> 
>>> static void blobmsg_format_json_list(struct strbuf *s, struct blob_attr *attr, int len, bool array);
>>> 
>>> -static void blobmsg_format_element(struct strbuf *s, struct blob_attr *attr, bool array, bool head)
>>> +static void blobmsg_format_element(struct strbuf *s, struct blob_attr *attr, bool without_name, bool head)
>>> {
>>>    const char *data_str;
>>>    char buf[32];
>>> @@ -217,7 +217,7 @@ static void blobmsg_format_element(struct strbuf *s, struct blob_attr *attr, boo
>>>    if (!blobmsg_check_attr(attr, false))
>>>        return;
>>> 
>>> -    if (!array && blobmsg_name(attr)[0]) {
>>> +    if (!without_name && blobmsg_name(attr)[0]) {
>>>        blobmsg_format_string(s, blobmsg_name(attr));
>>>        blobmsg_puts(s, ": ", s->indent ? 2 : 1);
>>>    }
>>> @@ -286,22 +286,26 @@ static void blobmsg_format_json_list(struct strbuf *s, struct blob_attr *attr, i
>>>    blobmsg_puts(s, (array ? "]" : "}"), 1);
>>> }
>>> 
>>> +static void setup_strbuf(struct strbuf *s, struct blob_attr *attr, blobmsg_json_format_t cb, void *priv, int indent) {
>>> +    s->len = blob_len(attr);
>>> +    s->buf = malloc(s->len);
>>> +    s->pos = 0;
>>> +    s->custom_format = cb;
>>> +    s->priv = priv;
>>> +    s->indent = false;
>>> +
>>> +    if (indent >= 0) {
>>> +        s->indent = true;
>>> +        s->indent_level = indent;
>>> +    }
>>> +}
>>> +
>>> char *blobmsg_format_json_with_cb(struct blob_attr *attr, bool list, blobmsg_json_format_t cb, void *priv, int indent)
>>> {
>>>    struct strbuf s;
>>>    bool array;
>>> 
>>> -    s.len = blob_len(attr);
>>> -    s.buf = malloc(s.len);
>>> -    s.pos = 0;
>>> -    s.custom_format = cb;
>>> -    s.priv = priv;
>>> -    s.indent = false;
>>> -
>>> -    if (indent >= 0) {
>>> -        s.indent = true;
>>> -        s.indent_level = indent;
>>> -    }
>>> +    setup_strbuf(&s, attr, cb, priv, indent);
>>> 
>>>    array = blob_is_extended(attr) &&
>>>        blobmsg_type(attr) == BLOBMSG_TYPE_ARRAY;
>>> @@ -321,3 +325,22 @@ char *blobmsg_format_json_with_cb(struct blob_attr *attr, bool list, blobmsg_jso
>>> 
>>>    return s.buf;
>>> }
>>> +
>>> +char *blobmsg_format_json_value_with_cb(struct blob_attr *attr, blobmsg_json_format_t cb, void *priv, int indent)
>>> +{
>>> +    struct strbuf s;
>>> +
>>> +    setup_strbuf(&s, attr, cb, priv, indent);
>>> +
>>> +    blobmsg_format_element(&s, attr, true, false);
>>> +
>>> +    if (!s.len) {
>>> +        free(s.buf);
>>> +        return NULL;
>>> +    }
>>> +
>>> +    s.buf = realloc(s.buf, s.pos + 1);
>>> +    s.buf[s.pos] = 0;
>>> +
>>> +    return s.buf;
>>> +}
>>> diff --git a/blobmsg_json.h b/blobmsg_json.h
>>> index cd9ed33..9dfc02d 100644
>>> --- a/blobmsg_json.h
>>> +++ b/blobmsg_json.h
>>> @@ -42,4 +42,18 @@ static inline char *blobmsg_format_json_indent(struct blob_attr *attr, bool list
>>>    return blobmsg_format_json_with_cb(attr, list, NULL, NULL, indent);
>>> }
>>> 
>>> +char *blobmsg_format_json_value_with_cb(struct blob_attr *attr,
>>> +                    blobmsg_json_format_t cb, void *priv,
>>> +                    int indent);
>>> +
>>> +static inline char *blobmsg_format_json_value(struct blob_attr *attr)
>>> +{
>>> +    return blobmsg_format_json_value_with_cb(attr, NULL, NULL, -1);
>>> +}
>>> +
>>> +static inline char *blobmsg_format_json_value_indent(struct blob_attr *attr, int indent)
>>> +{
>>> +    return blobmsg_format_json_value_with_cb(attr, NULL, NULL, indent);
>>> +}
>>> +
>>> #endif
> 
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


From edgar.soldin at web.de  Fri Jun  3 08:04:21 2016
From: edgar.soldin at web.de (edgar.soldin at web.de)
Date: Fri, 3 Jun 2016 17:04:21 +0200
Subject: [LEDE-DEV] international keyboard layout support
In-Reply-To: <4dbce99f-c232-1fb6-00fb-7a90659b2af4@phrozen.org>
References: <810e5bea-5baf-4cc5-5808-9301b2487293@web.de>
 <4dbce99f-c232-1fb6-00fb-7a90659b2af4@phrozen.org>
Message-ID: <5ff27e82-9edf-c65a-0488-f5912fd5c915@web.de>

On 03.06.2016 16:48, John Crispin wrote:
> 
> 
> On 03/06/2016 14:19, edgar.soldin at web.de wrote:
>> hey All,
>>
>> i already posted this on openwrt-devel at lists.openwrt.org , but am currently unsure what the status is for LEDE vs. OpenWrt. so here i go again on this very ml.
>>
>> while tinkering with Gluon the Openwrt based Freifunk firmware (currently on CC) on a x86 based thin client box i needed support for a german keyboard layout. i managed to realize that manually as i didn't find any prepared packages for this purpose.
>>
>> is there any interest in a keyboardmaps package, holding busybox compatible binary kmaps and activating the needed busybox utilities? i imagine some devs/users especially on platforms with proper keyboard interfaces (usb/ps2) would appreciate that.
>>
>> thanks ..ede
>>
> 
> 
> Hi,
> 
> generally not a bad idea. the problem is enabling extra uclibc applets.
> can this be done using the normal gnu tools ? x86 will have enough space
> to install extra full blown tools
> 

you mean busybox applets? it's actually just one CONFIG_BUSYBOX_CONFIG_LOADKMAP=y .

i just added a short Gluon specific summary here
 https://github.com/freifunk-gluon/gluon/wiki/Commandline-administration#load-a-new-keyboard-layout

a full blown package would autoselect the busybox applet and offer menuconfig entries for users to select the maps they want in their build, although they will probably just add all on x86 most of the time (1.1MB).

i already wrote a uci-defaults/ script that adds the appropriate line to /etc/rc.local so a default mapping will be loaded automagically. that could be made selectable in menuconfig as well.

thanks.. ede


From Alexey.Brodkin at synopsys.com  Fri Jun  3 08:36:34 2016
From: Alexey.Brodkin at synopsys.com (Alexey Brodkin)
Date: Fri, 3 Jun 2016 15:36:34 +0000
Subject: [LEDE-DEV] [PATCH] fix uClibc-ng scanf check
In-Reply-To: <20160603151648.GU6825@waldemar-brodkorb.de>
References: <20160603022328.GA24494@waldemar-brodkorb.de>
 <1464947857.8682.3.camel@synopsys.com>
 <20160603151648.GU6825@waldemar-brodkorb.de>
Message-ID: <1464968152.8682.52.camel@synopsys.com>

Hi Waldemar,

On Fri, 2016-06-03 at 17:16 +0200, Waldemar Brodkorb wrote:
> Hi Alexey,
> Alexey Brodkin wrote,
> 
> > 
> > Hi Waldemar,
> > 
> > On Fri, 2016-06-03 at 04:23 +0200, Waldemar Brodkorb wrote:
> > > 
> > > uClibc-ng tries to be compatible with GNU libc and defines
> > > __GLIBC__ and pretend to be version 2.2.
> > > We once changed it to 2.10, but then some hard to fix problems
> > > in different software packages (gcc) occured.
> > > It would be better if we disable the special GNU libc checks
> > > for uClibc-ng here. uClibc-ng implements the required scanf
> > > functionality.
> > > 
> > > Signed-off-by: Waldemar Brodkorb <wbx at uclibc-ng.org>
> > > ---
> > > ?configure.ac | 2 +-
> > > ?1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/configure.ac b/configure.ac
> > > index f36b18c..4661c0d 100644
> > > --- a/configure.ac
> > > +++ b/configure.ac
> > > @@ -581,7 +581,7 @@ AC_CACHE_VAL([scanf_cv_alloc_modifier],
> > > ??????#include <stdio.h>
> > > ??????#include <unistd.h>
> > > ?
> > > -?????#ifdef __GLIBC__
> > > +?????#if defined(__GLIBC__) && !defined(__UCLIBC__)
> > > ?
> > > ??????#if !(__GLIBC_PREREQ(2, 7))
> > > ??????#error %m is not available
> > Even though this is a very minor and clean change I don't like this
> > approach. We're again implicitly assume something.
> > 
> > IMHO much better approach would be to include a compile test for
> > small source that uses scanf() with "%as"/"%ms".
> > 
> > That way we may remove all dependencies on either GLIBC/UCLIBC/MUSL etc.
> Just for completeness, I saw your other mail already.
> Musl has no problem with this code, because it is util-linux
> fallback code for old GNU libc. Unfortunately it matches the
> pretended version from uClibc-ng. So I think it is the right
> solution, if the fallback code will not be removed.

Thanks for explanation.

-Alexey

From karlp at tweak.net.au  Fri Jun  3 09:16:32 2016
From: karlp at tweak.net.au (Karl Palsson)
Date: Fri, 03 Jun 2016 16:16:32 -0000
Subject: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.
In-Reply-To: <57517A27.1030200@conorogorman.net>
References: <57517A27.1030200@conorogorman.net>
Message-ID: <NPg2vSLQaWbCmMsJ7rn8Hubu9ZTQAwaRQoeeybuN211d@mailpile>


Conor O'Gorman <i at conorogorman.net> wrote:
> 
> 
> On 03/06/16 13:27, Ben Greear wrote:
> >
> >
> > On 06/03/2016 02:17 AM, John Crispin wrote:
> >>
> >>
> >> On 01/06/2016 20:21, Ben Greear wrote:
> >>> On 06/01/2016 11:07 AM, John Crispin wrote:
> >>>> Hi Ben,
> >>>>
> >>>> also inclined to reject this one. it will open up the pandoras box and
> >>>> we will end up maintaining piles of diffconfig files. it would make
> >>>> morse sense to document what the script does inside web.git as a 
> >>>> "how to
> >>>> build" or "getting started" page
> >>>
> >>> I do not have much history with LEDE/WRT, but is the diffconfig output
> >>> really that fragile?
> >>>
> >>> I will be willing to maintain the x86-64 and probably Ventana
> >>> diffconfigs, and even if it totally fails, you have not lost
> >>> any functionality since the main infrastructure is unchanged.
> >>
> >> for how long and will all the other people submitting these files also
> >> provide LTS ? normally activism fades after a few months. we can see
> >> this will board support and package maintenance. i think this will be a
> >> burden.
> >
> > Anything that makes it more easy for others to build images
> > should help bring in more newbies faster, which might keep the
> > activism going, especially for common platforms that will
> > constantly be getting new hardware (like x86-64).
> >
> > Currently, a newbie with an x86-64 board is going to have a slow
> > and frustrating time trying to get any sort of useful 'AP' built
> > from LEDE.  I think I can help to fix that problem if you will
> > let me.
> >
> > So, how about you accept a small number of diffconfig recipes, and the 
> > buildme
> > script, and then see how that works for a while.  I can update
> > buildme.sh to grab a diffconfig from a URL (using curl, or something)
> > and then folks wanting to provide out-of-tree diffconfigs need only
> > put their config in a public place and tell users how to use it:
> >
> > ./buildme.sh -T http://my.funkyplatform.com/board1
> >
> > Thanks,
> > Ben
> >
> This seems to duplicate the functionality of the sub-targets
> and profiles mechanism?


Also, image builder.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP Digital Signature
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20160603/80f921f8/attachment.sig>

From karlp at tweak.net.au  Fri Jun  3 09:19:45 2016
From: karlp at tweak.net.au (Karl Palsson)
Date: Fri, 03 Jun 2016 16:19:45 -0000
Subject: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.
In-Reply-To: <57517E13.6080202@candelatech.com>
References: <57517E13.6080202@candelatech.com>
Message-ID: <DnbW7iMIpQg9kuxBWZDdaLYhASW4a5SMbkoCVP9a211d@mailpile>


> Maybe some of it, but for more generic platforms, I am not sure
> sub-targets make sense, and in general, it is more difficult to
> edit those than to change a diffconfig as far as I can tell.

For who?  I'm pretty sure I can use "make menuconfig" _far_ more reliably than I can edit a diffconfig file to use a "buildme" script.  If I don't know anything, and _need_ to build a custom image that can't be built with image builder, or post install config, then menuconfig at least makes sure that dependencies get pulled in properly.  Adding line items to file that you then "defoncfig" and hope you got perfectt seems fraught with danger, and for what? To avoid showing someone how to use menuconfig?  Which they'll need to use anyway?  Because I don't believe for a _second_ that somehow you're going to have "buildme" magic that automatically solves all the configs someone needs.  

Sincerely,
Karl Palsson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP Digital Signature
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20160603/e44a6d8e/attachment.sig>

From greearb at candelatech.com  Fri Jun  3 09:32:24 2016
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 3 Jun 2016 09:32:24 -0700
Subject: [LEDE-DEV] [PATCH 2/2] Add script to build common platforms.
In-Reply-To: <DnbW7iMIpQg9kuxBWZDdaLYhASW4a5SMbkoCVP9a211d@mailpile>
References: <57517E13.6080202@candelatech.com>
 <DnbW7iMIpQg9kuxBWZDdaLYhASW4a5SMbkoCVP9a211d@mailpile>
Message-ID: <5751B118.5020707@candelatech.com>

On 06/03/2016 09:19 AM, Karl Palsson wrote:
>
>> Maybe some of it, but for more generic platforms, I am not sure
>> sub-targets make sense, and in general, it is more difficult to
>> edit those than to change a diffconfig as far as I can tell.
>
> For who?  I'm pretty sure I can use "make menuconfig" _far_ more reliably than I can edit a diffconfig file to use a "buildme" script.  If I don't know anything, and _need_ to build a custom image that can't be built with image builder, or post install config, then menuconfig at least makes sure that dependencies get pulled in properly.  Adding line items to file that you then "defoncfig" and hope you got perfectt seems fraught with danger, and for what? To avoid showing someone how to use menuconfig?  Which they'll need to use anyway?  Because I don't believe for a _second_ that somehow you're going to have "buildme" magic that automatically solves all the configs someone needs.

First of all, any time you try to add a new module, someone will bitch about
how it bloats their beautiful image and makes it impure.  Adding more sub-targets
almost cannot by definition be any less likely to rot or be un-maintained than
the buildme targets I am proposing.

To create (or update) the diffconfig, you can run menuconfig, twiddle as you like, and then save the
new diffconfig.  And commit changes (assuming you are maintaining this buildme profile).

If the diffconfig profiles are really that un-cool, then maybe just add the buildme
script with ability to use URL for the diffconfig profile and let folks host them
elsewhere.  That is less user-friendly (it would be hard to show user all available options),
but at least it is still one command to build an image.

And anyway, no one is proposing to remove menuconfig logic, I just want to add some
wrappers to make it easier for newbies that may initially be bewildered by all of the menuconfig
options (and lack of options if you haven't installed the proper feeds already).

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From lede at kitschensync.net  Fri Jun  3 14:12:00 2016
From: lede at kitschensync.net (Ted Hess)
Date: Fri, 03 Jun 2016 17:12:00 -0400
Subject: [LEDE-DEV] IXP4xx support for LEDE kernel v4.4
Message-ID: <1464988320.24268.11.camel@kitschensync.net>

I've updated the config for IXP4xx systems and fixed the patches, etc. If anyone
wants to test, the updates are in my staging tree at:

https://git.lede-project.org:lede/thess/staging.git (ixp4xx-kernel-4.4 branch)

Builds all platforms and has been tested on NSLU2 w/mjpg-streamer.

/ted



From eschultz at prplfoundation.org  Fri Jun  3 14:41:59 2016
From: eschultz at prplfoundation.org (Eric Schultz)
Date: Fri, 3 Jun 2016 16:41:59 -0500
Subject: [LEDE-DEV] Meeting on TR-069 Work - Friday, June 10 - 7 AM PT
Message-ID: <5751F9A7.6050406@prplfoundation.org>

I'm excited to see so many people interested in TR-069 support! As a
follow up to the previous TR-069 email, I've set up a meeting on TR-069
support for OpenWrt. The meeting is on Friday, June 10 at 7 AM PT.

I expect the meeting will discuss:

* The proposals for creating/integrating TR-069 support into OpenWrt
from Luka and Felix
* The proposed open source TR-069 stacks from SoftAtHome and
Technicolor, as well as the potential for reuse between stacks
* The potential for a standard TR-069 stack interface in OpenWrt
* A standard interface in OpenWrt for protocols like TR-069, as proposed
by Felix
* A face-to-face meeting for all of the core implementers to work
through the technical details to develop a plan forward
* Anything else related!

Everyone interested is invited to join the meeting. I also plan to post
a video of the meeting to Youtube for those who couldn't attend. To join
the meeting using any WebRTC enabled browser, please follow the
instructions below.

Thanks a lot and I look forward to seeing many of you at the meeting.

Thanks,

Eric

--

Eric Schultz, Community Manager, prpl Foundation
http://www.prplfoundation.org
eschultz at prplfoundation.org <mailto:eschultz at prplfoundation.org>
cell: 920-539-0404 <tel:920-539-0404>
skype: ericschultzwi
@EricPrpl

---

 
To join the web meeting click or copy and paste this URL into your browser:
 
_http://fuze.me/32924366_
 
To join the audio portion of this meeting:
 
Internet Audio: Simply select the internet audio option after joining.
Toll / Intl #: +12014794595
Toll free #: +18553463893
You can find international access numbers at
_https://www.fuze.com/extras/symphony_
If prompted, enter the meeting number: 32924366, then press #.
 
For the optimal experience, download Fuze: 
_www.fuzebox.com/products/download_
 
Need help? You can connect to our Customer Support Team or access self-help
tools at _www.fuzebox.com/support_ <http://www.fuzebox.com/support>.


From eschultz at prplfoundation.org  Fri Jun  3 14:47:58 2016
From: eschultz at prplfoundation.org (Eric Schultz)
Date: Fri, 3 Jun 2016 16:47:58 -0500
Subject: [LEDE-DEV] Meeting on TR-069 Work - Friday, June 10 - 7 AM PT
In-Reply-To: <5751F9A7.6050406@prplfoundation.org>
References: <5751F9A7.6050406@prplfoundation.org>
Message-ID: <5751FB0E.1010603@prplfoundation.org>

All,

Just noticed that the Fuze url was sent inappropriately in my mail
client. The correct URL is http://fuze.me/32924366

Thanks,

Eric

On 06/03/2016 04:41 PM, Eric Schultz wrote:
> I'm excited to see so many people interested in TR-069 support! As a
> follow up to the previous TR-069 email, I've set up a meeting on TR-069
> support for OpenWrt. The meeting is on Friday, June 10 at 7 AM PT.
>
> I expect the meeting will discuss:
>
> * The proposals for creating/integrating TR-069 support into OpenWrt
> from Luka and Felix
> * The proposed open source TR-069 stacks from SoftAtHome and
> Technicolor, as well as the potential for reuse between stacks
> * The potential for a standard TR-069 stack interface in OpenWrt
> * A standard interface in OpenWrt for protocols like TR-069, as proposed
> by Felix
> * A face-to-face meeting for all of the core implementers to work
> through the technical details to develop a plan forward
> * Anything else related!
>
> Everyone interested is invited to join the meeting. I also plan to post
> a video of the meeting to Youtube for those who couldn't attend. To join
> the meeting using any WebRTC enabled browser, please follow the
> instructions below.
>
> Thanks a lot and I look forward to seeing many of you at the meeting.
>
> Thanks,
>
> Eric
>
> --
>
> Eric Schultz, Community Manager, prpl Foundation
> http://www.prplfoundation.org
> eschultz at prplfoundation.org <mailto:eschultz at prplfoundation.org>
> cell: 920-539-0404 <tel:920-539-0404>
> skype: ericschultzwi
> @EricPrpl
>
> ---
>
>  
> To join the web meeting click or copy and paste this URL into your browser:
>  
> _http://fuze.me/32924366_
>  
> To join the audio portion of this meeting:
>  
> Internet Audio: Simply select the internet audio option after joining.
> Toll / Intl #: +12014794595
> Toll free #: +18553463893
> You can find international access numbers at
> _https://www.fuze.com/extras/symphony_
> If prompted, enter the meeting number: 32924366, then press #.
>  
> For the optimal experience, download Fuze: 
> _www.fuzebox.com/products/download_
>  
> Need help? You can connect to our Customer Support Team or access self-help
> tools at _www.fuzebox.com/support_ <http://www.fuzebox.com/support>.
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev



From marco.castrovilli at gmail.com  Fri Jun  3 19:40:14 2016
From: marco.castrovilli at gmail.com (Marco Castrovilli)
Date: Sat, 4 Jun 2016 04:40:14 +0200
Subject: [LEDE-DEV] mmc driver for openwrt on fonera 2100
In-Reply-To: <CA+yTfBCViAFD=pOTmfro=S5vyEJcbsjZ8ijHbbTpkOGPyaH9hA@mail.gmail.com>
References: <56700383-6ffd-72a4-fca6-f46e582eff90@gmail.com>
 <CA+yTfBBGrvy8r8yiZ+ZNf-4m1Ss1==fr95HvgEaQ4WrwB_XBTw@mail.gmail.com>
 <13d21777-d42d-bcab-4831-542c87fa0a14@gmail.com>
 <CA+yTfBCViAFD=pOTmfro=S5vyEJcbsjZ8ijHbbTpkOGPyaH9hA@mail.gmail.com>
Message-ID: <2c0e0357-a4c3-76c4-ab64-b7f82744956c@gmail.com>

hi andrew,
i've installed
openwrt-atheros-root.jffs2-64k
openwrt-atheros-vmlinux.lzma
from https://downloads.openwrt.org/kamikaze/8.09/atheros/

after few problems to configure internet access, i did:

opkg update
opkg install kmod-mmc-over-gpio kmod-fs-ext3 cfdisk e2fsprogs kmod-nls-base kmod-nls-cp437 kmod-nls-iso8859-1

and each installation was fine.

during GPIO configuration i had the message:
uci: entry not found
after each command:
uci set mmc_over_gpio. at mmc_over_gpio[0].enabled=1
uci set mmc_over_gpio. at mmc_over_gpio[0].DI_pin=1
uci set mmc_over_gpio. at mmc_over_gpio[0].DO_pin=4
uci set mmc_over_gpio. at mmc_over_gpio[0].CLK_pin=3
uci set mmc_over_gpio. at mmc_over_gpio[0].CS_pin=7
then i had "can't create /config/gpiommc/ directory" error. so i rebooted, but now i can ping fonera 15/16 times, 1 timeout, other 10/12 ping ok,
then it is unreachable for some seconds and so looping on.

do you know the reason?

and now the final question: i soldered exactly like in figure above:
www.WiFi-Ita.com
as explained here:
http://www.wifi-ita.com/index.php?option=com_content&task=view&id=223

must i have to solder ALL cables on pin of GPIO?

thank you again.
Il 03/06/2016 16:32, Andrew Yong ha scritto:
> You'll want to use OpenWrt Kamikaze 8.09 and use the official package
> manager opkg. Follow the linked wiki page
> (https://wiki.openwrt.org/doc/howto/mmc_over_gpio) and you'll be fine.
>
> The latest releases have deprecated kmod-mmc-over-gpio in favor of
> just getting other generic $30 routers from AliExpress that have built
> in TF/MMC ports (generally RT5350), or AR9311 routers with USB e.g.
> TL-MR3020.
>
>
>
> On Fri, Jun 3, 2016 at 10:15 PM, Marco Castrovilli
> <marco.castrovilli at gmail.com> wrote:
>> thanks a lot for your immediate answer.
>> i followed this guide to mod fonera adding an sd card:
>> http://www.wifi-ita.com/index.php?option=com_content&task=view&id=223
>> and this one:
>> http://www.nabuk.org/f/index.php?topic=1486.0
>> everything is ok but i can't find 26215-4pinfon2100Driver7143.ipk anywere.
>> i'm on kamikaze 7.09 and kernel:
>> Linux Legend 2.6.22.1 #5 Mon Aug 13 18:18:07 EDT 2007 mips unknown
>>
>> i tried to update (with ipkg, not opkg) but i have problem with original
>> openwrt feed:
>> root at Legend:~# ipkg update
>> Downloading
>> http://downloads.openwrt.org/snapshots/atheros-2.6/packages/Packages
>> wget: server returned error: HTTP/1.1 404 Not Found
>> Downloading http://downloads.openwrt.org/kamikaze/packages/mips/Packages
>> wget: server returned error: HTTP/1.1 404 Not Found
>> Downloading
>> http://downloads.x-wrt.org/xwrt/kamikaze/snapshots/atheros-2.6/packages/Packages
>> wget: server returned error: HTTP/1.1 404 Not Found
>> An error ocurred, return value: 3.
>> Collected errors:
>> ipkg_download: ERROR: Command failed with return value 1: `wget
>> --passive-ftp    -q -P /tmp/ipkg-hCDHje
>> http://downloads.openwrt.org/snapshots/atheros-2.6/packages/Packages'
>> ipkg_download: ERROR: Command failed with return value 1: `wget
>> --passive-ftp    -q -P /tmp/ipkg-hCDHje
>> http://downloads.openwrt.org/kamikaze/packages/mips/Packages'
>> ipkg_download: ERROR: Command failed with return value 1: `wget
>> --passive-ftp    -q -P /tmp/ipkg-hCDHje
>> http://downloads.x-wrt.org/xwrt/kamikaze/snapshots/atheros-2.6/packages/Packages'
>> root at Legend:~#
>>
>> so i tried with other ones but:
>> root at Legend:~# ipkg update
>> Downloading
>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
>> wget: not an http or ftp url:
>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
>> Downloading
>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
>> wget: not an http or ftp url:
>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
>> Downloading
>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
>> wget: not an http or ftp url:
>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages
>> An error ocurred, return value: 3.
>> Collected errors:
>> ipkg_download: ERROR: Command failed with return value 1: `wget
>> --passive-ftp    -q -P /tmp/ipkg-nErUJo
>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages'
>> ipkg_download: ERROR: Command failed with return value 1: `wget
>> --passive-ftp    -q -P /tmp/ipkg-nErUJo
>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages'
>> ipkg_download: ERROR: Command failed with return value 1: `wget
>> --passive-ftp    -q -P /tmp/ipkg-nErUJo
>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages'
>> root at Legend:~#
>>
>> i got a more recent wget (wget_1.10.2-2_mips.ipk) but stil have problems
>> with ssl.
>> anyway, browsing manually feeds i can't find driver.
>>
>> perhaps i NEED to use kamikaze 8.09 and all troubles will run away?
>>
>> again many thanks Andrew for your interest: this is my last chance to use a
>> microSD on my fonera 2100 :)
>>
>>
>>
>> Il 03/06/2016 15:49, Andrew Yong ha scritto:
>>
>> https://wiki.openwrt.org/doc/hardware/port.gpio and see relevant sections
>> for bitbanging MMC over GPIO.
>>
>> On 3 Jun 2016 21:46, "Marco Castrovilli" <marco.castrovilli at gmail.com>
>> wrote:
>>> hi all!
>>> does anyone can help me to find mmc driver working on openwrt, installed
>>> on fonera 2100 (mips architectire)?
>>> thank you in advance.
>>>
>>> _______________________________________________
>>> Lede-dev mailing list
>>> Lede-dev at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>


From yszhou4tech at gmail.com  Fri Jun  3 21:49:04 2016
From: yszhou4tech at gmail.com (Yousong Zhou)
Date: Sat, 4 Jun 2016 12:49:04 +0800
Subject: [LEDE-DEV] ar71xx kernel size starts getting oversized
Message-ID: <CAECwjAi_6yZQevUOKB=A=___8gQnG3dELahEvDjvXysKGNNNPA@mail.gmail.com>

Several days ago I tried to build a firmware for HiWiFi-HC6361 with
LEDE master branch.  Yet the firmware was not present in
bin/targets/ar71xx/generic after the build completed.  I checked the
downloads.lede-project.org the firmware was also missing there.

The problem is that mtdparts layout of HC6361 requires the kernel part
to be not bigger than 1280KB (1310720 bytes).  Yet the lzma-compressed
kernel uImage has exceeded this size limit.

The current size of lede-ar71xx-generic-uImage-lzma.bin in
downloads.lede-project.org is 1367988

The corresponding file in OpenWrt downloads site are as follows

    snapshot         1295637
    15.05.1            1176662
    14.07               1107048

My device is currently running 4.1.16 with OpenWrt r48975.  So the
bloat probably comes from the 4.4 bump.  Sorry that at the moment I
can just bring the issue up and cannot find time to do further
investigation.

Regards

                yousong


From ardeleanalex at gmail.com  Sat Jun  4 03:40:53 2016
From: ardeleanalex at gmail.com (Alexandru Ardelean)
Date: Sat, 4 Jun 2016 13:40:53 +0300
Subject: [LEDE-DEV] [PATCH 1/3] [ubox] remove unnecessary size struct
 between messages
In-Reply-To: <57516996.5060603@conorogorman.net>
References: <1464951549-4152-1-git-send-email-danutbug@gmail.com>
 <57516996.5060603@conorogorman.net>
Message-ID: <CA+U=Dsq8zB09MiSLz2dKkgALbnP6KhR5iE29V4zUPBZtrr4U5A@mail.gmail.com>

On Fri, Jun 3, 2016 at 2:27 PM, Conor O'Gorman <i at conorogorman.net> wrote:
> On 03/06/16 11:59, Dan Bugnar wrote:
>>
>> From: Dan Bugnar <dnbugnar at ocedo.com>
>>
>> The next message needs to be written after the data of current message.
>> This was adding "sizeof(struct log_head)" bytes between messages.
>>
>> Signed-off-by: Dan Bugnar <danutbug at gmail.com>
>> ---
>>   log/syslog.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/log/syslog.c b/log/syslog.c
>> index e8b6774..2042e93 100644
>> --- a/log/syslog.c
>> +++ b/log/syslog.c
>> @@ -51,7 +51,7 @@ static regex_t pat_tstamp;
>>   static struct log_head*
>>   log_next(struct log_head *h, int size)
>>   {
>> -       struct log_head *n = (struct log_head *)
>> &h->data[PAD(sizeof(struct log_head) + size)];
>> +       struct log_head *n = (struct log_head *) &h->data[size];
>>
> You lost the PAD? Which is over the struct and size, not just the struct.
>
> Conor
>
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

hmm, what about moving the PAD() somewhere in the log_add() function ?
it would save some cycles, since, that's the only place where the size
would need to be adjusted for padding/alignment;
doing it in log_next(), can be a bit CPU expensive

as for the comment "Which is over the struct and size, not just the struct."
i am bit unclear;
apologies if i'll be too verbose (below)

this change is good (padding aside)
previously, the log_next() function would jump over "sizeof(struct
log_head) + PAD(sizeof(struct log_head) + size)"
the "data" field in the struct log_head is at the end of the struct
(offset sizeof(struct log_head) )
there should be no need to also jump "sizeof(struct log_head)"  in the
"data" field
basically, it would punch "sizeof(struct log_head)" holes (i think 20
bytes each) in the log buffer, between entries


From jonas.gorski at gmail.com  Sat Jun  4 03:48:44 2016
From: jonas.gorski at gmail.com (Jonas Gorski)
Date: Sat, 4 Jun 2016 12:48:44 +0200
Subject: [LEDE-DEV] Add info about git URLs in Lede Git Web
In-Reply-To: <882df163-e404-4f62-5c0e-6f617aaa394b@phrozen.org>
References: <1464874823.3047.45.camel@synopsys.com>
 <1464886922.2984.2.camel@kitschensync.net>
 <882df163-e404-4f62-5c0e-6f617aaa394b@phrozen.org>
Message-ID: <CAOiHx=m6OCKM3dayJ6=Zx2aO_amS1B_mf9N0t33bSfPn_wPmiw@mail.gmail.com>

On 2 June 2016 at 19:18, John Crispin <john at phrozen.org> wrote:
>
>
> On 02/06/2016 19:02, Ted Hess wrote:
>> Check it out now...
>>
>
> .... the funk soul brothers

Hm, it now advertises git protocol, but it isn't actually usable:

$ git clone git://git.lede-project.org/source.git
Cloning into 'source'...
fatal: unable to connect to git.lede-project.org:
git.lede-project.org[0: 188.40.166.7]: errno=Connection refused

Should be probably removed, or git:// allowed.


Jonas


From gareth41 at orcon.net.nz  Sat Jun  4 04:07:12 2016
From: gareth41 at orcon.net.nz (Gareth Parker)
Date: Sat, 4 Jun 2016 23:07:12 +1200
Subject: [LEDE-DEV] Adding support for Comfast CF-WR650AC
In-Reply-To: <e40ca44c-0d5c-01de-aadd-73f154704f51@mein.io>
References: <08be01d1b808$e8df9130$ba9eb390$@orcon.net.nz>
 <e40ca44c-0d5c-01de-aadd-73f154704f51@mein.io>
Message-ID: <000001d1be51$3f4f11f0$bded35d0$@orcon.net.nz>

I have found part of the cause of switch problem

It's related to this commit:
http://git.openwrt.org/?p=openwrt.git;a=commit;h=ef54bfd6c8c82e865dd2f6c80b3
78a0c0f772ffc

I tried to checkout parent commit and worked fine, any commits after this
one cause the router to hang then reboot on issuing "swconfig dev switch0
show".
I also tried reverting this commit in lede, editing file
"target/linux/generic/files/drivers/net/phy/ar8216.c" but still had the same
problem, so it looks there's something else also causing this problem in
lede.

If anyone wants to have a look at this, I can give you remote access to a
linux box with serial console to router.


Here is what I get:

root at OpenWrt:/# swconfig dev switch0 show
Global attributes:
        enable_vlan: 1
        enable_mirror_rx: 0
        enable_mirror_tx: 0
        mirror_monitor_port: 0
        mirror_source_port: 0

and it locks up there for approximately 5 seconds before router reboots, I'm
assuming the watchdog timer is forcing the reboot.  There's no other console
output that shows up.


Gareth



-----Original Message-----
From: Lede-dev [mailto:lede-dev-bounces at lists.infradead.org] On Behalf Of
Jo-Philipp Wich
Sent: Monday, 30 May 2016 1:09 a.m.
To: lede-dev at lists.infradead.org
Subject: Re: [LEDE-DEV] Adding support for Comfast CF-WR650AC

Hi Gareth,

the CC patch you linked looks reasonably clean so I can't spot immediate
reasons that would prevent it from getting included into LEDE.

I suggest that you fork https://github.com/lede-project/source and integrate
the required changes into your clone, then open a PR based on it. You can of
course use git-send-email and patches too if you prefer that.

If you need help porting certain changes to master let me know, a few things
surrounding image building and default config changed compared to CC.

Regards,
Jo

_______________________________________________
Lede-dev mailing list
Lede-dev at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev



From daniel at makrotopia.org  Sat Jun  4 05:41:06 2016
From: daniel at makrotopia.org (Daniel Golle)
Date: Sat, 4 Jun 2016 14:41:06 +0200
Subject: [LEDE-DEV] ar71xx kernel size starts getting oversized
In-Reply-To: <CAECwjAi_6yZQevUOKB=A=___8gQnG3dELahEvDjvXysKGNNNPA@mail.gmail.com>
References: <CAECwjAi_6yZQevUOKB=A=___8gQnG3dELahEvDjvXysKGNNNPA@mail.gmail.com>
Message-ID: <20160604124105.GB1892@makrotopia.org>

Hi Yousong,

the main issue on ar71xx is the high number of mach-*.c files for all
the boards being included in *all* images. Once the target has been
migrated to device tree (which is a huge amount of work, lynxis has
done major progress there), this should easily free 500 kB of the
uncompressed kernel image.

Cheers

Daniel

On Sat, Jun 04, 2016 at 12:49:04PM +0800, Yousong Zhou wrote:
> Several days ago I tried to build a firmware for HiWiFi-HC6361 with
> LEDE master branch.  Yet the firmware was not present in
> bin/targets/ar71xx/generic after the build completed.  I checked the
> downloads.lede-project.org the firmware was also missing there.
> 
> The problem is that mtdparts layout of HC6361 requires the kernel part
> to be not bigger than 1280KB (1310720 bytes).  Yet the lzma-compressed
> kernel uImage has exceeded this size limit.
> 
> The current size of lede-ar71xx-generic-uImage-lzma.bin in
> downloads.lede-project.org is 1367988
> 
> The corresponding file in OpenWrt downloads site are as follows
> 
>     snapshot         1295637
>     15.05.1            1176662
>     14.07               1107048
> 
> My device is currently running 4.1.16 with OpenWrt r48975.  So the
> bloat probably comes from the 4.4 bump.  Sorry that at the moment I
> can just bring the issue up and cannot find time to do further
> investigation.
> 
> Regards
> 
>                 yousong
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


From yszhou4tech at gmail.com  Sat Jun  4 07:15:43 2016
From: yszhou4tech at gmail.com (Yousong Zhou)
Date: Sat, 4 Jun 2016 22:15:43 +0800
Subject: [LEDE-DEV] ar71xx kernel size starts getting oversized
In-Reply-To: <20160604124105.GB1892@makrotopia.org>
References: <CAECwjAi_6yZQevUOKB=A=___8gQnG3dELahEvDjvXysKGNNNPA@mail.gmail.com>
 <20160604124105.GB1892@makrotopia.org>
Message-ID: <CAECwjAiGboOb2Z8exJ_toAAY-dmMDh9OYWt9XiT2x4ybZqPiLA@mail.gmail.com>

On 04/06/2016, Daniel Golle <daniel at makrotopia.org> wrote:
> Hi Yousong,
>
> the main issue on ar71xx is the high number of mach-*.c files for all
> the boards being included in *all* images. Once the target has been
> migrated to device tree (which is a huge amount of work, lynxis has
> done major progress there), this should easily free 500 kB of the
> uncompressed kernel image.

The lzma-compressed size has increased by more than 200KB.  I dont
think it is caused by those mach files.

It has been quite a while since I tried building ar71xx kernel by
deleting unneeded mach files first.  I believe the size reduction was
not so impressive that I do not remember them at all...

Cheers
                yousong

>
> Cheers
>
> Daniel
>
> On Sat, Jun 04, 2016 at 12:49:04PM +0800, Yousong Zhou wrote:
>> Several days ago I tried to build a firmware for HiWiFi-HC6361 with
>> LEDE master branch.  Yet the firmware was not present in
>> bin/targets/ar71xx/generic after the build completed.  I checked the
>> downloads.lede-project.org the firmware was also missing there.
>>
>> The problem is that mtdparts layout of HC6361 requires the kernel part
>> to be not bigger than 1280KB (1310720 bytes).  Yet the lzma-compressed
>> kernel uImage has exceeded this size limit.
>>
>> The current size of lede-ar71xx-generic-uImage-lzma.bin in
>> downloads.lede-project.org is 1367988
>>
>> The corresponding file in OpenWrt downloads site are as follows
>>
>>     snapshot         1295637
>>     15.05.1            1176662
>>     14.07               1107048
>>
>> My device is currently running 4.1.16 with OpenWrt r48975.  So the
>> bloat probably comes from the 4.4 bump.  Sorry that at the moment I
>> can just bring the issue up and cannot find time to do further
>> investigation.
>>
>> Regards
>>
>>                 yousong
>>
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
>


-- 
                yousong


From p.wassi at gmx.at  Sat Jun  4 07:17:06 2016
From: p.wassi at gmx.at (p.wassi at gmx.at)
Date: Sat, 4 Jun 2016 16:17:06 +0200
Subject: [LEDE-DEV] Issues on brcm47xx, Buildbot config
Message-ID: <trinity-d03df1ff-d176-40c6-a1cf-05f6b1d8f11e-1465049826542@3capp-gmx-bs36>

Related to my last post to the list "brcm47xx legacy broken in trunk?"

I'm not sure whether "legacy broken in trunk" is the right terminology.
When I started to dig into the problem, I cloned the repo and built the
image myself. It worked immediately.

To confirm my findings, I downloaded today's current trunk again. These images
still DO NOT BOOT on WRT54G(L).

The only settings I change in "make menuconfig" for the new image:
-) Target System = Broadcom BCM47xx/53xx (MIPS)
-) Subtarget = Legacy (BMIPS3300)
A built image with these settings works perfectly fine:
> Loader:raw Filesys:raw Dev:flash0.os File: Options:(null)
> Loading: .. 3800 bytes read
> Entry at 0x80001000
> Closing network.
> Starting program at 0x80001000
> [    0.000000] Linux version 4.1.20 (openwrt at debian-compiler) (gcc version 5.3.0 (LEDE GCC 5.3.0 r482) ) #4 Sat Jun 4 10:01:44 UTC 2016
> [    0.000000] CPU0 revision is: 00029008 (Broadcom BMIPS3300)
> [    0.000000] bcm47xx: Using ssb bus
> [    0.000000] ssb: Found chip with id 0x5352, rev 0x00 and package 0x02
> [    0.000000] ssb: Sonics Silicon Backplane found at address 0x18000000
> (...)

So I assume, some configuration the buildbot is using, makes the images
unusable for WRT54G(L)

Best regards,
P.Wassi


From mschiffer at universe-factory.net  Sat Jun  4 08:27:03 2016
From: mschiffer at universe-factory.net (Matthias Schiffer)
Date: Sat, 4 Jun 2016 17:27:03 +0200
Subject: [LEDE-DEV] [OpenWrt-Devel] [PATCH libubox] blobmsg_json: add
 new functions blobmsg_format_json_value*
In-Reply-To: <A597E23F-9BF7-4C47-8F36-AA527F32E669@gmail.com>
References: <dbc90f6d05a606753e2576bd6fc3569c5958885a.1464812878.git.mschiffer@universe-factory.net>
 <e63ded11-8ba8-c0da-78ee-a5be70eca1fd@phrozen.org>
 <02fc8e5d-d737-58b0-e712-d0b9ebf58f9e@universe-factory.net>
 <A597E23F-9BF7-4C47-8F36-AA527F32E669@gmail.com>
Message-ID: <72d43356-1b13-6c1d-ef64-2b116705f6f9@universe-factory.net>

On 06/03/2016 04:55 PM, Eyal Birger wrote:
> 
> Hi,
> 
>> On 3 Jun 2016, at 13:11, Matthias Schiffer <mschiffer at universe-factory.net> wrote:
>>
> (snip)
>>
>> 1) and 2) would allow blobmsg to store everything that json-c can (with the
>> caveat that json-c stores integers as int64 internally, while blobmsg_json
>> uses int32) -
> 
> We also noticed this as a problem for us since when converting json strings to blobmsg, integers become signed and thus no more than INT32_MAX can be used.
> 
> Do you plans to approach this in your patchsets?
> 
> Eyal

I don't think this can be fixed easily without having to adjust all
blobmsg_json users, as the blobmsg_policy entries contain
BLOBMSG_TYPE_INT32 everywhere. I don't know how much the ubus methods are
considered unchangeable ABI.

Possible approaches include:

1) Always map JSON intergers to int64. Will cause an incompatible ABI
change for all ubus calls when used with blobmsg_json.

2) Add new blobmsg_add_json_* functions which use int64. The caller of a
ubus method would need to know if the service excepts int32 or int64
integers, making this more or less unusable for the ubus CLI tool

3) Adjust blobmsg_add_json_* to encode integers as int32 or int64 depending
on the value itself. We'd need to extend the blobmsg_policy with some kind
of BLOBMSG_TYPE_INT which accepts both int32 and int64, and add a
blobmsg_get_int function that can work with different lengths. Existing
software would continue to work as long as the supplied values fit into an
int32.

4) Introduce a new BLOBMSG_TYPE_INT type for variable-length integers,
together with a blobmsg_get_int function (note that, in contrast to 3),
BLOBMSG_TYPE_INT is a real blobmsg type in this approach). The length of
records is encoded in the blobmsg format already. Again, this approach
would need all software to be adjusted.

1) and 4) are very similar and would cause a hard ABI break for many ubus
methods. If we want to avoid a flagday change, 3) seems like the best
option - or some other approach I haven't listed?

Matthias


> 
>> do you think these changes make sense?
>>
>> Would there also be general interest in 3), so it might be integrated into
>> libubox?
>>
>> Regards,
>> Matthias
>>
>>
>>>
>>>>
>>>> Signed-off-by: Matthias Schiffer <mschiffer at universe-factory.net>
>>>> ---
>>>> blobmsg_json.c | 49 ++++++++++++++++++++++++++++++++++++-------------
>>>> blobmsg_json.h | 14 ++++++++++++++
>>>> 2 files changed, 50 insertions(+), 13 deletions(-)
>>>>
>>>> diff --git a/blobmsg_json.c b/blobmsg_json.c
>>>> index 5713948..538c816 100644
>>>> --- a/blobmsg_json.c
>>>> +++ b/blobmsg_json.c
>>>> @@ -207,7 +207,7 @@ static void blobmsg_format_string(struct strbuf *s, const char *str)
>>>>
>>>> static void blobmsg_format_json_list(struct strbuf *s, struct blob_attr *attr, int len, bool array);
>>>>
>>>> -static void blobmsg_format_element(struct strbuf *s, struct blob_attr *attr, bool array, bool head)
>>>> +static void blobmsg_format_element(struct strbuf *s, struct blob_attr *attr, bool without_name, bool head)
>>>> {
>>>>    const char *data_str;
>>>>    char buf[32];
>>>> @@ -217,7 +217,7 @@ static void blobmsg_format_element(struct strbuf *s, struct blob_attr *attr, boo
>>>>    if (!blobmsg_check_attr(attr, false))
>>>>        return;
>>>>
>>>> -    if (!array && blobmsg_name(attr)[0]) {
>>>> +    if (!without_name && blobmsg_name(attr)[0]) {
>>>>        blobmsg_format_string(s, blobmsg_name(attr));
>>>>        blobmsg_puts(s, ": ", s->indent ? 2 : 1);
>>>>    }
>>>> @@ -286,22 +286,26 @@ static void blobmsg_format_json_list(struct strbuf *s, struct blob_attr *attr, i
>>>>    blobmsg_puts(s, (array ? "]" : "}"), 1);
>>>> }
>>>>
>>>> +static void setup_strbuf(struct strbuf *s, struct blob_attr *attr, blobmsg_json_format_t cb, void *priv, int indent) {
>>>> +    s->len = blob_len(attr);
>>>> +    s->buf = malloc(s->len);
>>>> +    s->pos = 0;
>>>> +    s->custom_format = cb;
>>>> +    s->priv = priv;
>>>> +    s->indent = false;
>>>> +
>>>> +    if (indent >= 0) {
>>>> +        s->indent = true;
>>>> +        s->indent_level = indent;
>>>> +    }
>>>> +}
>>>> +
>>>> char *blobmsg_format_json_with_cb(struct blob_attr *attr, bool list, blobmsg_json_format_t cb, void *priv, int indent)
>>>> {
>>>>    struct strbuf s;
>>>>    bool array;
>>>>
>>>> -    s.len = blob_len(attr);
>>>> -    s.buf = malloc(s.len);
>>>> -    s.pos = 0;
>>>> -    s.custom_format = cb;
>>>> -    s.priv = priv;
>>>> -    s.indent = false;
>>>> -
>>>> -    if (indent >= 0) {
>>>> -        s.indent = true;
>>>> -        s.indent_level = indent;
>>>> -    }
>>>> +    setup_strbuf(&s, attr, cb, priv, indent);
>>>>
>>>>    array = blob_is_extended(attr) &&
>>>>        blobmsg_type(attr) == BLOBMSG_TYPE_ARRAY;
>>>> @@ -321,3 +325,22 @@ char *blobmsg_format_json_with_cb(struct blob_attr *attr, bool list, blobmsg_jso
>>>>
>>>>    return s.buf;
>>>> }
>>>> +
>>>> +char *blobmsg_format_json_value_with_cb(struct blob_attr *attr, blobmsg_json_format_t cb, void *priv, int indent)
>>>> +{
>>>> +    struct strbuf s;
>>>> +
>>>> +    setup_strbuf(&s, attr, cb, priv, indent);
>>>> +
>>>> +    blobmsg_format_element(&s, attr, true, false);
>>>> +
>>>> +    if (!s.len) {
>>>> +        free(s.buf);
>>>> +        return NULL;
>>>> +    }
>>>> +
>>>> +    s.buf = realloc(s.buf, s.pos + 1);
>>>> +    s.buf[s.pos] = 0;
>>>> +
>>>> +    return s.buf;
>>>> +}
>>>> diff --git a/blobmsg_json.h b/blobmsg_json.h
>>>> index cd9ed33..9dfc02d 100644
>>>> --- a/blobmsg_json.h
>>>> +++ b/blobmsg_json.h
>>>> @@ -42,4 +42,18 @@ static inline char *blobmsg_format_json_indent(struct blob_attr *attr, bool list
>>>>    return blobmsg_format_json_with_cb(attr, list, NULL, NULL, indent);
>>>> }
>>>>
>>>> +char *blobmsg_format_json_value_with_cb(struct blob_attr *attr,
>>>> +                    blobmsg_json_format_t cb, void *priv,
>>>> +                    int indent);
>>>> +
>>>> +static inline char *blobmsg_format_json_value(struct blob_attr *attr)
>>>> +{
>>>> +    return blobmsg_format_json_value_with_cb(attr, NULL, NULL, -1);
>>>> +}
>>>> +
>>>> +static inline char *blobmsg_format_json_value_indent(struct blob_attr *attr, int indent)
>>>> +{
>>>> +    return blobmsg_format_json_value_with_cb(attr, NULL, NULL, indent);
>>>> +}
>>>> +
>>>> #endif
>>
>>
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel at lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20160604/6282a963/attachment.sig>

From lede at kitschensync.net  Sat Jun  4 08:40:58 2016
From: lede at kitschensync.net (Ted Hess)
Date: Sat, 04 Jun 2016 11:40:58 -0400
Subject: [LEDE-DEV] Add info about git URLs in Lede Git Web
In-Reply-To: <CAOiHx=m6OCKM3dayJ6=Zx2aO_amS1B_mf9N0t33bSfPn_wPmiw@mail.gmail.com>
References: <1464874823.3047.45.camel@synopsys.com>
 <1464886922.2984.2.camel@kitschensync.net>
 <882df163-e404-4f62-5c0e-6f617aaa394b@phrozen.org>
 <CAOiHx=m6OCKM3dayJ6=Zx2aO_amS1B_mf9N0t33bSfPn_wPmiw@mail.gmail.com>
Message-ID: <1465054858.3634.2.camel@kitschensync.net>

On Sat, 2016-06-04 at 12:48 +0200, Jonas Gorski wrote:
> On 2 June 2016 at 19:18, John Crispin <john at phrozen.org> wrote:
> > 
> > 
> > 
> > On 02/06/2016 19:02, Ted Hess wrote:
> > > 
> > > Check it out now...
> > > 
> > .... the funk soul brothers
> Hm, it now advertises git protocol, but it isn't actually usable:
> 
> $ git clone git://git.lede-project.org/source.git
> Cloning into 'source'...
> fatal: unable to connect to git.lede-project.org:
> git.lede-project.org[0: 188.40.166.7]: errno=Connection refused
> 
> Should be probably removed, or git:// allowed.
> 
> 
> Jonas
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

Forgot to 'enable' git-daemon -- OK now.

/ted


From dirkneukirchen at web.de  Sat Jun  4 09:34:02 2016
From: dirkneukirchen at web.de (Dirk Neukirchen)
Date: Sat,  4 Jun 2016 18:34:02 +0200
Subject: [LEDE-DEV] [PATCH] modules: add BMP085 pressure sensor
Message-ID: <20160604163402.2352-1-dirkneukirchen@web.de>

add BMP085 and BMP180 pressure sensors
this driver supports the SPI and I2C and
older chips (BMP280 is supported by iio subsystem)

issue found when cleaning up omap/config

found while writing this patch that a
similar patch was submitted in June/July 2014 but not integrated

only compile tested

Signed-off-by: Dirk Neukirchen <dirkneukirchen at web.de>
---
 package/kernel/linux/modules/other.mk | 48 +++++++++++++++++++++++++++++++++++
 1 file changed, 48 insertions(+)

diff --git a/package/kernel/linux/modules/other.mk b/package/kernel/linux/modules/other.mk
index 11d836e..bc7fb7c 100644
--- a/package/kernel/linux/modules/other.mk
+++ b/package/kernel/linux/modules/other.mk
@@ -990,3 +990,51 @@ define KernelPackage/echo/description
 endef
 
 $(eval $(call KernelPackage,echo))
+
+
+define KernelPackage/bmp085
+  SUBMENU:=$(OTHER_MENU)
+  TITLE:=BMP085/BMP18x pressure sensor
+  DEPENDS:= +kmod-regmap
+  KCONFIG:= CONFIG_BMP085
+  FILES:= $(LINUX_DIR)/drivers/misc/bmp085.ko
+endef
+
+define KernelPackage/bmp085/description
+ This driver adds support for Bosch Sensortec's digital pressure
+ sensors BMP085 and BMP18x.
+endef
+
+$(eval $(call KernelPackage,bmp085))
+
+
+define KernelPackage/bmp085-i2c
+  SUBMENU:=$(OTHER_MENU)
+  TITLE:=BMP085/BMP18x pressure sensor I2C
+  DEPENDS:= +kmod-bmp085
+  KCONFIG:= CONFIG_BMP085_I2C
+  FILES:= $(LINUX_DIR)/drivers/misc/bmp085-i2c.ko
+  AUTOLOAD:=$(call AutoProbe,bmp085-i2c)
+endef
+define KernelPackage/bmp085-i2c/description
+ This driver adds support for Bosch Sensortec's digital pressure
+ sensor connected via I2C.
+endef
+
+$(eval $(call KernelPackage,bmp085-i2c))
+
+
+define KernelPackage/bmp085-spi
+  SUBMENU:=$(OTHER_MENU)
+  TITLE:=BMP085/BMP18x pressure sensor SPI
+  DEPENDS:= +kmod-bmp085
+  KCONFIG:= CONFIG_BMP085_SPI
+  FILES:= $(LINUX_DIR)/drivers/misc/bmp085-spi.ko
+  AUTOLOAD:=$(call AutoProbe,bm085-spi)
+endef
+define KernelPackage/bmp085-spi/description
+ This driver adds support for Bosch Sensortec's digital pressure
+ sensor connected via SPI.
+endef
+
+$(eval $(call KernelPackage,bmp085-spi))
-- 
2.8.3



From dirkneukirchen at web.de  Sat Jun  4 09:34:09 2016
From: dirkneukirchen at web.de (Dirk Neukirchen)
Date: Sat,  4 Jun 2016 18:34:09 +0200
Subject: [LEDE-DEV] [PATCH] omap: remove BMP085 symbol
Message-ID: <20160604163409.2435-1-dirkneukirchen@web.de>

BMP085 is a pressure sensor and available as module

Signed-off-by: Dirk Neukirchen <dirkneukirchen at web.de>
---
 target/linux/omap/config-4.4 | 2 --
 1 file changed, 2 deletions(-)

diff --git a/target/linux/omap/config-4.4 b/target/linux/omap/config-4.4
index a483ab2..b4f4e53 100644
--- a/target/linux/omap/config-4.4
+++ b/target/linux/omap/config-4.4
@@ -69,8 +69,6 @@ CONFIG_BLK_DEV_RAM=y
 CONFIG_BLK_DEV_RAM_COUNT=16
 CONFIG_BLK_DEV_RAM_SIZE=16384
 CONFIG_BLK_DEV_SD=y
-CONFIG_BMP085=y
-CONFIG_BMP085_I2C=y
 CONFIG_BOUNCE=y
 CONFIG_BSD_PROCESS_ACCT=y
 CONFIG_BUILD_BIN2C=y
-- 
2.8.3



From dirkneukirchen at web.de  Sat Jun  4 09:34:16 2016
From: dirkneukirchen at web.de (Dirk Neukirchen)
Date: Sat,  4 Jun 2016 18:34:16 +0200
Subject: [LEDE-DEV] [PATCH] omap: remove config symbol NETFILTER
Message-ID: <20160604163416.2487-1-dirkneukirchen@web.de>

Signed-off-by: Dirk Neukirchen <dirkneukirchen at web.de>
---
 target/linux/omap/config-4.4 | 1 -
 1 file changed, 1 deletion(-)

diff --git a/target/linux/omap/config-4.4 b/target/linux/omap/config-4.4
index b4f4e53..5bc619d 100644
--- a/target/linux/omap/config-4.4
+++ b/target/linux/omap/config-4.4
@@ -387,7 +387,6 @@ CONFIG_NAMESPACES=y
 CONFIG_NEED_DMA_MAP_STATE=y
 CONFIG_NEED_PER_CPU_KM=y
 CONFIG_NEON=y
-CONFIG_NETFILTER=y
 # CONFIG_NET_CADENCE is not set
 CONFIG_NET_KEY=y
 CONFIG_NET_KEY_MIGRATE=y
-- 
2.8.3



From dirkneukirchen at web.de  Sat Jun  4 09:35:02 2016
From: dirkneukirchen at web.de (Dirk Neukirchen)
Date: Sat,  4 Jun 2016 18:35:02 +0200
Subject: [LEDE-DEV] [PATCH] omap: remove config symbol W1
Message-ID: <20160604163502.2715-1-dirkneukirchen@web.de>

it is available as module

Signed-off-by: Dirk Neukirchen <dirkneukirchen at web.de>
---
 target/linux/omap/config-4.4 | 1 -
 1 file changed, 1 deletion(-)

diff --git a/target/linux/omap/config-4.4 b/target/linux/omap/config-4.4
index 5bc619d..3d33b0c 100644
--- a/target/linux/omap/config-4.4
+++ b/target/linux/omap/config-4.4
@@ -667,7 +667,6 @@ CONFIG_VFAT_FS=y
 CONFIG_VFP=y
 CONFIG_VFPv3=y
 CONFIG_VIDEOMODE_HELPERS=y
-CONFIG_W1=y
 CONFIG_WATCHDOG_CORE=y
 # CONFIG_WKUP_M3_RPROC is not set
 CONFIG_XFRM_ALGO=y
-- 
2.8.3



From dirkneukirchen at web.de  Sat Jun  4 09:35:09 2016
From: dirkneukirchen at web.de (Dirk Neukirchen)
Date: Sat,  4 Jun 2016 18:35:09 +0200
Subject: [LEDE-DEV] [PATCH] omap: remove XFRM config symbols
Message-ID: <20160604163509.2798-1-dirkneukirchen@web.de>

Signed-off-by: Dirk Neukirchen <dirkneukirchen at web.de>
---
 target/linux/omap/config-4.4 | 2 --
 1 file changed, 2 deletions(-)

diff --git a/target/linux/omap/config-4.4 b/target/linux/omap/config-4.4
index 3d33b0c..82b8ca7 100644
--- a/target/linux/omap/config-4.4
+++ b/target/linux/omap/config-4.4
@@ -669,8 +669,6 @@ CONFIG_VFPv3=y
 CONFIG_VIDEOMODE_HELPERS=y
 CONFIG_WATCHDOG_CORE=y
 # CONFIG_WKUP_M3_RPROC is not set
-CONFIG_XFRM_ALGO=y
-CONFIG_XFRM_MIGRATE=y
 CONFIG_ZBOOT_ROM_BSS=0x0
 CONFIG_ZBOOT_ROM_TEXT=0x0
 CONFIG_ZLIB_DEFLATE=y
-- 
2.8.3



From dirkneukirchen at web.de  Sat Jun  4 09:35:19 2016
From: dirkneukirchen at web.de (Dirk Neukirchen)
Date: Sat,  4 Jun 2016 18:35:19 +0200
Subject: [LEDE-DEV] [PATCH] modules: add missing module to ipsec description
Message-ID: <20160604163519.2881-1-dirkneukirchen@web.de>

Signed-off-by: Dirk Neukirchen <dirkneukirchen at web.de>
---
 package/kernel/linux/modules/netsupport.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/kernel/linux/modules/netsupport.mk b/package/kernel/linux/modules/netsupport.mk
index 09fa595..24f1e27 100644
--- a/package/kernel/linux/modules/netsupport.mk
+++ b/package/kernel/linux/modules/netsupport.mk
@@ -300,6 +300,7 @@ define KernelPackage/ipsec/description
  Kernel modules for IPsec support in both IPv4 and IPv6.
  Includes:
  - af_key
+ - xfrm_algo
  - xfrm_ipcomp
  - xfrm_user
 endef
-- 
2.8.3



From dirkneukirchen at web.de  Sat Jun  4 09:35:27 2016
From: dirkneukirchen at web.de (Dirk Neukirchen)
Date: Sat,  4 Jun 2016 18:35:27 +0200
Subject: [LEDE-DEV] [PATCH] sunxi: remove XFRM_ config symbols
Message-ID: <20160604163527.2939-1-dirkneukirchen@web.de>

they are part of packages

Signed-off-by: Dirk Neukirchen <dirkneukirchen at web.de>
---
 target/linux/sunxi/config-4.4 | 2 --
 1 file changed, 2 deletions(-)

diff --git a/target/linux/sunxi/config-4.4 b/target/linux/sunxi/config-4.4
index 4050494..4784efb 100644
--- a/target/linux/sunxi/config-4.4
+++ b/target/linux/sunxi/config-4.4
@@ -492,8 +492,6 @@ CONFIG_VT_CONSOLE_SLEEP=y
 CONFIG_VT_HW_CONSOLE_BINDING=y
 CONFIG_WATCHDOG_CORE=y
 # CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set
-CONFIG_XFRM_ALGO=y
-CONFIG_XFRM_USER=y
 CONFIG_XPS=y
 CONFIG_XZ_DEC_ARM=y
 CONFIG_XZ_DEC_BCJ=y
-- 
2.8.3



From dirkneukirchen at web.de  Sat Jun  4 09:35:34 2016
From: dirkneukirchen at web.de (Dirk Neukirchen)
Date: Sat,  4 Jun 2016 18:35:34 +0200
Subject: [LEDE-DEV] [PATCH] oxnas: remove unneeded _DIAG symbols
Message-ID: <20160604163534.3022-1-dirkneukirchen@web.de>

Signed-off-by: Dirk Neukirchen <dirkneukirchen at web.de>
---
 target/linux/oxnas/config-4.4 | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/target/linux/oxnas/config-4.4 b/target/linux/oxnas/config-4.4
index 07ce8b2..23b20de 100644
--- a/target/linux/oxnas/config-4.4
+++ b/target/linux/oxnas/config-4.4
@@ -192,9 +192,6 @@ CONFIG_I2C=y
 CONFIG_I2C_ALGOBIT=y
 CONFIG_I2C_BOARDINFO=y
 CONFIG_ICPLUS_PHY=y
-CONFIG_INET_DIAG=y
-CONFIG_INET_TCP_DIAG=y
-CONFIG_INET_UDP_DIAG=y
 CONFIG_INPUT=y
 # CONFIG_INPUT_MISC is not set
 CONFIG_IOMMU_API=y
@@ -286,7 +283,6 @@ CONFIG_OF_PCI_IRQ=y
 CONFIG_OF_RESERVED_MEM=y
 CONFIG_OLD_SIGACTION=y
 CONFIG_OLD_SIGSUSPEND3=y
-CONFIG_PACKET_DIAG=y
 CONFIG_PAGE_OFFSET=0xC0000000
 CONFIG_PCI=y
 CONFIG_PCIEAER=y
@@ -346,7 +342,6 @@ CONFIG_SERIAL_OF_PLATFORM=y
 # CONFIG_SG_SPLIT is not set
 CONFIG_SMP=y
 CONFIG_SMP_ON_UP=y
-CONFIG_SOCK_DIAG=y
 CONFIG_SRCU=y
 CONFIG_STMMAC_ETH=y
 CONFIG_STMMAC_PLATFORM=y
-- 
2.8.3



From dirkneukirchen at web.de  Sat Jun  4 09:35:41 2016
From: dirkneukirchen at web.de (Dirk Neukirchen)
Date: Sat,  4 Jun 2016 18:35:41 +0200
Subject: [LEDE-DEV] [PATCH] zynq: remove unneeded _DIAG and _XFRM symbols
Message-ID: <20160604163541.3105-1-dirkneukirchen@web.de>

Signed-off-by: Dirk Neukirchen <dirkneukirchen at web.de>
---
 target/linux/zynq/config-4.4 | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/target/linux/zynq/config-4.4 b/target/linux/zynq/config-4.4
index ea28550..f8e080d 100644
--- a/target/linux/zynq/config-4.4
+++ b/target/linux/zynq/config-4.4
@@ -360,12 +360,6 @@ CONFIG_IIO_TRIGGER=y
 CONFIG_IIO_TRIGGERED_BUFFER=y
 CONFIG_IKCONFIG=y
 CONFIG_IKCONFIG_PROC=y
-CONFIG_INET_DIAG=y
-CONFIG_INET_LRO=y
-CONFIG_INET_TCP_DIAG=y
-CONFIG_INET_XFRM_MODE_BEET=y
-CONFIG_INET_XFRM_MODE_TRANSPORT=y
-CONFIG_INET_XFRM_MODE_TUNNEL=y
 CONFIG_INITRAMFS_SOURCE=""
 CONFIG_INPUT=y
 CONFIG_INPUT_EVDEV=y
@@ -625,7 +619,6 @@ CONFIG_SND_SOC_GENERIC_DMAENGINE_PCM=y
 CONFIG_SND_SOC_I2C_AND_SPI=y
 CONFIG_SND_SPI=y
 CONFIG_SND_SUPPORT_OLD_API=y
-CONFIG_SOCK_DIAG=y
 CONFIG_SOC_BUS=y
 CONFIG_SOUND=y
 CONFIG_SPARSE_IRQ=y
-- 
2.8.3



From dirkneukirchen at web.de  Sat Jun  4 09:35:52 2016
From: dirkneukirchen at web.de (Dirk Neukirchen)
Date: Sat,  4 Jun 2016 18:35:52 +0200
Subject: [LEDE-DEV] [PATCH] mpc85xx: remove unneeded symbols
Message-ID: <20160604163552.3188-1-dirkneukirchen@web.de>

Signed-off-by: Dirk Neukirchen <dirkneukirchen at web.de>
---
 target/linux/mpc85xx/config-4.4 | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/target/linux/mpc85xx/config-4.4 b/target/linux/mpc85xx/config-4.4
index 5b76ec5..90bde4f 100644
--- a/target/linux/mpc85xx/config-4.4
+++ b/target/linux/mpc85xx/config-4.4
@@ -132,8 +132,6 @@ CONFIG_HZ=250
 # CONFIG_HZ_100 is not set
 CONFIG_HZ_250=y
 CONFIG_HZ_PERIODIC=y
-CONFIG_INET_DIAG=y
-CONFIG_INET_TCP_DIAG=y
 CONFIG_INITRAMFS_SOURCE=""
 CONFIG_IOMMU_HELPER=y
 # CONFIG_IPIC is not set
@@ -270,7 +268,6 @@ CONFIG_SERIAL_8250_SHARE_IRQ=y
 CONFIG_SERIAL_OF_PLATFORM=y
 # CONFIG_SERIAL_QE is not set
 CONFIG_SIMPLE_GPIO=y
-CONFIG_SOCK_DIAG=y
 # CONFIG_SOCRATES is not set
 CONFIG_SPARSE_IRQ=y
 CONFIG_SPE=y
-- 
2.8.3



From dirkneukirchen at web.de  Sat Jun  4 09:36:07 2016
From: dirkneukirchen at web.de (Dirk Neukirchen)
Date: Sat,  4 Jun 2016 18:36:07 +0200
Subject: [LEDE-DEV] [PATCH] malta: remove unneeded symbols
Message-ID: <20160604163607.3474-1-dirkneukirchen@web.de>

Signed-off-by: Dirk Neukirchen <dirkneukirchen at web.de>
---
 target/linux/malta/config-4.4 | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/target/linux/malta/config-4.4 b/target/linux/malta/config-4.4
index 7bcfaea..b19c9f2 100644
--- a/target/linux/malta/config-4.4
+++ b/target/linux/malta/config-4.4
@@ -139,8 +139,6 @@ CONFIG_HW_HAS_PCI=y
 CONFIG_I8253=y
 CONFIG_I8253_LOCK=y
 CONFIG_I8259=y
-CONFIG_INET_DIAG=y
-CONFIG_INET_TCP_DIAG=y
 CONFIG_INPUT=y
 # CONFIG_INPUT_MISC is not set
 CONFIG_INPUT_MOUSEDEV=y
@@ -258,7 +256,6 @@ CONFIG_SERIO=y
 CONFIG_SERIO_SERPORT=y
 CONFIG_SMP=y
 CONFIG_SMP_UP=y
-CONFIG_SOCK_DIAG=y
 CONFIG_SRCU=y
 # CONFIG_STAGING is not set
 # CONFIG_SUNXI_SRAM is not set
-- 
2.8.3



From dirkneukirchen at web.de  Sat Jun  4 09:36:13 2016
From: dirkneukirchen at web.de (Dirk Neukirchen)
Date: Sat,  4 Jun 2016 18:36:13 +0200
Subject: [LEDE-DEV] [PATCH] malta: remove NAMESPACES config symbols
Message-ID: <20160604163613.3560-1-dirkneukirchen@web.de>

they are available in config/Config-kernel.in

Signed-off-by: Dirk Neukirchen <dirkneukirchen at web.de>
---
 target/linux/malta/config-4.4 | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/target/linux/malta/config-4.4 b/target/linux/malta/config-4.4
index b19c9f2..c20073b 100644
--- a/target/linux/malta/config-4.4
+++ b/target/linux/malta/config-4.4
@@ -145,7 +145,6 @@ CONFIG_INPUT_MOUSEDEV=y
 CONFIG_INPUT_MOUSEDEV_PSAUX=y
 CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
-CONFIG_IPC_NS=y
 # CONFIG_IP_MROUTE is not set
 CONFIG_IRQCHIP=y
 CONFIG_IRQ_DOMAIN=y
@@ -201,10 +200,8 @@ CONFIG_MODULE_FORCE_UNLOAD=y
 CONFIG_MTD_CFI_STAA=y
 # CONFIG_MTD_COMPLEX_MAPPINGS is not set
 CONFIG_MTD_PHYSMAP=y
-CONFIG_NAMESPACES=y
 CONFIG_NEED_DMA_MAP_STATE=y
 CONFIG_NET_FLOW_LIMIT=y
-# CONFIG_NET_NS is not set
 CONFIG_NO_GENERIC_PCI_IOPORT_MAP=y
 CONFIG_NO_HZ=y
 CONFIG_NO_HZ_COMMON=y
@@ -229,7 +226,6 @@ CONFIG_PCSPKR_PLATFORM=y
 CONFIG_PERF_EVENTS=y
 CONFIG_PERF_USE_VMALLOC=y
 CONFIG_PGTABLE_LEVELS=2
-CONFIG_PID_NS=y
 CONFIG_PRINT_QUOTA_WARNING=y
 CONFIG_PROC_PAGE_MONITOR=y
 # CONFIG_QFMT_V1 is not set
@@ -294,9 +290,7 @@ CONFIG_TICK_CPU_ACCOUNTING=y
 CONFIG_TREE_RCU=y
 CONFIG_USB_SUPPORT=y
 # CONFIG_USERIO is not set
-# CONFIG_USER_NS is not set
 CONFIG_USE_OF=y
-CONFIG_UTS_NS=y
 # CONFIG_VGA_CONSOLE is not set
 CONFIG_VM_EVENT_COUNTERS=y
 CONFIG_VT=y
-- 
2.8.3



From dirkneukirchen at web.de  Sat Jun  4 09:36:19 2016
From: dirkneukirchen at web.de (Dirk Neukirchen)
Date: Sat,  4 Jun 2016 18:36:19 +0200
Subject: [LEDE-DEV] [PATCH] sunxi: remove NAMESPACES config symbols
Message-ID: <20160604163619.3643-1-dirkneukirchen@web.de>

they are available in config/Config-kernel.in

Signed-off-by: Dirk Neukirchen <dirkneukirchen at web.de>
---
 target/linux/sunxi/config-4.4 | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/target/linux/sunxi/config-4.4 b/target/linux/sunxi/config-4.4
index 4784efb..568bcb7 100644
--- a/target/linux/sunxi/config-4.4
+++ b/target/linux/sunxi/config-4.4
@@ -270,7 +270,6 @@ CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
 CONFIG_INPUT_TOUCHSCREEN=y
 CONFIG_IOMMU_HELPER=y
 CONFIG_IOSCHED_CFQ=y
-CONFIG_IPC_NS=y
 CONFIG_IRQCHIP=y
 CONFIG_IRQ_DOMAIN=y
 CONFIG_IRQ_DOMAIN_HIERARCHY=y
@@ -320,11 +319,9 @@ CONFIG_MODULES_USE_ELF_REL=y
 # CONFIG_MTD is not set
 CONFIG_MULTI_IRQ_HANDLER=y
 CONFIG_MUTEX_SPIN_ON_OWNER=y
-CONFIG_NAMESPACES=y
 CONFIG_NEED_DMA_MAP_STATE=y
 CONFIG_NEON=y
 CONFIG_NET_FLOW_LIMIT=y
-CONFIG_NET_NS=y
 CONFIG_NET_PTP_CLASSIFY=y
 CONFIG_NET_VENDOR_ALLWINNER=y
 CONFIG_NLS=y
@@ -480,7 +477,6 @@ CONFIG_USB_STORAGE=y
 CONFIG_USB_SUPPORT=y
 CONFIG_USERIO=y
 CONFIG_USE_OF=y
-CONFIG_UTS_NS=y
 CONFIG_VDSO=y
 CONFIG_VECTORS_BASE=0xffff0000
 CONFIG_VFP=y
-- 
2.8.3



From dirkneukirchen at web.de  Sat Jun  4 09:36:27 2016
From: dirkneukirchen at web.de (Dirk Neukirchen)
Date: Sat,  4 Jun 2016 18:36:27 +0200
Subject: [LEDE-DEV] [PATCH] omap: remove NAMESPACES config symbols
Message-ID: <20160604163627.3705-1-dirkneukirchen@web.de>

they are available in config/Config-kernel.in

Signed-off-by: Dirk Neukirchen <dirkneukirchen at web.de>
---
 target/linux/omap/config-4.4 | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/target/linux/omap/config-4.4 b/target/linux/omap/config-4.4
index 82b8ca7..88d7b33 100644
--- a/target/linux/omap/config-4.4
+++ b/target/linux/omap/config-4.4
@@ -383,14 +383,12 @@ CONFIG_MTD_UBI_BEB_LIMIT=20
 # CONFIG_MTD_UBI_GLUEBI is not set
 CONFIG_MTD_UBI_WL_THRESHOLD=4096
 CONFIG_MULTI_IRQ_HANDLER=y
-CONFIG_NAMESPACES=y
 CONFIG_NEED_DMA_MAP_STATE=y
 CONFIG_NEED_PER_CPU_KM=y
 CONFIG_NEON=y
 # CONFIG_NET_CADENCE is not set
 CONFIG_NET_KEY=y
 CONFIG_NET_KEY_MIGRATE=y
-CONFIG_NET_NS=y
 CONFIG_NET_PTP_CLASSIFY=y
 # CONFIG_NET_VENDOR_ARC is not set
 # CONFIG_NET_VENDOR_BROADCOM is not set
@@ -660,7 +658,6 @@ CONFIG_UNINLINE_SPIN_UNLOCK=y
 CONFIG_USB_SUPPORT=y
 # CONFIG_USB_DWC3_OMAP is not set
 # CONFIG_USERIO is not set
-# CONFIG_USER_NS is not set
 CONFIG_USE_OF=y
 CONFIG_VECTORS_BASE=0xffff0000
 CONFIG_VFAT_FS=y
-- 
2.8.3



From dirkneukirchen at web.de  Sat Jun  4 09:36:38 2016
From: dirkneukirchen at web.de (Dirk Neukirchen)
Date: Sat,  4 Jun 2016 18:36:38 +0200
Subject: [LEDE-DEV] [PATCH] mediatek: remove modules from Kernel config
Message-ID: <20160604163638.3788-1-dirkneukirchen@web.de>

most symbols should be in Kernel packages

depending on HW the removal of
CONFIG_REALTEK_PHY
and USB symbols might be wrong

compile tested only

Signed-off-by: Dirk Neukirchen <dirkneukirchen at web.de>
---
 target/linux/mediatek/config-4.4 | 85 ----------------------------------------
 1 file changed, 85 deletions(-)

diff --git a/target/linux/mediatek/config-4.4 b/target/linux/mediatek/config-4.4
index b20ae5d..78c9aa8 100644
--- a/target/linux/mediatek/config-4.4
+++ b/target/linux/mediatek/config-4.4
@@ -97,28 +97,7 @@ CONFIG_CPU_V7=y
 CONFIG_CRC16=y
 # CONFIG_CRC32_SARWATE is not set
 CONFIG_CRC32_SLICEBY8=y
-CONFIG_CRC_CCITT=m
 CONFIG_CROSS_MEMORY_ATTACH=y
-CONFIG_CRYPTO_AEAD=m
-CONFIG_CRYPTO_AEAD2=m
-CONFIG_CRYPTO_DRBG=m
-CONFIG_CRYPTO_DRBG_HMAC=y
-CONFIG_CRYPTO_DRBG_MENU=m
-CONFIG_CRYPTO_ECHAINIV=m
-CONFIG_CRYPTO_HASH=m
-CONFIG_CRYPTO_HASH2=m
-CONFIG_CRYPTO_HMAC=m
-CONFIG_CRYPTO_HW=y
-CONFIG_CRYPTO_JITTERENTROPY=m
-CONFIG_CRYPTO_MANAGER=m
-CONFIG_CRYPTO_MANAGER2=y
-CONFIG_CRYPTO_NULL=m
-CONFIG_CRYPTO_NULL2=m
-CONFIG_CRYPTO_RNG=m
-CONFIG_CRYPTO_RNG2=y
-CONFIG_CRYPTO_RNG_DEFAULT=m
-CONFIG_CRYPTO_SHA256=m
-CONFIG_CRYPTO_WORKQUEUE=y
 CONFIG_DCACHE_WORD_ACCESS=y
 CONFIG_DEBUG_BUGVERBOSE=y
 CONFIG_DEBUG_GPIO=y
@@ -237,32 +216,12 @@ CONFIG_INITRAMFS_SOURCE="/openwrt/trunk/build_dir/target-arm_cortex-a7_musl-1.1.
 CONFIG_IOMMU_HELPER=y
 # CONFIG_IOMMU_IO_PGTABLE_LPAE is not set
 CONFIG_IOMMU_SUPPORT=y
-CONFIG_IP6_NF_FILTER=m
-CONFIG_IP6_NF_IPTABLES=m
-CONFIG_IP6_NF_MANGLE=m
-CONFIG_IP6_NF_RAW=m
-CONFIG_IP6_NF_TARGET_REJECT=m
-CONFIG_IPV6=y
-# CONFIG_IPV6_GRE is not set
-CONFIG_IPV6_MROUTE=y
-CONFIG_IPV6_MULTIPLE_TABLES=y
-# CONFIG_IPV6_PIMSM_V2 is not set
-CONFIG_IPV6_SUBTREES=y
-CONFIG_IP_NF_FILTER=m
-CONFIG_IP_NF_IPTABLES=m
-CONFIG_IP_NF_MANGLE=m
-CONFIG_IP_NF_NAT=m
-CONFIG_IP_NF_RAW=m
-CONFIG_IP_NF_TARGET_MASQUERADE=m
-CONFIG_IP_NF_TARGET_REDIRECT=m
-CONFIG_IP_NF_TARGET_REJECT=m
 CONFIG_IRQCHIP=y
 CONFIG_IRQ_DOMAIN=y
 CONFIG_IRQ_DOMAIN_HIERARCHY=y
 CONFIG_IRQ_FORCED_THREADING=y
 CONFIG_IRQ_WORK=y
 CONFIG_KALLSYMS=y
-CONFIG_LEDS_GPIO=m
 CONFIG_LIBFDT=y
 CONFIG_LOCKUP_DETECTOR=y
 CONFIG_LOCK_SPIN_ON_OWNER=y
@@ -311,46 +270,12 @@ CONFIG_MULTI_IRQ_HANDLER=y
 CONFIG_MUTEX_SPIN_ON_OWNER=y
 CONFIG_NEED_DMA_MAP_STATE=y
 # CONFIG_NEON is not set
-CONFIG_NETFILTER=y
-CONFIG_NETFILTER_ADVANCED=y
-CONFIG_NETFILTER_INGRESS=y
-CONFIG_NETFILTER_XTABLES=m
-CONFIG_NETFILTER_XT_MARK=m
-CONFIG_NETFILTER_XT_MATCH_COMMENT=m
-CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m
-# CONFIG_NETFILTER_XT_MATCH_ID is not set
-CONFIG_NETFILTER_XT_MATCH_LIMIT=m
-CONFIG_NETFILTER_XT_MATCH_MAC=m
-CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m
-CONFIG_NETFILTER_XT_MATCH_STATE=m
-CONFIG_NETFILTER_XT_MATCH_TIME=m
-CONFIG_NETFILTER_XT_NAT=m
-CONFIG_NETFILTER_XT_TARGET_CT=m
-CONFIG_NETFILTER_XT_TARGET_LOG=m
-CONFIG_NETFILTER_XT_TARGET_REDIRECT=m
-CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
 CONFIG_NET_FLOW_LIMIT=y
 CONFIG_NET_INGRESS=y
 CONFIG_NET_MEDIATEK_SOC=y
 # CONFIG_NET_VENDOR_AURORA is not set
 CONFIG_NET_VENDOR_MEDIATEK=y
 # CONFIG_NET_VENDOR_WIZNET is not set
-CONFIG_NF_CONNTRACK=m
-CONFIG_NF_CONNTRACK_IPV4=m
-CONFIG_NF_CONNTRACK_IPV6=m
-# CONFIG_NF_CONNTRACK_RTCACHE is not set
-CONFIG_NF_DEFRAG_IPV4=m
-CONFIG_NF_DEFRAG_IPV6=m
-CONFIG_NF_LOG_COMMON=m
-CONFIG_NF_LOG_IPV4=m
-CONFIG_NF_LOG_IPV6=m
-CONFIG_NF_NAT=m
-CONFIG_NF_NAT_IPV4=m
-CONFIG_NF_NAT_MASQUERADE_IPV4=m
-CONFIG_NF_NAT_NEEDED=y
-CONFIG_NF_NAT_REDIRECT=m
-CONFIG_NF_REJECT_IPV4=m
-CONFIG_NF_REJECT_IPV6=m
 CONFIG_NLS=y
 CONFIG_NO_BOOTMEM=y
 CONFIG_NO_HZ=y
@@ -399,9 +324,6 @@ CONFIG_PM_SLEEP=y
 CONFIG_PM_SLEEP_SMP=y
 CONFIG_POWER_RESET=y
 CONFIG_POWER_SUPPLY=y
-CONFIG_PPP=m
-CONFIG_PPPOE=m
-CONFIG_PPP_ASYNC=m
 CONFIG_PREEMPT=y
 CONFIG_PREEMPT_COUNT=y
 # CONFIG_PREEMPT_NONE is not set
@@ -415,7 +337,6 @@ CONFIG_RATIONAL=y
 CONFIG_RCU_CPU_STALL_TIMEOUT=21
 # CONFIG_RCU_EXPERT is not set
 CONFIG_RCU_STALL_COMMON=y
-CONFIG_REALTEK_PHY=m
 CONFIG_REGMAP=y
 CONFIG_REGMAP_MMIO=y
 CONFIG_REGULATOR=y
@@ -440,7 +361,6 @@ CONFIG_SERIAL_8250_FSL=y
 CONFIG_SERIAL_8250_MT6577=y
 CONFIG_SERIAL_8250_NR_UARTS=4
 CONFIG_SERIAL_8250_RUNTIME_UARTS=4
-CONFIG_SLHC=m
 CONFIG_SMP=y
 # CONFIG_SMP_ON_UP is not set
 CONFIG_SPARSE_IRQ=y
@@ -465,11 +385,6 @@ CONFIG_UNCOMPRESS_INCLUDE="debug/uncompress.h"
 CONFIG_UNINLINE_SPIN_UNLOCK=y
 CONFIG_USB=y
 CONFIG_USB_COMMON=y
-CONFIG_USB_EHCI_HCD=m
-CONFIG_USB_EHCI_HCD_PLATFORM=m
-CONFIG_USB_EHCI_PCI=m
-CONFIG_USB_OHCI_HCD=m
-CONFIG_USB_OHCI_HCD_PLATFORM=m
 CONFIG_USB_SUPPORT=y
 # CONFIG_USB_UHCI_HCD is not set
 CONFIG_USB_XHCI_HCD=y
-- 
2.8.3



From wbx at openadk.org  Sat Jun  4 13:21:38 2016
From: wbx at openadk.org (Waldemar Brodkorb)
Date: Sat, 4 Jun 2016 22:21:38 +0200
Subject: [LEDE-DEV] [PATCH] uClibc-ng: allow to choose for all supported
	architectures
Message-ID: <20160604202137.GA15002@waldemar-brodkorb.de>

Update to 1.0.15 and allow to choose uClibc-ng for all
supported architectures. Some users still need to port over
their code from uClibc-ng to musl, with this change they
can do it in a comfortable way.

Extra pregen is not required.

Signed-off-by: Waldemar Brodkorb <wbx at uclibc-ng.org>
---
 toolchain/Config.in               | 3 +--
 toolchain/uClibc/Config.version   | 2 +-
 toolchain/uClibc/Makefile         | 2 +-
 toolchain/uClibc/common.mk        | 2 +-
 toolchain/uClibc/config/common    | 1 +
 toolchain/uClibc/headers/Makefile | 1 -
 6 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/toolchain/Config.in b/toolchain/Config.in
index a6aa84d..7186cfb 100644
--- a/toolchain/Config.in
+++ b/toolchain/Config.in
@@ -223,9 +223,8 @@ choice
 
 	config LIBC_USE_UCLIBC
 		select USE_UCLIBC
-		bool "Use uClibc"
+		bool "Use uClibc-ng"
 		depends on !(aarch64 || aarch64_be)
-		depends on BROKEN || !(arm || armeb || i386 || x86_64 || mips || mipsel || mips64 || mips64el || powerpc)
 
 	config LIBC_USE_MUSL
 		select USE_MUSL
diff --git a/toolchain/uClibc/Config.version b/toolchain/uClibc/Config.version
index 3c1c54d..7c32ee5 100644
--- a/toolchain/uClibc/Config.version
+++ b/toolchain/uClibc/Config.version
@@ -1,7 +1,7 @@
 config UCLIBC_VERSION
 	string
 	depends on USE_UCLIBC
-	default "1.0.14"
+	default "1.0.15"
 
 config UCLIBC_VERSION_NG
 	bool
diff --git a/toolchain/uClibc/Makefile b/toolchain/uClibc/Makefile
index a5fb54b..813e5de 100644
--- a/toolchain/uClibc/Makefile
+++ b/toolchain/uClibc/Makefile
@@ -9,7 +9,7 @@ HOST_BUILD_PARALLEL:=1
 
 define Host/SetToolchainInfo
 	$(SED) 's,^\(LIBC_TYPE\)=.*,\1=$(PKG_NAME),' $(TOOLCHAIN_DIR)/info.mk
-	$(SED) 's,^\(LIBC_URL\)=.*,\1=http://www.uclibc.org/,' $(TOOLCHAIN_DIR)/info.mk
+	$(SED) 's,^\(LIBC_URL\)=.*,\1=http://www.uclibc-ng.org/,' $(TOOLCHAIN_DIR)/info.mk
 	$(SED) 's,^\(LIBC_VERSION\)=.*,\1=$(PKG_VERSION),' $(TOOLCHAIN_DIR)/info.mk
 	$(SED) 's,^\(LIBC_SO_VERSION\)=.*,\1=$(LIBC_SO_VERSION),' $(TOOLCHAIN_DIR)/info.mk
 endef
diff --git a/toolchain/uClibc/common.mk b/toolchain/uClibc/common.mk
index 878bd76..02d1c93 100644
--- a/toolchain/uClibc/common.mk
+++ b/toolchain/uClibc/common.mk
@@ -16,7 +16,7 @@ CONFIG_DIR:=$(PATH_PREFIX)/config
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 LIBC_SO_VERSION:=$(PKG_VERSION)
 
-PKG_MD5SUM=8eed7f3635216142c1c5e122874b89c6
+PKG_MD5SUM=31a558739311583b9bdf9017f5c93fa4
 
 HOST_BUILD_DIR:=$(BUILD_DIR_TOOLCHAIN)/$(PKG_NAME)-$(PKG_VERSION)
 
diff --git a/toolchain/uClibc/config/common b/toolchain/uClibc/config/common
index b476639..8484cae 100644
--- a/toolchain/uClibc/config/common
+++ b/toolchain/uClibc/config/common
@@ -223,3 +223,4 @@ WARNINGS="-Wall"
 # UCLIBC_SUSV2_LEGACY is not set
 # UCLIBC_HAS_CONTEXT_FUNCS is not set
 UCLIBC_HAS_GETOPT_LONG=y
+# UCLIBC_HAS_ARGP is not set
diff --git a/toolchain/uClibc/headers/Makefile b/toolchain/uClibc/headers/Makefile
index 67a2d95..202d293 100644
--- a/toolchain/uClibc/headers/Makefile
+++ b/toolchain/uClibc/headers/Makefile
@@ -18,7 +18,6 @@ define Host/Install
 		CC="$(TARGET_CC)" \
 		CPU_CFLAGS="$(TARGET_CFLAGS)" \
 		ARCH="$(CONFIG_ARCH)" \
-		pregen \
 		install_headers
 endef
 
-- 
2.7.4 (Apple Git-66)



From wbx at openadk.org  Sat Jun  4 13:24:56 2016
From: wbx at openadk.org (Waldemar Brodkorb)
Date: Sat, 4 Jun 2016 22:24:56 +0200
Subject: [LEDE-DEV] [PATCH] util-linux: fix scanf fallback detection for
	uClibc-ng
Message-ID: <20160604202456.GA18235@waldemar-brodkorb.de>

uClibc-ng pretends to be GNU libc 2.2 and then a fallback
scanf check is tried, so that libmount is disabled
afterwards. Add a fix already suggested upstream.
Add librt dependency required for other apps, too.

Signed-off-by: Waldemar Brodkorb <wbx at uclibc-ng.org>
---
 package/utils/util-linux/Makefile                  |  2 +-
 .../patches/0001-fix-uClibc-ng-scanf-check.patch   | 34 ++++++++++++++++++++++
 2 files changed, 35 insertions(+), 1 deletion(-)
 create mode 100644 package/utils/util-linux/patches/0001-fix-uClibc-ng-scanf-check.patch

diff --git a/package/utils/util-linux/Makefile b/package/utils/util-linux/Makefile
index cfa244d..d1abacb 100644
--- a/package/utils/util-linux/Makefile
+++ b/package/utils/util-linux/Makefile
@@ -40,6 +40,7 @@ include $(INCLUDE_DIR)/package.mk
 define Package/util-linux/Default
   SECTION:=utils
   CATEGORY:=Utilities
+  DEPENDS:= +librt
   URL:=http://www.kernel.org/pub/linux/utils/util-linux/
 endef
 
@@ -167,7 +168,6 @@ endef
 define Package/dmesg
 $(call Package/util-linux/Default)
   TITLE:=print or control the kernel ring buffer
-  DEPENDS:= +librt
 endef
 
 define Package/dmesg/description
diff --git a/package/utils/util-linux/patches/0001-fix-uClibc-ng-scanf-check.patch b/package/utils/util-linux/patches/0001-fix-uClibc-ng-scanf-check.patch
new file mode 100644
index 0000000..2da95f6
--- /dev/null
+++ b/package/utils/util-linux/patches/0001-fix-uClibc-ng-scanf-check.patch
@@ -0,0 +1,34 @@
+From 180c908e2e80552b19bf3552667fc197d6edf7b3 Mon Sep 17 00:00:00 2001
+From: Waldemar Brodkorb <wbx at uclibc-ng.org>
+Date: Fri, 3 Jun 2016 04:13:08 +0200
+Subject: [PATCH] fix uClibc-ng scanf check
+
+uClibc-ng tries to be compatible with GNU libc and defines
+__GLIBC__ and pretend to be version 2.2.
+We once changed it to 2.10, but then some hard to fix problems
+in different software packages (gcc) occured.
+It would be better if we disable the special GNU libc checks
+for uClibc-ng here. uClibc-ng implements the required scanf
+functionality.
+
+Signed-off-by: Waldemar Brodkorb <wbx at uclibc-ng.org>
+---
+ configure.ac | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/configure.ac b/configure.ac
+index f36b18c..4661c0d 100644
+--- a/configure.ac
++++ b/configure.ac
+@@ -581,7 +581,7 @@ AC_CACHE_VAL([scanf_cv_alloc_modifier],
+      #include <stdio.h>
+      #include <unistd.h>
+ 
+-     #ifdef __GLIBC__
++     #if defined(__GLIBC__) && !defined(__UCLIBC__)
+ 
+      #if !(__GLIBC_PREREQ(2, 7))
+      #error %m is not available
+-- 
+2.1.4
+
-- 
2.7.4 (Apple Git-66)



From john at phrozen.org  Sat Jun  4 13:31:46 2016
From: john at phrozen.org (John Crispin)
Date: Sat, 4 Jun 2016 22:31:46 +0200
Subject: [LEDE-DEV] [PATCH] uClibc-ng: allow to choose for all supported
 architectures
In-Reply-To: <20160604202137.GA15002@waldemar-brodkorb.de>
References: <20160604202137.GA15002@waldemar-brodkorb.de>
Message-ID: <c3cc8b1e-41b6-f6f2-8387-2307bd38342f@phrozen.org>



On 04/06/2016 22:21, Waldemar Brodkorb wrote:
> Update to 1.0.15 and allow to choose uClibc-ng for all
> supported architectures. Some users still need to port over
> their code from uClibc-ng to musl, with this change they
> can do it in a comfortable way.
> 
> Extra pregen is not required.
> 
> Signed-off-by: Waldemar Brodkorb <wbx at uclibc-ng.org>

personally i am against supporting uclibc for anything that can be run
on musl. it has been a pita for year and i am happy it is finally gone.

but that is just my 2cents, lets see what others have to say.

	John

> ---
>  toolchain/Config.in               | 3 +--
>  toolchain/uClibc/Config.version   | 2 +-
>  toolchain/uClibc/Makefile         | 2 +-
>  toolchain/uClibc/common.mk        | 2 +-
>  toolchain/uClibc/config/common    | 1 +
>  toolchain/uClibc/headers/Makefile | 1 -
>  6 files changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/toolchain/Config.in b/toolchain/Config.in
> index a6aa84d..7186cfb 100644
> --- a/toolchain/Config.in
> +++ b/toolchain/Config.in
> @@ -223,9 +223,8 @@ choice
>  
>  	config LIBC_USE_UCLIBC
>  		select USE_UCLIBC
> -		bool "Use uClibc"
> +		bool "Use uClibc-ng"
>  		depends on !(aarch64 || aarch64_be)
> -		depends on BROKEN || !(arm || armeb || i386 || x86_64 || mips || mipsel || mips64 || mips64el || powerpc)
>  
>  	config LIBC_USE_MUSL
>  		select USE_MUSL
> diff --git a/toolchain/uClibc/Config.version b/toolchain/uClibc/Config.version
> index 3c1c54d..7c32ee5 100644
> --- a/toolchain/uClibc/Config.version
> +++ b/toolchain/uClibc/Config.version
> @@ -1,7 +1,7 @@
>  config UCLIBC_VERSION
>  	string
>  	depends on USE_UCLIBC
> -	default "1.0.14"
> +	default "1.0.15"
>  
>  config UCLIBC_VERSION_NG
>  	bool
> diff --git a/toolchain/uClibc/Makefile b/toolchain/uClibc/Makefile
> index a5fb54b..813e5de 100644
> --- a/toolchain/uClibc/Makefile
> +++ b/toolchain/uClibc/Makefile
> @@ -9,7 +9,7 @@ HOST_BUILD_PARALLEL:=1
>  
>  define Host/SetToolchainInfo
>  	$(SED) 's,^\(LIBC_TYPE\)=.*,\1=$(PKG_NAME),' $(TOOLCHAIN_DIR)/info.mk
> -	$(SED) 's,^\(LIBC_URL\)=.*,\1=http://www.uclibc.org/,' $(TOOLCHAIN_DIR)/info.mk
> +	$(SED) 's,^\(LIBC_URL\)=.*,\1=http://www.uclibc-ng.org/,' $(TOOLCHAIN_DIR)/info.mk
>  	$(SED) 's,^\(LIBC_VERSION\)=.*,\1=$(PKG_VERSION),' $(TOOLCHAIN_DIR)/info.mk
>  	$(SED) 's,^\(LIBC_SO_VERSION\)=.*,\1=$(LIBC_SO_VERSION),' $(TOOLCHAIN_DIR)/info.mk
>  endef
> diff --git a/toolchain/uClibc/common.mk b/toolchain/uClibc/common.mk
> index 878bd76..02d1c93 100644
> --- a/toolchain/uClibc/common.mk
> +++ b/toolchain/uClibc/common.mk
> @@ -16,7 +16,7 @@ CONFIG_DIR:=$(PATH_PREFIX)/config
>  PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
>  LIBC_SO_VERSION:=$(PKG_VERSION)
>  
> -PKG_MD5SUM=8eed7f3635216142c1c5e122874b89c6
> +PKG_MD5SUM=31a558739311583b9bdf9017f5c93fa4
>  
>  HOST_BUILD_DIR:=$(BUILD_DIR_TOOLCHAIN)/$(PKG_NAME)-$(PKG_VERSION)
>  
> diff --git a/toolchain/uClibc/config/common b/toolchain/uClibc/config/common
> index b476639..8484cae 100644
> --- a/toolchain/uClibc/config/common
> +++ b/toolchain/uClibc/config/common
> @@ -223,3 +223,4 @@ WARNINGS="-Wall"
>  # UCLIBC_SUSV2_LEGACY is not set
>  # UCLIBC_HAS_CONTEXT_FUNCS is not set
>  UCLIBC_HAS_GETOPT_LONG=y
> +# UCLIBC_HAS_ARGP is not set
> diff --git a/toolchain/uClibc/headers/Makefile b/toolchain/uClibc/headers/Makefile
> index 67a2d95..202d293 100644
> --- a/toolchain/uClibc/headers/Makefile
> +++ b/toolchain/uClibc/headers/Makefile
> @@ -18,7 +18,6 @@ define Host/Install
>  		CC="$(TARGET_CC)" \
>  		CPU_CFLAGS="$(TARGET_CFLAGS)" \
>  		ARCH="$(CONFIG_ARCH)" \
> -		pregen \
>  		install_headers
>  endef
>  
> 


From wbx at openadk.org  Sat Jun  4 14:33:38 2016
From: wbx at openadk.org (Waldemar Brodkorb)
Date: Sat, 4 Jun 2016 23:33:38 +0200
Subject: [LEDE-DEV] [PATCH] uClibc-ng: allow to choose for all supported
 architectures
In-Reply-To: <c3cc8b1e-41b6-f6f2-8387-2307bd38342f@phrozen.org>
References: <20160604202137.GA15002@waldemar-brodkorb.de>
 <c3cc8b1e-41b6-f6f2-8387-2307bd38342f@phrozen.org>
Message-ID: <20160604213338.GZ6825@waldemar-brodkorb.de>

Hi John,
John Crispin wrote,

> On 04/06/2016 22:21, Waldemar Brodkorb wrote:
> > Update to 1.0.15 and allow to choose uClibc-ng for all
> > supported architectures. Some users still need to port over
> > their code from uClibc-ng to musl, with this change they
> > can do it in a comfortable way.
> > 
> > Extra pregen is not required.
> > 
> > Signed-off-by: Waldemar Brodkorb <wbx at uclibc-ng.org>
> 
> personally i am against supporting uclibc for anything that can be run
> on musl. it has been a pita for year and i am happy it is finally gone.

But uClibc 0.9.33.2 + 100 of patches is not the same as uClibc-ng
1.0.15. You need to additional patches and I take care of any
uClibc-ng related bug reports. (As you have seen for the util-linux
package)
 
> but that is just my 2cents, lets see what others have to say.

Let's see.
 best regards
  Waldemar


From wbx at openadk.org  Sat Jun  4 14:35:49 2016
From: wbx at openadk.org (Waldemar Brodkorb)
Date: Sat, 4 Jun 2016 23:35:49 +0200
Subject: [LEDE-DEV] [PATCH] uClibc-ng: allow to choose for all supported
 architectures
In-Reply-To: <20160604213338.GZ6825@waldemar-brodkorb.de>
References: <20160604202137.GA15002@waldemar-brodkorb.de>
 <c3cc8b1e-41b6-f6f2-8387-2307bd38342f@phrozen.org>
 <20160604213338.GZ6825@waldemar-brodkorb.de>
Message-ID: <20160604213548.GA6825@waldemar-brodkorb.de>

Hi,
Waldemar Brodkorb wrote,

> Hi John,
> John Crispin wrote,
> 
> > On 04/06/2016 22:21, Waldemar Brodkorb wrote:
> > > Update to 1.0.15 and allow to choose uClibc-ng for all
> > > supported architectures. Some users still need to port over
> > > their code from uClibc-ng to musl, with this change they
> > > can do it in a comfortable way.
> > > 
> > > Extra pregen is not required.
> > > 
> > > Signed-off-by: Waldemar Brodkorb <wbx at uclibc-ng.org>
> > 
> > personally i am against supporting uclibc for anything that can be run
> > on musl. it has been a pita for year and i am happy it is finally gone.
> 
> But uClibc 0.9.33.2 + 100 of patches is not the same as uClibc-ng
> 1.0.15. You need to additional patches and I take care of any
> uClibc-ng related bug reports. (As you have seen for the util-linux
> package)

I mean you need "no" additional patches, sorry.
  
best regards
 Waldemar


From marco.castrovilli at gmail.com  Sat Jun  4 17:02:46 2016
From: marco.castrovilli at gmail.com (Marco Castrovilli)
Date: Sun, 5 Jun 2016 02:02:46 +0200
Subject: [LEDE-DEV] mmc driver for openwrt on fonera 2100
In-Reply-To: <2c0e0357-a4c3-76c4-ab64-b7f82744956c@gmail.com>
References: <56700383-6ffd-72a4-fca6-f46e582eff90@gmail.com>
 <CA+yTfBBGrvy8r8yiZ+ZNf-4m1Ss1==fr95HvgEaQ4WrwB_XBTw@mail.gmail.com>
 <13d21777-d42d-bcab-4831-542c87fa0a14@gmail.com>
 <CA+yTfBCViAFD=pOTmfro=S5vyEJcbsjZ8ijHbbTpkOGPyaH9hA@mail.gmail.com>
 <2c0e0357-a4c3-76c4-ab64-b7f82744956c@gmail.com>
Message-ID: <fd26bcc1-4b01-db20-f4af-16c9c70feb25@gmail.com>

hi andrew. no good news. i flashed again fonera and followed instruction 
of the guide but:

when i try command uci set mmc_over_gpio. at mmc_over_gpio[0].enabled=1 i 
have uci: Entry not found message;

uci is ok: other commands (uci add fstab mount etc. etc) are correctly 
executed;

when i try starting mmc_over_gpio, fonera reboot and connection become 
ustable.

below you can find details.

perhaps does this mean that soldered points are not good? or do i forget 
some fundamental step?

thank you for your opinion.


login as: root
root at 192.168.1.1's password:


BusyBox v1.11.2 (2009-01-05 06:34:55 CET) built-in shell (ash)
Enter 'help' for a list of built-in commands.

   _______                     ________        __
  |       |.-----.-----.-----.|  |  |  |.----.|  |_
  |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
  |_______||   __|_____|__|__||________||__|  |____|
           |__| W I R E L E S S   F R E E D O M
  KAMIKAZE (8.09, r14511) ----------------------------
   * 10 oz Vodka       Shake well with ice and strain
   * 10 oz Triple sec  mixture into 10 shot glasses.
   * 10 oz lime juice  Salute!
  ---------------------------------------------------
root at OpenWrt:~# free
               total         used         free       shared buffers
   Mem:        13688         7808         5880 0            0
  Swap:            0            0            0
Total:        13688         7808         5880
root at OpenWrt:~# ping 192.168.1.171
PING 192.168.1.171 (192.168.1.171): 56 data bytes
64 bytes from 192.168.1.171: seq=0 ttl=128 time=3.857 ms
64 bytes from 192.168.1.171: seq=1 ttl=128 time=3.451 ms
64 bytes from 192.168.1.171: seq=2 ttl=128 time=2.674 ms
64 bytes from 192.168.1.171: seq=3 ttl=128 time=6.248 ms
64 bytes from 192.168.1.171: seq=4 ttl=128 time=3.290 ms
^C
--- 192.168.1.171 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 2.674/3.904/6.248 ms
root at OpenWrt:~# ping www.google.it
ping: bad address 'www.google.it'
root at OpenWrt:~# cat /etc/resolv.conf
nameserver 127.0.0.1
root at OpenWrt:~# cat /etc/config/network
# Copyright (C) 2006 OpenWrt.org

config interface loopback
         option ifname   lo
         option proto    static
         option ipaddr   127.0.0.1
         option netmask  255.0.0.0

config interface lan
         option ifname   eth0
         option type     bridge
         option proto    static
         option ipaddr   192.168.1.1
         option netmask  255.255.255.0
root at OpenWrt:~# cat /etc/resolv.conf
nameserver 127.0.0.1
root at OpenWrt:~# cat /etc/config/network

config 'interface' 'loopback'
         option 'ifname' 'lo'
         option 'proto' 'static'
         option 'ipaddr' '127.0.0.1'
         option 'netmask' '255.0.0.0'

config 'interface' 'lan'
         option 'ifname' 'eth0'
         option 'type' 'bridge'
         option 'proto' 'static'
         option 'ipaddr' '192.168.1.1'
         option 'netmask' '255.255.255.0'
         option 'gateway' '192.168.1.254'
         option 'defaultroute' '0'
         option 'peerdns' '0'
         option 'dns' '192.168.1.254'

root at OpenWrt:~# cat /etc/resolv.conf
nameserver 127.0.0.1
root at OpenWrt:~# cat /etc/config/network

config 'interface' 'loopback'
         option 'ifname' 'lo'
         option 'proto' 'static'
         option 'ipaddr' '127.0.0.1'
         option 'netmask' '255.0.0.0'

config 'interface' 'lan'
         option 'ifname' 'eth0'
         option 'proto' 'static'
         option 'ipaddr' '192.168.1.1'
         option 'netmask' '255.255.255.0'
         option 'gateway' '192.168.1.254'
         option 'defaultroute' '0'
         option 'peerdns' '0'
         option 'dns' '192.168.1.254'

root at OpenWrt:~# date
Fri Feb  6 02:13:00 UTC 2009
root at OpenWrt:~# ping www.google.it
PING www.google.it (216.58.198.131): 56 data bytes
64 bytes from 216.58.198.131: seq=0 ttl=53 time=47.755 ms
64 bytes from 216.58.198.131: seq=1 ttl=53 time=48.364 ms
64 bytes from 216.58.198.131: seq=2 ttl=53 time=47.934 ms
64 bytes from 216.58.198.131: seq=3 ttl=53 time=51.164 ms
64 bytes from 216.58.198.131: seq=4 ttl=53 time=47.692 ms
^C
--- www.google.it ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 47.692/48.581/51.164 ms
root at OpenWrt:~# opkg update
Downloading 
http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/Packages.gz
Connecting to downloads.openwrt.org (78.24.191.177:80)
Packages.gz          100% 
|************************************************************************************************************| 
143k 00:00:00 ETA
Inflating 
http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/Packages.gz
Updated list of available packages in /var/opkg-lists/snapshots
root at OpenWrt:~# opkg install kmod-mmc-over-gpio kmod-fs-ext3 cfdisk 
e2fsprogs kmod-nls-base kmod-nls-cp437 kmod-nls-iso8859-1
Installing kmod-mmc-over-gpio (2.6.26.5-atheros-2) to root...
Downloading 
http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/./kmod-mmc-over-gpio_2.6.26.5-atheros-2_mips.ipk
Connecting to downloads.openwrt.org (78.24.191.177:80)
kmod-mmc-over-gpio_2 100% 
|************************************************************************************************************| 
5565  --:--:-- ETA
Installing kmod-mmc-spi (2.6.26.5-atheros-1) to root...
Downloading 
http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/./kmod-mmc-spi_2.6.26.5-atheros-1_mips.ipk
Connecting to downloads.openwrt.org (78.24.191.177:80)
kmod-mmc-spi_2.6.26. 100% 
|************************************************************************************************************| 
7219  --:--:-- ETA
Installing kmod-mmc (2.6.26.5-atheros-1) to root...
Downloading 
http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/./kmod-mmc_2.6.26.5-atheros-1_mips.ipk
Connecting to downloads.openwrt.org (78.24.191.177:80)
kmod-mmc_2.6.26.5-at 100% 
|************************************************************************************************************| 
28898  --:--:-- ETA
Installing kmod-crc-itu-t (2.6.26.5-atheros-1) to root...
Downloading 
http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/./kmod-crc-itu-t_2.6.26.5-atheros-1_mips.ipk
Connecting to downloads.openwrt.org (78.24.191.177:80)
kmod-crc-itu-t_2.6.2 100% 
|************************************************************************************************************| 
2269  --:--:-- ETA
Installing kmod-crc7 (2.6.26.5-atheros-1) to root...
Downloading 
http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/./kmod-crc7_2.6.26.5-atheros-1_mips.ipk
Connecting to downloads.openwrt.org (78.24.191.177:80)
kmod-crc7_2.6.26.5-a 100% 
|************************************************************************************************************| 
1911  --:--:-- ETA
Installing kmod-spi-gpio (2.6.26.5-atheros-1) to root...
Downloading 
http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/./kmod-spi-gpio_2.6.26.5-atheros-1_mips.ipk
Connecting to downloads.openwrt.org (78.24.191.177:80)
kmod-spi-gpio_2.6.26 100% 
|************************************************************************************************************| 
3945  --:--:-- ETA
Installing kmod-spi-bitbang (2.6.26.5-atheros-1) to root...
Downloading 
http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/./kmod-spi-bitbang_2.6.26.5-atheros-1_mips.ipk
Connecting to downloads.openwrt.org (78.24.191.177:80)
kmod-spi-bitbang_2.6 100% 
|************************************************************************************************************| 
3580  --:--:-- ETA
Installing kmod-fs-ext3 (2.6.26.5-atheros-1) to root...
Downloading 
http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/./kmod-fs-ext3_2.6.26.5-atheros-1_mips.ipk
Connecting to downloads.openwrt.org (78.24.191.177:80)
kmod-fs-ext3_2.6.26. 100% 
|************************************************************************************************************| 
92934  00:00:00 ETA
Installing cfdisk (2.13.0.1-2) to root...
Downloading 
http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/./cfdisk_2.13.0.1-2_mips.ipk
Connecting to downloads.openwrt.org (78.24.191.177:80)
cfdisk_2.13.0.1-2_mi 100% 
|************************************************************************************************************| 
28445  --:--:-- ETA
Installing libncurses (5.6-1) to root...
Downloading 
http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/./libncurses_5.6-1_mips.ipk
Connecting to downloads.openwrt.org (78.24.191.177:80)
libncurses_5.6-1_mip 100% 
|************************************************************************************************************| 
135k 00:00:00 ETA
Installing e2fsprogs (1.40.11-1) to root...
Downloading 
http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/./e2fsprogs_1.40.11-1_mips.ipk
Connecting to downloads.openwrt.org (78.24.191.177:80)
e2fsprogs_1.40.11-1_ 100% 
|************************************************************************************************************| 
101k 00:00:00 ETA
Installing libblkid (1.40.11-1) to root...
Downloading 
http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/./libblkid_1.40.11-1_mips.ipk
Connecting to downloads.openwrt.org (78.24.191.177:80)
libblkid_1.40.11-1_m 100% 
|************************************************************************************************************| 
17309  --:--:-- ETA
Installing libuuid (1.40.11-1) to root...
Downloading 
http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/./libuuid_1.40.11-1_mips.ipk
Connecting to downloads.openwrt.org (78.24.191.177:80)
libuuid_1.40.11-1_mi 100% 
|************************************************************************************************************| 
7491  --:--:-- ETA
Installing libext2fs (1.40.11-1) to root...
Downloading 
http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/./libext2fs_1.40.11-1_mips.ipk
Connecting to downloads.openwrt.org (78.24.191.177:80)
libext2fs_1.40.11-1_ 100% 
|************************************************************************************************************| 
195k --:--:-- ETA
Installing kmod-nls-base (2.6.26.5-atheros-1) to root...
Downloading 
http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/./kmod-nls-base_2.6.26.5-atheros-1_mips.ipk
Connecting to downloads.openwrt.org (78.24.191.177:80)
kmod-nls-base_2.6.26 100% 
|************************************************************************************************************| 
3724  --:--:-- ETA
Installing kmod-nls-cp437 (2.6.26.5-atheros-1) to root...
Downloading 
http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/./kmod-nls-cp437_2.6.26.5-atheros-1_mips.ipk
Connecting to downloads.openwrt.org (78.24.191.177:80)
kmod-nls-cp437_2.6.2 100% 
|************************************************************************************************************| 
2977  --:--:-- ETA
Installing kmod-nls-iso8859-1 (2.6.26.5-atheros-1) to root...
Downloading 
http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/./kmod-nls-iso8859-1_2.6.26.5-atheros-1_mips.ipk
Connecting to downloads.openwrt.org (78.24.191.177:80)
kmod-nls-iso8859-1_2 100% 
|************************************************************************************************************| 
2650  --:--:-- ETA
Configuring cfdisk
Configuring e2fsprogs
Configuring kmod-crc-itu-t
Configuring kmod-crc7
Configuring kmod-fs-ext3
Configuring kmod-mmc
Configuring kmod-mmc-over-gpio
Configuring kmod-mmc-spi
Configuring kmod-nls-base
Configuring kmod-nls-cp437
Configuring kmod-nls-iso8859-1
Configuring kmod-spi-bitbang
Configuring kmod-spi-gpio
Configuring libblkid
Configuring libext2fs
Configuring libncurses
Configuring libuuid
root at OpenWrt:~#

reboot

login as: root
root at 192.168.1.1's password:


BusyBox v1.11.2 (2009-01-05 06:34:55 CET) built-in shell (ash)
Enter 'help' for a list of built-in commands.

   _______                     ________        __
  |       |.-----.-----.-----.|  |  |  |.----.|  |_
  |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
  |_______||   __|_____|__|__||________||__|  |____|
           |__| W I R E L E S S   F R E E D O M
  KAMIKAZE (8.09, r14511) ----------------------------
   * 10 oz Vodka       Shake well with ice and strain
   * 10 oz Triple sec  mixture into 10 shot glasses.
   * 10 oz lime juice  Salute!
  ---------------------------------------------------
root at OpenWrt:~# ping www.google.it
PING www.google.it (216.58.214.99): 56 data bytes
64 bytes from 216.58.214.99: seq=0 ttl=52 time=49.145 ms
64 bytes from 216.58.214.99: seq=1 ttl=52 time=48.823 ms
64 bytes from 216.58.214.99: seq=2 ttl=52 time=47.853 ms
64 bytes from 216.58.214.99: seq=3 ttl=52 time=48.080 ms
^C
--- www.google.it ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 47.853/48.475/49.145 ms
root at OpenWrt:~# uci set mmc_over_gpio. at mmc_over_gpio[0].enabled=1
uci: Entry not found
root at OpenWrt:~# ls /sbin/uci -all
-rwxr-xr-x    1 root     root        10815 Jan 20 17:04 /sbin/uci
root at OpenWrt:~# uci --help
uci: invalid option -- -
Usage: uci [<options>] <command> [<arguments>]

Commands:
         batch
         export     [<config>]
         import     [<config>]
         changes    [<config>]
         commit     [<config>]
         add        <config> <section-type>
         add_list <config>.<section>.<option>=<string>
         show [<config>[.<section>[.<option>]]]
         get        <config>.<section>[.<option>]
         set <config>.<section>[.<option>]=<value>
         delete     <config>[.<section[.<option>]]
         rename <config>.<section>[.<option>]=<name>
         revert <config>[.<section>[.<option>]]

Options:
         -c <path>  set the search path for config files (default: 
/etc/config)
         -d <str>   set the delimiter for list values in uci show
         -f <file>  use <file> as input instead of stdin
         -m         when importing, merge data into an existing package
         -n         name unnamed sections on export (default)
         -N         don't name unnamed sections
         -p <path>  add a search path for config change files
         -P <path>  add a search path for config change files and use as 
default
         -q         quiet mode (don't print error messages)
         -s         force strict mode (stop on parser errors, default)
         -S         disable strict mode
         -X         do not use extended syntax on 'show'

root at OpenWrt:~# ls /etc/init.d/mmc_over_gpio -all
-rwxr-xr-x    1 root     root         1238 Feb 14  2009 
/etc/init.d/mmc_over_gpio

root at OpenWrt:/# uci add fstab mount
cfg064d78
root at OpenWrt:/# uci set fstab. at mount[0].enabled=1
root at OpenWrt:/# uci set fstab. at mount[0].fstype=ext3
root at OpenWrt:/# uci set fstab. at mount[0].device=/dev/mmcblk0p1
root at OpenWrt:/# uci set fstab. at mount[0].target=/mnt/mmc
root at OpenWrt:/# uci set fstab. at mount[0].options=rw,sync,noatime
root at OpenWrt:/# uci commit fstab
root at OpenWrt:/# /etc/init.d/fstab restart
umount: cannot umount /mnt/mmc: No such file or directory
mount: mounting /dev/mmcblk0p1 on /mnt/mmc failed: No such file or directory

root at OpenWrt:/# /etc/init.d/mmc_over_gpio
Syntax: /etc/init.d/mmc_over_gpio [command]

Available commands:
         start   Start the service
         stop    Stop the service
         restart Restart the service
         reload  Reload configuration files (or restart if that fails)
         enable  Enable service autostart
         disable Disable service autostart

root at OpenWrt:/# /etc/init.d/mmc_over_gpio start


Il 04/06/2016 04:40, Marco Castrovilli ha scritto:
> hi andrew,
> i've installed
> openwrt-atheros-root.jffs2-64k
> openwrt-atheros-vmlinux.lzma
> from https://downloads.openwrt.org/kamikaze/8.09/atheros/
>
> after few problems to configure internet access, i did:
>
> opkg update
> opkg install kmod-mmc-over-gpio kmod-fs-ext3 cfdisk e2fsprogs 
> kmod-nls-base kmod-nls-cp437 kmod-nls-iso8859-1
>
> and each installation was fine.
>
> during GPIO configuration i had the message:
> uci: entry not found
> after each command:
> uci set mmc_over_gpio. at mmc_over_gpio[0].enabled=1
> uci set mmc_over_gpio. at mmc_over_gpio[0].DI_pin=1
> uci set mmc_over_gpio. at mmc_over_gpio[0].DO_pin=4
> uci set mmc_over_gpio. at mmc_over_gpio[0].CLK_pin=3
> uci set mmc_over_gpio. at mmc_over_gpio[0].CS_pin=7
> then i had "can't create /config/gpiommc/ directory" error. so i 
> rebooted, but now i can ping fonera 15/16 times, 1 timeout, other 
> 10/12 ping ok,
> then it is unreachable for some seconds and so looping on.
>
> do you know the reason?
>
> and now the final question: i soldered exactly like in figure above:
> www.WiFi-Ita.com
> as explained here:
> http://www.wifi-ita.com/index.php?option=com_content&task=view&id=223
>
> must i have to solder ALL cables on pin of GPIO?
>
> thank you again.
> Il 03/06/2016 16:32, Andrew Yong ha scritto:
>> You'll want to use OpenWrt Kamikaze 8.09 and use the official package
>> manager opkg. Follow the linked wiki page
>> (https://wiki.openwrt.org/doc/howto/mmc_over_gpio) and you'll be fine.
>>
>> The latest releases have deprecated kmod-mmc-over-gpio in favor of
>> just getting other generic $30 routers from AliExpress that have built
>> in TF/MMC ports (generally RT5350), or AR9311 routers with USB e.g.
>> TL-MR3020.
>>
>>
>>
>> On Fri, Jun 3, 2016 at 10:15 PM, Marco Castrovilli
>> <marco.castrovilli at gmail.com> wrote:
>>> thanks a lot for your immediate answer.
>>> i followed this guide to mod fonera adding an sd card:
>>> http://www.wifi-ita.com/index.php?option=com_content&task=view&id=223
>>> and this one:
>>> http://www.nabuk.org/f/index.php?topic=1486.0
>>> everything is ok but i can't find 26215-4pinfon2100Driver7143.ipk 
>>> anywere.
>>> i'm on kamikaze 7.09 and kernel:
>>> Linux Legend 2.6.22.1 #5 Mon Aug 13 18:18:07 EDT 2007 mips unknown
>>>
>>> i tried to update (with ipkg, not opkg) but i have problem with 
>>> original
>>> openwrt feed:
>>> root at Legend:~# ipkg update
>>> Downloading
>>> http://downloads.openwrt.org/snapshots/atheros-2.6/packages/Packages
>>> wget: server returned error: HTTP/1.1 404 Not Found
>>> Downloading 
>>> http://downloads.openwrt.org/kamikaze/packages/mips/Packages
>>> wget: server returned error: HTTP/1.1 404 Not Found
>>> Downloading
>>> http://downloads.x-wrt.org/xwrt/kamikaze/snapshots/atheros-2.6/packages/Packages 
>>>
>>> wget: server returned error: HTTP/1.1 404 Not Found
>>> An error ocurred, return value: 3.
>>> Collected errors:
>>> ipkg_download: ERROR: Command failed with return value 1: `wget
>>> --passive-ftp    -q -P /tmp/ipkg-hCDHje
>>> http://downloads.openwrt.org/snapshots/atheros-2.6/packages/Packages'
>>> ipkg_download: ERROR: Command failed with return value 1: `wget
>>> --passive-ftp    -q -P /tmp/ipkg-hCDHje
>>> http://downloads.openwrt.org/kamikaze/packages/mips/Packages'
>>> ipkg_download: ERROR: Command failed with return value 1: `wget
>>> --passive-ftp    -q -P /tmp/ipkg-hCDHje
>>> http://downloads.x-wrt.org/xwrt/kamikaze/snapshots/atheros-2.6/packages/Packages' 
>>>
>>> root at Legend:~#
>>>
>>> so i tried with other ones but:
>>> root at Legend:~# ipkg update
>>> Downloading
>>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages 
>>>
>>> wget: not an http or ftp url:
>>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages 
>>>
>>> Downloading
>>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages 
>>>
>>> wget: not an http or ftp url:
>>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages 
>>>
>>> Downloading
>>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages 
>>>
>>> wget: not an http or ftp url:
>>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages 
>>>
>>> An error ocurred, return value: 3.
>>> Collected errors:
>>> ipkg_download: ERROR: Command failed with return value 1: `wget
>>> --passive-ftp    -q -P /tmp/ipkg-nErUJo
>>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages' 
>>>
>>> ipkg_download: ERROR: Command failed with return value 1: `wget
>>> --passive-ftp    -q -P /tmp/ipkg-nErUJo
>>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages' 
>>>
>>> ipkg_download: ERROR: Command failed with return value 1: `wget
>>> --passive-ftp    -q -P /tmp/ipkg-nErUJo
>>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages' 
>>>
>>> root at Legend:~#
>>>
>>> i got a more recent wget (wget_1.10.2-2_mips.ipk) but stil have 
>>> problems
>>> with ssl.
>>> anyway, browsing manually feeds i can't find driver.
>>>
>>> perhaps i NEED to use kamikaze 8.09 and all troubles will run away?
>>>
>>> again many thanks Andrew for your interest: this is my last chance 
>>> to use a
>>> microSD on my fonera 2100 :)
>>>
>>>
>>>
>>> Il 03/06/2016 15:49, Andrew Yong ha scritto:
>>>
>>> https://wiki.openwrt.org/doc/hardware/port.gpio and see relevant 
>>> sections
>>> for bitbanging MMC over GPIO.
>>>
>>> On 3 Jun 2016 21:46, "Marco Castrovilli" <marco.castrovilli at gmail.com>
>>> wrote:
>>>> hi all!
>>>> does anyone can help me to find mmc driver working on openwrt, 
>>>> installed
>>>> on fonera 2100 (mips architectire)?
>>>> thank you in advance.
>>>>
>>>> _______________________________________________
>>>> Lede-dev mailing list
>>>> Lede-dev at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>>



From dirkneukirchen at web.de  Sat Jun  4 22:02:52 2016
From: dirkneukirchen at web.de (Dirk Neukirchen)
Date: Sun, 5 Jun 2016 07:02:52 +0200
Subject: [LEDE-DEV] ar71xx kernel size starts getting oversized
In-Reply-To: <CAECwjAiGboOb2Z8exJ_toAAY-dmMDh9OYWt9XiT2x4ybZqPiLA@mail.gmail.com>
References: <CAECwjAi_6yZQevUOKB=A=___8gQnG3dELahEvDjvXysKGNNNPA@mail.gmail.com>
 <20160604124105.GB1892@makrotopia.org>
 <CAECwjAiGboOb2Z8exJ_toAAY-dmMDh9OYWt9XiT2x4ybZqPiLA@mail.gmail.com>
Message-ID: <4712d78a-3990-305a-ffe4-3fb8c77370bb@web.de>

On 04.06.2016 16:15, Yousong Zhou wrote:
> It has been quite a while since I tried building ar71xx kernel by
> deleting unneeded mach files first.  I believe the size reduction was
> not so impressive that I do not remember them at all...

Some results on TP-LINK WDR3600 target:

without mach-files:
 1835528  4. Jun 20:44 lede-ar71xx-generic-uImage-gzip.bin
 1294713  4. Jun 20:44 lede-ar71xx-generic-uImage-lzma.bin

with mach-files:
 1867906  4. Jun 20:35 lede-ar71xx-generic-uImage-gzip.bin
 1319890  4. Jun 20:35 lede-ar71xx-generic-uImage-lzma.bin

compile a normal image, switch to a new branch,
I removed mach-XXXX.c files in target/linux/ar71xx/files... ,
unset CONFIG_ATH79_MACH_XXXXX symbols target/linux/ar71xx/config-4.4 
make clean and make




From yszhou4tech at gmail.com  Sat Jun  4 22:05:03 2016
From: yszhou4tech at gmail.com (Yousong Zhou)
Date: Sun, 5 Jun 2016 13:05:03 +0800
Subject: [LEDE-DEV] ar71xx kernel size starts getting oversized
In-Reply-To: <CAECwjAiGboOb2Z8exJ_toAAY-dmMDh9OYWt9XiT2x4ybZqPiLA@mail.gmail.com>
References: <CAECwjAi_6yZQevUOKB=A=___8gQnG3dELahEvDjvXysKGNNNPA@mail.gmail.com>
 <20160604124105.GB1892@makrotopia.org>
 <CAECwjAiGboOb2Z8exJ_toAAY-dmMDh9OYWt9XiT2x4ybZqPiLA@mail.gmail.com>
Message-ID: <CAECwjAho0zHKk+A3bp_3Diuij6qN6hG-3eky=WZ5408AqJ6i+g@mail.gmail.com>

On 4 June 2016 at 22:15, Yousong Zhou <yszhou4tech at gmail.com> wrote:
> On 04/06/2016, Daniel Golle <daniel at makrotopia.org> wrote:
>> Hi Yousong,
>>
>> the main issue on ar71xx is the high number of mach-*.c files for all
>> the boards being included in *all* images. Once the target has been
>> migrated to device tree (which is a huge amount of work, lynxis has
>> done major progress there), this should easily free 500 kB of the
>> uncompressed kernel image.
>
> The lzma-compressed size has increased by more than 200KB.  I dont
> think it is caused by those mach files.
>
> It has been quite a while since I tried building ar71xx kernel by
> deleting unneeded mach files first.  I believe the size reduction was
> not so impressive that I do not remember them at all...

Here are some numbers just got by building LEDE master 29b412b8c5

With all mach files compiled in

-rwxr-xr-x 1 yousong yousong  4186524 Jun  5 12:37 vmlinux-hiwifi-hc6361
-rw-r--r-- 1 yousong yousong  1320762 Jun  5 12:38
vmlinux-hiwifi-hc6361.bin.lzma
-rw-r--r-- 1 yousong yousong  1320826 Jun  5 12:38 vmlinux-hiwifi-hc6361.uImage

Excluding non-relevant mach files by editing arch/mips/ath79/Makefile

-rwxr-xr-x 1 yousong yousong  4061516 Jun  5 12:42 vmlinux-hiwifi-hc6361
-rw-r--r-- 1 yousong yousong  1298961 Jun  5 12:42
vmlinux-hiwifi-hc6361.bin.lzma
-rw-r--r-- 1 yousong yousong  1299025 Jun  5 12:42 vmlinux-hiwifi-hc6361.uImage

About 100KB uncompressed size reduction, and 20KB reduction in compressed size.

                yousong

>
> Cheers
>                 yousong
>
>>
>> Cheers
>>
>> Daniel
>>
>> On Sat, Jun 04, 2016 at 12:49:04PM +0800, Yousong Zhou wrote:
>>> Several days ago I tried to build a firmware for HiWiFi-HC6361 with
>>> LEDE master branch.  Yet the firmware was not present in
>>> bin/targets/ar71xx/generic after the build completed.  I checked the
>>> downloads.lede-project.org the firmware was also missing there.
>>>
>>> The problem is that mtdparts layout of HC6361 requires the kernel part
>>> to be not bigger than 1280KB (1310720 bytes).  Yet the lzma-compressed
>>> kernel uImage has exceeded this size limit.
>>>
>>> The current size of lede-ar71xx-generic-uImage-lzma.bin in
>>> downloads.lede-project.org is 1367988
>>>
>>> The corresponding file in OpenWrt downloads site are as follows
>>>
>>>     snapshot         1295637
>>>     15.05.1            1176662
>>>     14.07               1107048
>>>
>>> My device is currently running 4.1.16 with OpenWrt r48975.  So the
>>> bloat probably comes from the 4.4 bump.  Sorry that at the moment I
>>> can just bring the issue up and cannot find time to do further
>>> investigation.
>>>
>>> Regards
>>>
>>>                 yousong
>>>
>>> _______________________________________________
>>> Lede-dev mailing list
>>> Lede-dev at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>
>
>
> --
>                 yousong


From jo at mein.io  Sun Jun  5 03:43:09 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Sun, 5 Jun 2016 12:43:09 +0200
Subject: [LEDE-DEV] Issues on brcm47xx, Buildbot config
In-Reply-To: <trinity-d03df1ff-d176-40c6-a1cf-05f6b1d8f11e-1465049826542@3capp-gmx-bs36>
References: <trinity-d03df1ff-d176-40c6-a1cf-05f6b1d8f11e-1465049826542@3capp-gmx-bs36>
Message-ID: <6f886d82-7302-0641-5d25-331d4eeaf89e@mein.io>

Hi,

can you check whether you can reproduce the hang when you enable kernel
debugging and kernel symbols?

See
http://phase1.builds.lede-project.org/builders/brcm47xx%2Flegacy/builds/60/steps/newconfig/logs/stdio
for the things the buildbot does besides choosing a target.

~ Jo


From tduszyns at gmail.com  Sun Jun  5 06:03:46 2016
From: tduszyns at gmail.com (Tomasz Duszynski)
Date: Sun,  5 Jun 2016 15:03:46 +0200
Subject: [LEDE-DEV] [PATCH 1/2] mail: imapfiler: use default imapfilter
	config options
Message-ID: <20160605130347.10573-1-tduszyns@gmail.com>

IMAP filtering is setup per user so it makes sense
to use settings defined under user's home directory.

Signed-off-by: Tomasz Duszynski <tduszyns at gmail.com>
---
 mail/imapfilter/patches/010-pathnames.patch | 31 -----------------------------
 1 file changed, 31 deletions(-)
 delete mode 100644 mail/imapfilter/patches/010-pathnames.patch

diff --git a/mail/imapfilter/patches/010-pathnames.patch b/mail/imapfilter/patches/010-pathnames.patch
deleted file mode 100644
index 6e9a43f..0000000
--- a/mail/imapfilter/patches/010-pathnames.patch
+++ /dev/null
@@ -1,31 +0,0 @@
---- a/pathnames.h
-+++ b/pathnames.h
-@@ -3,7 +3,7 @@
- 
- 
- /* Program's home directory. */
--#define PATHNAME_HOME			".imapfilter"
-+#define PATHNAME_HOME			"/etc/imapfilter"
- 
- /* Program's configuration file. */
- #define PATHNAME_CONFIG			PATHNAME_HOME "/config.lua"
-@@ -39,7 +39,7 @@
- #define PATHNAME_CERTS			PATHNAME_HOME "/certificates"
- 
- /* Debug temporary file template. */
--#define PATHNAME_DEBUG			PATHNAME_HOME "/debug.XXXXXX"
-+#define PATHNAME_DEBUG			"/tmp/imapfilterdebug.XXXXXX"
- 
- 
- #endif				/* PATHNAMES_H */
---- a/imapfilter.c
-+++ b/imapfilter.c
-@@ -50,7 +50,7 @@
- 	opts.config = NULL;
- 	opts.oneline = NULL;
- 
--	env.home = getenv("HOME");
-+	env.home = "";
- 	env.pathmax = -1;
- 
- 	while ((c = getopt(argc, argv, "Vc:de:il:v?")) != -1) {
-- 
2.8.3



From tduszyns at gmail.com  Sun Jun  5 06:03:47 2016
From: tduszyns at gmail.com (Tomasz Duszynski)
Date: Sun,  5 Jun 2016 15:03:47 +0200
Subject: [LEDE-DEV] [PATCH 2/2] mail: imapfilter: update imapfilter
In-Reply-To: <20160605130347.10573-1-tduszyns@gmail.com>
References: <20160605130347.10573-1-tduszyns@gmail.com>
Message-ID: <20160605130347.10573-2-tduszyns@gmail.com>

Update makefile to fetch imapfilter sources from project's repository and
build latest release.

Signed-off-by: Tomasz Duszynski <tduszyns at gmail.com>
---
 mail/imapfilter/Makefile | 51 ++++++++++++++++++++++--------------------------
 1 file changed, 23 insertions(+), 28 deletions(-)

diff --git a/mail/imapfilter/Makefile b/mail/imapfilter/Makefile
index 19ee723..1925fe7 100644
--- a/mail/imapfilter/Makefile
+++ b/mail/imapfilter/Makefile
@@ -1,5 +1,5 @@
 #
-# Copyright (C) 2006-2010 OpenWrt.org
+# Copyright (C) 2016 OpenWrt.org
 #
 # This is free software, licensed under the GNU General Public License v2.
 # See /LICENSE for more information.
@@ -8,12 +8,19 @@
 include $(TOPDIR)/rules.mk

 PKG_NAME:=imapfilter
-PKG_VERSION:=2.2.2
+PKG_VERSION:=2.6.6
 PKG_RELEASE:=1

-PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
-PKG_SOURCE_URL:=http://imapfilter.hellug.gr/source/
-PKG_MD5SUM:=09c6ffb085a5a244dc9f3e798259f341
+PKG_SOURCE_PROTO:=git
+PKG_SOURCE_URL:=https://github.com/lefcha/imapfilter.git
+PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
+PKG_SOURCE_VERSION:=075444786c53772395b69987da69f71716099f26
+PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.gz
+
+PKG_LICENSE:=MIT
+PKG_LICENSE_FILES:=LICENSE
+
+PKG_BUILD_PARALLEL:=1

 include $(INCLUDE_DIR)/package.mk

@@ -21,8 +28,8 @@ define Package/imapfilter
   SECTION:=mail
   CATEGORY:=Mail
   DEPENDS:=+liblua +libopenssl +libpcre
-  TITLE:=IMAP server based email filtering
-  URL:=http://imapfilter.hellug.gr/
+  TITLE:=A mail filtering utility for processing IMAP mailboxes
+  URL:=http://github.com/lefcha/imapfilter
 endef

 define Package/imapfilter/description
@@ -37,33 +44,21 @@ define Package/imapfilter/description
 	extension language.
 endef

-define Build/Configure
-	(cd $(PKG_BUILD_DIR); \
-		./configure \
-			-d /usr \
-	);
-endef
-
 define Build/Compile
-	$(MAKE) -C $(PKG_BUILD_DIR) \
-		$(TARGET_CONFIGURE_OPTS) \
-		INCDIRS="$(TARGET_CPPFLAGS)" \
-		LIBDIRS="$(TARGET_LDFLAGS)" \
-		MYCFLAGS="$(TARGET_CFLAGS) -std=gnu99" \
-		MYLDFLAGS="-lcrypt"
-endef
-
-define Package/imapfilter/conffiles
-/etc/imapfilter/config.lua
+	$(call Build/Compile/Default, \
+		DESTDIR=$(PKG_INSTALL_DIR) \
+		PREFIX="/usr" \
+		all install \
+	)
 endef

 define Package/imapfilter/install
 	$(INSTALL_DIR) $(1)/usr/bin
-	$(INSTALL_BIN) $(PKG_BUILD_DIR)/imapfilter $(1)/usr/bin/
-	$(INSTALL_DIR) $(1)/etc/imapfilter
-	$(INSTALL_CONF) $(PKG_BUILD_DIR)/sample.config.lua $(1)/etc/imapfilter/config.lua
+	$(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/imapfilter $(1)/usr/bin/
 	$(INSTALL_DIR) $(1)/usr/share/imapfilter
-	$(INSTALL_DATA) $(PKG_BUILD_DIR)/{account,auxiliary,common,mailbox,message,options,regex,set,deprecated}.lua $(1)/usr/share/imapfilter/
+	$(INSTALL_DATA) $(PKG_INSTALL_DIR)/usr/share/imapfilter/*.lua $(1)/usr/share/imapfilter/
+	$(INSTALL_DIR) $(1)/usr/share/imapfilter/samples
+	$(INSTALL_CONF) $(PKG_BUILD_DIR)/samples/{config,extend}.lua $(1)/usr/share/imapfilter/samples/
 endef

 $(eval $(call BuildPackage,imapfilter))
--
2.8.3



From xotic750 at gmail.com  Sun Jun  5 06:13:46 2016
From: xotic750 at gmail.com (Graham Fairweather)
Date: Sun, 5 Jun 2016 15:13:46 +0200
Subject: [LEDE-DEV] [PATCHv3 1/1] [brcm63xx] Add initial support for
	EVG2000
In-Reply-To: <CAD2Yd_ZPxL_68wykFiP1zCeVjsKFuO25oSoU9Kks3M0Km8ZCBA@mail.gmail.com>
References: <1463957783-9346-1-git-send-email-xotic750@gmail.com>
 <575156D8.5020602@gmail.com>
 <CAD2Yd_ZPxL_68wykFiP1zCeVjsKFuO25oSoU9Kks3M0Km8ZCBA@mail.gmail.com>
Message-ID: <CAD2Yd_ZqMiXwvJw+KX9K2W1z+w27XawCXYgN2xv-qrWnVkeqUg@mail.gmail.com>

It would great if someone with the knowledge could take at look and
see if they know why the 53115 switch is not detected so that this is
a fully working device.

On 3 June 2016 at 12:45, Graham Fairweather <xotic750 at gmail.com> wrote:
> Hi and thanks.
>
> On 3 June 2016 at 12:07, ?lvaro Fern?ndez Rojas <noltari at gmail.com> wrote:
>> Hello Graham,
>>
>> Pulled into my staging tree with some changes (whitespace fixes, cleanups...):
>> https://git.lede-project.org/?p=lede/noltari/staging.git;a=shortlog;h=refs/heads/brcm63xx-next
>>
>> Regards,
>> ?lvaro.
>>
>> El 23/5/16 a las 0:56, Xotic750 escribi?:
>>> From: Graham Fairweather <xotic750 at gmail.com>
>>>
>>> This patch adds support for the Netgear EVG2000 VoIP Gateway to the
>>> bcm63xx targets.
>>> Ran 'make target/linux/refresh V=s' after update to kernel 4.4.10 from
>>> 4.4.8 where the initial patch was added.
>>> This device was not sold to the general public, but rather is/was
>>> provided by telcos to customers in Sweden, Australia, Singapore and
>>> other parts of asia.
>>> System-On-Chip: Broadcom BCM6369 (2 * BMIPS4350 v3.1 / 400 MHz)
>>> Flash size: 16 MiB
>>> RAM size: 64 MiB
>>> Wireless: BCM4322 802.11b/g/n (onboard)
>>> Ethernet: Broadcom BCM53115
>>> USB: 2 x USB 2.0
>>> Known issues:
>>>  - Unable to detect 53115 switch. This appear to be a problem with
>>> probing for the PHY using MDIO and results in error 5. Doesn't seem to
>>> be a problem with the configuration, and could use someone with
>>> experience to have a look at it.
>>>  - Uses the b43 driver as using the OpenWRT/LEDE broadcom-wl driver
>>> fails to load the firmware for the 4322, so 802.11n is not supported.
>>> The factory build uses a newer broadcom-wl driver.
>>>  - No support for the 2 VoIP ports (not attempted)
>>> More info on the device and the research can be found at:
>>> https://wiki.openwrt.org/toh/netgear/evg2000
>>> https://wikidevi.com/wiki/Netgear_EVG2000
>>> https://github.com/Xotic750/mirror-lede/tree/evg2000
>>> https://forum.openwrt.org/viewtopic.php?id=63950
>>> Signed-off-by: Graham Fairweather <xotic750 at gmail.com>
>>> ---
>>>  .../linux/brcm63xx/base-files/etc/board.d/01_leds  |   7 ++
>>>  .../brcm63xx/base-files/etc/board.d/02_network     |   1 +
>>>  target/linux/brcm63xx/base-files/etc/diag.sh       |   3 +
>>>  .../base-files/etc/uci-defaults/09_fix_crc         |   2 +-
>>>  target/linux/brcm63xx/base-files/lib/brcm63xx.sh   |   3 +
>>>  .../lib/preinit/05_init_interfaces_brcm63xx        |   1 +
>>>  target/linux/brcm63xx/dts/evg2000.dts              | 103 +++++++++++++++++++++
>>>  target/linux/brcm63xx/image/Makefile               |   2 +
>>>  .../brcm63xx/patches-4.1/575-board_EVG2000.patch   |  62 +++++++++++++
>>>  ...-m25p80-use-parsers-if-provided-in-flash-.patch |   2 +-
>>>  ...CES-m25p80-add-support-for-limiting-reads.patch |   4 +-
>>>  .../414-MTD-m25p80-allow-passing-pp_data.patch     |   2 +-
>>>  .../brcm63xx/patches-4.4/575-board_EVG2000.patch   |  62 +++++++++++++
>>>  target/linux/brcm63xx/profiles/netgear.mk          |  10 ++
>>>  14 files changed, 259 insertions(+), 5 deletions(-)
>>>  create mode 100644 target/linux/brcm63xx/dts/evg2000.dts
>>>  create mode 100644 target/linux/brcm63xx/patches-4.1/575-board_EVG2000.patch
>>>  create mode 100644 target/linux/brcm63xx/patches-4.4/575-board_EVG2000.patch
>>>
>>> diff --git a/target/linux/brcm63xx/base-files/etc/board.d/01_leds b/target/linux/brcm63xx/base-files/etc/board.d/01_leds
>>> index 8339254..4163214 100755
>>> --- a/target/linux/brcm63xx/base-files/etc/board.d/01_leds
>>> +++ b/target/linux/brcm63xx/base-files/etc/board.d/01_leds
>>> @@ -24,6 +24,13 @@ dgnd3700v1_dgnd3800b)
>>>       ucidef_set_led_usbdev "usb1" "USB1" "DGND3700v1_3800B:green:usb-back" "1-1"
>>>       ucidef_set_led_usbdev "usb2" "USB2" "DGND3700v1_3800B:green:usb-front" "1-2"
>>>       ;;
>>> +evg2000)
>>> +     ucidef_set_led_netdev "lan" "LAN" "EVG2000:green:lan" "eth0"
>>> +     ucidef_set_led_netdev "wan" "WAN" "EVG2000:green:wan" "eth1"
>>> +     ucidef_set_led_netdev "wlan0" "WIFI" "EVG2000:green:wireless" "wlan0"
>>> +     ucidef_set_led_usbdev "usb1" "USB1" "EVG2000:green:voip1" "1-1"
>>> +     ucidef_set_led_usbdev "usb2" "USB2" "EVG2000:green:voip2" "1-2"
>>> +     ;;
>>>  fast2704n)
>>>       ucidef_set_led_netdev "wan" "WAN" "F at ST2704N:green:inet" "eth0.2"
>>>       ;;
>>> diff --git a/target/linux/brcm63xx/base-files/etc/board.d/02_network b/target/linux/brcm63xx/base-files/etc/board.d/02_network
>>> index f96da08..83367c1 100755
>>> --- a/target/linux/brcm63xx/base-files/etc/board.d/02_network
>>> +++ b/target/linux/brcm63xx/base-files/etc/board.d/02_network
>>> @@ -11,6 +11,7 @@ board_config_update
>>>  case "$(brcm63xx_board_name)" in
>>>
>>>  cvg834g |\
>>> +evg2000 |\
>>>  rta770bw |\
>>>  rta770w |\
>>>  spw303v |\
>>> diff --git a/target/linux/brcm63xx/base-files/etc/diag.sh b/target/linux/brcm63xx/base-files/etc/diag.sh
>>> index b864964..6ac2459 100644
>>> --- a/target/linux/brcm63xx/base-files/etc/diag.sh
>>> +++ b/target/linux/brcm63xx/base-files/etc/diag.sh
>>> @@ -70,6 +70,9 @@ set_state() {
>>>       dgnd3700v1_dgnd3800b)
>>>               status_led="DGND3700v1_3800B:green:power"
>>>               ;;
>>> +     evg2000)
>>> +             status_led="EVG2000:green:power"
>>> +             ;;
>>>       fast2504n)
>>>               status_led="fast2504n:green:ok"
>>>               ;;
>>> diff --git a/target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc b/target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc
>>> index 70dbe2a..1201168 100644
>>> --- a/target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc
>>> +++ b/target/linux/brcm63xx/base-files/etc/uci-defaults/09_fix_crc
>>> @@ -21,6 +21,7 @@ case "$(brcm63xx_board_name)" in
>>>       cpva642 |\
>>>       ct-6373 |\
>>>       dsl-274xb-f |\
>>> +     evg2000 |\
>>>       hg622 |\
>>>       magic |\
>>>       p870hw-51a_v2 |\
>>> @@ -37,4 +38,3 @@ case "$(brcm63xx_board_name)" in
>>>               do_fixcrc
>>>               ;;
>>>  esac
>>> -
>>> diff --git a/target/linux/brcm63xx/base-files/lib/brcm63xx.sh b/target/linux/brcm63xx/base-files/lib/brcm63xx.sh
>>> index a2d6519..9cc0b2b 100755
>>> --- a/target/linux/brcm63xx/base-files/lib/brcm63xx.sh
>>> +++ b/target/linux/brcm63xx/base-files/lib/brcm63xx.sh
>>> @@ -183,6 +183,9 @@ brcm63xx_dt_detect() {
>>>       "Netgear DGND3700v1/DGND3800B")
>>>               board_name="dgnd3700v1_dgnd3800b"
>>>               ;;
>>> +     "Netgear EVG2000")
>>> +             board_name="evg2000"
>>> +             ;;
>>>       "NuCom R5010UN v2")
>>>               board_name="r5010un_v2"
>>>               ;;
>>> diff --git a/target/linux/brcm63xx/base-files/lib/preinit/05_init_interfaces_brcm63xx b/target/linux/brcm63xx/base-files/lib/preinit/05_init_interfaces_brcm63xx
>>> index 7e4dfcb..1e3fc14 100644
>>> --- a/target/linux/brcm63xx/base-files/lib/preinit/05_init_interfaces_brcm63xx
>>> +++ b/target/linux/brcm63xx/base-files/lib/preinit/05_init_interfaces_brcm63xx
>>> @@ -18,6 +18,7 @@ set_preinit_iface() {
>>>       dsl-274xb-c |\
>>>       dsl-274xb-f |\
>>>       dsl-275xb-d |\
>>> +     evg2000 |\
>>>       fast2504n |\
>>>       fast2704v2 |\
>>>       hg553 |\
>>> diff --git a/target/linux/brcm63xx/dts/evg2000.dts b/target/linux/brcm63xx/dts/evg2000.dts
>>> new file mode 100644
>>> index 0000000..04f7b84
>>> --- /dev/null
>>> +++ b/target/linux/brcm63xx/dts/evg2000.dts
>>> @@ -0,0 +1,103 @@
>>> +/dts-v1/;
>>> +
>>> +#include "bcm6368.dtsi"
>>> +
>>> +#include <dt-bindings/input/input.h>
>>> +
>>> +/ {
>>> +     model = "Netgear EVG2000";
>>> +     compatible = "netgear,evg2000", "brcm,bcm6368";
>>> +
>>> +     gpio-keys-polled {
>>> +             compatible = "gpio-keys-polled";
>>> +             #address-cells = <1>;
>>> +             #size-cells = <0>;
>>> +             poll-interval = <20>;
>>> +             debounce-interval = <60>;
>>> +
>>> +             reset {
>>> +                     label = "reset";
>>> +                     gpios = <&gpio0 25 1>;
>>> +                     linux,code = <KEY_RESTART>;
>>> +             };
>>> +             wps {
>>> +                     label = "wps";
>>> +                     gpios = <&gpio0 26 1>;
>>> +                     linux,code = <KEY_WPS_BUTTON>;
>>> +             };
>>> +     };
>>> +
>>> +     gpio-leds {
>>> +             compatible = "gpio-leds";
>>> +
>>> +             voip1_green {
>>> +                     label = "EVG2000:green:voip1";
>>> +                     gpios = <&gpio0 14 1>;
>>> +             };
>>> +             voip2_green {
>>> +                     label = "EVG2000:green:voip2";
>>> +                     gpios = <&gpio0 2 1>;
>>> +             };
>>> +             inet_red {
>>> +                     label = "EVG2000:red:inet";
>>> +                     gpios = <&gpio0 4 1>;
>>> +             };
>>> +             inet_green {
>>> +                     label = "EVG2000:green:inet";
>>> +                     gpios = <&gpio0 5 1>;
>>> +             };
>>> +             usb_green {
>>> +                     label = "EVG2000:green:usb";
>>> +                     gpios = <&gpio0 15 1>;
>>> +             };
>>> +             power_green {
>>> +                     label = "EVG2000:green:power";
>>> +                     gpios = <&gpio0 22 1>;
>>> +                     default-state = "on";
>>> +             };
>>> +             power_red {
>>> +                     label = "EVG2000:red:power";
>>> +                     gpios = <&gpio0 23 1>;
>>> +             };
>>> +             lan_green {
>>> +                     label = "EVG2000:green:lan";
>>> +                     gpios = <&gpio0 24 1>;
>>> +             };
>>> +             wireless_green {
>>> +                     label = "EVG2000:green:wireless";
>>> +                     gpios = <&gpio0 26 1>;
>>> +             };
>>> +             wan_green {
>>> +                     label = "EVG2000:green:wan";
>>> +                     gpios = <&gpio0 27 1>;
>>> +             };
>>> +     };
>>> +};
>>> +
>>> +&pflash {
>>> +     status = "ok";
>>> +
>>> +     linux,part-probe = "bcm63xxpart";
>>> +
>>> +     cfe at 0 {
>>> +                     label = "CFE";
>>> +                     reg = <0x00000000 0x00020000>;
>>> +                     read-only;
>>> +     };
>>> +
>>> +     linux at 20000 {
>>> +                     label = "linux";
>>> +                     reg = <0x00020000 0x00f40000>;
>>> +     };
>>> +
>>> +     board_data at f60000 {
>>> +                     label = "board_data";
>>> +                     reg = <0x00f60000 0x00080000>;
>>> +                     read-only;
>>> +     };
>>> +
>>> +     nvram at fe0000 {
>>> +                     label = "nvram";
>>> +                     reg = <0x00fe0000 0x00020000>;
>>> +     };
>>> +};
>>> diff --git a/target/linux/brcm63xx/image/Makefile b/target/linux/brcm63xx/image/Makefile
>>> index e00b6fb..f1fb86b 100644
>>> --- a/target/linux/brcm63xx/image/Makefile
>>> +++ b/target/linux/brcm63xx/image/Makefile
>>> @@ -593,6 +593,8 @@ $(eval $(call bcm63xxCfeRamdisk,DG834GV4,DG834GTv4,dg834g_v4,96348W3,6348))
>>>  $(eval $(call bcm63xxCfeNetgear,DGND3700v1_3800B,DGND3700v1,dgnd3700v1,96368MVWG,6368,--image-offset 0x20000 --block-size 0x20000,U12L144T01_NETGEAR_NEWLED,1))
>>>  # Netgear DGND3800B
>>>  $(eval $(call bcm63xxCfeNetgear,DGND3700v1_3800B,DGND3800B,dgnd3700v1,96368MVWG,6368,--image-offset 0x20000 --block-size 0x20000,U12L144T11_NETGEAR_NEWLED,1))
>>> +# Netgear EVG2000
>>> +$(eval $(call bcm63xxCfeNetgear,EVG2000,EVG2000,evg2000,96369PVG,6369,--image-offset 0x20000 --block-size 0x20000,U12H154T90_NETGEAR,1))
>>>  # NuCom R5010UNv2
>>>  $(eval $(call bcm63xxCfe,R5010UNV2,R5010UNv2,r5010unv2,96328ang,6328,--pad 8))
>>>  # Pirelli Alice Gate VoIP 2 Plus Wi-Fi AGPF-S0
>>> diff --git a/target/linux/brcm63xx/patches-4.1/575-board_EVG2000.patch b/target/linux/brcm63xx/patches-4.1/575-board_EVG2000.patch
>>> new file mode 100644
>>> index 0000000..9339085
>>> --- /dev/null
>>> +++ b/target/linux/brcm63xx/patches-4.1/575-board_EVG2000.patch
>>> @@ -0,0 +1,62 @@
>>> +--- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
>>> ++++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c
>>> +@@ -2010,6 +2010,43 @@ static struct board_info __initdata boar
>>> +     .num_spis = ARRAY_SIZE(DGND3700v1_3800B_spi_devices),
>>> + };
>>> +
>>> ++static struct sprom_fixup __initdata EVG2000_fixups[] = {
>>> ++  { .offset = 219, .value = 0xec08 },
>>> ++};
>>> ++
>>> ++static struct board_info __initdata board_EVG2000 = {
>>> ++    .name                           = "96369PVG",
>>> ++    .expected_cpu_id                = 0x6368,
>>> ++
>>> ++    .has_uart0                      = 1,
>>> ++    .has_pci                        = 1,
>>> ++    .has_ohci0                      = 1,
>>> ++    .has_ehci0                      = 1,
>>> ++    .num_usbh_ports                 = 2,
>>> ++
>>> ++    .has_enetsw                     = 1,
>>> ++    .enetsw = {
>>> ++            .used_ports = {
>>> ++                    [5] = {
>>> ++                            .used  = 1,
>>> ++                            .phy_id  = 0xff,
>>> ++                            .bypass_link = 1,
>>> ++                            .force_speed = 1000,
>>> ++                            .force_duplex_full = 1,
>>> ++                            .name  = "RGMII",
>>> ++                    },
>>> ++            },
>>> ++    },
>>> ++    .use_fallback_sprom     = 1,
>>> ++    .fallback_sprom = {
>>> ++                    .type               = SPROM_BCM4322,
>>> ++                    .pci_bus            = 0,
>>> ++                    .pci_dev            = 1,
>>> ++                    .board_fixups                   = EVG2000_fixups,
>>> ++                    .num_board_fixups               = ARRAY_SIZE(EVG2000_fixups),
>>> ++    },
>>> ++};
>>> ++
>>> + static struct board_info __initdata board_HG655b = {
>>> +     .name                           = "HW65x",
>>> +     .expected_cpu_id                = 0x6368,
>>> +@@ -2610,6 +2647,7 @@ static const struct board_info __initcon
>>> +     &board_96368mvwg,
>>> +     &board_96368mvngr,
>>> +     &board_DGND3700v1_3800B,
>>> ++    &board_EVG2000,
>>> +     &board_HG622,
>>> +     &board_HG655b,
>>> +     &board_P870HW51A_V2,
>>> +@@ -2722,6 +2760,7 @@ static struct of_device_id const bcm963x
>>> +     { .compatible = "huawei,hg622", .data = &board_HG622, },
>>> +     { .compatible = "huawei,hg655b", .data = &board_HG655b, },
>>> +     { .compatible = "netgear,dgnd3700v1", .data = &board_DGND3700v1_3800B, },
>>> ++    { .compatible = "netgear,evg2000", .data = &board_EVG2000, },
>>> +     { .compatible = "zyxel,p870hw-51a-v2", .data = &board_P870HW51A_V2, },
>>> + #endif
>>> + #ifdef CONFIG_BCM63XX_CPU_63268
>>> diff --git a/target/linux/brcm63xx/patches-4.4/202-MTD-DEVICES-m25p80-use-parsers-if-provided-in-flash-.patch b/target/linux/brcm63xx/patches-4.4/202-MTD-DEVICES-m25p80-use-parsers-if-provided-in-flash-.patch
>>> index be62e67..4793836 100644
>>> --- a/target/linux/brcm63xx/patches-4.4/202-MTD-DEVICES-m25p80-use-parsers-if-provided-in-flash-.patch
>>> +++ b/target/linux/brcm63xx/patches-4.4/202-MTD-DEVICES-m25p80-use-parsers-if-provided-in-flash-.patch
>>> @@ -11,7 +11,7 @@ Signed-off-by: Jonas Gorski <jonas.gorski at gmail.com>
>>>
>>>  --- a/drivers/mtd/devices/m25p80.c
>>>  +++ b/drivers/mtd/devices/m25p80.c
>>> -@@ -229,7 +229,8 @@ static int m25p_probe(struct spi_device
>>> +@@ -251,7 +251,8 @@ static int m25p_probe(struct spi_device
>>>
>>>       ppdata.of_node = spi->dev.of_node;
>>>
>>> diff --git a/target/linux/brcm63xx/patches-4.4/203-MTD-DEVICES-m25p80-add-support-for-limiting-reads.patch b/target/linux/brcm63xx/patches-4.4/203-MTD-DEVICES-m25p80-add-support-for-limiting-reads.patch
>>> index 3877442..75a874d 100644
>>> --- a/target/linux/brcm63xx/patches-4.4/203-MTD-DEVICES-m25p80-add-support-for-limiting-reads.patch
>>> +++ b/target/linux/brcm63xx/patches-4.4/203-MTD-DEVICES-m25p80-add-support-for-limiting-reads.patch
>>> @@ -28,7 +28,7 @@ Signed-off-by: Jonas Gorski <jonas.gorski at gmail.com>
>>>                       size_t *retlen, u_char *buf)
>>>   {
>>>       struct m25p *flash = nor->priv;
>>> -@@ -152,6 +153,29 @@ static int m25p80_read(struct spi_nor *n
>>> +@@ -174,6 +175,29 @@ static int m25p80_read(struct spi_nor *n
>>>       return 0;
>>>   }
>>>
>>> @@ -58,7 +58,7 @@ Signed-off-by: Jonas Gorski <jonas.gorski at gmail.com>
>>>   static int m25p80_erase(struct spi_nor *nor, loff_t offset)
>>>   {
>>>       struct m25p *flash = nor->priv;
>>> -@@ -223,6 +247,9 @@ static int m25p_probe(struct spi_device
>>> +@@ -245,6 +269,9 @@ static int m25p_probe(struct spi_device
>>>       else
>>>               flash_name = spi->modalias;
>>>
>>> diff --git a/target/linux/brcm63xx/patches-4.4/414-MTD-m25p80-allow-passing-pp_data.patch b/target/linux/brcm63xx/patches-4.4/414-MTD-m25p80-allow-passing-pp_data.patch
>>> index e421e9a..bbb565e 100644
>>> --- a/target/linux/brcm63xx/patches-4.4/414-MTD-m25p80-allow-passing-pp_data.patch
>>> +++ b/target/linux/brcm63xx/patches-4.4/414-MTD-m25p80-allow-passing-pp_data.patch
>>> @@ -10,7 +10,7 @@ Subject: [PATCH 64/79] MTD: m25p80: allow passing pp_data
>>>
>>>  --- a/drivers/mtd/devices/m25p80.c
>>>  +++ b/drivers/mtd/devices/m25p80.c
>>> -@@ -250,6 +250,9 @@ static int m25p_probe(struct spi_device
>>> +@@ -272,6 +272,9 @@ static int m25p_probe(struct spi_device
>>>       if (data)
>>>               flash->max_transfer_len = data->max_transfer_len;
>>>
>>> diff --git a/target/linux/brcm63xx/patches-4.4/575-board_EVG2000.patch b/target/linux/brcm63xx/patches-4.4/575-board_EVG2000.patch
>>> new file mode 100644
>>> index 0000000..fc7afc7
>>> --- /dev/null
>>> +++ b/target/linux/brcm63xx/patches-4.4/575-board_EVG2000.patch
>>> @@ -0,0 +1,62 @@
>>> +--- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
>>> ++++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c
>>> +@@ -2011,6 +2011,43 @@ static struct board_info __initdata boar
>>> +     .num_spis = ARRAY_SIZE(DGND3700v1_3800B_spi_devices),
>>> + };
>>> +
>>> ++static struct sprom_fixup __initdata EVG2000_fixups[] = {
>>> ++  { .offset = 219, .value = 0xec08 },
>>> ++};
>>> ++
>>> ++static struct board_info __initdata board_EVG2000 = {
>>> ++    .name                           = "96369PVG",
>>> ++    .expected_cpu_id                = 0x6368,
>>> ++
>>> ++    .has_uart0                      = 1,
>>> ++    .has_pci                        = 1,
>>> ++    .has_ohci0                      = 1,
>>> ++    .has_ehci0                      = 1,
>>> ++    .num_usbh_ports                 = 2,
>>> ++
>>> ++    .has_enetsw                     = 1,
>>> ++    .enetsw = {
>>> ++            .used_ports = {
>>> ++                    [5] = {
>>> ++                            .used  = 1,
>>> ++                            .phy_id  = 0xff,
>>> ++                            .bypass_link = 1,
>>> ++                            .force_speed = 1000,
>>> ++                            .force_duplex_full = 1,
>>> ++                            .name  = "RGMII",
>>> ++                    },
>>> ++            },
>>> ++    },
>>> ++    .use_fallback_sprom     = 1,
>>> ++    .fallback_sprom = {
>>> ++                    .type               = SPROM_BCM4322,
>>> ++                    .pci_bus            = 0,
>>> ++                    .pci_dev            = 1,
>>> ++                    .board_fixups                   = EVG2000_fixups,
>>> ++                    .num_board_fixups               = ARRAY_SIZE(EVG2000_fixups),
>>> ++    },
>>> ++};
>>> ++
>>> + static struct board_info __initdata board_HG655b = {
>>> +     .name                           = "HW65x",
>>> +     .expected_cpu_id                = 0x6368,
>>> +@@ -2611,6 +2648,7 @@ static const struct board_info __initcon
>>> +     &board_96368mvwg,
>>> +     &board_96368mvngr,
>>> +     &board_DGND3700v1_3800B,
>>> ++    &board_EVG2000,
>>> +     &board_HG622,
>>> +     &board_HG655b,
>>> +     &board_P870HW51A_V2,
>>> +@@ -2723,6 +2761,7 @@ static struct of_device_id const bcm963x
>>> +     { .compatible = "huawei,hg622", .data = &board_HG622, },
>>> +     { .compatible = "huawei,hg655b", .data = &board_HG655b, },
>>> +     { .compatible = "netgear,dgnd3700v1", .data = &board_DGND3700v1_3800B, },
>>> ++    { .compatible = "netgear,evg2000", .data = &board_EVG2000, },
>>> +     { .compatible = "zyxel,p870hw-51a-v2", .data = &board_P870HW51A_V2, },
>>> + #endif
>>> + #ifdef CONFIG_BCM63XX_CPU_63268
>>> diff --git a/target/linux/brcm63xx/profiles/netgear.mk b/target/linux/brcm63xx/profiles/netgear.mk
>>> index bc345bb..e3bc34a 100644
>>> --- a/target/linux/brcm63xx/profiles/netgear.mk
>>> +++ b/target/linux/brcm63xx/profiles/netgear.mk
>>> @@ -41,3 +41,13 @@ define Profile/DGND3700v1_3800B/Description
>>>    Package set optimized for DGND3700 v1 / DGND3800B.
>>>  endef
>>>  $(eval $(call Profile,DGND3700v1_3800B))
>>> +
>>> +define Profile/EVG2000
>>> +  NAME:=Netgear EVG2000
>>> +  PACKAGES:=kmod-b43 wpad-mini \
>>> +     kmod-usb2 kmod-usb-ohci kmod-ledtrig-usbdev
>>> +endef
>>> +define Profile/EVG2000/Description
>>> +  Package set optimized for EVG2000.
>>> +endef
>>> +$(eval $(call Profile,EVG2000))
>>


From jonas.gorski at gmail.com  Sun Jun  5 06:37:06 2016
From: jonas.gorski at gmail.com (Jonas Gorski)
Date: Sun, 5 Jun 2016 15:37:06 +0200
Subject: [LEDE-DEV] [PATCHv3 1/1] [brcm63xx] Add initial support for
	EVG2000
In-Reply-To: <CAD2Yd_ZqMiXwvJw+KX9K2W1z+w27XawCXYgN2xv-qrWnVkeqUg@mail.gmail.com>
References: <1463957783-9346-1-git-send-email-xotic750@gmail.com>
 <575156D8.5020602@gmail.com>
 <CAD2Yd_ZPxL_68wykFiP1zCeVjsKFuO25oSoU9Kks3M0Km8ZCBA@mail.gmail.com>
 <CAD2Yd_ZqMiXwvJw+KX9K2W1z+w27XawCXYgN2xv-qrWnVkeqUg@mail.gmail.com>
Message-ID: <CAOiHx=nAd1hb52yud8d1kjyWeDcPzhKYD=b63+5h+oEOdyqDxw@mail.gmail.com>

Hi,

On 5 June 2016 at 15:13, Graham Fairweather <xotic750 at gmail.com> wrote:
> It would great if someone with the knowledge could take at look and
> see if they know why the 53115 switch is not detected so that this is
> a fully working device.

MDIO connected switches aren't currently supported for bcm6368 and
newer, only SPI connected ones (it's a driver limitation). Assuming it
is MDIO connected.


Jonas


From xotic750 at gmail.com  Sun Jun  5 06:48:20 2016
From: xotic750 at gmail.com (Graham Fairweather)
Date: Sun, 5 Jun 2016 15:48:20 +0200
Subject: [LEDE-DEV] [PATCHv3 1/1] [brcm63xx] Add initial support for
	EVG2000
In-Reply-To: <CAOiHx=nAd1hb52yud8d1kjyWeDcPzhKYD=b63+5h+oEOdyqDxw@mail.gmail.com>
References: <1463957783-9346-1-git-send-email-xotic750@gmail.com>
 <575156D8.5020602@gmail.com>
 <CAD2Yd_ZPxL_68wykFiP1zCeVjsKFuO25oSoU9Kks3M0Km8ZCBA@mail.gmail.com>
 <CAD2Yd_ZqMiXwvJw+KX9K2W1z+w27XawCXYgN2xv-qrWnVkeqUg@mail.gmail.com>
 <CAOiHx=nAd1hb52yud8d1kjyWeDcPzhKYD=b63+5h+oEOdyqDxw@mail.gmail.com>
Message-ID: <CAD2Yd_ao8em-QA8rHhd355hdGnE2puy4DKdQBmX5jMAObj+QOA@mail.gmail.com>

Aha. It is MDIO as far as I am aware. Is this something new/changed,
because whoever tested it originally (when 'roboswitch' was in the
build) was able to detect it?

https://wiki.openwrt.org/toh/netgear/evg2000#openwrt_test_bootlog_bcm6368_cpu_id_6369

On 5 June 2016 at 15:37, Jonas Gorski <jonas.gorski at gmail.com> wrote:
> Hi,
>
> On 5 June 2016 at 15:13, Graham Fairweather <xotic750 at gmail.com> wrote:
>> It would great if someone with the knowledge could take at look and
>> see if they know why the 53115 switch is not detected so that this is
>> a fully working device.
>
> MDIO connected switches aren't currently supported for bcm6368 and
> newer, only SPI connected ones (it's a driver limitation). Assuming it
> is MDIO connected.
>
>
> Jonas


From jo at mein.io  Sun Jun  5 08:39:14 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Sun, 5 Jun 2016 17:39:14 +0200
Subject: [LEDE-DEV] IXP4xx support for LEDE kernel v4.4
In-Reply-To: <1464988320.24268.11.camel@kitschensync.net>
References: <1464988320.24268.11.camel@kitschensync.net>
Message-ID: <3b3eacca-d152-421b-fdce-bc2df16dc773@mein.io>

Hi Ted,

from a cursory look it appears fine to me and since you runtime tested
it on your Slug already I'd say go for it.

~ Jo


From lede at kitschensync.net  Sun Jun  5 10:19:50 2016
From: lede at kitschensync.net (Ted Hess)
Date: Sun, 05 Jun 2016 13:19:50 -0400
Subject: [LEDE-DEV] IXP4xx support for LEDE kernel v4.4
In-Reply-To: <3b3eacca-d152-421b-fdce-bc2df16dc773@mein.io>
References: <1464988320.24268.11.camel@kitschensync.net>
 <3b3eacca-d152-421b-fdce-bc2df16dc773@mein.io>
Message-ID: <1465147190.26998.11.camel@kitschensync.net>

On Sun, 2016-06-05 at 17:39 +0200, Jo-Philipp Wich wrote:
> Hi Ted,
> 
> from a cursory look it appears fine to me and since you runtime tested
> it on your Slug already I'd say go for it.
> 
> ~ Jo
> 

Current maintainer is Kaloz - should I leave it as is?

/ted



From nbd at nbd.name  Sun Jun  5 11:02:11 2016
From: nbd at nbd.name (Felix Fietkau)
Date: Sun, 5 Jun 2016 20:02:11 +0200
Subject: [LEDE-DEV] IXP4xx support for LEDE kernel v4.4
In-Reply-To: <1465147190.26998.11.camel@kitschensync.net>
References: <1464988320.24268.11.camel@kitschensync.net>
 <3b3eacca-d152-421b-fdce-bc2df16dc773@mein.io>
 <1465147190.26998.11.camel@kitschensync.net>
Message-ID: <28b49115-0044-17c7-8fb2-5d6a0f14aae1@nbd.name>

On 2016-06-05 19:19, Ted Hess wrote:
> On Sun, 2016-06-05 at 17:39 +0200, Jo-Philipp Wich wrote:
>> Hi Ted,
>> 
>> from a cursory look it appears fine to me and since you runtime tested
>> it on your Slug already I'd say go for it.
>> 
>> ~ Jo
>> 
> 
> Current maintainer is Kaloz - should I leave it as is?
Feel free to change the maintainer to yourself. I don't see any
indication that Kaloz is planning on joining LEDE.

- Felix


From p.wassi at gmx.at  Sun Jun  5 15:10:44 2016
From: p.wassi at gmx.at (p.wassi at gmx.at)
Date: Mon, 6 Jun 2016 00:10:44 +0200
Subject: [LEDE-DEV] Issues on brcm47xx, Buildbot config
In-Reply-To: <6f886d82-7302-0641-5d25-331d4eeaf89e@mein.io>
References: <trinity-d03df1ff-d176-40c6-a1cf-05f6b1d8f11e-1465049826542@3capp-gmx-bs36>, 
 <6f886d82-7302-0641-5d25-331d4eeaf89e@mein.io>
Message-ID: <trinity-1c0d5f3d-0a2a-42c6-9cdb-e1e6f0e7dacf-1465164644629@3capp-gmx-bs37>

Hi jow,

I already had CONFIG_KERNEL_KALLSYMS enabled (seems to be default).
However, I've checked with the file, you gave me earlier [1].
I was NOT able to reproduce the problem. I.e. buildbot's images
do not boot, while mine boot on WRT54G(L) even when using your config.

Regarding [1], I did the linked config locally, however, these differences
remain: (this represents my config)
# CONFIG_SDK is not set
# CONFIG_IB is not set
(therefore CONFIG_IB_STANDALONE is not present at all)
CONFIG_PER_FEED_REPO_ADD_COMMENTED=y

The first differences regarding SDK and Imagebuilder shouldn't
have any influence on the problem; for the last one, I don't know
what this is doing.

Best regards,
P.Wassi

[1]:
http://phase1.builds.lede-project.org/builders/brcm47xx%2Flegacy/builds/60/steps/newconfig/logs/stdio


From marco.castrovilli at gmail.com  Sun Jun  5 17:00:04 2016
From: marco.castrovilli at gmail.com (Marco Castrovilli)
Date: Mon, 6 Jun 2016 02:00:04 +0200
Subject: [LEDE-DEV] mmc driver for openwrt on fonera 2100
In-Reply-To: <fd26bcc1-4b01-db20-f4af-16c9c70feb25@gmail.com>
References: <56700383-6ffd-72a4-fca6-f46e582eff90@gmail.com>
 <CA+yTfBBGrvy8r8yiZ+ZNf-4m1Ss1==fr95HvgEaQ4WrwB_XBTw@mail.gmail.com>
 <13d21777-d42d-bcab-4831-542c87fa0a14@gmail.com>
 <CA+yTfBCViAFD=pOTmfro=S5vyEJcbsjZ8ijHbbTpkOGPyaH9hA@mail.gmail.com>
 <2c0e0357-a4c3-76c4-ab64-b7f82744956c@gmail.com>
 <fd26bcc1-4b01-db20-f4af-16c9c70feb25@gmail.com>
Message-ID: <0e876e36-0aa7-2458-164b-44b0472ca24c@gmail.com>

i tried 8.09.2 too.

always the same behaviour: everything is ok until i enable 
/etc/init.d/mmc_over_gpio: then network become unstable and i can't get 
ssh connection anymore.

:(


Il 05/06/2016 02:02, Marco Castrovilli ha scritto:
> hi andrew. no good news. i flashed again fonera and followed 
> instruction of the guide but:
>
> when i try command uci set mmc_over_gpio. at mmc_over_gpio[0].enabled=1 i 
> have uci: Entry not found message;
>
> uci is ok: other commands (uci add fstab mount etc. etc) are correctly 
> executed;
>
> when i try starting mmc_over_gpio, fonera reboot and connection become 
> ustable.
>
> below you can find details.
>
> perhaps does this mean that soldered points are not good? or do i 
> forget some fundamental step?
>
> thank you for your opinion.
>
>
> login as: root
> root at 192.168.1.1's password:
>
>
> BusyBox v1.11.2 (2009-01-05 06:34:55 CET) built-in shell (ash)
> Enter 'help' for a list of built-in commands.
>
>   _______                     ________        __
>  |       |.-----.-----.-----.|  |  |  |.----.|  |_
>  |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
>  |_______||   __|_____|__|__||________||__|  |____|
>           |__| W I R E L E S S   F R E E D O M
>  KAMIKAZE (8.09, r14511) ----------------------------
>   * 10 oz Vodka       Shake well with ice and strain
>   * 10 oz Triple sec  mixture into 10 shot glasses.
>   * 10 oz lime juice  Salute!
>  ---------------------------------------------------
> root at OpenWrt:~# free
>               total         used         free       shared buffers
>   Mem:        13688         7808         5880 0            0
>  Swap:            0            0            0
> Total:        13688         7808         5880
> root at OpenWrt:~# ping 192.168.1.171
> PING 192.168.1.171 (192.168.1.171): 56 data bytes
> 64 bytes from 192.168.1.171: seq=0 ttl=128 time=3.857 ms
> 64 bytes from 192.168.1.171: seq=1 ttl=128 time=3.451 ms
> 64 bytes from 192.168.1.171: seq=2 ttl=128 time=2.674 ms
> 64 bytes from 192.168.1.171: seq=3 ttl=128 time=6.248 ms
> 64 bytes from 192.168.1.171: seq=4 ttl=128 time=3.290 ms
> ^C
> --- 192.168.1.171 ping statistics ---
> 5 packets transmitted, 5 packets received, 0% packet loss
> round-trip min/avg/max = 2.674/3.904/6.248 ms
> root at OpenWrt:~# ping www.google.it
> ping: bad address 'www.google.it'
> root at OpenWrt:~# cat /etc/resolv.conf
> nameserver 127.0.0.1
> root at OpenWrt:~# cat /etc/config/network
> # Copyright (C) 2006 OpenWrt.org
>
> config interface loopback
>         option ifname   lo
>         option proto    static
>         option ipaddr   127.0.0.1
>         option netmask  255.0.0.0
>
> config interface lan
>         option ifname   eth0
>         option type     bridge
>         option proto    static
>         option ipaddr   192.168.1.1
>         option netmask  255.255.255.0
> root at OpenWrt:~# cat /etc/resolv.conf
> nameserver 127.0.0.1
> root at OpenWrt:~# cat /etc/config/network
>
> config 'interface' 'loopback'
>         option 'ifname' 'lo'
>         option 'proto' 'static'
>         option 'ipaddr' '127.0.0.1'
>         option 'netmask' '255.0.0.0'
>
> config 'interface' 'lan'
>         option 'ifname' 'eth0'
>         option 'type' 'bridge'
>         option 'proto' 'static'
>         option 'ipaddr' '192.168.1.1'
>         option 'netmask' '255.255.255.0'
>         option 'gateway' '192.168.1.254'
>         option 'defaultroute' '0'
>         option 'peerdns' '0'
>         option 'dns' '192.168.1.254'
>
> root at OpenWrt:~# cat /etc/resolv.conf
> nameserver 127.0.0.1
> root at OpenWrt:~# cat /etc/config/network
>
> config 'interface' 'loopback'
>         option 'ifname' 'lo'
>         option 'proto' 'static'
>         option 'ipaddr' '127.0.0.1'
>         option 'netmask' '255.0.0.0'
>
> config 'interface' 'lan'
>         option 'ifname' 'eth0'
>         option 'proto' 'static'
>         option 'ipaddr' '192.168.1.1'
>         option 'netmask' '255.255.255.0'
>         option 'gateway' '192.168.1.254'
>         option 'defaultroute' '0'
>         option 'peerdns' '0'
>         option 'dns' '192.168.1.254'
>
> root at OpenWrt:~# date
> Fri Feb  6 02:13:00 UTC 2009
> root at OpenWrt:~# ping www.google.it
> PING www.google.it (216.58.198.131): 56 data bytes
> 64 bytes from 216.58.198.131: seq=0 ttl=53 time=47.755 ms
> 64 bytes from 216.58.198.131: seq=1 ttl=53 time=48.364 ms
> 64 bytes from 216.58.198.131: seq=2 ttl=53 time=47.934 ms
> 64 bytes from 216.58.198.131: seq=3 ttl=53 time=51.164 ms
> 64 bytes from 216.58.198.131: seq=4 ttl=53 time=47.692 ms
> ^C
> --- www.google.it ping statistics ---
> 5 packets transmitted, 5 packets received, 0% packet loss
> round-trip min/avg/max = 47.692/48.581/51.164 ms
> root at OpenWrt:~# opkg update
> Downloading 
> http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/Packages.gz
> Connecting to downloads.openwrt.org (78.24.191.177:80)
> Packages.gz          100% 
> |************************************************************************************************************| 
> 143k 00:00:00 ETA
> Inflating 
> http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/Packages.gz
> Updated list of available packages in /var/opkg-lists/snapshots
> root at OpenWrt:~# opkg install kmod-mmc-over-gpio kmod-fs-ext3 cfdisk 
> e2fsprogs kmod-nls-base kmod-nls-cp437 kmod-nls-iso8859-1
> Installing kmod-mmc-over-gpio (2.6.26.5-atheros-2) to root...
> Downloading 
> http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/./kmod-mmc-over-gpio_2.6.26.5-atheros-2_mips.ipk
> Connecting to downloads.openwrt.org (78.24.191.177:80)
> kmod-mmc-over-gpio_2 100% 
> |************************************************************************************************************| 
> 5565  --:--:-- ETA
> Installing kmod-mmc-spi (2.6.26.5-atheros-1) to root...
> Downloading 
> http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/./kmod-mmc-spi_2.6.26.5-atheros-1_mips.ipk
> Connecting to downloads.openwrt.org (78.24.191.177:80)
> kmod-mmc-spi_2.6.26. 100% 
> |************************************************************************************************************| 
> 7219  --:--:-- ETA
> Installing kmod-mmc (2.6.26.5-atheros-1) to root...
> Downloading 
> http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/./kmod-mmc_2.6.26.5-atheros-1_mips.ipk
> Connecting to downloads.openwrt.org (78.24.191.177:80)
> kmod-mmc_2.6.26.5-at 100% 
> |************************************************************************************************************| 
> 28898  --:--:-- ETA
> Installing kmod-crc-itu-t (2.6.26.5-atheros-1) to root...
> Downloading 
> http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/./kmod-crc-itu-t_2.6.26.5-atheros-1_mips.ipk
> Connecting to downloads.openwrt.org (78.24.191.177:80)
> kmod-crc-itu-t_2.6.2 100% 
> |************************************************************************************************************| 
> 2269  --:--:-- ETA
> Installing kmod-crc7 (2.6.26.5-atheros-1) to root...
> Downloading 
> http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/./kmod-crc7_2.6.26.5-atheros-1_mips.ipk
> Connecting to downloads.openwrt.org (78.24.191.177:80)
> kmod-crc7_2.6.26.5-a 100% 
> |************************************************************************************************************| 
> 1911  --:--:-- ETA
> Installing kmod-spi-gpio (2.6.26.5-atheros-1) to root...
> Downloading 
> http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/./kmod-spi-gpio_2.6.26.5-atheros-1_mips.ipk
> Connecting to downloads.openwrt.org (78.24.191.177:80)
> kmod-spi-gpio_2.6.26 100% 
> |************************************************************************************************************| 
> 3945  --:--:-- ETA
> Installing kmod-spi-bitbang (2.6.26.5-atheros-1) to root...
> Downloading 
> http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/./kmod-spi-bitbang_2.6.26.5-atheros-1_mips.ipk
> Connecting to downloads.openwrt.org (78.24.191.177:80)
> kmod-spi-bitbang_2.6 100% 
> |************************************************************************************************************| 
> 3580  --:--:-- ETA
> Installing kmod-fs-ext3 (2.6.26.5-atheros-1) to root...
> Downloading 
> http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/./kmod-fs-ext3_2.6.26.5-atheros-1_mips.ipk
> Connecting to downloads.openwrt.org (78.24.191.177:80)
> kmod-fs-ext3_2.6.26. 100% 
> |************************************************************************************************************| 
> 92934  00:00:00 ETA
> Installing cfdisk (2.13.0.1-2) to root...
> Downloading 
> http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/./cfdisk_2.13.0.1-2_mips.ipk
> Connecting to downloads.openwrt.org (78.24.191.177:80)
> cfdisk_2.13.0.1-2_mi 100% 
> |************************************************************************************************************| 
> 28445  --:--:-- ETA
> Installing libncurses (5.6-1) to root...
> Downloading 
> http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/./libncurses_5.6-1_mips.ipk
> Connecting to downloads.openwrt.org (78.24.191.177:80)
> libncurses_5.6-1_mip 100% 
> |************************************************************************************************************| 
> 135k 00:00:00 ETA
> Installing e2fsprogs (1.40.11-1) to root...
> Downloading 
> http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/./e2fsprogs_1.40.11-1_mips.ipk
> Connecting to downloads.openwrt.org (78.24.191.177:80)
> e2fsprogs_1.40.11-1_ 100% 
> |************************************************************************************************************| 
> 101k 00:00:00 ETA
> Installing libblkid (1.40.11-1) to root...
> Downloading 
> http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/./libblkid_1.40.11-1_mips.ipk
> Connecting to downloads.openwrt.org (78.24.191.177:80)
> libblkid_1.40.11-1_m 100% 
> |************************************************************************************************************| 
> 17309  --:--:-- ETA
> Installing libuuid (1.40.11-1) to root...
> Downloading 
> http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/./libuuid_1.40.11-1_mips.ipk
> Connecting to downloads.openwrt.org (78.24.191.177:80)
> libuuid_1.40.11-1_mi 100% 
> |************************************************************************************************************| 
> 7491  --:--:-- ETA
> Installing libext2fs (1.40.11-1) to root...
> Downloading 
> http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/./libext2fs_1.40.11-1_mips.ipk
> Connecting to downloads.openwrt.org (78.24.191.177:80)
> libext2fs_1.40.11-1_ 100% 
> |************************************************************************************************************| 
> 195k --:--:-- ETA
> Installing kmod-nls-base (2.6.26.5-atheros-1) to root...
> Downloading 
> http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/./kmod-nls-base_2.6.26.5-atheros-1_mips.ipk
> Connecting to downloads.openwrt.org (78.24.191.177:80)
> kmod-nls-base_2.6.26 100% 
> |************************************************************************************************************| 
> 3724  --:--:-- ETA
> Installing kmod-nls-cp437 (2.6.26.5-atheros-1) to root...
> Downloading 
> http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/./kmod-nls-cp437_2.6.26.5-atheros-1_mips.ipk
> Connecting to downloads.openwrt.org (78.24.191.177:80)
> kmod-nls-cp437_2.6.2 100% 
> |************************************************************************************************************| 
> 2977  --:--:-- ETA
> Installing kmod-nls-iso8859-1 (2.6.26.5-atheros-1) to root...
> Downloading 
> http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/./kmod-nls-iso8859-1_2.6.26.5-atheros-1_mips.ipk
> Connecting to downloads.openwrt.org (78.24.191.177:80)
> kmod-nls-iso8859-1_2 100% 
> |************************************************************************************************************| 
> 2650  --:--:-- ETA
> Configuring cfdisk
> Configuring e2fsprogs
> Configuring kmod-crc-itu-t
> Configuring kmod-crc7
> Configuring kmod-fs-ext3
> Configuring kmod-mmc
> Configuring kmod-mmc-over-gpio
> Configuring kmod-mmc-spi
> Configuring kmod-nls-base
> Configuring kmod-nls-cp437
> Configuring kmod-nls-iso8859-1
> Configuring kmod-spi-bitbang
> Configuring kmod-spi-gpio
> Configuring libblkid
> Configuring libext2fs
> Configuring libncurses
> Configuring libuuid
> root at OpenWrt:~#
>
> reboot
>
> login as: root
> root at 192.168.1.1's password:
>
>
> BusyBox v1.11.2 (2009-01-05 06:34:55 CET) built-in shell (ash)
> Enter 'help' for a list of built-in commands.
>
>   _______                     ________        __
>  |       |.-----.-----.-----.|  |  |  |.----.|  |_
>  |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
>  |_______||   __|_____|__|__||________||__|  |____|
>           |__| W I R E L E S S   F R E E D O M
>  KAMIKAZE (8.09, r14511) ----------------------------
>   * 10 oz Vodka       Shake well with ice and strain
>   * 10 oz Triple sec  mixture into 10 shot glasses.
>   * 10 oz lime juice  Salute!
>  ---------------------------------------------------
> root at OpenWrt:~# ping www.google.it
> PING www.google.it (216.58.214.99): 56 data bytes
> 64 bytes from 216.58.214.99: seq=0 ttl=52 time=49.145 ms
> 64 bytes from 216.58.214.99: seq=1 ttl=52 time=48.823 ms
> 64 bytes from 216.58.214.99: seq=2 ttl=52 time=47.853 ms
> 64 bytes from 216.58.214.99: seq=3 ttl=52 time=48.080 ms
> ^C
> --- www.google.it ping statistics ---
> 4 packets transmitted, 4 packets received, 0% packet loss
> round-trip min/avg/max = 47.853/48.475/49.145 ms
> root at OpenWrt:~# uci set mmc_over_gpio. at mmc_over_gpio[0].enabled=1
> uci: Entry not found
> root at OpenWrt:~# ls /sbin/uci -all
> -rwxr-xr-x    1 root     root        10815 Jan 20 17:04 /sbin/uci
> root at OpenWrt:~# uci --help
> uci: invalid option -- -
> Usage: uci [<options>] <command> [<arguments>]
>
> Commands:
>         batch
>         export     [<config>]
>         import     [<config>]
>         changes    [<config>]
>         commit     [<config>]
>         add        <config> <section-type>
>         add_list <config>.<section>.<option>=<string>
>         show [<config>[.<section>[.<option>]]]
>         get        <config>.<section>[.<option>]
>         set <config>.<section>[.<option>]=<value>
>         delete     <config>[.<section[.<option>]]
>         rename <config>.<section>[.<option>]=<name>
>         revert <config>[.<section>[.<option>]]
>
> Options:
>         -c <path>  set the search path for config files (default: 
> /etc/config)
>         -d <str>   set the delimiter for list values in uci show
>         -f <file>  use <file> as input instead of stdin
>         -m         when importing, merge data into an existing package
>         -n         name unnamed sections on export (default)
>         -N         don't name unnamed sections
>         -p <path>  add a search path for config change files
>         -P <path>  add a search path for config change files and use 
> as default
>         -q         quiet mode (don't print error messages)
>         -s         force strict mode (stop on parser errors, default)
>         -S         disable strict mode
>         -X         do not use extended syntax on 'show'
>
> root at OpenWrt:~# ls /etc/init.d/mmc_over_gpio -all
> -rwxr-xr-x    1 root     root         1238 Feb 14  2009 
> /etc/init.d/mmc_over_gpio
>
> root at OpenWrt:/# uci add fstab mount
> cfg064d78
> root at OpenWrt:/# uci set fstab. at mount[0].enabled=1
> root at OpenWrt:/# uci set fstab. at mount[0].fstype=ext3
> root at OpenWrt:/# uci set fstab. at mount[0].device=/dev/mmcblk0p1
> root at OpenWrt:/# uci set fstab. at mount[0].target=/mnt/mmc
> root at OpenWrt:/# uci set fstab. at mount[0].options=rw,sync,noatime
> root at OpenWrt:/# uci commit fstab
> root at OpenWrt:/# /etc/init.d/fstab restart
> umount: cannot umount /mnt/mmc: No such file or directory
> mount: mounting /dev/mmcblk0p1 on /mnt/mmc failed: No such file or 
> directory
>
> root at OpenWrt:/# /etc/init.d/mmc_over_gpio
> Syntax: /etc/init.d/mmc_over_gpio [command]
>
> Available commands:
>         start   Start the service
>         stop    Stop the service
>         restart Restart the service
>         reload  Reload configuration files (or restart if that fails)
>         enable  Enable service autostart
>         disable Disable service autostart
>
> root at OpenWrt:/# /etc/init.d/mmc_over_gpio start
>
>
> Il 04/06/2016 04:40, Marco Castrovilli ha scritto:
>> hi andrew,
>> i've installed
>> openwrt-atheros-root.jffs2-64k
>> openwrt-atheros-vmlinux.lzma
>> from https://downloads.openwrt.org/kamikaze/8.09/atheros/
>>
>> after few problems to configure internet access, i did:
>>
>> opkg update
>> opkg install kmod-mmc-over-gpio kmod-fs-ext3 cfdisk e2fsprogs 
>> kmod-nls-base kmod-nls-cp437 kmod-nls-iso8859-1
>>
>> and each installation was fine.
>>
>> during GPIO configuration i had the message:
>> uci: entry not found
>> after each command:
>> uci set mmc_over_gpio. at mmc_over_gpio[0].enabled=1
>> uci set mmc_over_gpio. at mmc_over_gpio[0].DI_pin=1
>> uci set mmc_over_gpio. at mmc_over_gpio[0].DO_pin=4
>> uci set mmc_over_gpio. at mmc_over_gpio[0].CLK_pin=3
>> uci set mmc_over_gpio. at mmc_over_gpio[0].CS_pin=7
>> then i had "can't create /config/gpiommc/ directory" error. so i 
>> rebooted, but now i can ping fonera 15/16 times, 1 timeout, other 
>> 10/12 ping ok,
>> then it is unreachable for some seconds and so looping on.
>>
>> do you know the reason?
>>
>> and now the final question: i soldered exactly like in figure above:
>> www.WiFi-Ita.com
>> as explained here:
>> http://www.wifi-ita.com/index.php?option=com_content&task=view&id=223
>>
>> must i have to solder ALL cables on pin of GPIO?
>>
>> thank you again.
>> Il 03/06/2016 16:32, Andrew Yong ha scritto:
>>> You'll want to use OpenWrt Kamikaze 8.09 and use the official package
>>> manager opkg. Follow the linked wiki page
>>> (https://wiki.openwrt.org/doc/howto/mmc_over_gpio) and you'll be fine.
>>>
>>> The latest releases have deprecated kmod-mmc-over-gpio in favor of
>>> just getting other generic $30 routers from AliExpress that have built
>>> in TF/MMC ports (generally RT5350), or AR9311 routers with USB e.g.
>>> TL-MR3020.
>>>
>>>
>>>
>>> On Fri, Jun 3, 2016 at 10:15 PM, Marco Castrovilli
>>> <marco.castrovilli at gmail.com> wrote:
>>>> thanks a lot for your immediate answer.
>>>> i followed this guide to mod fonera adding an sd card:
>>>> http://www.wifi-ita.com/index.php?option=com_content&task=view&id=223
>>>> and this one:
>>>> http://www.nabuk.org/f/index.php?topic=1486.0
>>>> everything is ok but i can't find 26215-4pinfon2100Driver7143.ipk 
>>>> anywere.
>>>> i'm on kamikaze 7.09 and kernel:
>>>> Linux Legend 2.6.22.1 #5 Mon Aug 13 18:18:07 EDT 2007 mips unknown
>>>>
>>>> i tried to update (with ipkg, not opkg) but i have problem with 
>>>> original
>>>> openwrt feed:
>>>> root at Legend:~# ipkg update
>>>> Downloading
>>>> http://downloads.openwrt.org/snapshots/atheros-2.6/packages/Packages
>>>> wget: server returned error: HTTP/1.1 404 Not Found
>>>> Downloading 
>>>> http://downloads.openwrt.org/kamikaze/packages/mips/Packages
>>>> wget: server returned error: HTTP/1.1 404 Not Found
>>>> Downloading
>>>> http://downloads.x-wrt.org/xwrt/kamikaze/snapshots/atheros-2.6/packages/Packages 
>>>>
>>>> wget: server returned error: HTTP/1.1 404 Not Found
>>>> An error ocurred, return value: 3.
>>>> Collected errors:
>>>> ipkg_download: ERROR: Command failed with return value 1: `wget
>>>> --passive-ftp    -q -P /tmp/ipkg-hCDHje
>>>> http://downloads.openwrt.org/snapshots/atheros-2.6/packages/Packages'
>>>> ipkg_download: ERROR: Command failed with return value 1: `wget
>>>> --passive-ftp    -q -P /tmp/ipkg-hCDHje
>>>> http://downloads.openwrt.org/kamikaze/packages/mips/Packages'
>>>> ipkg_download: ERROR: Command failed with return value 1: `wget
>>>> --passive-ftp    -q -P /tmp/ipkg-hCDHje
>>>> http://downloads.x-wrt.org/xwrt/kamikaze/snapshots/atheros-2.6/packages/Packages' 
>>>>
>>>> root at Legend:~#
>>>>
>>>> so i tried with other ones but:
>>>> root at Legend:~# ipkg update
>>>> Downloading
>>>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages 
>>>>
>>>> wget: not an http or ftp url:
>>>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages 
>>>>
>>>> Downloading
>>>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages 
>>>>
>>>> wget: not an http or ftp url:
>>>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages 
>>>>
>>>> Downloading
>>>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages 
>>>>
>>>> wget: not an http or ftp url:
>>>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages 
>>>>
>>>> An error ocurred, return value: 3.
>>>> Collected errors:
>>>> ipkg_download: ERROR: Command failed with return value 1: `wget
>>>> --passive-ftp    -q -P /tmp/ipkg-nErUJo
>>>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages' 
>>>>
>>>> ipkg_download: ERROR: Command failed with return value 1: `wget
>>>> --passive-ftp    -q -P /tmp/ipkg-nErUJo
>>>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages' 
>>>>
>>>> ipkg_download: ERROR: Command failed with return value 1: `wget
>>>> --passive-ftp    -q -P /tmp/ipkg-nErUJo
>>>> https://downloads.openwrt.org/kamikaze/7.09/atheros-2.6/packages/Packages' 
>>>>
>>>> root at Legend:~#
>>>>
>>>> i got a more recent wget (wget_1.10.2-2_mips.ipk) but stil have 
>>>> problems
>>>> with ssl.
>>>> anyway, browsing manually feeds i can't find driver.
>>>>
>>>> perhaps i NEED to use kamikaze 8.09 and all troubles will run away?
>>>>
>>>> again many thanks Andrew for your interest: this is my last chance 
>>>> to use a
>>>> microSD on my fonera 2100 :)
>>>>
>>>>
>>>>
>>>> Il 03/06/2016 15:49, Andrew Yong ha scritto:
>>>>
>>>> https://wiki.openwrt.org/doc/hardware/port.gpio and see relevant 
>>>> sections
>>>> for bitbanging MMC over GPIO.
>>>>
>>>> On 3 Jun 2016 21:46, "Marco Castrovilli" <marco.castrovilli at gmail.com>
>>>> wrote:
>>>>> hi all!
>>>>> does anyone can help me to find mmc driver working on openwrt, 
>>>>> installed
>>>>> on fonera 2100 (mips architectire)?
>>>>> thank you in advance.
>>>>>
>>>>> _______________________________________________
>>>>> Lede-dev mailing list
>>>>> Lede-dev at lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>>>
>



From john at phrozen.org  Mon Jun  6 00:34:18 2016
From: john at phrozen.org (John Crispin)
Date: Mon, 6 Jun 2016 09:34:18 +0200
Subject: [LEDE-DEV] [PATCH 1/2] mail: imapfiler: use default imapfilter
 config options
In-Reply-To: <20160605130347.10573-1-tduszyns@gmail.com>
References: <20160605130347.10573-1-tduszyns@gmail.com>
Message-ID: <ecf8adaa-4e09-78e7-ba96-0fde0e9dd3e5@phrozen.org>

Hi Tomasz,

these need to be submitted via a PRS to the openwrt packages feed on github

	John

On 05/06/2016 15:03, Tomasz Duszynski wrote:
> IMAP filtering is setup per user so it makes sense
> to use settings defined under user's home directory.
> 
> Signed-off-by: Tomasz Duszynski <tduszyns at gmail.com>
> ---
>  mail/imapfilter/patches/010-pathnames.patch | 31 -----------------------------
>  1 file changed, 31 deletions(-)
>  delete mode 100644 mail/imapfilter/patches/010-pathnames.patch
> 
> diff --git a/mail/imapfilter/patches/010-pathnames.patch b/mail/imapfilter/patches/010-pathnames.patch
> deleted file mode 100644
> index 6e9a43f..0000000
> --- a/mail/imapfilter/patches/010-pathnames.patch
> +++ /dev/null
> @@ -1,31 +0,0 @@
> ---- a/pathnames.h
> -+++ b/pathnames.h
> -@@ -3,7 +3,7 @@
> - 
> - 
> - /* Program's home directory. */
> --#define PATHNAME_HOME			".imapfilter"
> -+#define PATHNAME_HOME			"/etc/imapfilter"
> - 
> - /* Program's configuration file. */
> - #define PATHNAME_CONFIG			PATHNAME_HOME "/config.lua"
> -@@ -39,7 +39,7 @@
> - #define PATHNAME_CERTS			PATHNAME_HOME "/certificates"
> - 
> - /* Debug temporary file template. */
> --#define PATHNAME_DEBUG			PATHNAME_HOME "/debug.XXXXXX"
> -+#define PATHNAME_DEBUG			"/tmp/imapfilterdebug.XXXXXX"
> - 
> - 
> - #endif				/* PATHNAMES_H */
> ---- a/imapfilter.c
> -+++ b/imapfilter.c
> -@@ -50,7 +50,7 @@
> - 	opts.config = NULL;
> - 	opts.oneline = NULL;
> - 
> --	env.home = getenv("HOME");
> -+	env.home = "";
> - 	env.pathmax = -1;
> - 
> - 	while ((c = getopt(argc, argv, "Vc:de:il:v?")) != -1) {
> 


From kzak at redhat.com  Mon Jun  6 01:05:44 2016
From: kzak at redhat.com (Karel Zak)
Date: Mon, 6 Jun 2016 10:05:44 +0200
Subject: [LEDE-DEV] [PATCH] fix uClibc-ng scanf check
In-Reply-To: <9e2695e1-1cb7-38bc-c1da-0fdbd1f1af3f@phrozen.org>
References: <20160603022328.GA24494@waldemar-brodkorb.de>
 <9e2695e1-1cb7-38bc-c1da-0fdbd1f1af3f@phrozen.org>
Message-ID: <20160606080544.tynq7jfbzl5z4ove@ws.net.home>

On Fri, Jun 03, 2016 at 10:54:57AM +0200, John Crispin wrote:
> >  configure.ac | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)

 Applied, thanks.

    Karel

-- 
 Karel Zak  <kzak at redhat.com>
 http://karelzak.blogspot.com


From dedeckeh at gmail.com  Mon Jun  6 03:03:42 2016
From: dedeckeh at gmail.com (Hans Dedecker)
Date: Mon,  6 Jun 2016 12:03:42 +0200
Subject: [LEDE-DEV] [PATCH netifd 2/3] device: Fix dotted vlan interface
	staying down
In-Reply-To: <1465207423-20413-1-git-send-email-dedeckeh@gmail.com>
References: <1465207423-20413-1-git-send-email-dedeckeh@gmail.com>
Message-ID: <1465207423-20413-2-git-send-email-dedeckeh@gmail.com>

Using the config below a dotted vlan interface stays down as get_vlan_device
does not find the device due to the aliased device stacked on top of the base
device.
As all devices; aliased devices being the exception; are in the device list
use device_find to find the device when setting the link state

config interface 'test'
    option proto 'static'
    option ipaddr '192.168.2.1'
    option netmask '255.255.255.0'

config interface 'test2'
    option ifname '@test.1'
    option proto 'dhcp'

Signed-off-by: Hans Dedecker <dedeckeh at gmail.com>
---
This fixes the issue reported in https://lists.openwrt.org/pipermail/openwrt-devel/2016-May/041323.html

 device.c       | 8 ++++++++
 device.h       | 3 ++-
 system-linux.c | 3 ++-
 3 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/device.c b/device.c
index 7149d86..45a9d07 100644
--- a/device.c
+++ b/device.c
@@ -477,6 +477,14 @@ device_create_default(const char *name, bool external)
 }
 
 struct device *
+device_find(const char *name)
+{
+	struct device *dev;
+
+	return avl_find_element(&devices, name, dev, avl);
+}
+
+struct device *
 device_get(const char *name, int create)
 {
 	struct device *dev;
diff --git a/device.h b/device.h
index b069a2b..e13e435 100644
--- a/device.h
+++ b/device.h
@@ -241,7 +241,8 @@ void device_set_default_ps(bool state);
 
 void device_init_virtual(struct device *dev, const struct device_type *type, const char *name);
 int device_init(struct device *iface, const struct device_type *type, const char *ifname);
-void device_cleanup(struct device *iface);
+void device_cleanup(struct device *dev);
+struct device *device_find(const char *name);
 struct device *device_get(const char *name, int create);
 void device_add_user(struct device_user *dep, struct device *iface);
 void device_remove_user(struct device_user *dep);
diff --git a/system-linux.c b/system-linux.c
index 90b0775..98acb9d 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -495,10 +495,11 @@ static int cb_rtnl_event(struct nl_msg *msg, void *arg)
 	if (!nla[IFLA_IFNAME])
 		goto out;
 
-	struct device *dev = device_get(nla_data(nla[IFLA_IFNAME]), false);
+	struct device *dev = device_find(nla_data(nla[IFLA_IFNAME]));
 	if (!dev)
 		goto out;
 
+
 	if (!system_get_dev_sysctl("/sys/class/net/%s/carrier", dev->ifname, buf, sizeof(buf)))
 		link_state = strtoul(buf, NULL, 0);
 
-- 
1.9.1



From dedeckeh at gmail.com  Mon Jun  6 03:03:41 2016
From: dedeckeh at gmail.com (Hans Dedecker)
Date: Mon,  6 Jun 2016 12:03:41 +0200
Subject: [LEDE-DEV] [PATCH netifd 1/3] device: Fix device find failure in
	avl list due to device name change
Message-ID: <1465207423-20413-1-git-send-email-dedeckeh@gmail.com>

As device name is used as key in avl list a device name change will break the avl find logic.
Function device_set_ifname offers api to set the device name and re-inserts the avl node in the list
when the avl key value is changed.

Signed-off-by: Hans Dedecker <dedeckeh at gmail.com>
---
 alias.c  |  9 +++------
 device.c | 27 ++++++++++++++++++++++++---
 device.h |  1 +
 vlan.c   | 11 +++++++----
 4 files changed, 35 insertions(+), 13 deletions(-)

diff --git a/alias.c b/alias.c
index e4bb700..6b938ca 100644
--- a/alias.c
+++ b/alias.c
@@ -59,13 +59,10 @@ static void alias_set_device(struct alias_device *alias, struct device *dev)
 	alias->dev.hidden = !dev;
 	if (dev) {
 		device_set_ifindex(&alias->dev, dev->ifindex);
-		strcpy(alias->dev.ifname, dev->ifname);
-		device_broadcast_event(&alias->dev, DEV_EVENT_UPDATE_IFNAME);
+		device_set_ifname(&alias->dev, dev->ifname);
 		device_add_user(&alias->dep, dev);
-	} else {
-		alias->dev.ifname[0] = 0;
-		device_broadcast_event(&alias->dev, DEV_EVENT_UPDATE_IFNAME);
-	}
+	} else
+		device_set_ifname(&alias->dev, "");
 }
 
 static int
diff --git a/device.c b/device.c
index 06c4820..7149d86 100644
--- a/device.c
+++ b/device.c
@@ -422,14 +422,14 @@ void device_init_virtual(struct device *dev, const struct device_type *type, con
 	assert(dev);
 	assert(type);
 
-	if (name)
-		strncpy(dev->ifname, name, IFNAMSIZ);
-
 	D(DEVICE, "Initialize device '%s'\n", dev->ifname);
 	INIT_SAFE_LIST(&dev->users);
 	INIT_SAFE_LIST(&dev->aliases);
 	dev->type = type;
 
+	if (name)
+		device_set_ifname(dev, name);
+
 	if (!dev->set_state)
 		dev->set_state = set_device_state;
 }
@@ -582,6 +582,27 @@ void device_set_ifindex(struct device *dev, int ifindex)
 	device_broadcast_event(dev, DEV_EVENT_UPDATE_IFINDEX);
 }
 
+int device_set_ifname(struct device *dev, const char *name)
+{
+	int ret = 0;
+
+	if (!strcmp(dev->ifname, name))
+		return 0;
+
+	if (dev->avl.key)
+		avl_delete(&devices, &dev->avl);
+
+	strncpy(dev->ifname, name, IFNAMSIZ);
+
+	if (dev->avl.key)
+		ret = avl_insert(&devices, &dev->avl);
+
+	if (ret == 0)
+		device_broadcast_event(dev, DEV_EVENT_UPDATE_IFNAME);
+
+	return ret;
+}
+
 static int device_refcount(struct device *dev)
 {
 	struct list_head *list;
diff --git a/device.h b/device.h
index 77a2fef..b069a2b 100644
--- a/device.h
+++ b/device.h
@@ -250,6 +250,7 @@ void device_broadcast_event(struct device *dev, enum device_event ev);
 void device_set_present(struct device *dev, bool state);
 void device_set_link(struct device *dev, bool state);
 void device_set_ifindex(struct device *dev, int ifindex);
+int device_set_ifname(struct device *dev, const char *name);
 void device_refresh_present(struct device *dev);
 int device_claim(struct device_user *dep);
 void device_release(struct device_user *dep);
diff --git a/vlan.c b/vlan.c
index ac434ce..7f8697b 100644
--- a/vlan.c
+++ b/vlan.c
@@ -63,8 +63,11 @@ static int vlan_set_device_state(struct device *dev, bool up)
 
 static void vlan_dev_set_name(struct vlan_device *vldev, struct device *dev)
 {
+	char name[IFNAMSIZ];
+
 	vldev->dev.hidden = dev->hidden;
-	snprintf(vldev->dev.ifname, IFNAMSIZ, "%s.%d", dev->ifname, vldev->id);
+	snprintf(name, IFNAMSIZ, "%s.%d", dev->ifname, vldev->id);
+	device_set_ifname(&vldev->dev, name);
 }
 
 static void vlan_dev_cb(struct device_user *dep, enum device_event ev)
@@ -81,7 +84,6 @@ static void vlan_dev_cb(struct device_user *dep, enum device_event ev)
 		break;
 	case DEV_EVENT_UPDATE_IFNAME:
 		vlan_dev_set_name(vldev, dep->dev);
-		device_broadcast_event(&vldev->dev, ev);
 		break;
 	case DEV_EVENT_TOPO_CHANGE:
 		/* Propagate topo changes */
@@ -124,9 +126,10 @@ static struct device *get_vlan_device(struct device *dev, int id, bool create)
 		return NULL;
 
 	vldev->id = id;
-	vlan_dev_set_name(vldev, dev);
 
-	device_init(&vldev->dev, &vlan_type, vldev->dev.ifname);
+	device_init(&vldev->dev, &vlan_type, NULL);
+
+	vlan_dev_set_name(vldev, dev);
 	vldev->dev.default_config = true;
 
 	vldev->set_state = vldev->dev.set_state;
-- 
1.9.1



From dedeckeh at gmail.com  Mon Jun  6 03:03:43 2016
From: dedeckeh at gmail.com (Hans Dedecker)
Date: Mon,  6 Jun 2016 12:03:43 +0200
Subject: [LEDE-DEV] [PATCH netifd 3/3] system-linux: Replace device_get by
	device_find where appropriate
In-Reply-To: <1465207423-20413-1-git-send-email-dedeckeh@gmail.com>
References: <1465207423-20413-1-git-send-email-dedeckeh@gmail.com>
Message-ID: <1465207423-20413-3-git-send-email-dedeckeh@gmail.com>

Replace device_get by device_find so it's clear a device needs to be found present
in the device list.

Signed-off-by: Hans Dedecker <dedeckeh at gmail.com>
---
 system-linux.c | 2 +-
 ubus.c         | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/system-linux.c b/system-linux.c
index 98acb9d..04f633a 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -549,7 +549,7 @@ handle_hotplug_msg(char *data, int size)
 	return;
 
 found:
-	dev = device_get(interface, false);
+	dev = device_find(interface);
 	if (!dev)
 		return;
 
diff --git a/ubus.c b/ubus.c
index 4184301..198d93b 100644
--- a/ubus.c
+++ b/ubus.c
@@ -290,7 +290,8 @@ netifd_handle_set_state(struct ubus_context *ctx, struct ubus_object *obj,
 	if (!cur)
 		return UBUS_STATUS_INVALID_ARGUMENT;
 
-	dev = device_get(blobmsg_data(cur), false);
+	dev = device_find(blobmsg_data(cur));
+
 	if (!dev)
 		return UBUS_STATUS_NOT_FOUND;
 
-- 
1.9.1



From eyal.birger at gmail.com  Mon Jun  6 03:38:30 2016
From: eyal.birger at gmail.com (Eyal Birger)
Date: Mon, 6 Jun 2016 13:38:30 +0300
Subject: [LEDE-DEV] [OpenWrt-Devel] [PATCH netifd 1/3] device: Fix
 device find failure in avl list due to device name change
In-Reply-To: <1465207423-20413-1-git-send-email-dedeckeh@gmail.com>
References: <1465207423-20413-1-git-send-email-dedeckeh@gmail.com>
Message-ID: <CAHsH6GsLXz8TBBqhPEyyz30zzwvfqonUsWru4Pp0f5j-M9uHTw@mail.gmail.com>

Hi Hans,

On Mon, Jun 6, 2016 at 1:03 PM, Hans Dedecker <dedeckeh at gmail.com> wrote:
> As device name is used as key in avl list a device name change will break the avl find logic.
> Function device_set_ifname offers api to set the device name and re-inserts the avl node in the list
> when the avl key value is changed.
>
> Signed-off-by: Hans Dedecker <dedeckeh at gmail.com>
> ---
>
> diff --git a/device.c b/device.c
> index 06c4820..7149d86 100644
> --- a/device.c
> +++ b/device.c
> @@ -422,14 +422,14 @@ void device_init_virtual(struct device *dev, const struct device_type *type, con
>         assert(dev);
>         assert(type);
>
> -       if (name)
> -               strncpy(dev->ifname, name, IFNAMSIZ);
> -
>         D(DEVICE, "Initialize device '%s'\n", dev->ifname);

Isn't this debug print broken by this change?

>         INIT_SAFE_LIST(&dev->users);
>         INIT_SAFE_LIST(&dev->aliases);
>         dev->type = type;
>
> +       if (name)
> +               device_set_ifname(dev, name);
> +


Eyal.


From dedeckeh at gmail.com  Mon Jun  6 04:06:08 2016
From: dedeckeh at gmail.com (Hans Dedecker)
Date: Mon, 6 Jun 2016 13:06:08 +0200
Subject: [LEDE-DEV] [OpenWrt-Devel] [PATCH netifd 1/3] device: Fix
 device find failure in avl list due to device name change
In-Reply-To: <CAHsH6GsLXz8TBBqhPEyyz30zzwvfqonUsWru4Pp0f5j-M9uHTw@mail.gmail.com>
References: <1465207423-20413-1-git-send-email-dedeckeh@gmail.com>
 <CAHsH6GsLXz8TBBqhPEyyz30zzwvfqonUsWru4Pp0f5j-M9uHTw@mail.gmail.com>
Message-ID: <CAJLcKsE6WkXsG9uxE=q9ZRrM=mV5e9hK7CfYaLDd-XT1s2CKjA@mail.gmail.com>

On Mon, Jun 6, 2016 at 12:38 PM, Eyal Birger <eyal.birger at gmail.com> wrote:
> Hi Hans,
>
> On Mon, Jun 6, 2016 at 1:03 PM, Hans Dedecker <dedeckeh at gmail.com> wrote:
>> As device name is used as key in avl list a device name change will break the avl find logic.
>> Function device_set_ifname offers api to set the device name and re-inserts the avl node in the list
>> when the avl key value is changed.
>>
>> Signed-off-by: Hans Dedecker <dedeckeh at gmail.com>
>> ---
>>
>> diff --git a/device.c b/device.c
>> index 06c4820..7149d86 100644
>> --- a/device.c
>> +++ b/device.c
>> @@ -422,14 +422,14 @@ void device_init_virtual(struct device *dev, const struct device_type *type, con
>>         assert(dev);
>>         assert(type);
>>
>> -       if (name)
>> -               strncpy(dev->ifname, name, IFNAMSIZ);
>> -
>>         D(DEVICE, "Initialize device '%s'\n", dev->ifname);
>
> Isn't this debug print broken by this change?
>
>>         INIT_SAFE_LIST(&dev->users);
>>         INIT_SAFE_LIST(&dev->aliases);
>>         dev->type = type;
>>
>> +       if (name)
>> +               device_set_ifname(dev, name);
>> +
>
>
> Eyal.
Correct I will send a V2

Thx,
Hans


From dedeckeh at gmail.com  Mon Jun  6 05:58:31 2016
From: dedeckeh at gmail.com (Hans Dedecker)
Date: Mon,  6 Jun 2016 14:58:31 +0200
Subject: [LEDE-DEV] [PATCH v2 netifd 1/3] device: Fix device find failure in
	avl list due to device name change
Message-ID: <1465217913-20861-1-git-send-email-dedeckeh@gmail.com>

As device name is used as key in avl list a device name change will break the avl find logic.
Function device_set_ifname offers api to set the device name and re-inserts the avl node in the list
when the avl key value is changed.

Signed-off-by: Hans Dedecker <dedeckeh at gmail.com>
---
v1 -> v2 : Fix debug print in device_init_virtual

 alias.c  |  9 +++------
 device.c | 29 +++++++++++++++++++++++++----
 device.h |  1 +
 vlan.c   | 11 +++++++----
 4 files changed, 36 insertions(+), 14 deletions(-)

diff --git a/alias.c b/alias.c
index e4bb700..6b938ca 100644
--- a/alias.c
+++ b/alias.c
@@ -59,13 +59,10 @@ static void alias_set_device(struct alias_device *alias, struct device *dev)
 	alias->dev.hidden = !dev;
 	if (dev) {
 		device_set_ifindex(&alias->dev, dev->ifindex);
-		strcpy(alias->dev.ifname, dev->ifname);
-		device_broadcast_event(&alias->dev, DEV_EVENT_UPDATE_IFNAME);
+		device_set_ifname(&alias->dev, dev->ifname);
 		device_add_user(&alias->dep, dev);
-	} else {
-		alias->dev.ifname[0] = 0;
-		device_broadcast_event(&alias->dev, DEV_EVENT_UPDATE_IFNAME);
-	}
+	} else
+		device_set_ifname(&alias->dev, "");
 }
 
 static int
diff --git a/device.c b/device.c
index 06c4820..a4d804e 100644
--- a/device.c
+++ b/device.c
@@ -422,14 +422,14 @@ void device_init_virtual(struct device *dev, const struct device_type *type, con
 	assert(dev);
 	assert(type);
 
-	if (name)
-		strncpy(dev->ifname, name, IFNAMSIZ);
-
-	D(DEVICE, "Initialize device '%s'\n", dev->ifname);
+	D(DEVICE, "Initialize device '%s'\n", name ? name : "");
 	INIT_SAFE_LIST(&dev->users);
 	INIT_SAFE_LIST(&dev->aliases);
 	dev->type = type;
 
+	if (name)
+		device_set_ifname(dev, name);
+
 	if (!dev->set_state)
 		dev->set_state = set_device_state;
 }
@@ -582,6 +582,27 @@ void device_set_ifindex(struct device *dev, int ifindex)
 	device_broadcast_event(dev, DEV_EVENT_UPDATE_IFINDEX);
 }
 
+int device_set_ifname(struct device *dev, const char *name)
+{
+	int ret = 0;
+
+	if (!strcmp(dev->ifname, name))
+		return 0;
+
+	if (dev->avl.key)
+		avl_delete(&devices, &dev->avl);
+
+	strncpy(dev->ifname, name, IFNAMSIZ);
+
+	if (dev->avl.key)
+		ret = avl_insert(&devices, &dev->avl);
+
+	if (ret == 0)
+		device_broadcast_event(dev, DEV_EVENT_UPDATE_IFNAME);
+
+	return ret;
+}
+
 static int device_refcount(struct device *dev)
 {
 	struct list_head *list;
diff --git a/device.h b/device.h
index 77a2fef..b069a2b 100644
--- a/device.h
+++ b/device.h
@@ -250,6 +250,7 @@ void device_broadcast_event(struct device *dev, enum device_event ev);
 void device_set_present(struct device *dev, bool state);
 void device_set_link(struct device *dev, bool state);
 void device_set_ifindex(struct device *dev, int ifindex);
+int device_set_ifname(struct device *dev, const char *name);
 void device_refresh_present(struct device *dev);
 int device_claim(struct device_user *dep);
 void device_release(struct device_user *dep);
diff --git a/vlan.c b/vlan.c
index ac434ce..7f8697b 100644
--- a/vlan.c
+++ b/vlan.c
@@ -63,8 +63,11 @@ static int vlan_set_device_state(struct device *dev, bool up)
 
 static void vlan_dev_set_name(struct vlan_device *vldev, struct device *dev)
 {
+	char name[IFNAMSIZ];
+
 	vldev->dev.hidden = dev->hidden;
-	snprintf(vldev->dev.ifname, IFNAMSIZ, "%s.%d", dev->ifname, vldev->id);
+	snprintf(name, IFNAMSIZ, "%s.%d", dev->ifname, vldev->id);
+	device_set_ifname(&vldev->dev, name);
 }
 
 static void vlan_dev_cb(struct device_user *dep, enum device_event ev)
@@ -81,7 +84,6 @@ static void vlan_dev_cb(struct device_user *dep, enum device_event ev)
 		break;
 	case DEV_EVENT_UPDATE_IFNAME:
 		vlan_dev_set_name(vldev, dep->dev);
-		device_broadcast_event(&vldev->dev, ev);
 		break;
 	case DEV_EVENT_TOPO_CHANGE:
 		/* Propagate topo changes */
@@ -124,9 +126,10 @@ static struct device *get_vlan_device(struct device *dev, int id, bool create)
 		return NULL;
 
 	vldev->id = id;
-	vlan_dev_set_name(vldev, dev);
 
-	device_init(&vldev->dev, &vlan_type, vldev->dev.ifname);
+	device_init(&vldev->dev, &vlan_type, NULL);
+
+	vlan_dev_set_name(vldev, dev);
 	vldev->dev.default_config = true;
 
 	vldev->set_state = vldev->dev.set_state;
-- 
1.9.1



From dedeckeh at gmail.com  Mon Jun  6 05:58:32 2016
From: dedeckeh at gmail.com (Hans Dedecker)
Date: Mon,  6 Jun 2016 14:58:32 +0200
Subject: [LEDE-DEV] [PATCH v2 netifd 2/3] device: Fix dotted vlan interface
	staying down
In-Reply-To: <1465217913-20861-1-git-send-email-dedeckeh@gmail.com>
References: <1465217913-20861-1-git-send-email-dedeckeh@gmail.com>
Message-ID: <1465217913-20861-2-git-send-email-dedeckeh@gmail.com>

Using the config below a dotted vlan interface stays down as get_vlan_device
does not find the device due to the aliased device stacked on top of the base
device.
As all devices; aliased devices being the exception; are in the device list
use device_find to find the device when setting the link state

config interface 'test'
    option proto 'static'
    option ipaddr '192.168.2.1'
    option netmask '255.255.255.0'

config interface 'test2'
    option ifname '@test.1'
    option proto 'dhcp'

Signed-off-by: Hans Dedecker <dedeckeh at gmail.com>
---
v1 -> v2 : Remove extra white line in cb_rtnl_event

This fixes the issue reported in https://lists.openwrt.org/pipermail/openwrt-devel/2016-May/041323.html

 device.c       | 8 ++++++++
 device.h       | 3 ++-
 system-linux.c | 2 +-
 3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/device.c b/device.c
index a4d804e..fa3d00f 100644
--- a/device.c
+++ b/device.c
@@ -477,6 +477,14 @@ device_create_default(const char *name, bool external)
 }
 
 struct device *
+device_find(const char *name)
+{
+	struct device *dev;
+
+	return avl_find_element(&devices, name, dev, avl);
+}
+
+struct device *
 device_get(const char *name, int create)
 {
 	struct device *dev;
diff --git a/device.h b/device.h
index b069a2b..e13e435 100644
--- a/device.h
+++ b/device.h
@@ -241,7 +241,8 @@ void device_set_default_ps(bool state);
 
 void device_init_virtual(struct device *dev, const struct device_type *type, const char *name);
 int device_init(struct device *iface, const struct device_type *type, const char *ifname);
-void device_cleanup(struct device *iface);
+void device_cleanup(struct device *dev);
+struct device *device_find(const char *name);
 struct device *device_get(const char *name, int create);
 void device_add_user(struct device_user *dep, struct device *iface);
 void device_remove_user(struct device_user *dep);
diff --git a/system-linux.c b/system-linux.c
index 90b0775..eb785b5 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -495,7 +495,7 @@ static int cb_rtnl_event(struct nl_msg *msg, void *arg)
 	if (!nla[IFLA_IFNAME])
 		goto out;
 
-	struct device *dev = device_get(nla_data(nla[IFLA_IFNAME]), false);
+	struct device *dev = device_find(nla_data(nla[IFLA_IFNAME]));
 	if (!dev)
 		goto out;
 
-- 
1.9.1



From dedeckeh at gmail.com  Mon Jun  6 05:58:33 2016
From: dedeckeh at gmail.com (Hans Dedecker)
Date: Mon,  6 Jun 2016 14:58:33 +0200
Subject: [LEDE-DEV] [PATCH v2 netifd 3/3] system-linux: Replace device_get
	by device_find where appropriate
In-Reply-To: <1465217913-20861-1-git-send-email-dedeckeh@gmail.com>
References: <1465217913-20861-1-git-send-email-dedeckeh@gmail.com>
Message-ID: <1465217913-20861-3-git-send-email-dedeckeh@gmail.com>

Replace device_get by device_find so it's clear a device needs to be found present
in the device list.

Signed-off-by: Hans Dedecker <dedeckeh at gmail.com>
---
v1 -> v2 : Remove extra white line in netifd_handle_set_state

 system-linux.c | 2 +-
 ubus.c         | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/system-linux.c b/system-linux.c
index eb785b5..d868c15 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -548,7 +548,7 @@ handle_hotplug_msg(char *data, int size)
 	return;
 
 found:
-	dev = device_get(interface, false);
+	dev = device_find(interface);
 	if (!dev)
 		return;
 
diff --git a/ubus.c b/ubus.c
index 4184301..74cdf28 100644
--- a/ubus.c
+++ b/ubus.c
@@ -290,7 +290,7 @@ netifd_handle_set_state(struct ubus_context *ctx, struct ubus_object *obj,
 	if (!cur)
 		return UBUS_STATUS_INVALID_ARGUMENT;
 
-	dev = device_get(blobmsg_data(cur), false);
+	dev = device_find(blobmsg_data(cur));
 	if (!dev)
 		return UBUS_STATUS_NOT_FOUND;
 
-- 
1.9.1



From karlp at tweak.net.au  Mon Jun  6 08:49:20 2016
From: karlp at tweak.net.au (Karl Palsson)
Date: Mon,  6 Jun 2016 15:49:20 +0000
Subject: [LEDE-DEV] RFC: patches on cyassl/wolfssl openssl compatibility
Message-ID: <1465228162-22084-1-git-send-email-karlp@tweak.net.au>

While attempting to update libwebsockets to version 2.x, I ran into
the curious case of openssl compatiblity in wolfssl (nee cyassl)

Apparently "--with-stunnel" enables "the rest" of the openssl
compatibitility, bringing the compatibility up to v1.0.1.

As openssl is already at 1.0.1, it seems reasonable that the wolfssl
compatiblity should also be at a useful level.  Unfortunately, you
still need to explicitly check the wolfssl options at compile time to
_enable_ the compatibility.  Patches for ustream-ssl follow, patches for
libwebsockets are not pushed yet, as there's no point until this is resolved.
They're available in https://github.com/karlp/packages/commits/drafts/lws-v2.x
if anyone wants to look at them.

Note: I'm not actually a wolfssl/cyassl user, this just came about while
trying to bring forward cyassl support in libwebsockets, so if someone
understands the true intentions of wolfssl here, I'm all ears.

Sincerely,
Karl P



From karlp at tweak.net.au  Mon Jun  6 08:49:21 2016
From: karlp at tweak.net.au (Karl Palsson)
Date: Mon,  6 Jun 2016 15:49:21 +0000
Subject: [LEDE-DEV] [PATCH] wolfssl: enable openssl 1.0.1 compatibility
In-Reply-To: <1465228162-22084-1-git-send-email-karlp@tweak.net.au>
References: <1465228162-22084-1-git-send-email-karlp@tweak.net.au>
Message-ID: <1465228162-22084-2-git-send-email-karlp@tweak.net.au>

From: Karl Palsson <karlp at etactica.com>

>From wolfssl/openssl/opensslv.h, and from skimming the contents of what
"--enable-stunnel" actually does, it seems that --enable-opensslextra
doesn't give you the "full" openssl compatibility that you may wish for
these days.  Unfortuantely, while wolfssl writes the build time options
into wolfssl/options.h, it doesn't include that file itself.  User
applications must include that directly.

Signed-off-by: Karl Palsson <karlp at etactica.com>
---
 package/libs/cyassl/Makefile                          |  1 +
 ...ove_SSL_set_tlsext_host_name_outside_STUNNEL.patch | 19 -------------------
 2 files changed, 1 insertion(+), 19 deletions(-)
 delete mode 100644 package/libs/cyassl/patches/300-debloat_move_SSL_set_tlsext_host_name_outside_STUNNEL.patch

diff --git a/package/libs/cyassl/Makefile b/package/libs/cyassl/Makefile
index b6440f3..a2b3b5e 100644
--- a/package/libs/cyassl/Makefile
+++ b/package/libs/cyassl/Makefile
@@ -41,6 +41,7 @@ CONFIGURE_ARGS += \
 	--enable-singlethreaded \
 	--enable-opensslextra \
 	--enable-sni \
+	--enable-stunnel \
 	--enable-ecc \
 	--disable-examples
 
diff --git a/package/libs/cyassl/patches/300-debloat_move_SSL_set_tlsext_host_name_outside_STUNNEL.patch b/package/libs/cyassl/patches/300-debloat_move_SSL_set_tlsext_host_name_outside_STUNNEL.patch
deleted file mode 100644
index 51d89f7..0000000
--- a/package/libs/cyassl/patches/300-debloat_move_SSL_set_tlsext_host_name_outside_STUNNEL.patch
+++ /dev/null
@@ -1,19 +0,0 @@
---- a/wolfssl/openssl/ssl.h
-+++ b/wolfssl/openssl/ssl.h
-@@ -402,6 +402,8 @@ typedef WOLFSSL_X509_STORE_CTX X509_STOR
- /* yassl had set the default to be 500 */
- #define SSL_get_default_timeout(ctx) 500
- 
-+#define SSL_set_tlsext_host_name(x, y) wolfSSL_UseSNI(x, WOLFSSL_SNI_HOST_NAME, y, strlen(y))
-+
- /* Lighthttp compatibility */
- 
- #ifdef HAVE_LIGHTY                       
-@@ -488,7 +490,6 @@ typedef WOLFSSL_ASN1_BIT_STRING    ASN1_
- #define SSL_TLSEXT_ERR_NOACK                 alert_warning
- #define TLSEXT_NAMETYPE_host_name            WOLFSSL_SNI_HOST_NAME
- 
--#define SSL_set_tlsext_host_name wolfSSL_set_tlsext_host_name
- #define SSL_get_servername wolfSSL_get_servername
- #define SSL_set_SSL_CTX                  wolfSSL_set_SSL_CTX
- #define SSL_CTX_get_verify_callback      wolfSSL_CTX_get_verify_callback
-- 
2.4.11



From karlp at tweak.net.au  Mon Jun  6 08:49:22 2016
From: karlp at tweak.net.au (Karl Palsson)
Date: Mon,  6 Jun 2016 15:49:22 +0000
Subject: [LEDE-DEV] [PATCH] ustream-ssl: cyassl compatibility with build
	time options
In-Reply-To: <1465228162-22084-1-git-send-email-karlp@tweak.net.au>
References: <1465228162-22084-1-git-send-email-karlp@tweak.net.au>
Message-ID: <1465228162-22084-3-git-send-email-karlp@tweak.net.au>

From: Karl Palsson <karlp at etactica.com>

Adds a HAVE_CYASSL definition to be consistent with polar/mbedtls.
Uses that definition to include the wolfssl build time options.
This enables the correct pullin of the "remainder" of the wolfssl openssl
compatibility options, if they were enabled in the build of wolfssl in the
first place.

Signed-off-by: Karl Palsson <karlp at etactica.com>
---

Unresolved: the fact that ustream still refers to everything as cyassl.

 CMakeLists.txt     | 1 +
 ustream-internal.h | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index c1c2b32..2ce9bf8 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -21,6 +21,7 @@ ELSEIF(CYASSL)
   IF (HAVE_CYASSL_VERSION_H)
     ADD_DEFINITIONS(-DHAVE_CYASSL_VERSION_H)
   ENDIF()
+  ADD_DEFINITIONS(-DHAVE_CYASSL)
   SET(SSL_SRC ustream-io-cyassl.c ustream-openssl.c)
   SET(SSL_LIB cyassl m)
 ELSE()
diff --git a/ustream-internal.h b/ustream-internal.h
index 020e1c6..4932a0d 100644
--- a/ustream-internal.h
+++ b/ustream-internal.h
@@ -26,6 +26,9 @@
 #elif defined(HAVE_POLARSSL)
 #include "ustream-polarssl.h"
 #else
+#if defined(HAVE_CYASSL)
+#include <wolfssl/options.h>
+#endif
 #include "ustream-openssl.h"
 #endif
 
-- 
2.4.11



From daniel at daniel.thecshore.com  Mon Jun  6 08:19:19 2016
From: daniel at daniel.thecshore.com (Daniel Curran-Dickinson)
Date: Mon, 06 Jun 2016 11:19:19 -0400
Subject: [LEDE-DEV] Anyone seen this issue with netifd?
Message-ID: <1465226359.30408.6.camel@homehost>

iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAABlBMVEX///8AAABVwtN+AAAAeklEQVQY04XQzQ2EIBAF4IdMDIc5UAIlUIKlWMr0ZiMm28jOj+6iMXEOfBBmXgJAVLGlBkU3wcZ9I3Q7EdrAveowx6hZ0q6QJDsRnHlJwr+W4CHF7vLqTEenXABeUnSssbP8SdwdjTHEwcFDtQGKFuWjH8Lna8vAmfEF3NMPdAOsBscAAAAASUVORK5CYII=
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.10.4-0ubuntu2 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit


Hi,

I recently ran into a strange issue with netifd and was wondering if
anyone else had see anything like it.  I had a non-bridge interface on a
router with with local-only ipv6 (that is no external ipv6, only the
ipv6 from ula from the router), and noticed that dhcpv6 wasn't working.

Eventually I noticed that ifstatus lanx reported and ipv6 of
<hex:hex:hex>: (note the *single* colon) while bridge interfaces were
reporting <hex:hex:hex>::.  When I changed the interface to bridge it
report <hex:hex:hex>:: and dhcpv6 addresses got served on that address.

Methinks there may be an issue the prefix associated with non-bridge
interfaces, but I don't know how to dig deeper on that.  Not enough
ipv6-fu for one thing.

Also this is from a rather old version of netifd (from trunk) so it
may be fixed already; opkg reports: 
2016-03-04-da687c2689f7ff2af1dccc9a428806dd15c3d554

Once I finally get that router updated to newer trunk I'll report if the issues persists.

Regards,

Daniel




From drew at nixcores.com  Mon Jun  6 17:04:34 2016
From: drew at nixcores.com (Drew from NixCore)
Date: Mon, 6 Jun 2016 20:04:34 -0400
Subject: [LEDE-DEV] [PATCH] [ramips] Added NixCore X1 target
Message-ID: <57560F92.8090409@nixcores.com>

Added NixCore X1 ramips target http://nixcores.com. This builds 8M and 
16M images

Signed-off-by: Drew Gaylo <drew at nixcores.com>
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index 69c0125..4728c75 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -77,7 +77,6 @@ ramips_setup_interfaces()
      mt7628|\
      mzk-750dhp|\
      mzk-w300nh2|\
-    nixcore|\
      oy-0001|\
      pbr-m1|\
      psg1208|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index 76f0e43..cbe455d 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -316,9 +316,6 @@ ramips_board_detect() {
      *"NCS601W")
          name="ncs601w"
          ;;
-    *"NixcoreX1")
-        name="nixcore-x1"
-        ;;
      *"NW718")
          name="nw718"
          ;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 0094568..91c9997 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -94,7 +94,6 @@ platform_check_image() {
      mzk-w300nh2|\
      mzk-wdpr|\
      nbg-419n|\
-    nixcore|\
      nw718|\
      oy-0001|\
      pbr-m1|\
diff --git a/target/linux/ramips/dts/NIXCOREX1-16M.dts 
b/target/linux/ramips/dts/NIXCOREX1-16M.dts
deleted file mode 100644
index c7ec410..0000000
--- a/target/linux/ramips/dts/NIXCOREX1-16M.dts
+++ /dev/null
@@ -1,186 +0,0 @@
-/dts-v1/;
-
-/include/ "rt5350.dtsi"
-
-/ {
-    compatible = "NixcoreX1", "ralink,rt5350-soc";
-    model = "NixcoreX1";
-
-    palmbus at 10000000 {
-        /* Re-enable the gpio1 ports */
-        gpio1: gpio at 660 {
-            status = "okay";
-        };
-
-        i2c at 900 {
-            status = "okay";
-        };
-        uart at 500 {
-            status = "okay";
-            /* Mix of uart and gpio */
-            reset-names = "gpio uartf";
-        };
-        spi at b00 {
-            status = "okay";
-
-            m25p80 at 0 {
-                #address-cells = <1>;
-                #size-cells = <1>;
-                compatible = "s25fl064k";
-                reg = <0>;
-                linux,modalias = "m25p80", "s25fl064k";
-                spi-max-frequency = <10000000>;
-
-                partition at 0 {
-                    label = "uboot";
-                    reg = <0x0 0x30000>;
-                    read-only;
-                };
-
-                partition at 30000 {
-                    label = "uboot-env";
-                    reg = <0x30000 0x10000>;
-                    read-only;
-                };
-
-                factory: partition at 40000 {
-                    label = "factory";
-                    reg = <0x40000 0x10000>;
-                    read-only;
-                };
-
-                partition at 50000 {
-                    label = "firmware";
-                    reg = <0x50000 0x7b0000>;
-                };
-            };
-
-            spidev at 1 {
-                compatible = "linux,spidev";
-                spi-max-frequency = <10000000>;
-                reg = <1>;
-            };
-        };
-    };
-
-    pinctrl {
-        state_default: pinctrl0 {
-            gpio {
-                /* Associate the tjag, uartf and led groups with gpio */
-                ralink,group = "jtag", "led", "spi_cs1";
-                /* How do we set individual pins? */
-                ralink,function = "gpio";
-            };
-        };
-    };
-
-    ethernet at 10100000 {
-        mtd-mac-address = <&factory 0x4>;
-    };
-
-    esw at 10110000 {
-        ralink,portmap = <0x17>;
-    };
-
-    wmac at 10180000 {
-        ralink,mtd-eeprom = <&factory 0>;
-    };
-
-    ehci at 101c0000 {
-        status = "okay";
-    };
-
-    ohci at 101c1000 {
-        status = "okay";
-    };
-
-    chosen {
-        bootargs = "console=ttyS1,57600";
-    };
-    gpio-export {
-        compatible = "gpio-export";
-        #size-cells = <0>;
-
-        gpio0 {
-            gpio-export,name = "gpio0";
-            gpio-export,direction_may_change = <1>;
-            gpios = <&gpio0 0 0>;
-        };
-
-        /* GPIOs 1-6 are I2C,SPI */
-
-        /* GPIO 7-14 are uart1 */
-
-        /* GPIOs 15 & 16 are uart2 */
-
-        /* JTAG */
-        gpio17 {
-            /* JTAG_TDO */
-            gpio-export,name = "gpio17";
-            gpio-export,direction_may_change = <1>;
-            gpios = <&gpio0 17 0>;
-        };
-        gpio18 {
-            /* JTAG_TDI */
-            gpio-export,name = "gpio18";
-            gpio-export,direction_may_change = <1>;
-            gpios = <&gpio0 18 0>;
-        };
-        gpio19 {
-            /* JTAG_TMS */
-            gpio-export,name = "gpio19";
-            gpio-export,direction_may_change = <1>;
-            gpios = <&gpio0 19 0>;
-        };
-        gpio20 {
-            /* JTAG_TCLK */
-            gpio-export,name = "gpio20";
-            gpio-export,direction_may_change = <1>;
-            gpios = <&gpio0 20 0>;
-        };
-        gpio21 {
-            /* JTAG_TRST_N */
-            gpio-export,name = "gpio21";
-            gpio-export,direction_may_change = <1>;
-            gpios = <&gpio0 21 0>;
-        };
-
-        /* ETH LEDs */
-        /*
-        gpio22 {
-            gpio-export,name = "gpio22";
-            gpio-export,direction_may_change = <1>;
-            gpios = <&gpio1 0 0>;
-        };
-        gpio23 {
-            gpio-export,name = "gpio23";
-            gpio-export,direction_may_change = <1>;
-            gpios = <&gpio1 1 0>;
-        };
-        gpio24 {
-            gpio-export,name = "gpio24";
-            gpio-export,direction_may_change = <1>;
-            gpios = <&gpio1 2 0>;
-        };
-        gpio25 {
-            gpio-export,name = "gpio25";
-            gpio-export,direction_may_change = <1>;
-            gpios = <&gpio1 3 0>;
-        };
-        */
-        gpio26 {
-            /* ETH4_LED */
-            gpio-export,name = "gpio26";
-            gpio-export,direction_may_change = <1>;
-            gpios = <&gpio1 4 0>;
-        };
-
-        gpio27 {
-            /* spi_cs1 */
-            gpio-export,name = "gpio27";
-            gpio-export,direction_may_change = <1>;
-            gpios = <&gpio1 5 0>;
-        };
-    };
-
-};
diff --git a/target/linux/ramips/dts/NIXCOREX1-8M.dts 
b/target/linux/ramips/dts/NIXCOREX1-8M.dts
deleted file mode 100644
index c7ec410..0000000
--- a/target/linux/ramips/dts/NIXCOREX1-8M.dts
+++ /dev/null
@@ -1,186 +0,0 @@
-/dts-v1/;
-
-/include/ "rt5350.dtsi"
-
-/ {
-    compatible = "NixcoreX1", "ralink,rt5350-soc";
-    model = "NixcoreX1";
-
-    palmbus at 10000000 {
-        /* Re-enable the gpio1 ports */
-        gpio1: gpio at 660 {
-            status = "okay";
-        };
-
-        i2c at 900 {
-            status = "okay";
-        };
-        uart at 500 {
-            status = "okay";
-            /* Mix of uart and gpio */
-            reset-names = "gpio uartf";
-        };
-        spi at b00 {
-            status = "okay";
-
-            m25p80 at 0 {
-                #address-cells = <1>;
-                #size-cells = <1>;
-                compatible = "s25fl064k";
-                reg = <0>;
-                linux,modalias = "m25p80", "s25fl064k";
-                spi-max-frequency = <10000000>;
-
-                partition at 0 {
-                    label = "uboot";
-                    reg = <0x0 0x30000>;
-                    read-only;
-                };
-
-                partition at 30000 {
-                    label = "uboot-env";
-                    reg = <0x30000 0x10000>;
-                    read-only;
-                };
-
-                factory: partition at 40000 {
-                    label = "factory";
-                    reg = <0x40000 0x10000>;
-                    read-only;
-                };
-
-                partition at 50000 {
-                    label = "firmware";
-                    reg = <0x50000 0x7b0000>;
-                };
-            };
-
-            spidev at 1 {
-                compatible = "linux,spidev";
-                spi-max-frequency = <10000000>;
-                reg = <1>;
-            };
-        };
-    };
-
-    pinctrl {
-        state_default: pinctrl0 {
-            gpio {
-                /* Associate the tjag, uartf and led groups with gpio */
-                ralink,group = "jtag", "led", "spi_cs1";
-                /* How do we set individual pins? */
-                ralink,function = "gpio";
-            };
-        };
-    };
-
-    ethernet at 10100000 {
-        mtd-mac-address = <&factory 0x4>;
-    };
-
-    esw at 10110000 {
-        ralink,portmap = <0x17>;
-    };
-
-    wmac at 10180000 {
-        ralink,mtd-eeprom = <&factory 0>;
-    };
-
-    ehci at 101c0000 {
-        status = "okay";
-    };
-
-    ohci at 101c1000 {
-        status = "okay";
-    };
-
-    chosen {
-        bootargs = "console=ttyS1,57600";
-    };
-    gpio-export {
-        compatible = "gpio-export";
-        #size-cells = <0>;
-
-        gpio0 {
-            gpio-export,name = "gpio0";
-            gpio-export,direction_may_change = <1>;
-            gpios = <&gpio0 0 0>;
-        };
-
-        /* GPIOs 1-6 are I2C,SPI */
-
-        /* GPIO 7-14 are uart1 */
-
-        /* GPIOs 15 & 16 are uart2 */
-
-        /* JTAG */
-        gpio17 {
-            /* JTAG_TDO */
-            gpio-export,name = "gpio17";
-            gpio-export,direction_may_change = <1>;
-            gpios = <&gpio0 17 0>;
-        };
-        gpio18 {
-            /* JTAG_TDI */
-            gpio-export,name = "gpio18";
-            gpio-export,direction_may_change = <1>;
-            gpios = <&gpio0 18 0>;
-        };
-        gpio19 {
-            /* JTAG_TMS */
-            gpio-export,name = "gpio19";
-            gpio-export,direction_may_change = <1>;
-            gpios = <&gpio0 19 0>;
-        };
-        gpio20 {
-            /* JTAG_TCLK */
-            gpio-export,name = "gpio20";
-            gpio-export,direction_may_change = <1>;
-            gpios = <&gpio0 20 0>;
-        };
-        gpio21 {
-            /* JTAG_TRST_N */
-            gpio-export,name = "gpio21";
-            gpio-export,direction_may_change = <1>;
-            gpios = <&gpio0 21 0>;
-        };
-
-        /* ETH LEDs */
-        /*
-        gpio22 {
-            gpio-export,name = "gpio22";
-            gpio-export,direction_may_change = <1>;
-            gpios = <&gpio1 0 0>;
-        };
-        gpio23 {
-            gpio-export,name = "gpio23";
-            gpio-export,direction_may_change = <1>;
-            gpios = <&gpio1 1 0>;
-        };
-        gpio24 {
-            gpio-export,name = "gpio24";
-            gpio-export,direction_may_change = <1>;
-            gpios = <&gpio1 2 0>;
-        };
-        gpio25 {
-            gpio-export,name = "gpio25";
-            gpio-export,direction_may_change = <1>;
-            gpios = <&gpio1 3 0>;
-        };
-        */
-        gpio26 {
-            /* ETH4_LED */
-            gpio-export,name = "gpio26";
-            gpio-export,direction_may_change = <1>;
-            gpios = <&gpio1 4 0>;
-        };
-
-        gpio27 {
-            /* spi_cs1 */
-            gpio-export,name = "gpio27";
-            gpio-export,direction_may_change = <1>;
-            gpios = <&gpio1 5 0>;
-        };
-    };
-
-};
diff --git a/target/linux/ramips/image/rt305x.mk 
b/target/linux/ramips/image/rt305x.mk
index db12a8e..da7fc46 100644
--- a/target/linux/ramips/image/rt305x.mk
+++ b/target/linux/ramips/image/rt305x.mk
@@ -100,21 +100,6 @@ define BuildFirmware/HLKRM04/initramfs
      mkhilinkfw -e -i$(call imgname,$(1),$(2))-uImage.bin -o $(call 
imgname,$(1),$(2))-factory.bin;
  endef

-# This is called to build the nixcore image.  Build both 8MB and 16MB
-nixcore_8mb_mtd_size=8060928
-nixcore_16mb_mtd_size=16449536
-define BuildFirmware/NIXCOREX1/squashfs
-# Args are XXX, nixcore-mM and NIXCOREX1-xM
-    $(call 
BuildFirmware/CustomFlash/$(1),$(1),$(2)-8M,$(3)-8M,$(nixcore_8mb_mtd_size))
-    $(call 
BuildFirmware/CustomFlash/$(1),$(1),$(2)-16M,$(3)-16M,$(nixcore_16mb_mtd_size))
-    # Can do somethings here after the build?
-endef
-define BuildFirmware/NIXCOREX1/initramfs
-# Args are XXXX, nixcore-mM and NIXCOREX1-xM
-    $(call BuildFirmware/OF/initramfs,$(1),$(2)-8M,$(3)-8M)
-    $(call BuildFirmware/OF/initramfs,$(1),$(2)-16M,$(3)-16M)
-endef
-
  vocore_8mb_mtd_size=8060928
  vocore_16mb_mtd_size=16449536
  define BuildFirmware/VOCORE/squashfs
@@ -272,7 +257,6 @@ Image/Build/Profile/NBG-419N=$(call 
BuildFirmware/Default4M/$(1),$(1),nbg-419n,N
  Image/Build/Profile/MZKW300NH2=$(call 
BuildFirmware/Edimax/$(1),$(1),mzk-w300nh2,MZK-W300NH2,$(mzkw300nh2_mtd_size),CSYS,RN52,0x50000,0xc0000)
  Image/Build/Profile/MZKWDPR=$(call 
BuildFirmware/Default8M/$(1),$(1),mzk-wdpr,MZK-WDPR)
  Image/Build/Profile/NCS601W=$(call 
BuildFirmware/Default8M/$(1),$(1),ncs601W,NCS601W)
-Image/Build/Profile/NIXCOREX1=$(call 
BuildFirmware/NIXCOREX1/$(1),$(1),nixcorex1,NIXCOREX1)
  nw718_mtd_size=3801088
  Image/Build/Profile/NW718=$(call 
BuildFirmware/CustomFlashFactory/$(1),$(1),nw718m,NW718,$(nw718_mtd_size),ARA1B4NCRNW718;1,factory)
  Image/Build/Profile/M2M=$(call 
BuildFirmware/Default8M/$(1),$(1),m2m,M2M,Linux Kernel Image)
@@ -369,7 +353,6 @@ define Image/Build/Profile/Default
      $(call Image/Build/Profile/MZKWDPR,$(1))
      $(call Image/Build/Profile/NBG-419N,$(1))
      $(call Image/Build/Profile/NCS601W,$(1))
-    $(call Image/Build/Profile/NIXCOREX1,$(1))
      $(call Image/Build/Profile/NW718,$(1))
      $(call Image/Build/Profile/MINIEMBWIFI,$(1))
      $(call Image/Build/Profile/MINIEMBPLUG,$(1))
diff --git a/target/linux/ramips/rt305x/profiles/nixcore.mk 
b/target/linux/ramips/rt305x/profiles/nixcore.mk
deleted file mode 100644
index 22dee9b..0000000
--- a/target/linux/ramips/rt305x/profiles/nixcore.mk
+++ /dev/null
@@ -1,20 +0,0 @@
-#
-# Copyright (C) 2014 OpenWrt.org
-#
-# This is free software, licensed under the GNU General Public License v2.
-# See /LICENSE for more information.
-#
-
-define Profile/NIXCOREX1
-    NAME:=NixcoreX1
-    PACKAGES:=\
-        kmod-usb-core kmod-usb-ohci kmod-usb2 \
-        kmod-i2c-core kmod-i2c-ralink \
-        kmod-spi-dev
-endef
-
-define Profile/NIXCOREX1/Description
-    Package set for Nixcore X1 board
-endef
-
-$(eval $(call Profile,NIXCOREX1))



From drew at nixcores.com  Mon Jun  6 17:16:44 2016
From: drew at nixcores.com (Drew from NixCore)
Date: Mon, 6 Jun 2016 20:16:44 -0400
Subject: [LEDE-DEV] [PATCH] [ramips] Added NixCore X1 target V2
Message-ID: <5756126C.5060101@nixcores.com>

Added NixCore X1 ramips target http://nixcores.com. This builds 8M and 16M
images

Signed-off-by: Drew Gaylo <drew at nixcores.com>
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index 4728c75..69c0125 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -77,6 +77,7 @@ ramips_setup_interfaces()
      mt7628|\
      mzk-750dhp|\
      mzk-w300nh2|\
+    nixcore|\
      oy-0001|\
      pbr-m1|\
      psg1208|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index cbe455d..76f0e43 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -316,6 +316,9 @@ ramips_board_detect() {
      *"NCS601W")
          name="ncs601w"
          ;;
+    *"NixcoreX1")
+        name="nixcore-x1"
+        ;;
      *"NW718")
          name="nw718"
          ;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 91c9997..0094568 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -94,6 +94,7 @@ platform_check_image() {
      mzk-w300nh2|\
      mzk-wdpr|\
      nbg-419n|\
+    nixcore|\
      nw718|\
      oy-0001|\
      pbr-m1|\
diff --git a/target/linux/ramips/dts/NIXCOREX1-16M.dts 
b/target/linux/ramips/dts/NIXCOREX1-16M.dts
new file mode 100644
index 0000000..c7ec410
--- /dev/null
+++ b/target/linux/ramips/dts/NIXCOREX1-16M.dts
@@ -0,0 +1,186 @@
+/dts-v1/;
+
+/include/ "rt5350.dtsi"
+
+/ {
+    compatible = "NixcoreX1", "ralink,rt5350-soc";
+    model = "NixcoreX1";
+
+    palmbus at 10000000 {
+        /* Re-enable the gpio1 ports */
+        gpio1: gpio at 660 {
+            status = "okay";
+        };
+
+        i2c at 900 {
+            status = "okay";
+        };
+        uart at 500 {
+            status = "okay";
+            /* Mix of uart and gpio */
+            reset-names = "gpio uartf";
+        };
+        spi at b00 {
+            status = "okay";
+
+            m25p80 at 0 {
+                #address-cells = <1>;
+                #size-cells = <1>;
+                compatible = "s25fl064k";
+                reg = <0>;
+                linux,modalias = "m25p80", "s25fl064k";
+                spi-max-frequency = <10000000>;
+
+                partition at 0 {
+                    label = "uboot";
+                    reg = <0x0 0x30000>;
+                    read-only;
+                };
+
+                partition at 30000 {
+                    label = "uboot-env";
+                    reg = <0x30000 0x10000>;
+                    read-only;
+                };
+
+                factory: partition at 40000 {
+                    label = "factory";
+                    reg = <0x40000 0x10000>;
+                    read-only;
+                };
+
+                partition at 50000 {
+                    label = "firmware";
+                    reg = <0x50000 0x7b0000>;
+                };
+            };
+
+            spidev at 1 {
+                compatible = "linux,spidev";
+                spi-max-frequency = <10000000>;
+                reg = <1>;
+            };
+        };
+    };
+
+    pinctrl {
+        state_default: pinctrl0 {
+            gpio {
+                /* Associate the tjag, uartf and led groups with gpio */
+                ralink,group = "jtag", "led", "spi_cs1";
+                /* How do we set individual pins? */
+                ralink,function = "gpio";
+            };
+        };
+    };
+
+    ethernet at 10100000 {
+        mtd-mac-address = <&factory 0x4>;
+    };
+
+    esw at 10110000 {
+        ralink,portmap = <0x17>;
+    };
+
+    wmac at 10180000 {
+        ralink,mtd-eeprom = <&factory 0>;
+    };
+
+    ehci at 101c0000 {
+        status = "okay";
+    };
+
+    ohci at 101c1000 {
+        status = "okay";
+    };
+
+    chosen {
+        bootargs = "console=ttyS1,57600";
+    };
+    gpio-export {
+        compatible = "gpio-export";
+        #size-cells = <0>;
+
+        gpio0 {
+            gpio-export,name = "gpio0";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio0 0 0>;
+        };
+
+        /* GPIOs 1-6 are I2C,SPI */
+
+        /* GPIO 7-14 are uart1 */
+
+        /* GPIOs 15 & 16 are uart2 */
+
+        /* JTAG */
+        gpio17 {
+            /* JTAG_TDO */
+            gpio-export,name = "gpio17";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio0 17 0>;
+        };
+        gpio18 {
+            /* JTAG_TDI */
+            gpio-export,name = "gpio18";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio0 18 0>;
+        };
+        gpio19 {
+            /* JTAG_TMS */
+            gpio-export,name = "gpio19";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio0 19 0>;
+        };
+        gpio20 {
+            /* JTAG_TCLK */
+            gpio-export,name = "gpio20";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio0 20 0>;
+        };
+        gpio21 {
+            /* JTAG_TRST_N */
+            gpio-export,name = "gpio21";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio0 21 0>;
+        };
+
+        /* ETH LEDs */
+        /*
+        gpio22 {
+            gpio-export,name = "gpio22";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio1 0 0>;
+        };
+        gpio23 {
+            gpio-export,name = "gpio23";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio1 1 0>;
+        };
+        gpio24 {
+            gpio-export,name = "gpio24";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio1 2 0>;
+        };
+        gpio25 {
+            gpio-export,name = "gpio25";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio1 3 0>;
+        };
+        */
+        gpio26 {
+            /* ETH4_LED */
+            gpio-export,name = "gpio26";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio1 4 0>;
+        };
+
+        gpio27 {
+            /* spi_cs1 */
+            gpio-export,name = "gpio27";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio1 5 0>;
+        };
+    };
+
+};
diff --git a/target/linux/ramips/dts/NIXCOREX1-8M.dts 
b/target/linux/ramips/dts/NIXCOREX1-8M.dts
new file mode 100644
index 0000000..c7ec410
--- /dev/null
+++ b/target/linux/ramips/dts/NIXCOREX1-8M.dts
@@ -0,0 +1,186 @@
+/dts-v1/;
+
+/include/ "rt5350.dtsi"
+
+/ {
+    compatible = "NixcoreX1", "ralink,rt5350-soc";
+    model = "NixcoreX1";
+
+    palmbus at 10000000 {
+        /* Re-enable the gpio1 ports */
+        gpio1: gpio at 660 {
+            status = "okay";
+        };
+
+        i2c at 900 {
+            status = "okay";
+        };
+        uart at 500 {
+            status = "okay";
+            /* Mix of uart and gpio */
+            reset-names = "gpio uartf";
+        };
+        spi at b00 {
+            status = "okay";
+
+            m25p80 at 0 {
+                #address-cells = <1>;
+                #size-cells = <1>;
+                compatible = "s25fl064k";
+                reg = <0>;
+                linux,modalias = "m25p80", "s25fl064k";
+                spi-max-frequency = <10000000>;
+
+                partition at 0 {
+                    label = "uboot";
+                    reg = <0x0 0x30000>;
+                    read-only;
+                };
+
+                partition at 30000 {
+                    label = "uboot-env";
+                    reg = <0x30000 0x10000>;
+                    read-only;
+                };
+
+                factory: partition at 40000 {
+                    label = "factory";
+                    reg = <0x40000 0x10000>;
+                    read-only;
+                };
+
+                partition at 50000 {
+                    label = "firmware";
+                    reg = <0x50000 0x7b0000>;
+                };
+            };
+
+            spidev at 1 {
+                compatible = "linux,spidev";
+                spi-max-frequency = <10000000>;
+                reg = <1>;
+            };
+        };
+    };
+
+    pinctrl {
+        state_default: pinctrl0 {
+            gpio {
+                /* Associate the tjag, uartf and led groups with gpio */
+                ralink,group = "jtag", "led", "spi_cs1";
+                /* How do we set individual pins? */
+                ralink,function = "gpio";
+            };
+        };
+    };
+
+    ethernet at 10100000 {
+        mtd-mac-address = <&factory 0x4>;
+    };
+
+    esw at 10110000 {
+        ralink,portmap = <0x17>;
+    };
+
+    wmac at 10180000 {
+        ralink,mtd-eeprom = <&factory 0>;
+    };
+
+    ehci at 101c0000 {
+        status = "okay";
+    };
+
+    ohci at 101c1000 {
+        status = "okay";
+    };
+
+    chosen {
+        bootargs = "console=ttyS1,57600";
+    };
+    gpio-export {
+        compatible = "gpio-export";
+        #size-cells = <0>;
+
+        gpio0 {
+            gpio-export,name = "gpio0";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio0 0 0>;
+        };
+
+        /* GPIOs 1-6 are I2C,SPI */
+
+        /* GPIO 7-14 are uart1 */
+
+        /* GPIOs 15 & 16 are uart2 */
+
+        /* JTAG */
+        gpio17 {
+            /* JTAG_TDO */
+            gpio-export,name = "gpio17";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio0 17 0>;
+        };
+        gpio18 {
+            /* JTAG_TDI */
+            gpio-export,name = "gpio18";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio0 18 0>;
+        };
+        gpio19 {
+            /* JTAG_TMS */
+            gpio-export,name = "gpio19";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio0 19 0>;
+        };
+        gpio20 {
+            /* JTAG_TCLK */
+            gpio-export,name = "gpio20";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio0 20 0>;
+        };
+        gpio21 {
+            /* JTAG_TRST_N */
+            gpio-export,name = "gpio21";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio0 21 0>;
+        };
+
+        /* ETH LEDs */
+        /*
+        gpio22 {
+            gpio-export,name = "gpio22";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio1 0 0>;
+        };
+        gpio23 {
+            gpio-export,name = "gpio23";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio1 1 0>;
+        };
+        gpio24 {
+            gpio-export,name = "gpio24";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio1 2 0>;
+        };
+        gpio25 {
+            gpio-export,name = "gpio25";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio1 3 0>;
+        };
+        */
+        gpio26 {
+            /* ETH4_LED */
+            gpio-export,name = "gpio26";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio1 4 0>;
+        };
+
+        gpio27 {
+            /* spi_cs1 */
+            gpio-export,name = "gpio27";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio1 5 0>;
+        };
+    };
+
+};
diff --git a/target/linux/ramips/image/rt305x.mk 
b/target/linux/ramips/image/rt305x.mk
index da7fc46..db12a8e 100644
--- a/target/linux/ramips/image/rt305x.mk
+++ b/target/linux/ramips/image/rt305x.mk
@@ -100,6 +100,21 @@ define BuildFirmware/HLKRM04/initramfs
      mkhilinkfw -e -i$(call imgname,$(1),$(2))-uImage.bin -o $(call 
imgname,$(1),$(2))-factory.bin;
  endef

+# This is called to build the nixcore image.  Build both 8MB and 16MB
+nixcore_8mb_mtd_size=8060928
+nixcore_16mb_mtd_size=16449536
+define BuildFirmware/NIXCOREX1/squashfs
+# Args are XXX, nixcore-mM and NIXCOREX1-xM
+    $(call 
BuildFirmware/CustomFlash/$(1),$(1),$(2)-8M,$(3)-8M,$(nixcore_8mb_mtd_size))
+    $(call 
BuildFirmware/CustomFlash/$(1),$(1),$(2)-16M,$(3)-16M,$(nixcore_16mb_mtd_size))
+    # Can do somethings here after the build?
+endef
+define BuildFirmware/NIXCOREX1/initramfs
+# Args are XXXX, nixcore-mM and NIXCOREX1-xM
+    $(call BuildFirmware/OF/initramfs,$(1),$(2)-8M,$(3)-8M)
+    $(call BuildFirmware/OF/initramfs,$(1),$(2)-16M,$(3)-16M)
+endef
+
  vocore_8mb_mtd_size=8060928
  vocore_16mb_mtd_size=16449536
  define BuildFirmware/VOCORE/squashfs
@@ -257,6 +272,7 @@ Image/Build/Profile/NBG-419N=$(call 
BuildFirmware/Default4M/$(1),$(1),nbg-419n,N
  Image/Build/Profile/MZKW300NH2=$(call 
BuildFirmware/Edimax/$(1),$(1),mzk-w300nh2,MZK-W300NH2,$(mzkw300nh2_mtd_size),CSYS,RN52,0x50000,0xc0000)
  Image/Build/Profile/MZKWDPR=$(call 
BuildFirmware/Default8M/$(1),$(1),mzk-wdpr,MZK-WDPR)
  Image/Build/Profile/NCS601W=$(call 
BuildFirmware/Default8M/$(1),$(1),ncs601W,NCS601W)
+Image/Build/Profile/NIXCOREX1=$(call 
BuildFirmware/NIXCOREX1/$(1),$(1),nixcorex1,NIXCOREX1)
  nw718_mtd_size=3801088
  Image/Build/Profile/NW718=$(call 
BuildFirmware/CustomFlashFactory/$(1),$(1),nw718m,NW718,$(nw718_mtd_size),ARA1B4NCRNW718;1,factory)
  Image/Build/Profile/M2M=$(call 
BuildFirmware/Default8M/$(1),$(1),m2m,M2M,Linux Kernel Image)
@@ -353,6 +369,7 @@ define Image/Build/Profile/Default
      $(call Image/Build/Profile/MZKWDPR,$(1))
      $(call Image/Build/Profile/NBG-419N,$(1))
      $(call Image/Build/Profile/NCS601W,$(1))
+    $(call Image/Build/Profile/NIXCOREX1,$(1))
      $(call Image/Build/Profile/NW718,$(1))
      $(call Image/Build/Profile/MINIEMBWIFI,$(1))
      $(call Image/Build/Profile/MINIEMBPLUG,$(1))
diff --git a/target/linux/ramips/rt305x/profiles/nixcore.mk 
b/target/linux/ramips/rt305x/profiles/nixcore.mk
new file mode 100644
index 0000000..22dee9b
--- /dev/null
+++ b/target/linux/ramips/rt305x/profiles/nixcore.mk
@@ -0,0 +1,20 @@
+#
+# Copyright (C) 2014 OpenWrt.org
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+
+define Profile/NIXCOREX1
+    NAME:=NixcoreX1
+    PACKAGES:=\
+        kmod-usb-core kmod-usb-ohci kmod-usb2 \
+        kmod-i2c-core kmod-i2c-ralink \
+        kmod-spi-dev
+endef
+
+define Profile/NIXCOREX1/Description
+    Package set for Nixcore X1 board
+endef
+
+$(eval $(call Profile,NIXCOREX1))



From eyal.birger at gmail.com  Mon Jun  6 21:48:17 2016
From: eyal.birger at gmail.com (Eyal Birger)
Date: Tue, 7 Jun 2016 07:48:17 +0300
Subject: [LEDE-DEV] [OpenWrt-Devel] [PATCH libubox] blobmsg_json: add
 new functions blobmsg_format_json_value*
In-Reply-To: <72d43356-1b13-6c1d-ef64-2b116705f6f9@universe-factory.net>
References: <dbc90f6d05a606753e2576bd6fc3569c5958885a.1464812878.git.mschiffer@universe-factory.net>
 <e63ded11-8ba8-c0da-78ee-a5be70eca1fd@phrozen.org>
 <02fc8e5d-d737-58b0-e712-d0b9ebf58f9e@universe-factory.net>
 <A597E23F-9BF7-4C47-8F36-AA527F32E669@gmail.com>
 <72d43356-1b13-6c1d-ef64-2b116705f6f9@universe-factory.net>
Message-ID: <CAHsH6GtBW1Dn=797x-ieAsBwdMvwWvUjPawaK0OZf1AARvMhTw@mail.gmail.com>

On Sat, Jun 4, 2016 at 6:27 PM, Matthias Schiffer
<mschiffer at universe-factory.net> wrote:
> On 06/03/2016 04:55 PM, Eyal Birger wrote:
>>
>> Hi,
>>
>>> On 3 Jun 2016, at 13:11, Matthias Schiffer <mschiffer at universe-factory.net> wrote:
>>>
>> (snip)
>>>
>>> 1) and 2) would allow blobmsg to store everything that json-c can (with the
>>> caveat that json-c stores integers as int64 internally, while blobmsg_json
>>> uses int32) -
>>
>> We also noticed this as a problem for us since when converting json strings to blobmsg, integers become signed and thus no more than INT32_MAX can be used.
>>
>> Do you plans to approach this in your patchsets?
>>
>> Eyal
>
> I don't think this can be fixed easily without having to adjust all
> blobmsg_json users, as the blobmsg_policy entries contain
> BLOBMSG_TYPE_INT32 everywhere. I don't know how much the ubus methods are
> considered unchangeable ABI.
>
> Possible approaches include:
>
> 1) Always map JSON intergers to int64. Will cause an incompatible ABI
> change for all ubus calls when used with blobmsg_json.
>
> 2) Add new blobmsg_add_json_* functions which use int64. The caller of a
> ubus method would need to know if the service excepts int32 or int64
> integers, making this more or less unusable for the ubus CLI tool
>
> 3) Adjust blobmsg_add_json_* to encode integers as int32 or int64 depending
> on the value itself. We'd need to extend the blobmsg_policy with some kind
> of BLOBMSG_TYPE_INT which accepts both int32 and int64, and add a
> blobmsg_get_int function that can work with different lengths. Existing
> software would continue to work as long as the supplied values fit into an
> int32.
>

Alas, I think this may still cause an ABI change, as the current int32
implementation caps
values at INT32_MAX; so when BLOBMSG_TYPE_INT32 is specified in the
policy, a value
is _always_ available, whereas in this solution, sometimes it won't
be. Am I wrong?

> 4) Introduce a new BLOBMSG_TYPE_INT type for variable-length integers,
> together with a blobmsg_get_int function (note that, in contrast to 3),
> BLOBMSG_TYPE_INT is a real blobmsg type in this approach). The length of
> records is encoded in the blobmsg format already. Again, this approach
> would need all software to be adjusted.
>
> 1) and 4) are very similar and would cause a hard ABI break for many ubus
> methods. If we want to avoid a flagday change, 3) seems like the best
> option - or some other approach I haven't listed?
>

I tried to think of a way in which we can have blobmsg_format_element() encode
*both* int32 and int64 values at the same time. It might work for parsing,
but won't work with the current serialization code, not to mention
that it would be
a very ugly hack.

Eyal.

> Matthias


From john at phrozen.org  Mon Jun  6 22:12:59 2016
From: john at phrozen.org (John Crispin)
Date: Tue, 7 Jun 2016 07:12:59 +0200
Subject: [LEDE-DEV] [PATCH] [ramips] Added NixCore X1 target V2
In-Reply-To: <5756126C.5060101@nixcores.com>
References: <5756126C.5060101@nixcores.com>
Message-ID: <c1c05543-6b19-d94f-7feb-ef0802908090@phrozen.org>

Hi Drew,

this patch seems to use the old devicetree layout and image building
code. do you think you could rebase this and make it work ontop of
latest source.git or do you need help to do that ? this patch wont apply
as is.

another question, did you build this yourself or is this a rebranded
whitelabel product ? i think we already support this board (or one that
looks almost identical, need to see if i can find it in my router zoo today)

	John

On 07/06/2016 02:16, Drew from NixCore wrote:
> Added NixCore X1 ramips target http://nixcores.com. This builds 8M and 16M
> images
> 
> Signed-off-by: Drew Gaylo <drew at nixcores.com>
> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
> b/target/linux/ramips/base-files/etc/board.d/02_network
> index 4728c75..69c0125 100755
> --- a/target/linux/ramips/base-files/etc/board.d/02_network
> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
> @@ -77,6 +77,7 @@ ramips_setup_interfaces()
>      mt7628|\
>      mzk-750dhp|\
>      mzk-w300nh2|\
> +    nixcore|\
>      oy-0001|\
>      pbr-m1|\
>      psg1208|\
> diff --git a/target/linux/ramips/base-files/lib/ramips.sh
> b/target/linux/ramips/base-files/lib/ramips.sh
> index cbe455d..76f0e43 100755
> --- a/target/linux/ramips/base-files/lib/ramips.sh
> +++ b/target/linux/ramips/base-files/lib/ramips.sh
> @@ -316,6 +316,9 @@ ramips_board_detect() {
>      *"NCS601W")
>          name="ncs601w"
>          ;;
> +    *"NixcoreX1")
> +        name="nixcore-x1"
> +        ;;
>      *"NW718")
>          name="nw718"
>          ;;
> diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh
> b/target/linux/ramips/base-files/lib/upgrade/platform.sh
> index 91c9997..0094568 100755
> --- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
> @@ -94,6 +94,7 @@ platform_check_image() {
>      mzk-w300nh2|\
>      mzk-wdpr|\
>      nbg-419n|\
> +    nixcore|\
>      nw718|\
>      oy-0001|\
>      pbr-m1|\
> diff --git a/target/linux/ramips/dts/NIXCOREX1-16M.dts
> b/target/linux/ramips/dts/NIXCOREX1-16M.dts
> new file mode 100644
> index 0000000..c7ec410
> --- /dev/null
> +++ b/target/linux/ramips/dts/NIXCOREX1-16M.dts
> @@ -0,0 +1,186 @@
> +/dts-v1/;
> +
> +/include/ "rt5350.dtsi"
> +
> +/ {
> +    compatible = "NixcoreX1", "ralink,rt5350-soc";
> +    model = "NixcoreX1";
> +
> +    palmbus at 10000000 {
> +        /* Re-enable the gpio1 ports */
> +        gpio1: gpio at 660 {
> +            status = "okay";
> +        };
> +
> +        i2c at 900 {
> +            status = "okay";
> +        };
> +        uart at 500 {
> +            status = "okay";
> +            /* Mix of uart and gpio */
> +            reset-names = "gpio uartf";
> +        };
> +        spi at b00 {
> +            status = "okay";
> +
> +            m25p80 at 0 {
> +                #address-cells = <1>;
> +                #size-cells = <1>;
> +                compatible = "s25fl064k";
> +                reg = <0>;
> +                linux,modalias = "m25p80", "s25fl064k";
> +                spi-max-frequency = <10000000>;
> +
> +                partition at 0 {
> +                    label = "uboot";
> +                    reg = <0x0 0x30000>;
> +                    read-only;
> +                };
> +
> +                partition at 30000 {
> +                    label = "uboot-env";
> +                    reg = <0x30000 0x10000>;
> +                    read-only;
> +                };
> +
> +                factory: partition at 40000 {
> +                    label = "factory";
> +                    reg = <0x40000 0x10000>;
> +                    read-only;
> +                };
> +
> +                partition at 50000 {
> +                    label = "firmware";
> +                    reg = <0x50000 0x7b0000>;
> +                };
> +            };
> +
> +            spidev at 1 {
> +                compatible = "linux,spidev";
> +                spi-max-frequency = <10000000>;
> +                reg = <1>;
> +            };
> +        };
> +    };
> +
> +    pinctrl {
> +        state_default: pinctrl0 {
> +            gpio {
> +                /* Associate the tjag, uartf and led groups with gpio */
> +                ralink,group = "jtag", "led", "spi_cs1";
> +                /* How do we set individual pins? */
> +                ralink,function = "gpio";
> +            };
> +        };
> +    };
> +
> +    ethernet at 10100000 {
> +        mtd-mac-address = <&factory 0x4>;
> +    };
> +
> +    esw at 10110000 {
> +        ralink,portmap = <0x17>;
> +    };
> +
> +    wmac at 10180000 {
> +        ralink,mtd-eeprom = <&factory 0>;
> +    };
> +
> +    ehci at 101c0000 {
> +        status = "okay";
> +    };
> +
> +    ohci at 101c1000 {
> +        status = "okay";
> +    };
> +
> +    chosen {
> +        bootargs = "console=ttyS1,57600";
> +    };
> +    gpio-export {
> +        compatible = "gpio-export";
> +        #size-cells = <0>;
> +
> +        gpio0 {
> +            gpio-export,name = "gpio0";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio0 0 0>;
> +        };
> +
> +        /* GPIOs 1-6 are I2C,SPI */
> +
> +        /* GPIO 7-14 are uart1 */
> +
> +        /* GPIOs 15 & 16 are uart2 */
> +
> +        /* JTAG */
> +        gpio17 {
> +            /* JTAG_TDO */
> +            gpio-export,name = "gpio17";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio0 17 0>;
> +        };
> +        gpio18 {
> +            /* JTAG_TDI */
> +            gpio-export,name = "gpio18";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio0 18 0>;
> +        };
> +        gpio19 {
> +            /* JTAG_TMS */
> +            gpio-export,name = "gpio19";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio0 19 0>;
> +        };
> +        gpio20 {
> +            /* JTAG_TCLK */
> +            gpio-export,name = "gpio20";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio0 20 0>;
> +        };
> +        gpio21 {
> +            /* JTAG_TRST_N */
> +            gpio-export,name = "gpio21";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio0 21 0>;
> +        };
> +
> +        /* ETH LEDs */
> +        /*
> +        gpio22 {
> +            gpio-export,name = "gpio22";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio1 0 0>;
> +        };
> +        gpio23 {
> +            gpio-export,name = "gpio23";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio1 1 0>;
> +        };
> +        gpio24 {
> +            gpio-export,name = "gpio24";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio1 2 0>;
> +        };
> +        gpio25 {
> +            gpio-export,name = "gpio25";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio1 3 0>;
> +        };
> +        */
> +        gpio26 {
> +            /* ETH4_LED */
> +            gpio-export,name = "gpio26";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio1 4 0>;
> +        };
> +
> +        gpio27 {
> +            /* spi_cs1 */
> +            gpio-export,name = "gpio27";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio1 5 0>;
> +        };
> +    };
> +
> +};
> diff --git a/target/linux/ramips/dts/NIXCOREX1-8M.dts
> b/target/linux/ramips/dts/NIXCOREX1-8M.dts
> new file mode 100644
> index 0000000..c7ec410
> --- /dev/null
> +++ b/target/linux/ramips/dts/NIXCOREX1-8M.dts
> @@ -0,0 +1,186 @@
> +/dts-v1/;
> +
> +/include/ "rt5350.dtsi"
> +
> +/ {
> +    compatible = "NixcoreX1", "ralink,rt5350-soc";
> +    model = "NixcoreX1";
> +
> +    palmbus at 10000000 {
> +        /* Re-enable the gpio1 ports */
> +        gpio1: gpio at 660 {
> +            status = "okay";
> +        };
> +
> +        i2c at 900 {
> +            status = "okay";
> +        };
> +        uart at 500 {
> +            status = "okay";
> +            /* Mix of uart and gpio */
> +            reset-names = "gpio uartf";
> +        };
> +        spi at b00 {
> +            status = "okay";
> +
> +            m25p80 at 0 {
> +                #address-cells = <1>;
> +                #size-cells = <1>;
> +                compatible = "s25fl064k";
> +                reg = <0>;
> +                linux,modalias = "m25p80", "s25fl064k";
> +                spi-max-frequency = <10000000>;
> +
> +                partition at 0 {
> +                    label = "uboot";
> +                    reg = <0x0 0x30000>;
> +                    read-only;
> +                };
> +
> +                partition at 30000 {
> +                    label = "uboot-env";
> +                    reg = <0x30000 0x10000>;
> +                    read-only;
> +                };
> +
> +                factory: partition at 40000 {
> +                    label = "factory";
> +                    reg = <0x40000 0x10000>;
> +                    read-only;
> +                };
> +
> +                partition at 50000 {
> +                    label = "firmware";
> +                    reg = <0x50000 0x7b0000>;
> +                };
> +            };
> +
> +            spidev at 1 {
> +                compatible = "linux,spidev";
> +                spi-max-frequency = <10000000>;
> +                reg = <1>;
> +            };
> +        };
> +    };
> +
> +    pinctrl {
> +        state_default: pinctrl0 {
> +            gpio {
> +                /* Associate the tjag, uartf and led groups with gpio */
> +                ralink,group = "jtag", "led", "spi_cs1";
> +                /* How do we set individual pins? */
> +                ralink,function = "gpio";
> +            };
> +        };
> +    };
> +
> +    ethernet at 10100000 {
> +        mtd-mac-address = <&factory 0x4>;
> +    };
> +
> +    esw at 10110000 {
> +        ralink,portmap = <0x17>;
> +    };
> +
> +    wmac at 10180000 {
> +        ralink,mtd-eeprom = <&factory 0>;
> +    };
> +
> +    ehci at 101c0000 {
> +        status = "okay";
> +    };
> +
> +    ohci at 101c1000 {
> +        status = "okay";
> +    };
> +
> +    chosen {
> +        bootargs = "console=ttyS1,57600";
> +    };
> +    gpio-export {
> +        compatible = "gpio-export";
> +        #size-cells = <0>;
> +
> +        gpio0 {
> +            gpio-export,name = "gpio0";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio0 0 0>;
> +        };
> +
> +        /* GPIOs 1-6 are I2C,SPI */
> +
> +        /* GPIO 7-14 are uart1 */
> +
> +        /* GPIOs 15 & 16 are uart2 */
> +
> +        /* JTAG */
> +        gpio17 {
> +            /* JTAG_TDO */
> +            gpio-export,name = "gpio17";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio0 17 0>;
> +        };
> +        gpio18 {
> +            /* JTAG_TDI */
> +            gpio-export,name = "gpio18";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio0 18 0>;
> +        };
> +        gpio19 {
> +            /* JTAG_TMS */
> +            gpio-export,name = "gpio19";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio0 19 0>;
> +        };
> +        gpio20 {
> +            /* JTAG_TCLK */
> +            gpio-export,name = "gpio20";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio0 20 0>;
> +        };
> +        gpio21 {
> +            /* JTAG_TRST_N */
> +            gpio-export,name = "gpio21";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio0 21 0>;
> +        };
> +
> +        /* ETH LEDs */
> +        /*
> +        gpio22 {
> +            gpio-export,name = "gpio22";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio1 0 0>;
> +        };
> +        gpio23 {
> +            gpio-export,name = "gpio23";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio1 1 0>;
> +        };
> +        gpio24 {
> +            gpio-export,name = "gpio24";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio1 2 0>;
> +        };
> +        gpio25 {
> +            gpio-export,name = "gpio25";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio1 3 0>;
> +        };
> +        */
> +        gpio26 {
> +            /* ETH4_LED */
> +            gpio-export,name = "gpio26";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio1 4 0>;
> +        };
> +
> +        gpio27 {
> +            /* spi_cs1 */
> +            gpio-export,name = "gpio27";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio1 5 0>;
> +        };
> +    };
> +
> +};
> diff --git a/target/linux/ramips/image/rt305x.mk
> b/target/linux/ramips/image/rt305x.mk
> index da7fc46..db12a8e 100644
> --- a/target/linux/ramips/image/rt305x.mk
> +++ b/target/linux/ramips/image/rt305x.mk
> @@ -100,6 +100,21 @@ define BuildFirmware/HLKRM04/initramfs
>      mkhilinkfw -e -i$(call imgname,$(1),$(2))-uImage.bin -o $(call
> imgname,$(1),$(2))-factory.bin;
>  endef
> 
> +# This is called to build the nixcore image.  Build both 8MB and 16MB
> +nixcore_8mb_mtd_size=8060928
> +nixcore_16mb_mtd_size=16449536
> +define BuildFirmware/NIXCOREX1/squashfs
> +# Args are XXX, nixcore-mM and NIXCOREX1-xM
> +    $(call
> BuildFirmware/CustomFlash/$(1),$(1),$(2)-8M,$(3)-8M,$(nixcore_8mb_mtd_size))
> 
> +    $(call
> BuildFirmware/CustomFlash/$(1),$(1),$(2)-16M,$(3)-16M,$(nixcore_16mb_mtd_size))
> 
> +    # Can do somethings here after the build?
> +endef
> +define BuildFirmware/NIXCOREX1/initramfs
> +# Args are XXXX, nixcore-mM and NIXCOREX1-xM
> +    $(call BuildFirmware/OF/initramfs,$(1),$(2)-8M,$(3)-8M)
> +    $(call BuildFirmware/OF/initramfs,$(1),$(2)-16M,$(3)-16M)
> +endef
> +
>  vocore_8mb_mtd_size=8060928
>  vocore_16mb_mtd_size=16449536
>  define BuildFirmware/VOCORE/squashfs
> @@ -257,6 +272,7 @@ Image/Build/Profile/NBG-419N=$(call
> BuildFirmware/Default4M/$(1),$(1),nbg-419n,N
>  Image/Build/Profile/MZKW300NH2=$(call
> BuildFirmware/Edimax/$(1),$(1),mzk-w300nh2,MZK-W300NH2,$(mzkw300nh2_mtd_size),CSYS,RN52,0x50000,0xc0000)
> 
>  Image/Build/Profile/MZKWDPR=$(call
> BuildFirmware/Default8M/$(1),$(1),mzk-wdpr,MZK-WDPR)
>  Image/Build/Profile/NCS601W=$(call
> BuildFirmware/Default8M/$(1),$(1),ncs601W,NCS601W)
> +Image/Build/Profile/NIXCOREX1=$(call
> BuildFirmware/NIXCOREX1/$(1),$(1),nixcorex1,NIXCOREX1)
>  nw718_mtd_size=3801088
>  Image/Build/Profile/NW718=$(call
> BuildFirmware/CustomFlashFactory/$(1),$(1),nw718m,NW718,$(nw718_mtd_size),ARA1B4NCRNW718;1,factory)
> 
>  Image/Build/Profile/M2M=$(call
> BuildFirmware/Default8M/$(1),$(1),m2m,M2M,Linux Kernel Image)
> @@ -353,6 +369,7 @@ define Image/Build/Profile/Default
>      $(call Image/Build/Profile/MZKWDPR,$(1))
>      $(call Image/Build/Profile/NBG-419N,$(1))
>      $(call Image/Build/Profile/NCS601W,$(1))
> +    $(call Image/Build/Profile/NIXCOREX1,$(1))
>      $(call Image/Build/Profile/NW718,$(1))
>      $(call Image/Build/Profile/MINIEMBWIFI,$(1))
>      $(call Image/Build/Profile/MINIEMBPLUG,$(1))
> diff --git a/target/linux/ramips/rt305x/profiles/nixcore.mk
> b/target/linux/ramips/rt305x/profiles/nixcore.mk
> new file mode 100644
> index 0000000..22dee9b
> --- /dev/null
> +++ b/target/linux/ramips/rt305x/profiles/nixcore.mk
> @@ -0,0 +1,20 @@
> +#
> +# Copyright (C) 2014 OpenWrt.org
> +#
> +# This is free software, licensed under the GNU General Public License v2.
> +# See /LICENSE for more information.
> +#
> +
> +define Profile/NIXCOREX1
> +    NAME:=NixcoreX1
> +    PACKAGES:=\
> +        kmod-usb-core kmod-usb-ohci kmod-usb2 \
> +        kmod-i2c-core kmod-i2c-ralink \
> +        kmod-spi-dev
> +endef
> +
> +define Profile/NIXCOREX1/Description
> +    Package set for Nixcore X1 board
> +endef
> +
> +$(eval $(call Profile,NIXCOREX1))
> 
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


From xinxing.huchn at gmail.com  Mon Jun  6 15:11:15 2016
From: xinxing.huchn at gmail.com (Xinxing Hu)
Date: Tue, 7 Jun 2016 06:11:15 +0800
Subject: [LEDE-DEV] libubox, procd: init process hangs
Message-ID: <f2dd22dd-8fff-4521-5e3f-cdbf6faa0275@gmail.com>

Hi Guys,

I have another idea about this issue. Maybe it is not kernel, but uloop 
related. I read procd and libubox code a little bit, and it seems there 
is a potential issue existing in uloop_run().

In general, uloop_run() is running in a while loop:

while()
         1, Process timeouts list

         2, Handle terminated child processes

         3, uloop_run_events(timeout) => calls epoll_wait()
done

During boot, procd_inittab_run("sysinit") is called in Step1, which 
calls add_initd(). add_initd() would add an entry in timeouts list, 
whose callback function is to execute an rc.d/S* script.

When the while loop goes back to Step1 again, the timeouts list would be 
processed, and an rc.d/S* script would be executed in a child process 
while the parent process remains in the while loop. If everything goes 
fine, when the child process is terminated, the parent process will 
handle terminated child process by calling waitpid() in the while loop. 
A process callback function will also be called, which adds another 
timeout entry in timeouts list. This new entry corresponds to the next 
rc.d/S* script to be executed. When the while loop reaches Step1 again, 
the next rc.d/S* script would be invoked.

Everything looks OK till now. However, due to process scheduling, 
problems might happen when uloop_run_events(uloop_get_next_timeout(&tv)) 
is called. For instance: if the child process is still running when 
uloop_get_next_timeout(&tv) is called, then the timeouts list is already 
empty at that time, so the return value of uloop_get_next_timeout(&tv) 
would be -1. Furthermore, if the child process is terminated and signal 
handler is executed before epoll_wait() is called, then epoll_wait will 
block the parent process forever until some other events it is listening 
to arrive. In this sense, other events arriving just hide this issue. 
During the boot, as long as /etc/rc.d/S* is not finished executing, 
epoll_wait() should never be blocked.

I think, a potential solution might be: during initialization, we let 
uloop listens to a kind of 'dummy' event. Every time when the child 
process finishes executing a rc.d/S* script, we send a 'dummy' event. In 
this case, epoll_wait would never be blocked during booting.

Best Regards,
Xinxing




On 2016/5/17 18:03, Mats Karrman wrote:
Hi Felix, others,

I have been experiencing problems with the init scripts dispatch
suddenly stopping (indefinitely).
This happens maybe once in 100 reboots.
After inserting a new start script that launches another daemon
(cgrulesengd) very early in the boot process, the failures started to
come a lot more frequently, maybe once in 10 reboots, making this a real
issue.
I'm normally using the versions of procd and libubox selected by OpenWRT
BB branch but I have tested the latest versions from the git repos with
the same result.
So far I have only got this to happen on a quite fast board (ARM dual
CorexA9 @ 1GHz).
Inserting trace prints in libubox changes behavior, also suggesting the
problem is timing dependent.

When init hangs:
- it is still possible to log in on console
- there is always a zombie start script, e.g. S11sysctl.
- by killing a process (e.g. ubusd or cgrulesengd) the init process
continues.
- otherwise generating an event, e.g inserting something into a USB port
also makes the init continue.

I have traced the problem down to the "epoll_wait" call in
libubox::uloop.c::uloop_fetch_events().
The following patch makes sure epoll_wait is never called without a timeout.
My tests show that this solves the problem.
I have been able to observe the case when the boot gets stuck and then
continues after the 8s timeout.
However I'm not sure that this is the correct fix for the problem as
there may be other reasons that there is no event in the first place.
Your feedback would be welcome!

BR // Mats
Currently working for Inteno Broadband Technology AB

---
Avast ??????????????????
https://www.avast.com/antivirus



From danutbug at gmail.com  Tue Jun  7 00:05:47 2016
From: danutbug at gmail.com (Dan Bugnar)
Date: Tue, 7 Jun 2016 10:05:47 +0300
Subject: [LEDE-DEV] Fwd: [PATCH 2/3] [ubox] syslog: change log buffer size
In-Reply-To: <CAGe4CuKxc2kjHcRy7vMhssVLuCC=Z-f0=biyFSFGEMw6R0sB-A@mail.gmail.com>
References: <1464951549-4152-1-git-send-email-danutbug@gmail.com>
 <1464951549-4152-2-git-send-email-danutbug@gmail.com>
 <18073257-4ff6-c15b-335b-47d2d11222bf@phrozen.org>
 <CAGe4CuJYWws+NEc7GSTwu5e=vposDqCwnTUkvNLy1Q0jw++jXg@mail.gmail.com>
 <CAGe4CuL1yC4NS8-QLkaLvjU9S7JEVUXkhR3eSEBmzRK7a2K=UA@mail.gmail.com>
 <CAGe4CuKxc2kjHcRy7vMhssVLuCC=Z-f0=biyFSFGEMw6R0sB-A@mail.gmail.com>
Message-ID: <CAGe4Cu+aTeRx50fySU_aWdqe3XHoXXPpdZfv2jS+05dLTJrv9g@mail.gmail.com>

>                        if (entries_size < size) {
>                                memcpy(start, l, copy_len);
>                                start = (struct log_head *) &start->data[l->size];
>                        } else{
>                                entries_size -= copy_len;
>                        }
>

Yes, the first block is executed just when the entries_size it fits in
the new buffer size, otherwise we skip entries in the second block.

>   void
>   log_init(int _log_size)
>   {
>        if (_log_size > 0)
>                log_size = _log_size;
>
> what happened to log_size ? if you dont use it anymore remove it fully
> please
>
log_size is used when the new buffer size is equal to the current
buffer size and we keep the current buffer intact.


From john at phrozen.org  Tue Jun  7 00:55:24 2016
From: john at phrozen.org (John Crispin)
Date: Tue, 7 Jun 2016 09:55:24 +0200
Subject: [LEDE-DEV] [PATCH] libnet-1.2.x: enable HAVE_PACKET_SOCKET
In-Reply-To: <1463662622-15688-1-git-send-email-alin.nastac@gmail.com>
References: <1463662622-15688-1-git-send-email-alin.nastac@gmail.com>
Message-ID: <f1c49b43-2d1b-2cbb-cd98-be5ed5f3af18@phrozen.org>



On 19/05/2016 14:57, Alin Nastac wrote:
> There is already a CONFIGURE_VAR set in here that seem
> to have the same purpose, but it doesn't do the trick
> in my cause (autoconf 2.69).
> ---
>  libs/libnet-1.2.x/Makefile | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libs/libnet-1.2.x/Makefile b/libs/libnet-1.2.x/Makefile
> index a791163..062c7b6 100644
> --- a/libs/libnet-1.2.x/Makefile
> +++ b/libs/libnet-1.2.x/Makefile
> @@ -39,6 +39,7 @@ CONFIGURE_ARGS += \
>  CONFIGURE_VARS += \
>  	ac_cv_libnet_endianess=$(ENDIANESS) \
>  	ac_libnet_have_pf_packet=yes \
> +	libnet_cv_have_packet_socket=yes \
>  	LL_INT_TYPE=libnet_link_linux
>  
>  define Build/Configure
> 

Hi,

this package is hosted on the github feed. can you pleases send a PRC
there ?

	John


From dheeranmech at gmail.com  Sun Jun  5 11:09:18 2016
From: dheeranmech at gmail.com (Dheeran Senthilvel)
Date: Sun, 5 Jun 2016 23:39:18 +0530
Subject: [LEDE-DEV]  WRT1900ACS - Kernel 4.4.12 boot failure
In-Reply-To: <A5192BCC-101B-487A-913B-B3DA7A88C5DB@gmail.com>
References: <3B297414-1369-42F4-8F5D-AEBB95CD252E@gmail.com>
 <714e959e-ee43-e0d5-bed8-667e0cfea233@nbd.name>
 <EA4BA398-4BE7-4C4D-B1D7-A0B9B848DF9F@gmail.com>
 <0A593775-05EB-45BC-A3C3-07AAECE5B748@gmail.com>
 <E92BB9D3-BF9D-411A-825C-ED82CAE36E98@gmail.com>
 <97C7E072-BA76-4B93-BF6A-EE2B9C5B4C3B@gmail.com>
 <EEA4CAC8-265C-471F-A0EB-7654DC094895@gmail.com>
 <9BD7CD08-6799-4FF0-B8FA-380AFF42B5AA@gmail.com>
 <64E9BFC2-B9F1-4AAE-B799-0435B3091E41@gmail.com>
 <A5192BCC-101B-487A-913B-B3DA7A88C5DB@gmail.com>
Message-ID: <F013F569-4F7F-4903-9F8E-F29FA6599A8F@gmail.com>

Hi,
	Compiled build r504 followed by clean build. Still not clear what is causing the boot error mentioned previously in mailing list - May 2016.

	? [LEDE-DEV] WRT1900ACS - Kernel 4.4.11 boot failure   Dheeran Senthilvel
		? [LEDE-DEV] WRT1900ACS - Kernel 4.4.11 boot failure   Syrone Wong
		? [LEDE-DEV] WRT1900ACS - Kernel 4.4.11 boot failure   Felix Fietkau
			? [LEDE-DEV] WRT1900ACS - Kernel 4.4.11 boot failure   Dheeran Senthilvel
				? [LEDE-DEV] WRT1900ACS - Kernel 4.4.11 boot failure   Dheeran Senthilvel
				? [LEDE-DEV] WRT1900ACS - Kernel 4.4.11 boot failure   Felix Fietkau
				? [LEDE-DEV] WRT1900ACS - Kernel 4.4.11 boot failure   Dheeran Senthilvel
				? [LEDE-DEV] WRT1900ACS - Kernel 4.4.11 boot failure   Dheeran Senthilvel
				? [LEDE-DEV] WRT1900ACS - Kernel 4.4.11 boot failure   Dheeran Senthilvel
				? [LEDE-DEV] WRT1900ACS - Kernel 4.4.11 boot failure   Dheeran Senthilvel

Found some info that might help diagnose the problem.

=============== Initial Boot_Official Firm ==================
__   __                      _ _
|  \/  | __ _ _ ____   _____| | |
| |\/| |/ _` | '__\ \ / / _ \ | |
| |  | | (_| | |   \ V /  __/ | |
|_|  |_|\__,_|_|    \_/ \___|_|_|
       _   _     ____              _
      | | | |   | __ )  ___   ___ | |_
      | | | |___|  _ \ / _ \ / _ \| __|
      | |_| |___| |_) | (_) | (_) | |_
       \___/    |____/ \___/ \___/ \__|
** LOADER **


U-Boot 2013.01 (Mar 27 2015 - 16:50:46) Marvell version: 2014_T3.0p6

Boot version : v1.0.13

Board: RD-NAS-88F6820-DDR3
SoC:   MV88F6820 Rev A0
     running 2 CPUs
CPU:   ARM Cortex A9 MPCore (Rev 1) LE
     CPU 0
     CPU    @ 1600 [MHz]
     L2     @ 800 [MHz]
     TClock @ 200 [MHz]
     DDR    @ 800 [MHz]
     DDR 32 Bit Width, FastPath Memory Access, DLB Enabled, ECC Disabled
DRAM:  512 MiB

Map:   Code:                    0x1fea9000:0x1ff7632c
     BSS:                     0x1ffef6b4
     Stack:                   0x1f9a8f20
     Heap:                    0x1f9a9000:0x1fea9000
raise: Signal # 8 caught
U-ENV offset == 0x200000
raise: Signal # 8 caught
U-ENV offset == 0x200000
     U-Boot Environment:      0x00200000:0x00220000 (NAND)

NAND:  128 MiB
MMC:   mv_sdh: 0
DEVINFO offset == 0x900000
U-ENV offset == 0x200000
U-ENV offset == 0x200000
*** Warning - bad CRC, using default environment 

S-ENV offset == 0x240000


#### auto_recovery ####
[u_env] get auto_recovery == yes
[u_env] get auto_recovery == yes
[u_env] get boot_part == 1
[u_env] get boot_part_ready == 3
auto_recovery enabled:1, boot_part:1, boot_part_ready:3

S-ENV offset == 0x240000
[boot_count_read] block:0x240000, size:128KB, records:64
[boot_count_read_record] boot_count:0, next_record:47

[boot_count_write] erase:0, auto_recovery->block_offset:0x240000 offset=0x257800

Updating boot_count ...
[boot_count_write] offset:0x257800 , length:2048
done

PCI-e 0 (IF 0 - bus 0) Root Complex Interface, Detected Link X1, GEN 2.0
PCI-e 1 (IF 1 - bus 1) Root Complex Interface, Detected Link X1, GEN 1.1
USB2.0 0: Host Mode
USB3.0 1: Host Mode
USB3.0 0: Host Mode
Board configuration detected:
mvEthE6171SwitchBasicInit init
Net:
|  port  | Interface | PHY address  |
|--------|-----------|--------------|
| egiga0 |   RGMII   |     0x01     |
| egiga1 |   SGMII   |     0x00     |
egiga0 [PRIME], egiga1
auto_recovery_check changes bootcmd: run nandboot
Hit any key to stop autoboot:  0

NAND read: device 0 offset 0xa00000, size 0x600000
6291456 bytes read: OK
## Booting kernel from Legacy Image at 02000000 ...
 Image Name:   Linksys WRT1900ACS Router
 Created:      2015-10


											???x???x???x???x??? 

=============== Initial Boot_LEDE(r504) ==================
__   __                      _ _
|  \/  | __ _ _ ____   _____| | |
| |\/| |/ _` | '__\ \ / / _ \ | |
| |  | | (_| | |   \ V /  __/ | |
|_|  |_|\__,_|_|    \_/ \___|_|_|
       _   _     ____              _
      | | | |   | __ )  ___   ___ | |_
      | | | |___|  _ \ / _ \ / _ \| __|
      | |_| |___| |_) | (_) | (_) | |_
       \___/    |____/ \___/ \___/ \__|
** LOADER **


U-Boot 2013.01 (Mar 27 2015 - 16:50:46) Marvell version: 2014_T3.0p6

Boot version : v1.0.13

Board: RD-NAS-88F6820-DDR3
SoC:   MV88F6820 Rev A0
     running 2 CPUs
CPU:   ARM Cortex A9 MPCore (Rev 1) LE
     CPU 0
     CPU    @ 1600 [MHz]
     L2     @ 800 [MHz]
     TClock @ 200 [MHz]
     DDR    @ 800 [MHz]
     DDR 32 Bit Width, FastPath Memory Access, DLB Enabled, ECC Disabled
DRAM:  512 MiB

Map:   Code:                    0x1fea9000:0x1ff7632c
     BSS:                     0x1ffef6b4
     Stack:                   0x1f9a8f20
     Heap:                    0x1f9a9000:0x1fea9000
raise: Signal # 8 caught
U-ENV offset == 0x200000
raise: Signal # 8 caught
U-ENV offset == 0x200000
     U-Boot Environment:      0x00200000:0x00220000 (NAND)

NAND:  128 MiB
MMC:   mv_sdh: 0
DEVINFO offset == 0x900000
U-ENV offset == 0x200000
U-ENV offset == 0x200000
S-ENV offset == 0x240000


#### auto_recovery ####
[u_env] get auto_recovery == yes
[u_env] get auto_recovery == yes
[u_env] get boot_part == <NULL>
set boot_part=1 as default value at u_env
[u_env] get boot_part_ready == <NULL>
set boot_part_ready=3 as default value at u_env
auto_recovery enabled:1, boot_part:1, boot_part_ready:3

S-ENV offset == 0x240000
[boot_count_read] block:0x240000, size:128KB, records:64
[boot_count_read_record] boot_count:0, next_record:60

[boot_count_write] erase:0, auto_recovery->block_offset:0x240000 offset=0x25E000

Updating boot_count ...
[boot_count_write] offset:0x25E000 , length:2048
done

PCI-e 0 (IF 0 - bus 0) Root Complex Interface, Detected Link X1, GEN 2.0
PCI-e 1 (IF 1 - bus 1) Root Complex Interface, Detected Link X1, GEN 1.1
USB2.0 0: Host Mode
USB3.0 1: Host Mode
USB3.0 0: Host Mode
Board configuration detected:
mvEthE6171SwitchBasicInit init
Net:
|  port  | Interface | PHY address  |
|--------|-----------|--------------|
| egiga0 |   RGMII   |     0x01     |
| egiga1 |   SGMII   |     0x00     |
egiga0 [PRIME], egiga1
auto_recovery_check changes bootcmd: run nandboot
Hit any key to stop autoboot:  0
## Error: "nandboot" not defined

== 1st try ==
__   __                      _ _
|  \/  | __ _ _ ____   _____| | |
| |\/| |/ _` | '__\ \ / / _ \ | |
| |  | | (_| | |   \ V /  __/ | |
|_|  |_|\__,_|_|    \_/ \___|_|_|
       _   _     ____              _
      | | | |   | __ )  ___   ___ | |_
      | | | |___|  _ \ / _ \ / _ \| __|
      | |_| |___| |_) | (_) | (_) | |_
       \___/    |____/ \___/ \___/ \__|
** LOADER **


U-Boot 2013.01 (Mar 27 2015 - 16:50:46) Marvell version: 2014_T3.0p6

Boot version : v1.0.13

Board: RD-NAS-88F6820-DDR3
SoC:   MV88F6820 Rev A0
     running 2 CPUs
CPU:   ARM Cortex A9 MPCore (Rev 1) LE
     CPU 0
     CPU    @ 1600 [MHz]
     L2     @ 800 [MHz]
     TClock @ 200 [MHz]
     DDR    @ 800 [MHz]
     DDR 32 Bit Width, FastPath Memory Access, DLB Enabled, ECC Disabled
DRAM:  512 MiB

Map:   Code:                    0x1fea9000:0x1ff7632c
     BSS:                     0x1ffef6b4
     Stack:                   0x1f9a8f20
     Heap:                    0x1f9a9000:0x1fea9000
raise: Signal # 8 caught
U-ENV offset == 0x200000
raise: Signal # 8 caught
U-ENV offset == 0x200000
     U-Boot Environment:      0x00200000:0x00220000 (NAND)

NAND:  128 MiB
MMC:   mv_sdh: 0
DEVINFO offset == 0x900000
U-ENV offset == 0x200000
U-ENV offset == 0x200000
S-ENV offset == 0x240000


#### auto_recovery ####
[u_env] get auto_recovery == yes
[u_env] get auto_recovery == yes
[u_env] get boot_part == <NULL>
set boot_part=1 as default value at u_env
[u_env] get boot_part_ready == <NULL>
set boot_part_ready=3 as default value at u_env
auto_recovery enabled:1, boot_part:1, boot_part_ready:3

S-ENV offset == 0x240000
[boot_count_read] block:0x240000, size:128KB, records:64
[boot_count_read_record] boot_count:1, next_record:61

[boot_count_write] erase:0, auto_recovery->block_offset:0x240000 offset=0x25E800

Updating boot_count ...
[boot_count_write] offset:0x25E800 , length:2048
done

PCI-e 0 (IF 0 - bus 0) Root Complex Interface, Detected Link X1, GEN 2.0
PCI-e 1 (IF 1 - bus 1) Root Complex Interface, Detected Link X1, GEN 1.1
USB2.0 0: Host Mode
USB3.0 1: Host Mode
USB3.0 0: Host Mode
Board configuration detected:
mvEthE6171SwitchBasicInit init
Net:
|  port  | Interface | PHY address  |
|--------|-----------|--------------|
| egiga0 |   RGMII   |     0x01     |
| egiga1 |   SGMII   |     0x00     |
egiga0 [PRIME], egiga1
auto_recovery_check changes bootcmd: run nandboot
Hit any key to stop autoboot:  0
## Error: "nandboot" not defined
Marvell>> reset
resetting ...

== 2nd Try ==

__   __                      _ _
|  \/  | __ _ _ ____   _____| | |
| |\/| |/ _` | '__\ \ / / _ \ | |
| |  | | (_| | |   \ V /  __/ | |
|_|  |_|\__,_|_|    \_/ \___|_|_|
       _   _     ____              _
      | | | |   | __ )  ___   ___ | |_
      | | | |___|  _ \ / _ \ / _ \| __|
      | |_| |___| |_) | (_) | (_) | |_
       \___/    |____/ \___/ \___/ \__|
** LOADER **


U-Boot 2013.01 (Mar 27 2015 - 16:50:46) Marvell version: 2014_T3.0p6

Boot version : v1.0.13

Board: RD-NAS-88F6820-DDR3
SoC:   MV88F6820 Rev A0
     running 2 CPUs
CPU:   ARM Cortex A9 MPCore (Rev 1) LE
     CPU 0
     CPU    @ 1600 [MHz]
     L2     @ 800 [MHz]
     TClock @ 200 [MHz]
     DDR    @ 800 [MHz]
     DDR 32 Bit Width, FastPath Memory Access, DLB Enabled, ECC Disabled
DRAM:  512 MiB

Map:   Code:                    0x1fea9000:0x1ff7632c
     BSS:                     0x1ffef6b4
     Stack:                   0x1f9a8f20
     Heap:                    0x1f9a9000:0x1fea9000
raise: Signal # 8 caught
U-ENV offset == 0x200000
raise: Signal # 8 caught
U-ENV offset == 0x200000
     U-Boot Environment:      0x00200000:0x00220000 (NAND)

NAND:  128 MiB
MMC:   mv_sdh: 0
DEVINFO offset == 0x900000
U-ENV offset == 0x200000
U-ENV offset == 0x200000
S-ENV offset == 0x240000


#### auto_recovery ####
[u_env] get auto_recovery == yes
[u_env] get auto_recovery == yes
[u_env] get boot_part == <NULL>
set boot_part=1 as default value at u_env
[u_env] get boot_part_ready == <NULL>
set boot_part_ready=3 as default value at u_env
auto_recovery enabled:1, boot_part:1, boot_part_ready:3

S-ENV offset == 0x240000
[boot_count_read] block:0x240000, size:128KB, records:64
[boot_count_read_record] boot_count:2, next_record:62

[boot_count_write] erase:0, auto_recovery->block_offset:0x240000 offset=0x25F000

Updating boot_count ...
[boot_count_write] offset:0x25F000 , length:2048
done

PCI-e 0 (IF 0 - bus 0) Root Complex Interface, Detected Link X1, GEN 2.0
PCI-e 1 (IF 1 - bus 1) Root Complex Interface, Detected Link X1, GEN 1.1
USB2.0 0: Host Mode
USB3.0 1: Host Mode
USB3.0 0: Host Mode
Board configuration detected:
mvEthE6171SwitchBasicInit init
Net:
|  port  | Interface | PHY address  |
|--------|-----------|--------------|
| egiga0 |   RGMII   |     0x01     |
| egiga1 |   SGMII   |     0x00     |
egiga0 [PRIME], egiga1
auto_recovery_check changes bootcmd: run nandboot
Hit any key to stop autoboot:  0
## Error: "nandboot" not defined
Marvell>> reset
resetting ?

== 3rd Try == <Triggers Recovery>==

__   __                      _ _
|  \/  | __ _ _ ____   _____| | |
| |\/| |/ _` | '__\ \ / / _ \ | |
| |  | | (_| | |   \ V /  __/ | |
|_|  |_|\__,_|_|    \_/ \___|_|_|
       _   _     ____              _
      | | | |   | __ )  ___   ___ | |_
      | | | |___|  _ \ / _ \ / _ \| __|
      | |_| |___| |_) | (_) | (_) | |_
       \___/    |____/ \___/ \___/ \__|
** LOADER **


U-Boot 2013.01 (Mar 27 2015 - 16:50:46) Marvell version: 2014_T3.0p6

Boot version : v1.0.13

Board: RD-NAS-88F6820-DDR3
SoC:   MV88F6820 Rev A0
     running 2 CPUs
CPU:   ARM Cortex A9 MPCore (Rev 1) LE
     CPU 0
     CPU    @ 1600 [MHz]
     L2     @ 800 [MHz]
     TClock @ 200 [MHz]
     DDR    @ 800 [MHz]
     DDR 32 Bit Width, FastPath Memory Access, DLB Enabled, ECC Disabled
DRAM:  512 MiB

Map:   Code:                    0x1fea9000:0x1ff7632c
     BSS:                     0x1ffef6b4
     Stack:                   0x1f9a8f20
     Heap:                    0x1f9a9000:0x1fea9000
raise: Signal # 8 caught
U-ENV offset == 0x200000
raise: Signal # 8 caught
U-ENV offset == 0x200000
     U-Boot Environment:      0x00200000:0x00220000 (NAND)

NAND:  128 MiB
MMC:   mv_sdh: 0
DEVINFO offset == 0x900000
U-ENV offset == 0x200000
U-ENV offset == 0x200000
S-ENV offset == 0x240000


#### auto_recovery ####
[u_env] get auto_recovery == yes
[u_env] get auto_recovery == yes
[u_env] get boot_part == <NULL>
set boot_part=1 as default value at u_env
[u_env] get boot_part_ready == <NULL>
set boot_part_ready=3 as default value at u_env
auto_recovery enabled:1, boot_part:1, boot_part_ready:3

S-ENV offset == 0x240000
[boot_count_read] block:0x240000, size:128KB, records:64
[boot_count_read_record] boot_count:3, next_record:63

[auto_recovery_init] BOOT_COUNT_TO_RECOVERY
[boot_count_write] erase:1, auto_recovery->block_offset:0x240000 offset=0x240000

Updating boot_count ...
[boot_count_write] offset:0x240000 , length:2048
done

PCI-e 0 (IF 0 - bus 0) Root Complex Interface, Detected Link X1, GEN 2.0
PCI-e 1 (IF 1 - bus 1) Root Complex Interface, Detected Link X1, GEN 1.1
USB2.0 0: Host Mode
USB3.0 1: Host Mode
USB3.0 0: Host Mode
Board configuration detected:
mvEthE6171SwitchBasicInit init
Net:
|  port  | Interface | PHY address  |
|--------|-----------|--------------|
| egiga0 |   RGMII   |     0x01     |
| egiga1 |   SGMII   |     0x00     |
egiga0 [PRIME], egiga1
Saving Environment to NAND...
U-ENV offset == 0x200000
Erasing Nand...
Writing to Nand... U-ENV offset == 0x200000
U-ENV offset == 0x200000
done
#### auto_recovery:2 ####
auto_recovery_check changes bootcmd: run altnandboot
Hit any key to stop autoboot:  0
## Error: "altnandboot" not defined

											???x???x???x???x??? 

=============== Partition Table_Linux 3.18_Official Firm ==================

armada-nand f10d0000.nand: Initialize HAL based NFC in 8bit mode with DMA Disabled using BCH 4bit ECC
NAND device: Manufacturer ID: 0x01, Chip ID: 0xf1 (AMD/Spansion NAND 128MiB 3,3V 8-bit), 128MiB, page size: 2048, OOB size: 64
Bad block table found at page 65472, version 0x01
Bad block table found at page 65408, version 0x01
10 cmdlinepart partitions found on MTD device armada-nand
Creating 10 MTD partitions on "armada-nand":
0x000000000000-0x000000200000 : "uboot"
0x000000200000-0x000000240000 : "u_env"
0x000000240000-0x000000280000 : "s_env"
0x000000900000-0x000000a00000 : "devinfo"
0x000000a00000-0x000003200000 : "kernel"
0x000001000000-0x000003200000 : "rootfs"
0x000003200000-0x000005a00000 : "alt_kernel"
0x000003800000-0x000005a00000 : "alt_rootfs"
0x000000a00000-0x000005a00000 : "ubifs"
0x000005a00000-0x000008000000 : "syscfg"

=============== Partition Table_LEDE(r504) ==================

[    0.917192] pxa3xx-nand f10d0000.flash: This platform can't do DMA on this device
[    0.925008] nand: device found, Manufacturer ID: 0x01, Chip ID: 0xf1
[    0.931387] nand: AMD/Spansion S34ML01G2
[    0.935334] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
[    0.942942] pxa3xx-nand f10d0000.flash: ECC strength 16, ECC step size 2048
[    0.950120] Bad block table found at page 65472, version 0x01
[    0.956233] Bad block table found at page 65408, version 0x01
[    0.962275] 10 ofpart partitions found on MTD device pxa3xx_nand-0
[    0.968479] Creating 10 MTD partitions on "pxa3xx_nand-0":
[    0.973995] 0x000000000000-0x000000200000 : "u-boot"
[    0.979273] 0x000000200000-0x000000240000 : "u_env"
[    0.984435] 0x000000240000-0x000000280000 : "s_env"
[    0.989586] 0x000000900000-0x000000a00000 : "devinfo"
[    0.994927] 0x000000a00000-0x000003200000 : "kernel1"
[    1.000279] 0x000001000000-0x000003200000 : "ubi"
[    1.005307] 0x000003200000-0x000005a00000 : "kernel2"
[    1.010650] 0x000003800000-0x000005a00000 : "rootfs2"
[    1.015993] 0x000005a00000-0x000008000000 : "syscfg"
[    1.021256] 0x000000280000-0x000000900000 : ?unused_area?
											???x???x???x???x??? 



Now running LEDE environment and collecting some more info:

=============== LEDE (r504) ================================


root at WRT1900ACS:/# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00200000 00020000 "u-boot"
mtd1: 00040000 00020000 "u_env"
mtd2: 00040000 00020000 "s_env"
mtd3: 00100000 00020000 "devinfo"
mtd4: 02800000 00020000 "kernel1"
mtd5: 02200000 00020000 "ubi"
mtd6: 02800000 00020000 "kernel2"
mtd7: 02200000 00020000 "rootfs2"
mtd8: 02600000 00020000 "syscfg"
mtd9: 00680000 00020000 ?unused_area?

root at WRT1900ACS:/# cat /etc/config/ubootenv

config ubootenv
      option dev '/dev/mtd1'
      option offset '0x0'
      option envsize '0x20000'
      option secsize '0x40000'

root at WRT1900ACS:/# cat /etc/fw_env.config
/dev/mtd1 0x0 0x20000 0x40000


root at WRT1900ACS:/# cat /etc/init.d/linksys_recovery
#!/bin/sh /etc/rc.common
# Copyright (C) 2015 OpenWrt.org

START=97
boot() {
. /lib/functions.sh
. /lib/mvebu.sh

case $(mvebu_board_name) in
      armada-385-linksys-caiman|armada-385-linksys-cobra|armada-385-linksys-shelby|armada-xp-linksys-mamba)
              # make sure auto_recovery in uboot is always on
              AUTO_RECOVERY_ENA="`fw_printenv -n auto_recovery`"
              if [ "$AUTO_RECOVERY_ENA" != "yes" ] ; then
                      fw_setenv auto_recovery yes
              fi
              # reset the boot counter
              mtd resetbc s_env

root at WRT1900ACS:/# fw_printenv
bootcmd=bootp; setenv bootargs root=/dev/nfs nfsroot=${serverip}:${rootpath} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm
bootdelay=5
baudrate=115200
auto_recovery=yes 

	==>> see that fw_printenv doesn?t return a expected result, this shows problem with boot variables. (May be MTD partition layout is to be blamed)

Moreover from the moment LEDE switched over to 4.4.11 the firmwares built manually and those obtained from the repo are not flash-able from official firmware, boots to official firmware after trying to flash LEDE. They need to be done serially through tftp. 

From leitec at gmail.com  Tue Jun  7 02:57:51 2016
From: leitec at gmail.com (Claudio Leite)
Date: Tue, 7 Jun 2016 05:57:51 -0400
Subject: [LEDE-DEV] WRT1900ACS - Kernel 4.4.12 boot failure
In-Reply-To: <F013F569-4F7F-4903-9F8E-F29FA6599A8F@gmail.com>
References: <714e959e-ee43-e0d5-bed8-667e0cfea233@nbd.name>
 <EA4BA398-4BE7-4C4D-B1D7-A0B9B848DF9F@gmail.com>
 <0A593775-05EB-45BC-A3C3-07AAECE5B748@gmail.com>
 <E92BB9D3-BF9D-411A-825C-ED82CAE36E98@gmail.com>
 <97C7E072-BA76-4B93-BF6A-EE2B9C5B4C3B@gmail.com>
 <EEA4CAC8-265C-471F-A0EB-7654DC094895@gmail.com>
 <9BD7CD08-6799-4FF0-B8FA-380AFF42B5AA@gmail.com>
 <64E9BFC2-B9F1-4AAE-B799-0435B3091E41@gmail.com>
 <A5192BCC-101B-487A-913B-B3DA7A88C5DB@gmail.com>
 <F013F569-4F7F-4903-9F8E-F29FA6599A8F@gmail.com>
Message-ID: <20160607095751.GA29607@pratt.mine.nu>

* Dheeran Senthilvel (dheeranmech at gmail.com) wrote:
> Hi,
> 	Compiled build r504 followed by clean build. Still not clear what is causing the boot error mentioned previously in mailing list - May 2016.
[snip]
> 
> auto_recovery_check changes bootcmd: run nandboot
> Hit any key to stop autoboot:  0
> ## Error: "nandboot" not defined

Have you tried the 'resetenv' command from u-boot?

resetenv- resetenv      - earse environment sector to reset all
variables to default.

I haven't tried this on a WRT1900AC, but on the EA4500 (which has a
somewhat similar u-boot) it correctly resets everything to default
values. Given that your u-boot settings are gone one way or another (as
your fw_printenv later shows) this might be worth a try.

-Claudio


From daniel at daniel.thecshore.com  Tue Jun  7 02:02:16 2016
From: daniel at daniel.thecshore.com (Daniel Curran-Dickinson)
Date: Tue, 07 Jun 2016 05:02:16 -0400
Subject: [LEDE-DEV] ACL kernel config options and 3.18
Message-ID: <1465290136.3094.24.camel@homehost>

iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAABlBMVEX///8AAABVwtN+AAAAeklEQVQY04XQzQ2EIBAF4IdMDIc5UAIlUIKlWMr0ZiMm28jOj+6iMXEOfBBmXgJAVLGlBkU3wcZ9I3Q7EdrAveowx6hZ0q6QJDsRnHlJwr+W4CHF7vLqTEenXABeUnSssbP8SdwdjTHEwcFDtQGKFuWjH8Lna8vAmfEF3NMPdAOsBscAAAAASUVORK5CYII=
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.10.4-0ubuntu2 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

Hi John,

I don't have a platform that is currently using 3.18, and on ar71xx I
can't even get 3.18 to get a proper kernel config never mind build, so
can we simply turn off the ACL config options for 3.18 and omit worrying
about getting the patch verified for that kernel version?

TBH I'm not sure there are any platforms anyone is actually using or
developing for on a regular basis that are still on 3.18.  It seems to
me that archs still on 3.18 are basically unloved cruft that perhaps
should be cleaned out rather than kept in tree.

Regards,

Daniel



From danutbug at gmail.com  Tue Jun  7 03:11:14 2016
From: danutbug at gmail.com (Dan Bugnar)
Date: Tue,  7 Jun 2016 13:11:14 +0300
Subject: [LEDE-DEV] [ubox] remove unnecessary size struct between messages
Message-ID: <1465294276-15925-1-git-send-email-danutbug@gmail.com>

From: Dan Bugnar <dnbugnar at ocedo.com>

The next message needs to be written after the data of current message.
This was adding "sizeof(struct log_head)" bytes between messages.

Signed-off-by: Dan Bugnar <danutbug at gmail.com>
---
 log/syslog.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/log/syslog.c b/log/syslog.c
index e8b6774..2042e93 100644
--- a/log/syslog.c
+++ b/log/syslog.c
@@ -51,7 +51,7 @@ static regex_t pat_tstamp;
 static struct log_head*
 log_next(struct log_head *h, int size)
 {
-	struct log_head *n = (struct log_head *) &h->data[PAD(sizeof(struct log_head) + size)];
+	struct log_head *n = (struct log_head *) &h->data[size];
 
 	return (n >= log_end) ? (log) : (n);
 }
-- 
2.8.1



From danutbug at gmail.com  Tue Jun  7 03:11:16 2016
From: danutbug at gmail.com (Dan Bugnar)
Date: Tue,  7 Jun 2016 13:11:16 +0300
Subject: [LEDE-DEV] [ubox] logd: add ubus reload method
In-Reply-To: <1465294276-15925-1-git-send-email-danutbug@gmail.com>
References: <1465294276-15925-1-git-send-email-danutbug@gmail.com>
Message-ID: <1465294276-15925-3-git-send-email-danutbug@gmail.com>

Add ubus method to set the buffer size.
Example:
	ubus call log reload "{\"log_buffer_size\":size}"

Signed-off-by: Dan Bugnar <danutbug at gmail.com>
---
 log/logd.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

diff --git a/log/logd.c b/log/logd.c
index 27d3cac..563c545 100644
--- a/log/logd.c
+++ b/log/logd.c
@@ -26,11 +26,16 @@
 
 #include "syslog.h"
 
+#define LOG_DEFAULT_SIZE 16 * 1024
+
 int debug = 0;
 static struct blob_buf b;
 static struct ubus_auto_conn conn;
 static LIST_HEAD(clients);
 
+static const struct blobmsg_policy reload_policy =
+	{ .name = "log_buffer_size", .type = BLOBMSG_TYPE_INT32 };
+
 static const struct blobmsg_policy read_policy =
 	{ .name = "lines", .type = BLOBMSG_TYPE_INT32 };
 
@@ -124,9 +129,29 @@ write_log(struct ubus_context *ctx, struct ubus_object *obj,
 	return 0;
 }
 
+static int
+reload_log(struct ubus_context *ctx, struct ubus_object *obj,
+		struct ubus_request_data *req, const char *method,
+		struct blob_attr *msg)
+{
+	struct blob_attr *tb;
+	int size = 0;
+
+	if (msg) {
+		blobmsg_parse(&reload_policy, 1, &tb, blob_data(msg), blob_len(msg));
+		if (tb) {
+			size = blobmsg_get_u32(tb);
+			log_buffer_reinit(size < 1 ? LOG_DEFAULT_SIZE : size * 1024);
+		}
+	}
+
+	return 0;
+}
+
 static const struct ubus_method log_methods[] = {
 	{ .name = "read", .handler = read_log, .policy = &read_policy, .n_policy = 1 },
 	{ .name = "write", .handler = write_log, .policy = &write_policy, .n_policy = 1 },
+	{ .name = "reload", .handler = reload_log, .policy = &reload_policy, .n_policy = 1 },
 };
 
 static struct ubus_object_type log_object_type =
-- 
2.8.1



From danutbug at gmail.com  Tue Jun  7 03:11:15 2016
From: danutbug at gmail.com (Dan Bugnar)
Date: Tue,  7 Jun 2016 13:11:15 +0300
Subject: [LEDE-DEV] [ubox] syslog: change log buffer size
In-Reply-To: <1465294276-15925-1-git-send-email-danutbug@gmail.com>
References: <1465294276-15925-1-git-send-email-danutbug@gmail.com>
Message-ID: <1465294276-15925-2-git-send-email-danutbug@gmail.com>

Change the log buffer size and copy the messages.
Copy the messages from the oldest to newest using the log_list.
First time we calculate the size of the all entries. The log_entries_size
calculates the size indifferent of the positions of the newest and oldest.

If we want to increase the log buffer size is simple, we just copy from the oldest
message to the newest all the messages into the new buffer.

In case we shrink the buffer we go over messages and decrease the entries size
with the size of each message until the entries size is less or equal to the new
size we allocate the new buffer.

Signed-off-by: Dan Bugnar <danutbug at gmail.com>
---
 log/syslog.c | 41 +++++++++++++++++++++++++++++++----------
 log/syslog.h |  2 +-
 2 files changed, 32 insertions(+), 11 deletions(-)

diff --git a/log/syslog.c b/log/syslog.c
index 2042e93..0183d4e 100644
--- a/log/syslog.c
+++ b/log/syslog.c
@@ -42,7 +42,7 @@
 #define PAD(x) (x % 4) ? (((x) - (x % 4)) + 4) : (x)
 
 static char *log_dev = LOG_DEFAULT_SOCKET;
-static int log_size = LOG_DEFAULT_SIZE;
+static int log_size;
 static struct log_head *log, *log_end, *oldest, *newest;
 static int current_id = 0;
 static regex_t pat_prio;
@@ -93,6 +93,7 @@ log_add(char *buf, int size, int source)
 	}
 #endif
 
+	size = PAD(size);
 	/* strip syslog timestamp */
 	if ((source == SOURCE_SYSLOG) && (size > SYSLOG_PADDING) && (buf[SYSLOG_PADDING - 1] == ' ')) {
 		size -= SYSLOG_PADDING;
@@ -213,6 +214,15 @@ syslog_open(void)
 	return 0;
 }
 
+static inline int 
+log_entries_size(void)
+{
+	if (newest > oldest)
+		return (newest - oldest);
+	else
+		return (log_end - oldest + newest - log);
+}
+
 struct log_head*
 log_list(int count, struct log_head *h)
 {
@@ -237,26 +247,40 @@ log_list(int count, struct log_head *h)
 }
 
 int
-log_buffer_init(int size)
+log_buffer_reinit(int size)
 {
-	struct log_head *_log = malloc(size);
+	struct log_head *_log;
+
+	if (size <= 0)
+		size = LOG_DEFAULT_SIZE;
+	if (log_size == size)
+		return 0;
+
+	_log = malloc(size);
 
 	if (!_log) {
+		oldest = newest = log = NULL;
 		fprintf(stderr, "Failed to initialize log buffer with size %d\n", log_size);
 		return -1;
 	}
 
 	memset(_log, 0, size);
 
-	if (log && ((log_size + sizeof(struct log_head)) < size)) {
+	if (log) {
 		struct log_head *start = _log;
 		struct log_head *end = ((void*) _log) + size;
 		struct log_head *l;
+		int entries_size = log_entries_size();
 
 		l = log_list(0, NULL);
 		while ((start < end) && l && l->size) {
-			memcpy(start, l, PAD(sizeof(struct log_head) + l->size));
-			start = (struct log_head *) &l->data[PAD(l->size)];
+			int copy_len = sizeof(struct log_head) + l->size;
+			if (entries_size < size) {
+				memcpy(start, l, copy_len);
+				start = (struct log_head *) &start->data[l->size];
+			} else{
+				entries_size -= copy_len;
+			}
 			l = log_list(0, l);
 		}
 		free(log);
@@ -276,13 +300,10 @@ log_buffer_init(int size)
 void
 log_init(int _log_size)
 {
-	if (_log_size > 0)
-		log_size = _log_size;
-
 	regcomp(&pat_prio, "^<([0-9]*)>(.*)", REG_EXTENDED);
 	regcomp(&pat_tstamp, "^\[[ 0]*([0-9]*).([0-9]*)] (.*)", REG_EXTENDED);
 
-	if (log_buffer_init(log_size)) {
+	if (log_buffer_reinit(_log_size)) {
 		fprintf(stderr, "Failed to allocate log memory\n");
 		exit(-1);
 	}
diff --git a/log/syslog.h b/log/syslog.h
index 81a039f..ed5a41b 100644
--- a/log/syslog.h
+++ b/log/syslog.h
@@ -35,7 +35,7 @@ void log_shutdown(void);
 
 typedef void (*log_list_cb)(struct log_head *h);
 struct log_head* log_list(int count, struct log_head *h);
-int log_buffer_init(int size);
+int log_buffer_reinit(int size);
 void log_add(char *buf, int size, int source);
 void ubus_notify_log(struct log_head *l);
 
-- 
2.8.1



From john at phrozen.org  Tue Jun  7 03:13:51 2016
From: john at phrozen.org (John Crispin)
Date: Tue, 7 Jun 2016 12:13:51 +0200
Subject: [LEDE-DEV] ACL kernel config options and 3.18
In-Reply-To: <1465290136.3094.24.camel@homehost>
References: <1465290136.3094.24.camel@homehost>
Message-ID: <6c322fec-3f96-904d-e207-7d28239372c1@phrozen.org>



On 07/06/2016 11:02, Daniel Curran-Dickinson wrote:
> iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAABlBMVEX///8AAABVwtN+AAAAeklEQVQY04XQzQ2EIBAF4IdMDIc5UAIlUIKlWMr0ZiMm28jOj+6iMXEOfBBmXgJAVLGlBkU3wcZ9I3Q7EdrAveowx6hZ0q6QJDsRnHlJwr+W4CHF7vLqTEenXABeUnSssbP8SdwdjTHEwcFDtQGKFuWjH8Lna8vAmfEF3NMPdAOsBscAAAAASUVORK5CYII=
> Content-Type: text/plain; charset="UTF-8"
> X-Mailer: Evolution 3.10.4-0ubuntu2 
> Mime-Version: 1.0
> Content-Transfer-Encoding: 7bit
> 
> Hi John,
> 
> I don't have a platform that is currently using 3.18, and on ar71xx I
> can't even get 3.18 to get a proper kernel config never mind build, so
> can we simply turn off the ACL config options for 3.18 and omit worrying
> about getting the patch verified for that kernel version?
> 
> TBH I'm not sure there are any platforms anyone is actually using or
> developing for on a regular basis that are still on 3.18.  It seems to
> me that archs still on 3.18 are basically unloved cruft that perhaps
> should be cleaned out rather than kept in tree.
> 
> Regards,
> 
> Daniel

Hi,

a V4.4 only series should be fine. we are moving all kernels to v4/4
anyhow. please compile etst it on a 3.18 and 4.1 target nonetheless please

	John


From koen.vandeputte at ncentric.com  Tue Jun  7 04:02:45 2016
From: koen.vandeputte at ncentric.com (Koen Vandeputte)
Date: Tue, 7 Jun 2016 13:02:45 +0200
Subject: [LEDE-DEV] Bug in ath9k coverage distance
Message-ID: <5756A9D5.4030504@ncentric.com>

Hi all,

Chaoscalmer has a lot less wifi bandwidth when coverage class is increased.
Even when 2 devices are only a few meters apart.

In Barrierbreaker release, the rates were a lot higher in this usecase.

When doing Iperf benchmarks (~ 30 sec);

  * The barrierbreaker 14.07 release is able to hit ~53Mbit from start
    to finish
  * Chaoscalmer starts at ~6Mbit/s, than slowly goes up to ~20Mbit/s.
    But starts at 6 again when the test is repeated


Hardware used for testing:

2x Gateworks Laguna CNS3xxx    + AR9280 (Ubnt sr71-15)
2x Gateworks Ventana IMX-6        + AR9300 (WLE350NX)


Branch tested:

5770678122e76079debd6eeeb118f32e3fc78b84 (Master @ June 1st 2016)


Following setup:

  * 2 identical devices
  * IBSS mode using wpa_supplicant WPA2
  * 2 meter apart
  * Free 5GHz channel (confirmed using spectrum analyzer)
  * HT20 (HT40 has same behaviour)


  * Coverage class 32 (up to 14400m)

Iperf using BarrierBreaker build: ~52Mbit/s
Iperf using ChaosCalmer build: ~6Mbit/s


  * Coverage class 16 (up to 7200m)

Iperf using BarrierBreaker build: ~53Mbit/s
Iperf using ChaosCalmer build: ~12Mbit/s


  * Dynack

Iperf using BarrierBreaker build: ~55Mbit/s
Iperf using ChaosCalmer build: ~53Mbit/s


Steps taken without success:

  * Upgraded wpa_supplicant to latest trunk
  * Checked ath9k code hw.c & recv.c (Acktime, slottime, etc. But code 
doesn't differ between BB release and Master branch)
  * Disabled any possible background scanning
  * Patches deleted - In delta to BB release: (in kernel/mac80211/patches)

--> 326-ath9k-make-NF-load-complete-quickly-and-reliably.patch
--> 330-mac80211-minstrel-Change-expected-throughput-unit-ba.patch
--> 334-mac80211-fix-wiphy-supported_band-access.patch
--> 335-mac80211-minstrel_ht-set-A-MSDU-tx-limits-based-on-s.patch
--> 336-mac80211-minstrel_ht-set-default-tx-aggregation-time.patch
--> 337-mac80211-minstrel_ht-fix-a-logic-error-in-RTS-CTS-ha.patch
--> 343-mac80211-minstrel_ht-improve-sample-rate-skip-logic.patch


Not yet checked:

  * Minstrel_ht


If more information is required, please let me know.

Thanks,

Koen Vandeputte
nCentric Europe


From dheeranmech at gmail.com  Tue Jun  7 04:27:48 2016
From: dheeranmech at gmail.com (Dheeran Senthilvel)
Date: Tue, 7 Jun 2016 16:57:48 +0530
Subject: [LEDE-DEV] WRT1900ACS - Kernel 4.4.12 boot failure
In-Reply-To: <20160607102408.GB29607@pratt.mine.nu>
References: <0A593775-05EB-45BC-A3C3-07AAECE5B748@gmail.com>
 <E92BB9D3-BF9D-411A-825C-ED82CAE36E98@gmail.com>
 <97C7E072-BA76-4B93-BF6A-EE2B9C5B4C3B@gmail.com>
 <EEA4CAC8-265C-471F-A0EB-7654DC094895@gmail.com>
 <9BD7CD08-6799-4FF0-B8FA-380AFF42B5AA@gmail.com>
 <64E9BFC2-B9F1-4AAE-B799-0435B3091E41@gmail.com>
 <A5192BCC-101B-487A-913B-B3DA7A88C5DB@gmail.com>
 <F013F569-4F7F-4903-9F8E-F29FA6599A8F@gmail.com>
 <20160607095751.GA29607@pratt.mine.nu>
 <CAJe1gWKTkiEGh+j6ay_13+MuRGTvLEFAynB1dUiBJCc+r9ch1A@mail.gmail.com>
 <20160607102408.GB29607@pratt.mine.nu>
Message-ID: <F1CDD9DC-2F03-412F-81DC-4C3318E489C9@gmail.com>

Hi,
	Yes even after I run resetenv followed by a reset command, the fw_printenv produces the same output every time. 

> On 07-Jun-2016, at 3:54 PM, Claudio Leite <leitec at gmail.com> wrote:
> 
> Hi,
> 
> * Dheeran Senthilvel (dheeranmech at gmail.com) wrote:
>> Hi,
>>       Thanks for the reply. But I already documented it in my previous
>> mails in May 2016.
>> This is temporary, once again when reboot is done the same error occurs.
> 
> I see, sorry for the noise.
> 
>> 
>>       I haven't been able to solve this issue. Also if altnandboot is
>> performed and used having lede in nandboot there seems to be no problem.
>> But once lede boots the error is imminent upon reboot.
> 
> I'm not sure I understand this part. Is the same image, with no custom
> settings, stored in both partitions?
Sorry for that! What I mean to say is if I boot ?altnandboot? (recovery official firmware) having lede in the primary_image partition, the problem doesn?t occur. Once I invoke nandboot and allow lede to boot and issue a reboot command, the error occurs. I gave this statement to clarify that the problem lede and not the 'hardware' or 'u-boot?.
> 
> What does fw_printenv look like after a "resetenv; reset" and boot into
> a recent LEDE? At that point, the linksys-recovery stuff will already
> have run.
But I really don?t understand the problem. This OpenWrt WiKi page - https://wiki.openwrt.org/doc/techref/bootloader/uboot.config , shows that this kind of error show only when the partition map is incorrect (That is what i understood) and as the following command shows that flash mapping recognised by lede is incorrect

root at WRT1900ACS:/# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00200000 00020000 "u-boot"
mtd1: 00040000 00020000 "u_env"
mtd2: 00040000 00020000 "s_env"
mtd3: 00100000 00020000 "devinfo"
mtd4: 02800000 00020000 "kernel1"
mtd5: 02200000 00020000 "ubi"
mtd6: 02800000 00020000 "kernel2"
mtd7: 02200000 00020000 "rootfs2"
mtd8: 02600000 00020000 "syscfg"
mtd9: 00680000 00020000 ?unused_area"

whereas boot to altnandboot gives something like this

armada-nand f10d0000.nand: Initialize HAL based NFC in 8bit mode with DMA Disabled using BCH 4bit ECC
NAND device: Manufacturer ID: 0x01, Chip ID: 0xf1 (AMD/Spansion NAND 128MiB 3,3V 8-bit), 128MiB, page size: 2048, OOB size: 64
Bad block table found at page 65472, version 0x01
Bad block table found at page 65408, version 0x01
10 cmdlinepart partitions found on MTD device armada-nand
Creating 10 MTD partitions on "armada-nand":
0x000000000000-0x000000200000 : "uboot"
0x000000200000-0x000000240000 : "u_env"
0x000000240000-0x000000280000 : "s_env"
0x000000900000-0x000000a00000 : "devinfo"
0x000000a00000-0x000003200000 : "kernel"
0x000001000000-0x000003200000 : "rootfs"
0x000003200000-0x000005a00000 : "alt_kernel"
0x000003800000-0x000005a00000 : "alt_rootfs"
0x000000a00000-0x000005a00000 : "ubifs"
0x000005a00000-0x000008000000 : "syscfg"


> 
> -Claudio
> 
>> On 07-Jun-2016 3:27 pm, "Claudio Leite" <leitec at gmail.com> wrote:
>> 
>>> * Dheeran Senthilvel (dheeranmech at gmail.com) wrote:
>>>> Hi,
>>>>      Compiled build r504 followed by clean build. Still not clear what
>>> is causing the boot error mentioned previously in mailing list - May 2016.
>>> [snip]
>>>> 
>>>> auto_recovery_check changes bootcmd: run nandboot
>>>> Hit any key to stop autoboot:  0
>>>> ## Error: "nandboot" not defined
>>> 
>>> Have you tried the 'resetenv' command from u-boot?
>>> 
>>> resetenv- resetenv      - earse environment sector to reset all
>>> variables to default.
>>> 
>>> I haven't tried this on a WRT1900AC, but on the EA4500 (which has a
>>> somewhat similar u-boot) it correctly resets everything to default
>>> values. Given that your u-boot settings are gone one way or another (as
>>> your fw_printenv later shows) this might be worth a try.
>>> 
>>> -Claudio
>>> 



From Jos.Delbar at technicolor.com  Tue Jun  7 04:50:32 2016
From: Jos.Delbar at technicolor.com (Delbar Jos)
Date: Tue, 7 Jun 2016 11:50:32 +0000
Subject: [LEDE-DEV] [OpenWrt] Meeting on TR-069 Work - Friday,
	June 10 - 7 AM PT
In-Reply-To: <5751F92E.2020503@prplfoundation.org>
References: <5751F92E.2020503@prplfoundation.org>
Message-ID: <SN1PR02MB2048A311A2C286EBB34C79EB915D0@SN1PR02MB2048.namprd02.prod.outlook.com>

Eric, all,

Eric Schultz <eschultz at prplfoundation.org> wrote:
> I'm excited to see so many people interested in TR-069 support! As a follow up
> to the previous TR-069 email,  I've set up a meeting on TR-069 support for
> OpenWrt. The meeting is on Friday, June 10 at 7 AM PT.

We have prepared a short presentation giving a high level overview of Technicolor's proposed TR-069 contribution. It includes an architecture diagram, a description of the main components and a few examples and code snippets. We can add more detail in the Friday meeting and we are happy to review questions up front.

You can grab the PDF at the link below, which will be invalidated in 5 days. Can anyone recommend a more permanent place to store this information?

	Url : https://rdupload.technicolor.com/dl/9f263b37a666282e2368fcbb15e4714f6a7311cc7467cef0
	Login : TCH75e8f8
	Password : 232IT_5G

Regards,
Jos

From yszhou4tech at gmail.com  Tue Jun  7 05:49:59 2016
From: yszhou4tech at gmail.com (Yousong Zhou)
Date: Tue, 7 Jun 2016 20:49:59 +0800
Subject: [LEDE-DEV] libubox, procd: init process hangs
In-Reply-To: <f2dd22dd-8fff-4521-5e3f-cdbf6faa0275@gmail.com>
References: <f2dd22dd-8fff-4521-5e3f-cdbf6faa0275@gmail.com>
Message-ID: <CAECwjAjrVG3M6EtYCtB45SYZNQhRJgC7CETT8u6+aypotF9c+g@mail.gmail.com>

On 7 June 2016 at 06:11, Xinxing Hu <xinxing.huchn at gmail.com> wrote:
> Hi Guys,
>
> I have another idea about this issue. Maybe it is not kernel, but uloop
> related. I read procd and libubox code a little bit, and it seems there is a
> potential issue existing in uloop_run().
>
> In general, uloop_run() is running in a while loop:
>
> while()
>         1, Process timeouts list
>
>         2, Handle terminated child processes
>
>         3, uloop_run_events(timeout) => calls epoll_wait()
> done
>
> During boot, procd_inittab_run("sysinit") is called in Step1, which calls
> add_initd(). add_initd() would add an entry in timeouts list, whose callback
> function is to execute an rc.d/S* script.
>
> When the while loop goes back to Step1 again, the timeouts list would be
> processed, and an rc.d/S* script would be executed in a child process while
> the parent process remains in the while loop. If everything goes fine, when
> the child process is terminated, the parent process will handle terminated
> child process by calling waitpid() in the while loop. A process callback
> function will also be called, which adds another timeout entry in timeouts
> list. This new entry corresponds to the next rc.d/S* script to be executed.
> When the while loop reaches Step1 again, the next rc.d/S* script would be
> invoked.
>
> Everything looks OK till now. However, due to process scheduling, problems
> might happen when uloop_run_events(uloop_get_next_timeout(&tv)) is called.
> For instance: if the child process is still running when
> uloop_get_next_timeout(&tv) is called, then the timeouts list is already
> empty at that time, so the return value of uloop_get_next_timeout(&tv) would
> be -1. Furthermore, if the child process is terminated and signal handler is
> executed before epoll_wait() is called, then epoll_wait will block the
> parent process forever until some other events it is listening to arrive. In
> this sense, other events arriving just hide this issue. During the boot, as
> long as /etc/rc.d/S* is not finished executing, epoll_wait() should never be
> blocked.
>
> I think, a potential solution might be: during initialization, we let uloop
> listens to a kind of 'dummy' event. Every time when the child process
> finishes executing a rc.d/S* script, we send a 'dummy' event. In this case,
> epoll_wait would never be blocked during booting.

Interesting.  Looks like the same issue can also happen to the
uloop_canceled check.  Python's tornado library uses pipe() as a
"waker" to "calls the given callback on the next I/O loop iteration."

Can you give the attached patch a try to see if it can solve the issue
for you?  It was only just run-tested on qemu malta to make sure the
patched libubox still runs.

                yousong

>
> Best Regards,
> Xinxing
>
>
>
>
> On 2016/5/17 18:03, Mats Karrman wrote:
> Hi Felix, others,
>
> I have been experiencing problems with the init scripts dispatch
> suddenly stopping (indefinitely).
> This happens maybe once in 100 reboots.
> After inserting a new start script that launches another daemon
> (cgrulesengd) very early in the boot process, the failures started to
> come a lot more frequently, maybe once in 10 reboots, making this a real
> issue.
> I'm normally using the versions of procd and libubox selected by OpenWRT
> BB branch but I have tested the latest versions from the git repos with
> the same result.
> So far I have only got this to happen on a quite fast board (ARM dual
> CorexA9 @ 1GHz).
> Inserting trace prints in libubox changes behavior, also suggesting the
> problem is timing dependent.
>
> When init hangs:
> - it is still possible to log in on console
> - there is always a zombie start script, e.g. S11sysctl.
> - by killing a process (e.g. ubusd or cgrulesengd) the init process
> continues.
> - otherwise generating an event, e.g inserting something into a USB port
> also makes the init continue.
>
> I have traced the problem down to the "epoll_wait" call in
> libubox::uloop.c::uloop_fetch_events().
> The following patch makes sure epoll_wait is never called without a timeout.
> My tests show that this solves the problem.
> I have been able to observe the case when the boot gets stuck and then
> continues after the 8s timeout.
> However I'm not sure that this is the correct fix for the problem as
> there may be other reasons that there is no event in the first place.
> Your feedback would be welcome!
>
> BR // Mats
> Currently working for Inteno Broadband Technology AB
>
> ---
> Avast ??????????????????
> https://www.avast.com/antivirus
>
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-uloop-use-a-waker-for-notifying-sigchld-and-loop-can.patch
Type: application/octet-stream
Size: 3299 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20160607/83ff4b75/attachment.obj>

From leitec at gmail.com  Tue Jun  7 06:33:06 2016
From: leitec at gmail.com (Claudio Leite)
Date: Tue, 7 Jun 2016 09:33:06 -0400
Subject: [LEDE-DEV] WRT1900ACS - Kernel 4.4.12 boot failure
In-Reply-To: <F1CDD9DC-2F03-412F-81DC-4C3318E489C9@gmail.com>
References: <97C7E072-BA76-4B93-BF6A-EE2B9C5B4C3B@gmail.com>
 <EEA4CAC8-265C-471F-A0EB-7654DC094895@gmail.com>
 <9BD7CD08-6799-4FF0-B8FA-380AFF42B5AA@gmail.com>
 <64E9BFC2-B9F1-4AAE-B799-0435B3091E41@gmail.com>
 <A5192BCC-101B-487A-913B-B3DA7A88C5DB@gmail.com>
 <F013F569-4F7F-4903-9F8E-F29FA6599A8F@gmail.com>
 <20160607095751.GA29607@pratt.mine.nu>
 <CAJe1gWKTkiEGh+j6ay_13+MuRGTvLEFAynB1dUiBJCc+r9ch1A@mail.gmail.com>
 <20160607102408.GB29607@pratt.mine.nu>
 <F1CDD9DC-2F03-412F-81DC-4C3318E489C9@gmail.com>
Message-ID: <20160607133306.GC29607@pratt.mine.nu>

Hello Dheeran,

* Dheeran Senthilvel (dheeranmech at gmail.com) wrote:
> Hi,
> 	Yes even after I run resetenv followed by a reset command, the fw_printenv produces the same output every time. 
> 
> > On 07-Jun-2016, at 3:54 PM, Claudio Leite <leitec at gmail.com> wrote:
> > 
> > Hi,
> > 
> > * Dheeran Senthilvel (dheeranmech at gmail.com) wrote:
> >> Hi,
> >>       Thanks for the reply. But I already documented it in my previous
> >> mails in May 2016.
> >> This is temporary, once again when reboot is done the same error occurs.
> > 
> > I see, sorry for the noise.
> > 
> >> 
> >>       I haven't been able to solve this issue. Also if altnandboot is
> >> performed and used having lede in nandboot there seems to be no problem.
> >> But once lede boots the error is imminent upon reboot.
> > 
> > I'm not sure I understand this part. Is the same image, with no custom
> > settings, stored in both partitions?
> Sorry for that! What I mean to say is if I boot ?altnandboot? (recovery official firmware) having lede in the primary_image partition, the problem doesn?t occur. Once I invoke nandboot and allow lede to boot and issue a reboot command, the error occurs. I gave this statement to clarify that the problem lede and not the 'hardware' or 'u-boot?.

OK, I understand now-you have the factory firmware on the secondary
partition.

> > 
> > What does fw_printenv look like after a "resetenv; reset" and boot into
> > a recent LEDE? At that point, the linksys-recovery stuff will already
> > have run.
> But I really don?t understand the problem. This OpenWrt WiKi page - https://wiki.openwrt.org/doc/techref/bootloader/uboot.config , shows that this kind of error show only when the partition map is incorrect (That is what i understood) and as the following command shows that flash mapping recognised by lede is incorrect

It's not incorrect; it's just how LEDE/OpenWrt defines it. The partition
map is baked into the kernel image via the dtb. The relevant partition
is mtd1, u_env (and s_env, for the 'resetbc' stuff) which is correctly
defined and matches up with the bootloader's (and factory firmware's)
expectations.

From your own output:

lede:

[    0.973995] 0x000000000000-0x000000200000 : "u-boot"
[    0.979273] 0x000000200000-0x000000240000 : "u_env"
[    0.984435] 0x000000240000-0x000000280000 : "s_env"

factory:

0x000000000000-0x000000200000 : "uboot"
0x000000200000-0x000000240000 : "u_env"
0x000000240000-0x000000280000 : "s_env"

Given the output you posted from fw_printenv earlier,

root at WRT1900ACS:/# fw_printenv
bootcmd=bootp; setenv bootargs root=/dev/nfs
nfsroot=${serverip}:${rootpath}
ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm
bootdelay=5
baudrate=115200
auto_recovery=yes 

there's some very strange corruption going on. It would probably help to
determine if this is happening during the auto_recovery/resetbc stuff
during boot, when it writes to u-env. If there's something off still
with the NAND driver this could cause the corruption you see.

Could you try this:

1. reboot and run "resetenv; reset"
2. boot into LEDE, but drop into failsafe mode (when prompted, type
f<enter>)

3. from failsafe mode, run
	strings /dev/mtd1

this should be the complete and long set of default variables.

4. still from failsafe, run 'reboot'

During this time nothing new is written to u-env, so upon a reboot it
should still be functional. The 'printenv' command from u-boot should
list the variables intact, and it should boot normally.

Once booted into LEDE normally, if the fw_setenv command during the boot
sequence is causing the corruption, fw_printenv or "strings /dev/mtd1"
will now show some sort of corrupted output.

-Claudio


From dheeranmech at gmail.com  Tue Jun  7 07:00:35 2016
From: dheeranmech at gmail.com (Dheeran Senthilvel)
Date: Tue, 7 Jun 2016 19:30:35 +0530
Subject: [LEDE-DEV] WRT1900ACS - Kernel 4.4.12 boot failure
In-Reply-To: <20160607133306.GC29607@pratt.mine.nu>
References: <97C7E072-BA76-4B93-BF6A-EE2B9C5B4C3B@gmail.com>
 <EEA4CAC8-265C-471F-A0EB-7654DC094895@gmail.com>
 <9BD7CD08-6799-4FF0-B8FA-380AFF42B5AA@gmail.com>
 <64E9BFC2-B9F1-4AAE-B799-0435B3091E41@gmail.com>
 <A5192BCC-101B-487A-913B-B3DA7A88C5DB@gmail.com>
 <F013F569-4F7F-4903-9F8E-F29FA6599A8F@gmail.com>
 <20160607095751.GA29607@pratt.mine.nu>
 <CAJe1gWKTkiEGh+j6ay_13+MuRGTvLEFAynB1dUiBJCc+r9ch1A@mail.gmail.com>
 <20160607102408.GB29607@pratt.mine.nu>
 <F1CDD9DC-2F03-412F-81DC-4C3318E489C9@gmail.com>
 <20160607133306.GC29607@pratt.mine.nu>
Message-ID: <6374F1F4-5A5F-4576-B43C-C65991C6E920@gmail.com>

=======> Step 1: Reboot <=======

BusyBox v1.24.2 () built-in shell (ash)

     _________
    /        /\      _    ___ ___  ___
   /  LE    /  \    | |  | __|   \| __|
  /    DE  /    \   | |__| _|| |) | _|
 /________/  LE  \  |____|___|___/|___|                      lede-project.org
 \        \   DE /
  \    LE  \    /  -----------------------------------------------------------
   \  DE    \  /    Reboot (HEAD, r504)
    \________\/    -----------------------------------------------------------

root at WRT1900ACS:/# reboot





=======> Step 2: resetenv & reset <=======
 __   __                      _ _
|  \/  | __ _ _ ____   _____| | |
| |\/| |/ _` | '__\ \ / / _ \ | |
| |  | | (_| | |   \ V /  __/ | |
|_|  |_|\__,_|_|    \_/ \___|_|_|
         _   _     ____              _
        | | | |   | __ )  ___   ___ | |_
        | | | |___|  _ \ / _ \ / _ \| __|
        | |_| |___| |_) | (_) | (_) | |_
         \___/    |____/ \___/ \___/ \__|
 ** LOADER **


U-Boot 2013.01 (Mar 27 2015 - 16:50:46) Marvell version: 2014_T3.0p6

Boot version : v1.0.13

Board: RD-NAS-88F6820-DDR3
SoC:   MV88F6820 Rev A0
       running 2 CPUs
CPU:   ARM Cortex A9 MPCore (Rev 1) LE
       CPU 0
       CPU    @ 1600 [MHz]
       L2     @ 800 [MHz]
       TClock @ 200 [MHz]
       DDR    @ 800 [MHz]
       DDR 32 Bit Width, FastPath Memory Access, DLB Enabled, ECC Disabled
DRAM:  512 MiB

Map:   Code:                    0x1fea9000:0x1ff7632c
       BSS:                     0x1ffef6b4
       Stack:                   0x1f9a8f20
       Heap:                    0x1f9a9000:0x1fea9000
raise: Signal # 8 caught
U-ENV offset == 0x200000
raise: Signal # 8 caught
U-ENV offset == 0x200000
       U-Boot Environment:      0x00200000:0x00220000 (NAND)

NAND:  128 MiB
MMC:   mv_sdh: 0
DEVINFO offset == 0x900000
U-ENV offset == 0x200000
U-ENV offset == 0x200000
S-ENV offset == 0x240000


#### auto_recovery ####
[u_env] get auto_recovery == yes
[u_env] get auto_recovery == yes
[u_env] get boot_part == <NULL>
set boot_part=1 as default value at u_env
[u_env] get boot_part_ready == <NULL>
set boot_part_ready=3 as default value at u_env
auto_recovery enabled:1, boot_part:1, boot_part_ready:3

S-ENV offset == 0x240000
[boot_count_read] block:0x240000, size:128KB, records:64
[boot_count_read_record] boot_count:0, next_record:18

[boot_count_write] erase:0, auto_recovery->block_offset:0x240000 offset=0x249000

Updating boot_count ...
[boot_count_write] offset:0x249000 , length:2048
done

PCI-e 0 (IF 0 - bus 0) Root Complex Interface, Detected Link X1, GEN 2.0
PCI-e 1 (IF 1 - bus 1) Root Complex Interface, Detected Link X1, GEN 1.1
USB2.0 0: Host Mode
USB3.0 1: Host Mode
USB3.0 0: Host Mode
Board configuration detected:
mvEthE6171SwitchBasicInit init
Net:
|  port  | Interface | PHY address  |
|--------|-----------|--------------|
| egiga0 |   RGMII   |     0x01     |
| egiga1 |   SGMII   |     0x00     |
egiga0 [PRIME], egiga1
auto_recovery_check changes bootcmd: run nandboot
Hit any key to stop autoboot:  0
## Error: "nandboot" not defined
Marvell>> resetenv
Erasing 0x200000 - 0x240000:[Done]
Warning: Default Environment Variables will take effect Only after RESET
Marvell>>reset





=======> Step 3: Intrupt boot into failsafe <=======

Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
f
- failsafe -
[    4.986830] random: dropbearkey urandom read with 121 bits of entropy available
Generating key, this may take a while...
Public key portion is:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDrNbAtbpvkCbOb93M8CIhkOklAmgzdXTLykIIDBiy6aGZB2LCVU9DCM09CyKJUOYWF2Pvk5i5THb3+TwM3ILr+iWraogyZzrTsAus1byAtJS0jEH0bHEzbv/hU
fd0XSVpypP8q+1R2UpGtzZm7vIy2V6dD5LCaABnTD6mNRKSXRQ++ root@(none)
Fingerprint: md5 ec:58:8a:60:48:32:94:26:30:0c:6d:e2:dd:10:5e:6e


BusyBox v1.24.2 () built-in shell (ash)

ash: can't access tty; job control turned off
     _________
    /        /\      _    ___ ___  ___
   /  LE    /  \    | |  | __|   \| __|
  /    DE  /    \   | |__| _|| |) | _|
 /________/  LE  \  |____|___|___/|___|                      lede-project.org
 \        \   DE /
  \    LE  \    /  -----------------------------------------------------------
   \  DE    \  /    Reboot (HEAD, r504)
    \________\/    -----------------------------------------------------------

================= FAILSAFE MODE active ================
special commands:
* firstboot          reset settings to factory defaults
* mount_root     mount root-partition with config files

after mount_root:
* passwd                         change root's password
* /etc/config               directory with config files

for more help see:
http://wiki.openwrt.org/doc/howto/generic.failsafe
=======================================================

root@(none):/# strings /dev/mtd1
[   44.008437] random: nonblocking pool is initialized
root@(none):/# reboot
reboot
root@(none):/# [  113.204287] reboot: Restarting system





=======> Step 4: Reboot <=======

BootROM - 1.73
Booting from NAND flash

General initialization - Version: 1.0.0
Detected Device ID 6820
High speed PHY - Version: 2.0

Init RD NAS topology Serdes Lane 3 is USB3
Serdes Lane 4 is SGMII
board SerDes lanes topology details:
 | Lane #  | Speed |  Type       |
 --------------------------------
 |   0    |  06   |  SATA0      |
 |   1    |  05   |  PCIe0      |
 |   2    |  06   |  SATA1      |
 |   3    |  05   |  USB3 HOST1 |
 |   4    |  05   |  PCIe1      |
 |   5    |  00   |  SGMII2     |
 --------------------------------
:** Link is Gen1, check the EP capability
PCIe, Idx 0: Link upgraded to Gen2 based on client cpabilities
:** Link is Gen1, check the EP capability
PCIe, Idx 1: remains Gen1
High speed PHY - Ended Successfully
DDR3 Training Sequence - Ver TIP-1.26.0
mvSysEnvGetTopologyUpdateInfo: TWSI Read failed
DDR3 Training Sequence - Switching XBAR Window to FastPath Window
DDR3 Training Sequence - Ended Successfully
Not detected suspend to RAM indication
BootROM: Image checksum verification PASSED

 __   __                      _ _
|  \/  | __ _ _ ____   _____| | |
| |\/| |/ _` | '__\ \ / / _ \ | |
| |  | | (_| | |   \ V /  __/ | |
|_|  |_|\__,_|_|    \_/ \___|_|_|
         _   _     ____              _
        | | | |   | __ )  ___   ___ | |_
        | | | |___|  _ \ / _ \ / _ \| __|
        | |_| |___| |_) | (_) | (_) | |_
         \___/    |____/ \___/ \___/ \__|
 ** LOADER **


U-Boot 2013.01 (Mar 27 2015 - 16:50:46) Marvell version: 2014_T3.0p6

Boot version : v1.0.13

Board: RD-NAS-88F6820-DDR3
SoC:   MV88F6820 Rev A0
       running 2 CPUs
CPU:   ARM Cortex A9 MPCore (Rev 1) LE
       CPU 0
       CPU    @ 1600 [MHz]
       L2     @ 800 [MHz]
       TClock @ 200 [MHz]
       DDR    @ 800 [MHz]
       DDR 32 Bit Width, FastPath Memory Access, DLB Enabled, ECC Disabled
DRAM:  512 MiB

Map:   Code:                    0x1fea9000:0x1ff7632c
       BSS:                     0x1ffef6b4
       Stack:                   0x1f9a8f20
       Heap:                    0x1f9a9000:0x1fea9000
raise: Signal # 8 caught
U-ENV offset == 0x200000
raise: Signal # 8 caught
U-ENV offset == 0x200000
       U-Boot Environment:      0x00200000:0x00220000 (NAND)

NAND:  128 MiB
MMC:   mv_sdh: 0
DEVINFO offset == 0x900000
U-ENV offset == 0x200000
U-ENV offset == 0x200000
*** Warning - bad CRC, using default environment

S-ENV offset == 0x240000


#### auto_recovery ####
[u_env] get auto_recovery == yes
[u_env] get auto_recovery == yes
[u_env] get boot_part == 1
[u_env] get boot_part_ready == 3
auto_recovery enabled:1, boot_part:1, boot_part_ready:3

S-ENV offset == 0x240000
[boot_count_read] block:0x240000, size:128KB, records:64
[boot_count_read_record] boot_count:2, next_record:20

[boot_count_write] erase:0, auto_recovery->block_offset:0x240000 offset=0x24A000

Updating boot_count ...
[boot_count_write] offset:0x24A000 , length:2048
done

PCI-e 0 (IF 0 - bus 0) Root Complex Interface, Detected Link X1, GEN 2.0
PCI-e 1 (IF 1 - bus 1) Root Complex Interface, Detected Link X1, GEN 1.1
USB2.0 0: Host Mode
USB3.0 1: Host Mode
USB3.0 0: Host Mode
Board configuration detected:
mvEthE6171SwitchBasicInit init
Net:
|  port  | Interface | PHY address  |
|--------|-----------|--------------|
| egiga0 |   RGMII   |     0x01     |
| egiga1 |   SGMII   |     0x00     |
egiga0 [PRIME], egiga1
auto_recovery_check changes bootcmd: run nandboot
Hit any key to stop autoboot:  0
Marvell>> run nandboot

NAND read: device 0 offset 0xa00000, size 0x600000
 6291456 bytes read: OK
## Booting kernel from Legacy Image at 02000000 ...
   Image Name:   ARM LEDE Linux-4.4.12
   Created:      2016-06-05  13:42:27 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2084373 Bytes = 2 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.4.12 (dhees at XPS) (gcc version 5.3.0 (LEDE GCC 5.3.0 r504) ) #1 SMP Sun Jun 5 15:29:33 UTC 2016
[    0.000000] CPU: ARMv7 Processor [414fc091] revision 1 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine model: Linksys WRT1900ACS
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] PERCPU: Embedded 12 pages/cpu @dfbcf000 s17984 r8192 d22976 u49152
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 130048
[    0.000000] Kernel command line: console=ttyS0,115200 root=/dev/mtdblock5 ro rootdelay=1 rootfstype=jffs2 earlyprintk mtdparts=armada-nand:2048K(uboot)ro,256
K(u_env),256K(s_env),1m at 9m(devinfo),40m at 10m(kernel),34m at 16m(rootfs),40m at 50m(alt_kernel),34m at 56m(alt_rootfs),80m at 10m(ubifs),- at 90m(syscfg)
[    0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Memory: 513220K/524288K available (4079K kernel code, 171K rwdata, 1528K rodata, 260K init, 295K bss, 11068K reserved, 0K cma-reserved, 0K highme
m)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
[    0.000000]     vmalloc : 0xe0800000 - 0xff800000   ( 496 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0008000 - 0xc05821d8   (5609 kB)
[    0.000000]       .init : 0xc0583000 - 0xc05c4000   ( 260 kB)
[    0.000000]       .data : 0xc05c4000 - 0xc05eedf4   ( 172 kB)
[    0.000000]        .bss : 0xc05eedf4 - 0xc0638a6c   ( 296 kB)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000]  RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
[    0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] mvebu_mbus: [Firmware Warn]: deprecated mbus-mvebu Device Tree, suspend/resume will not work
[    0.000000] L2C-310 enabling early BRESP for Cortex-A9
[    0.000000] L2C-310 full line of zeros enabled for Cortex-A9
[    0.000000] L2C-310 D prefetch enabled, offset 1 lines
[    0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled
[    0.000000] L2C-310 Coherent cache controller enabled, 16 ways, 1024 kB
[    0.000000] L2C-310 Coherent: CACHE_ID 0x410054c9, AUX_CTRL 0x56070001
[    0.000000] Switching to timer-based delay loop, resolution 40ns
[    0.000003] sched_clock: 32 bits at 25MHz, resolution 40ns, wraps every 85899345900ns
[    0.000009] clocksource: armada_370_xp_clocksource: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 76450417870 ns
[    0.000112] Calibrating delay loop (skipped), value calculated using timer frequency.. 50.00 BogoMIPS (lpj=250000)
[    0.000119] pid_max: default: 32768 minimum: 301
[    0.000154] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000159] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000337] CPU: Testing write buffer coherency: ok
[    0.000434] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.000457] Setting up static identity map for 0x8280 - 0x82d8
[    0.000534] mvebu-soc-id: MVEBU SoC ID=0x6820, Rev=0x4
[    0.000609] mvebu-pmsu: Initializing Power Management Service Unit
[    0.000993] Booting CPU 1
[    0.001152] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[    0.001179] Brought up 2 CPUs
[    0.001185] SMP: Total of 2 processors activated (100.00 BogoMIPS).
[    0.001188] CPU: All CPU(s) started in SVC mode.
[    0.002855] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
[    0.002929] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.002968] pinctrl core: initialized pinctrl subsystem
[    0.003274] NET: Registered protocol family 16
[    0.003766] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.029940] cpuidle: using governor ladder
[    0.032347] mvebu-pmsu: CPU hotplug support is currently broken on Armada 38x: disabling
[    0.032355] mvebu-pmsu: CPU idle is currently broken on Armada 38x: disabling
[    0.060502] reg-fixed-voltage xhci0-vbus: could not find pctldev for node /soc/internal-regs/pinctrl at 18000/xhci0-vbus-pins, deferring probe
[    0.060646] SCSI subsystem initialized
[    0.060888] usbcore: registered new interface driver usbfs
[    0.060912] usbcore: registered new interface driver hub
[    0.060934] usbcore: registered new device driver usb
[    0.061438] clocksource: Switched to clocksource armada_370_xp_clocksource
[    0.061839] NET: Registered protocol family 2
[    0.062050] TCP established hash table entries: 4096 (order: 2, 16384 bytes)
[    0.062075] TCP bind hash table entries: 4096 (order: 3, 32768 bytes)
[    0.062108] TCP: Hash tables configured (established 4096 bind 4096)
[    0.062133] UDP hash table entries: 256 (order: 1, 8192 bytes)
[    0.062145] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
[    0.062208] NET: Registered protocol family 1
[    0.062586] futex hash table entries: 512 (order: 3, 32768 bytes)
[    0.065248] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    0.065258] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc.
[    0.066108] io scheduler noop registered
[    0.066114] io scheduler deadline registered (default)
[    0.066494] armada-38x-pinctrl f1018000.pinctrl: registered pinctrl driver
[    0.066791] irq: Cannot allocate irq_descs @ IRQ44, assuming pre-allocated
[    0.066927] irq: Cannot allocate irq_descs @ IRQ76, assuming pre-allocated
[    0.067212] mvebu-pcie soc:pcie-controller: PCI host bridge to bus 0000:00
[    0.067219] pci_bus 0000:00: root bus resource [io  0x1000-0xfffff]
[    0.067224] pci_bus 0000:00: root bus resource [mem 0xe0000000-0xe7ffffff]
[    0.067229] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.067408] PCI: bus0: Fast back to back transfers disabled
[    0.067414] pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    0.067420] pci 0000:00:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    0.067631] PCI: bus1: Fast back to back transfers disabled
[    0.067879] PCI: bus2: Fast back to back transfers disabled
[    0.067931] pci 0000:00:01.0: BAR 8: assigned [mem 0xe0000000-0xe01fffff]
[    0.067937] pci 0000:00:02.0: BAR 8: assigned [mem 0xe0200000-0xe03fffff]
[    0.067943] pci 0000:01:00.0: BAR 0: assigned [mem 0xe0000000-0xe00fffff 64bit pref]
[    0.067953] pci 0000:01:00.0: BAR 2: assigned [mem 0xe0100000-0xe01fffff 64bit pref]
[    0.067962] pci 0000:00:01.0: PCI bridge to [bus 01]
[    0.067967] pci 0000:00:01.0:   bridge window [mem 0xe0000000-0xe01fffff]
[    0.067974] pci 0000:02:00.0: BAR 0: assigned [mem 0xe0200000-0xe02fffff 64bit pref]
[    0.067985] pci 0000:02:00.0: BAR 2: assigned [mem 0xe0300000-0xe03fffff 64bit pref]
[    0.067994] pci 0000:00:02.0: PCI bridge to [bus 02]
[    0.067999] pci 0000:00:02.0:   bridge window [mem 0xe0200000-0xe03fffff]
[    0.068088] mv_xor f1060800.xor: Marvell shared XOR driver
[    0.101877] mv_xor f1060800.xor: Marvell XOR (Descriptor Mode): ( xor cpy intr )
[    0.101956] mv_xor f1060900.xor: Marvell shared XOR driver
[    0.141858] mv_xor f1060900.xor: Marvell XOR (Descriptor Mode): ( xor cpy intr )
[    0.141991] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[    0.142243] console [ttyS0] disabled
[    0.162310] f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 21, base_baud = 12500000) is a 16550A
[    0.871491] console [ttyS0] enabled
[    0.875319] ahci-mvebu f10a8000.sata: AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl platform mode
[    0.884418] ahci-mvebu f10a8000.sata: flags: 64bit ncq sntf led only pmp fbs pio slum part sxs
[    0.893815] scsi host0: ahci-mvebu
[    0.897377] scsi host1: ahci-mvebu
[    0.900876] ata1: SATA max UDMA/133 mmio [mem 0xf10a8000-0xf10a9fff] port 0x100 irq 41
[    0.908836] ata2: SATA max UDMA/133 mmio [mem 0xf10a8000-0xf10a9fff] port 0x180 irq 41
[    0.917171] pxa3xx-nand f10d0000.flash: This platform can't do DMA on this device
[    0.924987] nand: device found, Manufacturer ID: 0x01, Chip ID: 0xf1
[    0.931366] nand: AMD/Spansion S34ML01G2
[    0.935313] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
[    0.942920] pxa3xx-nand f10d0000.flash: ECC strength 16, ECC step size 2048
[    0.950098] Bad block table found at page 65472, version 0x01
[    0.956210] Bad block table found at page 65408, version 0x01
[    0.962247] 10 ofpart partitions found on MTD device pxa3xx_nand-0
[    0.968452] Creating 10 MTD partitions on "pxa3xx_nand-0":
[    0.973967] 0x000000000000-0x000000200000 : "u-boot"
[    0.979249] 0x000000200000-0x000000240000 : "u_env"
[    0.984428] 0x000000240000-0x000000280000 : "s_env"
[    0.989579] 0x000000900000-0x000000a00000 : "devinfo"
[    0.994916] 0x000000a00000-0x000003200000 : "kernel1"
[    1.000270] 0x000001000000-0x000003200000 : "ubi"
[    1.005295] 0x000003200000-0x000005a00000 : "kernel2"
[    1.010635] 0x000003800000-0x000005a00000 : "rootfs2"
[    1.015979] 0x000005a00000-0x000008000000 : "syscfg"
[    1.021245] 0x000000280000-0x000000900000 : "unused_area"
[    1.027367] libphy: Fixed MDIO Bus: probed
[    1.031591] libphy: orion_mdio_bus: probed
[    1.035842] mvneta_bm f10c8000.bm: Buffer Manager for network controller enabled
[    1.044750] mvneta f1034000.ethernet eth0: Using random mac address 2e:a7:f8:7e:27:4b
[    1.053775] mvneta f1070000.ethernet eth1: Using hardware mac address 00:50:43:45:e1:e5
[    1.061878] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.068434] ehci-pci: EHCI PCI platform driver
[    1.072940] ehci-platform: EHCI generic platform driver
[    1.078273] ehci-orion: EHCI orion driver
[    1.082370] orion-ehci f1058000.usb: EHCI Host Controller
[    1.087802] orion-ehci f1058000.usb: new USB bus registered, assigned bus number 1
[    1.095465] orion-ehci f1058000.usb: irq 36, io mem 0xf1058000
[    1.111441] orion-ehci f1058000.usb: USB 2.0 started, EHCI 1.00
[    1.117615] hub 1-0:1.0: USB hub found
[    1.121391] hub 1-0:1.0: 1 port detected
[    1.125693] usbcore: registered new interface driver usb-storage
[    1.131874] armada38x-rtc f10a3800.rtc: rtc core: registered f10a3800.rtc as rtc0
[    1.139518] i2c /dev entries driver
[    1.154508] orion_wdt: Initial timeout 171 sec
[    1.162326] marvell-cesa f1090000.crypto: CESA device successfully registered
[    1.169978] NET: Registered protocol family 10
[    1.174885] NET: Registered protocol family 17
[    1.179363] bridge: automatic filtering via arp/ip/ip6tables has been deprecated. Update your scripts to load br_netfilter if you need this.
[    1.192037] 8021q: 802.1Q VLAN Support v1.8
[    1.196301] Registering SWP/SWPB emulation handler
[    1.201888] xhci-hcd f10f8000.usb3: xHCI Host Controller
[    1.207234] xhci-hcd f10f8000.usb3: new USB bus registered, assigned bus number 2
[    1.214856] xhci-hcd f10f8000.usb3: hcc params 0x0a000990 hci version 0x100 quirks 0x00010010
[    1.223449] xhci-hcd f10f8000.usb3: irq 43, io mem 0xf10f8000
[    1.229507] hub 2-0:1.0: USB hub found
[    1.233305] hub 2-0:1.0: 1 port detected
[    1.237327] xhci-hcd f10f8000.usb3: xHCI Host Controller
[    1.242673] xhci-hcd f10f8000.usb3: new USB bus registered, assigned bus number 3
[    1.250215] usb usb3: We don't know the algorithms for LPM for this host, disabling LPM.
[    1.258541] hub 3-0:1.0: USB hub found
[    1.261450] ata2: SATA link down (SStatus 0 SControl 300)
[    1.261471] ata1: SATA link down (SStatus 0 SControl 300)
[    1.273172] hub 3-0:1.0: 1 port detected
[    1.277444] UBI: auto-attach mtd5
[    1.280598] ubi0: attaching mtd5
[    1.376194] ubi0: scanning is finished
[    1.384288] ubi0: attached mtd5 (name "ubi", size 34 MiB)
[    1.389709] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
[    1.396622] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
[    1.403443] ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
[    1.410432] ubi0: good PEBs: 272, bad PEBs: 0, corrupted PEBs: 0
[    1.416466] ubi0: user volume: 2, internal volumes: 1, max. volumes count: 128
[    1.423721] ubi0: max/mean erase counter: 2/0, WL threshold: 4096, image sequence number: 86527830
[    1.432719] ubi0: available PEBs: 0, total reserved PEBs: 272, PEBs reserved for bad PEB handling: 20
[    1.441993] ubi0: background thread "ubi_bgt0d" started, PID 552
[    1.448390] block ubiblock0_0: created from ubi0:0(rootfs)
[    1.453909] ubiblock: device ubiblock0_0 (rootfs) set to be root filesystem
[    1.461084] mvsw61xx 10.mvsw61xx: Found MV88E6176 at f1072004.mdio-mi:10
[    1.467821] mvsw61xx 10.mvsw61xx: Using direct addressing
[    1.473287] armada38x-rtc f10a3800.rtc: setting system clock to 2067-10-27 11:56:41 UTC (3086942201)
[    1.483223] Waiting 1 sec before mounting root device...
[    2.492621] VFS: Mounted root (squashfs filesystem) readonly on device 254:0.
[    2.499919] Freeing unused kernel memory: 260K (c0583000 - c05c4000)
[    2.712564] init: Console is alive
[    2.716037] init: - watchdog -
[    3.001095] init: - preinit -
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
[    6.286174] mount_root: loading kmods from internal overlay
[    6.327645] random: nonblocking pool is initialized
[    6.371533] UBIFS (ubi0:1): background thread "ubifs_bgt0_1" started, PID 633
[    6.400043] UBIFS (ubi0:1): recovery needed
[    6.447012] UBIFS (ubi0:1): recovery completed
[    6.451514] UBIFS (ubi0:1): UBIFS: mounted UBI device 0, volume 1, name "rootfs_data"
[    6.459377] UBIFS (ubi0:1): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
[    6.469339] UBIFS (ubi0:1): FS size: 25903104 bytes (24 MiB, 204 LEBs), journal size 1269760 bytes (1 MiB, 10 LEBs)
[    6.479820] UBIFS (ubi0:1): reserved for root: 1223467 bytes (1194 KiB)
[    6.486467] UBIFS (ubi0:1): media format: w4/r0 (latest is w4/r0), UUID 2C714E96-005A-4368-A08F-AA0D97858BED, small LPT model
[    6.498427] block: attempting to load /tmp/ubifs_cfg/upper/etc/config/fstab
[    6.508344] block: extroot: not configured
[    6.541492] UBIFS (ubi0:1): un-mount UBI device 0
[    6.546222] UBIFS (ubi0:1): background thread "ubifs_bgt0_1" stops
[    6.554064] UBIFS (ubi0:1): background thread "ubifs_bgt0_1" started, PID 636
[    6.613752] UBIFS (ubi0:1): UBIFS: mounted UBI device 0, volume 1, name "rootfs_data"
[    6.621626] UBIFS (ubi0:1): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
[    6.631585] UBIFS (ubi0:1): FS size: 25903104 bytes (24 MiB, 204 LEBs), journal size 1269760 bytes (1 MiB, 10 LEBs)
[    6.642065] UBIFS (ubi0:1): reserved for root: 1223467 bytes (1194 KiB)
[    6.648707] UBIFS (ubi0:1): media format: w4/r0 (latest is w4/r0), UUID 2C714E96-005A-4368-A08F-AA0D97858BED, small LPT model
[    6.718997] block: attempting to load /tmp/ubifs_cfg/upper/etc/config/fstab
[    6.728235] block: extroot: not configured
[    6.762147] mount_root: switching to jffs2 overlay
[    6.800087] ubi1: attaching mtd8
[    6.903447] ubi1: scanning is finished
[    6.911558] ubi1: attached mtd8 (name "syscfg", size 38 MiB)
[    6.917242] ubi1: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
[    6.924150] ubi1: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
[    6.930965] ubi1: VID header offset: 2048 (aligned 2048), data offset: 4096
[    6.937957] ubi1: good PEBs: 296, bad PEBs: 8, corrupted PEBs: 0
[    6.943990] ubi1: user volume: 1, internal volumes: 1, max. volumes count: 128
[    6.951240] ubi1: max/mean erase counter: 207/138, WL threshold: 4096, image sequence number: 1220797378
[    6.960761] ubi1: available PEBs: 0, total reserved PEBs: 296, PEBs reserved for bad PEB handling: 12
[    6.970025] ubi1: background thread "ubi_bgt1d" started, PID 646
UBI device number 1, total 296 LEBs (37584896 bytes, 35.8 MiB), [    6.980555] UBIFS (ubi1:0): background thread "ubifs_bgt1_0" started, PID 650
available 0 LEBs (0 bytes), LEB size 126976 bytes (124.0 KiB)
[    7.030143] UBIFS (ubi1:0): UBIFS: mounted UBI device 1, volume 0, name "syscfg"
[    7.037578] UBIFS (ubi1:0): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
[    7.047537] UBIFS (ubi1:0): FS size: 34283520 bytes (32 MiB, 270 LEBs), journal size 1777664 bytes (1 MiB, 14 LEBs)
[    7.058017] UBIFS (ubi1:0): reserved for root: 1619295 bytes (1581 KiB)
[    7.064662] UBIFS (ubi1:0): media format: w4/r0 (latest is w4/r0), UUID 966E9803-824D-461B-8D6E-52CC0641547D, small LPT model
[    7.078942] procd: - early -
[    7.081871] procd: - watchdog -
[    7.676652] procd: - ubus -
[    7.731554] procd: - init -
Please press Enter to activate this console.
[    7.816111] ntfs: driver 2.1.32 [Flags: R/O MODULE].
[    7.824067] ip6_tables: (C) 2000-2006 Netfilter Core Team
[    7.831670] Loading modules backported from Linux version wt-2016-05-12-0-g7a54796
[    7.839277] Backport generated by backports.git backports-20160216-0-ge3c56e4
[    7.854105] <<Marvell 802.11ac Wireless Network Driver version 10.3.0.17-20160520-1>>
[    7.861846] pci 0000:00:01.0: enabling device (0140 -> 0142)
[    8.930453] ieee80211 phy0: firmware version: 0x7020902
[    8.960729] ieee80211 phy0: 2G disabled, 5G enabled
[    8.965656] ieee80211 phy0: 4 TX antennas, 4 RX antennas
[    8.971101] pci 0000:00:02.0: enabling device (0140 -> 0142)
[    9.980455] ieee80211 phy1: firmware version: 0x7020902
[   10.008546] ieee80211 phy1: 2G enabled, 5G disabled
[   10.013473] ieee80211 phy1: 4 TX antennas, 4 RX antennas
[   10.037984] u32 classifier
[   10.040704]     input device check on
[   10.044388]     Actions configured
[   10.048195] Mirror/redirect action on
[   10.058043] ip_tables: (C) 2000-2006 Netfilter Core Team
[   10.067707] nf_conntrack version 0.5.0 (8023 buckets, 32092 max)
[   10.169055] xt_time: kernel timezone is -0000
[   10.175972] PPP generic driver version 2.4.2
[   10.180654] NET: Registered protocol family 24
[   12.205668] device eth1 entered promiscuous mode
[   12.212332] br-lan: port 1(eth1) entered forwarding state
[   12.217785] br-lan: port 1(eth1) entered forwarding state
[   12.235143] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   13.197804] br-lan: port 1(eth1) entered disabled state
[   13.950656] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
[   14.201449] mvneta f1070000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
[   14.218536] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   14.224641] device wlan1 entered promiscuous mode
[   14.229398] br-lan: port 2(wlan1) entered forwarding state
[   14.234932] br-lan: port 2(wlan1) entered forwarding state
[   14.240626] br-lan: port 2(wlan1) entered disabled state
[   14.241458] mvneta f1034000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
[   14.253926] br-lan: port 1(eth1) entered forwarding state
[   14.259358] br-lan: port 1(eth1) entered forwarding state
[   14.264883] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   14.271367] device wlan0 entered promiscuous mode
[   16.251445] br-lan: port 1(eth1) entered forwarding state
[   28.174224] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[   28.180666] br-lan: port 3(wlan0) entered forwarding state
[   28.186196] br-lan: port 3(wlan0) entered forwarding state
[   29.586164] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
[   29.592644] br-lan: port 2(wlan1) entered forwarding state
[   29.598172] br-lan: port 2(wlan1) entered forwarding state
[   30.181120] br-lan: port 3(wlan0) entered forwarding state
[   31.591085] br-lan: port 2(wlan1) entered forwarding state





=======> Step 5: Check @root <=======

BusyBox v1.24.2 () built-in shell (ash)

     _________
    /        /\      _    ___ ___  ___
   /  LE    /  \    | |  | __|   \| __|
  /    DE  /    \   | |__| _|| |) | _|
 /________/  LE  \  |____|___|___/|___|                      lede-project.org
 \        \   DE /
  \    LE  \    /  -----------------------------------------------------------
   \  DE    \  /    Reboot (HEAD, r504)
    \________\/    -----------------------------------------------------------

root at WRT1900ACS:/# fw_printenv
bootcmd=bootp; setenv bootargs root=/dev/nfs nfsroot=${serverip}:${rootpath} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm
bootdelay=5
baudrate=115200
auto_recovery=yes
root at WRT1900ACS:/# strings /dev/mtd1
Z'ybootcmd=bootp; setenv bootargs root=/dev/nfs nfsroot=${serverip}:${rootpath} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm
bootdelay=5
baudrate=115200
auto_recovery=yes



	I think this will help. Let me know if you need to do any other test.

> On 07-Jun-2016, at 7:03 PM, Claudio Leite <leitec at gmail.com> wrote:
> 
> Hello Dheeran,
> 
> * Dheeran Senthilvel (dheeranmech at gmail.com) wrote:
>> Hi,
>> 	Yes even after I run resetenv followed by a reset command, the fw_printenv produces the same output every time. 
>> 
>>> On 07-Jun-2016, at 3:54 PM, Claudio Leite <leitec at gmail.com> wrote:
>>> 
>>> Hi,
>>> 
>>> * Dheeran Senthilvel (dheeranmech at gmail.com) wrote:
>>>> Hi,
>>>>      Thanks for the reply. But I already documented it in my previous
>>>> mails in May 2016.
>>>> This is temporary, once again when reboot is done the same error occurs.
>>> 
>>> I see, sorry for the noise.
>>> 
>>>> 
>>>>      I haven't been able to solve this issue. Also if altnandboot is
>>>> performed and used having lede in nandboot there seems to be no problem.
>>>> But once lede boots the error is imminent upon reboot.
>>> 
>>> I'm not sure I understand this part. Is the same image, with no custom
>>> settings, stored in both partitions?
>> Sorry for that! What I mean to say is if I boot ?altnandboot? (recovery official firmware) having lede in the primary_image partition, the problem doesn?t occur. Once I invoke nandboot and allow lede to boot and issue a reboot command, the error occurs. I gave this statement to clarify that the problem lede and not the 'hardware' or 'u-boot?.
> 
> OK, I understand now-you have the factory firmware on the secondary
> partition.
> 
>>> 
>>> What does fw_printenv look like after a "resetenv; reset" and boot into
>>> a recent LEDE? At that point, the linksys-recovery stuff will already
>>> have run.
>> But I really don?t understand the problem. This OpenWrt WiKi page - https://wiki.openwrt.org/doc/techref/bootloader/uboot.config , shows that this kind of error show only when the partition map is incorrect (That is what i understood) and as the following command shows that flash mapping recognised by lede is incorrect
> 
> It's not incorrect; it's just how LEDE/OpenWrt defines it. The partition
> map is baked into the kernel image via the dtb. The relevant partition
> is mtd1, u_env (and s_env, for the 'resetbc' stuff) which is correctly
> defined and matches up with the bootloader's (and factory firmware's)
> expectations.
> 
> From your own output:
> 
> lede:
> 
> [    0.973995] 0x000000000000-0x000000200000 : "u-boot"
> [    0.979273] 0x000000200000-0x000000240000 : "u_env"
> [    0.984435] 0x000000240000-0x000000280000 : "s_env"
> 
> factory:
> 
> 0x000000000000-0x000000200000 : "uboot"
> 0x000000200000-0x000000240000 : "u_env"
> 0x000000240000-0x000000280000 : "s_env"
> 
> Given the output you posted from fw_printenv earlier,
> 
> root at WRT1900ACS:/# fw_printenv
> bootcmd=bootp; setenv bootargs root=/dev/nfs
> nfsroot=${serverip}:${rootpath}
> ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm
> bootdelay=5
> baudrate=115200
> auto_recovery=yes 
> 
> there's some very strange corruption going on. It would probably help to
> determine if this is happening during the auto_recovery/resetbc stuff
> during boot, when it writes to u-env. If there's something off still
> with the NAND driver this could cause the corruption you see.
> 
> Could you try this:
> 
> 1. reboot and run "resetenv; reset"
> 2. boot into LEDE, but drop into failsafe mode (when prompted, type
> f<enter>)
> 
> 3. from failsafe mode, run
> 	strings /dev/mtd1
> 
> this should be the complete and long set of default variables.
> 
> 4. still from failsafe, run 'reboot'
> 
> During this time nothing new is written to u-env, so upon a reboot it
> should still be functional. The 'printenv' command from u-boot should
> list the variables intact, and it should boot normally.
> 
> Once booted into LEDE normally, if the fw_setenv command during the boot
> sequence is causing the corruption, fw_printenv or "strings /dev/mtd1"
> will now show some sort of corrupted output.
> 
> -Claudio



From leitec at gmail.com  Tue Jun  7 07:10:39 2016
From: leitec at gmail.com (Claudio Leite)
Date: Tue, 7 Jun 2016 10:10:39 -0400
Subject: [LEDE-DEV] WRT1900ACS - Kernel 4.4.12 boot failure
In-Reply-To: <6374F1F4-5A5F-4576-B43C-C65991C6E920@gmail.com>
References: <9BD7CD08-6799-4FF0-B8FA-380AFF42B5AA@gmail.com>
 <64E9BFC2-B9F1-4AAE-B799-0435B3091E41@gmail.com>
 <A5192BCC-101B-487A-913B-B3DA7A88C5DB@gmail.com>
 <F013F569-4F7F-4903-9F8E-F29FA6599A8F@gmail.com>
 <20160607095751.GA29607@pratt.mine.nu>
 <CAJe1gWKTkiEGh+j6ay_13+MuRGTvLEFAynB1dUiBJCc+r9ch1A@mail.gmail.com>
 <20160607102408.GB29607@pratt.mine.nu>
 <F1CDD9DC-2F03-412F-81DC-4C3318E489C9@gmail.com>
 <20160607133306.GC29607@pratt.mine.nu>
 <6374F1F4-5A5F-4576-B43C-C65991C6E920@gmail.com>
Message-ID: <20160607141039.GD29607@pratt.mine.nu>

Thanks for the clear output.

* Dheeran Senthilvel (dheeranmech at gmail.com) wrote:
[snip]
> =======> Step 3: Intrupt boot into failsafe <=======
> 
> Press the [f] key and hit [enter] to enter failsafe mode
> Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
> f
> - failsafe -
> [    4.986830] random: dropbearkey urandom read with 121 bits of entropy available
[snip]
> root@(none):/# strings /dev/mtd1
> [   44.008437] random: nonblocking pool is initialized

OK, this is definitely not right. It should be a long list of variables.

> =======> Step 4: Reboot <=======

> *** Warning - bad CRC, using default environment

again not right. this should have been cleared up the first time booting
after resetenv erased the old settings:

> 
> S-ENV offset == 0x240000
> 
> 
> #### auto_recovery ####
> [u_env] get auto_recovery == yes
> [u_env] get auto_recovery == yes
> [u_env] get boot_part == 1
> [u_env] get boot_part_ready == 3
> auto_recovery enabled:1, boot_part:1, boot_part_ready:3

This bit looks OK, though.

I'm a little confused because I thought after resetenv and a reset the
bootloader would actually write the default values to flash. This may
not have happened here, since mtd1 is empty. I think it's fairly safe
to say reads from NAND are OK, since otherwise you would get lots of
errors when booting the system.

So, one more test, again trying to clear and reset the u-boot
environment:

(these are all u-boot commands)

resetenv; reset

<interrupt boot>
printenv

if the default values are there, then do

saveenv
reset

and interrupt the boot again and run 'printenv'. Are they there?

-Claudio


From dheeranmech at gmail.com  Tue Jun  7 07:48:04 2016
From: dheeranmech at gmail.com (Dheeran Senthilvel)
Date: Tue, 7 Jun 2016 20:18:04 +0530
Subject: [LEDE-DEV] WRT1900ACS - Kernel 4.4.12 boot failure
In-Reply-To: <20160607141039.GD29607@pratt.mine.nu>
References: <9BD7CD08-6799-4FF0-B8FA-380AFF42B5AA@gmail.com>
 <64E9BFC2-B9F1-4AAE-B799-0435B3091E41@gmail.com>
 <A5192BCC-101B-487A-913B-B3DA7A88C5DB@gmail.com>
 <F013F569-4F7F-4903-9F8E-F29FA6599A8F@gmail.com>
 <20160607095751.GA29607@pratt.mine.nu>
 <CAJe1gWKTkiEGh+j6ay_13+MuRGTvLEFAynB1dUiBJCc+r9ch1A@mail.gmail.com>
 <20160607102408.GB29607@pratt.mine.nu>
 <F1CDD9DC-2F03-412F-81DC-4C3318E489C9@gmail.com>
 <20160607133306.GC29607@pratt.mine.nu>
 <6374F1F4-5A5F-4576-B43C-C65991C6E920@gmail.com>
 <20160607141039.GD29607@pratt.mine.nu>
Message-ID: <7B57CB2B-38DF-4A68-88FC-9F5D26CF6917@gmail.com>

=======> Step 1 : resetenv & reset <=======
 __   __                      _ _
|  \/  | __ _ _ ____   _____| | |
| |\/| |/ _` | '__\ \ / / _ \ | |
| |  | | (_| | |   \ V /  __/ | |
|_|  |_|\__,_|_|    \_/ \___|_|_|
         _   _     ____              _
        | | | |   | __ )  ___   ___ | |_
        | | | |___|  _ \ / _ \ / _ \| __|
        | |_| |___| |_) | (_) | (_) | |_
         \___/    |____/ \___/ \___/ \__|
 ** LOADER **


U-Boot 2013.01 (Mar 27 2015 - 16:50:46) Marvell version: 2014_T3.0p6

Boot version : v1.0.13

Board: RD-NAS-88F6820-DDR3
SoC:   MV88F6820 Rev A0
       running 2 CPUs
CPU:   ARM Cortex A9 MPCore (Rev 1) LE
       CPU 0
       CPU    @ 1600 [MHz]
       L2     @ 800 [MHz]
       TClock @ 200 [MHz]
       DDR    @ 800 [MHz]
       DDR 32 Bit Width, FastPath Memory Access, DLB Enabled, ECC Disabled
DRAM:  512 MiB

Map:   Code:                    0x1fea9000:0x1ff7632c
       BSS:                     0x1ffef6b4
       Stack:                   0x1f9a8f20
       Heap:                    0x1f9a9000:0x1fea9000
raise: Signal # 8 caught
U-ENV offset == 0x200000
raise: Signal # 8 caught
U-ENV offset == 0x200000
       U-Boot Environment:      0x00200000:0x00220000 (NAND)

NAND:  128 MiB
MMC:   mv_sdh: 0
DEVINFO offset == 0x900000
U-ENV offset == 0x200000
U-ENV offset == 0x200000
*** Warning - bad CRC, using default environment

S-ENV offset == 0x240000


#### auto_recovery ####
[u_env] get auto_recovery == yes
[u_env] get auto_recovery == yes
[u_env] get boot_part == 1
[u_env] get boot_part_ready == 3
auto_recovery enabled:1, boot_part:1, boot_part_ready:3

S-ENV offset == 0x240000
[boot_count_read] block:0x240000, size:128KB, records:64
[boot_count_read_record] boot_count:1, next_record:34

[boot_count_write] erase:0, auto_recovery->block_offset:0x240000 offset=0x251000

Updating boot_count ...
[boot_count_write] offset:0x251000 , length:2048
done

PCI-e 0 (IF 0 - bus 0) Root Complex Interface, Detected Link X1, GEN 2.0
PCI-e 1 (IF 1 - bus 1) Root Complex Interface, Detected Link X1, GEN 1.1
USB2.0 0: Host Mode
USB3.0 1: Host Mode
USB3.0 0: Host Mode
Board configuration detected:
mvEthE6171SwitchBasicInit init
Net:
|  port  | Interface | PHY address  |
|--------|-----------|--------------|
| egiga0 |   RGMII   |     0x01     |
| egiga1 |   SGMII   |     0x00     |
egiga0 [PRIME], egiga1
auto_recovery_check changes bootcmd: run nandboot
Hit any key to stop autoboot:  0

Marvell>> printenv
CASset=max
MALLOC_len=5
MPmode=SMP
altFwSize=0x2800000
altKernAddr=0x3200000
altKernSize=0x0600000
altnandboot=setenv bootargs console=ttyS0,115200 root=/dev/mtdblock7 ro rootdelay=1 rootfstype=jffs2 earlyprintk $mtdparts;nand read $defaultLoadAddr $altKernAd
dr $altKernSize; bootm $defaultLoadAddr
auto_recovery=yes
autoload=no
baudrate=115200
boot_order=hd_scr usb_scr mmc_scr hd_img usb_img mmc_img pxe net_img net_scr
boot_part=1
boot_part_ready=3
bootargs_dflt=$console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_para
ms clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel
bootargs_end=:10.4.50.254:255.255.255.0:Armada38x:eth0:none
bootargs_root=root=/dev/nfs rw
bootcmd=run nandboot
bootcmd_auto=stage_boot $boot_order
bootcmd_fdt=tftpboot 0x2000000 $image_name;tftpboot $fdtaddr $fdtfile;setenv bootargs $console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=
$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel; bootz 0x2000000 - $fdtaddr;
bootcmd_fdt_boot=tftpboot 0x2000000 $image_name; setenv bootargs $console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$boo
targs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel; bootz 0x2000000 - $fdtaddr;
bootcmd_fdt_edit=tftpboot $fdtaddr $fdtfile; fdt addr $fdtaddr; setenv bootcmd $bootcmd_fdt_boot
bootcmd_lgcy=tftpboot 0x2000000 $image_name; setenv bootargs $bootargs_dflt; bootm 0x2000000;
bootdelay=3
cacheShare=no
console=console=ttyS0,115200
defaultLoadAddr=0x2000000
device_partition=0:1
disaMvPnp=no
eeeEnable=no
enaClockGating=no
enaCpuStream=no
enaFPU=yes
enaMonExt=no
enaWrAllo=no
eth1addr=00:50:43:7a:d1:e5
eth1mtu=1500
eth2addr=00:50:43:7a:45:d5
eth2mtu=1500
eth3addr=00:50:43:e1:45:8a
eth3mtu=1500
ethact=egiga0
ethaddr=00:50:43:45:e1:f5
ethmtu=1500
ethprime=egiga0
fdt_addr=2040000
fdt_skip_update=no
fdtaddr=0x1000000
fdtfile=armada-38x-modular.dtb
firmwareName=cobra.img
flash_alt_image=tftpboot $defaultLoadAddr $firmwareName && nand erase $altKernAddr $altFwSize && nand write $defaultLoadAddr $altKernAddr $filesize
flash_pri_image=tftpboot $defaultLoadAddr $firmwareName && nand erase $priKernAddr $priFwSize && nand write $defaultLoadAddr $priKernAddr $filesize
ide_path=/
image_name=uImage
initrd_name=uInitrd
ipaddr=192.168.1.1
kernel_addr_r=2080000
lcd0_enable=0
lcd0_params=640x480-16 at 60
lcd_panel=0
loadaddr=0x02000000
loads_echo=0
mtdids=nand0=armada-nand
mtdparts=mtdparts=armada-nand:2048K(uboot)ro,256K(u_env),256K(s_env),1m at 9m(devinfo),40m at 10m(kernel),34m at 16m(rootfs),40m at 50m(alt_kernel),34m at 56m(alt_rootfs),80m@
10m(ubifs),- at 90m(syscfg)
mvNetConfig=mv_net_config=4,(00:50:43:11:11:11,0:1:2:3),mtu=1500
mv_pon_addr=00:50:43:e5:45:7a
nandEcc=nfcConfig=4bitecc
nandboot=setenv bootargs console=ttyS0,115200 root=/dev/mtdblock5 ro rootdelay=1 rootfstype=jffs2 earlyprintk $mtdparts;nand read $defaultLoadAddr $priKernAddr
$priKernSize; bootm $defaultLoadAddr
netbsd_en=no
netmask=255.255.255.0
netretry=no
pcieTune=no
pexMode=RC
priFwSize=0x2800000
priKernAddr=0x0a00000
priKernSize=0x0600000
pxe_files_load=:default.arm-armadaxp-db:default.arm-armadaxp:default.arm
pxefile_addr_r=3100000
ramdisk_addr_r=2880000
rootpath=/srv/nfs/
sata_delay_reset=0
sata_dma_mode=yes
script_addr_r=3000000
script_name=boot.scr
serverip=192.168.1.254
standalone=fsload 0x2000000 $image_name;setenv bootargs $console $nandEcc $mtdparts root=/dev/mtdblock0 rw ip=$ipaddr:$serverip$bootargs_end; bootm 0x2000000;
stderr=serial
stdin=serial
stdout=serial
update_both_images=tftpboot $defaultLoadAddr $firmwareName && nand erase $priKernAddr $priFwSize && nand erase $altKernAddr $altFwSize && nand write $defaultLoa
dAddr $priKernAddr $filesize && nand write $defaultLoadAddr $altKernAddr $filesize
usb0Mode=host
usbActive=0
usbType=2
vxworks_en=no
yuk_ethaddr=00:00:00:EE:41:71

Environment size: 4211/131068 bytes

Marvell>> saveenv
Saving Environment to NAND...
U-ENV offset == 0x200000
Erasing Nand...
Writing to Nand... U-ENV offset == 0x200000
U-ENV offset == 0x200000
done

Marvell>> reset


=======> Step 2: Allow it to boot <=======
 __   __                      _ _
|  \/  | __ _ _ ____   _____| | |
| |\/| |/ _` | '__\ \ / / _ \ | |
| |  | | (_| | |   \ V /  __/ | |
|_|  |_|\__,_|_|    \_/ \___|_|_|
         _   _     ____              _
        | | | |   | __ )  ___   ___ | |_
        | | | |___|  _ \ / _ \ / _ \| __|
        | |_| |___| |_) | (_) | (_) | |_
         \___/    |____/ \___/ \___/ \__|
 ** LOADER **


U-Boot 2013.01 (Mar 27 2015 - 16:50:46) Marvell version: 2014_T3.0p6

Boot version : v1.0.13

Board: RD-NAS-88F6820-DDR3
SoC:   MV88F6820 Rev A0
       running 2 CPUs
CPU:   ARM Cortex A9 MPCore (Rev 1) LE
       CPU 0
       CPU    @ 1600 [MHz]
       L2     @ 800 [MHz]
       TClock @ 200 [MHz]
       DDR    @ 800 [MHz]
       DDR 32 Bit Width, FastPath Memory Access, DLB Enabled, ECC Disabled
DRAM:  512 MiB

Map:   Code:                    0x1fea9000:0x1ff7632c
       BSS:                     0x1ffef6b4
       Stack:                   0x1f9a8f20
       Heap:                    0x1f9a9000:0x1fea9000
raise: Signal # 8 caught
U-ENV offset == 0x200000
raise: Signal # 8 caught
U-ENV offset == 0x200000
       U-Boot Environment:      0x00200000:0x00220000 (NAND)

NAND:  128 MiB
MMC:   mv_sdh: 0
DEVINFO offset == 0x900000
U-ENV offset == 0x200000
U-ENV offset == 0x200000
S-ENV offset == 0x240000


#### auto_recovery ####
[u_env] get auto_recovery == yes
[u_env] get auto_recovery == yes
[u_env] get boot_part == 1
[u_env] get boot_part_ready == 3
auto_recovery enabled:1, boot_part:1, boot_part_ready:3

S-ENV offset == 0x240000
[boot_count_read] block:0x240000, size:128KB, records:64
[boot_count_read_record] boot_count:2, next_record:35

[boot_count_write] erase:0, auto_recovery->block_offset:0x240000 offset=0x251800

Updating boot_count ...
[boot_count_write] offset:0x251800 , length:2048
done

PCI-e 0 (IF 0 - bus 0) Root Complex Interface, Detected Link X1, GEN 2.0
PCI-e 1 (IF 1 - bus 1) Root Complex Interface, Detected Link X1, GEN 1.1
USB2.0 0: Host Mode
USB3.0 1: Host Mode
USB3.0 0: Host Mode
Board configuration detected:
mvEthE6171SwitchBasicInit init
Net:
|  port  | Interface | PHY address  |
|--------|-----------|--------------|
| egiga0 |   RGMII   |     0x01     |
| egiga1 |   SGMII   |     0x00     |
egiga0 [PRIME], egiga1
auto_recovery_check changes bootcmd: run nandboot
Hit any key to stop autoboot:  0

NAND read: device 0 offset 0xa00000, size 0x600000
 6291456 bytes read: OK
## Booting kernel from Legacy Image at 02000000 ...
   Image Name:   ARM LEDE Linux-4.4.12
   Created:      2016-06-05  13:42:27 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2084373 Bytes = 2 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.4.12 (dhees at XPS) (gcc version 5.3.0 (LEDE GCC 5.3.0 r504) ) #1 SMP Sun Jun 5 15:29:33 UTC 2016
[    0.000000] CPU: ARMv7 Processor [414fc091] revision 1 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine model: Linksys WRT1900ACS
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] PERCPU: Embedded 12 pages/cpu @dfbcf000 s17984 r8192 d22976 u49152
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 130048
[    0.000000] Kernel command line: console=ttyS0,115200 root=/dev/mtdblock5 ro rootdelay=1 rootfstype=jffs2 earlyprintk mtdparts=armada-nand:2048K(uboot)ro,256
K(u_env),256K(s_env),1m at 9m(devinfo),40m at 10m(kernel),34m at 16m(rootfs),40m at 50m(alt_kernel),34m at 56m(alt_rootfs),80m at 10m(ubifs),- at 90m(syscfg)
[    0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Memory: 513220K/524288K available (4079K kernel code, 171K rwdata, 1528K rodata, 260K init, 295K bss, 11068K reserved, 0K cma-reserved, 0K highme
m)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
[    0.000000]     vmalloc : 0xe0800000 - 0xff800000   ( 496 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0008000 - 0xc05821d8   (5609 kB)
[    0.000000]       .init : 0xc0583000 - 0xc05c4000   ( 260 kB)
[    0.000000]       .data : 0xc05c4000 - 0xc05eedf4   ( 172 kB)
[    0.000000]        .bss : 0xc05eedf4 - 0xc0638a6c   ( 296 kB)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000]  RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
[    0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] mvebu_mbus: [Firmware Warn]: deprecated mbus-mvebu Device Tree, suspend/resume will not work
[    0.000000] L2C-310 enabling early BRESP for Cortex-A9
[    0.000000] L2C-310 full line of zeros enabled for Cortex-A9
[    0.000000] L2C-310 D prefetch enabled, offset 1 lines
[    0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled
[    0.000000] L2C-310 Coherent cache controller enabled, 16 ways, 1024 kB
[    0.000000] L2C-310 Coherent: CACHE_ID 0x410054c9, AUX_CTRL 0x56070001
[    0.000000] Switching to timer-based delay loop, resolution 40ns
[    0.000003] sched_clock: 32 bits at 25MHz, resolution 40ns, wraps every 85899345900ns
[    0.000009] clocksource: armada_370_xp_clocksource: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 76450417870 ns
[    0.000111] Calibrating delay loop (skipped), value calculated using timer frequency.. 50.00 BogoMIPS (lpj=250000)
[    0.000118] pid_max: default: 32768 minimum: 301
[    0.000154] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000158] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000339] CPU: Testing write buffer coherency: ok
[    0.000437] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.000460] Setting up static identity map for 0x8280 - 0x82d8
[    0.000537] mvebu-soc-id: MVEBU SoC ID=0x6820, Rev=0x4
[    0.000613] mvebu-pmsu: Initializing Power Management Service Unit
[    0.001001] Booting CPU 1
[    0.001160] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[    0.001187] Brought up 2 CPUs
[    0.001193] SMP: Total of 2 processors activated (100.00 BogoMIPS).
[    0.001196] CPU: All CPU(s) started in SVC mode.
[    0.002859] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
[    0.002933] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.002971] pinctrl core: initialized pinctrl subsystem
[    0.003279] NET: Registered protocol family 16
[    0.003768] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.029940] cpuidle: using governor ladder
[    0.032349] mvebu-pmsu: CPU hotplug support is currently broken on Armada 38x: disabling
[    0.032357] mvebu-pmsu: CPU idle is currently broken on Armada 38x: disabling
[    0.060500] reg-fixed-voltage xhci0-vbus: could not find pctldev for node /soc/internal-regs/pinctrl at 18000/xhci0-vbus-pins, deferring probe
[    0.060659] SCSI subsystem initialized
[    0.060847] usbcore: registered new interface driver usbfs
[    0.060874] usbcore: registered new interface driver hub
[    0.060896] usbcore: registered new device driver usb
[    0.061433] clocksource: Switched to clocksource armada_370_xp_clocksource
[    0.061845] NET: Registered protocol family 2
[    0.062054] TCP established hash table entries: 4096 (order: 2, 16384 bytes)
[    0.062079] TCP bind hash table entries: 4096 (order: 3, 32768 bytes)
[    0.062111] TCP: Hash tables configured (established 4096 bind 4096)
[    0.062132] UDP hash table entries: 256 (order: 1, 8192 bytes)
[    0.062144] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
[    0.062208] NET: Registered protocol family 1
[    0.062592] futex hash table entries: 512 (order: 3, 32768 bytes)
[    0.064985] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    0.064995] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc.
[    0.065642] io scheduler noop registered
[    0.065648] io scheduler deadline registered (default)
[    0.066020] armada-38x-pinctrl f1018000.pinctrl: registered pinctrl driver
[    0.066319] irq: Cannot allocate irq_descs @ IRQ44, assuming pre-allocated
[    0.066453] irq: Cannot allocate irq_descs @ IRQ76, assuming pre-allocated
[    0.066739] mvebu-pcie soc:pcie-controller: PCI host bridge to bus 0000:00
[    0.066746] pci_bus 0000:00: root bus resource [io  0x1000-0xfffff]
[    0.066751] pci_bus 0000:00: root bus resource [mem 0xe0000000-0xe7ffffff]
[    0.066755] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.066939] PCI: bus0: Fast back to back transfers disabled
[    0.066945] pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    0.066952] pci 0000:00:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    0.067166] PCI: bus1: Fast back to back transfers disabled
[    0.067417] PCI: bus2: Fast back to back transfers disabled
[    0.067471] pci 0000:00:01.0: BAR 8: assigned [mem 0xe0000000-0xe01fffff]
[    0.067477] pci 0000:00:02.0: BAR 8: assigned [mem 0xe0200000-0xe03fffff]
[    0.067484] pci 0000:01:00.0: BAR 0: assigned [mem 0xe0000000-0xe00fffff 64bit pref]
[    0.067494] pci 0000:01:00.0: BAR 2: assigned [mem 0xe0100000-0xe01fffff 64bit pref]
[    0.067502] pci 0000:00:01.0: PCI bridge to [bus 01]
[    0.067508] pci 0000:00:01.0:   bridge window [mem 0xe0000000-0xe01fffff]
[    0.067515] pci 0000:02:00.0: BAR 0: assigned [mem 0xe0200000-0xe02fffff 64bit pref]
[    0.067525] pci 0000:02:00.0: BAR 2: assigned [mem 0xe0300000-0xe03fffff 64bit pref]
[    0.067534] pci 0000:00:02.0: PCI bridge to [bus 02]
[    0.067539] pci 0000:00:02.0:   bridge window [mem 0xe0200000-0xe03fffff]
[    0.067633] mv_xor f1060800.xor: Marvell shared XOR driver
[    0.101849] mv_xor f1060800.xor: Marvell XOR (Descriptor Mode): ( xor cpy intr )
[    0.101931] mv_xor f1060900.xor: Marvell shared XOR driver
[    0.141835] mv_xor f1060900.xor: Marvell XOR (Descriptor Mode): ( xor cpy intr )
[    0.141975] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[    0.142241] console [ttyS0] disabled
[    0.162310] f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 21, base_baud = 12500000) is a 16550A
[    0.871471] console [ttyS0] enabled
[    0.875295] ahci-mvebu f10a8000.sata: AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl platform mode
[    0.884393] ahci-mvebu f10a8000.sata: flags: 64bit ncq sntf led only pmp fbs pio slum part sxs
[    0.893792] scsi host0: ahci-mvebu
[    0.897354] scsi host1: ahci-mvebu
[    0.900854] ata1: SATA max UDMA/133 mmio [mem 0xf10a8000-0xf10a9fff] port 0x100 irq 41
[    0.908814] ata2: SATA max UDMA/133 mmio [mem 0xf10a8000-0xf10a9fff] port 0x180 irq 41
[    0.917152] pxa3xx-nand f10d0000.flash: This platform can't do DMA on this device
[    0.924970] nand: device found, Manufacturer ID: 0x01, Chip ID: 0xf1
[    0.931349] nand: AMD/Spansion S34ML01G2
[    0.935295] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
[    0.942903] pxa3xx-nand f10d0000.flash: ECC strength 16, ECC step size 2048
[    0.950081] Bad block table found at page 65472, version 0x01
[    0.956193] Bad block table found at page 65408, version 0x01
[    0.962229] 10 ofpart partitions found on MTD device pxa3xx_nand-0
[    0.968434] Creating 10 MTD partitions on "pxa3xx_nand-0":
[    0.973950] 0x000000000000-0x000000200000 : "u-boot"
[    0.979230] 0x000000200000-0x000000240000 : "u_env"
[    0.984395] 0x000000240000-0x000000280000 : "s_env"
[    0.989547] 0x000000900000-0x000000a00000 : "devinfo"
[    0.994884] 0x000000a00000-0x000003200000 : "kernel1"
[    1.000239] 0x000001000000-0x000003200000 : "ubi"
[    1.005267] 0x000003200000-0x000005a00000 : "kernel2"
[    1.010608] 0x000003800000-0x000005a00000 : "rootfs2"
[    1.015951] 0x000005a00000-0x000008000000 : "syscfg"
[    1.021212] 0x000000280000-0x000000900000 : "unused_area"
[    1.027338] libphy: Fixed MDIO Bus: probed
[    1.031559] libphy: orion_mdio_bus: probed
[    1.035807] mvneta_bm f10c8000.bm: Buffer Manager for network controller enabled
[    1.044714] mvneta f1034000.ethernet eth0: Using random mac address ea:69:35:9f:06:8e
[    1.053741] mvneta f1070000.ethernet eth1: Using hardware mac address 00:50:43:45:e1:e5
[    1.061846] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.068401] ehci-pci: EHCI PCI platform driver
[    1.072906] ehci-platform: EHCI generic platform driver
[    1.078238] ehci-orion: EHCI orion driver
[    1.082337] orion-ehci f1058000.usb: EHCI Host Controller
[    1.087770] orion-ehci f1058000.usb: new USB bus registered, assigned bus number 1
[    1.095433] orion-ehci f1058000.usb: irq 36, io mem 0xf1058000
[    1.111419] orion-ehci f1058000.usb: USB 2.0 started, EHCI 1.00
[    1.117592] hub 1-0:1.0: USB hub found
[    1.121368] hub 1-0:1.0: 1 port detected
[    1.125667] usbcore: registered new interface driver usb-storage
[    1.131849] armada38x-rtc f10a3800.rtc: rtc core: registered f10a3800.rtc as rtc0
[    1.139492] i2c /dev entries driver
[    1.154479] orion_wdt: Initial timeout 171 sec
[    1.162292] marvell-cesa f1090000.crypto: CESA device successfully registered
[    1.169945] NET: Registered protocol family 10
[    1.174852] NET: Registered protocol family 17
[    1.179330] bridge: automatic filtering via arp/ip/ip6tables has been deprecated. Update your scripts to load br_netfilter if you need this.
[    1.192002] 8021q: 802.1Q VLAN Support v1.8
[    1.196265] Registering SWP/SWPB emulation handler
[    1.201849] xhci-hcd f10f8000.usb3: xHCI Host Controller
[    1.207194] xhci-hcd f10f8000.usb3: new USB bus registered, assigned bus number 2
[    1.214818] xhci-hcd f10f8000.usb3: hcc params 0x0a000990 hci version 0x100 quirks 0x00010010
[    1.223412] xhci-hcd f10f8000.usb3: irq 43, io mem 0xf10f8000
[    1.229467] hub 2-0:1.0: USB hub found
[    1.233265] hub 2-0:1.0: 1 port detected
[    1.237289] xhci-hcd f10f8000.usb3: xHCI Host Controller
[    1.242636] xhci-hcd f10f8000.usb3: new USB bus registered, assigned bus number 3
[    1.250178] usb usb3: We don't know the algorithms for LPM for this host, disabling LPM.
[    1.258502] hub 3-0:1.0: USB hub found
[    1.261426] ata2: SATA link down (SStatus 0 SControl 300)
[    1.261446] ata1: SATA link down (SStatus 0 SControl 300)
[    1.273131] hub 3-0:1.0: 1 port detected
[    1.277403] UBI: auto-attach mtd5
[    1.280558] ubi0: attaching mtd5
[    1.376234] ubi0: scanning is finished
[    1.384320] ubi0: attached mtd5 (name "ubi", size 34 MiB)
[    1.389740] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
[    1.396653] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
[    1.403474] ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
[    1.410463] ubi0: good PEBs: 272, bad PEBs: 0, corrupted PEBs: 0
[    1.416497] ubi0: user volume: 2, internal volumes: 1, max. volumes count: 128
[    1.423751] ubi0: max/mean erase counter: 2/1, WL threshold: 4096, image sequence number: 86527830
[    1.432750] ubi0: available PEBs: 0, total reserved PEBs: 272, PEBs reserved for bad PEB handling: 20
[    1.442023] ubi0: background thread "ubi_bgt0d" started, PID 552
[    1.448425] block ubiblock0_0: created from ubi0:0(rootfs)
[    1.453943] ubiblock: device ubiblock0_0 (rootfs) set to be root filesystem
[    1.461117] mvsw61xx 10.mvsw61xx: Found MV88E6176 at f1072004.mdio-mi:10
[    1.467854] mvsw61xx 10.mvsw61xx: Using direct addressing
[    1.473323] armada38x-rtc f10a3800.rtc: setting system clock to 2067-10-27 11:56:41 UTC (3086942201)
[    1.483267] Waiting 1 sec before mounting root device...
[    2.492601] VFS: Mounted root (squashfs filesystem) readonly on device 254:0.
[    2.499898] Freeing unused kernel memory: 260K (c0583000 - c05c4000)
[    2.712613] init: Console is alive
[    2.716094] init: - watchdog -
[    3.000983] init: - preinit -
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
[    6.306832] mount_root: loading kmods from internal overlay
[    6.347886] random: nonblocking pool is initialized
[    6.397182] UBIFS (ubi0:1): background thread "ubifs_bgt0_1" started, PID 634
[    6.425546] UBIFS (ubi0:1): recovery needed
[    6.476463] UBIFS (ubi0:1): recovery completed
[    6.480957] UBIFS (ubi0:1): UBIFS: mounted UBI device 0, volume 1, name "rootfs_data"
[    6.488828] UBIFS (ubi0:1): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
[    6.498787] UBIFS (ubi0:1): FS size: 25903104 bytes (24 MiB, 204 LEBs), journal size 1269760 bytes (1 MiB, 10 LEBs)
[    6.509267] UBIFS (ubi0:1): reserved for root: 1223467 bytes (1194 KiB)
[    6.515911] UBIFS (ubi0:1): media format: w4/r0 (latest is w4/r0), UUID 2C714E96-005A-4368-A08F-AA0D97858BED, small LPT model
[    6.527851] block: attempting to load /tmp/ubifs_cfg/upper/etc/config/fstab
[    6.537383] block: extroot: not configured
[    6.571468] UBIFS (ubi0:1): un-mount UBI device 0
[    6.576197] UBIFS (ubi0:1): background thread "ubifs_bgt0_1" stops
[    6.584113] UBIFS (ubi0:1): background thread "ubifs_bgt0_1" started, PID 637
[    6.641608] UBIFS (ubi0:1): UBIFS: mounted UBI device 0, volume 1, name "rootfs_data"
[    6.649472] UBIFS (ubi0:1): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
[    6.659438] UBIFS (ubi0:1): FS size: 25903104 bytes (24 MiB, 204 LEBs), journal size 1269760 bytes (1 MiB, 10 LEBs)
[    6.669921] UBIFS (ubi0:1): reserved for root: 1223467 bytes (1194 KiB)
[    6.676568] UBIFS (ubi0:1): media format: w4/r0 (latest is w4/r0), UUID 2C714E96-005A-4368-A08F-AA0D97858BED, small LPT model
[    6.746332] block: attempting to load /tmp/ubifs_cfg/upper/etc/config/fstab
[    6.755551] block: extroot: not configured
[    6.782122] mount_root: switching to jffs2 overlay
[    6.820125] ubi1: attaching mtd8
[    6.923892] ubi1: scanning is finished
[    6.931980] ubi1: attached mtd8 (name "syscfg", size 38 MiB)
[    6.937663] ubi1: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
[    6.944574] ubi1: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
[    6.951389] ubi1: VID header offset: 2048 (aligned 2048), data offset: 4096
[    6.958382] ubi1: good PEBs: 296, bad PEBs: 8, corrupted PEBs: 0
[    6.964415] ubi1: user volume: 1, internal volumes: 1, max. volumes count: 128
[    6.971669] ubi1: max/mean erase counter: 208/138, WL threshold: 4096, image sequence number: 1220797378
[    6.981187] ubi1: available PEBs: 0, total reserved PEBs: 296, PEBs reserved for bad PEB handling: 12
[    6.990454] ubi1: background thread "ubi_bgt1d" started, PID 647
UBI device number 1, total 296 LEBs (37584896 bytes, 35.8 MiB), [    7.001004] UBIFS (ubi1:0): background thread "ubifs_bgt1_0" started, PID 651
available 0 LEBs (0 bytes), LEB size 126976 bytes (124.0 KiB)
[    7.030913] UBIFS (ubi1:0): recovery needed
[    7.123953] UBIFS (ubi1:0): recovery completed
[    7.128444] UBIFS (ubi1:0): UBIFS: mounted UBI device 1, volume 0, name "syscfg"
[    7.135880] UBIFS (ubi1:0): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
[    7.145840] UBIFS (ubi1:0): FS size: 34283520 bytes (32 MiB, 270 LEBs), journal size 1777664 bytes (1 MiB, 14 LEBs)
[    7.156322] UBIFS (ubi1:0): reserved for root: 1619295 bytes (1581 KiB)
[    7.162967] UBIFS (ubi1:0): media format: w4/r0 (latest is w4/r0), UUID 966E9803-824D-461B-8D6E-52CC0641547D, small LPT model
[    7.178650] procd: - early -
[    7.181727] procd: - watchdog -
[    7.776824] procd: - ubus -
[    7.831667] procd: - init -
Please press Enter to activate this console.
[    7.915896] ntfs: driver 2.1.32 [Flags: R/O MODULE].
[    7.923841] ip6_tables: (C) 2000-2006 Netfilter Core Team
[    7.931461] Loading modules backported from Linux version wt-2016-05-12-0-g7a54796
[    7.939067] Backport generated by backports.git backports-20160216-0-ge3c56e4
[    7.953984] <<Marvell 802.11ac Wireless Network Driver version 10.3.0.17-20160520-1>>
[    7.961729] pci 0000:00:01.0: enabling device (0140 -> 0142)
[    9.026415] ieee80211 phy0: firmware version: 0x7020902
[    9.056680] ieee80211 phy0: 2G disabled, 5G enabled
[    9.061597] ieee80211 phy0: 4 TX antennas, 4 RX antennas
[    9.067042] pci 0000:00:02.0: enabling device (0140 -> 0142)
[   10.076415] ieee80211 phy1: firmware version: 0x7020902
[   10.104510] ieee80211 phy1: 2G enabled, 5G disabled
[   10.109414] ieee80211 phy1: 4 TX antennas, 4 RX antennas
[   10.133960] u32 classifier
[   10.136680]     input device check on
[   10.140354]     Actions configured
[   10.144169] Mirror/redirect action on
[   10.154055] ip_tables: (C) 2000-2006 Netfilter Core Team
[   10.162296] nf_conntrack version 0.5.0 (8023 buckets, 32092 max)
[   10.269056] xt_time: kernel timezone is -0000
[   10.275989] PPP generic driver version 2.4.2
[   10.280659] NET: Registered protocol family 24
[   12.285964] device eth1 entered promiscuous mode
[   12.292011] br-lan: port 1(eth1) entered forwarding state
[   12.297450] br-lan: port 1(eth1) entered forwarding state
[   12.310594] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   13.271438] br-lan: port 1(eth1) entered disabled state
[   14.000628] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
[   14.260618] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   14.266699] device wlan1 entered promiscuous mode
[   14.271462] br-lan: port 2(wlan1) entered forwarding state
[   14.276982] br-lan: port 2(wlan1) entered forwarding state
[   14.281435] mvneta f1070000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
[   14.290414] br-lan: port 2(wlan1) entered disabled state
[   14.296037] br-lan: port 1(eth1) entered forwarding state
[   14.301443] mvneta f1034000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
[   14.309338] br-lan: port 1(eth1) entered forwarding state
[   14.314816] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   14.321635] device wlan0 entered promiscuous mode
[   16.301426] br-lan: port 1(eth1) entered forwarding state
[   28.291435] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[   28.297882] br-lan: port 3(wlan0) entered forwarding state
[   28.303418] br-lan: port 3(wlan0) entered forwarding state
[   29.665446] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
[   29.671898] br-lan: port 2(wlan1) entered forwarding state
[   29.677421] br-lan: port 2(wlan1) entered forwarding state
[   30.301413] br-lan: port 3(wlan0) entered forwarding state
[   31.671414] br-lan: port 2(wlan1) entered forwarding state


BusyBox v1.24.2 () built-in shell (ash)

     _________
    /        /\      _    ___ ___  ___
   /  LE    /  \    | |  | __|   \| __|
  /    DE  /    \   | |__| _|| |) | _|
 /________/  LE  \  |____|___|___/|___|                      lede-project.org
 \        \   DE /
  \    LE  \    /  -----------------------------------------------------------
   \  DE    \  /    Reboot (HEAD, r504)
    \________\/    -----------------------------------------------------------


root at WRT1900ACS:/# fw_printenv
CASset=max
MALLOC_len=5
MPmode=SMP
altFwSize=0x2800000
altKernAddr=0x3200000
altKernSize=0x0600000
altnandboot=setenv bootargs console=ttyS0,115200 root=/dev/mtdblock7 ro rootdelay=1 rootfstype=jffs2 earlyprintk $mtdparts;nand read $defaultLoadAddr $altKernAd
dr $altKernSize; bootm $defaultLoadAddr
auto_recovery=yes
autoload=no
baudrate=115200
boot_order=hd_scr usb_scr mmc_scr hd_img usb_img mmc_img pxe net_img net_scr
boot_part=1
boot_part_ready=3
bootargs_dflt=$console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_para
ms clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel
bootargs_end=:10.4.50.254:255.255.255.0:Armada38x:eth0:none
bootargs_root=root=/dev/nfs rw
bootcmd=run nandboot
bootcmd_auto=stage_boot $boot_order
bootcmd_fdt=tftpboot 0x2000000 $image_name;tftpboot $fdtaddr $fdtfile;setenv bootargs $console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=
$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel; bootz 0x2000000 - $fdtaddr;
bootcmd_fdt_boot=tftpboot 0x2000000 $image_name; setenv bootargs $console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$boo
targs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel; bootz 0x2000000 - $fdtaddr;
bootcmd_fdt_edit=tftpboot $fdtaddr $fdtfile; fdt addr $fdtaddr; setenv bootcmd $bootcmd_fdt_boot
bootcmd_lgcy=tftpboot 0x2000000 $image_name; setenv bootargs $bootargs_dflt; bootm 0x2000000;
bootdelay=3
cacheShare=no
console=console=ttyS0,115200
defaultLoadAddr=0x2000000
device_partition=0:1
disaMvPnp=no
eeeEnable=no
enaClockGating=no
enaCpuStream=no
enaFPU=yes
enaMonExt=no
enaWrAllo=no
eth1addr=00:50:43:7a:d1:e5
eth1mtu=1500
eth2addr=00:50:43:7a:45:d5
eth2mtu=1500
eth3addr=00:50:43:e1:45:8a
eth3mtu=1500
ethact=egiga0
ethaddr=00:50:43:45:e1:f5
ethmtu=1500
ethprime=egiga0
fdt_addr=2040000
fdt_skip_update=no
fdtaddr=0x1000000
fdtfile=armada-38x-modular.dtb
firmwareName=cobra.img
flash_alt_image=tftpboot $defaultLoadAddr $firmwareName && nand erase $altKernAddr $altFwSize && nand write $defaultLoadAddr $altKernAddr $filesize
flash_pri_image=tftpboot $defaultLoadAddr $firmwareName && nand erase $priKernAddr $priFwSize && nand write $defaultLoadAddr $priKernAddr $filesize
ide_path=/
image_name=uImage
initrd_name=uInitrd
ipaddr=192.168.1.1
kernel_addr_r=2080000
lcd0_enable=0
lcd0_params=640x480-16 at 60
lcd_panel=0
loadaddr=0x02000000
loads_echo=0
mtdids=nand0=armada-nand
mtdparts=mtdparts=armada-nand:2048K(uboot)ro,256K(u_env),256K(s_env),1m at 9m(devinfo),40m at 10m(kernel),34m at 16m(rootfs),40m at 50m(alt_kernel),34m at 56m(alt_rootfs),80m@
10m(ubifs),- at 90m(syscfg)
mvNetConfig=mv_net_config=4,(00:50:43:11:11:11,0:1:2:3),mtu=1500
mv_pon_addr=00:50:43:e5:45:7a
nandEcc=nfcConfig=4bitecc
nandboot=setenv bootargs console=ttyS0,115200 root=/dev/mtdblock5 ro rootdelay=1 rootfstype=jffs2 earlyprintk $mtdparts;nand read $defaultLoadAddr $priKernAddr
$priKernSize; bootm $defaultLoadAddr
netbsd_en=no
netmask=255.255.255.0
netretry=no
pcieTune=no
pexMode=RC
priFwSize=0x2800000
priKernAddr=0x0a00000
priKernSize=0x0600000
pxe_files_load=:default.arm-armadaxp-db:default.arm-armadaxp:default.arm
pxefile_addr_r=3100000
ramdisk_addr_r=2880000
rootpath=/srv/nfs/
sata_delay_reset=0
sata_dma_mode=yes
script_addr_r=3000000
script_name=boot.scr
serverip=192.168.1.254
standalone=fsload 0x2000000 $image_name;setenv bootargs $console $nandEcc $mtdparts root=/dev/mtdblock0 rw ip=$ipaddr:$serverip$bootargs_end; bootm 0x2000000;
stderr=serial
stdin=serial
stdout=serial
update_both_images=tftpboot $defaultLoadAddr $firmwareName && nand erase $priKernAddr $priFwSize && nand erase $altKernAddr $altFwSize && nand write $defaultLoa
dAddr $priKernAddr $filesize && nand write $defaultLoadAddr $altKernAddr $filesize
usb0Mode=host
usbActive=0
usbType=2
vxworks_en=no
yuk_ethaddr=00:00:00:EE:41:71


root at WRT1900ACS:/# strings /dev/mtd1
CASset=max
MALLOC_len=5
MPmode=SMP
altFwSize=0x2800000
altKernAddr=0x3200000
altKernSize=0x0600000
altnandboot=setenv bootargs console=ttyS0,115200 root=/dev/mtdblock7 ro rootdelay=1 rootfstype=jffs2 earlyprintk $mtdparts;nand read $defaultLoadAddr $altKernAd
dr $altKernSize; bootm $defaultLoadAddr
auto_recovery=yes
autoload=no
baudrate=115200
boot_order=hd_scr usb_scr mmc_scr hd_img usb_img mmc_img pxe net_img net_scr
boot_part=1
boot_part_ready=3
bootargs_dflt=$console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_para
ms clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel
bootargs_end=:10.4.50.254:255.255.255.0:Armada38x:eth0:none
bootargs_root=root=/dev/nfs rw
bootcmd=run nandboot
bootcmd_auto=stage_boot $boot_order
bootcmd_fdt=tftpboot 0x2000000 $image_name;tftpboot $fdtaddr $fdtfile;setenv bootargs $console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=
$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel; bootz 0x2000000 - $fdtaddr;
bootcmd_fdt_boot=tftpboot 0x2000000 $image_name; setenv bootargs $console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$boo
targs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel; bootz 0x2000000 - $fdtaddr;
bootcmd_fdt_edit=tftpboot $fdtaddr $fdtfile; fdt addr $fdtaddr; setenv bootcmd $bootcmd_fdt_boot
bootcmd_lgcy=tftpboot 0x2000000 $image_name; setenv bootargs $bootargs_dflt; bootm 0x2000000;
bootdelay=3
cacheShare=no
console=console=ttyS0,115200
defaultLoadAddr=0x2000000
device_partition=0:1
disaMvPnp=no
eeeEnable=no
enaClockGating=no
enaCpuStream=no
enaFPU=yes
enaMonExt=no
enaWrAllo=no
eth1addr=00:50:43:7a:d1:e5
eth1mtu=1500
eth2addr=00:50:43:7a:45:d5
eth2mtu=1500
eth3addr=00:50:43:e1:45:8a
eth3mtu=1500
ethact=egiga0
ethaddr=00:50:43:45:e1:f5
ethmtu=1500
ethprime=egiga0
fdt_addr=2040000
fdt_skip_update=no
fdtaddr=0x1000000
fdtfile=armada-38x-modular.dtb
firmwareName=cobra.img
flash_alt_image=tftpboot $defaultLoadAddr $firmwareName && nand erase $altKernAddr $altFwSize && nand write $defaultLoadAddr $altKernAddr $filesize
flash_pri_image=tftpboot $defaultLoadAddr $firmwareName && nand erase $priKernAddr $priFwSize && nand write $defaultLoadAddr $priKernAddr $filesize
ide_path=/
image_name=uImage
initrd_name=uInitrd
ipaddr=192.168.1.1
kernel_addr_r=2080000
lcd0_enable=0
lcd0_params=640x480-16 at 60
lcd_panel=0
loadaddr=0x02000000
loads_echo=0
mtdids=nand0=armada-nand
mtdparts=mtdparts=armada-nand:2048K(uboot)ro,256K(u_env),256K(s_env),1m at 9m(devinfo),40m at 10m(kernel),34m at 16m(rootfs),40m at 50m(alt_kernel),34m at 56m(alt_rootfs),80m@
10m(ubifs),- at 90m(syscfg)
mvNetConfig=mv_net_config=4,(00:50:43:11:11:11,0:1:2:3),mtu=1500
mv_pon_addr=00:50:43:e5:45:7a
nandEcc=nfcConfig=4bitecc
nandboot=setenv bootargs console=ttyS0,115200 root=/dev/mtdblock5 ro rootdelay=1 rootfstype=jffs2 earlyprintk $mtdparts;nand read $defaultLoadAddr $priKernAddr
$priKernSize; bootm $defaultLoadAddr
netbsd_en=no
netmask=255.255.255.0
netretry=no
pcieTune=no
pexMode=RC
priFwSize=0x2800000
priKernAddr=0x0a00000
priKernSize=0x0600000
pxe_files_load=:default.arm-armadaxp-db:default.arm-armadaxp:default.arm
pxefile_addr_r=3100000
ramdisk_addr_r=2880000
rootpath=/srv/nfs/
sata_delay_reset=0
sata_dma_mode=yes
script_addr_r=3000000
script_name=boot.scr
serverip=192.168.1.254
standalone=fsload 0x2000000 $image_name;setenv bootargs $console $nandEcc $mtdparts root=/dev/mtdblock0 rw ip=$ipaddr:$serverip$bootargs_end; bootm 0x2000000;
stderr=serial
stdin=serial
stdout=serial
update_both_images=tftpboot $defaultLoadAddr $firmwareName && nand erase $priKernAddr $priFwSize && nand erase $altKernAddr $altFwSize && nand write $defaultLoa
dAddr $priKernAddr $filesize && nand write $defaultLoadAddr $altKernAddr $filesize
usb0Mode=host
usbActive=0
usbType=2
vxworks_en=no
yuk_ethaddr=00:00:00:EE:41:71

=======> Step 3: Reboot <======
	After the above procedures, I don?t have the error anymore. Wonder what really caused the problem in first place. Also when we reboot from Failsafe the recovery is automatically triggered - is this normal. One more doubt would be, should 'env reset' be in this order. 

resetenv ??> reset ??> printing ??> saveenv ??> reset

	I am building from the current git, will flash that and see if after the flash - the error occurs or not.

Thank you, very much? I have been trying to solve this for about 3 weeks. Now I can keep lede and won?t have to flash stock when I leave for work.

Regards 
Dheeran senthilvel  
 
> On 07-Jun-2016, at 7:40 PM, Claudio Leite <leitec at gmail.com> wrote:
> 
> Thanks for the clear output.
> 
> * Dheeran Senthilvel (dheeranmech at gmail.com) wrote:
> [snip]
>> =======> Step 3: Intrupt boot into failsafe <=======
>> 
>> Press the [f] key and hit [enter] to enter failsafe mode
>> Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
>> f
>> - failsafe -
>> [    4.986830] random: dropbearkey urandom read with 121 bits of entropy available
> [snip]
>> root@(none):/# strings /dev/mtd1
>> [   44.008437] random: nonblocking pool is initialized
> 
> OK, this is definitely not right. It should be a long list of variables.
> 
>> =======> Step 4: Reboot <=======
> 
>> *** Warning - bad CRC, using default environment
> 
> again not right. this should have been cleared up the first time booting
> after resetenv erased the old settings:
> 
>> 
>> S-ENV offset == 0x240000
>> 
>> 
>> #### auto_recovery ####
>> [u_env] get auto_recovery == yes
>> [u_env] get auto_recovery == yes
>> [u_env] get boot_part == 1
>> [u_env] get boot_part_ready == 3
>> auto_recovery enabled:1, boot_part:1, boot_part_ready:3
> 
> This bit looks OK, though.
> 
> I'm a little confused because I thought after resetenv and a reset the
> bootloader would actually write the default values to flash. This may
> not have happened here, since mtd1 is empty. I think it's fairly safe
> to say reads from NAND are OK, since otherwise you would get lots of
> errors when booting the system.
> 
> So, one more test, again trying to clear and reset the u-boot
> environment:
> 
> (these are all u-boot commands)
> 
> resetenv; reset
> 
> <interrupt boot>
> printenv
> 
> if the default values are there, then do
> 
> saveenv
> reset
> 
> and interrupt the boot again and run 'printenv'. Are they there?
> 
> -Claudio



From leitec at gmail.com  Tue Jun  7 08:00:41 2016
From: leitec at gmail.com (Claudio Leite)
Date: Tue, 7 Jun 2016 11:00:41 -0400
Subject: [LEDE-DEV] WRT1900ACS - Kernel 4.4.12 boot failure
In-Reply-To: <7B57CB2B-38DF-4A68-88FC-9F5D26CF6917@gmail.com>
References: <9BD7CD08-6799-4FF0-B8FA-380AFF42B5AA@gmail.com>
 <64E9BFC2-B9F1-4AAE-B799-0435B3091E41@gmail.com>
 <A5192BCC-101B-487A-913B-B3DA7A88C5DB@gmail.com>
 <F013F569-4F7F-4903-9F8E-F29FA6599A8F@gmail.com>
 <20160607095751.GA29607@pratt.mine.nu>
 <CAJe1gWKTkiEGh+j6ay_13+MuRGTvLEFAynB1dUiBJCc+r9ch1A@mail.gmail.com>
 <20160607102408.GB29607@pratt.mine.nu>
 <F1CDD9DC-2F03-412F-81DC-4C3318E489C9@gmail.com>
 <20160607133306.GC29607@pratt.mine.nu>
 <6374F1F4-5A5F-4576-B43C-C65991C6E920@gmail.com>
 <20160607141039.GD29607@pratt.mine.nu>
 <7B57CB2B-38DF-4A68-88FC-9F5D26CF6917@gmail.com>
Message-ID: <5756E199.40300@gmail.com>

On 06/07/2016 10:48 AM, Dheeran Senthilvel wrote:
[snip]
> =======> Step 3: Reboot <======
> 	After the above procedures, I don?t have the error anymore.

Great -- so you're all set, as far as you can tell?

> Wonder what really caused the problem in first place.

Given the date when you initially had the issue I suspected that it was 
due to bugs in the NAND driver that potentially messed things up in your 
u_env. I would have expected 'resetenv' to make quick work of cleaning 
that up.

It sort of looks like resetenv only half-cleared the problem. At least 
on the other model I tested it on it claims to erase the partition. 
Something goes wrong at some point here on your model and the old 
corrupted data was kept. 'saveenv' forces rewriting the good data back 
to flash.

 > Also when we reboot from Failsafe the recovery is automatically 
triggered - is this normal.

Failsafe won't reset the failed boot counter, so if it's gone more than 
three times since the last successful boot it will indeed trigger 
auto-recovery.

> One more doubt would be, should 'env reset' be in this order.
> resetenv ??> reset ??> printing ??> saveenv ??> reset

'printenv' is just a check. I would say

   resetenv; reset

followed by a reboot, and

   saveenv; reset

(or even saveenv; boot)

should be sufficient.

-Claudio


From leitec at gmail.com  Tue Jun  7 08:07:12 2016
From: leitec at gmail.com (Claudio Leite)
Date: Tue, 7 Jun 2016 11:07:12 -0400
Subject: [LEDE-DEV] WRT1900ACS - Kernel 4.4.12 boot failure
In-Reply-To: <5756E199.40300@gmail.com>
References: <9BD7CD08-6799-4FF0-B8FA-380AFF42B5AA@gmail.com>
 <64E9BFC2-B9F1-4AAE-B799-0435B3091E41@gmail.com>
 <A5192BCC-101B-487A-913B-B3DA7A88C5DB@gmail.com>
 <F013F569-4F7F-4903-9F8E-F29FA6599A8F@gmail.com>
 <20160607095751.GA29607@pratt.mine.nu>
 <CAJe1gWKTkiEGh+j6ay_13+MuRGTvLEFAynB1dUiBJCc+r9ch1A@mail.gmail.com>
 <20160607102408.GB29607@pratt.mine.nu>
 <F1CDD9DC-2F03-412F-81DC-4C3318E489C9@gmail.com>
 <20160607133306.GC29607@pratt.mine.nu>
 <6374F1F4-5A5F-4576-B43C-C65991C6E920@gmail.com>
 <20160607141039.GD29607@pratt.mine.nu>
 <7B57CB2B-38DF-4A68-88FC-9F5D26CF6917@gmail.com> <5756E199.40300@gmail.com>
Message-ID: <5756E320.7090703@gmail.com>

On 06/07/2016 11:00 AM, Claudio Leite wrote:
> On 06/07/2016 10:48 AM, Dheeran Senthilvel wrote:
> [snip]
>> =======> Step 3: Reboot <======
>>     After the above procedures, I don?t have the error anymore.
>
> Great -- so you're all set, as far as you can tell?
>
>> Wonder what really caused the problem in first place.
>
> Given the date when you initially had the issue I suspected that it was
> due to bugs in the NAND driver that potentially messed things up in your
> u_env. I would have expected 'resetenv' to make quick work of cleaning
> that up.
>
> It sort of looks like resetenv only half-cleared the problem. At least
> on the other model I tested it on it claims to erase the partition.
> Something goes wrong at some point here on your model and the old
> corrupted data was kept. 'saveenv' forces rewriting the good data back
> to flash.

Responding to myself -- it looks like the "corruption" from u-boot I 
thought was going on was just the defaults from uboot-envtools. 
fw_setenv, when trying to write the 'auto_recovery=yes' value during 
boot, was committing these to the then-empty flash partition.

root at wrt1900ac:/tmp# mtd erase u_env
Unlocking u_env ...
Erasing u_env ...
root at wrt1900ac:/tmp# fw_printenv
Warning: Bad CRC, using default environment
bootcmd=bootp; setenv bootargs root=/dev/nfs 
nfsroot=${serverip}:${rootpath} 
ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm
bootdelay=5
baudrate=115200
root at wrt1900ac:/tmp# fw_setenv test blah
Warning: Bad CRC, using default environment
root at wrt1900ac:/tmp# fw_printenv
bootcmd=bootp; setenv bootargs root=/dev/nfs 
nfsroot=${serverip}:${rootpath} 
ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm
bootdelay=5
baudrate=115200
test=blah
root at wrt1900ac:/tmp#

So, no corruption at all. The bootloader resetenv just didn't commit the 
default values back to flash.

-Claudio


From drew at nixcores.com  Tue Jun  7 11:47:07 2016
From: drew at nixcores.com (Drew from NixCore)
Date: Tue, 7 Jun 2016 12:47:07 -0600
Subject: [LEDE-DEV] [PATCH] [ramips] Added NixCore X1 target V2
In-Reply-To: <c1c05543-6b19-d94f-7feb-ef0802908090@phrozen.org>
References: <5756126C.5060101@nixcores.com>
 <c1c05543-6b19-d94f-7feb-ef0802908090@phrozen.org>
Message-ID: <575716AB.5020207@nixcores.com>

John,

This target was built for OpenWRT CC so the dts matches that format.  I 
am not very familiar with the dts format, can you provide a resource to 
get up to speed on the latest format?

This is a board with the RT5350 SOC, very similar to other boards 
supported.  The dts has some settings specific to this board rather than 
others.

Thanks,

Drew

On 06/06/2016 11:12 PM, John Crispin wrote:
> Hi Drew,
>
> this patch seems to use the old devicetree layout and image building
> code. do you think you could rebase this and make it work ontop of
> latest source.git or do you need help to do that ? this patch wont apply
> as is.
>
> another question, did you build this yourself or is this a rebranded
> whitelabel product ? i think we already support this board (or one that
> looks almost identical, need to see if i can find it in my router zoo today)
>
> 	John
>
> On 07/06/2016 02:16, Drew from NixCore wrote:
>> Added NixCore X1 ramips target http://nixcores.com. This builds 8M and 16M
>> images
>>
>> Signed-off-by: Drew Gaylo <drew at nixcores.com>
>> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
>> b/target/linux/ramips/base-files/etc/board.d/02_network
>> index 4728c75..69c0125 100755
>> --- a/target/linux/ramips/base-files/etc/board.d/02_network
>> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
>> @@ -77,6 +77,7 @@ ramips_setup_interfaces()
>>       mt7628|\
>>       mzk-750dhp|\
>>       mzk-w300nh2|\
>> +    nixcore|\
>>       oy-0001|\
>>       pbr-m1|\
>>       psg1208|\
>> diff --git a/target/linux/ramips/base-files/lib/ramips.sh
>> b/target/linux/ramips/base-files/lib/ramips.sh
>> index cbe455d..76f0e43 100755
>> --- a/target/linux/ramips/base-files/lib/ramips.sh
>> +++ b/target/linux/ramips/base-files/lib/ramips.sh
>> @@ -316,6 +316,9 @@ ramips_board_detect() {
>>       *"NCS601W")
>>           name="ncs601w"
>>           ;;
>> +    *"NixcoreX1")
>> +        name="nixcore-x1"
>> +        ;;
>>       *"NW718")
>>           name="nw718"
>>           ;;
>> diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh
>> b/target/linux/ramips/base-files/lib/upgrade/platform.sh
>> index 91c9997..0094568 100755
>> --- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
>> +++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
>> @@ -94,6 +94,7 @@ platform_check_image() {
>>       mzk-w300nh2|\
>>       mzk-wdpr|\
>>       nbg-419n|\
>> +    nixcore|\
>>       nw718|\
>>       oy-0001|\
>>       pbr-m1|\
>> diff --git a/target/linux/ramips/dts/NIXCOREX1-16M.dts
>> b/target/linux/ramips/dts/NIXCOREX1-16M.dts
>> new file mode 100644
>> index 0000000..c7ec410
>> --- /dev/null
>> +++ b/target/linux/ramips/dts/NIXCOREX1-16M.dts
>> @@ -0,0 +1,186 @@
>> +/dts-v1/;
>> +
>> +/include/ "rt5350.dtsi"
>> +
>> +/ {
>> +    compatible = "NixcoreX1", "ralink,rt5350-soc";
>> +    model = "NixcoreX1";
>> +
>> +    palmbus at 10000000 {
>> +        /* Re-enable the gpio1 ports */
>> +        gpio1: gpio at 660 {
>> +            status = "okay";
>> +        };
>> +
>> +        i2c at 900 {
>> +            status = "okay";
>> +        };
>> +        uart at 500 {
>> +            status = "okay";
>> +            /* Mix of uart and gpio */
>> +            reset-names = "gpio uartf";
>> +        };
>> +        spi at b00 {
>> +            status = "okay";
>> +
>> +            m25p80 at 0 {
>> +                #address-cells = <1>;
>> +                #size-cells = <1>;
>> +                compatible = "s25fl064k";
>> +                reg = <0>;
>> +                linux,modalias = "m25p80", "s25fl064k";
>> +                spi-max-frequency = <10000000>;
>> +
>> +                partition at 0 {
>> +                    label = "uboot";
>> +                    reg = <0x0 0x30000>;
>> +                    read-only;
>> +                };
>> +
>> +                partition at 30000 {
>> +                    label = "uboot-env";
>> +                    reg = <0x30000 0x10000>;
>> +                    read-only;
>> +                };
>> +
>> +                factory: partition at 40000 {
>> +                    label = "factory";
>> +                    reg = <0x40000 0x10000>;
>> +                    read-only;
>> +                };
>> +
>> +                partition at 50000 {
>> +                    label = "firmware";
>> +                    reg = <0x50000 0x7b0000>;
>> +                };
>> +            };
>> +
>> +            spidev at 1 {
>> +                compatible = "linux,spidev";
>> +                spi-max-frequency = <10000000>;
>> +                reg = <1>;
>> +            };
>> +        };
>> +    };
>> +
>> +    pinctrl {
>> +        state_default: pinctrl0 {
>> +            gpio {
>> +                /* Associate the tjag, uartf and led groups with gpio */
>> +                ralink,group = "jtag", "led", "spi_cs1";
>> +                /* How do we set individual pins? */
>> +                ralink,function = "gpio";
>> +            };
>> +        };
>> +    };
>> +
>> +    ethernet at 10100000 {
>> +        mtd-mac-address = <&factory 0x4>;
>> +    };
>> +
>> +    esw at 10110000 {
>> +        ralink,portmap = <0x17>;
>> +    };
>> +
>> +    wmac at 10180000 {
>> +        ralink,mtd-eeprom = <&factory 0>;
>> +    };
>> +
>> +    ehci at 101c0000 {
>> +        status = "okay";
>> +    };
>> +
>> +    ohci at 101c1000 {
>> +        status = "okay";
>> +    };
>> +
>> +    chosen {
>> +        bootargs = "console=ttyS1,57600";
>> +    };
>> +    gpio-export {
>> +        compatible = "gpio-export";
>> +        #size-cells = <0>;
>> +
>> +        gpio0 {
>> +            gpio-export,name = "gpio0";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 0 0>;
>> +        };
>> +
>> +        /* GPIOs 1-6 are I2C,SPI */
>> +
>> +        /* GPIO 7-14 are uart1 */
>> +
>> +        /* GPIOs 15 & 16 are uart2 */
>> +
>> +        /* JTAG */
>> +        gpio17 {
>> +            /* JTAG_TDO */
>> +            gpio-export,name = "gpio17";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 17 0>;
>> +        };
>> +        gpio18 {
>> +            /* JTAG_TDI */
>> +            gpio-export,name = "gpio18";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 18 0>;
>> +        };
>> +        gpio19 {
>> +            /* JTAG_TMS */
>> +            gpio-export,name = "gpio19";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 19 0>;
>> +        };
>> +        gpio20 {
>> +            /* JTAG_TCLK */
>> +            gpio-export,name = "gpio20";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 20 0>;
>> +        };
>> +        gpio21 {
>> +            /* JTAG_TRST_N */
>> +            gpio-export,name = "gpio21";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 21 0>;
>> +        };
>> +
>> +        /* ETH LEDs */
>> +        /*
>> +        gpio22 {
>> +            gpio-export,name = "gpio22";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 0 0>;
>> +        };
>> +        gpio23 {
>> +            gpio-export,name = "gpio23";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 1 0>;
>> +        };
>> +        gpio24 {
>> +            gpio-export,name = "gpio24";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 2 0>;
>> +        };
>> +        gpio25 {
>> +            gpio-export,name = "gpio25";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 3 0>;
>> +        };
>> +        */
>> +        gpio26 {
>> +            /* ETH4_LED */
>> +            gpio-export,name = "gpio26";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 4 0>;
>> +        };
>> +
>> +        gpio27 {
>> +            /* spi_cs1 */
>> +            gpio-export,name = "gpio27";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 5 0>;
>> +        };
>> +    };
>> +
>> +};
>> diff --git a/target/linux/ramips/dts/NIXCOREX1-8M.dts
>> b/target/linux/ramips/dts/NIXCOREX1-8M.dts
>> new file mode 100644
>> index 0000000..c7ec410
>> --- /dev/null
>> +++ b/target/linux/ramips/dts/NIXCOREX1-8M.dts
>> @@ -0,0 +1,186 @@
>> +/dts-v1/;
>> +
>> +/include/ "rt5350.dtsi"
>> +
>> +/ {
>> +    compatible = "NixcoreX1", "ralink,rt5350-soc";
>> +    model = "NixcoreX1";
>> +
>> +    palmbus at 10000000 {
>> +        /* Re-enable the gpio1 ports */
>> +        gpio1: gpio at 660 {
>> +            status = "okay";
>> +        };
>> +
>> +        i2c at 900 {
>> +            status = "okay";
>> +        };
>> +        uart at 500 {
>> +            status = "okay";
>> +            /* Mix of uart and gpio */
>> +            reset-names = "gpio uartf";
>> +        };
>> +        spi at b00 {
>> +            status = "okay";
>> +
>> +            m25p80 at 0 {
>> +                #address-cells = <1>;
>> +                #size-cells = <1>;
>> +                compatible = "s25fl064k";
>> +                reg = <0>;
>> +                linux,modalias = "m25p80", "s25fl064k";
>> +                spi-max-frequency = <10000000>;
>> +
>> +                partition at 0 {
>> +                    label = "uboot";
>> +                    reg = <0x0 0x30000>;
>> +                    read-only;
>> +                };
>> +
>> +                partition at 30000 {
>> +                    label = "uboot-env";
>> +                    reg = <0x30000 0x10000>;
>> +                    read-only;
>> +                };
>> +
>> +                factory: partition at 40000 {
>> +                    label = "factory";
>> +                    reg = <0x40000 0x10000>;
>> +                    read-only;
>> +                };
>> +
>> +                partition at 50000 {
>> +                    label = "firmware";
>> +                    reg = <0x50000 0x7b0000>;
>> +                };
>> +            };
>> +
>> +            spidev at 1 {
>> +                compatible = "linux,spidev";
>> +                spi-max-frequency = <10000000>;
>> +                reg = <1>;
>> +            };
>> +        };
>> +    };
>> +
>> +    pinctrl {
>> +        state_default: pinctrl0 {
>> +            gpio {
>> +                /* Associate the tjag, uartf and led groups with gpio */
>> +                ralink,group = "jtag", "led", "spi_cs1";
>> +                /* How do we set individual pins? */
>> +                ralink,function = "gpio";
>> +            };
>> +        };
>> +    };
>> +
>> +    ethernet at 10100000 {
>> +        mtd-mac-address = <&factory 0x4>;
>> +    };
>> +
>> +    esw at 10110000 {
>> +        ralink,portmap = <0x17>;
>> +    };
>> +
>> +    wmac at 10180000 {
>> +        ralink,mtd-eeprom = <&factory 0>;
>> +    };
>> +
>> +    ehci at 101c0000 {
>> +        status = "okay";
>> +    };
>> +
>> +    ohci at 101c1000 {
>> +        status = "okay";
>> +    };
>> +
>> +    chosen {
>> +        bootargs = "console=ttyS1,57600";
>> +    };
>> +    gpio-export {
>> +        compatible = "gpio-export";
>> +        #size-cells = <0>;
>> +
>> +        gpio0 {
>> +            gpio-export,name = "gpio0";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 0 0>;
>> +        };
>> +
>> +        /* GPIOs 1-6 are I2C,SPI */
>> +
>> +        /* GPIO 7-14 are uart1 */
>> +
>> +        /* GPIOs 15 & 16 are uart2 */
>> +
>> +        /* JTAG */
>> +        gpio17 {
>> +            /* JTAG_TDO */
>> +            gpio-export,name = "gpio17";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 17 0>;
>> +        };
>> +        gpio18 {
>> +            /* JTAG_TDI */
>> +            gpio-export,name = "gpio18";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 18 0>;
>> +        };
>> +        gpio19 {
>> +            /* JTAG_TMS */
>> +            gpio-export,name = "gpio19";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 19 0>;
>> +        };
>> +        gpio20 {
>> +            /* JTAG_TCLK */
>> +            gpio-export,name = "gpio20";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 20 0>;
>> +        };
>> +        gpio21 {
>> +            /* JTAG_TRST_N */
>> +            gpio-export,name = "gpio21";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 21 0>;
>> +        };
>> +
>> +        /* ETH LEDs */
>> +        /*
>> +        gpio22 {
>> +            gpio-export,name = "gpio22";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 0 0>;
>> +        };
>> +        gpio23 {
>> +            gpio-export,name = "gpio23";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 1 0>;
>> +        };
>> +        gpio24 {
>> +            gpio-export,name = "gpio24";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 2 0>;
>> +        };
>> +        gpio25 {
>> +            gpio-export,name = "gpio25";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 3 0>;
>> +        };
>> +        */
>> +        gpio26 {
>> +            /* ETH4_LED */
>> +            gpio-export,name = "gpio26";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 4 0>;
>> +        };
>> +
>> +        gpio27 {
>> +            /* spi_cs1 */
>> +            gpio-export,name = "gpio27";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 5 0>;
>> +        };
>> +    };
>> +
>> +};
>> diff --git a/target/linux/ramips/image/rt305x.mk
>> b/target/linux/ramips/image/rt305x.mk
>> index da7fc46..db12a8e 100644
>> --- a/target/linux/ramips/image/rt305x.mk
>> +++ b/target/linux/ramips/image/rt305x.mk
>> @@ -100,6 +100,21 @@ define BuildFirmware/HLKRM04/initramfs
>>       mkhilinkfw -e -i$(call imgname,$(1),$(2))-uImage.bin -o $(call
>> imgname,$(1),$(2))-factory.bin;
>>   endef
>>
>> +# This is called to build the nixcore image.  Build both 8MB and 16MB
>> +nixcore_8mb_mtd_size=8060928
>> +nixcore_16mb_mtd_size=16449536
>> +define BuildFirmware/NIXCOREX1/squashfs
>> +# Args are XXX, nixcore-mM and NIXCOREX1-xM
>> +    $(call
>> BuildFirmware/CustomFlash/$(1),$(1),$(2)-8M,$(3)-8M,$(nixcore_8mb_mtd_size))
>>
>> +    $(call
>> BuildFirmware/CustomFlash/$(1),$(1),$(2)-16M,$(3)-16M,$(nixcore_16mb_mtd_size))
>>
>> +    # Can do somethings here after the build?
>> +endef
>> +define BuildFirmware/NIXCOREX1/initramfs
>> +# Args are XXXX, nixcore-mM and NIXCOREX1-xM
>> +    $(call BuildFirmware/OF/initramfs,$(1),$(2)-8M,$(3)-8M)
>> +    $(call BuildFirmware/OF/initramfs,$(1),$(2)-16M,$(3)-16M)
>> +endef
>> +
>>   vocore_8mb_mtd_size=8060928
>>   vocore_16mb_mtd_size=16449536
>>   define BuildFirmware/VOCORE/squashfs
>> @@ -257,6 +272,7 @@ Image/Build/Profile/NBG-419N=$(call
>> BuildFirmware/Default4M/$(1),$(1),nbg-419n,N
>>   Image/Build/Profile/MZKW300NH2=$(call
>> BuildFirmware/Edimax/$(1),$(1),mzk-w300nh2,MZK-W300NH2,$(mzkw300nh2_mtd_size),CSYS,RN52,0x50000,0xc0000)
>>
>>   Image/Build/Profile/MZKWDPR=$(call
>> BuildFirmware/Default8M/$(1),$(1),mzk-wdpr,MZK-WDPR)
>>   Image/Build/Profile/NCS601W=$(call
>> BuildFirmware/Default8M/$(1),$(1),ncs601W,NCS601W)
>> +Image/Build/Profile/NIXCOREX1=$(call
>> BuildFirmware/NIXCOREX1/$(1),$(1),nixcorex1,NIXCOREX1)
>>   nw718_mtd_size=3801088
>>   Image/Build/Profile/NW718=$(call
>> BuildFirmware/CustomFlashFactory/$(1),$(1),nw718m,NW718,$(nw718_mtd_size),ARA1B4NCRNW718;1,factory)
>>
>>   Image/Build/Profile/M2M=$(call
>> BuildFirmware/Default8M/$(1),$(1),m2m,M2M,Linux Kernel Image)
>> @@ -353,6 +369,7 @@ define Image/Build/Profile/Default
>>       $(call Image/Build/Profile/MZKWDPR,$(1))
>>       $(call Image/Build/Profile/NBG-419N,$(1))
>>       $(call Image/Build/Profile/NCS601W,$(1))
>> +    $(call Image/Build/Profile/NIXCOREX1,$(1))
>>       $(call Image/Build/Profile/NW718,$(1))
>>       $(call Image/Build/Profile/MINIEMBWIFI,$(1))
>>       $(call Image/Build/Profile/MINIEMBPLUG,$(1))
>> diff --git a/target/linux/ramips/rt305x/profiles/nixcore.mk
>> b/target/linux/ramips/rt305x/profiles/nixcore.mk
>> new file mode 100644
>> index 0000000..22dee9b
>> --- /dev/null
>> +++ b/target/linux/ramips/rt305x/profiles/nixcore.mk
>> @@ -0,0 +1,20 @@
>> +#
>> +# Copyright (C) 2014 OpenWrt.org
>> +#
>> +# This is free software, licensed under the GNU General Public License v2.
>> +# See /LICENSE for more information.
>> +#
>> +
>> +define Profile/NIXCOREX1
>> +    NAME:=NixcoreX1
>> +    PACKAGES:=\
>> +        kmod-usb-core kmod-usb-ohci kmod-usb2 \
>> +        kmod-i2c-core kmod-i2c-ralink \
>> +        kmod-spi-dev
>> +endef
>> +
>> +define Profile/NIXCOREX1/Description
>> +    Package set for Nixcore X1 board
>> +endef
>> +
>> +$(eval $(call Profile,NIXCOREX1))
>>
>>
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev



From drew at nixcores.com  Tue Jun  7 12:13:35 2016
From: drew at nixcores.com (Drew from NixCore)
Date: Tue, 7 Jun 2016 13:13:35 -0600
Subject: [LEDE-DEV] [PATCH] [ramips] Added NixCore X1 target V2
In-Reply-To: <c1c05543-6b19-d94f-7feb-ef0802908090@phrozen.org>
References: <5756126C.5060101@nixcores.com>
 <c1c05543-6b19-d94f-7feb-ef0802908090@phrozen.org>
Message-ID: <57571CDF.8070205@nixcores.com>

John,

I took a look at the dtsi file and see how the dts is updating the 
settings.  I have
a dts that builds, but I would like a sanity check before submitting the 
patch again.

http://pastebin.com/EunNmAf4

If this looks good I will update the 16M DTS and then submit again.

Thanks,

Drew

On 06/06/2016 11:12 PM, John Crispin wrote:
> Hi Drew,
>
> this patch seems to use the old devicetree layout and image building
> code. do you think you could rebase this and make it work ontop of
> latest source.git or do you need help to do that ? this patch wont apply
> as is.
>
> another question, did you build this yourself or is this a rebranded
> whitelabel product ? i think we already support this board (or one that
> looks almost identical, need to see if i can find it in my router zoo today)
>
> 	John
>
> On 07/06/2016 02:16, Drew from NixCore wrote:
>> Added NixCore X1 ramips target http://nixcores.com. This builds 8M and 16M
>> images
>>
>> Signed-off-by: Drew Gaylo <drew at nixcores.com>
>> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
>> b/target/linux/ramips/base-files/etc/board.d/02_network
>> index 4728c75..69c0125 100755
>> --- a/target/linux/ramips/base-files/etc/board.d/02_network
>> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
>> @@ -77,6 +77,7 @@ ramips_setup_interfaces()
>>       mt7628|\
>>       mzk-750dhp|\
>>       mzk-w300nh2|\
>> +    nixcore|\
>>       oy-0001|\
>>       pbr-m1|\
>>       psg1208|\
>> diff --git a/target/linux/ramips/base-files/lib/ramips.sh
>> b/target/linux/ramips/base-files/lib/ramips.sh
>> index cbe455d..76f0e43 100755
>> --- a/target/linux/ramips/base-files/lib/ramips.sh
>> +++ b/target/linux/ramips/base-files/lib/ramips.sh
>> @@ -316,6 +316,9 @@ ramips_board_detect() {
>>       *"NCS601W")
>>           name="ncs601w"
>>           ;;
>> +    *"NixcoreX1")
>> +        name="nixcore-x1"
>> +        ;;
>>       *"NW718")
>>           name="nw718"
>>           ;;
>> diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh
>> b/target/linux/ramips/base-files/lib/upgrade/platform.sh
>> index 91c9997..0094568 100755
>> --- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
>> +++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
>> @@ -94,6 +94,7 @@ platform_check_image() {
>>       mzk-w300nh2|\
>>       mzk-wdpr|\
>>       nbg-419n|\
>> +    nixcore|\
>>       nw718|\
>>       oy-0001|\
>>       pbr-m1|\
>> diff --git a/target/linux/ramips/dts/NIXCOREX1-16M.dts
>> b/target/linux/ramips/dts/NIXCOREX1-16M.dts
>> new file mode 100644
>> index 0000000..c7ec410
>> --- /dev/null
>> +++ b/target/linux/ramips/dts/NIXCOREX1-16M.dts
>> @@ -0,0 +1,186 @@
>> +/dts-v1/;
>> +
>> +/include/ "rt5350.dtsi"
>> +
>> +/ {
>> +    compatible = "NixcoreX1", "ralink,rt5350-soc";
>> +    model = "NixcoreX1";
>> +
>> +    palmbus at 10000000 {
>> +        /* Re-enable the gpio1 ports */
>> +        gpio1: gpio at 660 {
>> +            status = "okay";
>> +        };
>> +
>> +        i2c at 900 {
>> +            status = "okay";
>> +        };
>> +        uart at 500 {
>> +            status = "okay";
>> +            /* Mix of uart and gpio */
>> +            reset-names = "gpio uartf";
>> +        };
>> +        spi at b00 {
>> +            status = "okay";
>> +
>> +            m25p80 at 0 {
>> +                #address-cells = <1>;
>> +                #size-cells = <1>;
>> +                compatible = "s25fl064k";
>> +                reg = <0>;
>> +                linux,modalias = "m25p80", "s25fl064k";
>> +                spi-max-frequency = <10000000>;
>> +
>> +                partition at 0 {
>> +                    label = "uboot";
>> +                    reg = <0x0 0x30000>;
>> +                    read-only;
>> +                };
>> +
>> +                partition at 30000 {
>> +                    label = "uboot-env";
>> +                    reg = <0x30000 0x10000>;
>> +                    read-only;
>> +                };
>> +
>> +                factory: partition at 40000 {
>> +                    label = "factory";
>> +                    reg = <0x40000 0x10000>;
>> +                    read-only;
>> +                };
>> +
>> +                partition at 50000 {
>> +                    label = "firmware";
>> +                    reg = <0x50000 0x7b0000>;
>> +                };
>> +            };
>> +
>> +            spidev at 1 {
>> +                compatible = "linux,spidev";
>> +                spi-max-frequency = <10000000>;
>> +                reg = <1>;
>> +            };
>> +        };
>> +    };
>> +
>> +    pinctrl {
>> +        state_default: pinctrl0 {
>> +            gpio {
>> +                /* Associate the tjag, uartf and led groups with gpio */
>> +                ralink,group = "jtag", "led", "spi_cs1";
>> +                /* How do we set individual pins? */
>> +                ralink,function = "gpio";
>> +            };
>> +        };
>> +    };
>> +
>> +    ethernet at 10100000 {
>> +        mtd-mac-address = <&factory 0x4>;
>> +    };
>> +
>> +    esw at 10110000 {
>> +        ralink,portmap = <0x17>;
>> +    };
>> +
>> +    wmac at 10180000 {
>> +        ralink,mtd-eeprom = <&factory 0>;
>> +    };
>> +
>> +    ehci at 101c0000 {
>> +        status = "okay";
>> +    };
>> +
>> +    ohci at 101c1000 {
>> +        status = "okay";
>> +    };
>> +
>> +    chosen {
>> +        bootargs = "console=ttyS1,57600";
>> +    };
>> +    gpio-export {
>> +        compatible = "gpio-export";
>> +        #size-cells = <0>;
>> +
>> +        gpio0 {
>> +            gpio-export,name = "gpio0";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 0 0>;
>> +        };
>> +
>> +        /* GPIOs 1-6 are I2C,SPI */
>> +
>> +        /* GPIO 7-14 are uart1 */
>> +
>> +        /* GPIOs 15 & 16 are uart2 */
>> +
>> +        /* JTAG */
>> +        gpio17 {
>> +            /* JTAG_TDO */
>> +            gpio-export,name = "gpio17";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 17 0>;
>> +        };
>> +        gpio18 {
>> +            /* JTAG_TDI */
>> +            gpio-export,name = "gpio18";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 18 0>;
>> +        };
>> +        gpio19 {
>> +            /* JTAG_TMS */
>> +            gpio-export,name = "gpio19";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 19 0>;
>> +        };
>> +        gpio20 {
>> +            /* JTAG_TCLK */
>> +            gpio-export,name = "gpio20";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 20 0>;
>> +        };
>> +        gpio21 {
>> +            /* JTAG_TRST_N */
>> +            gpio-export,name = "gpio21";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 21 0>;
>> +        };
>> +
>> +        /* ETH LEDs */
>> +        /*
>> +        gpio22 {
>> +            gpio-export,name = "gpio22";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 0 0>;
>> +        };
>> +        gpio23 {
>> +            gpio-export,name = "gpio23";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 1 0>;
>> +        };
>> +        gpio24 {
>> +            gpio-export,name = "gpio24";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 2 0>;
>> +        };
>> +        gpio25 {
>> +            gpio-export,name = "gpio25";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 3 0>;
>> +        };
>> +        */
>> +        gpio26 {
>> +            /* ETH4_LED */
>> +            gpio-export,name = "gpio26";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 4 0>;
>> +        };
>> +
>> +        gpio27 {
>> +            /* spi_cs1 */
>> +            gpio-export,name = "gpio27";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 5 0>;
>> +        };
>> +    };
>> +
>> +};
>> diff --git a/target/linux/ramips/dts/NIXCOREX1-8M.dts
>> b/target/linux/ramips/dts/NIXCOREX1-8M.dts
>> new file mode 100644
>> index 0000000..c7ec410
>> --- /dev/null
>> +++ b/target/linux/ramips/dts/NIXCOREX1-8M.dts
>> @@ -0,0 +1,186 @@
>> +/dts-v1/;
>> +
>> +/include/ "rt5350.dtsi"
>> +
>> +/ {
>> +    compatible = "NixcoreX1", "ralink,rt5350-soc";
>> +    model = "NixcoreX1";
>> +
>> +    palmbus at 10000000 {
>> +        /* Re-enable the gpio1 ports */
>> +        gpio1: gpio at 660 {
>> +            status = "okay";
>> +        };
>> +
>> +        i2c at 900 {
>> +            status = "okay";
>> +        };
>> +        uart at 500 {
>> +            status = "okay";
>> +            /* Mix of uart and gpio */
>> +            reset-names = "gpio uartf";
>> +        };
>> +        spi at b00 {
>> +            status = "okay";
>> +
>> +            m25p80 at 0 {
>> +                #address-cells = <1>;
>> +                #size-cells = <1>;
>> +                compatible = "s25fl064k";
>> +                reg = <0>;
>> +                linux,modalias = "m25p80", "s25fl064k";
>> +                spi-max-frequency = <10000000>;
>> +
>> +                partition at 0 {
>> +                    label = "uboot";
>> +                    reg = <0x0 0x30000>;
>> +                    read-only;
>> +                };
>> +
>> +                partition at 30000 {
>> +                    label = "uboot-env";
>> +                    reg = <0x30000 0x10000>;
>> +                    read-only;
>> +                };
>> +
>> +                factory: partition at 40000 {
>> +                    label = "factory";
>> +                    reg = <0x40000 0x10000>;
>> +                    read-only;
>> +                };
>> +
>> +                partition at 50000 {
>> +                    label = "firmware";
>> +                    reg = <0x50000 0x7b0000>;
>> +                };
>> +            };
>> +
>> +            spidev at 1 {
>> +                compatible = "linux,spidev";
>> +                spi-max-frequency = <10000000>;
>> +                reg = <1>;
>> +            };
>> +        };
>> +    };
>> +
>> +    pinctrl {
>> +        state_default: pinctrl0 {
>> +            gpio {
>> +                /* Associate the tjag, uartf and led groups with gpio */
>> +                ralink,group = "jtag", "led", "spi_cs1";
>> +                /* How do we set individual pins? */
>> +                ralink,function = "gpio";
>> +            };
>> +        };
>> +    };
>> +
>> +    ethernet at 10100000 {
>> +        mtd-mac-address = <&factory 0x4>;
>> +    };
>> +
>> +    esw at 10110000 {
>> +        ralink,portmap = <0x17>;
>> +    };
>> +
>> +    wmac at 10180000 {
>> +        ralink,mtd-eeprom = <&factory 0>;
>> +    };
>> +
>> +    ehci at 101c0000 {
>> +        status = "okay";
>> +    };
>> +
>> +    ohci at 101c1000 {
>> +        status = "okay";
>> +    };
>> +
>> +    chosen {
>> +        bootargs = "console=ttyS1,57600";
>> +    };
>> +    gpio-export {
>> +        compatible = "gpio-export";
>> +        #size-cells = <0>;
>> +
>> +        gpio0 {
>> +            gpio-export,name = "gpio0";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 0 0>;
>> +        };
>> +
>> +        /* GPIOs 1-6 are I2C,SPI */
>> +
>> +        /* GPIO 7-14 are uart1 */
>> +
>> +        /* GPIOs 15 & 16 are uart2 */
>> +
>> +        /* JTAG */
>> +        gpio17 {
>> +            /* JTAG_TDO */
>> +            gpio-export,name = "gpio17";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 17 0>;
>> +        };
>> +        gpio18 {
>> +            /* JTAG_TDI */
>> +            gpio-export,name = "gpio18";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 18 0>;
>> +        };
>> +        gpio19 {
>> +            /* JTAG_TMS */
>> +            gpio-export,name = "gpio19";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 19 0>;
>> +        };
>> +        gpio20 {
>> +            /* JTAG_TCLK */
>> +            gpio-export,name = "gpio20";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 20 0>;
>> +        };
>> +        gpio21 {
>> +            /* JTAG_TRST_N */
>> +            gpio-export,name = "gpio21";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 21 0>;
>> +        };
>> +
>> +        /* ETH LEDs */
>> +        /*
>> +        gpio22 {
>> +            gpio-export,name = "gpio22";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 0 0>;
>> +        };
>> +        gpio23 {
>> +            gpio-export,name = "gpio23";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 1 0>;
>> +        };
>> +        gpio24 {
>> +            gpio-export,name = "gpio24";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 2 0>;
>> +        };
>> +        gpio25 {
>> +            gpio-export,name = "gpio25";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 3 0>;
>> +        };
>> +        */
>> +        gpio26 {
>> +            /* ETH4_LED */
>> +            gpio-export,name = "gpio26";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 4 0>;
>> +        };
>> +
>> +        gpio27 {
>> +            /* spi_cs1 */
>> +            gpio-export,name = "gpio27";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 5 0>;
>> +        };
>> +    };
>> +
>> +};
>> diff --git a/target/linux/ramips/image/rt305x.mk
>> b/target/linux/ramips/image/rt305x.mk
>> index da7fc46..db12a8e 100644
>> --- a/target/linux/ramips/image/rt305x.mk
>> +++ b/target/linux/ramips/image/rt305x.mk
>> @@ -100,6 +100,21 @@ define BuildFirmware/HLKRM04/initramfs
>>       mkhilinkfw -e -i$(call imgname,$(1),$(2))-uImage.bin -o $(call
>> imgname,$(1),$(2))-factory.bin;
>>   endef
>>
>> +# This is called to build the nixcore image.  Build both 8MB and 16MB
>> +nixcore_8mb_mtd_size=8060928
>> +nixcore_16mb_mtd_size=16449536
>> +define BuildFirmware/NIXCOREX1/squashfs
>> +# Args are XXX, nixcore-mM and NIXCOREX1-xM
>> +    $(call
>> BuildFirmware/CustomFlash/$(1),$(1),$(2)-8M,$(3)-8M,$(nixcore_8mb_mtd_size))
>>
>> +    $(call
>> BuildFirmware/CustomFlash/$(1),$(1),$(2)-16M,$(3)-16M,$(nixcore_16mb_mtd_size))
>>
>> +    # Can do somethings here after the build?
>> +endef
>> +define BuildFirmware/NIXCOREX1/initramfs
>> +# Args are XXXX, nixcore-mM and NIXCOREX1-xM
>> +    $(call BuildFirmware/OF/initramfs,$(1),$(2)-8M,$(3)-8M)
>> +    $(call BuildFirmware/OF/initramfs,$(1),$(2)-16M,$(3)-16M)
>> +endef
>> +
>>   vocore_8mb_mtd_size=8060928
>>   vocore_16mb_mtd_size=16449536
>>   define BuildFirmware/VOCORE/squashfs
>> @@ -257,6 +272,7 @@ Image/Build/Profile/NBG-419N=$(call
>> BuildFirmware/Default4M/$(1),$(1),nbg-419n,N
>>   Image/Build/Profile/MZKW300NH2=$(call
>> BuildFirmware/Edimax/$(1),$(1),mzk-w300nh2,MZK-W300NH2,$(mzkw300nh2_mtd_size),CSYS,RN52,0x50000,0xc0000)
>>
>>   Image/Build/Profile/MZKWDPR=$(call
>> BuildFirmware/Default8M/$(1),$(1),mzk-wdpr,MZK-WDPR)
>>   Image/Build/Profile/NCS601W=$(call
>> BuildFirmware/Default8M/$(1),$(1),ncs601W,NCS601W)
>> +Image/Build/Profile/NIXCOREX1=$(call
>> BuildFirmware/NIXCOREX1/$(1),$(1),nixcorex1,NIXCOREX1)
>>   nw718_mtd_size=3801088
>>   Image/Build/Profile/NW718=$(call
>> BuildFirmware/CustomFlashFactory/$(1),$(1),nw718m,NW718,$(nw718_mtd_size),ARA1B4NCRNW718;1,factory)
>>
>>   Image/Build/Profile/M2M=$(call
>> BuildFirmware/Default8M/$(1),$(1),m2m,M2M,Linux Kernel Image)
>> @@ -353,6 +369,7 @@ define Image/Build/Profile/Default
>>       $(call Image/Build/Profile/MZKWDPR,$(1))
>>       $(call Image/Build/Profile/NBG-419N,$(1))
>>       $(call Image/Build/Profile/NCS601W,$(1))
>> +    $(call Image/Build/Profile/NIXCOREX1,$(1))
>>       $(call Image/Build/Profile/NW718,$(1))
>>       $(call Image/Build/Profile/MINIEMBWIFI,$(1))
>>       $(call Image/Build/Profile/MINIEMBPLUG,$(1))
>> diff --git a/target/linux/ramips/rt305x/profiles/nixcore.mk
>> b/target/linux/ramips/rt305x/profiles/nixcore.mk
>> new file mode 100644
>> index 0000000..22dee9b
>> --- /dev/null
>> +++ b/target/linux/ramips/rt305x/profiles/nixcore.mk
>> @@ -0,0 +1,20 @@
>> +#
>> +# Copyright (C) 2014 OpenWrt.org
>> +#
>> +# This is free software, licensed under the GNU General Public License v2.
>> +# See /LICENSE for more information.
>> +#
>> +
>> +define Profile/NIXCOREX1
>> +    NAME:=NixcoreX1
>> +    PACKAGES:=\
>> +        kmod-usb-core kmod-usb-ohci kmod-usb2 \
>> +        kmod-i2c-core kmod-i2c-ralink \
>> +        kmod-spi-dev
>> +endef
>> +
>> +define Profile/NIXCOREX1/Description
>> +    Package set for Nixcore X1 board
>> +endef
>> +
>> +$(eval $(call Profile,NIXCOREX1))
>>
>>
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev



From Alexey.Brodkin at synopsys.com  Tue Jun  7 23:50:55 2016
From: Alexey.Brodkin at synopsys.com (Alexey Brodkin)
Date: Wed,  8 Jun 2016 09:50:55 +0300
Subject: [LEDE-DEV] [PATCH] package/devel/gdb-arc: Add target GDB for ARC
Message-ID: <1465368655-31230-1-git-send-email-abrodkin@synopsys.com>

ARC port of GDB is not yet upstream so we need to use
sources from Synopsys GitHub repo.

Given Synopys' commitment to upstream ARC support in GDB
in the nearest future it might be simpler to add a separate
package for ARC GDB instead of patching generic GDB package.
This way once ARC GDB stuff gets uptreamed we'll only need
to remove that new "gdb-arc" package.

Note 1 very minor change in generic gdb package was done -
it now depends on !arc (while "gdb-arc" depends on "arc").

Signed-off-by: Alexey Brodkin <abrodkin at synopsys.com>
---
 package/devel/{gdb => gdb-arc}/Makefile            | 44 ++++++++++++----------
 .../gdb-arc/patches/100-no_extern_inline.patch     | 32 ++++++++++++++++
 .../devel/gdb-arc/patches/110-no_testsuite.patch   | 21 +++++++++++
 .../patches/120-fix-compile-flag-mismatch.patch    | 11 ++++++
 package/devel/gdb/Makefile                         |  2 +-
 5 files changed, 90 insertions(+), 20 deletions(-)
 copy package/devel/{gdb => gdb-arc}/Makefile (64%)
 create mode 100644 package/devel/gdb-arc/patches/100-no_extern_inline.patch
 create mode 100644 package/devel/gdb-arc/patches/110-no_testsuite.patch
 create mode 100644 package/devel/gdb-arc/patches/120-fix-compile-flag-mismatch.patch

diff --git a/package/devel/gdb/Makefile b/package/devel/gdb-arc/Makefile
similarity index 64%
copy from package/devel/gdb/Makefile
copy to package/devel/gdb-arc/Makefile
index f6d5fec..c42b108 100644
--- a/package/devel/gdb/Makefile
+++ b/package/devel/gdb-arc/Makefile
@@ -7,13 +7,15 @@
 
 include $(TOPDIR)/rules.mk
 
-PKG_NAME:=gdb
-PKG_VERSION:=7.11
+PKG_NAME:=gdb-arc
+PKG_VERSION:=arc-2016.03-gdb
 PKG_RELEASE:=1
 
-PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
-PKG_SOURCE_URL:=@GNU/gdb
-PKG_MD5SUM:=b5c784685e1cde65ba135feea86b6d75
+PKG_SOURCE:=gdb-arc-2016.03-gdb.tar.gz
+PKG_SOURCE_URL:=https://github.com/foss-for-synopsys-dwc-arc-processors/binutils-gdb/archive/$(PKG_VERSION)
+PKG_MD5SUM:=775caaf6385c16f20b6f53c0a2b95f79
+
+PKG_BUILD_DIR:=$(BUILD_DIR)/binutils-gdb-arc-2016.03-gdb
 
 PKG_BUILD_PARALLEL:=1
 PKG_INSTALL:=1
@@ -21,31 +23,31 @@ PKG_LICENSE:=GPL-3.0+
 
 include $(INCLUDE_DIR)/package.mk
 
-define Package/gdb/Default
+define Package/gdb-arc/Default
   SECTION:=devel
   CATEGORY:=Development
-  DEPENDS:=+!USE_MUSL:libthread-db +PACKAGE_zlib:zlib
+  DEPENDS:=+!USE_MUSL:libthread-db +PACKAGE_zlib:zlib @arc
   URL:=http://www.gnu.org/software/gdb/
 endef
 
-define Package/gdb
-$(call Package/gdb/Default)
-  TITLE:=GNU Debugger
+define Package/gdb-arc
+$(call Package/gdb-arc/Default)
+  TITLE:=GNU Debugger for ARC
   DEPENDS+=+libreadline +libncurses +zlib
 endef
 
-define Package/gdb/description
+define Package/gdb-arc/description
 GDB, the GNU Project debugger, allows you to see what is going on `inside'
 another program while it executes -- or what another program was doing at the
 moment it crashed.
 endef
 
-define Package/gdbserver
-$(call Package/gdb/Default)
+define Package/gdbserver-arc
+$(call Package/gdb-arc/Default)
   TITLE:=Remote server for GNU Debugger
 endef
 
-define Package/gdbserver/description
+define Package/gdbserver-arc/description
 GDBSERVER is a program that allows you to run GDB on a different machine than the
 one which is running the program being debugged.
 endef
@@ -55,7 +57,11 @@ CONFIGURE_ARGS+= \
 	--with-system-readline \
 	--without-expat \
 	--without-lzma \
-	--disable-werror
+	--disable-werror \
+	--disable-binutils \
+	--disable-ld \
+	--disable-gas \
+	--disable-sim
 
 CONFIGURE_VARS+= \
 	ac_cv_search_tgetent="$(TARGET_LDFLAGS) -lncurses -lreadline"
@@ -74,15 +80,15 @@ define Build/Install
 		install-gdb
 endef
 
-define Package/gdb/install
+define Package/gdb-arc/install
 	$(INSTALL_DIR) $(1)/usr/bin
 	$(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/gdb $(1)/usr/bin/
 endef
 
-define Package/gdbserver/install
+define Package/gdbserver-arc/install
 	$(INSTALL_DIR) $(1)/usr/bin
 	$(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/gdbserver $(1)/usr/bin/
 endef
 
-$(eval $(call BuildPackage,gdb))
-$(eval $(call BuildPackage,gdbserver))
+$(eval $(call BuildPackage,gdb-arc))
+$(eval $(call BuildPackage,gdbserver-arc))
diff --git a/package/devel/gdb-arc/patches/100-no_extern_inline.patch b/package/devel/gdb-arc/patches/100-no_extern_inline.patch
new file mode 100644
index 0000000..8c18c6e
--- /dev/null
+++ b/package/devel/gdb-arc/patches/100-no_extern_inline.patch
@@ -0,0 +1,32 @@
+--- a/sim/common/sim-arange.c
++++ b/sim/common/sim-arange.c
+@@ -280,11 +280,7 @@ sim_addr_range_delete (ADDR_RANGE *ar, a
+   build_search_tree (ar);
+ }
+ 
+-#endif /* DEFINE_NON_INLINE_P */
+-
+-#if DEFINE_INLINE_P
+-
+-SIM_ARANGE_INLINE int
++int
+ sim_addr_range_hit_p (ADDR_RANGE *ar, address_word addr)
+ {
+   ADDR_RANGE_TREE *t = ar->range_tree;
+@@ -301,4 +297,4 @@ sim_addr_range_hit_p (ADDR_RANGE *ar, ad
+   return 0;
+ }
+ 
+-#endif /* DEFINE_INLINE_P */
++#endif /* DEFINE_NON_INLINE_P */
+--- a/sim/common/sim-arange.h
++++ b/sim/common/sim-arange.h
+@@ -73,7 +73,7 @@ extern void sim_addr_range_delete (ADDR_
+ 
+ /* Return non-zero if ADDR is in range AR, traversing the entire tree.
+    If no range is specified, that is defined to mean "everything".  */
+-SIM_ARANGE_INLINE int
++extern int
+ sim_addr_range_hit_p (ADDR_RANGE * /*ar*/, address_word /*addr*/);
+ #define ADDR_RANGE_HIT_P(ar, addr) \
+   ((ar)->range_tree == NULL || sim_addr_range_hit_p ((ar), (addr)))
diff --git a/package/devel/gdb-arc/patches/110-no_testsuite.patch b/package/devel/gdb-arc/patches/110-no_testsuite.patch
new file mode 100644
index 0000000..1b284ea
--- /dev/null
+++ b/package/devel/gdb-arc/patches/110-no_testsuite.patch
@@ -0,0 +1,21 @@
+--- a/gdb/configure
++++ b/gdb/configure
+@@ -870,8 +870,7 @@ MAKEINFOFLAGS
+ YACC
+ YFLAGS
+ XMKMF'
+-ac_subdirs_all='testsuite
+-gdbtk
++ac_subdirs_all='gdbtk
+ multi-ice
+ gdbserver'
+ 
+@@ -5610,7 +5610,7 @@ $as_echo "$with_auto_load_safe_path" >&6
+ 
+ 
+ 
+-subdirs="$subdirs testsuite"
++subdirs="$subdirs"
+ 
+ 
+ # Check whether to support alternative target configurations
diff --git a/package/devel/gdb-arc/patches/120-fix-compile-flag-mismatch.patch b/package/devel/gdb-arc/patches/120-fix-compile-flag-mismatch.patch
new file mode 100644
index 0000000..c8b41f2
--- /dev/null
+++ b/package/devel/gdb-arc/patches/120-fix-compile-flag-mismatch.patch
@@ -0,0 +1,11 @@
+--- a/gdb/gdbserver/configure
++++ b/gdb/gdbserver/configure
+@@ -2468,7 +2468,7 @@ $as_echo "$as_me: error: \`$ac_var' was
+       ac_cache_corrupted=: ;;
+     ,);;
+     *)
+-      if test "x$ac_old_val" != "x$ac_new_val"; then
++      if test "`echo x$ac_old_val`" != "`echo x$ac_new_val`"; then
+ 	# differences in whitespace do not lead to failure.
+ 	ac_old_val_w=`echo x $ac_old_val`
+ 	ac_new_val_w=`echo x $ac_new_val`
diff --git a/package/devel/gdb/Makefile b/package/devel/gdb/Makefile
index f6d5fec..5678b5b 100644
--- a/package/devel/gdb/Makefile
+++ b/package/devel/gdb/Makefile
@@ -24,7 +24,7 @@ include $(INCLUDE_DIR)/package.mk
 define Package/gdb/Default
   SECTION:=devel
   CATEGORY:=Development
-  DEPENDS:=+!USE_MUSL:libthread-db +PACKAGE_zlib:zlib
+  DEPENDS:=+!USE_MUSL:libthread-db +PACKAGE_zlib:zlib @!arc
   URL:=http://www.gnu.org/software/gdb/
 endef
 
-- 
2.5.5



From noltari at gmail.com  Wed Jun  8 00:42:56 2016
From: noltari at gmail.com (=?UTF-8?Q?=c3=81lvaro_Fern=c3=a1ndez_Rojas?=)
Date: Wed, 8 Jun 2016 09:42:56 +0200
Subject: [LEDE-DEV] brcm2708: take over maintainership
Message-ID: <5757CC80.1060105@gmail.com>

Hello Florian,

Do you mind if I take over brcm2708's maintainership?
https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/brcm2708/Makefile;hb=HEAD#l14

Regards,
?lvaro.


From michal.osowiecki at gmail.com  Wed Jun  8 06:49:26 2016
From: michal.osowiecki at gmail.com (=?UTF-8?Q?Micha=c5=82_Osowiecki?=)
Date: Wed, 8 Jun 2016 15:49:26 +0200
Subject: [LEDE-DEV]  cavium: Ignore MEM boot param when too small
Message-ID: <57582266.8020105@gmail.com>

Cisco RV0XX u-boot sets MEM=2048 as boot param. We assume that at least 
4MB (mem_alloc_size) of ram is needed to run linux on cavium boards, so 
if mem < 4M - ignore it and set default value


Signed-off-by: Micha? Osowiecki <michal.osowiecki at gmail.com>

--- a/arch/mips/cavium-octeon/setup.c   2016-06-06 18:15:32.000000000 +0200
+++ b/arch/mips/cavium-octeon/setup.c   2016-06-08 15:28:56.642919151 +0200
@@ -941,6 +941,11 @@
          * to consistently work.
          */
         mem_alloc_size = 4 << 20;
+
+       /* Ignore bootarg MEM <= 4MB */
+       if (MAX_MEMORY <= mem_alloc_size)
+               MAX_MEMORY = 512ull << 20;
+
         if (mem_alloc_size > MAX_MEMORY)
                 mem_alloc_size = MAX_MEMORY;



From lynxis at fe80.eu  Wed Jun  8 10:30:54 2016
From: lynxis at fe80.eu (Alexander Couzens)
Date: Wed, 8 Jun 2016 19:30:54 +0200
Subject: [LEDE-DEV] Add Hawkboard (OMAP-L138) support
In-Reply-To: <CAG7sGSEE6SyHhsyRBF4s1-h55iE2D0HBZCb1fe6V9hMF-5-WKQ@mail.gmail.com>
References: <CAG7sGSEE6SyHhsyRBF4s1-h55iE2D0HBZCb1fe6V9hMF-5-WKQ@mail.gmail.com>
Message-ID: <20160608193054.52abfabf@lazus.yip>

On Wed, 25 May 2016 13:34:18 +0200
Marcin Go?a? <marcingol30 at gmail.com> wrote:

> Dear LEDE developers,
> 
> Is it possible to port LEDE and run it on Hawkboard (OMAP-L138)?
> Please let me know if anyone is able to help me in this subject.
> 
> Thanks,
> Marcin

Hi Marcin,

after a short look into the architecture, the board is supported by
the linux kernel, but hasn't yet migrated to devicetree, but the cpu
is supported by devicetree.
The cpu is an arm926ej, this would result in a new platform,
because our still supported omap platform use a different architecture:

omap24xx -> arm1136j-s
omap -> cortex-9

So yes, it's possible to add it, but you have to create a new platform
and it also needs a maintainer, who take care of the platform for the
long run.

Best,
lynxis
-- 
Alexander Couzens

mail: lynxis at fe80.eu
jabber: lynxis at fe80.eu
mobile: +4915123277221
gpg: 390D CF78 8BF9 AA50 4F8F  F1E2 C29E 9DA6 A0DF 8604
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20160608/7fc05dc9/attachment.sig>

From john at phrozen.org  Wed Jun  8 11:52:05 2016
From: john at phrozen.org (John Crispin)
Date: Wed, 8 Jun 2016 20:52:05 +0200
Subject: [LEDE-DEV] [PATCH] [ramips] Added NixCore X1 target V2
In-Reply-To: <57571CDF.8070205@nixcores.com>
References: <5756126C.5060101@nixcores.com>
 <c1c05543-6b19-d94f-7feb-ef0802908090@phrozen.org>
 <57571CDF.8070205@nixcores.com>
Message-ID: <0270e2f4-d504-ecf9-a3a9-8c2b9cf8618c@phrozen.org>

Hi Drew,

since CC a few things have changed. the new dts file looks good, i will
merge it tomorrow, rebase the userland script changes and change the
image generation code to the new style. i'll put the patch into my
staging tree and let you know where to find it so you can test it.

Thanks,
	John

On 07/06/2016 21:13, Drew from NixCore wrote:
> John,
> 
> I took a look at the dtsi file and see how the dts is updating the
> settings.  I have
> a dts that builds, but I would like a sanity check before submitting the
> patch again.
> 
> http://pastebin.com/EunNmAf4
> 
> If this looks good I will update the 16M DTS and then submit again.
> 
> Thanks,
> 
> Drew
> 
> On 06/06/2016 11:12 PM, John Crispin wrote:
>> Hi Drew,
>>
>> this patch seems to use the old devicetree layout and image building
>> code. do you think you could rebase this and make it work ontop of
>> latest source.git or do you need help to do that ? this patch wont apply
>> as is.
>>
>> another question, did you build this yourself or is this a rebranded
>> whitelabel product ? i think we already support this board (or one that
>> looks almost identical, need to see if i can find it in my router zoo
>> today)
>>
>>     John
>>
>> On 07/06/2016 02:16, Drew from NixCore wrote:
>>> Added NixCore X1 ramips target http://nixcores.com. This builds 8M
>>> and 16M
>>> images
>>>
>>> Signed-off-by: Drew Gaylo <drew at nixcores.com>
>>> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
>>> b/target/linux/ramips/base-files/etc/board.d/02_network
>>> index 4728c75..69c0125 100755
>>> --- a/target/linux/ramips/base-files/etc/board.d/02_network
>>> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
>>> @@ -77,6 +77,7 @@ ramips_setup_interfaces()
>>>       mt7628|\
>>>       mzk-750dhp|\
>>>       mzk-w300nh2|\
>>> +    nixcore|\
>>>       oy-0001|\
>>>       pbr-m1|\
>>>       psg1208|\
>>> diff --git a/target/linux/ramips/base-files/lib/ramips.sh
>>> b/target/linux/ramips/base-files/lib/ramips.sh
>>> index cbe455d..76f0e43 100755
>>> --- a/target/linux/ramips/base-files/lib/ramips.sh
>>> +++ b/target/linux/ramips/base-files/lib/ramips.sh
>>> @@ -316,6 +316,9 @@ ramips_board_detect() {
>>>       *"NCS601W")
>>>           name="ncs601w"
>>>           ;;
>>> +    *"NixcoreX1")
>>> +        name="nixcore-x1"
>>> +        ;;
>>>       *"NW718")
>>>           name="nw718"
>>>           ;;
>>> diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh
>>> b/target/linux/ramips/base-files/lib/upgrade/platform.sh
>>> index 91c9997..0094568 100755
>>> --- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
>>> +++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
>>> @@ -94,6 +94,7 @@ platform_check_image() {
>>>       mzk-w300nh2|\
>>>       mzk-wdpr|\
>>>       nbg-419n|\
>>> +    nixcore|\
>>>       nw718|\
>>>       oy-0001|\
>>>       pbr-m1|\
>>> diff --git a/target/linux/ramips/dts/NIXCOREX1-16M.dts
>>> b/target/linux/ramips/dts/NIXCOREX1-16M.dts
>>> new file mode 100644
>>> index 0000000..c7ec410
>>> --- /dev/null
>>> +++ b/target/linux/ramips/dts/NIXCOREX1-16M.dts
>>> @@ -0,0 +1,186 @@
>>> +/dts-v1/;
>>> +
>>> +/include/ "rt5350.dtsi"
>>> +
>>> +/ {
>>> +    compatible = "NixcoreX1", "ralink,rt5350-soc";
>>> +    model = "NixcoreX1";
>>> +
>>> +    palmbus at 10000000 {
>>> +        /* Re-enable the gpio1 ports */
>>> +        gpio1: gpio at 660 {
>>> +            status = "okay";
>>> +        };
>>> +
>>> +        i2c at 900 {
>>> +            status = "okay";
>>> +        };
>>> +        uart at 500 {
>>> +            status = "okay";
>>> +            /* Mix of uart and gpio */
>>> +            reset-names = "gpio uartf";
>>> +        };
>>> +        spi at b00 {
>>> +            status = "okay";
>>> +
>>> +            m25p80 at 0 {
>>> +                #address-cells = <1>;
>>> +                #size-cells = <1>;
>>> +                compatible = "s25fl064k";
>>> +                reg = <0>;
>>> +                linux,modalias = "m25p80", "s25fl064k";
>>> +                spi-max-frequency = <10000000>;
>>> +
>>> +                partition at 0 {
>>> +                    label = "uboot";
>>> +                    reg = <0x0 0x30000>;
>>> +                    read-only;
>>> +                };
>>> +
>>> +                partition at 30000 {
>>> +                    label = "uboot-env";
>>> +                    reg = <0x30000 0x10000>;
>>> +                    read-only;
>>> +                };
>>> +
>>> +                factory: partition at 40000 {
>>> +                    label = "factory";
>>> +                    reg = <0x40000 0x10000>;
>>> +                    read-only;
>>> +                };
>>> +
>>> +                partition at 50000 {
>>> +                    label = "firmware";
>>> +                    reg = <0x50000 0x7b0000>;
>>> +                };
>>> +            };
>>> +
>>> +            spidev at 1 {
>>> +                compatible = "linux,spidev";
>>> +                spi-max-frequency = <10000000>;
>>> +                reg = <1>;
>>> +            };
>>> +        };
>>> +    };
>>> +
>>> +    pinctrl {
>>> +        state_default: pinctrl0 {
>>> +            gpio {
>>> +                /* Associate the tjag, uartf and led groups with
>>> gpio */
>>> +                ralink,group = "jtag", "led", "spi_cs1";
>>> +                /* How do we set individual pins? */
>>> +                ralink,function = "gpio";
>>> +            };
>>> +        };
>>> +    };
>>> +
>>> +    ethernet at 10100000 {
>>> +        mtd-mac-address = <&factory 0x4>;
>>> +    };
>>> +
>>> +    esw at 10110000 {
>>> +        ralink,portmap = <0x17>;
>>> +    };
>>> +
>>> +    wmac at 10180000 {
>>> +        ralink,mtd-eeprom = <&factory 0>;
>>> +    };
>>> +
>>> +    ehci at 101c0000 {
>>> +        status = "okay";
>>> +    };
>>> +
>>> +    ohci at 101c1000 {
>>> +        status = "okay";
>>> +    };
>>> +
>>> +    chosen {
>>> +        bootargs = "console=ttyS1,57600";
>>> +    };
>>> +    gpio-export {
>>> +        compatible = "gpio-export";
>>> +        #size-cells = <0>;
>>> +
>>> +        gpio0 {
>>> +            gpio-export,name = "gpio0";
>>> +            gpio-export,direction_may_change = <1>;
>>> +            gpios = <&gpio0 0 0>;
>>> +        };
>>> +
>>> +        /* GPIOs 1-6 are I2C,SPI */
>>> +
>>> +        /* GPIO 7-14 are uart1 */
>>> +
>>> +        /* GPIOs 15 & 16 are uart2 */
>>> +
>>> +        /* JTAG */
>>> +        gpio17 {
>>> +            /* JTAG_TDO */
>>> +            gpio-export,name = "gpio17";
>>> +            gpio-export,direction_may_change = <1>;
>>> +            gpios = <&gpio0 17 0>;
>>> +        };
>>> +        gpio18 {
>>> +            /* JTAG_TDI */
>>> +            gpio-export,name = "gpio18";
>>> +            gpio-export,direction_may_change = <1>;
>>> +            gpios = <&gpio0 18 0>;
>>> +        };
>>> +        gpio19 {
>>> +            /* JTAG_TMS */
>>> +            gpio-export,name = "gpio19";
>>> +            gpio-export,direction_may_change = <1>;
>>> +            gpios = <&gpio0 19 0>;
>>> +        };
>>> +        gpio20 {
>>> +            /* JTAG_TCLK */
>>> +            gpio-export,name = "gpio20";
>>> +            gpio-export,direction_may_change = <1>;
>>> +            gpios = <&gpio0 20 0>;
>>> +        };
>>> +        gpio21 {
>>> +            /* JTAG_TRST_N */
>>> +            gpio-export,name = "gpio21";
>>> +            gpio-export,direction_may_change = <1>;
>>> +            gpios = <&gpio0 21 0>;
>>> +        };
>>> +
>>> +        /* ETH LEDs */
>>> +        /*
>>> +        gpio22 {
>>> +            gpio-export,name = "gpio22";
>>> +            gpio-export,direction_may_change = <1>;
>>> +            gpios = <&gpio1 0 0>;
>>> +        };
>>> +        gpio23 {
>>> +            gpio-export,name = "gpio23";
>>> +            gpio-export,direction_may_change = <1>;
>>> +            gpios = <&gpio1 1 0>;
>>> +        };
>>> +        gpio24 {
>>> +            gpio-export,name = "gpio24";
>>> +            gpio-export,direction_may_change = <1>;
>>> +            gpios = <&gpio1 2 0>;
>>> +        };
>>> +        gpio25 {
>>> +            gpio-export,name = "gpio25";
>>> +            gpio-export,direction_may_change = <1>;
>>> +            gpios = <&gpio1 3 0>;
>>> +        };
>>> +        */
>>> +        gpio26 {
>>> +            /* ETH4_LED */
>>> +            gpio-export,name = "gpio26";
>>> +            gpio-export,direction_may_change = <1>;
>>> +            gpios = <&gpio1 4 0>;
>>> +        };
>>> +
>>> +        gpio27 {
>>> +            /* spi_cs1 */
>>> +            gpio-export,name = "gpio27";
>>> +            gpio-export,direction_may_change = <1>;
>>> +            gpios = <&gpio1 5 0>;
>>> +        };
>>> +    };
>>> +
>>> +};
>>> diff --git a/target/linux/ramips/dts/NIXCOREX1-8M.dts
>>> b/target/linux/ramips/dts/NIXCOREX1-8M.dts
>>> new file mode 100644
>>> index 0000000..c7ec410
>>> --- /dev/null
>>> +++ b/target/linux/ramips/dts/NIXCOREX1-8M.dts
>>> @@ -0,0 +1,186 @@
>>> +/dts-v1/;
>>> +
>>> +/include/ "rt5350.dtsi"
>>> +
>>> +/ {
>>> +    compatible = "NixcoreX1", "ralink,rt5350-soc";
>>> +    model = "NixcoreX1";
>>> +
>>> +    palmbus at 10000000 {
>>> +        /* Re-enable the gpio1 ports */
>>> +        gpio1: gpio at 660 {
>>> +            status = "okay";
>>> +        };
>>> +
>>> +        i2c at 900 {
>>> +            status = "okay";
>>> +        };
>>> +        uart at 500 {
>>> +            status = "okay";
>>> +            /* Mix of uart and gpio */
>>> +            reset-names = "gpio uartf";
>>> +        };
>>> +        spi at b00 {
>>> +            status = "okay";
>>> +
>>> +            m25p80 at 0 {
>>> +                #address-cells = <1>;
>>> +                #size-cells = <1>;
>>> +                compatible = "s25fl064k";
>>> +                reg = <0>;
>>> +                linux,modalias = "m25p80", "s25fl064k";
>>> +                spi-max-frequency = <10000000>;
>>> +
>>> +                partition at 0 {
>>> +                    label = "uboot";
>>> +                    reg = <0x0 0x30000>;
>>> +                    read-only;
>>> +                };
>>> +
>>> +                partition at 30000 {
>>> +                    label = "uboot-env";
>>> +                    reg = <0x30000 0x10000>;
>>> +                    read-only;
>>> +                };
>>> +
>>> +                factory: partition at 40000 {
>>> +                    label = "factory";
>>> +                    reg = <0x40000 0x10000>;
>>> +                    read-only;
>>> +                };
>>> +
>>> +                partition at 50000 {
>>> +                    label = "firmware";
>>> +                    reg = <0x50000 0x7b0000>;
>>> +                };
>>> +            };
>>> +
>>> +            spidev at 1 {
>>> +                compatible = "linux,spidev";
>>> +                spi-max-frequency = <10000000>;
>>> +                reg = <1>;
>>> +            };
>>> +        };
>>> +    };
>>> +
>>> +    pinctrl {
>>> +        state_default: pinctrl0 {
>>> +            gpio {
>>> +                /* Associate the tjag, uartf and led groups with
>>> gpio */
>>> +                ralink,group = "jtag", "led", "spi_cs1";
>>> +                /* How do we set individual pins? */
>>> +                ralink,function = "gpio";
>>> +            };
>>> +        };
>>> +    };
>>> +
>>> +    ethernet at 10100000 {
>>> +        mtd-mac-address = <&factory 0x4>;
>>> +    };
>>> +
>>> +    esw at 10110000 {
>>> +        ralink,portmap = <0x17>;
>>> +    };
>>> +
>>> +    wmac at 10180000 {
>>> +        ralink,mtd-eeprom = <&factory 0>;
>>> +    };
>>> +
>>> +    ehci at 101c0000 {
>>> +        status = "okay";
>>> +    };
>>> +
>>> +    ohci at 101c1000 {
>>> +        status = "okay";
>>> +    };
>>> +
>>> +    chosen {
>>> +        bootargs = "console=ttyS1,57600";
>>> +    };
>>> +    gpio-export {
>>> +        compatible = "gpio-export";
>>> +        #size-cells = <0>;
>>> +
>>> +        gpio0 {
>>> +            gpio-export,name = "gpio0";
>>> +            gpio-export,direction_may_change = <1>;
>>> +            gpios = <&gpio0 0 0>;
>>> +        };
>>> +
>>> +        /* GPIOs 1-6 are I2C,SPI */
>>> +
>>> +        /* GPIO 7-14 are uart1 */
>>> +
>>> +        /* GPIOs 15 & 16 are uart2 */
>>> +
>>> +        /* JTAG */
>>> +        gpio17 {
>>> +            /* JTAG_TDO */
>>> +            gpio-export,name = "gpio17";
>>> +            gpio-export,direction_may_change = <1>;
>>> +            gpios = <&gpio0 17 0>;
>>> +        };
>>> +        gpio18 {
>>> +            /* JTAG_TDI */
>>> +            gpio-export,name = "gpio18";
>>> +            gpio-export,direction_may_change = <1>;
>>> +            gpios = <&gpio0 18 0>;
>>> +        };
>>> +        gpio19 {
>>> +            /* JTAG_TMS */
>>> +            gpio-export,name = "gpio19";
>>> +            gpio-export,direction_may_change = <1>;
>>> +            gpios = <&gpio0 19 0>;
>>> +        };
>>> +        gpio20 {
>>> +            /* JTAG_TCLK */
>>> +            gpio-export,name = "gpio20";
>>> +            gpio-export,direction_may_change = <1>;
>>> +            gpios = <&gpio0 20 0>;
>>> +        };
>>> +        gpio21 {
>>> +            /* JTAG_TRST_N */
>>> +            gpio-export,name = "gpio21";
>>> +            gpio-export,direction_may_change = <1>;
>>> +            gpios = <&gpio0 21 0>;
>>> +        };
>>> +
>>> +        /* ETH LEDs */
>>> +        /*
>>> +        gpio22 {
>>> +            gpio-export,name = "gpio22";
>>> +            gpio-export,direction_may_change = <1>;
>>> +            gpios = <&gpio1 0 0>;
>>> +        };
>>> +        gpio23 {
>>> +            gpio-export,name = "gpio23";
>>> +            gpio-export,direction_may_change = <1>;
>>> +            gpios = <&gpio1 1 0>;
>>> +        };
>>> +        gpio24 {
>>> +            gpio-export,name = "gpio24";
>>> +            gpio-export,direction_may_change = <1>;
>>> +            gpios = <&gpio1 2 0>;
>>> +        };
>>> +        gpio25 {
>>> +            gpio-export,name = "gpio25";
>>> +            gpio-export,direction_may_change = <1>;
>>> +            gpios = <&gpio1 3 0>;
>>> +        };
>>> +        */
>>> +        gpio26 {
>>> +            /* ETH4_LED */
>>> +            gpio-export,name = "gpio26";
>>> +            gpio-export,direction_may_change = <1>;
>>> +            gpios = <&gpio1 4 0>;
>>> +        };
>>> +
>>> +        gpio27 {
>>> +            /* spi_cs1 */
>>> +            gpio-export,name = "gpio27";
>>> +            gpio-export,direction_may_change = <1>;
>>> +            gpios = <&gpio1 5 0>;
>>> +        };
>>> +    };
>>> +
>>> +};
>>> diff --git a/target/linux/ramips/image/rt305x.mk
>>> b/target/linux/ramips/image/rt305x.mk
>>> index da7fc46..db12a8e 100644
>>> --- a/target/linux/ramips/image/rt305x.mk
>>> +++ b/target/linux/ramips/image/rt305x.mk
>>> @@ -100,6 +100,21 @@ define BuildFirmware/HLKRM04/initramfs
>>>       mkhilinkfw -e -i$(call imgname,$(1),$(2))-uImage.bin -o $(call
>>> imgname,$(1),$(2))-factory.bin;
>>>   endef
>>>
>>> +# This is called to build the nixcore image.  Build both 8MB and 16MB
>>> +nixcore_8mb_mtd_size=8060928
>>> +nixcore_16mb_mtd_size=16449536
>>> +define BuildFirmware/NIXCOREX1/squashfs
>>> +# Args are XXX, nixcore-mM and NIXCOREX1-xM
>>> +    $(call
>>> BuildFirmware/CustomFlash/$(1),$(1),$(2)-8M,$(3)-8M,$(nixcore_8mb_mtd_size))
>>>
>>>
>>> +    $(call
>>> BuildFirmware/CustomFlash/$(1),$(1),$(2)-16M,$(3)-16M,$(nixcore_16mb_mtd_size))
>>>
>>>
>>> +    # Can do somethings here after the build?
>>> +endef
>>> +define BuildFirmware/NIXCOREX1/initramfs
>>> +# Args are XXXX, nixcore-mM and NIXCOREX1-xM
>>> +    $(call BuildFirmware/OF/initramfs,$(1),$(2)-8M,$(3)-8M)
>>> +    $(call BuildFirmware/OF/initramfs,$(1),$(2)-16M,$(3)-16M)
>>> +endef
>>> +
>>>   vocore_8mb_mtd_size=8060928
>>>   vocore_16mb_mtd_size=16449536
>>>   define BuildFirmware/VOCORE/squashfs
>>> @@ -257,6 +272,7 @@ Image/Build/Profile/NBG-419N=$(call
>>> BuildFirmware/Default4M/$(1),$(1),nbg-419n,N
>>>   Image/Build/Profile/MZKW300NH2=$(call
>>> BuildFirmware/Edimax/$(1),$(1),mzk-w300nh2,MZK-W300NH2,$(mzkw300nh2_mtd_size),CSYS,RN52,0x50000,0xc0000)
>>>
>>>
>>>   Image/Build/Profile/MZKWDPR=$(call
>>> BuildFirmware/Default8M/$(1),$(1),mzk-wdpr,MZK-WDPR)
>>>   Image/Build/Profile/NCS601W=$(call
>>> BuildFirmware/Default8M/$(1),$(1),ncs601W,NCS601W)
>>> +Image/Build/Profile/NIXCOREX1=$(call
>>> BuildFirmware/NIXCOREX1/$(1),$(1),nixcorex1,NIXCOREX1)
>>>   nw718_mtd_size=3801088
>>>   Image/Build/Profile/NW718=$(call
>>> BuildFirmware/CustomFlashFactory/$(1),$(1),nw718m,NW718,$(nw718_mtd_size),ARA1B4NCRNW718;1,factory)
>>>
>>>
>>>   Image/Build/Profile/M2M=$(call
>>> BuildFirmware/Default8M/$(1),$(1),m2m,M2M,Linux Kernel Image)
>>> @@ -353,6 +369,7 @@ define Image/Build/Profile/Default
>>>       $(call Image/Build/Profile/MZKWDPR,$(1))
>>>       $(call Image/Build/Profile/NBG-419N,$(1))
>>>       $(call Image/Build/Profile/NCS601W,$(1))
>>> +    $(call Image/Build/Profile/NIXCOREX1,$(1))
>>>       $(call Image/Build/Profile/NW718,$(1))
>>>       $(call Image/Build/Profile/MINIEMBWIFI,$(1))
>>>       $(call Image/Build/Profile/MINIEMBPLUG,$(1))
>>> diff --git a/target/linux/ramips/rt305x/profiles/nixcore.mk
>>> b/target/linux/ramips/rt305x/profiles/nixcore.mk
>>> new file mode 100644
>>> index 0000000..22dee9b
>>> --- /dev/null
>>> +++ b/target/linux/ramips/rt305x/profiles/nixcore.mk
>>> @@ -0,0 +1,20 @@
>>> +#
>>> +# Copyright (C) 2014 OpenWrt.org
>>> +#
>>> +# This is free software, licensed under the GNU General Public
>>> License v2.
>>> +# See /LICENSE for more information.
>>> +#
>>> +
>>> +define Profile/NIXCOREX1
>>> +    NAME:=NixcoreX1
>>> +    PACKAGES:=\
>>> +        kmod-usb-core kmod-usb-ohci kmod-usb2 \
>>> +        kmod-i2c-core kmod-i2c-ralink \
>>> +        kmod-spi-dev
>>> +endef
>>> +
>>> +define Profile/NIXCOREX1/Description
>>> +    Package set for Nixcore X1 board
>>> +endef
>>> +
>>> +$(eval $(call Profile,NIXCOREX1))
>>>
>>>
>>> _______________________________________________
>>> Lede-dev mailing list
>>> Lede-dev at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/lede-dev
> 


From xinxing.huchn at gmail.com  Wed Jun  8 14:43:40 2016
From: xinxing.huchn at gmail.com (Xinxing Hu)
Date: Thu, 9 Jun 2016 05:43:40 +0800
Subject: [LEDE-DEV] libubox, procd: init process hangs
In-Reply-To: <CAECwjAjrVG3M6EtYCtB45SYZNQhRJgC7CETT8u6+aypotF9c+g@mail.gmail.com>
References: <f2dd22dd-8fff-4521-5e3f-cdbf6faa0275@gmail.com>
 <CAECwjAjrVG3M6EtYCtB45SYZNQhRJgC7CETT8u6+aypotF9c+g@mail.gmail.com>
Message-ID: <ab4ba37d-f312-dd2f-8e22-a512c1533d1f@gmail.com>

Hi Yousong,

Thanks a lot for you patch. I tried it a little bit, and till now 
everything looks OK. It seems this issue is solved by your patch.

Not sure whether Mats (the original reporter of this issue) still see 
the issue or not.

Best Regards,
Xinxing

On 2016/6/7 20:49, Yousong Zhou wrote:
> On 7 June 2016 at 06:11, Xinxing Hu <xinxing.huchn at gmail.com> wrote:
>> Hi Guys,
>>
>> I have another idea about this issue. Maybe it is not kernel, but uloop
>> related. I read procd and libubox code a little bit, and it seems there is a
>> potential issue existing in uloop_run().
>>
>> In general, uloop_run() is running in a while loop:
>>
>> while()
>>         1, Process timeouts list
>>
>>         2, Handle terminated child processes
>>
>>         3, uloop_run_events(timeout) => calls epoll_wait()
>> done
>>
>> During boot, procd_inittab_run("sysinit") is called in Step1, which calls
>> add_initd(). add_initd() would add an entry in timeouts list, whose callback
>> function is to execute an rc.d/S* script.
>>
>> When the while loop goes back to Step1 again, the timeouts list would be
>> processed, and an rc.d/S* script would be executed in a child process while
>> the parent process remains in the while loop. If everything goes fine, when
>> the child process is terminated, the parent process will handle terminated
>> child process by calling waitpid() in the while loop. A process callback
>> function will also be called, which adds another timeout entry in timeouts
>> list. This new entry corresponds to the next rc.d/S* script to be executed.
>> When the while loop reaches Step1 again, the next rc.d/S* script would be
>> invoked.
>>
>> Everything looks OK till now. However, due to process scheduling, problems
>> might happen when uloop_run_events(uloop_get_next_timeout(&tv)) is called.
>> For instance: if the child process is still running when
>> uloop_get_next_timeout(&tv) is called, then the timeouts list is already
>> empty at that time, so the return value of uloop_get_next_timeout(&tv) would
>> be -1. Furthermore, if the child process is terminated and signal handler is
>> executed before epoll_wait() is called, then epoll_wait will block the
>> parent process forever until some other events it is listening to arrive. In
>> this sense, other events arriving just hide this issue. During the boot, as
>> long as /etc/rc.d/S* is not finished executing, epoll_wait() should never be
>> blocked.
>>
>> I think, a potential solution might be: during initialization, we let uloop
>> listens to a kind of 'dummy' event. Every time when the child process
>> finishes executing a rc.d/S* script, we send a 'dummy' event. In this case,
>> epoll_wait would never be blocked during booting.
>
> Interesting.  Looks like the same issue can also happen to the
> uloop_canceled check.  Python's tornado library uses pipe() as a
> "waker" to "calls the given callback on the next I/O loop iteration."
>
> Can you give the attached patch a try to see if it can solve the issue
> for you?  It was only just run-tested on qemu malta to make sure the
> patched libubox still runs.
>
>                 yousong
>
>>
>> Best Regards,
>> Xinxing
>>
>>
>>
>>
>> On 2016/5/17 18:03, Mats Karrman wrote:
>> Hi Felix, others,
>>
>> I have been experiencing problems with the init scripts dispatch
>> suddenly stopping (indefinitely).
>> This happens maybe once in 100 reboots.
>> After inserting a new start script that launches another daemon
>> (cgrulesengd) very early in the boot process, the failures started to
>> come a lot more frequently, maybe once in 10 reboots, making this a real
>> issue.
>> I'm normally using the versions of procd and libubox selected by OpenWRT
>> BB branch but I have tested the latest versions from the git repos with
>> the same result.
>> So far I have only got this to happen on a quite fast board (ARM dual
>> CorexA9 @ 1GHz).
>> Inserting trace prints in libubox changes behavior, also suggesting the
>> problem is timing dependent.
>>
>> When init hangs:
>> - it is still possible to log in on console
>> - there is always a zombie start script, e.g. S11sysctl.
>> - by killing a process (e.g. ubusd or cgrulesengd) the init process
>> continues.
>> - otherwise generating an event, e.g inserting something into a USB port
>> also makes the init continue.
>>
>> I have traced the problem down to the "epoll_wait" call in
>> libubox::uloop.c::uloop_fetch_events().
>> The following patch makes sure epoll_wait is never called without a timeout.
>> My tests show that this solves the problem.
>> I have been able to observe the case when the boot gets stuck and then
>> continues after the 8s timeout.
>> However I'm not sure that this is the correct fix for the problem as
>> there may be other reasons that there is no event in the first place.
>> Your feedback would be welcome!
>>
>> BR // Mats
>> Currently working for Inteno Broadband Technology AB
>>
>> ---
>> Avast ??????????????????
>> https://www.avast.com/antivirus
>>
>>
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev


From chunkeey at googlemail.com  Wed Jun  8 15:29:52 2016
From: chunkeey at googlemail.com (Christian Lamparter)
Date: Thu,  9 Jun 2016 00:29:52 +0200
Subject: [LEDE-DEV] [PATCH] xtables-addons: fix kmod-ipt-sysrq missing
	crypto_hash dependency
Message-ID: <1465424992-23912-1-git-send-email-chunkeey@gmail.com>

This patch fixes the following dependency issue when building
kmod-ipt-sysrq module package from xtable-addons library:
"Package kmod-ipt-sysrq is missing dependencies for the following libraries:"
crypto_hash.ko"

By looking at the code, the kmod-ipt-sysrq module just needs
an additional dependency on kmod-crypto-manager.

Cc: Dirk Neukirchen <dirkneukirchen at web.de>
Signed-off-by: Christian Lamparter <chunkeey at gmail.com>
---
 package/network/utils/xtables-addons/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/network/utils/xtables-addons/Makefile b/package/network/utils/xtables-addons/Makefile
index 0842e11..9224922 100644
--- a/package/network/utils/xtables-addons/Makefile
+++ b/package/network/utils/xtables-addons/Makefile
@@ -145,7 +145,7 @@ $(eval $(call BuildTemplate,lscan,lscan,xt_lscan,xt_lscan,))
 $(eval $(call BuildTemplate,lua,Lua PacketScript,xt_LUA,LUA/xt_LUA,+kmod-ipt-conntrack-extra))
 $(eval $(call BuildTemplate,psd,psd,xt_psd,xt_psd,))
 $(eval $(call BuildTemplate,quota2,quota2,xt_quota2,xt_quota2,))
-$(eval $(call BuildTemplate,sysrq,SYSRQ,xt_SYSRQ,xt_SYSRQ,+kmod-ipt-compat-xtables))
+$(eval $(call BuildTemplate,sysrq,SYSRQ,xt_SYSRQ,xt_SYSRQ,+kmod-ipt-compat-xtables +kmod-crypto-manager))
 $(eval $(call BuildTemplate,tarpit,TARPIT,xt_TARPIT,xt_TARPIT,+kmod-ipt-compat-xtables))
 
 $(eval $(call BuildPackage,iptaccount))
-- 
2.8.1



From yszhou4tech at gmail.com  Wed Jun  8 19:04:23 2016
From: yszhou4tech at gmail.com (Yousong Zhou)
Date: Thu,  9 Jun 2016 10:04:23 +0800
Subject: [LEDE-DEV] [PATCH 1/2] libunwind: initial version 1.1
Message-ID: <1465437864-19567-1-git-send-email-yszhou4tech@gmail.com>

The package Makefile was based on work at link [1] with the following
changes

 1. Disable minidebuginfo support thus no dependency on liblzma
 2. Add 2 patches for building against musl-libc and building with
    mips16 enabled
 3. Add LICENSE and DEPENDS info, etc.

[1] https://github.com/rpi-openwrt/rpi-packages/tree/master/libs/libunwind

Signed-off-by: Yousong Zhou <yszhou4tech at gmail.com>
---
 package/libs/libunwind/Makefile                    | 53 ++++++++++++++++++++++
 .../libs/libunwind/patches/001-disable-tests.patch | 22 +++++++++
 .../patches/002-fix-building-getcontext_S.patch    | 19 ++++++++
 .../003-fix-missing-ef_reg-defs-with-musl.patch    | 47 +++++++++++++++++++
 4 files changed, 141 insertions(+)
 create mode 100644 package/libs/libunwind/Makefile
 create mode 100644 package/libs/libunwind/patches/001-disable-tests.patch
 create mode 100644 package/libs/libunwind/patches/002-fix-building-getcontext_S.patch
 create mode 100644 package/libs/libunwind/patches/003-fix-missing-ef_reg-defs-with-musl.patch

diff --git a/package/libs/libunwind/Makefile b/package/libs/libunwind/Makefile
new file mode 100644
index 0000000..ec19656
--- /dev/null
+++ b/package/libs/libunwind/Makefile
@@ -0,0 +1,53 @@
+#
+# Copyright (C) 2008-2013 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:=libunwind
+PKG_VERSION:=1.1
+PKG_RELEASE:=1
+
+PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
+PKG_SOURCE_URL:=http://download.savannah.gnu.org/releases/libunwind
+PKG_MD5SUM:=fb4ea2f6fbbe45bf032cd36e586883ce
+PKG_FIXUP:=autoreconf
+PKG_INSTALL:=1
+
+PKG_LICENSE:=X11
+PKG_LICENSE_FILES:=LICENSE
+
+PKG_MAINTAINER:=Yousong Zhou <yszhou4tech at gmail.com>
+
+include $(INCLUDE_DIR)/package.mk
+
+define Package/libunwind
+  SECTION:=libs
+  CATEGORY:=Libraries
+  TITLE:=The libunwind project
+  URL:=http://www.nongnu.org/libunwind/
+  DEPENDS:=@(mips||mipsel||powerpc||i386||x86_64)
+endef
+
+define Package/libunwind/description
+  Libunwind defines a portable and efficient C programming interface (API) to determine the call-chain of a program.
+endef
+
+CONFIGURE_ARGS += --enable-minidebuginfo=no
+
+define Package/libunwind/install
+	$(INSTALL_DIR) $(1)/usr/lib
+	$(CP) $(PKG_INSTALL_DIR)/usr/lib/libunwin*.so* $(1)/usr/lib/
+endef
+
+define Build/InstallDev
+	$(INSTALL_DIR) $(1)/usr/include $(1)/usr/lib/pkgconfig
+	$(CP) $(PKG_INSTALL_DIR)/usr/include/*.h $(1)/usr/include
+	$(CP) $(PKG_INSTALL_DIR)/usr/lib/libunwin*.so* $(1)/usr/lib
+	$(CP) $(PKG_INSTALL_DIR)/usr/lib/pkgconfig/* $(1)/usr/lib/pkgconfig/
+endef
+
+$(eval $(call BuildPackage,libunwind))
diff --git a/package/libs/libunwind/patches/001-disable-tests.patch b/package/libs/libunwind/patches/001-disable-tests.patch
new file mode 100644
index 0000000..9700fea
--- /dev/null
+++ b/package/libs/libunwind/patches/001-disable-tests.patch
@@ -0,0 +1,22 @@
+--- a/Makefile.am
++++ b/Makefile.am
+@@ -36,7 +36,7 @@
+ 
+ nodist_include_HEADERS = include/libunwind-common.h
+ 
+-SUBDIRS = src tests doc
++SUBDIRS = src doc
+ 
+ noinst_HEADERS = include/dwarf.h include/dwarf_i.h include/dwarf-eh.h	\
+ 	include/compiler.h include/libunwind_i.h include/mempool.h	\
+--- a/Makefile.in
++++ b/Makefile.in
+@@ -313,7 +313,7 @@
+ 	$(am__append_7) $(am__append_8) $(am__append_9) \
+ 	$(am__append_10)
+ nodist_include_HEADERS = include/libunwind-common.h
+-SUBDIRS = src tests doc
++SUBDIRS = src doc
+ noinst_HEADERS = include/dwarf.h include/dwarf_i.h include/dwarf-eh.h	\
+ 	include/compiler.h include/libunwind_i.h include/mempool.h	\
+ 	include/remote.h						\
diff --git a/package/libs/libunwind/patches/002-fix-building-getcontext_S.patch b/package/libs/libunwind/patches/002-fix-building-getcontext_S.patch
new file mode 100644
index 0000000..10b1dd1
--- /dev/null
+++ b/package/libs/libunwind/patches/002-fix-building-getcontext_S.patch
@@ -0,0 +1,19 @@
+diff -uprN a/src/mips/getcontext.S b/src/mips/getcontext.S
+--- a/src/mips/getcontext.S	2012-10-06 12:54:38.000000000 +0800
++++ b/src/mips/getcontext.S	2016-06-08 13:35:25.033051679 +0800
+@@ -24,12 +24,12 @@ OF CONTRACT, TORT OR OTHERWISE, ARISING
+ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.  */
+ 
+ #include "offsets.h"
+-#include <endian.h>
+ 
+ 	.text
++	.set nomips16
+ 
+ #if _MIPS_SIM == _ABIO32
+-# if __BYTE_ORDER == __BIG_ENDIAN
++# if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
+ #  define OFFSET 4
+ # else
+ #  define OFFSET 0
+
diff --git a/package/libs/libunwind/patches/003-fix-missing-ef_reg-defs-with-musl.patch b/package/libs/libunwind/patches/003-fix-missing-ef_reg-defs-with-musl.patch
new file mode 100644
index 0000000..465abb4
--- /dev/null
+++ b/package/libs/libunwind/patches/003-fix-missing-ef_reg-defs-with-musl.patch
@@ -0,0 +1,47 @@
+diff -uprN a/include/libunwind-mips.h b/include/libunwind-mips.h
+--- a/include/libunwind-mips.h	2012-10-06 12:54:38.000000000 +0800
++++ b/include/libunwind-mips.h	2016-06-08 13:55:55.029436442 +0800
+@@ -111,6 +111,42 @@ typedef enum
+   }
+ mips_regnum_t;
+ 
++#ifndef __GLIBC__
++#include <sys/reg.h>
++
++/* musl as of 1.1.14 does not export these */
++#define EF_REG0			6
++#define EF_REG1			7
++#define EF_REG2			8
++#define EF_REG3			9
++#define EF_REG4			10
++#define EF_REG5			11
++#define EF_REG6			12
++#define EF_REG7			13
++#define EF_REG8			14
++#define EF_REG9			15
++#define EF_REG10		16
++#define EF_REG11		17
++#define EF_REG12		18
++#define EF_REG13		19
++#define EF_REG14		20
++#define EF_REG15		21
++#define EF_REG16		22
++#define EF_REG17		23
++#define EF_REG18		24
++#define EF_REG19		25
++#define EF_REG20		26
++#define EF_REG21		27
++#define EF_REG22		28
++#define EF_REG23		29
++#define EF_REG24		30
++#define EF_REG25		31
++#define EF_REG28		34
++#define EF_REG29		35
++#define EF_REG30		36
++#define EF_REG31		37
++#endif
++
+ typedef enum
+   {
+     UNW_MIPS_ABI_O32,
+
-- 
2.6.4



From yszhou4tech at gmail.com  Wed Jun  8 19:04:24 2016
From: yszhou4tech at gmail.com (Yousong Zhou)
Date: Thu,  9 Jun 2016 10:04:24 +0800
Subject: [LEDE-DEV] [PATCH 2/2] strace: add option for enabling stack trace
	support
In-Reply-To: <1465437864-19567-1-git-send-email-yszhou4tech@gmail.com>
References: <1465437864-19567-1-git-send-email-yszhou4tech@gmail.com>
Message-ID: <1465437864-19567-2-git-send-email-yszhou4tech@gmail.com>

Signed-off-by: Yousong Zhou <yszhou4tech at gmail.com>
---
 package/devel/strace/Makefile | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/package/devel/strace/Makefile b/package/devel/strace/Makefile
index 8a0d2e8..df560fd 100644
--- a/package/devel/strace/Makefile
+++ b/package/devel/strace/Makefile
@@ -11,7 +11,7 @@ include $(INCLUDE_DIR)/kernel.mk
 PKG_NAME:=strace
 
 PKG_VERSION:=4.11
-PKG_RELEASE:=1
+PKG_RELEASE:=2
 PKG_MD5SUM:=a15d2555a7febb56d00c6e1a51c655dc
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
@@ -23,6 +23,7 @@ PKG_LICENSE_FILES:=COPYRIGHT
 PKG_MAINTAINER:=Felix Fietkau <nbd at nbd.name>
 
 PKG_FIXUP:=autoreconf
+PKG_CONFIG_DEPENDS:=CONFIG_PACKAGE_strace_libunwind
 PKG_INSTALL:=1
 
 include $(INCLUDE_DIR)/package.mk
@@ -39,6 +40,7 @@ define Package/strace
   SECTION:=utils
   CATEGORY:=Utilities
   TITLE:=System call tracer
+  DEPENDS:=+PACKAGE_strace_libunwind:libunwind
   URL:=http://strace.sourceforge.net/
 endef
 
@@ -47,6 +49,13 @@ A useful diagnostic, instructional, and debugging tool. Allows you to track what
 system calls a program makes while it is running.
 endef
 
+define Package/strace/config
+config PACKAGE_strace_libunwind
+	bool "Enable stack tracing support using libunwind (experimental)"
+	default n
+endef
+
+CONFIGURE_ARGS += --with-libunwind=$(if $(CONFIG_PACKAGE_strace_libunwind),yes,no)
 MAKE_FLAGS := \
 	CCOPT="$(TARGET_CFLAGS)"
 
-- 
2.6.4



From yszhou4tech at gmail.com  Wed Jun  8 19:20:32 2016
From: yszhou4tech at gmail.com (Yousong Zhou)
Date: Thu,  9 Jun 2016 10:20:32 +0800
Subject: [LEDE-DEV] [PATCH] uloop: use a waker for notifying sigchld and
	loop cancel events
Message-ID: <1465438832-20133-1-git-send-email-yszhou4tech@gmail.com>

Fix a race condition when do_sigchld, uloop_cancelled were set just
before epoll_wait(timeout=-1), resulting the loop stuck in the syscall
without noticing the events just happened

Signed-off-by: Yousong Zhou <yszhou4tech at gmail.com>
---
 uloop-epoll.c  |  2 +-
 uloop-kqueue.c |  2 +-
 uloop.c        | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++++++----
 3 files changed, 63 insertions(+), 6 deletions(-)

diff --git a/uloop-epoll.c b/uloop-epoll.c
index bb652fd..6014bea 100644
--- a/uloop-epoll.c
+++ b/uloop-epoll.c
@@ -23,7 +23,7 @@
 #define EPOLLRDHUP 0x2000
 #endif
 
-int uloop_init(void)
+static int uloop_init_pollfd(void)
 {
 	if (poll_fd >= 0)
 		return 0;
diff --git a/uloop-kqueue.c b/uloop-kqueue.c
index 0cb1c14..ba5595b 100644
--- a/uloop-kqueue.c
+++ b/uloop-kqueue.c
@@ -15,7 +15,7 @@
  * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
-int uloop_init(void)
+static int uloop_init_pollfd(void)
 {
 	struct timespec timeout = { 0, 0 };
 	struct kevent ev = {};
diff --git a/uloop.c b/uloop.c
index cd3de85..b59c31f 100644
--- a/uloop.c
+++ b/uloop.c
@@ -63,6 +63,11 @@ static bool do_sigchld = false;
 static struct uloop_fd_event cur_fds[ULOOP_MAX_EVENTS];
 static int cur_fd, cur_nfds;
 
+static int waker_pipe[2] = {-1, -1};
+static struct uloop_fd waker_fd;
+
+int uloop_fd_add(struct uloop_fd *sock, unsigned int flags);
+
 #ifdef USE_KQUEUE
 #include "uloop-kqueue.c"
 #endif
@@ -71,6 +76,45 @@ static int cur_fd, cur_nfds;
 #include "uloop-epoll.c"
 #endif
 
+static void waker_consume(struct uloop_fd *fd, unsigned int events)
+{
+	char buf[4];
+
+	while (read(fd->fd, buf, 4) > 0)
+		;
+}
+
+static int waker_init(void)
+{
+	if (waker_pipe[0] >= 0 && waker_pipe[1] >= 0)
+		return 0;
+
+	if (pipe(waker_pipe) < 0)
+		return -1;
+
+	fcntl(waker_pipe[0], F_SETFD, fcntl(waker_pipe[0], F_GETFD) | O_NONBLOCK);
+	fcntl(waker_pipe[1], F_SETFD, fcntl(waker_pipe[1], F_GETFD) | O_NONBLOCK);
+
+	waker_fd.fd = waker_pipe[0];
+	waker_fd.cb = waker_consume;
+	uloop_fd_add(&waker_fd, ULOOP_READ);
+
+	return 0;
+}
+
+int uloop_init(void)
+{
+	if (uloop_init_pollfd() < 0)
+		return -1;
+
+	if (waker_init() < 0) {
+		close(poll_fd);
+		poll_fd = -1;
+		return -1;
+	}
+	return 0;
+}
+
 static bool uloop_fd_stack_event(struct uloop_fd *fd, int events)
 {
 	struct uloop_fd_stack *cur;
@@ -330,12 +374,18 @@ static void uloop_handle_processes(void)
 
 static void uloop_handle_sigint(int signo)
 {
+	char buf[1] = {'w'};
+
 	uloop_cancelled = true;
+	write(waker_pipe[1], buf, 1);
 }
 
 static void uloop_sigchld(int signo)
 {
+	char buf[1] = {'w'};
+
 	do_sigchld = true;
+	write(waker_pipe[1], buf, 1);
 }
 
 static void uloop_install_handler(int signum, void (*handler)(int), struct sigaction* old, bool add)
@@ -477,11 +527,18 @@ void uloop_run(void)
 
 void uloop_done(void)
 {
-	if (poll_fd < 0)
-		return;
+	int i;
 
-	close(poll_fd);
-	poll_fd = -1;
+	if (poll_fd >= 0) {
+		close(poll_fd);
+		poll_fd = -1;
+	}
+	for (i = 0; i < ARRAY_SIZE(waker_pipe); i++) {
+		if (waker_pipe[i] >= 0) {
+			close(waker_pipe[i]);
+			waker_pipe[i] = -1;
+		}
+	}
 
 	uloop_clear_timeouts();
 	uloop_clear_processes();
-- 
2.6.4



From john at phrozen.org  Wed Jun  8 21:50:03 2016
From: john at phrozen.org (John Crispin)
Date: Thu, 9 Jun 2016 06:50:03 +0200
Subject: [LEDE-DEV] [PATCH] [ramips] Added NixCore X1 target V2
In-Reply-To: <0270e2f4-d504-ecf9-a3a9-8c2b9cf8618c@phrozen.org>
References: <5756126C.5060101@nixcores.com>
 <c1c05543-6b19-d94f-7feb-ef0802908090@phrozen.org>
 <57571CDF.8070205@nixcores.com>
 <0270e2f4-d504-ecf9-a3a9-8c2b9cf8618c@phrozen.org>
Message-ID: <08df5712-072c-0008-bb42-59347c9ff173@phrozen.org>

Hi Drew,

just sent a new version please.

	John

On 08/06/2016 20:52, John Crispin wrote:
> Hi Drew,
> 
> since CC a few things have changed. the new dts file looks good, i will
> merge it tomorrow, rebase the userland script changes and change the
> image generation code to the new style. i'll put the patch into my
> staging tree and let you know where to find it so you can test it.
> 
> Thanks,
> 	John
> 
> On 07/06/2016 21:13, Drew from NixCore wrote:
>> John,
>>
>> I took a look at the dtsi file and see how the dts is updating the
>> settings.  I have
>> a dts that builds, but I would like a sanity check before submitting the
>> patch again.
>>
>> http://pastebin.com/EunNmAf4
>>
>> If this looks good I will update the 16M DTS and then submit again.
>>
>> Thanks,
>>
>> Drew
>>
>> On 06/06/2016 11:12 PM, John Crispin wrote:
>>> Hi Drew,
>>>
>>> this patch seems to use the old devicetree layout and image building
>>> code. do you think you could rebase this and make it work ontop of
>>> latest source.git or do you need help to do that ? this patch wont apply
>>> as is.
>>>
>>> another question, did you build this yourself or is this a rebranded
>>> whitelabel product ? i think we already support this board (or one that
>>> looks almost identical, need to see if i can find it in my router zoo
>>> today)
>>>
>>>     John
>>>
>>> On 07/06/2016 02:16, Drew from NixCore wrote:
>>>> Added NixCore X1 ramips target http://nixcores.com. This builds 8M
>>>> and 16M
>>>> images
>>>>
>>>> Signed-off-by: Drew Gaylo <drew at nixcores.com>
>>>> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
>>>> b/target/linux/ramips/base-files/etc/board.d/02_network
>>>> index 4728c75..69c0125 100755
>>>> --- a/target/linux/ramips/base-files/etc/board.d/02_network
>>>> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
>>>> @@ -77,6 +77,7 @@ ramips_setup_interfaces()
>>>>       mt7628|\
>>>>       mzk-750dhp|\
>>>>       mzk-w300nh2|\
>>>> +    nixcore|\
>>>>       oy-0001|\
>>>>       pbr-m1|\
>>>>       psg1208|\
>>>> diff --git a/target/linux/ramips/base-files/lib/ramips.sh
>>>> b/target/linux/ramips/base-files/lib/ramips.sh
>>>> index cbe455d..76f0e43 100755
>>>> --- a/target/linux/ramips/base-files/lib/ramips.sh
>>>> +++ b/target/linux/ramips/base-files/lib/ramips.sh
>>>> @@ -316,6 +316,9 @@ ramips_board_detect() {
>>>>       *"NCS601W")
>>>>           name="ncs601w"
>>>>           ;;
>>>> +    *"NixcoreX1")
>>>> +        name="nixcore-x1"
>>>> +        ;;
>>>>       *"NW718")
>>>>           name="nw718"
>>>>           ;;
>>>> diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh
>>>> b/target/linux/ramips/base-files/lib/upgrade/platform.sh
>>>> index 91c9997..0094568 100755
>>>> --- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
>>>> +++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
>>>> @@ -94,6 +94,7 @@ platform_check_image() {
>>>>       mzk-w300nh2|\
>>>>       mzk-wdpr|\
>>>>       nbg-419n|\
>>>> +    nixcore|\
>>>>       nw718|\
>>>>       oy-0001|\
>>>>       pbr-m1|\
>>>> diff --git a/target/linux/ramips/dts/NIXCOREX1-16M.dts
>>>> b/target/linux/ramips/dts/NIXCOREX1-16M.dts
>>>> new file mode 100644
>>>> index 0000000..c7ec410
>>>> --- /dev/null
>>>> +++ b/target/linux/ramips/dts/NIXCOREX1-16M.dts
>>>> @@ -0,0 +1,186 @@
>>>> +/dts-v1/;
>>>> +
>>>> +/include/ "rt5350.dtsi"
>>>> +
>>>> +/ {
>>>> +    compatible = "NixcoreX1", "ralink,rt5350-soc";
>>>> +    model = "NixcoreX1";
>>>> +
>>>> +    palmbus at 10000000 {
>>>> +        /* Re-enable the gpio1 ports */
>>>> +        gpio1: gpio at 660 {
>>>> +            status = "okay";
>>>> +        };
>>>> +
>>>> +        i2c at 900 {
>>>> +            status = "okay";
>>>> +        };
>>>> +        uart at 500 {
>>>> +            status = "okay";
>>>> +            /* Mix of uart and gpio */
>>>> +            reset-names = "gpio uartf";
>>>> +        };
>>>> +        spi at b00 {
>>>> +            status = "okay";
>>>> +
>>>> +            m25p80 at 0 {
>>>> +                #address-cells = <1>;
>>>> +                #size-cells = <1>;
>>>> +                compatible = "s25fl064k";
>>>> +                reg = <0>;
>>>> +                linux,modalias = "m25p80", "s25fl064k";
>>>> +                spi-max-frequency = <10000000>;
>>>> +
>>>> +                partition at 0 {
>>>> +                    label = "uboot";
>>>> +                    reg = <0x0 0x30000>;
>>>> +                    read-only;
>>>> +                };
>>>> +
>>>> +                partition at 30000 {
>>>> +                    label = "uboot-env";
>>>> +                    reg = <0x30000 0x10000>;
>>>> +                    read-only;
>>>> +                };
>>>> +
>>>> +                factory: partition at 40000 {
>>>> +                    label = "factory";
>>>> +                    reg = <0x40000 0x10000>;
>>>> +                    read-only;
>>>> +                };
>>>> +
>>>> +                partition at 50000 {
>>>> +                    label = "firmware";
>>>> +                    reg = <0x50000 0x7b0000>;
>>>> +                };
>>>> +            };
>>>> +
>>>> +            spidev at 1 {
>>>> +                compatible = "linux,spidev";
>>>> +                spi-max-frequency = <10000000>;
>>>> +                reg = <1>;
>>>> +            };
>>>> +        };
>>>> +    };
>>>> +
>>>> +    pinctrl {
>>>> +        state_default: pinctrl0 {
>>>> +            gpio {
>>>> +                /* Associate the tjag, uartf and led groups with
>>>> gpio */
>>>> +                ralink,group = "jtag", "led", "spi_cs1";
>>>> +                /* How do we set individual pins? */
>>>> +                ralink,function = "gpio";
>>>> +            };
>>>> +        };
>>>> +    };
>>>> +
>>>> +    ethernet at 10100000 {
>>>> +        mtd-mac-address = <&factory 0x4>;
>>>> +    };
>>>> +
>>>> +    esw at 10110000 {
>>>> +        ralink,portmap = <0x17>;
>>>> +    };
>>>> +
>>>> +    wmac at 10180000 {
>>>> +        ralink,mtd-eeprom = <&factory 0>;
>>>> +    };
>>>> +
>>>> +    ehci at 101c0000 {
>>>> +        status = "okay";
>>>> +    };
>>>> +
>>>> +    ohci at 101c1000 {
>>>> +        status = "okay";
>>>> +    };
>>>> +
>>>> +    chosen {
>>>> +        bootargs = "console=ttyS1,57600";
>>>> +    };
>>>> +    gpio-export {
>>>> +        compatible = "gpio-export";
>>>> +        #size-cells = <0>;
>>>> +
>>>> +        gpio0 {
>>>> +            gpio-export,name = "gpio0";
>>>> +            gpio-export,direction_may_change = <1>;
>>>> +            gpios = <&gpio0 0 0>;
>>>> +        };
>>>> +
>>>> +        /* GPIOs 1-6 are I2C,SPI */
>>>> +
>>>> +        /* GPIO 7-14 are uart1 */
>>>> +
>>>> +        /* GPIOs 15 & 16 are uart2 */
>>>> +
>>>> +        /* JTAG */
>>>> +        gpio17 {
>>>> +            /* JTAG_TDO */
>>>> +            gpio-export,name = "gpio17";
>>>> +            gpio-export,direction_may_change = <1>;
>>>> +            gpios = <&gpio0 17 0>;
>>>> +        };
>>>> +        gpio18 {
>>>> +            /* JTAG_TDI */
>>>> +            gpio-export,name = "gpio18";
>>>> +            gpio-export,direction_may_change = <1>;
>>>> +            gpios = <&gpio0 18 0>;
>>>> +        };
>>>> +        gpio19 {
>>>> +            /* JTAG_TMS */
>>>> +            gpio-export,name = "gpio19";
>>>> +            gpio-export,direction_may_change = <1>;
>>>> +            gpios = <&gpio0 19 0>;
>>>> +        };
>>>> +        gpio20 {
>>>> +            /* JTAG_TCLK */
>>>> +            gpio-export,name = "gpio20";
>>>> +            gpio-export,direction_may_change = <1>;
>>>> +            gpios = <&gpio0 20 0>;
>>>> +        };
>>>> +        gpio21 {
>>>> +            /* JTAG_TRST_N */
>>>> +            gpio-export,name = "gpio21";
>>>> +            gpio-export,direction_may_change = <1>;
>>>> +            gpios = <&gpio0 21 0>;
>>>> +        };
>>>> +
>>>> +        /* ETH LEDs */
>>>> +        /*
>>>> +        gpio22 {
>>>> +            gpio-export,name = "gpio22";
>>>> +            gpio-export,direction_may_change = <1>;
>>>> +            gpios = <&gpio1 0 0>;
>>>> +        };
>>>> +        gpio23 {
>>>> +            gpio-export,name = "gpio23";
>>>> +            gpio-export,direction_may_change = <1>;
>>>> +            gpios = <&gpio1 1 0>;
>>>> +        };
>>>> +        gpio24 {
>>>> +            gpio-export,name = "gpio24";
>>>> +            gpio-export,direction_may_change = <1>;
>>>> +            gpios = <&gpio1 2 0>;
>>>> +        };
>>>> +        gpio25 {
>>>> +            gpio-export,name = "gpio25";
>>>> +            gpio-export,direction_may_change = <1>;
>>>> +            gpios = <&gpio1 3 0>;
>>>> +        };
>>>> +        */
>>>> +        gpio26 {
>>>> +            /* ETH4_LED */
>>>> +            gpio-export,name = "gpio26";
>>>> +            gpio-export,direction_may_change = <1>;
>>>> +            gpios = <&gpio1 4 0>;
>>>> +        };
>>>> +
>>>> +        gpio27 {
>>>> +            /* spi_cs1 */
>>>> +            gpio-export,name = "gpio27";
>>>> +            gpio-export,direction_may_change = <1>;
>>>> +            gpios = <&gpio1 5 0>;
>>>> +        };
>>>> +    };
>>>> +
>>>> +};
>>>> diff --git a/target/linux/ramips/dts/NIXCOREX1-8M.dts
>>>> b/target/linux/ramips/dts/NIXCOREX1-8M.dts
>>>> new file mode 100644
>>>> index 0000000..c7ec410
>>>> --- /dev/null
>>>> +++ b/target/linux/ramips/dts/NIXCOREX1-8M.dts
>>>> @@ -0,0 +1,186 @@
>>>> +/dts-v1/;
>>>> +
>>>> +/include/ "rt5350.dtsi"
>>>> +
>>>> +/ {
>>>> +    compatible = "NixcoreX1", "ralink,rt5350-soc";
>>>> +    model = "NixcoreX1";
>>>> +
>>>> +    palmbus at 10000000 {
>>>> +        /* Re-enable the gpio1 ports */
>>>> +        gpio1: gpio at 660 {
>>>> +            status = "okay";
>>>> +        };
>>>> +
>>>> +        i2c at 900 {
>>>> +            status = "okay";
>>>> +        };
>>>> +        uart at 500 {
>>>> +            status = "okay";
>>>> +            /* Mix of uart and gpio */
>>>> +            reset-names = "gpio uartf";
>>>> +        };
>>>> +        spi at b00 {
>>>> +            status = "okay";
>>>> +
>>>> +            m25p80 at 0 {
>>>> +                #address-cells = <1>;
>>>> +                #size-cells = <1>;
>>>> +                compatible = "s25fl064k";
>>>> +                reg = <0>;
>>>> +                linux,modalias = "m25p80", "s25fl064k";
>>>> +                spi-max-frequency = <10000000>;
>>>> +
>>>> +                partition at 0 {
>>>> +                    label = "uboot";
>>>> +                    reg = <0x0 0x30000>;
>>>> +                    read-only;
>>>> +                };
>>>> +
>>>> +                partition at 30000 {
>>>> +                    label = "uboot-env";
>>>> +                    reg = <0x30000 0x10000>;
>>>> +                    read-only;
>>>> +                };
>>>> +
>>>> +                factory: partition at 40000 {
>>>> +                    label = "factory";
>>>> +                    reg = <0x40000 0x10000>;
>>>> +                    read-only;
>>>> +                };
>>>> +
>>>> +                partition at 50000 {
>>>> +                    label = "firmware";
>>>> +                    reg = <0x50000 0x7b0000>;
>>>> +                };
>>>> +            };
>>>> +
>>>> +            spidev at 1 {
>>>> +                compatible = "linux,spidev";
>>>> +                spi-max-frequency = <10000000>;
>>>> +                reg = <1>;
>>>> +            };
>>>> +        };
>>>> +    };
>>>> +
>>>> +    pinctrl {
>>>> +        state_default: pinctrl0 {
>>>> +            gpio {
>>>> +                /* Associate the tjag, uartf and led groups with
>>>> gpio */
>>>> +                ralink,group = "jtag", "led", "spi_cs1";
>>>> +                /* How do we set individual pins? */
>>>> +                ralink,function = "gpio";
>>>> +            };
>>>> +        };
>>>> +    };
>>>> +
>>>> +    ethernet at 10100000 {
>>>> +        mtd-mac-address = <&factory 0x4>;
>>>> +    };
>>>> +
>>>> +    esw at 10110000 {
>>>> +        ralink,portmap = <0x17>;
>>>> +    };
>>>> +
>>>> +    wmac at 10180000 {
>>>> +        ralink,mtd-eeprom = <&factory 0>;
>>>> +    };
>>>> +
>>>> +    ehci at 101c0000 {
>>>> +        status = "okay";
>>>> +    };
>>>> +
>>>> +    ohci at 101c1000 {
>>>> +        status = "okay";
>>>> +    };
>>>> +
>>>> +    chosen {
>>>> +        bootargs = "console=ttyS1,57600";
>>>> +    };
>>>> +    gpio-export {
>>>> +        compatible = "gpio-export";
>>>> +        #size-cells = <0>;
>>>> +
>>>> +        gpio0 {
>>>> +            gpio-export,name = "gpio0";
>>>> +            gpio-export,direction_may_change = <1>;
>>>> +            gpios = <&gpio0 0 0>;
>>>> +        };
>>>> +
>>>> +        /* GPIOs 1-6 are I2C,SPI */
>>>> +
>>>> +        /* GPIO 7-14 are uart1 */
>>>> +
>>>> +        /* GPIOs 15 & 16 are uart2 */
>>>> +
>>>> +        /* JTAG */
>>>> +        gpio17 {
>>>> +            /* JTAG_TDO */
>>>> +            gpio-export,name = "gpio17";
>>>> +            gpio-export,direction_may_change = <1>;
>>>> +            gpios = <&gpio0 17 0>;
>>>> +        };
>>>> +        gpio18 {
>>>> +            /* JTAG_TDI */
>>>> +            gpio-export,name = "gpio18";
>>>> +            gpio-export,direction_may_change = <1>;
>>>> +            gpios = <&gpio0 18 0>;
>>>> +        };
>>>> +        gpio19 {
>>>> +            /* JTAG_TMS */
>>>> +            gpio-export,name = "gpio19";
>>>> +            gpio-export,direction_may_change = <1>;
>>>> +            gpios = <&gpio0 19 0>;
>>>> +        };
>>>> +        gpio20 {
>>>> +            /* JTAG_TCLK */
>>>> +            gpio-export,name = "gpio20";
>>>> +            gpio-export,direction_may_change = <1>;
>>>> +            gpios = <&gpio0 20 0>;
>>>> +        };
>>>> +        gpio21 {
>>>> +            /* JTAG_TRST_N */
>>>> +            gpio-export,name = "gpio21";
>>>> +            gpio-export,direction_may_change = <1>;
>>>> +            gpios = <&gpio0 21 0>;
>>>> +        };
>>>> +
>>>> +        /* ETH LEDs */
>>>> +        /*
>>>> +        gpio22 {
>>>> +            gpio-export,name = "gpio22";
>>>> +            gpio-export,direction_may_change = <1>;
>>>> +            gpios = <&gpio1 0 0>;
>>>> +        };
>>>> +        gpio23 {
>>>> +            gpio-export,name = "gpio23";
>>>> +            gpio-export,direction_may_change = <1>;
>>>> +            gpios = <&gpio1 1 0>;
>>>> +        };
>>>> +        gpio24 {
>>>> +            gpio-export,name = "gpio24";
>>>> +            gpio-export,direction_may_change = <1>;
>>>> +            gpios = <&gpio1 2 0>;
>>>> +        };
>>>> +        gpio25 {
>>>> +            gpio-export,name = "gpio25";
>>>> +            gpio-export,direction_may_change = <1>;
>>>> +            gpios = <&gpio1 3 0>;
>>>> +        };
>>>> +        */
>>>> +        gpio26 {
>>>> +            /* ETH4_LED */
>>>> +            gpio-export,name = "gpio26";
>>>> +            gpio-export,direction_may_change = <1>;
>>>> +            gpios = <&gpio1 4 0>;
>>>> +        };
>>>> +
>>>> +        gpio27 {
>>>> +            /* spi_cs1 */
>>>> +            gpio-export,name = "gpio27";
>>>> +            gpio-export,direction_may_change = <1>;
>>>> +            gpios = <&gpio1 5 0>;
>>>> +        };
>>>> +    };
>>>> +
>>>> +};
>>>> diff --git a/target/linux/ramips/image/rt305x.mk
>>>> b/target/linux/ramips/image/rt305x.mk
>>>> index da7fc46..db12a8e 100644
>>>> --- a/target/linux/ramips/image/rt305x.mk
>>>> +++ b/target/linux/ramips/image/rt305x.mk
>>>> @@ -100,6 +100,21 @@ define BuildFirmware/HLKRM04/initramfs
>>>>       mkhilinkfw -e -i$(call imgname,$(1),$(2))-uImage.bin -o $(call
>>>> imgname,$(1),$(2))-factory.bin;
>>>>   endef
>>>>
>>>> +# This is called to build the nixcore image.  Build both 8MB and 16MB
>>>> +nixcore_8mb_mtd_size=8060928
>>>> +nixcore_16mb_mtd_size=16449536
>>>> +define BuildFirmware/NIXCOREX1/squashfs
>>>> +# Args are XXX, nixcore-mM and NIXCOREX1-xM
>>>> +    $(call
>>>> BuildFirmware/CustomFlash/$(1),$(1),$(2)-8M,$(3)-8M,$(nixcore_8mb_mtd_size))
>>>>
>>>>
>>>> +    $(call
>>>> BuildFirmware/CustomFlash/$(1),$(1),$(2)-16M,$(3)-16M,$(nixcore_16mb_mtd_size))
>>>>
>>>>
>>>> +    # Can do somethings here after the build?
>>>> +endef
>>>> +define BuildFirmware/NIXCOREX1/initramfs
>>>> +# Args are XXXX, nixcore-mM and NIXCOREX1-xM
>>>> +    $(call BuildFirmware/OF/initramfs,$(1),$(2)-8M,$(3)-8M)
>>>> +    $(call BuildFirmware/OF/initramfs,$(1),$(2)-16M,$(3)-16M)
>>>> +endef
>>>> +
>>>>   vocore_8mb_mtd_size=8060928
>>>>   vocore_16mb_mtd_size=16449536
>>>>   define BuildFirmware/VOCORE/squashfs
>>>> @@ -257,6 +272,7 @@ Image/Build/Profile/NBG-419N=$(call
>>>> BuildFirmware/Default4M/$(1),$(1),nbg-419n,N
>>>>   Image/Build/Profile/MZKW300NH2=$(call
>>>> BuildFirmware/Edimax/$(1),$(1),mzk-w300nh2,MZK-W300NH2,$(mzkw300nh2_mtd_size),CSYS,RN52,0x50000,0xc0000)
>>>>
>>>>
>>>>   Image/Build/Profile/MZKWDPR=$(call
>>>> BuildFirmware/Default8M/$(1),$(1),mzk-wdpr,MZK-WDPR)
>>>>   Image/Build/Profile/NCS601W=$(call
>>>> BuildFirmware/Default8M/$(1),$(1),ncs601W,NCS601W)
>>>> +Image/Build/Profile/NIXCOREX1=$(call
>>>> BuildFirmware/NIXCOREX1/$(1),$(1),nixcorex1,NIXCOREX1)
>>>>   nw718_mtd_size=3801088
>>>>   Image/Build/Profile/NW718=$(call
>>>> BuildFirmware/CustomFlashFactory/$(1),$(1),nw718m,NW718,$(nw718_mtd_size),ARA1B4NCRNW718;1,factory)
>>>>
>>>>
>>>>   Image/Build/Profile/M2M=$(call
>>>> BuildFirmware/Default8M/$(1),$(1),m2m,M2M,Linux Kernel Image)
>>>> @@ -353,6 +369,7 @@ define Image/Build/Profile/Default
>>>>       $(call Image/Build/Profile/MZKWDPR,$(1))
>>>>       $(call Image/Build/Profile/NBG-419N,$(1))
>>>>       $(call Image/Build/Profile/NCS601W,$(1))
>>>> +    $(call Image/Build/Profile/NIXCOREX1,$(1))
>>>>       $(call Image/Build/Profile/NW718,$(1))
>>>>       $(call Image/Build/Profile/MINIEMBWIFI,$(1))
>>>>       $(call Image/Build/Profile/MINIEMBPLUG,$(1))
>>>> diff --git a/target/linux/ramips/rt305x/profiles/nixcore.mk
>>>> b/target/linux/ramips/rt305x/profiles/nixcore.mk
>>>> new file mode 100644
>>>> index 0000000..22dee9b
>>>> --- /dev/null
>>>> +++ b/target/linux/ramips/rt305x/profiles/nixcore.mk
>>>> @@ -0,0 +1,20 @@
>>>> +#
>>>> +# Copyright (C) 2014 OpenWrt.org
>>>> +#
>>>> +# This is free software, licensed under the GNU General Public
>>>> License v2.
>>>> +# See /LICENSE for more information.
>>>> +#
>>>> +
>>>> +define Profile/NIXCOREX1
>>>> +    NAME:=NixcoreX1
>>>> +    PACKAGES:=\
>>>> +        kmod-usb-core kmod-usb-ohci kmod-usb2 \
>>>> +        kmod-i2c-core kmod-i2c-ralink \
>>>> +        kmod-spi-dev
>>>> +endef
>>>> +
>>>> +define Profile/NIXCOREX1/Description
>>>> +    Package set for Nixcore X1 board
>>>> +endef
>>>> +
>>>> +$(eval $(call Profile,NIXCOREX1))
>>>>
>>>>
>>>> _______________________________________________
>>>> Lede-dev mailing list
>>>> Lede-dev at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 


From mats.dev.list at gmail.com  Thu Jun  9 00:27:11 2016
From: mats.dev.list at gmail.com (Mats Karrman)
Date: Thu, 9 Jun 2016 09:27:11 +0200
Subject: [LEDE-DEV] libubox, procd: init process hangs
In-Reply-To: <ab4ba37d-f312-dd2f-8e22-a512c1533d1f@gmail.com>
References: <f2dd22dd-8fff-4521-5e3f-cdbf6faa0275@gmail.com>
 <CAECwjAjrVG3M6EtYCtB45SYZNQhRJgC7CETT8u6+aypotF9c+g@mail.gmail.com>
 <ab4ba37d-f312-dd2f-8e22-a512c1533d1f@gmail.com>
Message-ID: <57591A4F.8040902@gmail.com>



On 2016-06-08 23:43, Xinxing Hu wrote:
> Hi Yousong,
>
> Thanks a lot for you patch. I tried it a little bit, and till now 
> everything looks OK. It seems this issue is solved by your patch.
>
> Not sure whether Mats (the original reporter of this issue) still see 
> the issue or not.
Unfortunately I have not had the opportunity to test the patch yet 
because of higher prioritized work,
I'll try to do it shortly though.

@Felix: Have you had the time to take a look at the patch? Any comments?

BR // Mats
>
> Best Regards,
> Xinxing
>



From Alexey.Brodkin at synopsys.com  Thu Jun  9 02:38:34 2016
From: Alexey.Brodkin at synopsys.com (Alexey Brodkin)
Date: Thu,  9 Jun 2016 12:38:34 +0300
Subject: [LEDE-DEV] [PATCH] toolchain/gdb: Use correct folder name for ARC
	patches
Message-ID: <1465465114-15281-1-git-send-email-abrodkin@synopsys.com>

Even though ARC tools were released as arc-2016.03
we have a little bit different version name for GDB.
That's because both Binutils and GDB come from the same
git repo but from different branches (and so different tags).

Also removing an extra patch that made its way into release.

Signed-off-by: Alexey Brodkin <abrodkin at synopsys.com>
---
 .../100-no_extern_inline.patch                              |  0
 .../{arc-2016.03 => arc-2016.03-gdb}/110-no_testsuite.patch |  0
 .../120-fix-compile-flag-mismatch.patch                     |  0
 .../gdb/patches/arc-2016.03/200-arc-fix-target-mask.patch   | 13 -------------
 4 files changed, 13 deletions(-)
 rename toolchain/gdb/patches/{arc-2016.03 => arc-2016.03-gdb}/100-no_extern_inline.patch (100%)
 rename toolchain/gdb/patches/{arc-2016.03 => arc-2016.03-gdb}/110-no_testsuite.patch (100%)
 rename toolchain/gdb/patches/{arc-2016.03 => arc-2016.03-gdb}/120-fix-compile-flag-mismatch.patch (100%)
 delete mode 100644 toolchain/gdb/patches/arc-2016.03/200-arc-fix-target-mask.patch

diff --git a/toolchain/gdb/patches/arc-2016.03/100-no_extern_inline.patch b/toolchain/gdb/patches/arc-2016.03-gdb/100-no_extern_inline.patch
similarity index 100%
rename from toolchain/gdb/patches/arc-2016.03/100-no_extern_inline.patch
rename to toolchain/gdb/patches/arc-2016.03-gdb/100-no_extern_inline.patch
diff --git a/toolchain/gdb/patches/arc-2016.03/110-no_testsuite.patch b/toolchain/gdb/patches/arc-2016.03-gdb/110-no_testsuite.patch
similarity index 100%
rename from toolchain/gdb/patches/arc-2016.03/110-no_testsuite.patch
rename to toolchain/gdb/patches/arc-2016.03-gdb/110-no_testsuite.patch
diff --git a/toolchain/gdb/patches/arc-2016.03/120-fix-compile-flag-mismatch.patch b/toolchain/gdb/patches/arc-2016.03-gdb/120-fix-compile-flag-mismatch.patch
similarity index 100%
rename from toolchain/gdb/patches/arc-2016.03/120-fix-compile-flag-mismatch.patch
rename to toolchain/gdb/patches/arc-2016.03-gdb/120-fix-compile-flag-mismatch.patch
diff --git a/toolchain/gdb/patches/arc-2016.03/200-arc-fix-target-mask.patch b/toolchain/gdb/patches/arc-2016.03/200-arc-fix-target-mask.patch
deleted file mode 100644
index 7e51d588..0000000
--- a/toolchain/gdb/patches/arc-2016.03/200-arc-fix-target-mask.patch
+++ /dev/null
@@ -1,13 +0,0 @@
-diff --git a/bfd/config.bfd b/bfd/config.bfd
-index 5145d4a..a9c9c99 100644
---- a/bfd/config.bfd
-+++ b/bfd/config.bfd
-@@ -275,7 +275,7 @@ case "${targ}" in
-     targ_defvec=am33_elf32_linux_vec
-     ;;
- 
--  arc*-*-elf* | arc*-*-linux-uclibc*)
-+  arc*-*-elf* | arc*-*-linux-*)
-     targ_defvec=arc_elf32_le_vec
-     targ_selvecs=arc_elf32_be_vec
-     ;;
-- 
2.5.0



From champetier.etienne at gmail.com  Thu Jun  9 06:03:00 2016
From: champetier.etienne at gmail.com (Etienne CHAMPETIER)
Date: Thu,  9 Jun 2016 13:03:00 +0000
Subject: [LEDE-DEV] [PATCH ubox] getrandom: add helper for getrandom()
	syscall
Message-ID: <1465477380-42771-1-git-send-email-champetier.etienne@gmail.com>

getrandom() was introduced in version 3.17 of the Linux kernel.
By default getrandom() block until /dev/urandom pool has been initialized
and then read from it.
Read buffer is 256 bytes so getrandom() calls always succeed.

First usage will be to save a seed for /dev/urandom.

Signed-off-by: Etienne CHAMPETIER <champetier.etienne at gmail.com>
---
 CMakeLists.txt |  5 +++++
 getrandom.c    | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 63 insertions(+)
 create mode 100644 getrandom.c

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 834b5b6..73e8753 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -16,6 +16,11 @@ IF(DEBUG)
   ADD_DEFINITIONS(-DDEBUG -g3)
 ENDIF()
 
+ADD_EXECUTABLE(getrandom getrandom.c)
+INSTALL(TARGETS getrandom
+	RUNTIME DESTINATION bin
+)
+
 ADD_EXECUTABLE(kmodloader kmodloader.c)
 TARGET_LINK_LIBRARIES(kmodloader ubox)
 
diff --git a/getrandom.c b/getrandom.c
new file mode 100644
index 0000000..9671202
--- /dev/null
+++ b/getrandom.c
@@ -0,0 +1,58 @@
+/*
+ * Copyright (C) 2016 Etienne Champetier <champetier.etienne at gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#define _GNU_SOURCE
+#include <errno.h>
+#include <linux/random.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <sys/syscall.h>
+#include <unistd.h>
+
+#define ERROR_EXIT(fmt, ...) do { \
+        fprintf(stderr, fmt, ## __VA_ARGS__); \
+        return EXIT_FAILURE; \
+        } while (0)
+
+static int usage(char *name)
+{
+    fprintf(stderr, "Usage: %s <nb>\n", name);
+    fprintf(stderr, " => return <nb> bytes from getrandom()\n");
+    return EXIT_FAILURE;
+}
+
+int main(int argc, char *argv[])
+{
+    if (argc != 2)
+        return usage(argv[0]);
+
+    if (isatty(STDOUT_FILENO))
+        ERROR_EXIT("Not outputting random to a tty\n");
+
+    int nbtot = atoi(argv[1]);
+    if (nbtot < 1)
+        ERROR_EXIT("Invalid <nb> param (must be > 0)\n");
+
+    char buf[256];
+    int len = sizeof(buf);
+    while (nbtot > 0) {
+        if (nbtot <= sizeof(buf))
+            len = nbtot;
+        if (syscall(SYS_getrandom, buf, len, 0) == -1)
+            ERROR_EXIT("getrandom() failed: %s\n", strerror(errno));
+        if (write(STDOUT_FILENO, buf, len) != len)
+            ERROR_EXIT("write() failed: %s\n", strerror(errno));
+        nbtot -= sizeof(buf);
+    }
+}
-- 
1.9.1



From john at phrozen.org  Thu Jun  9 06:03:35 2016
From: john at phrozen.org (John Crispin)
Date: Thu, 9 Jun 2016 15:03:35 +0200
Subject: [LEDE-DEV] cavium: Ignore MEM boot param when too small
In-Reply-To: <57582266.8020105@gmail.com>
References: <57582266.8020105@gmail.com>
Message-ID: <ff0a6720-c963-dbe0-f176-206da8f363e6@phrozen.org>



On 08/06/2016 15:49, Micha? Osowiecki wrote:
> Cisco RV0XX u-boot sets MEM=2048 as boot param. We assume that at least
> 4MB (mem_alloc_size) of ram is needed to run linux on cavium boards, so
> if mem < 4M - ignore it and set default value
> 
> 
> Signed-off-by: Micha? Osowiecki <michal.osowiecki at gmail.com>
> 

Hi Micha?,

how much memory does the board have ? maybe they just forgot the "<< 20"
part ?

	John

> --- a/arch/mips/cavium-octeon/setup.c   2016-06-06 18:15:32.000000000 +0200
> +++ b/arch/mips/cavium-octeon/setup.c   2016-06-08 15:28:56.642919151 +0200
> @@ -941,6 +941,11 @@
>          * to consistently work.
>          */
>         mem_alloc_size = 4 << 20;
> +
> +       /* Ignore bootarg MEM <= 4MB */
> +       if (MAX_MEMORY <= mem_alloc_size)
> +               MAX_MEMORY = 512ull << 20;
> +
>         if (mem_alloc_size > MAX_MEMORY)
>                 mem_alloc_size = MAX_MEMORY;
> 
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


From john at phrozen.org  Thu Jun  9 07:17:38 2016
From: john at phrozen.org (John Crispin)
Date: Thu, 9 Jun 2016 16:17:38 +0200
Subject: [LEDE-DEV] [PATCH ubox] getrandom: add helper for getrandom()
 syscall
In-Reply-To: <1465477380-42771-1-git-send-email-champetier.etienne@gmail.com>
References: <1465477380-42771-1-git-send-email-champetier.etienne@gmail.com>
Message-ID: <42254205-bceb-e072-91fc-dadbf896d548@phrozen.org>

Hi Etienne,

pushed the patch to ubox.git and updated the ubox package inside my
staging tree. should the tool be installed to /usr/bin ? if not let me
know and i will fix the staged commit.

	John

On 09/06/2016 15:03, Etienne CHAMPETIER wrote:
> getrandom() was introduced in version 3.17 of the Linux kernel.
> By default getrandom() block until /dev/urandom pool has been initialized
> and then read from it.
> Read buffer is 256 bytes so getrandom() calls always succeed.
> 
> First usage will be to save a seed for /dev/urandom.
> 
> Signed-off-by: Etienne CHAMPETIER <champetier.etienne at gmail.com>
> ---
>  CMakeLists.txt |  5 +++++
>  getrandom.c    | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 63 insertions(+)
>  create mode 100644 getrandom.c
> 
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index 834b5b6..73e8753 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -16,6 +16,11 @@ IF(DEBUG)
>    ADD_DEFINITIONS(-DDEBUG -g3)
>  ENDIF()
>  
> +ADD_EXECUTABLE(getrandom getrandom.c)
> +INSTALL(TARGETS getrandom
> +	RUNTIME DESTINATION bin
> +)
> +
>  ADD_EXECUTABLE(kmodloader kmodloader.c)
>  TARGET_LINK_LIBRARIES(kmodloader ubox)
>  
> diff --git a/getrandom.c b/getrandom.c
> new file mode 100644
> index 0000000..9671202
> --- /dev/null
> +++ b/getrandom.c
> @@ -0,0 +1,58 @@
> +/*
> + * Copyright (C) 2016 Etienne Champetier <champetier.etienne at gmail.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +#define _GNU_SOURCE
> +#include <errno.h>
> +#include <linux/random.h>
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <string.h>
> +#include <sys/syscall.h>
> +#include <unistd.h>
> +
> +#define ERROR_EXIT(fmt, ...) do { \
> +        fprintf(stderr, fmt, ## __VA_ARGS__); \
> +        return EXIT_FAILURE; \
> +        } while (0)
> +
> +static int usage(char *name)
> +{
> +    fprintf(stderr, "Usage: %s <nb>\n", name);
> +    fprintf(stderr, " => return <nb> bytes from getrandom()\n");
> +    return EXIT_FAILURE;
> +}
> +
> +int main(int argc, char *argv[])
> +{
> +    if (argc != 2)
> +        return usage(argv[0]);
> +
> +    if (isatty(STDOUT_FILENO))
> +        ERROR_EXIT("Not outputting random to a tty\n");
> +
> +    int nbtot = atoi(argv[1]);
> +    if (nbtot < 1)
> +        ERROR_EXIT("Invalid <nb> param (must be > 0)\n");
> +
> +    char buf[256];
> +    int len = sizeof(buf);
> +    while (nbtot > 0) {
> +        if (nbtot <= sizeof(buf))
> +            len = nbtot;
> +        if (syscall(SYS_getrandom, buf, len, 0) == -1)
> +            ERROR_EXIT("getrandom() failed: %s\n", strerror(errno));
> +        if (write(STDOUT_FILENO, buf, len) != len)
> +            ERROR_EXIT("write() failed: %s\n", strerror(errno));
> +        nbtot -= sizeof(buf);
> +    }
> +}
> 


From champetier.etienne at gmail.com  Thu Jun  9 08:02:16 2016
From: champetier.etienne at gmail.com (Etienne Champetier)
Date: Thu, 9 Jun 2016 18:02:16 +0300
Subject: [LEDE-DEV] [PATCH ubox] getrandom: add helper for getrandom()
	syscall
In-Reply-To: <42254205-bceb-e072-91fc-dadbf896d548@phrozen.org>
References: <1465477380-42771-1-git-send-email-champetier.etienne@gmail.com>
 <42254205-bceb-e072-91fc-dadbf896d548@phrozen.org>
Message-ID: <CAOdf3gqr_vFLYXxt7MGJ6tYsdwfHZgbo_K438cbAx8H-wahdfw@mail.gmail.com>

Hi,

Everything is fine except your computer clock ;)
ubox commit:
author    Etienne CHAMPETIER <champetier.etienne at gmail.com>
    Thu, 9 Jun 2016 16:03:00 +0300 (13:03 +0000)
committer    John Crispin <john at phrozen.org>
    Wed, 8 Jun 2016 01:19:24 +0300 (00:19 +0200)

staging commit:
author    John Crispin <john at phrozen.org>
    Wed, 8 Jun 2016 01:22:16 +0300 (00:22 +0200)
committer    John Crispin <john at phrozen.org>
    Wed, 8 Jun 2016 01:56:48 +0300

Thanks
Etienne

2016-06-09 17:17 GMT+03:00 John Crispin <john at phrozen.org>:
> Hi Etienne,
>
> pushed the patch to ubox.git and updated the ubox package inside my
> staging tree. should the tool be installed to /usr/bin ? if not let me
> know and i will fix the staged commit.
>
>         John
>
> On 09/06/2016 15:03, Etienne CHAMPETIER wrote:
>> getrandom() was introduced in version 3.17 of the Linux kernel.
>> By default getrandom() block until /dev/urandom pool has been initialized
>> and then read from it.
>> Read buffer is 256 bytes so getrandom() calls always succeed.
>>
>> First usage will be to save a seed for /dev/urandom.
>>
>> Signed-off-by: Etienne CHAMPETIER <champetier.etienne at gmail.com>
>> ---
>>  CMakeLists.txt |  5 +++++
>>  getrandom.c    | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>  2 files changed, 63 insertions(+)
>>  create mode 100644 getrandom.c
>>
>> diff --git a/CMakeLists.txt b/CMakeLists.txt
>> index 834b5b6..73e8753 100644
>> --- a/CMakeLists.txt
>> +++ b/CMakeLists.txt
>> @@ -16,6 +16,11 @@ IF(DEBUG)
>>    ADD_DEFINITIONS(-DDEBUG -g3)
>>  ENDIF()
>>
>> +ADD_EXECUTABLE(getrandom getrandom.c)
>> +INSTALL(TARGETS getrandom
>> +     RUNTIME DESTINATION bin
>> +)
>> +
>>  ADD_EXECUTABLE(kmodloader kmodloader.c)
>>  TARGET_LINK_LIBRARIES(kmodloader ubox)
>>
>> diff --git a/getrandom.c b/getrandom.c
>> new file mode 100644
>> index 0000000..9671202
>> --- /dev/null
>> +++ b/getrandom.c
>> @@ -0,0 +1,58 @@
>> +/*
>> + * Copyright (C) 2016 Etienne Champetier <champetier.etienne at gmail.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +#define _GNU_SOURCE
>> +#include <errno.h>
>> +#include <linux/random.h>
>> +#include <stdio.h>
>> +#include <stdlib.h>
>> +#include <string.h>
>> +#include <sys/syscall.h>
>> +#include <unistd.h>
>> +
>> +#define ERROR_EXIT(fmt, ...) do { \
>> +        fprintf(stderr, fmt, ## __VA_ARGS__); \
>> +        return EXIT_FAILURE; \
>> +        } while (0)
>> +
>> +static int usage(char *name)
>> +{
>> +    fprintf(stderr, "Usage: %s <nb>\n", name);
>> +    fprintf(stderr, " => return <nb> bytes from getrandom()\n");
>> +    return EXIT_FAILURE;
>> +}
>> +
>> +int main(int argc, char *argv[])
>> +{
>> +    if (argc != 2)
>> +        return usage(argv[0]);
>> +
>> +    if (isatty(STDOUT_FILENO))
>> +        ERROR_EXIT("Not outputting random to a tty\n");
>> +
>> +    int nbtot = atoi(argv[1]);
>> +    if (nbtot < 1)
>> +        ERROR_EXIT("Invalid <nb> param (must be > 0)\n");
>> +
>> +    char buf[256];
>> +    int len = sizeof(buf);
>> +    while (nbtot > 0) {
>> +        if (nbtot <= sizeof(buf))
>> +            len = nbtot;
>> +        if (syscall(SYS_getrandom, buf, len, 0) == -1)
>> +            ERROR_EXIT("getrandom() failed: %s\n", strerror(errno));
>> +        if (write(STDOUT_FILENO, buf, len) != len)
>> +            ERROR_EXIT("write() failed: %s\n", strerror(errno));
>> +        nbtot -= sizeof(buf);
>> +    }
>> +}
>>
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


From john at phrozen.org  Thu Jun  9 08:04:46 2016
From: john at phrozen.org (John Crispin)
Date: Thu, 9 Jun 2016 17:04:46 +0200
Subject: [LEDE-DEV] [PATCH ubox] getrandom: add helper for getrandom()
 syscall
In-Reply-To: <CAOdf3gqr_vFLYXxt7MGJ6tYsdwfHZgbo_K438cbAx8H-wahdfw@mail.gmail.com>
References: <1465477380-42771-1-git-send-email-champetier.etienne@gmail.com>
 <42254205-bceb-e072-91fc-dadbf896d548@phrozen.org>
 <CAOdf3gqr_vFLYXxt7MGJ6tYsdwfHZgbo_K438cbAx8H-wahdfw@mail.gmail.com>
Message-ID: <4e47f6ff-fcdc-fd7c-3372-361691eeea5a@phrozen.org>

its a vm that takes a few moments to get the real time hen coming out of
sleep ;)


On 09/06/2016 17:02, Etienne Champetier wrote:
> Hi,
> 
> Everything is fine except your computer clock ;)
> ubox commit:
> author    Etienne CHAMPETIER <champetier.etienne at gmail.com>
>     Thu, 9 Jun 2016 16:03:00 +0300 (13:03 +0000)
> committer    John Crispin <john at phrozen.org>
>     Wed, 8 Jun 2016 01:19:24 +0300 (00:19 +0200)
> 
> staging commit:
> author    John Crispin <john at phrozen.org>
>     Wed, 8 Jun 2016 01:22:16 +0300 (00:22 +0200)
> committer    John Crispin <john at phrozen.org>
>     Wed, 8 Jun 2016 01:56:48 +0300
> 
> Thanks
> Etienne
> 
> 2016-06-09 17:17 GMT+03:00 John Crispin <john at phrozen.org>:
>> Hi Etienne,
>>
>> pushed the patch to ubox.git and updated the ubox package inside my
>> staging tree. should the tool be installed to /usr/bin ? if not let me
>> know and i will fix the staged commit.
>>
>>         John
>>
>> On 09/06/2016 15:03, Etienne CHAMPETIER wrote:
>>> getrandom() was introduced in version 3.17 of the Linux kernel.
>>> By default getrandom() block until /dev/urandom pool has been initialized
>>> and then read from it.
>>> Read buffer is 256 bytes so getrandom() calls always succeed.
>>>
>>> First usage will be to save a seed for /dev/urandom.
>>>
>>> Signed-off-by: Etienne CHAMPETIER <champetier.etienne at gmail.com>
>>> ---
>>>  CMakeLists.txt |  5 +++++
>>>  getrandom.c    | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>  2 files changed, 63 insertions(+)
>>>  create mode 100644 getrandom.c
>>>
>>> diff --git a/CMakeLists.txt b/CMakeLists.txt
>>> index 834b5b6..73e8753 100644
>>> --- a/CMakeLists.txt
>>> +++ b/CMakeLists.txt
>>> @@ -16,6 +16,11 @@ IF(DEBUG)
>>>    ADD_DEFINITIONS(-DDEBUG -g3)
>>>  ENDIF()
>>>
>>> +ADD_EXECUTABLE(getrandom getrandom.c)
>>> +INSTALL(TARGETS getrandom
>>> +     RUNTIME DESTINATION bin
>>> +)
>>> +
>>>  ADD_EXECUTABLE(kmodloader kmodloader.c)
>>>  TARGET_LINK_LIBRARIES(kmodloader ubox)
>>>
>>> diff --git a/getrandom.c b/getrandom.c
>>> new file mode 100644
>>> index 0000000..9671202
>>> --- /dev/null
>>> +++ b/getrandom.c
>>> @@ -0,0 +1,58 @@
>>> +/*
>>> + * Copyright (C) 2016 Etienne Champetier <champetier.etienne at gmail.com>
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License as published by
>>> + * the Free Software Foundation; either version 2 of the License, or
>>> + * (at your option) any later version.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>> + * GNU General Public License for more details.
>>> + */
>>> +#define _GNU_SOURCE
>>> +#include <errno.h>
>>> +#include <linux/random.h>
>>> +#include <stdio.h>
>>> +#include <stdlib.h>
>>> +#include <string.h>
>>> +#include <sys/syscall.h>
>>> +#include <unistd.h>
>>> +
>>> +#define ERROR_EXIT(fmt, ...) do { \
>>> +        fprintf(stderr, fmt, ## __VA_ARGS__); \
>>> +        return EXIT_FAILURE; \
>>> +        } while (0)
>>> +
>>> +static int usage(char *name)
>>> +{
>>> +    fprintf(stderr, "Usage: %s <nb>\n", name);
>>> +    fprintf(stderr, " => return <nb> bytes from getrandom()\n");
>>> +    return EXIT_FAILURE;
>>> +}
>>> +
>>> +int main(int argc, char *argv[])
>>> +{
>>> +    if (argc != 2)
>>> +        return usage(argv[0]);
>>> +
>>> +    if (isatty(STDOUT_FILENO))
>>> +        ERROR_EXIT("Not outputting random to a tty\n");
>>> +
>>> +    int nbtot = atoi(argv[1]);
>>> +    if (nbtot < 1)
>>> +        ERROR_EXIT("Invalid <nb> param (must be > 0)\n");
>>> +
>>> +    char buf[256];
>>> +    int len = sizeof(buf);
>>> +    while (nbtot > 0) {
>>> +        if (nbtot <= sizeof(buf))
>>> +            len = nbtot;
>>> +        if (syscall(SYS_getrandom, buf, len, 0) == -1)
>>> +            ERROR_EXIT("getrandom() failed: %s\n", strerror(errno));
>>> +        if (write(STDOUT_FILENO, buf, len) != len)
>>> +            ERROR_EXIT("write() failed: %s\n", strerror(errno));
>>> +        nbtot -= sizeof(buf);
>>> +    }
>>> +}
>>>
>>
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev


From lynxis at fe80.eu  Thu Jun  9 11:41:32 2016
From: lynxis at fe80.eu (Alexander Couzens)
Date: Thu, 9 Jun 2016 20:41:32 +0200
Subject: [LEDE-DEV] [RFC] sysupgrade image format
Message-ID: <20160609204132.14724bd2@lazus.yip>

Hi,

I'm posting the results of a small group who talked about the
sysupgrade image format at the battlemesh in Porto.

sysupgrade
##########
 * don't limit our format by vendor image limitations
 * should contain meta information
 * meta data like compatible boards, lede version, ..
 * meta data gets appended as Trailer to be compatible
 * trailer got automatic removed by jffs2 format on first-boot
 * meta data is a tar ball (compressed)

sysupgrade.img := image + meta + trailer

Trailer
#######
 * 8 byte version field (of the trailer) + additional unknown
   informations
 * 4 byte length of the metadata
 * x byte crypto signature
-- 
Alexander Couzens

mail: lynxis at fe80.eu
jabber: lynxis at fe80.eu
mobile: +4915123277221
gpg: 390D CF78 8BF9 AA50 4F8F  F1E2 C29E 9DA6 A0DF 8604
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20160609/4015cd34/attachment.sig>

From drew at nixcores.com  Thu Jun  9 12:35:07 2016
From: drew at nixcores.com (Drew from NixCore)
Date: Thu, 9 Jun 2016 13:35:07 -0600
Subject: [LEDE-DEV]  [PATCH] [ramips] Added NixCore X1 target V3
Message-ID: <5759C4EB.5080203@nixcores.com>

Added NixCore X1 ramips target http://nixcores.com. This builds 8M and 
16M images.  V3 updates the dts to support LEDE updated format

Signed-off-by: Drew Gaylo <drew at nixcores.com>
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index 4728c75..69c0125 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -77,6 +77,7 @@ ramips_setup_interfaces()
      mt7628|\
      mzk-750dhp|\
      mzk-w300nh2|\
+    nixcore|\
      oy-0001|\
      pbr-m1|\
      psg1208|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index cbe455d..76f0e43 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -316,6 +316,9 @@ ramips_board_detect() {
      *"NCS601W")
          name="ncs601w"
          ;;
+    *"NixcoreX1")
+        name="nixcore-x1"
+        ;;
      *"NW718")
          name="nw718"
          ;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 91c9997..0094568 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -94,6 +94,7 @@ platform_check_image() {
      mzk-w300nh2|\
      mzk-wdpr|\
      nbg-419n|\
+    nixcore|\
      nw718|\
      oy-0001|\
      pbr-m1|\
diff --git a/target/linux/ramips/dts/NIXCOREX1-16M.dts 
b/target/linux/ramips/dts/NIXCOREX1-16M.dts
new file mode 100644
index 0000000..1e1a205
--- /dev/null
+++ b/target/linux/ramips/dts/NIXCOREX1-16M.dts
@@ -0,0 +1,182 @@
+/dts-v1/;
+
+/include/ "rt5350.dtsi"
+
+/ {
+    compatible = "NixcoreX1", "ralink,rt5350-soc";
+    model = "NixcoreX1";
+
+    chosen{
+        bootargs = "console=ttyS1,57600";
+    };
+
+    gpio-export {
+        compatible = "gpio-export";
+        #size-cells = <0>;
+
+        gpio0 {
+            gpio-export,name = "gpio0";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio0 0 0>;
+        };
+        /* GPIOs 1-6 are I2C,SPI */
+
+        /* GPIO 7-14 are uart1 */
+
+        /* GPIOs 15 & 16 are uart2 */
+
+        /* JTAG */
+        gpio17 {
+            /* JTAG_TDO */
+            gpio-export,name = "gpio17";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio0 17 0>;
+        };
+        gpio18 {
+            /* JTAG_TDI */
+            gpio-export,name = "gpio18";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio0 18 0>;
+        };
+        gpio19 {
+            /* JTAG_TMS */
+            gpio-export,name = "gpio19";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio0 19 0>;
+        };
+        gpio20 {
+            /* JTAG_TCLK */
+            gpio-export,name = "gpio20";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio0 20 0>;
+        };
+        gpio21 {
+            /* JTAG_TRST_N */
+            gpio-export,name = "gpio21";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio0 21 0>;
+        };
+
+        /* ETH LEDs */
+        /*
+        gpio22 {
+            gpio-export,name = "gpio22";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio1 0 0>;
+        };
+        gpio23 {
+            gpio-export,name = "gpio23";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio1 1 0>;
+        };
+        gpio24 {
+            gpio-export,name = "gpio24";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio1 2 0>;
+        };
+        gpio25 {
+            gpio-export,name = "gpio25";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio1 3 0>;
+        };
+        */
+
+        gpio26 {
+            /* ETH4_LED */
+            gpio-export,name = "gpio26";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio1 4 0>;
+        };
+
+        gpio27 {
+            /* spi_cs1 */
+            gpio-export,name = "gpio27";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio1 5 0>;
+        };
+    };
+
+};
+
+&gpio0{
+    status = "okay";
+};
+
+&gpio1{
+    status = "okay";
+};
+
+&i2c{
+    status = "okay";
+};
+&uart{
+    status = "okay";
+    /* Mix of uart and gpio */
+    reset-names = "gpio uartf";
+};
+&spi0{
+    status = "okay";
+
+    m25p80 at 0 {
+        #address-cells = <1>;
+        #size-cells = <1>;
+        compatible = "s25fl064k";
+        reg = <0>;
+        linux,modalias = "m25p80", "s25fl064k";
+        spi-max-frequency = <10000000>;
+
+        partition at 0 {
+            label = "uboot";
+            reg = <0x0 0x30000>;
+            read-only;
+        };
+
+        partition at 30000 {
+            label = "uboot-env";
+            reg = <0x30000 0x10000>;
+            read-only;
+        };
+
+        factory: partition at 40000 {
+            label = "factory";
+            reg = <0x40000 0x10000>;
+            read-only;
+        };
+
+        partition at 50000 {
+            label = "firmware";
+            reg = <0x50000 0xfb0000>;
+        };
+    };
+};
+
+&pinctrl {
+    state_default: pinctrl0 {
+        gpio {
+            /* Associate the tjag, uartf and led groups with gpio */
+            ralink,group = "jtag", "led", "spi_cs1";
+            /* How do we set individual pins? */
+            ralink,function = "gpio";
+        };
+    };
+};
+
+&ethernet {
+    mtd-mac-address = <&factory 0x4>;
+};
+
+&esw {
+    ralink,portmap = <0x17>;
+};
+
+&wmac {
+    ralink,mtd-eeprom = <&factory 0>;
+};
+
+&ehci {
+    status = "okay";
+};
+
+&ohci {
+    status = "okay";
+};
diff --git a/target/linux/ramips/dts/NIXCOREX1-8M.dts 
b/target/linux/ramips/dts/NIXCOREX1-8M.dts
new file mode 100644
index 0000000..c514860
--- /dev/null
+++ b/target/linux/ramips/dts/NIXCOREX1-8M.dts
@@ -0,0 +1,183 @@
+/dts-v1/;
+
+/include/ "rt5350.dtsi"
+
+/ {
+    compatible = "NixcoreX1", "ralink,rt5350-soc";
+    model = "NixcoreX1";
+
+    chosen{
+        bootargs = "console=ttyS1,57600";
+    };
+
+    gpio-export {
+        compatible = "gpio-export";
+        #size-cells = <0>;
+
+        gpio0 {
+            gpio-export,name = "gpio0";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio0 0 0>;
+        };
+        /* GPIOs 1-6 are I2C,SPI */
+
+        /* GPIO 7-14 are uart1 */
+
+        /* GPIOs 15 & 16 are uart2 */
+
+        /* JTAG */
+        gpio17 {
+            /* JTAG_TDO */
+            gpio-export,name = "gpio17";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio0 17 0>;
+        };
+        gpio18 {
+            /* JTAG_TDI */
+            gpio-export,name = "gpio18";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio0 18 0>;
+        };
+        gpio19 {
+            /* JTAG_TMS */
+            gpio-export,name = "gpio19";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio0 19 0>;
+        };
+        gpio20 {
+            /* JTAG_TCLK */
+            gpio-export,name = "gpio20";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio0 20 0>;
+        };
+        gpio21 {
+            /* JTAG_TRST_N */
+            gpio-export,name = "gpio21";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio0 21 0>;
+        };
+
+        /* ETH LEDs */
+        /*
+        gpio22 {
+            gpio-export,name = "gpio22";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio1 0 0>;
+        };
+        gpio23 {
+            gpio-export,name = "gpio23";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio1 1 0>;
+        };
+        gpio24 {
+            gpio-export,name = "gpio24";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio1 2 0>;
+        };
+        gpio25 {
+            gpio-export,name = "gpio25";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio1 3 0>;
+        };
+        */
+
+        gpio26 {
+            /* ETH4_LED */
+            gpio-export,name = "gpio26";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio1 4 0>;
+        };
+
+        gpio27 {
+            /* spi_cs1 */
+            gpio-export,name = "gpio27";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio1 5 0>;
+        };
+    };
+
+};
+
+&gpio0{
+    status = "okay";
+};
+
+&gpio1{
+    status = "okay";
+};
+
+&i2c{
+    status = "okay";
+};
+&uart{
+    status = "okay";
+    /* Mix of uart and gpio */
+    reset-names = "gpio uartf";
+};
+&spi0{
+    status = "okay";
+
+    m25p80 at 0 {
+        #address-cells = <1>;
+        #size-cells = <1>;
+        compatible = "s25fl064k";
+        reg = <0>;
+        linux,modalias = "m25p80", "s25fl064k";
+        spi-max-frequency = <10000000>;
+
+        partition at 0 {
+            label = "uboot";
+            reg = <0x0 0x30000>;
+            read-only;
+        };
+
+        partition at 30000 {
+            label = "uboot-env";
+            reg = <0x30000 0x10000>;
+            read-only;
+        };
+
+        factory: partition at 40000 {
+            label = "factory";
+            reg = <0x40000 0x10000>;
+            read-only;
+        };
+
+        partition at 50000 {
+            label = "firmware";
+            reg = <0x50000 0x7b0000>;
+        };
+    };
+};
+
+&pinctrl {
+    state_default: pinctrl0 {
+        gpio {
+            /* Associate the tjag, uartf and led groups with gpio */
+            ralink,group = "jtag", "led", "spi_cs1";
+            /* How do we set individual pins? */
+            ralink,function = "gpio";
+        };
+    };
+};
+
+&ethernet {
+    mtd-mac-address = <&factory 0x4>;
+};
+
+&esw {
+    ralink,portmap = <0x17>;
+};
+
+&wmac {
+    ralink,mtd-eeprom = <&factory 0>;
+};
+
+&ehci {
+    status = "okay";
+};
+
+&ohci {
+    status = "okay";
+};
+
diff --git a/target/linux/ramips/image/rt305x.mk 
b/target/linux/ramips/image/rt305x.mk
index da7fc46..db12a8e 100644
--- a/target/linux/ramips/image/rt305x.mk
+++ b/target/linux/ramips/image/rt305x.mk
@@ -100,6 +100,21 @@ define BuildFirmware/HLKRM04/initramfs
      mkhilinkfw -e -i$(call imgname,$(1),$(2))-uImage.bin -o $(call 
imgname,$(1),$(2))-factory.bin;
  endef

+# This is called to build the nixcore image.  Build both 8MB and 16MB
+nixcore_8mb_mtd_size=8060928
+nixcore_16mb_mtd_size=16449536
+define BuildFirmware/NIXCOREX1/squashfs
+# Args are XXX, nixcore-mM and NIXCOREX1-xM
+    $(call 
BuildFirmware/CustomFlash/$(1),$(1),$(2)-8M,$(3)-8M,$(nixcore_8mb_mtd_size))
+    $(call 
BuildFirmware/CustomFlash/$(1),$(1),$(2)-16M,$(3)-16M,$(nixcore_16mb_mtd_size))
+    # Can do somethings here after the build?
+endef
+define BuildFirmware/NIXCOREX1/initramfs
+# Args are XXXX, nixcore-mM and NIXCOREX1-xM
+    $(call BuildFirmware/OF/initramfs,$(1),$(2)-8M,$(3)-8M)
+    $(call BuildFirmware/OF/initramfs,$(1),$(2)-16M,$(3)-16M)
+endef
+
  vocore_8mb_mtd_size=8060928
  vocore_16mb_mtd_size=16449536
  define BuildFirmware/VOCORE/squashfs
@@ -257,6 +272,7 @@ Image/Build/Profile/NBG-419N=$(call 
BuildFirmware/Default4M/$(1),$(1),nbg-419n,N
  Image/Build/Profile/MZKW300NH2=$(call 
BuildFirmware/Edimax/$(1),$(1),mzk-w300nh2,MZK-W300NH2,$(mzkw300nh2_mtd_size),CSYS,RN52,0x50000,0xc0000)
  Image/Build/Profile/MZKWDPR=$(call 
BuildFirmware/Default8M/$(1),$(1),mzk-wdpr,MZK-WDPR)
  Image/Build/Profile/NCS601W=$(call 
BuildFirmware/Default8M/$(1),$(1),ncs601W,NCS601W)
+Image/Build/Profile/NIXCOREX1=$(call 
BuildFirmware/NIXCOREX1/$(1),$(1),nixcorex1,NIXCOREX1)
  nw718_mtd_size=3801088
  Image/Build/Profile/NW718=$(call 
BuildFirmware/CustomFlashFactory/$(1),$(1),nw718m,NW718,$(nw718_mtd_size),ARA1B4NCRNW718;1,factory)
  Image/Build/Profile/M2M=$(call 
BuildFirmware/Default8M/$(1),$(1),m2m,M2M,Linux Kernel Image)
@@ -353,6 +369,7 @@ define Image/Build/Profile/Default
      $(call Image/Build/Profile/MZKWDPR,$(1))
      $(call Image/Build/Profile/NBG-419N,$(1))
      $(call Image/Build/Profile/NCS601W,$(1))
+    $(call Image/Build/Profile/NIXCOREX1,$(1))
      $(call Image/Build/Profile/NW718,$(1))
      $(call Image/Build/Profile/MINIEMBWIFI,$(1))
      $(call Image/Build/Profile/MINIEMBPLUG,$(1))
diff --git a/target/linux/ramips/rt305x/profiles/nixcore.mk 
b/target/linux/ramips/rt305x/profiles/nixcore.mk
new file mode 100644
index 0000000..22dee9b
--- /dev/null
+++ b/target/linux/ramips/rt305x/profiles/nixcore.mk
@@ -0,0 +1,20 @@
+#
+# Copyright (C) 2014 OpenWrt.org
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+
+define Profile/NIXCOREX1
+    NAME:=NixcoreX1
+    PACKAGES:=\
+        kmod-usb-core kmod-usb-ohci kmod-usb2 \
+        kmod-i2c-core kmod-i2c-ralink \
+        kmod-spi-dev
+endef
+
+define Profile/NIXCOREX1/Description
+    Package set for Nixcore X1 board
+endef
+
+$(eval $(call Profile,NIXCOREX1))



From karlp at tweak.net.au  Thu Jun  9 14:12:29 2016
From: karlp at tweak.net.au (Karl Palsson)
Date: Thu, 09 Jun 2016 21:12:29 -0000
Subject: [LEDE-DEV] [PATCH] [ramips] Added NixCore X1 target V3
In-Reply-To: <5759C4EB.5080203@nixcores.com>
References: <5759C4EB.5080203@nixcores.com>
Message-ID: <zgYTGkNqNXAsBg4LZWbgrWX87g4XN49vqurgh8zI2120@mailpile>


If the 8 and 16 meg files only differ in their memory, should
they perhaps just have a common .dtsi file for them both? instead
of duplicating the entire dts? I've snipped the only differences
between them below...

Sincerely,
Karl P


Drew from NixCore <drew at nixcores.com> wrote:
> Added NixCore X1 ramips target http://nixcores.com. This builds
> 8M and 16M images. V3 updates the dts to support LEDE updated
> format
> 
> Signed-off-by: Drew Gaylo <drew at nixcores.com>
> diff --git
> diff --git a/target/linux/ramips/dts/NIXCOREX1-16M.dts
> b/target/linux/ramips/dts/NIXCOREX1-16M.dts new file mode
> 100644 index 0000000..1e1a205
> --- /dev/null
> +++ b/target/linux/ramips/dts/NIXCOREX1-16M.dts
snip

> +        partition at 50000 {
> +            label = "firmware";
> +            reg = <0x50000 0xfb0000>;
> +        };
> +    };
> +};
> +

> diff --git a/target/linux/ramips/dts/NIXCOREX1-8M.dts
> b/target/linux/ramips/dts/NIXCOREX1-8M.dts new file mode 100644
> index 0000000..c514860
> --- /dev/null
> +++ b/target/linux/ramips/dts/NIXCOREX1-8M.dts
snip 

> +        partition at 50000 {
> +            label = "firmware";
> +            reg = <0x50000 0x7b0000>;
> +        };
> +    };
> +};
> +
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP Digital Signature
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20160609/3651f1b5/attachment.sig>

From drew at nixcores.com  Thu Jun  9 14:36:44 2016
From: drew at nixcores.com (Drew from NixCore)
Date: Thu, 9 Jun 2016 15:36:44 -0600
Subject: [LEDE-DEV] [PATCH] [ramips] Added NixCore X1 target V3
In-Reply-To: <zgYTGkNqNXAsBg4LZWbgrWX87g4XN49vqurgh8zI2120@mailpile>
References: <5759C4EB.5080203@nixcores.com>
 <zgYTGkNqNXAsBg4LZWbgrWX87g4XN49vqurgh8zI2120@mailpile>
Message-ID: <5759E16C.1080904@nixcores.com>

I have no problem with a common dtsi, can I get these changes in first 
and then do the dtsi as I continue work?

Drew

On 06/09/2016 03:12 PM, Karl Palsson wrote:
> If the 8 and 16 meg files only differ in their memory, should
> they perhaps just have a common .dtsi file for them both? instead
> of duplicating the entire dts? I've snipped the only differences
> between them below...
>
> Sincerely,
> Karl P
>
>
> Drew from NixCore <drew at nixcores.com> wrote:
>> Added NixCore X1 ramips target http://nixcores.com. This builds
>> 8M and 16M images. V3 updates the dts to support LEDE updated
>> format
>>
>> Signed-off-by: Drew Gaylo <drew at nixcores.com>
>> diff --git
>> diff --git a/target/linux/ramips/dts/NIXCOREX1-16M.dts
>> b/target/linux/ramips/dts/NIXCOREX1-16M.dts new file mode
>> 100644 index 0000000..1e1a205
>> --- /dev/null
>> +++ b/target/linux/ramips/dts/NIXCOREX1-16M.dts
> snip
>
>> +        partition at 50000 {
>> +            label = "firmware";
>> +            reg = <0x50000 0xfb0000>;
>> +        };
>> +    };
>> +};
>> +
>> diff --git a/target/linux/ramips/dts/NIXCOREX1-8M.dts
>> b/target/linux/ramips/dts/NIXCOREX1-8M.dts new file mode 100644
>> index 0000000..c514860
>> --- /dev/null
>> +++ b/target/linux/ramips/dts/NIXCOREX1-8M.dts
> snip
>
>> +        partition at 50000 {
>> +            label = "firmware";
>> +            reg = <0x50000 0x7b0000>;
>> +        };
>> +    };
>> +};
>> +
>>
>>
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev



From xinglp at gmail.com  Thu Jun  9 20:38:24 2016
From: xinglp at gmail.com (xinglp)
Date: Fri, 10 Jun 2016 11:38:24 +0800
Subject: [LEDE-DEV] Do we have a timeline of somethings else.
Message-ID: <CAHQM780zJy6QFL042aL9uq6FWxXQQwz2=PeZwGYgZA4+YgN=UA@mail.gmail.com>

Just like https://dev.openwrt.org/timeline


From john at phrozen.org  Thu Jun  9 23:38:49 2016
From: john at phrozen.org (John Crispin)
Date: Fri, 10 Jun 2016 08:38:49 +0200
Subject: [LEDE-DEV] [PATCH] [ramips] Added NixCore X1 target V3
In-Reply-To: <5759E16C.1080904@nixcores.com>
References: <5759C4EB.5080203@nixcores.com>
 <zgYTGkNqNXAsBg4LZWbgrWX87g4XN49vqurgh8zI2120@mailpile>
 <5759E16C.1080904@nixcores.com>
Message-ID: <e0469793-f5a6-fe81-a047-ce4ed9ab45cb@phrozen.org>



On 09/06/2016 23:36, Drew from NixCore wrote:
> I have no problem with a common dtsi, can I get these changes in first
> and then do the dtsi as I continue work?
> 
> Drew
> 
> On 06/09/2016 03:12 PM, Karl Palsson wrote:
>> If the 8 and 16 meg files only differ in their memory, should
>> they perhaps just have a common .dtsi file for them both? instead
>> of duplicating the entire dts? I've snipped the only differences
>> between them below...
>>
>> Sincerely,
>> Karl P
>>
>>
>> Drew from NixCore <drew at nixcores.com> wrote:
>>> Added NixCore X1 ramips target http://nixcores.com. This builds
>>> 8M and 16M images. V3 updates the dts to support LEDE updated
>>> format

Hi Drew,

i just wanted to fix the dtsi stuff myself however the patch is
whitespace broken and does not apply. i went on to manually fix the
whitespace breakage to find that you did not generate this patch against
our latest source.git and that it wont apply.

which tree at what rev did you use to generate the patch ?

	John








>>>
>>> Signed-off-by: Drew Gaylo <drew at nixcores.com>
>>> diff --git
>>> diff --git a/target/linux/ramips/dts/NIXCOREX1-16M.dts
>>> b/target/linux/ramips/dts/NIXCOREX1-16M.dts new file mode
>>> 100644 index 0000000..1e1a205
>>> --- /dev/null
>>> +++ b/target/linux/ramips/dts/NIXCOREX1-16M.dts
>> snip
>>
>>> +        partition at 50000 {
>>> +            label = "firmware";
>>> +            reg = <0x50000 0xfb0000>;
>>> +        };
>>> +    };
>>> +};
>>> +
>>> diff --git a/target/linux/ramips/dts/NIXCOREX1-8M.dts
>>> b/target/linux/ramips/dts/NIXCOREX1-8M.dts new file mode 100644
>>> index 0000000..c514860
>>> --- /dev/null
>>> +++ b/target/linux/ramips/dts/NIXCOREX1-8M.dts
>> snip
>>
>>> +        partition at 50000 {
>>> +            label = "firmware";
>>> +            reg = <0x50000 0x7b0000>;
>>> +        };
>>> +    };
>>> +};
>>> +
>>>
>>>
>>> _______________________________________________
>>> Lede-dev mailing list
>>> Lede-dev at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/lede-dev
> 
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


From jo at mein.io  Fri Jun 10 01:10:39 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Fri, 10 Jun 2016 10:10:39 +0200
Subject: [LEDE-DEV] Do we have a timeline of somethings else.
In-Reply-To: <CAHQM780zJy6QFL042aL9uq6FWxXQQwz2=PeZwGYgZA4+YgN=UA@mail.gmail.com>
References: <CAHQM780zJy6QFL042aL9uq6FWxXQQwz2=PeZwGYgZA4+YgN=UA@mail.gmail.com>
Message-ID: <31cd9a66-d26b-6785-9e07-a8d5f71c9aaa@mein.io>

Hi,

you can either use https://git.lede-project.org/?p=source.git;a=summary
or https://github.com/lede-project/source/commits/master

HTH,
Jo


From john at phrozen.org  Fri Jun 10 01:55:06 2016
From: john at phrozen.org (John Crispin)
Date: Fri, 10 Jun 2016 10:55:06 +0200
Subject: [LEDE-DEV] [RFC] sysupgrade image format
In-Reply-To: <20160609204132.14724bd2@lazus.yip>
References: <20160609204132.14724bd2@lazus.yip>
Message-ID: <9ff42ca4-4154-f4d9-1325-f4e738225017@phrozen.org>

Hi,

some comments inline

On 09/06/2016 20:41, Alexander Couzens wrote:
> Hi,
> 
> I'm posting the results of a small group who talked about the
> sysupgrade image format at the battlemesh in Porto.
> 
> sysupgrade
> ##########
>  * don't limit our format by vendor image limitations

i dont understand what is meant by this

>  * should contain meta information
>  * meta data like compatible boards, lede version, ..
>  * meta data gets appended as Trailer to be compatible

that wont work for images that have a checksum at the end


>  * trailer got automatic removed by jffs2 format on first-boot

only works if the kernel is located before the roots and if the image
actually uses jffs2

>  * meta data is a tar ball (compressed)
> 
> sysupgrade.img := image + meta + trailer
> 
> Trailer
> #######
>  * 8 byte version field (of the trailer) + additional unknown
>    informations

why 8 bytes ? would kvl or json not be much more appropriate ?

>  * 4 byte length of the metadata

putting the length at the end of a file is always weird. why no have a
header, that would save us having to seek the end and not be sure if the
file is completed

>  * x byte crypto signature

who would be owner of the key ?

	John

> 
> 
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 


From olivier.hardouin at gmail.com  Fri Jun 10 02:18:01 2016
From: olivier.hardouin at gmail.com (olivier.hardouin at gmail.com)
Date: Fri, 10 Jun 2016 11:18:01 +0200
Subject: [LEDE-DEV] [PATCH mountd] filesystem mount options in uci config
Message-ID: <1465550281-8719-1-git-send-email-olivier.hardouin@gmail.com>

Move (previously hardcoded) mount option to UCI to allow different configuration 
like charset (utf-8 or iso) and filesystem driver (if alternative ones are used).
The fs names are changed in lowercase to comply with UCI general naming.

Signed-off-by: Olivier Hardouin <olivier.hardouin at gmail.com>
---
 mount.c | 69 ++++++++++++++++++++++++++---------------------------------------
 1 file changed, 28 insertions(+), 41 deletions(-)

diff --git a/mount.c b/mount.c
index 8892040..c8f7ea6 100644
--- a/mount.c
+++ b/mount.c
@@ -51,15 +51,15 @@ struct mount {
 char *fs_names[] = {
 	"",
 	"",
-	"MBR",
-	"EXT2",
-	"EXT3",
-	"FAT",
-	"HFSPLUS",
+	"mbr",
+	"ext2",
+	"ext3",
+	"fat",
+	"hfsplus",
 	"",
-	"NTFS",
+	"ntfs",
 	"",
-	"EXT4"
+	"ext4"
 };
 
 #define MAX_MOUNTED		32
@@ -227,42 +227,29 @@ int mount_new(char *path, char *dev)
 	pid = autofs_safe_fork();
 	if(!pid)
 	{
-		if(mount->fs == EXFAT)
+		if(mount->fs > MBR && mount->fs <= EXT4)
 		{
-			log_printf("mount -t exfat -o rw,uid=1000,gid=1000 /dev/%s %s", mount->dev, tmp);
-			ret = system_printf("mount -t exfat -o rw,uid=1000,gid=1000 /dev/%s %s", mount->dev, tmp);
-		}
-		if(mount->fs == FAT)
-		{
-			log_printf("mount -t vfat -o rw,uid=1000,gid=1000 /dev/%s %s", mount->dev, tmp);
-			ret = system_printf("mount -t vfat -o rw,uid=1000,gid=1000 /dev/%s %s", mount->dev, tmp);
-		}
-		if(mount->fs == EXT4)
-		{
-			log_printf("mount -t ext4 -o rw,defaults /dev/%s %s", mount->dev, tmp);
-			ret = system_printf("mount -t ext4 -o rw,defaults /dev/%s %s", mount->dev, tmp);
-		}
-		if(mount->fs == EXT3)
-		{
-			log_printf("mount -t ext3 -o rw,defaults /dev/%s %s", mount->dev, tmp);
-			ret = system_printf("mount -t ext3 -o rw,defaults /dev/%s %s", mount->dev, tmp);
-		}
-		if(mount->fs == EXT2)
-		{
-			log_printf("mount -t ext2 -o rw,defaults /dev/%s %s", mount->dev, tmp);
-			ret = system_printf("mount -t ext2 -o rw,defaults /dev/%s %s", mount->dev, tmp);
-		}
-		if(mount->fs == HFSPLUS)
-		{
-			log_printf("mount -t hfsplus -o rw,defaults,uid=1000,gid=1000 /dev/%s %s", mount->dev, tmp);
-			ret = system_printf("mount -t hfsplus -o rw,defaults,uid=1000,gid=1000 /dev/%s %s", mount->dev, tmp);
-		}
-		if(mount->fs == NTFS)
-		{
-			log_printf("ntfs-3g /dev/%s %s -o force", mount->dev, tmp);
-			ret = system_printf("ntfs-3g /dev/%s %s -o force", mount->dev, tmp);
+			struct uci_context *ctx;
+			char *options, *fstype;
+			ctx = ucix_init("mountd");
+			options = ucix_get_option(ctx, "mountd", fs_names[mount->fs], "options");
+			fstype = ucix_get_option(ctx, "mountd", fs_names[mount->fs], "fstype");
+			ucix_cleanup(ctx);
+			if(!fstype)
+			{
+				log_printf("mounting /dev/%s failed, expecting 'fstype' uci parameter (kernel driver) for %s", mount->dev, fs_names[mount->fs]);
+			} else {
+				if(!options)
+				{
+					log_printf("mount -t %s /dev/%s %s", fstype, mount->dev, tmp);
+					ret = system_printf("mount -t %s /dev/%s %s", fstype, mount->dev, tmp);
+				} else {
+					log_printf("mount -t %s -o %s /dev/%s %s", fstype, options, mount->dev, tmp);
+					ret = system_printf("mount -t %s -o %s /dev/%s %s", fstype, options, mount->dev, tmp);
+				}
+			}
+			exit(WEXITSTATUS(ret));
 		}
-		exit(WEXITSTATUS(ret));
 	}
 	pid = waitpid(pid, &ret, 0);
 	ret = WEXITSTATUS(ret);
-- 
1.9.1



From nbd at nbd.name  Fri Jun 10 02:26:37 2016
From: nbd at nbd.name (Felix Fietkau)
Date: Fri, 10 Jun 2016 11:26:37 +0200
Subject: [LEDE-DEV] [RFC] sysupgrade image format
In-Reply-To: <9ff42ca4-4154-f4d9-1325-f4e738225017@phrozen.org>
References: <20160609204132.14724bd2@lazus.yip>
 <9ff42ca4-4154-f4d9-1325-f4e738225017@phrozen.org>
Message-ID: <9dc6c5a9-944c-86af-aee6-f1eef1ef5632@nbd.name>

On 2016-06-10 10:55, John Crispin wrote:
> Hi,
> 
> some comments inline
> 
> On 09/06/2016 20:41, Alexander Couzens wrote:
>> Hi,
>> 
>> I'm posting the results of a small group who talked about the
>> sysupgrade image format at the battlemesh in Porto.
>> 
>> sysupgrade
>> ##########
>>  * don't limit our format by vendor image limitations
> 
> i dont understand what is meant by this
Limitations such as not having a board id to prevent flashing
incompatible images.

>>  * should contain meta information
>>  * meta data like compatible boards, lede version, ..
>>  * meta data gets appended as Trailer to be compatible
> 
> that wont work for images that have a checksum at the end
I don't think any of our sysupgrade images have a checksum at the end.
The -factory.bin image format remains unaffected by this proposal.

>>  * trailer got automatic removed by jffs2 format on first-boot
> 
> only works if the kernel is located before the roots and if the image
> actually uses jffs2
In the case of rootfs + kernel, the trailer might end up on flash, but
in a harmless place. Note: it will only end up on flash if a new
sysupgrade image was flashed over a firmware that does not understand
this metadata. In all other cases it will be stripped before flashing
starts.

>>  * meta data is a tar ball (compressed)
>> 
>> sysupgrade.img := image + meta + trailer
>> 
>> Trailer
>> #######
>>  * 8 byte version field (of the trailer) + additional unknown
>>    informations
> 
> why 8 bytes ? would kvl or json not be much more appropriate ?
This is just a fixed length field we can use in case we have to change
the layout/format of the main metadata area. Ideally the version here
would never change after the format is defined.

>>  * 4 byte length of the metadata
> 
> putting the length at the end of a file is always weird. why no have a
> header, that would save us having to seek the end and not be sure if the
> file is completed
To ensure that the sysupgrade images are backwards compatible for
upgrading from devices running older firmware.

>>  * x byte crypto signature
> who would be owner of the key ?
Whatever key is put in during the build process. For releases this would
be a key that is part of the lede keyring. For custom builds it could be
the main build key.

- Felix


From olivier.hardouin at gmail.com  Fri Jun 10 02:37:44 2016
From: olivier.hardouin at gmail.com (olivier.hardouin at gmail.com)
Date: Fri, 10 Jun 2016 11:37:44 +0200
Subject: [LEDE-DEV] [PATCH package mountd] uci config for mountd fileystem
	options
Message-ID: <1465551464-8946-1-git-send-email-olivier.hardouin@gmail.com>

Signed-off-by: Olivier Hardouin <olivier.hardouin at gmail.com>
---
 package/system/mountd/files/mountd.config | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/package/system/mountd/files/mountd.config b/package/system/mountd/files/mountd.config
index 5610129..c105606 100644
--- a/package/system/mountd/files/mountd.config
+++ b/package/system/mountd/files/mountd.config
@@ -1,3 +1,31 @@
 config mountd mountd
 	option	timeout		60
 	option	path		/tmp/mounts/
+
+config filesystem ext2
+	option options		'rw,defaults'
+	option fstype		'ext2'
+
+config filesystem ext3
+	option options		'rw,defaults'
+	option fstype		'ext3'
+
+config filesystem ext4
+	option options		'rw,defaults'
+	option fstype		'ext4'
+
+config filesystem fat
+	option options		'rw,uid=1000,gid=1000'
+	option fstype		'vfat'
+
+config filesystem exfat
+	option options		'rw,uid=1000,gid=1000'
+	option fstype		'exfat'
+
+config filesystem hfsplus
+	option options		'rw,defaults,uid=1000,gid=1000'
+	option fstype		'hfsplus'
+
+config filesystem ntfs
+	option options		'force'
+	option fstype		'ntfs'
-- 
1.9.1



From dev at kresin.me  Fri Jun 10 03:00:56 2016
From: dev at kresin.me (Mathias Kresin)
Date: Fri, 10 Jun 2016 12:00:56 +0200
Subject: [LEDE-DEV] [OpenWrt-Devel] [PATCH package mountd] uci config
 for mountd fileystem options
In-Reply-To: <1465551464-8946-1-git-send-email-olivier.hardouin@gmail.com>
References: <1465551464-8946-1-git-send-email-olivier.hardouin@gmail.com>
Message-ID: <CABwW5nka3V1sLKqbB97KT7yB=Sq4h=Q2-pVYmYLx8VfWtLeVJg@mail.gmail.com>

Hi Oliver,

2016-06-10 11:37 GMT+02:00  <olivier.hardouin at gmail.com>:
> Signed-off-by: Olivier Hardouin <olivier.hardouin at gmail.com>
> ---

Your patch doesn't have a commit message, which explains why these
options are required by default.

I've used mountd recently with ext4 and was able to read/write the
mounted filesystem out of the box.

Mathias

>  package/system/mountd/files/mountd.config | 28 ++++++++++++++++++++++++++++
>  1 file changed, 28 insertions(+)
>
> diff --git a/package/system/mountd/files/mountd.config b/package/system/mountd/files/mountd.config
> index 5610129..c105606 100644
> --- a/package/system/mountd/files/mountd.config
> +++ b/package/system/mountd/files/mountd.config
> @@ -1,3 +1,31 @@
>  config mountd mountd
>         option  timeout         60
>         option  path            /tmp/mounts/
> +
> +config filesystem ext2
> +       option options          'rw,defaults'
> +       option fstype           'ext2'
> +
> +config filesystem ext3
> +       option options          'rw,defaults'
> +       option fstype           'ext3'
> +
> +config filesystem ext4
> +       option options          'rw,defaults'
> +       option fstype           'ext4'
> +
> +config filesystem fat
> +       option options          'rw,uid=1000,gid=1000'
> +       option fstype           'vfat'
> +
> +config filesystem exfat
> +       option options          'rw,uid=1000,gid=1000'
> +       option fstype           'exfat'
> +
> +config filesystem hfsplus
> +       option options          'rw,defaults,uid=1000,gid=1000'
> +       option fstype           'hfsplus'
> +
> +config filesystem ntfs
> +       option options          'force'
> +       option fstype           'ntfs'
> --
> 1.9.1
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


From john at phrozen.org  Fri Jun 10 03:02:32 2016
From: john at phrozen.org (John Crispin)
Date: Fri, 10 Jun 2016 12:02:32 +0200
Subject: [LEDE-DEV] [OpenWrt-Devel] [PATCH package mountd] uci config
 for mountd fileystem options
In-Reply-To: <CABwW5nka3V1sLKqbB97KT7yB=Sq4h=Q2-pVYmYLx8VfWtLeVJg@mail.gmail.com>
References: <1465551464-8946-1-git-send-email-olivier.hardouin@gmail.com>
 <CABwW5nka3V1sLKqbB97KT7yB=Sq4h=Q2-pVYmYLx8VfWtLeVJg@mail.gmail.com>
Message-ID: <efbb4b9f-e517-0190-4b33-60709e1b4949@phrozen.org>



On 10/06/2016 12:00, Mathias Kresin wrote:
> Hi Oliver,
> 
> 2016-06-10 11:37 GMT+02:00  <olivier.hardouin at gmail.com>:
>> Signed-off-by: Olivier Hardouin <olivier.hardouin at gmail.com>
>> ---
> 
> Your patch doesn't have a commit message, which explains why these
> options are required by default.
> 
> I've used mountd recently with ext4 and was able to read/write the
> mounted filesystem out of the box.
> 
> Mathias

looks like these are the defaults removed from the c code int he patch
he sent 5 minutes before this patch

	John

> 
>>  package/system/mountd/files/mountd.config | 28 ++++++++++++++++++++++++++++
>>  1 file changed, 28 insertions(+)
>>
>> diff --git a/package/system/mountd/files/mountd.config b/package/system/mountd/files/mountd.config
>> index 5610129..c105606 100644
>> --- a/package/system/mountd/files/mountd.config
>> +++ b/package/system/mountd/files/mountd.config
>> @@ -1,3 +1,31 @@
>>  config mountd mountd
>>         option  timeout         60
>>         option  path            /tmp/mounts/
>> +
>> +config filesystem ext2
>> +       option options          'rw,defaults'
>> +       option fstype           'ext2'
>> +
>> +config filesystem ext3
>> +       option options          'rw,defaults'
>> +       option fstype           'ext3'
>> +
>> +config filesystem ext4
>> +       option options          'rw,defaults'
>> +       option fstype           'ext4'
>> +
>> +config filesystem fat
>> +       option options          'rw,uid=1000,gid=1000'
>> +       option fstype           'vfat'
>> +
>> +config filesystem exfat
>> +       option options          'rw,uid=1000,gid=1000'
>> +       option fstype           'exfat'
>> +
>> +config filesystem hfsplus
>> +       option options          'rw,defaults,uid=1000,gid=1000'
>> +       option fstype           'hfsplus'
>> +
>> +config filesystem ntfs
>> +       option options          'force'
>> +       option fstype           'ntfs'
>> --
>> 1.9.1
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel at lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 


From zajec5 at gmail.com  Fri Jun 10 16:36:09 2016
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Sat, 11 Jun 2016 01:36:09 +0200
Subject: [LEDE-DEV] [PATCH] kernel: mtdsplit: calculate kernel partition
	precisely for Seama
Message-ID: <1465601769-8234-1-git-send-email-zajec5@gmail.com>

So far "kernel" partition didn't contain just a kernel. It also included
Seama header and meta data. This was making kernel update complex and it
wasn't trivial to read kernel size.
Fix it by making "kernel" parition contain just a kernel image.

Signed-off-by: Rafa? Mi?ecki <zajec5 at gmail.com>
---
 target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_seama.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_seama.c b/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_seama.c
index ee0444a..9fe1311 100644
--- a/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_seama.c
+++ b/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_seama.c
@@ -79,8 +79,8 @@ static int mtdsplit_parse_seama(struct mtd_info *master,
 		return -ENOMEM;
 
 	parts[0].name = KERNEL_PART_NAME;
-	parts[0].offset = 0;
-	parts[0].size = rootfs_offset;
+	parts[0].offset = sizeof hdr + be16_to_cpu(hdr.metasize);
+	parts[0].size = rootfs_offset - parts[0].offset;
 
 	if (type == MTDSPLIT_PART_TYPE_UBI)
 		parts[1].name = UBI_PART_NAME;
-- 
1.8.4.5



From lynxis at fe80.eu  Fri Jun 10 19:15:23 2016
From: lynxis at fe80.eu (Alexander Couzens)
Date: Sat, 11 Jun 2016 04:15:23 +0200
Subject: [LEDE-DEV] [PATCH] tools/mkfwimage2: remove 256 length limit for
	partition images
Message-ID: <20160611021523.23793-1-lynxis@fe80.eu>

Signed-off-by: Alexander Couzens <lynxis at fe80.eu>
---
 tools/firmware-utils/src/mkfwimage2.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/tools/firmware-utils/src/mkfwimage2.c b/tools/firmware-utils/src/mkfwimage2.c
index 146b2ad..8255a04 100644
--- a/tools/firmware-utils/src/mkfwimage2.c
+++ b/tools/firmware-utils/src/mkfwimage2.c
@@ -197,6 +197,10 @@ int str2u32(char *arg, u_int32_t *val)
 	return 0;
 }
 
+#ifndef STRINGIFY
+#define STRINGIFY2(X) #X
+#define STRINGIFY(X) STRINGIFY2(X)
+#endif
 static int image_layout_add_partition(const char *part_desc)
 {
 	part_data_t *d;
@@ -211,8 +215,9 @@ static int image_layout_add_partition(const char *part_desc)
 		return (-1);
 	}
 
+
 	d = &im.parts[im.part_count];
-	t = sscanf(part_desc, "%15[-0-9a-zA-Z]:%15[0-9a-fA-Fx]:%15[0-9a-fA-Fx]:%15[0-9a-fA-Fx]:%15[0-9a-fA-Fx]:%256s",
+	t = sscanf(part_desc, "%15[-0-9a-zA-Z]:%15[0-9a-fA-Fx]:%15[0-9a-fA-Fx]:%15[0-9a-fA-Fx]:%15[0-9a-fA-Fx]:%"STRINGIFY(PATH_MAX)"s",
 			d->partition_name,
 			offset,
 			length,
-- 
2.8.3



From champetier.etienne at gmail.com  Fri Jun 10 23:37:55 2016
From: champetier.etienne at gmail.com (Etienne CHAMPETIER)
Date: Sat, 11 Jun 2016 06:37:55 +0000
Subject: [LEDE-DEV] [PATCH] base-files: seed /dev/urandom
Message-ID: <1465627075-13683-1-git-send-email-champetier.etienne@gmail.com>

This commit:
1) seed /dev/urandom with a saved seed as early as possible
   (using /lib/preinit/81_urandom_seed)
2) save a new seed using getrandom() so we are sure /dev/urandom
   pool is initialized (using /etc/init.d/urandom_seed)

seed size is 512 bytes (ie /proc/sys/kernel/random/poolsize / 8)
it's the same size as in ubuntu 14.04 and all systemd systems

seed file is /etc/urandom.seed (need a writable path)

seeding /dev/urandom doesn't change entropy estimation, so we still have
"random: ubus urandom read with 4 bits of entropy available"
messages in the logs, but we can now ignore them

We could also add an urandom.seed at build time to improve first boot

Signed-off-by: Etienne CHAMPETIER <champetier.etienne at gmail.com>
---
 package/base-files/files/etc/init.d/urandom_seed   | 22 ++++++++++++++++++++++
 .../base-files/files/lib/preinit/81_urandom_seed   | 15 +++++++++++++++
 2 files changed, 37 insertions(+)
 create mode 100755 package/base-files/files/etc/init.d/urandom_seed
 create mode 100644 package/base-files/files/lib/preinit/81_urandom_seed

diff --git a/package/base-files/files/etc/init.d/urandom_seed b/package/base-files/files/etc/init.d/urandom_seed
new file mode 100755
index 0000000..d7c1f71
--- /dev/null
+++ b/package/base-files/files/etc/init.d/urandom_seed
@@ -0,0 +1,22 @@
+#!/bin/sh /etc/rc.common
+
+START=99
+
+SEED=/etc/urandom.seed
+
+error_exit() {
+    logger -t urandom_seed "$1"
+    exit 1
+}
+
+save_seed() {
+    touch $SEED.tmp || error_exit "touch failed"
+    chown root:root $SEED.tmp || error_exit "chown failed"
+    chmod 600 $SEED.tmp || error_exit "chmod failed"
+    getrandom 512 > $SEED.tmp || error_exit "getrandom failed"
+    mv $SEED.tmp $SEED || error_exit "mv failed"
+}
+
+boot() {
+    save_seed
+}
diff --git a/package/base-files/files/lib/preinit/81_urandom_seed b/package/base-files/files/lib/preinit/81_urandom_seed
new file mode 100644
index 0000000..27ff587
--- /dev/null
+++ b/package/base-files/files/lib/preinit/81_urandom_seed
@@ -0,0 +1,15 @@
+#!/bin/sh
+
+do_urandom_seed() {
+    S=/etc/urandom.seed
+    U=/dev/urandom
+
+    [ -c $U ] || { echo "Something is wrong with $U"; return; }
+    [ -f $S ] || { echo "Seed file not found: $S"; return; }
+    [ -O $S -a -G $S -a ! -x $S ] || { echo "Wrong owner / permissions for $S"; return; }
+
+    echo "Seeding $U with $S"
+    cat $S > $U
+}
+
+boot_hook_add preinit_main do_urandom_seed
-- 
1.9.1



From iainf at netduma.com  Sat Jun 11 06:54:32 2016
From: iainf at netduma.com (Iain Fraser)
Date: Sat, 11 Jun 2016 14:54:32 +0100
Subject: [LEDE-DEV] [PATCH] Pass method paraneter to Lua notifications.
Message-ID: <1465653272-29005-1-git-send-email-iainf@netduma.com>

---
 lua/ubus.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lua/ubus.c b/lua/ubus.c
index f59af90..be54d8d 100644
--- a/lua/ubus.c
+++ b/lua/ubus.c
@@ -770,11 +770,12 @@ ubus_sub_notify_handler(struct ubus_context *ctx, struct ubus_object *obj,
 	lua_remove(state, -2);
 
 	if (lua_isfunction(state, -1)) {
+		lua_pushstring(state, method);
 		if( msg ){
 			ubus_lua_parse_blob_array(state, blob_data(msg), blob_len(msg), true);
-			lua_call(state, 1, 0);
+			lua_call(state, 2, 0);
 		} else {
-			lua_call(state, 0, 0);
+			lua_call(state, 1, 0);
 		}
 	} else {
 		lua_pop(state, 1);
-- 
1.7.9.5



From eschultz at prplfoundation.org  Sat Jun 11 10:17:31 2016
From: eschultz at prplfoundation.org (Eric Schultz)
Date: Sat, 11 Jun 2016 12:17:31 -0500
Subject: [LEDE-DEV] Poll on date for TR-069 & OpenWrt Face to face
Message-ID: <575C47AB.6050806@prplfoundation.org>

All,

As requested, I've created a Doodle poll to help decide on the best
dates for the TR-069 & OpenWrt Face to face. Please visit
http://doodle.com/poll/f4zc8nseeb5s8s69 as soon as possible and select
the days that work for you. Given the short time-constraints, it's
likely best that we settle on a date by the end of the day on Monday,
June 13.

Thanks everyone!

Eric


From denis.dorigo at ddinternet.com  Sat Jun 11 10:28:48 2016
From: denis.dorigo at ddinternet.com (Denis Dorigo)
Date: Sat, 11 Jun 2016 20:28:48 +0300
Subject: [LEDE-DEV] WE3526 MULTI SSID CRASH
Message-ID: <60d85a8308804802418c23f4937c3cc4@mail.gmail.com>

Good day

LEDE Reboot r595

lede-ramips-mt7621-zbt-wg3526-squashfs-sysupgrade

After ?adding new AP to Radio 1 ?(Multi SSID) you get? the following and
router stops working:


[?? 95.070000] ------------[ cut here ]------------
[?? 95.070000] WARNING: CPU: 1 PID: 22 at
/home/buildbot/slave-lede-local/ramips_mt7621/build/build_dir/target-mipse
l_1004kc+dsp_musl-1.1.14/linux-ramips_mt7621/mt76-2016-05-14/mt7603_mac.c:
1199 mt7603_mac_work+0x1c0/0x274 [mt7603e]()
[?? 95.090000] Modules linked in: pppoe ppp_async iptable_nat pppox
ppp_generic nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT
ipt_MASQUERADE xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark
xt_mac xt_limit xt_id xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG
xt_CT slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_nat
nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache
nf_conntrack iptable_raw iptable_mangle iptable_filter ip_tables crc_ccitt
mt7603e mt76x2e mt76 mac80211 cfg80211 compat ledtrig_usbdev ip6t_REJECT
nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_raw ip6table_mangle
ip6table_filter ip6_tables x_tables leds_gpio xhci_mtk xhci_plat_hcd
xhci_pci xhci_hcd gpio_button_hotplug usbcore nls_base usb_common
[?? 95.160000] CPU: 1 PID: 22 Comm: kworker/u8:1 Tainted: G??????? W
4.4.12 #1
[?? 95.160000] Workqueue: phy1 mt7603_mac_work [mt7603e]
[? ?95.170000] Stack : 8f8c6080 80470000 803f0e78 000004af 8ed451fc
00000000 8f804614 8f8c6098
[?? 95.170000]??? 00000088 80063260 803f0e78 00000001 00000016 804c365c
8040c7dc 8f8dfd54
[?? 95.170000]??? 80470000 80060fe8 80480000 804e0000 8047a318 8047a31c
803f575c 8f8dfd54
[?? 95.170000]??? 80470000 80040bf4 8f804614 8f8dfd8c 000004e5 00000000
00000000 008dfd74
[?? 95.170000]??? 8ed4503c 8fbccd00 8fbcce00 31796870 00000000 00000000
00000000 00000000
[?? 95.170000]??? ...
[?? 95.210000] Call Trace:
[?? 95.210000] [<80016728>] show_stack+0x50/0x84
[?? 95.210000] [<801acb74>] dump_stack+0x84/0xbc
[?? 95.220000] [<8002bb3c>] warn_slowpath_common+0xa0/0xd0
[?? 95.220000] [<8002bbf0>] warn_slowpath_null+0x18/0x24
[?? 95.230000] [<8ed451fc>] mt7603_mac_work+0x1c0/0x274 [mt7603e]
[?? 95.230000] [<8003e854>] process_one_work+0x214/0x358
[?? 95.240000] [<8003f73c>] worker_thread+0x2dc/0x444
[?? 95.240000] [<80043e7c>] kthread+0xdc/0xe8
[?? 95.250000] [<80005478>] ret_from_kernel_thread+0x14/0x1c
[?? 95.250000]
[?? 95.250000] ---[ end trace 38c84c1d91958c61 ]---

Thank you


From p.bombino at adbglobal.com  Sat Jun 11 10:35:59 2016
From: p.bombino at adbglobal.com (Pasquale Bombino)
Date: Sat, 11 Jun 2016 17:35:59 +0000
Subject: [LEDE-DEV] [OpenWrt] Poll on date for TR-069 & OpenWrt Face to
	face
In-Reply-To: <575C47AB.6050806@prplfoundation.org>
References: <575C47AB.6050806@prplfoundation.org>
Message-ID: <HE1PR0701MB185117A850FC38C57DF7558CED510@HE1PR0701MB1851.eurprd07.prod.outlook.com>

Hi All,

Can we also add the week after (first of July) as per our discussion during last week call ?

Cheers,
Pasquale


-----Original Message-----
From: openwrt-bounces at lists.prplfoundation.org [mailto:openwrt-bounces at lists.prplfoundation.org] On Behalf Of Eric Schultz
Sent: sabato 11 giugno 2016 19:18
To: openwrt at lists.prplfoundation.org; lede-dev at lists.infradead.org; openwrt-devel at lists.openwrt.org
Subject: [OpenWrt] Poll on date for TR-069 & OpenWrt Face to face

All,

As requested, I've created a Doodle poll to help decide on the best dates for the TR-069 & OpenWrt Face to face. Please visit
http://doodle.com/poll/f4zc8nseeb5s8s69 as soon as possible and select the days that work for you. Given the short time-constraints, it's likely best that we settle on a date by the end of the day on Monday, June 13.

Thanks everyone!

Eric
_______________________________________________
OpenWrt mailing list
OpenWrt at lists.prplfoundation.org
http://lists.prplfoundation.org/cgi-bin/mailman/listinfo/openwrt
connecting lives
connecting worlds


From eschultz at prplfoundation.org  Sat Jun 11 10:42:50 2016
From: eschultz at prplfoundation.org (Eric Schultz)
Date: Sat, 11 Jun 2016 12:42:50 -0500
Subject: [LEDE-DEV] [OpenWrt] Poll on date for TR-069 & OpenWrt Face to
	face
In-Reply-To: <HE1PR0701MB185117A850FC38C57DF7558CED510@HE1PR0701MB1851.eurprd07.prod.outlook.com>
References: <575C47AB.6050806@prplfoundation.org>
 <HE1PR0701MB185117A850FC38C57DF7558CED510@HE1PR0701MB1851.eurprd07.prod.outlook.com>
Message-ID: <575C4D9A.8030908@prplfoundation.org>

Pasquale,

Sure, no problem. I've added the week after to the poll. If you've
already participated, please update with your dates for the week after.
Reminder the poll is at: http://doodle.com/poll/f4zc8nseeb5s8s69

Thanks,

Eric

On 06/11/2016 12:35 PM, Pasquale Bombino wrote:
> Hi All,
>
> Can we also add the week after (first of July) as per our discussion during last week call ?
>
> Cheers,
> Pasquale
>
>
> -----Original Message-----
> From: openwrt-bounces at lists.prplfoundation.org [mailto:openwrt-bounces at lists.prplfoundation.org] On Behalf Of Eric Schultz
> Sent: sabato 11 giugno 2016 19:18
> To: openwrt at lists.prplfoundation.org; lede-dev at lists.infradead.org; openwrt-devel at lists.openwrt.org
> Subject: [OpenWrt] Poll on date for TR-069 & OpenWrt Face to face
>
> All,
>
> As requested, I've created a Doodle poll to help decide on the best dates for the TR-069 & OpenWrt Face to face. Please visit
> http://doodle.com/poll/f4zc8nseeb5s8s69 as soon as possible and select the days that work for you. Given the short time-constraints, it's likely best that we settle on a date by the end of the day on Monday, June 13.
>
> Thanks everyone!
>
> Eric
> _______________________________________________
> OpenWrt mailing list
> OpenWrt at lists.prplfoundation.org
> http://lists.prplfoundation.org/cgi-bin/mailman/listinfo/openwrt
> connecting lives
> connecting worlds



From dave.taht at gmail.com  Sat Jun 11 10:44:13 2016
From: dave.taht at gmail.com (Dave Taht)
Date: Sat, 11 Jun 2016 10:44:13 -0700
Subject: [LEDE-DEV] lede integration issues remaining from the detrius of
	cerowrt
Message-ID: <CAA93jw7=bHNXJqmjWmg3CHHH-biua17wK4AHfn_wB0wPWs=EqQ@mail.gmail.com>

happy to see cake working today! thx all!

In https://github.com/dtaht/ceropackages-3.10:

A) We have flent's tc-iterate.c as a fast, lightweight means of
polling fq_codel, pie, cake stats (as the shell in openwrt doesn't
support a subsecond sleep) for openwrt.

(However this package and code is in need of iteration to support
polling the new stats presented in the fq_codel for wifi sysfs code.)

Having something like this working is essential to analyze the real
performance and correctness of the new implementations on the low end
hardware.

B) I am probably the only user of the gnugol package. :(

C) I really need to sync the isochronous code with what avery has upstream

D) https://github.com/dtaht/ceropackages-3.10/tree/master/utils/nanom5poe

I don't know what landed upstream to control poe for the nano-m5
radios, if anything?

E) https://github.com/dtaht/ceropackages-3.10/tree/master/utils/gdisk

The principal problem with fdisk nowadays is that very large (> 2TB, I
think) devices are not supported by it, and require a GPT capable
tool. Is there a replacement in lede that handles GPT? If not - this
is an old gdisk port to openwrt that I used to use.

F) https://github.com/dtaht/ceropackages-3.10/tree/master/utils/cerowrt-scripts
was a tool we used to measure latency under load directly on the
router...

some other packages that might be worth upstreaming, or putting in
another repo or updating in ceropackages

owamp: lets us measure ping times very precisely. (requires good ntp)
ntpsec - a vastly hardened full fledged ntp fork https://www.ntpsec.org/
scamper - two other measurement tools
shaperprobe

?

G) We used lighttpd in cerowrt as it was tons faster than uhttpd and
flexible enough to also do local web serving. can it (or ngnix) be
substituted for uhttpd? Or has uhttpd got faster?

H) Anyone working on go or rust for lede? hugo and ipfs and all the
other blockchain related distributed web bits looks like fun...

It looks like the static linking in go is a deal-killer

https://github.com/GeertJohan/openwrt-go/issues/2


From lists at sumpfralle.de  Sat Jun 11 15:07:48 2016
From: lists at sumpfralle.de (Lars Kruse)
Date: Sun, 12 Jun 2016 00:07:48 +0200
Subject: [LEDE-DEV] lede integration issues remaining from the detrius
 of cerowrt
In-Reply-To: <CAA93jw7=bHNXJqmjWmg3CHHH-biua17wK4AHfn_wB0wPWs=EqQ@mail.gmail.com>
References: <CAA93jw7=bHNXJqmjWmg3CHHH-biua17wK4AHfn_wB0wPWs=EqQ@mail.gmail.com>
Message-ID: <20160612000748.4b208d1f@erker.lan>

Hi Dave,

> D) https://github.com/dtaht/ceropackages-3.10/tree/master/utils/nanom5poe
> 
> I don't know what landed upstream to control poe for the nano-m5
> radios, if anything?

I submitted a patch (that was accepted) for GPIO-based POE control - at least
for Nanostations XM/XW and for TP-Link CPE210 and CPE510:
 https://git.lede-project.org/?p=source.git;a=commitdiff;h=d65916047b44d6d157d88d15e8e3d92555c5e6f8

Only the luci interface is missing ...

Cheers,
Lars


From daniel at daniel.thecshore.com  Sat Jun 11 11:11:49 2016
From: daniel at daniel.thecshore.com (Daniel Curran-Dickinson)
Date: Sat, 11 Jun 2016 14:11:49 -0400
Subject: [LEDE-DEV] lede integration issues remaining from the detrius
 of cerowrt
In-Reply-To: <CAA93jw7=bHNXJqmjWmg3CHHH-biua17wK4AHfn_wB0wPWs=EqQ@mail.gmail.com>
References: <CAA93jw7=bHNXJqmjWmg3CHHH-biua17wK4AHfn_wB0wPWs=EqQ@mail.gmail.com>
Message-ID: <1465668709.2609.2.camel@homehost>

Hi Dave,

I don't speak for the LEDE team, but it looks to me a lot of your
problem is that you are using LEDE/openwrt for far bigger iron than the
primary target (standard routers, including pre-AC non-NAND ones, which
are really quite small and low powered).  2 TB+ storage for example, or
using lighttpd instead of uhttpd are really things that don't affect the
primary use case and if you want to support this, you need to find a way
to do that does not negatively affect your typical router (without
external storage).

Regards,

Daniel



From david at lang.hm  Sat Jun 11 17:56:16 2016
From: david at lang.hm (David Lang)
Date: Sat, 11 Jun 2016 17:56:16 -0700 (PDT)
Subject: [LEDE-DEV] lede integration issues remaining from the detrius
 of cerowrt
In-Reply-To: <1465668709.2609.2.camel@homehost>
References: <CAA93jw7=bHNXJqmjWmg3CHHH-biua17wK4AHfn_wB0wPWs=EqQ@mail.gmail.com>
 <1465668709.2609.2.camel@homehost>
Message-ID: <alpine.DEB.2.02.1606111746470.11839@nftneq.ynat.uz>

On Sat, 11 Jun 2016, Daniel Curran-Dickinson wrote:

> Hi Dave,
>
> I don't speak for the LEDE team, but it looks to me a lot of your
> problem is that you are using LEDE/openwrt for far bigger iron than the
> primary target (standard routers, including pre-AC non-NAND ones, which
> are really quite small and low powered).  2 TB+ storage for example, or
> using lighttpd instead of uhttpd are really things that don't affect the
> primary use case and if you want to support this, you need to find a way
> to do that does not negatively affect your typical router (without
> external storage).

While CeroWRT has expanded it's aim to be able to support today's faster network 
connections (up to and including the 1G connections now available), that's not 
really the issue here.

Even low-end devices now include a USB port, and it's really easy to plugi in an 
external USB drive that's >2TB. 3TB drives are now <$100

Now, if support for larger drives really does add a lot to the system footprint, 
it should be optional. But how much space are we talking about here? It should 
at least be an easy-to-select option.

David Lang


From aczlan+ledev at gmail.com  Sat Jun 11 21:51:54 2016
From: aczlan+ledev at gmail.com (Aaron Z)
Date: Sun, 12 Jun 2016 00:51:54 -0400
Subject: [LEDE-DEV] lede integration issues remaining from the detrius
	of cerowrt
In-Reply-To: <alpine.DEB.2.02.1606111746470.11839@nftneq.ynat.uz>
References: <CAA93jw7=bHNXJqmjWmg3CHHH-biua17wK4AHfn_wB0wPWs=EqQ@mail.gmail.com>
 <1465668709.2609.2.camel@homehost>
 <alpine.DEB.2.02.1606111746470.11839@nftneq.ynat.uz>
Message-ID: <CAKNoO9q5GdSG_nOmJZME7bfwooRGfO2jLvQyNTGEtT2w_eXkcg@mail.gmail.com>

On Sat, Jun 11, 2016 at 8:56 PM, David Lang <david at lang.hm> wrote:
> Even low-end devices now include a USB port, and it's really easy to plugi
> in an external USB drive that's >2TB. 3TB drives are now <$100
>
> Now, if support for larger drives really does add a lot to the system
> footprint, it should be optional. But how much space are we talking about
> here? It should at least be an easy-to-select option.
I would have to agree with this. While I dont do it (I got a good deal
on a dedicated NAS and I dont want an accidental mis-configuration or
bug to make my private data publicly available), I know several people
who have a good sized (500GB or larger) external HDD plugged into
their router to use as a NAS.
Might be worth at least including as a separate package if it is too
big to replace the stock program.

Aaron Z


From alan.christopher.jenkins at gmail.com  Sun Jun 12 01:06:52 2016
From: alan.christopher.jenkins at gmail.com (Alan Jenkins)
Date: Sun, 12 Jun 2016 09:06:52 +0100
Subject: [LEDE-DEV] [Cerowrt-devel] lede integration issues remaining
 from the detrius of cerowrt
In-Reply-To: <CAA93jw7=bHNXJqmjWmg3CHHH-biua17wK4AHfn_wB0wPWs=EqQ@mail.gmail.com>
References: <CAA93jw7=bHNXJqmjWmg3CHHH-biua17wK4AHfn_wB0wPWs=EqQ@mail.gmail.com>
Message-ID: <c6dac60e-b87f-d142-62d4-528c4c6ffa5c@gmail.com>

On 11/06/16 18:44, Dave Taht wrote:
> happy to see cake working today! thx all!
>
> In https://github.com/dtaht/ceropackages-3.10:
> The principal problem with fdisk nowadays is that very large (> 2TB, I
> think) devices are not supported by it, and require a GPT capable
> tool. Is there a replacement in lede that handles GPT? If not - this
> is an old gdisk port to openwrt that I used to use.
>

fdisk has support for creating GPT now (like all the other formats it 
can do).  Available in util-linux versions used on the desktop. I just 
checked Chaos Calmer, it's there in the fdisk package.


From dirkneukirchen at web.de  Sun Jun 12 02:17:33 2016
From: dirkneukirchen at web.de (Dirk Neukirchen)
Date: Sun, 12 Jun 2016 11:17:33 +0200
Subject: [LEDE-DEV] lede integration issues remaining from the detrius
 of cerowrt
In-Reply-To: <CAA93jw7=bHNXJqmjWmg3CHHH-biua17wK4AHfn_wB0wPWs=EqQ@mail.gmail.com>
References: <CAA93jw7=bHNXJqmjWmg3CHHH-biua17wK4AHfn_wB0wPWs=EqQ@mail.gmail.com>
Message-ID: <60a72dc6-9b0e-92bf-43dc-73c858720619@web.de>

On 11.06.2016 19:44, Dave Taht wrote:
> E) https://github.com/dtaht/ceropackages-3.10/tree/master/utils/gdisk
> 
> The principal problem with fdisk nowadays is that very large (> 2TB, I
> think) devices are not supported by it, and require a GPT capable
> tool. Is there a replacement in lede that handles GPT? If not - this
> is an old gdisk port to openwrt that I used to use.

util-linux w. fdisk/cfdisk etc. should work - i just tested your case in a malta VM w. virtual 3TB qemu disk:

qemu-img create test.disk 3T
Formatting 'test.disk', fmt=raw size=3298534883328

qemu-system-mipsel -M malta -hda lede-malta-le-root.ext4 -hdb test.disk -kernel lede-malta-le-vmlinux.elf -nographic -append "root=/dev/sda console=ttyS0 debug ignore_loglevel loglevel=7 verbose "

root@(none):/# lsblk
[    9.429150] random: nonblocking pool is initialized
NAME      MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda         8:0    0   48M  0 disk /
sdb         8:16   0    3T  0 disk 
mtdblock0  31:0    0    1M  1 disk 
mtdblock1  31:1    0  2.9M  0 disk 
mtdblock2  31:2    0  128K  1 disk 

cfdisk /dev/sdb
i create 3 partitions there

root at lede:/# fdisk -l /dev/sdb
Disk /dev/sdb: 3 TiB, 3298534883328 bytes, 6442450944 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 5F5FA543-8EEB-47B1-A6D0-F0E24A4C544D

Device          Start        End    Sectors  Size Type
/dev/sdb1        2048 2147485695 2147483648    1T Linux filesystem
/dev/sdb2  2147485696 4294969343 2147483648    1T Linux filesystem
/dev/sdb3  4294969344 6442450910 2147481567 1024G Linux filesystem
root at lede:/# lsblk
NAME      MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda         8:0    0   48M  0 disk /
sdb         8:16   0    3T  0 disk 
??sdb1      8:17   0    1T  0 part 
??sdb2      8:18   0    1T  0 part 
??sdb3      8:19   0 1024G  0 part 




From nbd at nbd.name  Sun Jun 12 03:45:10 2016
From: nbd at nbd.name (Felix Fietkau)
Date: Sun, 12 Jun 2016 12:45:10 +0200
Subject: [LEDE-DEV] [PATCH] base-files: seed /dev/urandom
In-Reply-To: <1465627075-13683-1-git-send-email-champetier.etienne@gmail.com>
References: <1465627075-13683-1-git-send-email-champetier.etienne@gmail.com>
Message-ID: <d16a674b-f1f0-67cb-ec02-c40804ed5a83@nbd.name>

On 2016-06-11 08:37, Etienne CHAMPETIER wrote:
> This commit:
> 1) seed /dev/urandom with a saved seed as early as possible
>    (using /lib/preinit/81_urandom_seed)
> 2) save a new seed using getrandom() so we are sure /dev/urandom
>    pool is initialized (using /etc/init.d/urandom_seed)
> 
> seed size is 512 bytes (ie /proc/sys/kernel/random/poolsize / 8)
> it's the same size as in ubuntu 14.04 and all systemd systems
> 
> seed file is /etc/urandom.seed (need a writable path)
> 
> seeding /dev/urandom doesn't change entropy estimation, so we still have
> "random: ubus urandom read with 4 bits of entropy available"
> messages in the logs, but we can now ignore them
> 
> We could also add an urandom.seed at build time to improve first boot
I'm not sure writing to flash on every single boot on every device is a
good default behavior.

- Felix


From hauke at hauke-m.de  Sun Jun 12 06:23:58 2016
From: hauke at hauke-m.de (Hauke Mehrtens)
Date: Sun, 12 Jun 2016 15:23:58 +0200
Subject: [LEDE-DEV] Nand flash partitions
Message-ID: <49219c24-0d59-456f-573d-e63ff8535679@hauke-m.de>

Hi Daniel,

I work on creating an OpenWrt image which I can just flash over an UGW
(Lantiq's/Intel's OpenWrt distribution) distribution with the normal
U-Boot. Then you do not have to touch the bootloader or the flash layout
and can just run OpenWrt. UGW is mostly focused on NAND flash based
devices. The partition layout for one device is shown in [0], the size
of the system_sw partition differs depending on the nand flash size and
contains an UBI layer. A partition ending with A or B means there are
two versions and when we upgrade only one is replaced and the other is
used for a backup. U-Boot says which partition to use with some kernel
command line parameters.

The UBI layer contains a kernelA, kernelB, rootfsA, rootfsB, firmwareA,
firmwareB and data_vol partition.

Can I change your UBI patches in a way that they accept a name for the
rootfs partition from the kernel command line? Are you planing to
upstream them or can I try?

Hauke


[0] UGW partition setup:

partition at 0 {
	label = "uboot";
	reg = <0x00000 0x100000>; /* 1024 KB */
};

partition at 100000 {
	label = "uboot_env";
	reg = <0x100000 0x40000>; /* 256 KB */
};

partition at 140000 {
	label = "ubootconfigB";
	reg = <0x140000 0x40000>; /* 256 KB */
};

partition at 180000 {
	label = "gphyfirmware";
	reg = <0x180000 0x40000>; /* 256 KB */
};

partition at 1c0000 {
	label = "system_sw";
	reg = <0x1c0000 0xc800000>;
};

partition at c9c0000 {
	label = "calibration";
	reg = <0xc9c0000 0x100000>;
};

partition at cac0000 {
	label = "res";
	reg = <0xcac0000 0x13540000>;
};


From dave.taht at gmail.com  Sun Jun 12 08:23:04 2016
From: dave.taht at gmail.com (Dave Taht)
Date: Sun, 12 Jun 2016 08:23:04 -0700
Subject: [LEDE-DEV] lede integration issues remaining from the detrius
	of cerowrt
In-Reply-To: <20160612000748.4b208d1f@erker.lan>
References: <CAA93jw7=bHNXJqmjWmg3CHHH-biua17wK4AHfn_wB0wPWs=EqQ@mail.gmail.com>
 <20160612000748.4b208d1f@erker.lan>
Message-ID: <CAA93jw52Umkw7Q2c73tBLebVXbvmN6r0a0VauczFev0BNc+vuA@mail.gmail.com>

On Sat, Jun 11, 2016 at 3:07 PM, Lars Kruse <lists at sumpfralle.de> wrote:
> Hi Dave,
>
>> D) https://github.com/dtaht/ceropackages-3.10/tree/master/utils/nanom5poe
>>
>> I don't know what landed upstream to control poe for the nano-m5
>> radios, if anything?
>
> I submitted a patch (that was accepted) for GPIO-based POE control - at least
> for Nanostations XM/XW and for TP-Link CPE210 and CPE510:
>  https://git.lede-project.org/?p=source.git;a=commitdiff;h=d65916047b44d6d157d88d15e8e3d92555c5e6f8

Groovy. There are quite a few other devices that have POE (edgerouter
is the first that comes to mind), perhaps this can be built on
generically?

> Only the luci interface is missing ...

noted....

>
> Cheers,
> Lars
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev



-- 
Dave T?ht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org


From daniel at makrotopia.org  Sun Jun 12 08:27:52 2016
From: daniel at makrotopia.org (Daniel Golle)
Date: Sun, 12 Jun 2016 17:27:52 +0200
Subject: [LEDE-DEV] Nand flash partitions
In-Reply-To: <49219c24-0d59-456f-573d-e63ff8535679@hauke-m.de>
References: <49219c24-0d59-456f-573d-e63ff8535679@hauke-m.de>
Message-ID: <20160612152750.GC1268@makrotopia.org>

Hi Hauke,

On Sun, Jun 12, 2016 at 03:23:58PM +0200, Hauke Mehrtens wrote:
> Hi Daniel,
> 
> I work on creating an OpenWrt image which I can just flash over an UGW
> (Lantiq's/Intel's OpenWrt distribution) distribution with the normal
> U-Boot. Then you do not have to touch the bootloader or the flash layout
> and can just run OpenWrt. UGW is mostly focused on NAND flash based
> devices. The partition layout for one device is shown in [0], the size
> of the system_sw partition differs depending on the nand flash size and
> contains an UBI layer. A partition ending with A or B means there are
> two versions and when we upgrade only one is replaced and the other is
> used for a backup. U-Boot says which partition to use with some kernel
> command line parameters.

I guess we got to consider that as given conditions not subject to
discussions (eg. whether it wouldn't be nicer to pass such things
by the bootloader patching the device-tree like it does to pass
the mac address of embedded ethernet interfaces).

> 
> The UBI layer contains a kernelA, kernelB, rootfsA, rootfsB, firmwareA,
> firmwareB and data_vol partition.
> 
> Can I change your UBI patches in a way that they accept a name for the
> rootfs partition from the kernel command line? Are you planing to
> upstream them or can I try?

Of course, that's why I do Free Software, so everyone can reuse and
remix everything :)
Also, feel free to suggest whatever you believe is suitable for
inclusion upstream.

With regard to the UBI patches in OpenWrt my approach was quite
idealistic when assuming that U-Boot on recent platforms will come with
modern features like device-tree and FIT enabled, store it's
environment redundantly in UBI volumes, ...
However, as my goal was to revive some ox820 based NAS devices and I
was willing to chain-load my own U-Boot I could then use all those
great and useful features (and that was back in 2013).
Recently the slightly older Oxford OX810SE has been included in Linus'
git tree, see

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=84316f4ef141cfee1e8ccd1b5749998eba2496ee

I'm thus planning to re-base the remaining parts needed for the OX820
on that once it has been completed. I reckon any upstreaming of rootfs-
auto-mount hackery will from my side only happen afterwards.

I kinda wonder why you need to have an additional cmdline parameter as
you can just use ubiblock=... and rootfs=... to explicitely specifify
the rootfs which will then not be chosen automatically, see

https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/generic/patches-4.4/493-ubi-set-ROOT_DEV-to-ubiblock-rootfs-if-unset.patch;h=f55e8e3a4d12f3883de8f6805051ba7a97f688d6;hb=HEAD#l27

To use data_vol in addition to rootfs_data is unrelated to UBI, see

https://git.lede-project.org/?p=project/fstools.git;a=blob;f=mount_root.c;h=6e06b45806e5e05ae660f7692a6a1585bd220ef4;hb=HEAD#l34

and all that requires some work for sysupgrade, but that you are surely
aware of...

I'm looking forward to your patches. Generally, I'd be glad if you
create new patches on top when it comes to cmdline-related stuff,
as I believe that there are many ways to achieve that and using the
kernel cmdline is just one of many options...
I already sent the ubifs-related part upstream long ago, see

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/fs/ubifs?id=90bea5a3f0bf680b87b90516f3c231997f4b8f3b

This was in order to allow probing whether rootfs is a single
read-write UBIFS volume in

https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/generic/patches-4.4/492-try-auto-mounting-ubi0-rootfs-in-init-do_mounts.c.patch;h=d21e6d21cefa11a966f8a249283162529d4cd7c9;hb=HEAD


Cheers

Daniel


> 
> Hauke
> 
> 
> [0] UGW partition setup:
> 
> partition at 0 {
> 	label = "uboot";
> 	reg = <0x00000 0x100000>; /* 1024 KB */
> };
> 
> partition at 100000 {
> 	label = "uboot_env";
> 	reg = <0x100000 0x40000>; /* 256 KB */
> };
> 
> partition at 140000 {
> 	label = "ubootconfigB";
> 	reg = <0x140000 0x40000>; /* 256 KB */
> };
> 
> partition at 180000 {
> 	label = "gphyfirmware";
> 	reg = <0x180000 0x40000>; /* 256 KB */
> };
> 
> partition at 1c0000 {
> 	label = "system_sw";
> 	reg = <0x1c0000 0xc800000>;
> };
> 
> partition at c9c0000 {
> 	label = "calibration";
> 	reg = <0xc9c0000 0x100000>;
> };
> 
> partition at cac0000 {
> 	label = "res";
> 	reg = <0xcac0000 0x13540000>;
> };


From dave.taht at gmail.com  Sun Jun 12 08:31:16 2016
From: dave.taht at gmail.com (Dave Taht)
Date: Sun, 12 Jun 2016 08:31:16 -0700
Subject: [LEDE-DEV] [Cerowrt-devel] lede integration issues remaining
 from the detrius of cerowrt
In-Reply-To: <c6dac60e-b87f-d142-62d4-528c4c6ffa5c@gmail.com>
References: <CAA93jw7=bHNXJqmjWmg3CHHH-biua17wK4AHfn_wB0wPWs=EqQ@mail.gmail.com>
 <c6dac60e-b87f-d142-62d4-528c4c6ffa5c@gmail.com>
Message-ID: <CAA93jw5Ui5nu42n8sLCJAE2s9OYNpk4C3UchFCfY-CY1zQp1VQ@mail.gmail.com>

On Sun, Jun 12, 2016 at 1:06 AM, Alan Jenkins
<alan.christopher.jenkins at gmail.com> wrote:
> On 11/06/16 18:44, Dave Taht wrote:
>>
>> happy to see cake working today! thx all!
>>
>> In https://github.com/dtaht/ceropackages-3.10:
>> The principal problem with fdisk nowadays is that very large (> 2TB, I
>> think) devices are not supported by it, and require a GPT capable
>> tool. Is there a replacement in lede that handles GPT? If not - this
>> is an old gdisk port to openwrt that I used to use.
>>
>
> fdisk has support for creating GPT now (like all the other formats it can
> do).  Available in util-linux versions used on the desktop. I just checked
> Chaos Calmer, it's there in the fdisk package.

Thank you for testing. It sounds like the
"https://wiki.openwrt.org/doc/howto/storage" is out of date if this is
true, and further, in the context of my question, the gdisk package
we'd had in cerowrt is no longer needed.

-- 
Dave T?ht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org


From lists at sumpfralle.de  Sun Jun 12 08:39:05 2016
From: lists at sumpfralle.de (Lars Kruse)
Date: Sun, 12 Jun 2016 17:39:05 +0200
Subject: [LEDE-DEV] lede integration issues remaining from the detrius
 of cerowrt
In-Reply-To: <CAA93jw52Umkw7Q2c73tBLebVXbvmN6r0a0VauczFev0BNc+vuA@mail.gmail.com>
References: <CAA93jw7=bHNXJqmjWmg3CHHH-biua17wK4AHfn_wB0wPWs=EqQ@mail.gmail.com>
 <20160612000748.4b208d1f@erker.lan>
 <CAA93jw52Umkw7Q2c73tBLebVXbvmN6r0a0VauczFev0BNc+vuA@mail.gmail.com>
Message-ID: <20160612173905.64e982a2@erker.lan>

Hi Dave,


Am Sun, 12 Jun 2016 08:23:04 -0700
schrieb Dave Taht <dave.taht at gmail.com>:

> Groovy. There are quite a few other devices that have POE (edgerouter
> is the first that comes to mind), perhaps this can be built on
> generically?

here should be the proper place (it was changed after my patch):
 https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/ar71xx/base-files/etc/board.d/03_gpio_switches

Cheers,
Lars


From dave.taht at gmail.com  Sun Jun 12 09:10:15 2016
From: dave.taht at gmail.com (Dave Taht)
Date: Sun, 12 Jun 2016 09:10:15 -0700
Subject: [LEDE-DEV] lede integration issues remaining from the detrius
	of cerowrt
In-Reply-To: <1465668709.2609.2.camel@homehost>
References: <CAA93jw7=bHNXJqmjWmg3CHHH-biua17wK4AHfn_wB0wPWs=EqQ@mail.gmail.com>
 <1465668709.2609.2.camel@homehost>
Message-ID: <CAA93jw6Vf-O=X245XDqm-exDeCSJt+qGMh=M-=qxNT1nsyriyA@mail.gmail.com>

On Sat, Jun 11, 2016 at 11:11 AM, Daniel Curran-Dickinson
<daniel at daniel.thecshore.com> wrote:
> Hi Dave,
>
> I don't speak for the LEDE team, but it looks to me a lot of your
> problem is that you are using LEDE/openwrt for far bigger iron than the
> primary target (standard routers, including pre-AC non-NAND ones, which
> are really quite small and low powered).  2 TB+ storage for example, or
> using lighttpd instead of uhttpd are really things that don't affect the
> primary use case and if you want to support this, you need to find a way
> to do that does not negatively affect your typical router (without
> external storage).

The context of the original question was more about being able to
access large amounts of external storage easily at all and if an
optional package needed to go upstream or not. Subsequent emails
resolved that.

The meta questions are: defining what lede's use cases will be 5-10
years in the future.

...

CeroWrt targetted routers, starting 5 years ago, with 8-16MB flash and
wedged quite a lot into that. One core feature was shipping a regular
build with an operable gui, which I hope lede starts doing, in
addition to the basic build, for devices with sufficient flash, as it
lowers the basic barriers to entry for new users considerably.

I think that lede sits atop a shrinking space, where - while very
small routers will continue to exist -  it is getting hard to get
flash chips as small as 4Mbytes these days for new products, and there
are other spaces growing at a rapid rate, notably IoT.

Most of the new routers ship with tons more flash than that.

Also, the latest generations of hackerboards, the getchip.com one, for
example, costs 9 dollars and comes with 512MB of flash, with a default
OS of debian. Nearly all the hackerboards (rpi, odroids, etc) have
been debian based, which while that does have the innate advantage of
local compilation, lacks the industrial strength characteristics of
lede (smaller footprint, well integrated key/value store in uci and
the gui, almost never writing to local flash, a good firewall).

Ledes willingness to be on the bleeding edge means it will continue to
gain valuable new features more rapidly than anything else (the
original bufferbloat and ongoing make-wifi-fast work being my own
cases in point), but to some extent that's also a disadvantage as long
term stability has been tough to get.

Another area of growth (I hope) will be in the "distributed web" space
where we start sharing data across the edges of the internet better,
and where the most "always on" box - like a lede router - would be one
of the best places to host and route such replicated content. The
tools that are creating that world have thus far tended to be written
in higher level languages (ipfs is written in go, for example), and
yet the added cpu horsepower required to manipulate a blockchain or do
DNS via a DHT is somewhat trivial for the next generation of embedded
devices.

http://www.decentralizedweb.net/schedule/ was very inspiring.

http://www.nytimes.com/2016/06/08/technology/the-webs-creator-looks-to-reinvent-it.html?_r=0

I personally don't make much distinction between "host" and "router"
anymore - a lot of the cerowrt related work on hncp (hnetd), babeld,
and source specific routing tried to make (primarily ipv6) devices
reachable no matter where or what network (or vpn) they were on, and
everyone in the above spaces is doing it with DHTs, and trying to go
the next mile past Tor. The CCN folk even go so far as to redefine a
router always having a ton of local storage.

There will always be a need for small cost effective, extremely
reliable and long term stable, routing devices, with good (and soon to
be *great*)  wifi, admittedly.

> Regards,
>
> Daniel
>



-- 
Dave T?ht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org


From arne at nerdkeller.org  Sun Jun 12 09:17:28 2016
From: arne at nerdkeller.org (Arne Zachlod)
Date: Sun, 12 Jun 2016 18:17:28 +0200
Subject: [LEDE-DEV] [PATCH] ar71xx: mach-ubnt-xm.c convert patches to mach
	file
Message-ID: <1465748248-8333-1-git-send-email-arne@nerdkeller.org>

Signed-off-by: Arne Zachlod <arne at nerdkeller.org>
---
 .../ar71xx/files/arch/mips/ath79/mach-ubnt-xm.c    | 700 +++++++++++++++++++++
 .../patches-4.4/607-MIPS-ath79-ubnt-xm-fixes.patch |  89 ---
 .../608-MIPS-ath79-ubnt-xm-add-more-boards.patch   | 623 +-----------------
 ...IPS-ath79-UBNT-add-airGateway-pro-support.patch |  62 --
 4 files changed, 701 insertions(+), 773 deletions(-)
 create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-ubnt-xm.c
 delete mode 100644 target/linux/ar71xx/patches-4.4/610-MIPS-ath79-UBNT-add-airGateway-pro-support.patch

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
new file mode 100644
index 0000000..bb5b28f
--- /dev/null
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-ubnt-xm.c
@@ -0,0 +1,700 @@
+/*
+ *  Ubiquiti Networks XM (rev 1.0) board support
+ *
+ *  Copyright (C) 2011 Ren? Bolldorf <xsecute at googlemail.com>
+ *
+ *  Derived from: mach-pb44.c
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License version 2 as published
+ *  by the Free Software Foundation.
+ */
+
+#include <linux/init.h>
+#include <linux/pci.h>
+#include <linux/platform_device.h>
+#include <linux/ath9k_platform.h>
+#include <linux/etherdevice.h>
+#include <linux/ar8216_platform.h>
+
+#include <asm/mach-ath79/ath79.h>
+#include <asm/mach-ath79/irq.h>
+#include <asm/mach-ath79/ar71xx_regs.h>
+
+#include <linux/platform_data/phy-at803x.h>
+
+#include "common.h"
+#include "dev-ap9x-pci.h"
+#include "dev-eth.h"
+#include "dev-gpio-buttons.h"
+#include "dev-leds-gpio.h"
+#include "dev-m25p80.h"
+#include "dev-usb.h"
+#include "dev-wmac.h"
+#include "machtypes.h"
+
+#define UBNT_XM_GPIO_LED_L1		0
+#define UBNT_XM_GPIO_LED_L2		1
+#define UBNT_XM_GPIO_LED_L3		11
+#define UBNT_XM_GPIO_LED_L4		7
+
+#define UBNT_XM_GPIO_BTN_RESET		12
+
+#define UBNT_XM_KEYS_POLL_INTERVAL	20
+#define UBNT_XM_KEYS_DEBOUNCE_INTERVAL	(3 * UBNT_XM_KEYS_POLL_INTERVAL)
+
+#define UBNT_XM_EEPROM_ADDR		0x1fff1000
+
+static struct gpio_led ubnt_xm_leds_gpio[] __initdata = {
+	{
+		.name		= "ubnt:red:link1",
+		.gpio		= UBNT_XM_GPIO_LED_L1,
+		.active_low	= 0,
+	}, {
+		.name		= "ubnt:orange:link2",
+		.gpio		= UBNT_XM_GPIO_LED_L2,
+		.active_low	= 0,
+	}, {
+		.name		= "ubnt:green:link3",
+		.gpio		= UBNT_XM_GPIO_LED_L3,
+		.active_low	= 0,
+	}, {
+		.name		= "ubnt:green:link4",
+		.gpio		= UBNT_XM_GPIO_LED_L4,
+		.active_low	= 0,
+	},
+};
+
+static struct gpio_keys_button ubnt_xm_gpio_keys[] __initdata = {
+	{
+		.desc			= "reset",
+		.type			= EV_KEY,
+		.code			= KEY_RESTART,
+		.debounce_interval	= UBNT_XM_KEYS_DEBOUNCE_INTERVAL,
+		.gpio			= UBNT_XM_GPIO_BTN_RESET,
+		.active_low		= 1,
+	}
+};
+
+#define UBNT_M_WAN_PHYMASK	BIT(4)
+
+static void __init ubnt_xm_init(void)
+{
+	u8 *eeprom = (u8 *) KSEG1ADDR(UBNT_XM_EEPROM_ADDR);
+	u8 *mac1 = (u8 *) KSEG1ADDR(0x1fff0000);
+	u8 *mac2 = (u8 *) KSEG1ADDR(0x1fff0000 + ETH_ALEN);
+
+	ath79_register_leds_gpio(-1, ARRAY_SIZE(ubnt_xm_leds_gpio),
+				 ubnt_xm_leds_gpio);
+
+	ath79_register_gpio_keys_polled(-1, UBNT_XM_KEYS_POLL_INTERVAL,
+					ARRAY_SIZE(ubnt_xm_gpio_keys),
+					ubnt_xm_gpio_keys);
+
+	ath79_register_m25p80(NULL);
+	ap91_pci_init(eeprom, NULL);
+
+	ath79_register_mdio(0, ~UBNT_M_WAN_PHYMASK);
+	ath79_init_mac(ath79_eth0_data.mac_addr, mac1, 0);
+	ath79_init_mac(ath79_eth1_data.mac_addr, mac2, 0);
+	ath79_register_eth(0);
+}
+
+MIPS_MACHINE(ATH79_MACH_UBNT_XM,
+	     "UBNT-XM",
+	     "Ubiquiti Networks XM (rev 1.0) board",
+	     ubnt_xm_init);
+
+MIPS_MACHINE(ATH79_MACH_UBNT_BULLET_M, "UBNT-BM", "Ubiquiti Bullet M",
+	     ubnt_xm_init);
+
+static void __init ubnt_rocket_m_setup(void)
+{
+	ubnt_xm_init();
+	ath79_register_usb();
+}
+
+MIPS_MACHINE(ATH79_MACH_UBNT_ROCKET_M, "UBNT-RM", "Ubiquiti Rocket M",
+	     ubnt_rocket_m_setup);
+
+static void __init ubnt_nano_m_setup(void)
+{
+	ubnt_xm_init();
+	ath79_register_eth(1);
+}
+
+MIPS_MACHINE(ATH79_MACH_UBNT_NANO_M, "UBNT-NM", "Ubiquiti Nanostation M",
+	     ubnt_nano_m_setup);
+
+static struct gpio_led ubnt_airrouter_leds_gpio[] __initdata = {
+	{
+		.name		= "ubnt:green:globe",
+		.gpio		= 0,
+		.active_low	= 1,
+	}, {
+	        .name		= "ubnt:green:power",
+		.gpio		= 11,
+		.active_low	= 1,
+		.default_state  = LEDS_GPIO_DEFSTATE_ON,
+	}
+};
+
+static void __init ubnt_airrouter_setup(void)
+{
+	u8 *mac1 = (u8 *) KSEG1ADDR(0x1fff0000);
+	u8 *ee = (u8 *) KSEG1ADDR(0x1fff1000);
+
+	ath79_register_m25p80(NULL);
+	ath79_register_mdio(0, ~UBNT_M_WAN_PHYMASK);
+
+	ath79_init_mac(ath79_eth0_data.mac_addr, mac1, 0);
+	ath79_init_local_mac(ath79_eth1_data.mac_addr, mac1);
+
+	ath79_register_eth(1);
+	ath79_register_eth(0);
+	ath79_register_usb();
+
+	ap91_pci_init(ee, NULL);
+	ath79_register_leds_gpio(-1, ARRAY_SIZE(ubnt_airrouter_leds_gpio),
+				 ubnt_airrouter_leds_gpio);
+
+	ath79_register_gpio_keys_polled(-1, UBNT_XM_KEYS_POLL_INTERVAL,
+                                        ARRAY_SIZE(ubnt_xm_gpio_keys),
+                                        ubnt_xm_gpio_keys);
+}
+
+MIPS_MACHINE(ATH79_MACH_UBNT_AIRROUTER, "UBNT-AR", "Ubiquiti AirRouter",
+	     ubnt_airrouter_setup);
+
+static struct gpio_led ubnt_unifi_leds_gpio[] __initdata = {
+	{
+		.name		= "ubnt:orange:dome",
+		.gpio		= 1,
+		.active_low	= 0,
+	}, {
+		.name		= "ubnt:green:dome",
+		.gpio		= 0,
+		.active_low	= 0,
+	}
+};
+
+static struct gpio_led ubnt_unifi_outdoor_leds_gpio[] __initdata = {
+	{
+		.name		= "ubnt:orange:front",
+		.gpio		= 1,
+		.active_low	= 0,
+	}, {
+		.name		= "ubnt:green:front",
+		.gpio		= 0,
+		.active_low	= 0,
+	}
+};
+
+static struct gpio_led ubnt_unifi_outdoor_plus_leds_gpio[] __initdata = {
+	{
+		.name		= "ubnt:white:front",
+		.gpio		= 1,
+		.active_low	= 0,
+	}, {
+		.name		= "ubnt:blue:front",
+		.gpio		= 0,
+		.active_low	= 0,
+	}
+};
+
+
+static void __init ubnt_unifi_setup(void)
+{
+	u8 *mac = (u8 *) KSEG1ADDR(0x1fff0000);
+	u8 *ee = (u8 *) KSEG1ADDR(0x1fff1000);
+
+	ath79_register_m25p80(NULL);
+
+	ath79_register_mdio(0, ~UBNT_M_WAN_PHYMASK);
+
+	ath79_init_mac(ath79_eth0_data.mac_addr, mac, 0);
+	ath79_register_eth(0);
+
+	ap91_pci_init(ee, NULL);
+
+	ath79_register_leds_gpio(-1, ARRAY_SIZE(ubnt_unifi_leds_gpio),
+				 ubnt_unifi_leds_gpio);
+
+	ath79_register_gpio_keys_polled(-1, UBNT_XM_KEYS_POLL_INTERVAL,
+                                        ARRAY_SIZE(ubnt_xm_gpio_keys),
+                                        ubnt_xm_gpio_keys);
+}
+
+MIPS_MACHINE(ATH79_MACH_UBNT_UNIFI, "UBNT-UF", "Ubiquiti UniFi",
+	     ubnt_unifi_setup);
+
+
+#define UBNT_UNIFIOD_PRI_PHYMASK	BIT(4)
+#define UBNT_UNIFIOD_2ND_PHYMASK	(BIT(0) | BIT(1) | BIT(2) | BIT(3))
+
+static void __init ubnt_unifi_outdoor_setup(void)
+{
+	u8 *mac1 = (u8 *) KSEG1ADDR(0x1fff0000);
+	u8 *mac2 = (u8 *) KSEG1ADDR(0x1fff0000 + ETH_ALEN);
+	u8 *ee = (u8 *) KSEG1ADDR(0x1fff1000);
+
+	ath79_register_m25p80(NULL);
+
+	ath79_register_mdio(0, ~(UBNT_UNIFIOD_PRI_PHYMASK |
+				 UBNT_UNIFIOD_2ND_PHYMASK));
+
+	ath79_init_mac(ath79_eth0_data.mac_addr, mac1, 0);
+	ath79_init_mac(ath79_eth1_data.mac_addr, mac2, 0);
+	ath79_register_eth(0);
+	ath79_register_eth(1);
+
+	ap91_pci_init(ee, NULL);
+
+	ath79_register_leds_gpio(-1, ARRAY_SIZE(ubnt_unifi_outdoor_leds_gpio),
+				 ubnt_unifi_outdoor_leds_gpio);
+
+	ath79_register_gpio_keys_polled(-1, UBNT_XM_KEYS_POLL_INTERVAL,
+                                        ARRAY_SIZE(ubnt_xm_gpio_keys),
+                                        ubnt_xm_gpio_keys);
+}
+
+MIPS_MACHINE(ATH79_MACH_UBNT_UNIFI_OUTDOOR, "UBNT-U20",
+	     "Ubiquiti UniFiAP Outdoor",
+	     ubnt_unifi_outdoor_setup);
+
+
+static void __init ubnt_unifi_outdoor_plus_setup(void)
+{
+	u8 *mac1 = (u8 *) KSEG1ADDR(0x1fff0000);
+	u8 *mac2 = (u8 *) KSEG1ADDR(0x1fff0000 + ETH_ALEN);
+	u8 *ee = (u8 *) KSEG1ADDR(0x1fff1000);
+
+	ath79_register_m25p80(NULL);
+
+	ath79_register_mdio(0, ~(UBNT_UNIFIOD_PRI_PHYMASK |
+				 UBNT_UNIFIOD_2ND_PHYMASK));
+
+	ath79_init_mac(ath79_eth0_data.mac_addr, mac1, 0);
+	ath79_init_mac(ath79_eth1_data.mac_addr, mac2, 0);
+	ath79_register_eth(0);
+	ath79_register_eth(1);
+
+	ap91_pci_init(ee, NULL);
+
+	ath79_register_leds_gpio(-1, ARRAY_SIZE(ubnt_unifi_outdoor_plus_leds_gpio),
+				 ubnt_unifi_outdoor_plus_leds_gpio);
+
+	ath79_register_gpio_keys_polled(-1, UBNT_XM_KEYS_POLL_INTERVAL,
+                                        ARRAY_SIZE(ubnt_xm_gpio_keys),
+                                        ubnt_xm_gpio_keys);
+}
+
+MIPS_MACHINE(ATH79_MACH_UBNT_UNIFI_OUTDOOR_PLUS, "UBNT-UOP",
+	     "Ubiquiti UniFiAP Outdoor+",
+	     ubnt_unifi_outdoor_plus_setup);
+
+
+static struct gpio_led ubnt_uap_pro_gpio_leds[] __initdata = {
+	{
+		.name		= "ubnt:white:dome",
+		.gpio		= 12,
+	}, {
+		.name		= "ubnt:blue:dome",
+		.gpio		= 13,
+	}
+};
+
+static struct gpio_keys_button uap_pro_gpio_keys[] __initdata = {
+	{
+		.desc			= "reset",
+		.type			= EV_KEY,
+		.code			= KEY_RESTART,
+		.debounce_interval	= UBNT_XM_KEYS_DEBOUNCE_INTERVAL,
+		.gpio			= 17,
+		.active_low		= 1,
+	}
+};
+
+static struct ar8327_pad_cfg uap_pro_ar8327_pad0_cfg = {
+	.mode = AR8327_PAD_MAC_RGMII,
+	.txclk_delay_en = true,
+	.rxclk_delay_en = true,
+	.txclk_delay_sel = AR8327_CLK_DELAY_SEL1,
+	.rxclk_delay_sel = AR8327_CLK_DELAY_SEL2,
+};
+
+static struct ar8327_platform_data uap_pro_ar8327_data = {
+	.pad0_cfg = &uap_pro_ar8327_pad0_cfg,
+	.port0_cfg = {
+		.force_link = 1,
+		.speed = AR8327_PORT_SPEED_1000,
+		.duplex = 1,
+		.txpause = 1,
+		.rxpause = 1,
+	},
+};
+
+static struct mdio_board_info uap_pro_mdio0_info[] = {
+	{
+		.bus_id = "ag71xx-mdio.0",
+		.phy_addr = 0,
+		.platform_data = &uap_pro_ar8327_data,
+	},
+};
+
+#define UAP_PRO_MAC0_OFFSET		0x0000
+#define UAP_PRO_MAC1_OFFSET		0x0006
+#define UAP_PRO_WMAC_CALDATA_OFFSET	0x1000
+#define UAP_PRO_PCI_CALDATA_OFFSET	0x5000
+
+static void __init ubnt_uap_pro_setup(void)
+{
+	u8 *eeprom = (u8 *) KSEG1ADDR(0x1fff0000);
+
+	ath79_register_m25p80(NULL);
+
+	ath79_register_leds_gpio(-1, ARRAY_SIZE(ubnt_uap_pro_gpio_leds),
+				 ubnt_uap_pro_gpio_leds);
+	ath79_register_gpio_keys_polled(-1, UBNT_XM_KEYS_POLL_INTERVAL,
+                                        ARRAY_SIZE(uap_pro_gpio_keys),
+                                        uap_pro_gpio_keys);
+
+	ath79_register_wmac(eeprom + UAP_PRO_WMAC_CALDATA_OFFSET, NULL);
+	ap91_pci_init(eeprom + UAP_PRO_PCI_CALDATA_OFFSET, NULL);
+
+	ath79_register_mdio(0, 0x0);
+	mdiobus_register_board_info(uap_pro_mdio0_info,
+				    ARRAY_SIZE(uap_pro_mdio0_info));
+
+	ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_RGMII_GMAC0);
+	ath79_init_mac(ath79_eth0_data.mac_addr,
+		       eeprom + UAP_PRO_MAC0_OFFSET, 0);
+
+	/* GMAC0 is connected to an AR8327 switch */
+	ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_RGMII;
+	ath79_eth0_data.phy_mask = BIT(0);
+	ath79_eth0_data.mii_bus_dev = &ath79_mdio0_device.dev;
+	ath79_eth0_pll_data.pll_1000 = 0x06000000;
+	ath79_register_eth(0);
+}
+
+MIPS_MACHINE(ATH79_MACH_UBNT_UAP_PRO, "UAP-PRO", "Ubiquiti UniFi AP Pro",
+	     ubnt_uap_pro_setup);
+
+#define UBNT_XW_GPIO_LED_L1		11
+#define UBNT_XW_GPIO_LED_L2		16
+#define UBNT_XW_GPIO_LED_L3		13
+#define UBNT_XW_GPIO_LED_L4		14
+
+static struct gpio_led ubnt_xw_leds_gpio[] __initdata = {
+	{
+		.name		= "ubnt:red:link1",
+		.gpio		= UBNT_XW_GPIO_LED_L1,
+		.active_low	= 1,
+	}, {
+		.name		= "ubnt:orange:link2",
+		.gpio		= UBNT_XW_GPIO_LED_L2,
+		.active_low	= 1,
+	}, {
+		.name		= "ubnt:green:link3",
+		.gpio		= UBNT_XW_GPIO_LED_L3,
+		.active_low	= 1,
+	}, {
+		.name		= "ubnt:green:link4",
+		.gpio		= UBNT_XW_GPIO_LED_L4,
+		.active_low	= 1,
+	},
+};
+
+#define UBNT_ROCKET_TI_GPIO_LED_L1	16
+#define UBNT_ROCKET_TI_GPIO_LED_L2	17
+#define UBNT_ROCKET_TI_GPIO_LED_L3	18
+#define UBNT_ROCKET_TI_GPIO_LED_L4	19
+#define UBNT_ROCKET_TI_GPIO_LED_L5	20
+#define UBNT_ROCKET_TI_GPIO_LED_L6	21
+static struct gpio_led ubnt_rocket_ti_leds_gpio[] __initdata = {
+	{
+		.name		= "ubnt:green:link1",
+		.gpio		= UBNT_ROCKET_TI_GPIO_LED_L1,
+		.active_low	= 1,
+	}, {
+		.name		= "ubnt:green:link2",
+		.gpio		= UBNT_ROCKET_TI_GPIO_LED_L2,
+		.active_low	= 1,
+	}, {
+		.name		= "ubnt:green:link3",
+		.gpio		= UBNT_ROCKET_TI_GPIO_LED_L3,
+		.active_low	= 1,
+	}, {
+		.name		= "ubnt:green:link4",
+		.gpio		= UBNT_ROCKET_TI_GPIO_LED_L4,
+		.active_low	= 0,
+	}, {
+		.name		= "ubnt:green:link5",
+		.gpio		= UBNT_ROCKET_TI_GPIO_LED_L5,
+		.active_low	= 0,
+	}, {
+		.name		= "ubnt:green:link6",
+		.gpio		= UBNT_ROCKET_TI_GPIO_LED_L6,
+		.active_low	= 0,
+	},
+};
+
+static void __init ubnt_xw_init(void)
+{
+	u8 *eeprom = (u8 *) KSEG1ADDR(0x1fff0000);
+
+	ath79_register_m25p80(NULL);
+
+	ath79_register_leds_gpio(-1, ARRAY_SIZE(ubnt_xw_leds_gpio),
+				 ubnt_xw_leds_gpio);
+	ath79_register_gpio_keys_polled(-1, UBNT_XM_KEYS_POLL_INTERVAL,
+                                        ARRAY_SIZE(ubnt_xm_gpio_keys),
+                                        ubnt_xm_gpio_keys);
+
+	ath79_register_wmac(eeprom + UAP_PRO_WMAC_CALDATA_OFFSET, NULL);
+	ap91_pci_init(eeprom + UAP_PRO_PCI_CALDATA_OFFSET, NULL);
+
+
+	ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_MII_GMAC0 | AR934X_ETH_CFG_MII_GMAC0_SLAVE);
+	ath79_init_mac(ath79_eth0_data.mac_addr,
+		       eeprom + UAP_PRO_MAC0_OFFSET, 0);
+
+	ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_MII;
+	ath79_eth0_data.mii_bus_dev = &ath79_mdio0_device.dev;
+}
+
+static void __init ubnt_nano_m_xw_setup(void)
+{
+	ubnt_xw_init();
+
+	/* GMAC0 is connected to an AR8326 switch */
+	ath79_register_mdio(0, ~(BIT(0) | BIT(1) | BIT(5)));
+	ath79_eth0_data.phy_mask = (BIT(0) | BIT(1) | BIT(5));
+	ath79_eth0_data.speed = SPEED_100;
+	ath79_eth0_data.duplex = DUPLEX_FULL;
+	ath79_register_eth(0);
+}
+
+static void __init ubnt_loco_m_xw_setup(void)
+{
+	ubnt_xw_init();
+
+	ath79_register_mdio(0, ~BIT(1));
+	ath79_eth0_data.phy_mask = BIT(1);
+	ath79_register_eth(0);
+}
+
+static void __init ubnt_rocket_m_xw_setup(void)
+{
+	u8 *eeprom = (u8 *) KSEG1ADDR(0x1fff0000);
+
+	ath79_register_m25p80(NULL);
+
+	ath79_register_leds_gpio(-1, ARRAY_SIZE(ubnt_xw_leds_gpio),
+				 ubnt_xw_leds_gpio);
+	ath79_register_gpio_keys_polled(-1, UBNT_XM_KEYS_POLL_INTERVAL,
+                                        ARRAY_SIZE(ubnt_xm_gpio_keys),
+                                        ubnt_xm_gpio_keys);
+
+	ath79_register_wmac(eeprom + UAP_PRO_WMAC_CALDATA_OFFSET, NULL);
+	ap91_pci_init(eeprom + UAP_PRO_PCI_CALDATA_OFFSET, NULL);
+
+	ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_RGMII_GMAC0);
+	ath79_init_mac(ath79_eth0_data.mac_addr,
+		       eeprom + UAP_PRO_MAC0_OFFSET, 0);
+
+	ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_RGMII;
+	ath79_eth0_data.mii_bus_dev = &ath79_mdio0_device.dev;
+
+	ath79_register_mdio(0, ~BIT(4));
+	ath79_eth0_data.phy_mask = BIT(4);
+	ath79_eth0_pll_data.pll_1000 = 0x06000000;
+	ath79_register_eth(0);
+}
+
+static struct at803x_platform_data ubnt_rocket_m_ti_at803_data = {
+	.disable_smarteee = 1,
+	.enable_rgmii_rx_delay = 1,
+	.enable_rgmii_tx_delay = 1,
+};
+static struct mdio_board_info ubnt_rocket_m_ti_mdio_info[] = {
+        {
+                .bus_id = "ag71xx-mdio.0",
+                .phy_addr = 4,
+                .platform_data = &ubnt_rocket_m_ti_at803_data,
+        },
+};
+
+static void __init ubnt_rocket_m_ti_setup(void)
+{
+	u8 *eeprom = (u8 *) KSEG1ADDR(0x1fff0000);
+
+	ath79_register_m25p80(NULL);
+
+	ath79_register_leds_gpio(-1, ARRAY_SIZE(ubnt_rocket_ti_leds_gpio),
+				 ubnt_rocket_ti_leds_gpio);
+	ath79_register_gpio_keys_polled(-1, UBNT_XM_KEYS_POLL_INTERVAL,
+                                        ARRAY_SIZE(ubnt_xm_gpio_keys),
+                                        ubnt_xm_gpio_keys);
+
+	ap91_pci_init(eeprom + 0x1000, NULL);
+
+	ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_RGMII_GMAC0);
+	ath79_setup_ar934x_eth_rx_delay(3, 3);
+	ath79_init_mac(ath79_eth0_data.mac_addr,
+		       eeprom + UAP_PRO_MAC0_OFFSET, 0);
+	ath79_init_mac(ath79_eth1_data.mac_addr,
+		       eeprom + UAP_PRO_MAC1_OFFSET, 0);
+
+	ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_RGMII;
+	ath79_eth0_data.mii_bus_dev = &ath79_mdio0_device.dev;
+	ath79_eth1_data.phy_if_mode = PHY_INTERFACE_MODE_GMII;
+	ath79_eth1_data.mii_bus_dev = &ath79_mdio1_device.dev;
+
+	mdiobus_register_board_info(ubnt_rocket_m_ti_mdio_info,
+			ARRAY_SIZE(ubnt_rocket_m_ti_mdio_info));
+	ath79_register_mdio(0, 0x0);
+
+
+	ath79_eth0_data.phy_mask = BIT(4);
+	/* read out from vendor */
+	ath79_eth0_pll_data.pll_1000 = 0x2000000;
+	ath79_eth0_pll_data.pll_10 = 0x1313;
+	ath79_register_eth(0);
+
+	ath79_register_mdio(1, 0x0);
+	ath79_eth1_data.phy_mask = BIT(3);
+	ath79_register_eth(1);
+}
+
+
+MIPS_MACHINE(ATH79_MACH_UBNT_NANO_M_XW, "UBNT-NM-XW", "Ubiquiti Nanostation M XW",
+	     ubnt_nano_m_xw_setup);
+
+MIPS_MACHINE(ATH79_MACH_UBNT_LOCO_M_XW, "UBNT-LOCO-XW", "Ubiquiti Loco M XW",
+	     ubnt_loco_m_xw_setup);
+
+MIPS_MACHINE(ATH79_MACH_UBNT_ROCKET_M_XW, "UBNT-RM-XW", "Ubiquiti Rocket M XW",
+	     ubnt_rocket_m_xw_setup);
+
+MIPS_MACHINE(ATH79_MACH_UBNT_ROCKET_M_TI, "UBNT-RM-TI", "Ubiquiti Rocket M TI",
+	     ubnt_rocket_m_ti_setup);
+
+static struct gpio_led ubnt_airgateway_gpio_leds[] __initdata = {
+	{
+		.name	   = "ubnt:blue:wlan",
+		.gpio	   = 0,
+	}, {
+		.name	   = "ubnt:white:status",
+		.gpio	   = 1,
+	},
+};
+
+static struct gpio_keys_button airgateway_gpio_keys[] __initdata = {
+	{
+		.desc		= "reset",
+		.type		= EV_KEY,
+		.code		= KEY_RESTART,
+		.debounce_interval	= UBNT_XM_KEYS_DEBOUNCE_INTERVAL,
+		.gpio		= 12,
+		.active_low	= 1,
+	}
+};
+
+static void __init ubnt_airgateway_setup(void)
+{
+	u32 t;
+	u8 *mac0 = (u8 *) KSEG1ADDR(0x1fff0000);
+	u8 *mac1 = (u8 *) KSEG1ADDR(0x1fff0000 + ETH_ALEN);
+	u8 *ee = (u8 *) KSEG1ADDR(0x1fff1000);
+
+
+	ath79_gpio_function_disable(AR933X_GPIO_FUNC_ETH_SWITCH_LED0_EN |
+				     AR933X_GPIO_FUNC_ETH_SWITCH_LED1_EN |
+				     AR933X_GPIO_FUNC_ETH_SWITCH_LED2_EN |
+				     AR933X_GPIO_FUNC_ETH_SWITCH_LED3_EN |
+				     AR933X_GPIO_FUNC_ETH_SWITCH_LED4_EN);
+
+	t = ath79_reset_rr(AR933X_RESET_REG_BOOTSTRAP);
+	t |= AR933X_BOOTSTRAP_MDIO_GPIO_EN;
+	ath79_reset_wr(AR933X_RESET_REG_BOOTSTRAP, t);
+
+	ath79_register_m25p80(NULL);
+	ath79_register_leds_gpio(-1, ARRAY_SIZE(ubnt_airgateway_gpio_leds),
+				 ubnt_airgateway_gpio_leds);
+
+	ath79_register_gpio_keys_polled(-1, UBNT_XM_KEYS_POLL_INTERVAL,
+					ARRAY_SIZE(airgateway_gpio_keys),
+					airgateway_gpio_keys);
+
+	ath79_init_mac(ath79_eth1_data.mac_addr, mac0, 0);
+	ath79_init_mac(ath79_eth0_data.mac_addr, mac1, 0);
+
+	ath79_register_mdio(0, 0x0);
+
+	ath79_register_eth(1);
+	ath79_register_eth(0);
+
+	ath79_register_wmac(ee, NULL);
+}
+
+MIPS_MACHINE(ATH79_MACH_UBNT_AIRGW, "UBNT-AGW", "Ubiquiti AirGateway",
+	     ubnt_airgateway_setup);
+
+static struct gpio_led ubnt_airgateway_pro_gpio_leds[] __initdata = {
+	{
+		.name	   = "ubnt:blue:wlan",
+		.gpio	   = 13,
+	}, {
+		.name	   = "ubnt:white:status",
+		.gpio	   = 17,
+	},
+};
+
+
+static struct gpio_keys_button airgateway_pro_gpio_keys[] __initdata = {
+	{
+		.desc		= "reset",
+		.type		= EV_KEY,
+		.code		= KEY_RESTART,
+		.debounce_interval	= UBNT_XM_KEYS_DEBOUNCE_INTERVAL,
+		.gpio		= 12,
+		.active_low	= 1,
+	}
+};
+
+static void __init ubnt_airgateway_pro_setup(void)
+{
+	u8 *eeprom = (u8 *) KSEG1ADDR(0x1fff0000);
+	u8 *mac0 = (u8 *) KSEG1ADDR(0x1fff0000);
+
+	ath79_register_m25p80(NULL);
+	ath79_register_leds_gpio(-1, ARRAY_SIZE(ubnt_airgateway_pro_gpio_leds),
+				 ubnt_airgateway_pro_gpio_leds);
+
+	ath79_register_gpio_keys_polled(-1, UBNT_XM_KEYS_POLL_INTERVAL,
+					ARRAY_SIZE(airgateway_pro_gpio_keys),
+					airgateway_pro_gpio_keys);
+
+	ath79_register_wmac(eeprom + UAP_PRO_WMAC_CALDATA_OFFSET, NULL);
+	ap91_pci_init(eeprom + UAP_PRO_PCI_CALDATA_OFFSET, NULL);
+
+
+	ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_SW_ONLY_MODE);
+
+	ath79_register_mdio(1, 0x0);
+
+	/* GMAC0 is left unused in this configuration */
+
+	/* GMAC1 is connected to MAC0 on the internal switch */
+	/* The PoE/WAN port connects to port 5 on the internal switch */
+	/* The LAN port connects to port 4 on the internal switch */
+	ath79_init_mac(ath79_eth1_data.mac_addr, mac0, 0);
+	ath79_eth1_data.phy_if_mode = PHY_INTERFACE_MODE_GMII;
+	ath79_register_eth(1);
+
+}
+
+MIPS_MACHINE(ATH79_MACH_UBNT_AIRGWP, "UBNT-AGWP", "Ubiquiti AirGateway Pro",
+	     ubnt_airgateway_pro_setup);
diff --git a/target/linux/ar71xx/patches-4.4/607-MIPS-ath79-ubnt-xm-fixes.patch b/target/linux/ar71xx/patches-4.4/607-MIPS-ath79-ubnt-xm-fixes.patch
index 50be509..4699c82 100644
--- a/target/linux/ar71xx/patches-4.4/607-MIPS-ath79-ubnt-xm-fixes.patch
+++ b/target/linux/ar71xx/patches-4.4/607-MIPS-ath79-ubnt-xm-fixes.patch
@@ -12,92 +12,3 @@
  	help
  	  Say 'Y' here if you want your kernel to support the
  	  Ubiquiti Networks XM (rev 1.0) board.
---- a/arch/mips/ath79/mach-ubnt-xm.c
-+++ b/arch/mips/ath79/mach-ubnt-xm.c
-@@ -16,10 +16,11 @@
- 
- #include <asm/mach-ath79/irq.h>
- 
--#include "machtypes.h"
-+#include "dev-ap9x-pci.h"
- #include "dev-gpio-buttons.h"
- #include "dev-leds-gpio.h"
--#include "dev-spi.h"
-+#include "dev-m25p80.h"
-+#include "machtypes.h"
- #include "pci.h"
- 
- #define UBNT_XM_GPIO_LED_L1		0
-@@ -32,7 +33,7 @@
- #define UBNT_XM_KEYS_POLL_INTERVAL	20
- #define UBNT_XM_KEYS_DEBOUNCE_INTERVAL	(3 * UBNT_XM_KEYS_POLL_INTERVAL)
- 
--#define UBNT_XM_EEPROM_ADDR		(u8 *) KSEG1ADDR(0x1fff1000)
-+#define UBNT_XM_EEPROM_ADDR		0x1fff1000
- 
- static struct gpio_led ubnt_xm_leds_gpio[] __initdata = {
- 	{
-@@ -65,48 +66,10 @@ static struct gpio_keys_button ubnt_xm_g
- 	}
- };
- 
--static struct spi_board_info ubnt_xm_spi_info[] = {
--	{
--		.bus_num	= 0,
--		.chip_select	= 0,
--		.max_speed_hz	= 25000000,
--		.modalias	= "mx25l6405d",
--	}
--};
--
--static struct ath79_spi_platform_data ubnt_xm_spi_data = {
--	.bus_num		= 0,
--	.num_chipselect		= 1,
--};
--
--#ifdef CONFIG_PCI
--static struct ath9k_platform_data ubnt_xm_eeprom_data;
--
--static int ubnt_xm_pci_plat_dev_init(struct pci_dev *dev)
--{
--	switch (PCI_SLOT(dev->devfn)) {
--	case 0:
--		dev->dev.platform_data = &ubnt_xm_eeprom_data;
--		break;
--	}
--
--	return 0;
--}
--
--static void __init ubnt_xm_pci_init(void)
--{
--	memcpy(ubnt_xm_eeprom_data.eeprom_data, UBNT_XM_EEPROM_ADDR,
--	       sizeof(ubnt_xm_eeprom_data.eeprom_data));
--
--	ath79_pci_set_plat_dev_init(ubnt_xm_pci_plat_dev_init);
--	ath79_register_pci();
--}
--#else
--static inline void ubnt_xm_pci_init(void) {}
--#endif /* CONFIG_PCI */
--
- static void __init ubnt_xm_init(void)
- {
-+	u8 *eeprom = (u8 *) KSEG1ADDR(UBNT_XM_EEPROM_ADDR);
-+
- 	ath79_register_leds_gpio(-1, ARRAY_SIZE(ubnt_xm_leds_gpio),
- 				 ubnt_xm_leds_gpio);
- 
-@@ -114,10 +77,8 @@ static void __init ubnt_xm_init(void)
- 					ARRAY_SIZE(ubnt_xm_gpio_keys),
- 					ubnt_xm_gpio_keys);
- 
--	ath79_register_spi(&ubnt_xm_spi_data, ubnt_xm_spi_info,
--			   ARRAY_SIZE(ubnt_xm_spi_info));
--
--	ubnt_xm_pci_init();
-+	ath79_register_m25p80(NULL);
-+	ap91_pci_init(eeprom, NULL);
- }
- 
- MIPS_MACHINE(ATH79_MACH_UBNT_XM,
diff --git a/target/linux/ar71xx/patches-4.4/608-MIPS-ath79-ubnt-xm-add-more-boards.patch b/target/linux/ar71xx/patches-4.4/608-MIPS-ath79-ubnt-xm-add-more-boards.patch
index b463d14..2bfd58d 100644
--- a/target/linux/ar71xx/patches-4.4/608-MIPS-ath79-ubnt-xm-add-more-boards.patch
+++ b/target/linux/ar71xx/patches-4.4/608-MIPS-ath79-ubnt-xm-add-more-boards.patch
@@ -1,629 +1,8 @@
---- a/arch/mips/ath79/mach-ubnt-xm.c
-+++ b/arch/mips/ath79/mach-ubnt-xm.c
-@@ -12,16 +12,26 @@
- 
- #include <linux/init.h>
- #include <linux/pci.h>
-+#include <linux/platform_device.h>
- #include <linux/ath9k_platform.h>
-+#include <linux/etherdevice.h>
-+#include <linux/ar8216_platform.h>
- 
-+#include <asm/mach-ath79/ath79.h>
- #include <asm/mach-ath79/irq.h>
-+#include <asm/mach-ath79/ar71xx_regs.h>
- 
-+#include <linux/platform_data/phy-at803x.h>
-+
-+#include "common.h"
- #include "dev-ap9x-pci.h"
-+#include "dev-eth.h"
- #include "dev-gpio-buttons.h"
- #include "dev-leds-gpio.h"
- #include "dev-m25p80.h"
-+#include "dev-usb.h"
-+#include "dev-wmac.h"
- #include "machtypes.h"
--#include "pci.h"
- 
- #define UBNT_XM_GPIO_LED_L1		0
- #define UBNT_XM_GPIO_LED_L2		1
-@@ -37,19 +47,19 @@
- 
- static struct gpio_led ubnt_xm_leds_gpio[] __initdata = {
- 	{
--		.name		= "ubnt-xm:red:link1",
-+		.name		= "ubnt:red:link1",
- 		.gpio		= UBNT_XM_GPIO_LED_L1,
- 		.active_low	= 0,
- 	}, {
--		.name		= "ubnt-xm:orange:link2",
-+		.name		= "ubnt:orange:link2",
- 		.gpio		= UBNT_XM_GPIO_LED_L2,
- 		.active_low	= 0,
- 	}, {
--		.name		= "ubnt-xm:green:link3",
-+		.name		= "ubnt:green:link3",
- 		.gpio		= UBNT_XM_GPIO_LED_L3,
- 		.active_low	= 0,
- 	}, {
--		.name		= "ubnt-xm:green:link4",
-+		.name		= "ubnt:green:link4",
- 		.gpio		= UBNT_XM_GPIO_LED_L4,
- 		.active_low	= 0,
- 	},
-@@ -66,9 +76,13 @@ static struct gpio_keys_button ubnt_xm_g
- 	}
- };
- 
-+#define UBNT_M_WAN_PHYMASK	BIT(4)
-+
- static void __init ubnt_xm_init(void)
- {
- 	u8 *eeprom = (u8 *) KSEG1ADDR(UBNT_XM_EEPROM_ADDR);
-+	u8 *mac1 = (u8 *) KSEG1ADDR(0x1fff0000);
-+	u8 *mac2 = (u8 *) KSEG1ADDR(0x1fff0000 + ETH_ALEN);
- 
- 	ath79_register_leds_gpio(-1, ARRAY_SIZE(ubnt_xm_leds_gpio),
- 				 ubnt_xm_leds_gpio);
-@@ -79,9 +93,552 @@ static void __init ubnt_xm_init(void)
- 
- 	ath79_register_m25p80(NULL);
- 	ap91_pci_init(eeprom, NULL);
-+
-+	ath79_register_mdio(0, ~UBNT_M_WAN_PHYMASK);
-+	ath79_init_mac(ath79_eth0_data.mac_addr, mac1, 0);
-+	ath79_init_mac(ath79_eth1_data.mac_addr, mac2, 0);
-+	ath79_register_eth(0);
- }
- 
- MIPS_MACHINE(ATH79_MACH_UBNT_XM,
- 	     "UBNT-XM",
- 	     "Ubiquiti Networks XM (rev 1.0) board",
- 	     ubnt_xm_init);
-+
-+MIPS_MACHINE(ATH79_MACH_UBNT_BULLET_M, "UBNT-BM", "Ubiquiti Bullet M",
-+	     ubnt_xm_init);
-+
-+static void __init ubnt_rocket_m_setup(void)
-+{
-+	ubnt_xm_init();
-+	ath79_register_usb();
-+}
-+
-+MIPS_MACHINE(ATH79_MACH_UBNT_ROCKET_M, "UBNT-RM", "Ubiquiti Rocket M",
-+	     ubnt_rocket_m_setup);
-+
-+static void __init ubnt_nano_m_setup(void)
-+{
-+	ubnt_xm_init();
-+	ath79_register_eth(1);
-+}
-+
-+MIPS_MACHINE(ATH79_MACH_UBNT_NANO_M, "UBNT-NM", "Ubiquiti Nanostation M",
-+	     ubnt_nano_m_setup);
-+
-+static struct gpio_led ubnt_airrouter_leds_gpio[] __initdata = {
-+	{
-+		.name		= "ubnt:green:globe",
-+		.gpio		= 0,
-+		.active_low	= 1,
-+	}, {
-+	        .name		= "ubnt:green:power",
-+		.gpio		= 11,
-+		.active_low	= 1,
-+		.default_state  = LEDS_GPIO_DEFSTATE_ON,
-+	}
-+};
-+
-+static void __init ubnt_airrouter_setup(void)
-+{
-+	u8 *mac1 = (u8 *) KSEG1ADDR(0x1fff0000);
-+	u8 *ee = (u8 *) KSEG1ADDR(0x1fff1000);
-+
-+	ath79_register_m25p80(NULL);
-+	ath79_register_mdio(0, ~UBNT_M_WAN_PHYMASK);
-+
-+	ath79_init_mac(ath79_eth0_data.mac_addr, mac1, 0);
-+	ath79_init_local_mac(ath79_eth1_data.mac_addr, mac1);
-+
-+	ath79_register_eth(1);
-+	ath79_register_eth(0);
-+	ath79_register_usb();
-+
-+	ap91_pci_init(ee, NULL);
-+	ath79_register_leds_gpio(-1, ARRAY_SIZE(ubnt_airrouter_leds_gpio),
-+				 ubnt_airrouter_leds_gpio);
-+
-+	ath79_register_gpio_keys_polled(-1, UBNT_XM_KEYS_POLL_INTERVAL,
-+                                        ARRAY_SIZE(ubnt_xm_gpio_keys),
-+                                        ubnt_xm_gpio_keys);
-+}
-+
-+MIPS_MACHINE(ATH79_MACH_UBNT_AIRROUTER, "UBNT-AR", "Ubiquiti AirRouter",
-+	     ubnt_airrouter_setup);
-+
-+static struct gpio_led ubnt_unifi_leds_gpio[] __initdata = {
-+	{
-+		.name		= "ubnt:orange:dome",
-+		.gpio		= 1,
-+		.active_low	= 0,
-+	}, {
-+		.name		= "ubnt:green:dome",
-+		.gpio		= 0,
-+		.active_low	= 0,
-+	}
-+};
-+
-+static struct gpio_led ubnt_unifi_outdoor_leds_gpio[] __initdata = {
-+	{
-+		.name		= "ubnt:orange:front",
-+		.gpio		= 1,
-+		.active_low	= 0,
-+	}, {
-+		.name		= "ubnt:green:front",
-+		.gpio		= 0,
-+		.active_low	= 0,
-+	}
-+};
-+
-+static struct gpio_led ubnt_unifi_outdoor_plus_leds_gpio[] __initdata = {
-+	{
-+		.name		= "ubnt:white:front",
-+		.gpio		= 1,
-+		.active_low	= 0,
-+	}, {
-+		.name		= "ubnt:blue:front",
-+		.gpio		= 0,
-+		.active_low	= 0,
-+	}
-+};
-+
-+
-+static void __init ubnt_unifi_setup(void)
-+{
-+	u8 *mac = (u8 *) KSEG1ADDR(0x1fff0000);
-+	u8 *ee = (u8 *) KSEG1ADDR(0x1fff1000);
-+
-+	ath79_register_m25p80(NULL);
-+
-+	ath79_register_mdio(0, ~UBNT_M_WAN_PHYMASK);
-+
-+	ath79_init_mac(ath79_eth0_data.mac_addr, mac, 0);
-+	ath79_register_eth(0);
-+
-+	ap91_pci_init(ee, NULL);
-+
-+	ath79_register_leds_gpio(-1, ARRAY_SIZE(ubnt_unifi_leds_gpio),
-+				 ubnt_unifi_leds_gpio);
-+
-+	ath79_register_gpio_keys_polled(-1, UBNT_XM_KEYS_POLL_INTERVAL,
-+                                        ARRAY_SIZE(ubnt_xm_gpio_keys),
-+                                        ubnt_xm_gpio_keys);
-+}
-+
-+MIPS_MACHINE(ATH79_MACH_UBNT_UNIFI, "UBNT-UF", "Ubiquiti UniFi",
-+	     ubnt_unifi_setup);
-+
-+
-+#define UBNT_UNIFIOD_PRI_PHYMASK	BIT(4)
-+#define UBNT_UNIFIOD_2ND_PHYMASK	(BIT(0) | BIT(1) | BIT(2) | BIT(3))
-+
-+static void __init ubnt_unifi_outdoor_setup(void)
-+{
-+	u8 *mac1 = (u8 *) KSEG1ADDR(0x1fff0000);
-+	u8 *mac2 = (u8 *) KSEG1ADDR(0x1fff0000 + ETH_ALEN);
-+	u8 *ee = (u8 *) KSEG1ADDR(0x1fff1000);
-+
-+	ath79_register_m25p80(NULL);
-+
-+	ath79_register_mdio(0, ~(UBNT_UNIFIOD_PRI_PHYMASK |
-+				 UBNT_UNIFIOD_2ND_PHYMASK));
-+
-+	ath79_init_mac(ath79_eth0_data.mac_addr, mac1, 0);
-+	ath79_init_mac(ath79_eth1_data.mac_addr, mac2, 0);
-+	ath79_register_eth(0);
-+	ath79_register_eth(1);
-+
-+	ap91_pci_init(ee, NULL);
-+
-+	ath79_register_leds_gpio(-1, ARRAY_SIZE(ubnt_unifi_outdoor_leds_gpio),
-+				 ubnt_unifi_outdoor_leds_gpio);
-+
-+	ath79_register_gpio_keys_polled(-1, UBNT_XM_KEYS_POLL_INTERVAL,
-+                                        ARRAY_SIZE(ubnt_xm_gpio_keys),
-+                                        ubnt_xm_gpio_keys);
-+}
-+
-+MIPS_MACHINE(ATH79_MACH_UBNT_UNIFI_OUTDOOR, "UBNT-U20",
-+	     "Ubiquiti UniFiAP Outdoor",
-+	     ubnt_unifi_outdoor_setup);
-+
-+
-+static void __init ubnt_unifi_outdoor_plus_setup(void)
-+{
-+	u8 *mac1 = (u8 *) KSEG1ADDR(0x1fff0000);
-+	u8 *mac2 = (u8 *) KSEG1ADDR(0x1fff0000 + ETH_ALEN);
-+	u8 *ee = (u8 *) KSEG1ADDR(0x1fff1000);
-+
-+	ath79_register_m25p80(NULL);
-+
-+	ath79_register_mdio(0, ~(UBNT_UNIFIOD_PRI_PHYMASK |
-+				 UBNT_UNIFIOD_2ND_PHYMASK));
-+
-+	ath79_init_mac(ath79_eth0_data.mac_addr, mac1, 0);
-+	ath79_init_mac(ath79_eth1_data.mac_addr, mac2, 0);
-+	ath79_register_eth(0);
-+	ath79_register_eth(1);
-+
-+	ap91_pci_init(ee, NULL);
-+
-+	ath79_register_leds_gpio(-1, ARRAY_SIZE(ubnt_unifi_outdoor_plus_leds_gpio),
-+				 ubnt_unifi_outdoor_plus_leds_gpio);
-+
-+	ath79_register_gpio_keys_polled(-1, UBNT_XM_KEYS_POLL_INTERVAL,
-+                                        ARRAY_SIZE(ubnt_xm_gpio_keys),
-+                                        ubnt_xm_gpio_keys);
-+}
-+
-+MIPS_MACHINE(ATH79_MACH_UBNT_UNIFI_OUTDOOR_PLUS, "UBNT-UOP",
-+	     "Ubiquiti UniFiAP Outdoor+",
-+	     ubnt_unifi_outdoor_plus_setup);
-+
-+
-+static struct gpio_led ubnt_uap_pro_gpio_leds[] __initdata = {
-+	{
-+		.name		= "ubnt:white:dome",
-+		.gpio		= 12,
-+	}, {
-+		.name		= "ubnt:blue:dome",
-+		.gpio		= 13,
-+	}
-+};
-+
-+static struct gpio_keys_button uap_pro_gpio_keys[] __initdata = {
-+	{
-+		.desc			= "reset",
-+		.type			= EV_KEY,
-+		.code			= KEY_RESTART,
-+		.debounce_interval	= UBNT_XM_KEYS_DEBOUNCE_INTERVAL,
-+		.gpio			= 17,
-+		.active_low		= 1,
-+	}
-+};
-+
-+static struct ar8327_pad_cfg uap_pro_ar8327_pad0_cfg = {
-+	.mode = AR8327_PAD_MAC_RGMII,
-+	.txclk_delay_en = true,
-+	.rxclk_delay_en = true,
-+	.txclk_delay_sel = AR8327_CLK_DELAY_SEL1,
-+	.rxclk_delay_sel = AR8327_CLK_DELAY_SEL2,
-+};
-+
-+static struct ar8327_platform_data uap_pro_ar8327_data = {
-+	.pad0_cfg = &uap_pro_ar8327_pad0_cfg,
-+	.port0_cfg = {
-+		.force_link = 1,
-+		.speed = AR8327_PORT_SPEED_1000,
-+		.duplex = 1,
-+		.txpause = 1,
-+		.rxpause = 1,
-+	},
-+};
-+
-+static struct mdio_board_info uap_pro_mdio0_info[] = {
-+	{
-+		.bus_id = "ag71xx-mdio.0",
-+		.phy_addr = 0,
-+		.platform_data = &uap_pro_ar8327_data,
-+	},
-+};
-+
-+#define UAP_PRO_MAC0_OFFSET		0x0000
-+#define UAP_PRO_MAC1_OFFSET		0x0006
-+#define UAP_PRO_WMAC_CALDATA_OFFSET	0x1000
-+#define UAP_PRO_PCI_CALDATA_OFFSET	0x5000
-+
-+static void __init ubnt_uap_pro_setup(void)
-+{
-+	u8 *eeprom = (u8 *) KSEG1ADDR(0x1fff0000);
-+
-+	ath79_register_m25p80(NULL);
-+
-+	ath79_register_leds_gpio(-1, ARRAY_SIZE(ubnt_uap_pro_gpio_leds),
-+				 ubnt_uap_pro_gpio_leds);
-+	ath79_register_gpio_keys_polled(-1, UBNT_XM_KEYS_POLL_INTERVAL,
-+                                        ARRAY_SIZE(uap_pro_gpio_keys),
-+                                        uap_pro_gpio_keys);
-+
-+	ath79_register_wmac(eeprom + UAP_PRO_WMAC_CALDATA_OFFSET, NULL);
-+	ap91_pci_init(eeprom + UAP_PRO_PCI_CALDATA_OFFSET, NULL);
-+
-+	ath79_register_mdio(0, 0x0);
-+	mdiobus_register_board_info(uap_pro_mdio0_info,
-+				    ARRAY_SIZE(uap_pro_mdio0_info));
-+
-+	ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_RGMII_GMAC0);
-+	ath79_init_mac(ath79_eth0_data.mac_addr,
-+		       eeprom + UAP_PRO_MAC0_OFFSET, 0);
-+
-+	/* GMAC0 is connected to an AR8327 switch */
-+	ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_RGMII;
-+	ath79_eth0_data.phy_mask = BIT(0);
-+	ath79_eth0_data.mii_bus_dev = &ath79_mdio0_device.dev;
-+	ath79_eth0_pll_data.pll_1000 = 0x06000000;
-+	ath79_register_eth(0);
-+}
-+
-+MIPS_MACHINE(ATH79_MACH_UBNT_UAP_PRO, "UAP-PRO", "Ubiquiti UniFi AP Pro",
-+	     ubnt_uap_pro_setup);
-+
-+#define UBNT_XW_GPIO_LED_L1		11
-+#define UBNT_XW_GPIO_LED_L2		16
-+#define UBNT_XW_GPIO_LED_L3		13
-+#define UBNT_XW_GPIO_LED_L4		14
-+
-+static struct gpio_led ubnt_xw_leds_gpio[] __initdata = {
-+	{
-+		.name		= "ubnt:red:link1",
-+		.gpio		= UBNT_XW_GPIO_LED_L1,
-+		.active_low	= 1,
-+	}, {
-+		.name		= "ubnt:orange:link2",
-+		.gpio		= UBNT_XW_GPIO_LED_L2,
-+		.active_low	= 1,
-+	}, {
-+		.name		= "ubnt:green:link3",
-+		.gpio		= UBNT_XW_GPIO_LED_L3,
-+		.active_low	= 1,
-+	}, {
-+		.name		= "ubnt:green:link4",
-+		.gpio		= UBNT_XW_GPIO_LED_L4,
-+		.active_low	= 1,
-+	},
-+};
-+
-+#define UBNT_ROCKET_TI_GPIO_LED_L1	16
-+#define UBNT_ROCKET_TI_GPIO_LED_L2	17
-+#define UBNT_ROCKET_TI_GPIO_LED_L3	18
-+#define UBNT_ROCKET_TI_GPIO_LED_L4	19
-+#define UBNT_ROCKET_TI_GPIO_LED_L5	20
-+#define UBNT_ROCKET_TI_GPIO_LED_L6	21
-+static struct gpio_led ubnt_rocket_ti_leds_gpio[] __initdata = {
-+	{
-+		.name		= "ubnt:green:link1",
-+		.gpio		= UBNT_ROCKET_TI_GPIO_LED_L1,
-+		.active_low	= 1,
-+	}, {
-+		.name		= "ubnt:green:link2",
-+		.gpio		= UBNT_ROCKET_TI_GPIO_LED_L2,
-+		.active_low	= 1,
-+	}, {
-+		.name		= "ubnt:green:link3",
-+		.gpio		= UBNT_ROCKET_TI_GPIO_LED_L3,
-+		.active_low	= 1,
-+	}, {
-+		.name		= "ubnt:green:link4",
-+		.gpio		= UBNT_ROCKET_TI_GPIO_LED_L4,
-+		.active_low	= 0,
-+	}, {
-+		.name		= "ubnt:green:link5",
-+		.gpio		= UBNT_ROCKET_TI_GPIO_LED_L5,
-+		.active_low	= 0,
-+	}, {
-+		.name		= "ubnt:green:link6",
-+		.gpio		= UBNT_ROCKET_TI_GPIO_LED_L6,
-+		.active_low	= 0,
-+	},
-+};
-+
-+static void __init ubnt_xw_init(void)
-+{
-+	u8 *eeprom = (u8 *) KSEG1ADDR(0x1fff0000);
-+
-+	ath79_register_m25p80(NULL);
-+
-+	ath79_register_leds_gpio(-1, ARRAY_SIZE(ubnt_xw_leds_gpio),
-+				 ubnt_xw_leds_gpio);
-+	ath79_register_gpio_keys_polled(-1, UBNT_XM_KEYS_POLL_INTERVAL,
-+                                        ARRAY_SIZE(ubnt_xm_gpio_keys),
-+                                        ubnt_xm_gpio_keys);
-+
-+	ath79_register_wmac(eeprom + UAP_PRO_WMAC_CALDATA_OFFSET, NULL);
-+	ap91_pci_init(eeprom + UAP_PRO_PCI_CALDATA_OFFSET, NULL);
-+
-+
-+	ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_MII_GMAC0 | AR934X_ETH_CFG_MII_GMAC0_SLAVE);
-+	ath79_init_mac(ath79_eth0_data.mac_addr,
-+		       eeprom + UAP_PRO_MAC0_OFFSET, 0);
-+
-+	ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_MII;
-+	ath79_eth0_data.mii_bus_dev = &ath79_mdio0_device.dev;
-+}
-+
-+static void __init ubnt_nano_m_xw_setup(void)
-+{
-+	ubnt_xw_init();
-+
-+	/* GMAC0 is connected to an AR8326 switch */
-+	ath79_register_mdio(0, ~(BIT(0) | BIT(1) | BIT(5)));
-+	ath79_eth0_data.phy_mask = (BIT(0) | BIT(1) | BIT(5));
-+	ath79_eth0_data.speed = SPEED_100;
-+	ath79_eth0_data.duplex = DUPLEX_FULL;
-+	ath79_register_eth(0);
-+}
-+
-+static void __init ubnt_loco_m_xw_setup(void)
-+{
-+	ubnt_xw_init();
-+
-+	ath79_register_mdio(0, ~BIT(1));
-+	ath79_eth0_data.phy_mask = BIT(1);
-+	ath79_register_eth(0);
-+}
-+
-+static void __init ubnt_rocket_m_xw_setup(void)
-+{
-+	u8 *eeprom = (u8 *) KSEG1ADDR(0x1fff0000);
-+
-+	ath79_register_m25p80(NULL);
-+
-+	ath79_register_leds_gpio(-1, ARRAY_SIZE(ubnt_xw_leds_gpio),
-+				 ubnt_xw_leds_gpio);
-+	ath79_register_gpio_keys_polled(-1, UBNT_XM_KEYS_POLL_INTERVAL,
-+                                        ARRAY_SIZE(ubnt_xm_gpio_keys),
-+                                        ubnt_xm_gpio_keys);
-+
-+	ath79_register_wmac(eeprom + UAP_PRO_WMAC_CALDATA_OFFSET, NULL);
-+	ap91_pci_init(eeprom + UAP_PRO_PCI_CALDATA_OFFSET, NULL);
-+
-+	ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_RGMII_GMAC0);
-+	ath79_init_mac(ath79_eth0_data.mac_addr,
-+		       eeprom + UAP_PRO_MAC0_OFFSET, 0);
-+
-+	ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_RGMII;
-+	ath79_eth0_data.mii_bus_dev = &ath79_mdio0_device.dev;
-+
-+	ath79_register_mdio(0, ~BIT(4));
-+	ath79_eth0_data.phy_mask = BIT(4);
-+	ath79_eth0_pll_data.pll_1000 = 0x06000000;
-+	ath79_register_eth(0);
-+}
-+
-+static struct at803x_platform_data ubnt_rocket_m_ti_at803_data = {
-+	.disable_smarteee = 1,
-+	.enable_rgmii_rx_delay = 1,
-+	.enable_rgmii_tx_delay = 1,
-+};
-+static struct mdio_board_info ubnt_rocket_m_ti_mdio_info[] = {
-+        {
-+                .bus_id = "ag71xx-mdio.0",
-+                .phy_addr = 4,
-+                .platform_data = &ubnt_rocket_m_ti_at803_data,
-+        },
-+};
-+
-+static void __init ubnt_rocket_m_ti_setup(void)
-+{
-+	u8 *eeprom = (u8 *) KSEG1ADDR(0x1fff0000);
-+
-+	ath79_register_m25p80(NULL);
-+
-+	ath79_register_leds_gpio(-1, ARRAY_SIZE(ubnt_rocket_ti_leds_gpio),
-+				 ubnt_rocket_ti_leds_gpio);
-+	ath79_register_gpio_keys_polled(-1, UBNT_XM_KEYS_POLL_INTERVAL,
-+                                        ARRAY_SIZE(ubnt_xm_gpio_keys),
-+                                        ubnt_xm_gpio_keys);
-+
-+	ap91_pci_init(eeprom + 0x1000, NULL);
-+
-+	ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_RGMII_GMAC0);
-+	ath79_setup_ar934x_eth_rx_delay(3, 3);
-+	ath79_init_mac(ath79_eth0_data.mac_addr,
-+		       eeprom + UAP_PRO_MAC0_OFFSET, 0);
-+	ath79_init_mac(ath79_eth1_data.mac_addr,
-+		       eeprom + UAP_PRO_MAC1_OFFSET, 0);
-+
-+	ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_RGMII;
-+	ath79_eth0_data.mii_bus_dev = &ath79_mdio0_device.dev;
-+	ath79_eth1_data.phy_if_mode = PHY_INTERFACE_MODE_GMII;
-+	ath79_eth1_data.mii_bus_dev = &ath79_mdio1_device.dev;
-+
-+	mdiobus_register_board_info(ubnt_rocket_m_ti_mdio_info,
-+			ARRAY_SIZE(ubnt_rocket_m_ti_mdio_info));
-+	ath79_register_mdio(0, 0x0);
-+
-+
-+	ath79_eth0_data.phy_mask = BIT(4);
-+	/* read out from vendor */
-+	ath79_eth0_pll_data.pll_1000 = 0x2000000;
-+	ath79_eth0_pll_data.pll_10 = 0x1313;
-+	ath79_register_eth(0);
-+
-+	ath79_register_mdio(1, 0x0);
-+	ath79_eth1_data.phy_mask = BIT(3);
-+	ath79_register_eth(1);
-+}
-+
-+
-+MIPS_MACHINE(ATH79_MACH_UBNT_NANO_M_XW, "UBNT-NM-XW", "Ubiquiti Nanostation M XW",
-+	     ubnt_nano_m_xw_setup);
-+
-+MIPS_MACHINE(ATH79_MACH_UBNT_LOCO_M_XW, "UBNT-LOCO-XW", "Ubiquiti Loco M XW",
-+	     ubnt_loco_m_xw_setup);
-+
-+MIPS_MACHINE(ATH79_MACH_UBNT_ROCKET_M_XW, "UBNT-RM-XW", "Ubiquiti Rocket M XW",
-+	     ubnt_rocket_m_xw_setup);
-+
-+MIPS_MACHINE(ATH79_MACH_UBNT_ROCKET_M_TI, "UBNT-RM-TI", "Ubiquiti Rocket M TI",
-+	     ubnt_rocket_m_ti_setup);
-+
-+static struct gpio_led ubnt_airgateway_gpio_leds[] __initdata = {
-+	{
-+		.name	   = "ubnt:blue:wlan",
-+		.gpio	   = 0,
-+	}, {
-+		.name	   = "ubnt:white:status",
-+		.gpio	   = 1,
-+	},
-+};
-+
-+static struct gpio_keys_button airgateway_gpio_keys[] __initdata = {
-+	{
-+		.desc		= "reset",
-+		.type		= EV_KEY,
-+		.code		= KEY_RESTART,
-+		.debounce_interval	= UBNT_XM_KEYS_DEBOUNCE_INTERVAL,
-+		.gpio		= 12,
-+		.active_low	= 1,
-+	}
-+};
-+
-+static void __init ubnt_airgateway_setup(void)
-+{
-+	u32 t;
-+	u8 *mac0 = (u8 *) KSEG1ADDR(0x1fff0000);
-+	u8 *mac1 = (u8 *) KSEG1ADDR(0x1fff0000 + ETH_ALEN);
-+	u8 *ee = (u8 *) KSEG1ADDR(0x1fff1000);
-+
-+
-+	ath79_gpio_function_disable(AR933X_GPIO_FUNC_ETH_SWITCH_LED0_EN |
-+				     AR933X_GPIO_FUNC_ETH_SWITCH_LED1_EN |
-+				     AR933X_GPIO_FUNC_ETH_SWITCH_LED2_EN |
-+				     AR933X_GPIO_FUNC_ETH_SWITCH_LED3_EN |
-+				     AR933X_GPIO_FUNC_ETH_SWITCH_LED4_EN);
-+
-+	t = ath79_reset_rr(AR933X_RESET_REG_BOOTSTRAP);
-+	t |= AR933X_BOOTSTRAP_MDIO_GPIO_EN;
-+	ath79_reset_wr(AR933X_RESET_REG_BOOTSTRAP, t);
-+
-+	ath79_register_m25p80(NULL);
-+	ath79_register_leds_gpio(-1, ARRAY_SIZE(ubnt_airgateway_gpio_leds),
-+				 ubnt_airgateway_gpio_leds);
-+
-+	ath79_register_gpio_keys_polled(-1, UBNT_XM_KEYS_POLL_INTERVAL,
-+					ARRAY_SIZE(airgateway_gpio_keys),
-+					airgateway_gpio_keys);
-+
-+	ath79_init_mac(ath79_eth1_data.mac_addr, mac0, 0);
-+	ath79_init_mac(ath79_eth0_data.mac_addr, mac1, 0);
-+
-+	ath79_register_mdio(0, 0x0);
-+
-+	ath79_register_eth(1);
-+	ath79_register_eth(0);
-+
-+	ath79_register_wmac(ee, NULL);
-+}
-+
-+MIPS_MACHINE(ATH79_MACH_UBNT_AIRGW, "UBNT-AGW", "Ubiquiti AirGateway",
-+	     ubnt_airgateway_setup);
-+
 --- a/arch/mips/ath79/Kconfig
 +++ b/arch/mips/ath79/Kconfig
 @@ -68,12 +68,16 @@ config ATH79_MACH_PB44
  	  Atheros PB44 reference board.
- 
+
  config ATH79_MACH_UBNT_XM
 -	bool "Ubiquiti Networks XM (rev 1.0) board"
 +	bool "Ubiquiti Networks XM/UniFi boards"
diff --git a/target/linux/ar71xx/patches-4.4/610-MIPS-ath79-UBNT-add-airGateway-pro-support.patch b/target/linux/ar71xx/patches-4.4/610-MIPS-ath79-UBNT-add-airGateway-pro-support.patch
deleted file mode 100644
index 27cc1e5..0000000
--- a/target/linux/ar71xx/patches-4.4/610-MIPS-ath79-UBNT-add-airGateway-pro-support.patch
+++ /dev/null
@@ -1,62 +0,0 @@
---- a/arch/mips/ath79/mach-ubnt-xm.c
-+++ b/arch/mips/ath79/mach-ubnt-xm.c
-@@ -642,3 +642,59 @@ static void __init ubnt_airgateway_setup
- MIPS_MACHINE(ATH79_MACH_UBNT_AIRGW, "UBNT-AGW", "Ubiquiti AirGateway",
- 	     ubnt_airgateway_setup);
- 
-+static struct gpio_led ubnt_airgateway_pro_gpio_leds[] __initdata = {
-+	{
-+		.name	   = "ubnt:blue:wlan",
-+		.gpio	   = 13,
-+	}, {
-+		.name	   = "ubnt:white:status",
-+		.gpio	   = 17,
-+	},
-+};
-+
-+
-+static struct gpio_keys_button airgateway_pro_gpio_keys[] __initdata = {
-+	{
-+		.desc		= "reset",
-+		.type		= EV_KEY,
-+		.code		= KEY_RESTART,
-+		.debounce_interval	= UBNT_XM_KEYS_DEBOUNCE_INTERVAL,
-+		.gpio		= 12,
-+		.active_low	= 1,
-+	}
-+};
-+
-+static void __init ubnt_airgateway_pro_setup(void)
-+{
-+	u8 *eeprom = (u8 *) KSEG1ADDR(0x1fff0000);
-+	u8 *mac0 = (u8 *) KSEG1ADDR(0x1fff0000);
-+
-+	ath79_register_m25p80(NULL);
-+	ath79_register_leds_gpio(-1, ARRAY_SIZE(ubnt_airgateway_pro_gpio_leds),
-+				 ubnt_airgateway_pro_gpio_leds);
-+
-+	ath79_register_gpio_keys_polled(-1, UBNT_XM_KEYS_POLL_INTERVAL,
-+					ARRAY_SIZE(airgateway_pro_gpio_keys),
-+					airgateway_pro_gpio_keys);
-+
-+	ath79_register_wmac(eeprom + UAP_PRO_WMAC_CALDATA_OFFSET, NULL);
-+	ap91_pci_init(eeprom + UAP_PRO_PCI_CALDATA_OFFSET, NULL);
-+
-+
-+	ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_SW_ONLY_MODE);
-+
-+	ath79_register_mdio(1, 0x0);
-+
-+	/* GMAC0 is left unused in this configuration */
-+
-+	/* GMAC1 is connected to MAC0 on the internal switch */
-+	/* The PoE/WAN port connects to port 5 on the internal switch */
-+	/* The LAN port connects to port 4 on the internal switch */
-+	ath79_init_mac(ath79_eth1_data.mac_addr, mac0, 0);
-+	ath79_eth1_data.phy_if_mode = PHY_INTERFACE_MODE_GMII;
-+	ath79_register_eth(1);
-+
-+}
-+
-+MIPS_MACHINE(ATH79_MACH_UBNT_AIRGWP, "UBNT-AGWP", "Ubiquiti AirGateway Pro",
-+	     ubnt_airgateway_pro_setup);
-- 
2.8.1



From ldpinney at gmail.com  Sun Jun 12 11:23:25 2016
From: ldpinney at gmail.com (L. D. Pinney)
Date: Sun, 12 Jun 2016 13:23:25 -0500
Subject: [LEDE-DEV] lede integration issues remaining from the detrius
	of cerowrt
In-Reply-To: <CAA93jw7=bHNXJqmjWmg3CHHH-biua17wK4AHfn_wB0wPWs=EqQ@mail.gmail.com>
References: <CAA93jw7=bHNXJqmjWmg3CHHH-biua17wK4AHfn_wB0wPWs=EqQ@mail.gmail.com>
Message-ID: <CAJOqq5TB4qki1iWHZd71kzXYoA=A3+4BeycoNPKqRXFWZ6bMZQ@mail.gmail.com>

Much like the convention of prefixing your subject line with [PATCH]
messages like this should be required to have a prefix such as
[DRIVEL] for effective filtering

lede integration issues ??

I don't see why there IS an issue CeroWrt died for good reason(s) ... such as :

Low return on investment by it's corporate sponsorship.
Only supported ONE router (and a few subtypes thereof)
Let the detrius settle to the bottom where it belongs.

I am probably the only user of the gnugol package. :(
There is most likely a good reason for that :)

fdisk doesn't support GPT ??

>From the lede 'menuconfig'
Base system > busybox
Linux System Utilities  --->

[*] fdisk
[*]   Write support
[ ]     Support AIX disklabels (NEW)
[ ]     Support SGI disklabels (NEW)
[ ]     Support SUN disklabels (NEW)
[ ]     Support BSD disklabels (NEW)
[*]     Support GPT disklabels
[*]     Support expert mode

So what the standard LEDE images don't support fdisk with GPT one can
easily format his so called large USB drive on a desktop...
Why should a wireless router support this by default?

We used lighttpd in cerowrt as it was tons faster than uhttpd.

"tons faster" ...really is the readership of LEDE-DEV primarily made
of teenage girls?

Can you provide evidence to suport this ...

Simply put .. It's a memory hog for a typical router ... how well does
it work with 32M or even 64M of RAM?

Are you suggesting LEDE drop support for 4M flash / 32M RAM routers in
favor of using lighttpd as the default?

defining what lede's use cases will be 5-10 years in the future

Really LEDE should have a five year plan much like the Communist Party
of China ?


On Sat, Jun 11, 2016 at 12:44 PM, Dave Taht <dave.taht at gmail.com> wrote:
> happy to see cake working today! thx all!
>
> In https://github.com/dtaht/ceropackages-3.10:
>
> A) We have flent's tc-iterate.c as a fast, lightweight means of
> polling fq_codel, pie, cake stats (as the shell in openwrt doesn't
> support a subsecond sleep) for openwrt.
>
> (However this package and code is in need of iteration to support
> polling the new stats presented in the fq_codel for wifi sysfs code.)
>
> Having something like this working is essential to analyze the real
> performance and correctness of the new implementations on the low end
> hardware.
>
> B) I am probably the only user of the gnugol package. :(
>
> C) I really need to sync the isochronous code with what avery has upstream
>
> D) https://github.com/dtaht/ceropackages-3.10/tree/master/utils/nanom5poe
>
> I don't know what landed upstream to control poe for the nano-m5
> radios, if anything?
>
> E) https://github.com/dtaht/ceropackages-3.10/tree/master/utils/gdisk
>
> The principal problem with fdisk nowadays is that very large (> 2TB, I
> think) devices are not supported by it, and require a GPT capable
> tool. Is there a replacement in lede that handles GPT? If not - this
> is an old gdisk port to openwrt that I used to use.
>
> F) https://github.com/dtaht/ceropackages-3.10/tree/master/utils/cerowrt-scripts
> was a tool we used to measure latency under load directly on the
> router...
>
> some other packages that might be worth upstreaming, or putting in
> another repo or updating in ceropackages
>
> owamp: lets us measure ping times very precisely. (requires good ntp)
> ntpsec - a vastly hardened full fledged ntp fork https://www.ntpsec.org/
> scamper - two other measurement tools
> shaperprobe
>
> ?
>
> G) We used lighttpd in cerowrt as it was tons faster than uhttpd and
> flexible enough to also do local web serving. can it (or ngnix) be
> substituted for uhttpd? Or has uhttpd got faster?
>
> H) Anyone working on go or rust for lede? hugo and ipfs and all the
> other blockchain related distributed web bits looks like fun...
>
> It looks like the static linking in go is a deal-killer
>
> https://github.com/GeertJohan/openwrt-go/issues/2
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


From mkroken at gmail.com  Sun Jun 12 14:49:42 2016
From: mkroken at gmail.com (Magnus Kroken)
Date: Sun, 12 Jun 2016 23:49:42 +0200
Subject: [LEDE-DEV] [PATCH] openvpn: update to 2.3.11
Message-ID: <1465768182-15833-1-git-send-email-mkroken@gmail.com>

Security fixes:
* Fixed port-share bug with DoS potential
* Fix buffer overflow by user supplied data

Full changelog: https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn23#OpenVPN2.3.11

Signed-off-by: Magnus Kroken <mkroken at gmail.com>
---
 package/network/services/openvpn/Makefile           |  6 +++---
 ...100-polarssl-disable-runtime-version-check.patch |  2 +-
 .../patches/101-remove_polarssl_debug_call.patch    | 21 +++++++++++++++++++++
 3 files changed, 25 insertions(+), 4 deletions(-)
 create mode 100644 package/network/services/openvpn/patches/101-remove_polarssl_debug_call.patch

diff --git a/package/network/services/openvpn/Makefile b/package/network/services/openvpn/Makefile
index e0e1b12..19f78bc 100644
--- a/package/network/services/openvpn/Makefile
+++ b/package/network/services/openvpn/Makefile
@@ -9,12 +9,12 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=openvpn
 
-PKG_VERSION:=2.3.10
-PKG_RELEASE:=2
+PKG_VERSION:=2.3.11
+PKG_RELEASE:=1
 
 PKG_SOURCE_URL:=http://swupdate.openvpn.net/community/releases
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
-PKG_MD5SUM:=8831ded42db4317e287157b6b8cba74c
+PKG_MD5SUM:=0f5f1ca1dc5743fa166d93dd4ec952f014b5f33bafd88f0ea34b455cae1434a7
 
 PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)-$(BUILD_VARIANT)/$(PKG_NAME)-$(PKG_VERSION)
 
diff --git a/package/network/services/openvpn/patches/100-polarssl-disable-runtime-version-check.patch b/package/network/services/openvpn/patches/100-polarssl-disable-runtime-version-check.patch
index 73ab406..bd8e5b7 100644
--- a/package/network/services/openvpn/patches/100-polarssl-disable-runtime-version-check.patch
+++ b/package/network/services/openvpn/patches/100-polarssl-disable-runtime-version-check.patch
@@ -1,6 +1,6 @@
 --- a/src/openvpn/ssl_polarssl.c
 +++ b/src/openvpn/ssl_polarssl.c
-@@ -1153,7 +1153,7 @@ const char *
+@@ -1151,7 +1151,7 @@ const char *
  get_ssl_library_version(void)
  {
      static char polar_version[30];
diff --git a/package/network/services/openvpn/patches/101-remove_polarssl_debug_call.patch b/package/network/services/openvpn/patches/101-remove_polarssl_debug_call.patch
new file mode 100644
index 0000000..3cef323
--- /dev/null
+++ b/package/network/services/openvpn/patches/101-remove_polarssl_debug_call.patch
@@ -0,0 +1,21 @@
+openvpn: remove call to PolarSSL debug function
+
+OpenVPN >=2.3.11 uses PolarSSL debug functions for improved logging.
+This requires that PolarSSL is built with POLARSSL_DEBUG_C, which increases
+its size significantly.
+
+This change does not impact OpenVPN operation, see:
+https://sourceforge.net/p/openvpn/mailman/message/35153943/
+
+Signed-off-by: Magnus Kroken <mkroken at gmail.com>
+
+--- a/src/openvpn/ssl_polarssl.c
++++ b/src/openvpn/ssl_polarssl.c
+@@ -742,7 +742,7 @@ void key_state_ssl_init(struct key_state
+   if (polar_ok(ssl_init(ks_ssl->ctx)))
+     {
+       /* Initialise SSL context */
+-      debug_set_threshold(3);
++      /*debug_set_threshold(3);*/
+       ssl_set_dbg (ks_ssl->ctx, my_debug, NULL);
+       ssl_set_endpoint (ks_ssl->ctx, ssl_ctx->endpoint);
-- 
2.1.4



From champetier.etienne at gmail.com  Sun Jun 12 15:25:54 2016
From: champetier.etienne at gmail.com (Etienne CHAMPETIER)
Date: Sun, 12 Jun 2016 22:25:54 +0000
Subject: [LEDE-DEV] [PATCH v2] base-files: seed /dev/urandom
Message-ID: <1465770354-11680-1-git-send-email-champetier.etienne@gmail.com>

This commit:
1) seed /dev/urandom with a saved seed as early as possible
   (using /lib/preinit/81_urandom_seed)
2) save a new seed using getrandom() so we are sure /dev/urandom
   pool is initialized (using /etc/init.d/urandom_seed)

seed size is 512 bytes (ie /proc/sys/kernel/random/poolsize / 8)
it's the same size as in ubuntu 14.04 and all systemd systems

seed file is /etc/urandom.seed (need a writable path)

seeding /dev/urandom doesn't change entropy estimation, so we still have
"random: ubus urandom read with 4 bits of entropy available"
messages in the logs, but we can now ignore them if
after "urandom-seed: Seeding with ..." message

We could also add an urandom.seed at build time to improve first boot

v2: log preinit messages to /dev/kmsg

Signed-off-by: Etienne CHAMPETIER <champetier.etienne at gmail.com>
---
 package/base-files/files/etc/init.d/urandom_seed   | 22 ++++++++++++++++++++++
 .../base-files/files/lib/preinit/81_urandom_seed   | 19 +++++++++++++++++++
 2 files changed, 41 insertions(+)
 create mode 100755 package/base-files/files/etc/init.d/urandom_seed
 create mode 100644 package/base-files/files/lib/preinit/81_urandom_seed

diff --git a/package/base-files/files/etc/init.d/urandom_seed b/package/base-files/files/etc/init.d/urandom_seed
new file mode 100755
index 0000000..d7c1f71
--- /dev/null
+++ b/package/base-files/files/etc/init.d/urandom_seed
@@ -0,0 +1,22 @@
+#!/bin/sh /etc/rc.common
+
+START=99
+
+SEED=/etc/urandom.seed
+
+error_exit() {
+    logger -t urandom_seed "$1"
+    exit 1
+}
+
+save_seed() {
+    touch $SEED.tmp || error_exit "touch failed"
+    chown root:root $SEED.tmp || error_exit "chown failed"
+    chmod 600 $SEED.tmp || error_exit "chmod failed"
+    getrandom 512 > $SEED.tmp || error_exit "getrandom failed"
+    mv $SEED.tmp $SEED || error_exit "mv failed"
+}
+
+boot() {
+    save_seed
+}
diff --git a/package/base-files/files/lib/preinit/81_urandom_seed b/package/base-files/files/lib/preinit/81_urandom_seed
new file mode 100644
index 0000000..2f8fc5e
--- /dev/null
+++ b/package/base-files/files/lib/preinit/81_urandom_seed
@@ -0,0 +1,19 @@
+#!/bin/sh
+
+logk() {
+    echo "urandom-seed: $1" > /dev/kmsg
+}
+
+do_urandom_seed() {
+    S=/etc/urandom.seed
+    U=/dev/urandom
+
+    [ -c $U ] || { logk "Something is wrong with $U"; return; }
+    [ -f $S ] || { logk "Seed file not found: $S"; return; }
+    [ -O $S -a -G $S -a ! -x $S ] || { logk "Wrong owner / permissions for $S"; return; }
+
+    logk "Seeding with $S"
+    cat $S > $U
+}
+
+boot_hook_add preinit_main do_urandom_seed
-- 
1.9.1



From champetier.etienne at gmail.com  Sun Jun 12 15:56:28 2016
From: champetier.etienne at gmail.com (Etienne Champetier)
Date: Mon, 13 Jun 2016 00:56:28 +0200
Subject: [LEDE-DEV] [PATCH] base-files: seed /dev/urandom
In-Reply-To: <d16a674b-f1f0-67cb-ec02-c40804ed5a83@nbd.name>
References: <1465627075-13683-1-git-send-email-champetier.etienne@gmail.com>
 <d16a674b-f1f0-67cb-ec02-c40804ed5a83@nbd.name>
Message-ID: <CAOdf3gq8Yx6M1nUZrOBog-2ziaqP-F1qpapFf1=32XtuVaDYWg@mail.gmail.com>

Hi Felix,

2016-06-12 12:45 GMT+02:00 Felix Fietkau <nbd at nbd.name>:
> On 2016-06-11 08:37, Etienne CHAMPETIER wrote:
>> This commit:
>> 1) seed /dev/urandom with a saved seed as early as possible
>>    (using /lib/preinit/81_urandom_seed)
>> 2) save a new seed using getrandom() so we are sure /dev/urandom
>>    pool is initialized (using /etc/init.d/urandom_seed)
>>
>> seed size is 512 bytes (ie /proc/sys/kernel/random/poolsize / 8)
>> it's the same size as in ubuntu 14.04 and all systemd systems
>>
>> seed file is /etc/urandom.seed (need a writable path)
>>
>> seeding /dev/urandom doesn't change entropy estimation, so we still have
>> "random: ubus urandom read with 4 bits of entropy available"
>> messages in the logs, but we can now ignore them
>>
>> We could also add an urandom.seed at build time to improve first boot
> I'm not sure writing to flash on every single boot on every device is a
> good default behavior.
>

Just saw your comment, it endend up in spam ...

Reusing the same seed multiple time is not really recommended, as it
means all boot with same seed are in the same state.
What would be an acceptable behaviour for you?
I could wait for ntp and then check if seed is older than X, but
that's way less robust.

BTW, we are already writing at every boot for dnsmasq/dnssec (/etc/dnsmasq.time)

Etienne

> - Felix


From john at phrozen.org  Sun Jun 12 21:54:15 2016
From: john at phrozen.org (John Crispin)
Date: Mon, 13 Jun 2016 06:54:15 +0200
Subject: [LEDE-DEV] [PATCH] tools/mkfwimage2: remove 256 length limit
 for partition images
In-Reply-To: <20160611021523.23793-1-lynxis@fe80.eu>
References: <20160611021523.23793-1-lynxis@fe80.eu>
Message-ID: <26a808c5-6e86-5194-9b1b-424e3c8bc887@phrozen.org>

could it be that the subject is wrong s/images/names/ ?

	John

On 11/06/2016 04:15, Alexander Couzens wrote:
> Signed-off-by: Alexander Couzens <lynxis at fe80.eu>
> ---
>  tools/firmware-utils/src/mkfwimage2.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/firmware-utils/src/mkfwimage2.c b/tools/firmware-utils/src/mkfwimage2.c
> index 146b2ad..8255a04 100644
> --- a/tools/firmware-utils/src/mkfwimage2.c
> +++ b/tools/firmware-utils/src/mkfwimage2.c
> @@ -197,6 +197,10 @@ int str2u32(char *arg, u_int32_t *val)
>  	return 0;
>  }
>  
> +#ifndef STRINGIFY
> +#define STRINGIFY2(X) #X
> +#define STRINGIFY(X) STRINGIFY2(X)
> +#endif
>  static int image_layout_add_partition(const char *part_desc)
>  {
>  	part_data_t *d;
> @@ -211,8 +215,9 @@ static int image_layout_add_partition(const char *part_desc)
>  		return (-1);
>  	}
>  
> +
>  	d = &im.parts[im.part_count];
> -	t = sscanf(part_desc, "%15[-0-9a-zA-Z]:%15[0-9a-fA-Fx]:%15[0-9a-fA-Fx]:%15[0-9a-fA-Fx]:%15[0-9a-fA-Fx]:%256s",
> +	t = sscanf(part_desc, "%15[-0-9a-zA-Z]:%15[0-9a-fA-Fx]:%15[0-9a-fA-Fx]:%15[0-9a-fA-Fx]:%15[0-9a-fA-Fx]:%"STRINGIFY(PATH_MAX)"s",
>  			d->partition_name,
>  			offset,
>  			length,
> 


From john at phrozen.org  Sun Jun 12 22:00:38 2016
From: john at phrozen.org (John Crispin)
Date: Mon, 13 Jun 2016 07:00:38 +0200
Subject: [LEDE-DEV] [PATCH] Pass method paraneter to Lua notifications.
In-Reply-To: <1465653272-29005-1-git-send-email-iainf@netduma.com>
References: <1465653272-29005-1-git-send-email-iainf@netduma.com>
Message-ID: <eee11966-ee39-2b5e-8391-7408f441e502@phrozen.org>

Hi Ian,

there is a typo in the subject and the description of the patch is
missing in the body. could you please fix those 2 things and resend the
patch ?

	Johb

On 11/06/2016 15:54, Iain Fraser wrote:
> ---
>  lua/ubus.c |    5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/lua/ubus.c b/lua/ubus.c
> index f59af90..be54d8d 100644
> --- a/lua/ubus.c
> +++ b/lua/ubus.c
> @@ -770,11 +770,12 @@ ubus_sub_notify_handler(struct ubus_context *ctx, struct ubus_object *obj,
>  	lua_remove(state, -2);
>  
>  	if (lua_isfunction(state, -1)) {
> +		lua_pushstring(state, method);
>  		if( msg ){
>  			ubus_lua_parse_blob_array(state, blob_data(msg), blob_len(msg), true);
> -			lua_call(state, 1, 0);
> +			lua_call(state, 2, 0);
>  		} else {
> -			lua_call(state, 0, 0);
> +			lua_call(state, 1, 0);
>  		}
>  	} else {
>  		lua_pop(state, 1);
> 


From john at phrozen.org  Sun Jun 12 22:03:16 2016
From: john at phrozen.org (John Crispin)
Date: Mon, 13 Jun 2016 07:03:16 +0200
Subject: [LEDE-DEV] [PATCH mountd] filesystem mount options in uci config
In-Reply-To: <1465550281-8719-1-git-send-email-olivier.hardouin@gmail.com>
References: <1465550281-8719-1-git-send-email-olivier.hardouin@gmail.com>
Message-ID: <efe151af-b1e5-a37b-247f-54c10fe5ebca@phrozen.org>

Hi,

comment inline.

On 10/06/2016 11:18, olivier.hardouin at gmail.com wrote:
> Move (previously hardcoded) mount option to UCI to allow different configuration 
> like charset (utf-8 or iso) and filesystem driver (if alternative ones are used).
> The fs names are changed in lowercase to comply with UCI general naming.
> 
> Signed-off-by: Olivier Hardouin <olivier.hardouin at gmail.com>
> ---
>  mount.c | 69 ++++++++++++++++++++++++++---------------------------------------
>  1 file changed, 28 insertions(+), 41 deletions(-)
> 
> diff --git a/mount.c b/mount.c
> index 8892040..c8f7ea6 100644
> --- a/mount.c
> +++ b/mount.c
> @@ -51,15 +51,15 @@ struct mount {
>  char *fs_names[] = {
>  	"",
>  	"",
> -	"MBR",
> -	"EXT2",
> -	"EXT3",
> -	"FAT",
> -	"HFSPLUS",
> +	"mbr",
> +	"ext2",
> +	"ext3",
> +	"fat",
> +	"hfsplus",
>  	"",
> -	"NTFS",
> +	"ntfs",
>  	"",
> -	"EXT4"
> +	"ext4"
>  };
>  
>  #define MAX_MOUNTED		32
> @@ -227,42 +227,29 @@ int mount_new(char *path, char *dev)
>  	pid = autofs_safe_fork();
>  	if(!pid)
>  	{
> -		if(mount->fs == EXFAT)
> +		if(mount->fs > MBR && mount->fs <= EXT4)
>  		{
> -			log_printf("mount -t exfat -o rw,uid=1000,gid=1000 /dev/%s %s", mount->dev, tmp);
> -			ret = system_printf("mount -t exfat -o rw,uid=1000,gid=1000 /dev/%s %s", mount->dev, tmp);
> -		}
> -		if(mount->fs == FAT)
> -		{
> -			log_printf("mount -t vfat -o rw,uid=1000,gid=1000 /dev/%s %s", mount->dev, tmp);
> -			ret = system_printf("mount -t vfat -o rw,uid=1000,gid=1000 /dev/%s %s", mount->dev, tmp);
> -		}
> -		if(mount->fs == EXT4)
> -		{
> -			log_printf("mount -t ext4 -o rw,defaults /dev/%s %s", mount->dev, tmp);
> -			ret = system_printf("mount -t ext4 -o rw,defaults /dev/%s %s", mount->dev, tmp);
> -		}
> -		if(mount->fs == EXT3)
> -		{
> -			log_printf("mount -t ext3 -o rw,defaults /dev/%s %s", mount->dev, tmp);
> -			ret = system_printf("mount -t ext3 -o rw,defaults /dev/%s %s", mount->dev, tmp);
> -		}
> -		if(mount->fs == EXT2)
> -		{
> -			log_printf("mount -t ext2 -o rw,defaults /dev/%s %s", mount->dev, tmp);
> -			ret = system_printf("mount -t ext2 -o rw,defaults /dev/%s %s", mount->dev, tmp);
> -		}
> -		if(mount->fs == HFSPLUS)
> -		{
> -			log_printf("mount -t hfsplus -o rw,defaults,uid=1000,gid=1000 /dev/%s %s", mount->dev, tmp);
> -			ret = system_printf("mount -t hfsplus -o rw,defaults,uid=1000,gid=1000 /dev/%s %s", mount->dev, tmp);
> -		}
> -		if(mount->fs == NTFS)
> -		{
> -			log_printf("ntfs-3g /dev/%s %s -o force", mount->dev, tmp);
> -			ret = system_printf("ntfs-3g /dev/%s %s -o force", mount->dev, tmp);
> +			struct uci_context *ctx;
> +			char *options, *fstype;
> +			ctx = ucix_init("mountd");
> +			options = ucix_get_option(ctx, "mountd", fs_names[mount->fs], "options");
> +			fstype = ucix_get_option(ctx, "mountd", fs_names[mount->fs], "fstype");

this might be NULL but is used below without checking for NULL. i am not
sure these even needs to be loaded from uci as it is the same as
fs_names[mount->fs].

could you look into this and then resend the patch ?

	John

> +			ucix_cleanup(ctx);
> +			if(!fstype)
> +			{
> +				log_printf("mounting /dev/%s failed, expecting 'fstype' uci parameter (kernel driver) for %s", mount->dev, fs_names[mount->fs]);
> +			} else {
> +				if(!options)
> +				{
> +					log_printf("mount -t %s /dev/%s %s", fstype, mount->dev, tmp);
> +					ret = system_printf("mount -t %s /dev/%s %s", fstype, mount->dev, tmp);
> +				} else {
> +					log_printf("mount -t %s -o %s /dev/%s %s", fstype, options, mount->dev, tmp);
> +					ret = system_printf("mount -t %s -o %s /dev/%s %s", fstype, options, mount->dev, tmp);
> +				}
> +			}
> +			exit(WEXITSTATUS(ret));
>  		}
> -		exit(WEXITSTATUS(ret));
>  	}
>  	pid = waitpid(pid, &ret, 0);
>  	ret = WEXITSTATUS(ret);
> 


From champetier.etienne at gmail.com  Sun Jun 12 23:59:35 2016
From: champetier.etienne at gmail.com (Etienne CHAMPETIER)
Date: Mon, 13 Jun 2016 06:59:35 +0000
Subject: [LEDE-DEV] [PATCH v3] base-files: seed /dev/urandom
Message-ID: <1465801175-34626-1-git-send-email-champetier.etienne@gmail.com>

This commit:
1) seed /dev/urandom with a saved seed as early as possible
   (using /lib/preinit/81_urandom_seed)
2) save a new seed using getrandom() so we are sure /dev/urandom
   pool is initialized (using /etc/init.d/urandom_seed)

seed size is 512 bytes (ie /proc/sys/kernel/random/poolsize / 8)
it's the same size as in ubuntu 14.04 and all systemd systems

seed file is /etc/urandom.seed (need a writable path)

seeding /dev/urandom doesn't change entropy estimation, so we still have
"random: ubus urandom read with 4 bits of entropy available"
messages in the logs, but we can now ignore them if
after "urandom-seed: Seeding with ..." message

We could also add an urandom.seed at build time to improve first boot

v2: log preinit messages to /dev/kmsg
v3: use non generic function name for logging, as /lib/preinit/ files
    are all sourced together in /etc/preinit

Signed-off-by: Etienne CHAMPETIER <champetier.etienne at gmail.com>
---
 package/base-files/files/etc/init.d/urandom_seed   | 22 ++++++++++++++++++++++
 .../base-files/files/lib/preinit/81_urandom_seed   | 19 +++++++++++++++++++
 2 files changed, 41 insertions(+)
 create mode 100755 package/base-files/files/etc/init.d/urandom_seed
 create mode 100644 package/base-files/files/lib/preinit/81_urandom_seed

diff --git a/package/base-files/files/etc/init.d/urandom_seed b/package/base-files/files/etc/init.d/urandom_seed
new file mode 100755
index 0000000..d7c1f71
--- /dev/null
+++ b/package/base-files/files/etc/init.d/urandom_seed
@@ -0,0 +1,22 @@
+#!/bin/sh /etc/rc.common
+
+START=99
+
+SEED=/etc/urandom.seed
+
+error_exit() {
+    logger -t urandom_seed "$1"
+    exit 1
+}
+
+save_seed() {
+    touch $SEED.tmp || error_exit "touch failed"
+    chown root:root $SEED.tmp || error_exit "chown failed"
+    chmod 600 $SEED.tmp || error_exit "chmod failed"
+    getrandom 512 > $SEED.tmp || error_exit "getrandom failed"
+    mv $SEED.tmp $SEED || error_exit "mv failed"
+}
+
+boot() {
+    save_seed
+}
diff --git a/package/base-files/files/lib/preinit/81_urandom_seed b/package/base-files/files/lib/preinit/81_urandom_seed
new file mode 100644
index 0000000..76c849a
--- /dev/null
+++ b/package/base-files/files/lib/preinit/81_urandom_seed
@@ -0,0 +1,19 @@
+#!/bin/sh
+
+log_urandom_seed() {
+    echo "urandom-seed: $1" > /dev/kmsg
+}
+
+do_urandom_seed() {
+    S=/etc/urandom.seed
+    U=/dev/urandom
+
+    [ -c $U ] || { log_urandom_seed "Something is wrong with $U"; return; }
+    [ -f $S ] || { log_urandom_seed "Seed file not found: $S"; return; }
+    [ -O $S -a -G $S -a ! -x $S ] || { log_urandom_seed "Wrong owner / permissions for $S"; return; }
+
+    log_urandom_seed "Seeding with $S"
+    cat $S > $U
+}
+
+boot_hook_add preinit_main do_urandom_seed
-- 
1.9.1



From john at phrozen.org  Mon Jun 13 00:58:10 2016
From: john at phrozen.org (John Crispin)
Date: Mon, 13 Jun 2016 09:58:10 +0200
Subject: [LEDE-DEV] [PATCH mountd] filesystem mount options in uci config
In-Reply-To: <CAE0HSK4Fq+EdoEDM-d5-4Kguea+bkSpMLM9JuK_jB3rJbjqNLA@mail.gmail.com>
References: <1465550281-8719-1-git-send-email-olivier.hardouin@gmail.com>
 <efe151af-b1e5-a37b-247f-54c10fe5ebca@phrozen.org>
 <CAE0HSK4Fq+EdoEDM-d5-4Kguea+bkSpMLM9JuK_jB3rJbjqNLA@mail.gmail.com>
Message-ID: <033a4fcc-020d-727d-cb0f-d8554d91c915@phrozen.org>



On 13/06/2016 09:47, Olivier Hardouin wrote:
> Hi John,
> 
> Thanks for your comment.
> You're right, I need to add some check before getting uci options.
> 
> Regarding the fs name, I propose to use per default the same driver name
> as defined in fs_names (and not have the fstype parameter in uci).
> I would still keep the fstype in uci as optional parameter in case an
> alternative driver has to be used (e.g. paragon for ntfs).
> 

Hi,

> What do you think about it?

make it optional in that case please. i would prefer to not list ext4
int he ext4 section for it to work. if the fs is not explicitly defined
use the sane default

	John


> 
> Olivier
> 
> 
> On Mon, Jun 13, 2016 at 7:03 AM, John Crispin <john at phrozen.org
> <mailto:john at phrozen.org>> wrote:
> 
>     Hi,
> 
>     comment inline.
> 
>     On 10/06/2016 11:18, olivier.hardouin at gmail.com
>     <mailto:olivier.hardouin at gmail.com> wrote:
>     > Move (previously hardcoded) mount option to UCI to allow different
>     configuration
>     > like charset (utf-8 or iso) and filesystem driver (if alternative
>     ones are used).
>     > The fs names are changed in lowercase to comply with UCI general
>     naming.
>     >
>     > Signed-off-by: Olivier Hardouin <olivier.hardouin at gmail.com
>     <mailto:olivier.hardouin at gmail.com>>
>     > ---
>     >  mount.c | 69
>     ++++++++++++++++++++++++++---------------------------------------
>     >  1 file changed, 28 insertions(+), 41 deletions(-)
>     >
>     > diff --git a/mount.c b/mount.c
>     > index 8892040..c8f7ea6 100644
>     > --- a/mount.c
>     > +++ b/mount.c
>     > @@ -51,15 +51,15 @@ struct mount {
>     >  char *fs_names[] = {
>     >       "",
>     >       "",
>     > -     "MBR",
>     > -     "EXT2",
>     > -     "EXT3",
>     > -     "FAT",
>     > -     "HFSPLUS",
>     > +     "mbr",
>     > +     "ext2",
>     > +     "ext3",
>     > +     "fat",
>     > +     "hfsplus",
>     >       "",
>     > -     "NTFS",
>     > +     "ntfs",
>     >       "",
>     > -     "EXT4"
>     > +     "ext4"
>     >  };
>     >
>     >  #define MAX_MOUNTED          32
>     > @@ -227,42 +227,29 @@ int mount_new(char *path, char *dev)
>     >       pid = autofs_safe_fork();
>     >       if(!pid)
>     >       {
>     > -             if(mount->fs == EXFAT)
>     > +             if(mount->fs > MBR && mount->fs <= EXT4)
>     >               {
>     > -                     log_printf("mount -t exfat -o
>     rw,uid=1000,gid=1000 /dev/%s %s", mount->dev, tmp);
>     > -                     ret = system_printf("mount -t exfat -o
>     rw,uid=1000,gid=1000 /dev/%s %s", mount->dev, tmp);
>     > -             }
>     > -             if(mount->fs == FAT)
>     > -             {
>     > -                     log_printf("mount -t vfat -o
>     rw,uid=1000,gid=1000 /dev/%s %s", mount->dev, tmp);
>     > -                     ret = system_printf("mount -t vfat -o
>     rw,uid=1000,gid=1000 /dev/%s %s", mount->dev, tmp);
>     > -             }
>     > -             if(mount->fs == EXT4)
>     > -             {
>     > -                     log_printf("mount -t ext4 -o rw,defaults
>     /dev/%s %s", mount->dev, tmp);
>     > -                     ret = system_printf("mount -t ext4 -o
>     rw,defaults /dev/%s %s", mount->dev, tmp);
>     > -             }
>     > -             if(mount->fs == EXT3)
>     > -             {
>     > -                     log_printf("mount -t ext3 -o rw,defaults
>     /dev/%s %s", mount->dev, tmp);
>     > -                     ret = system_printf("mount -t ext3 -o
>     rw,defaults /dev/%s %s", mount->dev, tmp);
>     > -             }
>     > -             if(mount->fs == EXT2)
>     > -             {
>     > -                     log_printf("mount -t ext2 -o rw,defaults
>     /dev/%s %s", mount->dev, tmp);
>     > -                     ret = system_printf("mount -t ext2 -o
>     rw,defaults /dev/%s %s", mount->dev, tmp);
>     > -             }
>     > -             if(mount->fs == HFSPLUS)
>     > -             {
>     > -                     log_printf("mount -t hfsplus -o
>     rw,defaults,uid=1000,gid=1000 /dev/%s %s", mount->dev, tmp);
>     > -                     ret = system_printf("mount -t hfsplus -o
>     rw,defaults,uid=1000,gid=1000 /dev/%s %s", mount->dev, tmp);
>     > -             }
>     > -             if(mount->fs == NTFS)
>     > -             {
>     > -                     log_printf("ntfs-3g /dev/%s %s -o force",
>     mount->dev, tmp);
>     > -                     ret = system_printf("ntfs-3g /dev/%s %s -o
>     force", mount->dev, tmp);
>     > +                     struct uci_context *ctx;
>     > +                     char *options, *fstype;
>     > +                     ctx = ucix_init("mountd");
>     > +                     options = ucix_get_option(ctx, "mountd",
>     fs_names[mount->fs], "options");
>     > +                     fstype = ucix_get_option(ctx, "mountd",
>     fs_names[mount->fs], "fstype");
> 
>     this might be NULL but is used below without checking for NULL. i am not
>     sure these even needs to be loaded from uci as it is the same as
>     fs_names[mount->fs].
> 
>     could you look into this and then resend the patch ?
> 
>             John
> 
>     > +                     ucix_cleanup(ctx);
>     > +                     if(!fstype)
>     > +                     {
>     > +                             log_printf("mounting /dev/%s failed,
>     expecting 'fstype' uci parameter (kernel driver) for %s",
>     mount->dev, fs_names[mount->fs]);
>     > +                     } else {
>     > +                             if(!options)
>     > +                             {
>     > +                                     log_printf("mount -t %s
>     /dev/%s %s", fstype, mount->dev, tmp);
>     > +                                     ret = system_printf("mount
>     -t %s /dev/%s %s", fstype, mount->dev, tmp);
>     > +                             } else {
>     > +                                     log_printf("mount -t %s -o
>     %s /dev/%s %s", fstype, options, mount->dev, tmp);
>     > +                                     ret = system_printf("mount
>     -t %s -o %s /dev/%s %s", fstype, options, mount->dev, tmp);
>     > +                             }
>     > +                     }
>     > +                     exit(WEXITSTATUS(ret));
>     >               }
>     > -             exit(WEXITSTATUS(ret));
>     >       }
>     >       pid = waitpid(pid, &ret, 0);
>     >       ret = WEXITSTATUS(ret);
>     >
> 
> 


From jo at mein.io  Mon Jun 13 02:17:46 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Mon, 13 Jun 2016 11:17:46 +0200
Subject: [LEDE-DEV] lede integration issues remaining from the detrius
 of cerowrt
In-Reply-To: <CAJOqq5TB4qki1iWHZd71kzXYoA=A3+4BeycoNPKqRXFWZ6bMZQ@mail.gmail.com>
References: <CAA93jw7=bHNXJqmjWmg3CHHH-biua17wK4AHfn_wB0wPWs=EqQ@mail.gmail.com>
 <CAJOqq5TB4qki1iWHZd71kzXYoA=A3+4BeycoNPKqRXFWZ6bMZQ@mail.gmail.com>
Message-ID: <f6898485-e1d4-ec35-4563-4591512d2d84@mein.io>

Hi,

no need to overreact :)  I think parts of the topics are about the
general availability of choices and not necessarily making them the default.

Imho most parts of CeroWrt can be replicated by using the ImageBuilder
to repack images with various components swapped (e.g. lighttpd vs.
uhttpd) and kernel features such as Cake and Codel are integrated and
default nowadays and other stuff is available in the form of packages.

For the remaining things that require compile time changes we need to
take a deeper look and figure out if they can be implemented directly in
LEDE or if it is feasible to simply drop them.

~ Jo


From john at phrozen.org  Mon Jun 13 04:55:49 2016
From: john at phrozen.org (John Crispin)
Date: Mon, 13 Jun 2016 13:55:49 +0200
Subject: [LEDE-DEV] [PATCH] base-files: seed /dev/urandom
In-Reply-To: <CAOdf3gq8Yx6M1nUZrOBog-2ziaqP-F1qpapFf1=32XtuVaDYWg@mail.gmail.com>
References: <1465627075-13683-1-git-send-email-champetier.etienne@gmail.com>
 <d16a674b-f1f0-67cb-ec02-c40804ed5a83@nbd.name>
 <CAOdf3gq8Yx6M1nUZrOBog-2ziaqP-F1qpapFf1=32XtuVaDYWg@mail.gmail.com>
Message-ID: <eb1f3f1b-3d2f-f406-9dec-4a45c6c0ea00@phrozen.org>



On 13/06/2016 00:56, Etienne Champetier wrote:
> Hi Felix,
> 
> 2016-06-12 12:45 GMT+02:00 Felix Fietkau <nbd at nbd.name>:
>> On 2016-06-11 08:37, Etienne CHAMPETIER wrote:
>>> This commit:
>>> 1) seed /dev/urandom with a saved seed as early as possible
>>>    (using /lib/preinit/81_urandom_seed)
>>> 2) save a new seed using getrandom() so we are sure /dev/urandom
>>>    pool is initialized (using /etc/init.d/urandom_seed)
>>>
>>> seed size is 512 bytes (ie /proc/sys/kernel/random/poolsize / 8)
>>> it's the same size as in ubuntu 14.04 and all systemd systems
>>>
>>> seed file is /etc/urandom.seed (need a writable path)
>>>
>>> seeding /dev/urandom doesn't change entropy estimation, so we still have
>>> "random: ubus urandom read with 4 bits of entropy available"
>>> messages in the logs, but we can now ignore them
>>>
>>> We could also add an urandom.seed at build time to improve first boot
>> I'm not sure writing to flash on every single boot on every device is a
>> good default behavior.
>>
> 
> Just saw your comment, it endend up in spam ...
> 
> Reusing the same seed multiple time is not really recommended, as it
> means all boot with same seed are in the same state.
> What would be an acceptable behaviour for you?
> I could wait for ntp and then check if seed is older than X, but
> that's way less robust.
> 
> BTW, we are already writing at every boot for dnsmasq/dnssec (/etc/dnsmasq.time)
>

lets add a system.system.write_state_to_flash_on_boot=0/1 uci option and
lock this and the dnssec time stuff with it and default it to 0

ideas what a short/descriptive name for the option would be ?

	John


> Etienne
> 
>> - Felix
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 


From ulrich.weber at riverbed.com  Mon Jun 13 06:21:47 2016
From: ulrich.weber at riverbed.com (Ulrich Weber)
Date: Mon, 13 Jun 2016 15:21:47 +0200
Subject: [LEDE-DEV] [PATCH] dnsmasq: write atomic config file
Message-ID: <20160613132147.GA10942@gir>

multiple invocation of dnsmasq script (e.g. by procd and hotplugd)
might cause procd to restart dnsmasq with an incomplete config file.
Config file generation might take quite a long time on larger configs
due ubus calls for each listening interface...

Signed-off-by: Ulrich Weber <ulrich.weber at riverbed.com>
---
 package/network/services/dnsmasq/files/dnsmasq.init | 18 ++++++++++--------
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/package/network/services/dnsmasq/files/dnsmasq.init b/package/network/services/dnsmasq/files/dnsmasq.init
index 1a9903e..6967049 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -13,6 +13,7 @@ ADD_LOCAL_DOMAIN=1
 ADD_LOCAL_HOSTNAME=1
 
 CONFIGFILE="/var/etc/dnsmasq.conf"
+CONFIGFILE_TMP="/var/etc/dnsmasq.conf.$$"
 HOSTFILE="/tmp/hosts/dhcp"
 TRUSTANCHORSFILE="/usr/share/dnsmasq/trust-anchors.conf"
 TIMESTAMPFILE="/etc/dnsmasq.time"
@@ -20,7 +21,7 @@ TIMESTAMPFILE="/etc/dnsmasq.time"
 xappend() {
 	local value="$1"
 
-	echo "${value#--}" >> $CONFIGFILE
+	echo "${value#--}" >> $CONFIGFILE_TMP
 }
 
 hex_to_hostid() {
@@ -249,7 +250,7 @@ dnsmasq() {
 	xappend "--user=dnsmasq"
 	xappend "--group=dnsmasq"
 
-	echo >> $CONFIGFILE
+	echo >> $CONFIGFILE_TMP
 
 	config_get_bool enable_tftp "$cfg" enable_tftp 0
 	[ "$enable_tftp" -gt 0 ] && {
@@ -632,7 +633,7 @@ start_service() {
 		chown dnsmasq.dnsmasq "$TIMESTAMPFILE"
 	fi
 
-	echo "# auto-generated config file from /etc/config/dhcp" > $CONFIGFILE
+	echo "# auto-generated config file from /etc/config/dhcp" > $CONFIGFILE_TMP
 	echo "# auto-generated config file from /etc/config/dhcp" > $HOSTFILE
 
 	# if we did this last, we could override auto-generated config
@@ -645,7 +646,7 @@ start_service() {
 	args=""
 	config_foreach dnsmasq dnsmasq
 	config_foreach dhcp_host_add host
-	echo >> $CONFIGFILE
+	echo >> $CONFIGFILE_TMP
 	config_foreach dhcp_boot_add boot
 	config_foreach dhcp_mac_add mac
 	config_foreach dhcp_tag_add tag
@@ -679,19 +680,20 @@ start_service() {
 		}
 	}
 
-	echo >> $CONFIGFILE
+	echo >> $CONFIGFILE_TMP
 	config_foreach dhcp_srv_add srvhost
 	config_foreach dhcp_mx_add mxhost
-	echo >> $CONFIGFILE
+	echo >> $CONFIGFILE_TMP
 
 	config_get odhcpd_is_active odhcpd maindhcp
 	if [ "$odhcpd_is_active" != "1" ]; then
 		config_foreach dhcp_add dhcp
 	fi
 
-	echo >> $CONFIGFILE
+	echo >> $CONFIGFILE_TMP
 	config_foreach dhcp_cname_add cname
-	echo >> $CONFIGFILE
+	echo >> $CONFIGFILE_TMP
+	mv -f $CONFIGFILE_TMP $CONFIGFILE
 
 	rm -f /tmp/resolv.conf
 	[ $ADD_LOCAL_DOMAIN -eq 1 ] && [ -n "$DOMAIN" ] && {
-- 
1.9.1



From jo at mein.io  Mon Jun 13 06:40:25 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Mon, 13 Jun 2016 15:40:25 +0200
Subject: [LEDE-DEV] [PATCH] dnsmasq: write atomic config file
In-Reply-To: <20160613132147.GA10942@gir>
References: <20160613132147.GA10942@gir>
Message-ID: <b62d4f0e-bc5c-64fc-1e8b-fcf7aad91f92@mein.io>

Hi Ulrich,

wouldn't some protection with "flock" or similar be better in this case
in order to serialize config generation and restart tasks?

~ Jo




From ansuelsmth at gmail.com  Mon Jun 13 03:06:40 2016
From: ansuelsmth at gmail.com (Ansuel Smith)
Date: Mon, 13 Jun 2016 12:06:40 +0200
Subject: [LEDE-DEV] Fwd: Bug found
In-Reply-To: <CA+_ehUwxS2r1uYQziD=xoEnm6bo6bwsK1xT0k7O1jzn2Sx2VVw@mail.gmail.com>
References: <CA+_ehUxxBjdby7dW2t2tzcf1_KywDGZa0reFMoQM-f7Wrvhaxw@mail.gmail.com>
 <CA+_ehUwxS2r1uYQziD=xoEnm6bo6bwsK1xT0k7O1jzn2Sx2VVw@mail.gmail.com>
Message-ID: <CA+_ehUydzedzkACeLhdU_+ux_f-mBsR14WqiDbWCjyURcq5ojw@mail.gmail.com>

I have an error with ddsn app for luci 200850 WARN : Busybox compiled
with musl - nslookup - no support to set/use DNS Server ? TERMINATE
And there a re lots of problems with the sqm scripts? everything
except simplets give me kernel panic and spam me the log message? the
router continue to function normally device: wdr3600 LEDE Reboot r604


From nbd at nbd.name  Mon Jun 13 06:50:13 2016
From: nbd at nbd.name (Felix Fietkau)
Date: Mon, 13 Jun 2016 15:50:13 +0200
Subject: [LEDE-DEV] [PATCH] dnsmasq: write atomic config file
In-Reply-To: <b62d4f0e-bc5c-64fc-1e8b-fcf7aad91f92@mein.io>
References: <20160613132147.GA10942@gir>
 <b62d4f0e-bc5c-64fc-1e8b-fcf7aad91f92@mein.io>
Message-ID: <86a50c73-2021-555f-c6ea-599f1fa0ede0@nbd.name>

On 2016-06-13 15:40, Jo-Philipp Wich wrote:
> Hi Ulrich,
> 
> wouldn't some protection with "flock" or similar be better in this case
> in order to serialize config generation and restart tasks?
I don't think we should be using flock. We should find a way to have
procd serialize init script calls properly.

As far as I know, dnsmasq can also re-read its configuration file, so
regardless of the issue of locking init scripts against concurrent
calls, this change is useful.

- Felix


From jo at mein.io  Mon Jun 13 06:53:19 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Mon, 13 Jun 2016 15:53:19 +0200
Subject: [LEDE-DEV] [PATCH] dnsmasq: write atomic config file
In-Reply-To: <86a50c73-2021-555f-c6ea-599f1fa0ede0@nbd.name>
References: <20160613132147.GA10942@gir>
 <b62d4f0e-bc5c-64fc-1e8b-fcf7aad91f92@mein.io>
 <86a50c73-2021-555f-c6ea-599f1fa0ede0@nbd.name>
Message-ID: <9567a424-eebd-d348-f74f-b36754b22064@mein.io>

Hi,

yes, it is certainly better than starting dnsmasq with an incomplete config.

~ Jo


From kevin at darbyshire-bryant.me.uk  Mon Jun 13 07:20:24 2016
From: kevin at darbyshire-bryant.me.uk (Kevin Darbyshire-Bryant)
Date: Mon, 13 Jun 2016 15:20:24 +0100
Subject: [LEDE-DEV] [PATCH] dnsmasq: write atomic config file
In-Reply-To: <86a50c73-2021-555f-c6ea-599f1fa0ede0@nbd.name>
References: <20160613132147.GA10942@gir>
 <b62d4f0e-bc5c-64fc-1e8b-fcf7aad91f92@mein.io>
 <86a50c73-2021-555f-c6ea-599f1fa0ede0@nbd.name>
Message-ID: <575EC128.6010909@darbyshire-bryant.me.uk>



On 13/06/16 14:50, Felix Fietkau wrote:
> On 2016-06-13 15:40, Jo-Philipp Wich wrote:
>> Hi Ulrich,
>>
>> wouldn't some protection with "flock" or similar be better in this case
>> in order to serialize config generation and restart tasks?
> I don't think we should be using flock. We should find a way to have
> procd serialize init script calls properly.
>
> As far as I know, dnsmasq can also re-read its configuration file, so
> regardless of the issue of locking init scripts against concurrent
> calls, this change is useful.
dnsmasq never re-reads the config file.  It may re-read: 
/etc/resolv.conf, dhcp-hostsfile, dhcp-optsfile, dhcp-hostsdir, 
/etc/ethers, --servers-file, usually in response to SIGHUP though 
/etc/resolv.conf may be polled.   From the manpage:

"When it receives a SIGHUP, *dnsmasq * clears its cache and then 
re-loads //etc/hosts/ and //etc/ethers / and any file given by 
--dhcp-hostsfile, --dhcp-hostsdir, --dhcp-optsfile, --dhcp-optsdir, 
--addn-hosts or --hostsdir. The dhcp lease change script is called for 
all existing DHCP leases. If *--no-poll* is set SIGHUP also re-reads 
//etc/resolv.conf./ SIGHUP does NOT re-read the configuration file."

Kevin

>
> - Felix
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev



From koen.vandeputte at ncentric.com  Mon Jun 13 09:12:39 2016
From: koen.vandeputte at ncentric.com (Koen Vandeputte)
Date: Mon, 13 Jun 2016 18:12:39 +0200
Subject: [LEDE-DEV] Bug - spinlock loop in cns3xxx_eth.c
Message-ID: <575EDB77.4040400@ncentric.com>

Hi All,

There seems to be a bug in the function eth_poll() in this driver

When the RX ring gets full once, the re-schedule is called forever, even 
when the ring is empty afterwards.


     if (!received) {
         napi_complete(napi);
         enable_irq(sw->rx_irq);
         budget = 0;

         /* if rx descriptors are full schedule another poll */
         if (rx_ring->desc[(i-1) & (RX_DESCS-1)].cown)
         {
             eth_schedule_poll(sw);    <----  Gets called on each 
function entry
         }
     }


This causes SoftIRQ to fully load a core forever.


I didn't fix it yet, but should I be the first, i'll supply a patch ..


Used hardware:
- Gateworks Laguna GW2388-4

Seen on branches:
- Lede master (4.4.13 kernel)
- Gateworks 16.02 (4.4.0 kernel)


Reproducing (100%):
- Iperf to an external server (Issue not seen - cpu is fast enough to 
avoid the RX ring from reaching 'Full')
- Route an iperf stream from a second device via wlan through eth to an 
external server (RX ring gets full after a minute .. spinlock loop 
forever occurs)


Kind Regards,

Koen Vandeputte
nCentric Europe


From tharvey at gateworks.com  Mon Jun 13 11:17:48 2016
From: tharvey at gateworks.com (Tim Harvey)
Date: Mon, 13 Jun 2016 11:17:48 -0700
Subject: [LEDE-DEV] Bug - spinlock loop in cns3xxx_eth.c
In-Reply-To: <575EDB77.4040400@ncentric.com>
References: <575EDB77.4040400@ncentric.com>
Message-ID: <CAJ+vNU0JxQJJZxjW+VHWDA4O-ujBh0T3ydu4GdNYtxumAFNW0A@mail.gmail.com>

On Mon, Jun 13, 2016 at 9:12 AM, Koen Vandeputte
<koen.vandeputte at ncentric.com> wrote:
> Hi All,
>
> There seems to be a bug in the function eth_poll() in this driver
>
> When the RX ring gets full once, the re-schedule is called forever, even
> when the ring is empty afterwards.
>
>
>     if (!received) {
>         napi_complete(napi);
>         enable_irq(sw->rx_irq);
>         budget = 0;
>
>         /* if rx descriptors are full schedule another poll */
>         if (rx_ring->desc[(i-1) & (RX_DESCS-1)].cown)
>         {
>             eth_schedule_poll(sw);    <----  Gets called on each function
> entry
>         }
>     }
>
>
> This causes SoftIRQ to fully load a core forever.
>
>
> I didn't fix it yet, but should I be the first, i'll supply a patch ..
>

Koen,

We have seen this before, but admittedly don't understand why we enter
into the same condition on each subsequent call to eth_poll(). The
check is to catch the condition described as irq rot [1] and is to
catch the case where after processing the full budget, we are
immediately full again (a situation which is easily re-producible with
a flood-ping). If this occurs we will no longer get an rx interrupt
(because the descriptors are full) and our napi function will never
get called again (unless transmitting packets).

What is your proposed patch?

Tim

1 .http://www.linuxfoundation.org/collaborate/workgroups/networking/napi#IRQ_race_a.k.a_rotting_packet


From kevin at darbyshire-bryant.me.uk  Mon Jun 13 12:34:08 2016
From: kevin at darbyshire-bryant.me.uk (Kevin Darbyshire-Bryant)
Date: Mon, 13 Jun 2016 20:34:08 +0100
Subject: [LEDE-DEV] [PATCH] base-files: seed /dev/urandom
In-Reply-To: <eb1f3f1b-3d2f-f406-9dec-4a45c6c0ea00@phrozen.org>
References: <1465627075-13683-1-git-send-email-champetier.etienne@gmail.com>
 <d16a674b-f1f0-67cb-ec02-c40804ed5a83@nbd.name>
 <CAOdf3gq8Yx6M1nUZrOBog-2ziaqP-F1qpapFf1=32XtuVaDYWg@mail.gmail.com>
 <eb1f3f1b-3d2f-f406-9dec-4a45c6c0ea00@phrozen.org>
Message-ID: <575F0AB0.7020303@darbyshire-bryant.me.uk>



On 13/06/16 12:55, John Crispin wrote:
>
> On 13/06/2016 00:56, Etienne Champetier wrote:
>> Hi Felix,
>>
>> 2016-06-12 12:45 GMT+02:00 Felix Fietkau <nbd at nbd.name>:
>>> On 2016-06-11 08:37, Etienne CHAMPETIER wrote:
>>>> This commit:
>>>> 1) seed /dev/urandom with a saved seed as early as possible
>>>>     (using /lib/preinit/81_urandom_seed)
>>>> 2) save a new seed using getrandom() so we are sure /dev/urandom
>>>>     pool is initialized (using /etc/init.d/urandom_seed)
>>>>
>>>> seed size is 512 bytes (ie /proc/sys/kernel/random/poolsize / 8)
>>>> it's the same size as in ubuntu 14.04 and all systemd systems
>>>>
>>>> seed file is /etc/urandom.seed (need a writable path)
>>>>
>>>> seeding /dev/urandom doesn't change entropy estimation, so we still have
>>>> "random: ubus urandom read with 4 bits of entropy available"
>>>> messages in the logs, but we can now ignore them
>>>>
>>>> We could also add an urandom.seed at build time to improve first boot
>>> I'm not sure writing to flash on every single boot on every device is a
>>> good default behavior.
>>>
>> Just saw your comment, it endend up in spam ...
>>
>> Reusing the same seed multiple time is not really recommended, as it
>> means all boot with same seed are in the same state.
>> What would be an acceptable behaviour for you?
>> I could wait for ntp and then check if seed is older than X, but
>> that's way less robust.
>>
>> BTW, we are already writing at every boot for dnsmasq/dnssec (/etc/dnsmasq.time)
>>
Potentially writing at every dnsmasq TERM as well, since it prefers to 
maintain an up-to-date 'last known good timestamp' for comparison purposes.
> lets add a system.system.write_state_to_flash_on_boot=0/1 uci option and
> lock this and the dnssec time stuff with it and default it to 0
>
> ideas what a short/descriptive name for the option would be ?
>
> 	John
I've a feeling that a default of '0' for dnsmasq would break the 'last 
known good' time logic.  The algorithm (simplistically) is "if the 
current system time is BEFORE the timestamp file date, then the clock 
hasn't been set so don't check DNSSEC signature timestamps thus allowing 
name resolution to complete"  Once the clock goes beyond 'timestamp' 
then time is considered valid, DNSSEC signature timestamps are checked, 
also the timestamp file mtime is updated.

The above is straightforward until sysfixtime appears on the scene, 
which by default and in an attempt to be helpful (?) searches through 
/etc and sets system time to the newest timestamped file...EXCLUDING 
dnsmasq.time for that would be self defeating!  I don't think 
/etc/urandom.seed needs to be excluded from sysfixtime as the file isn't 
updated on shutdown.

I'm beginning to think that the whole /etc/dnsmasq.time thing whilst a 
'quick & dirty' workaround to the whole chicken'n'egg 'ntpd needs name 
resolution to work irrespective of time being valid' problem was a 
reasonable idea, a solution that relies on ntp raising a 'time is valid' 
flag would be better.  The flag could go in /tmp.

I'm really NOT a fan of using the SIGHUP signalling to dnsmasq that time 
is now okay - there's too much to go wrong in terms of signalling in the 
event of dnsmasq restarting for whatever reason. Much better that 
dnsmasq is started without signature timestamp checking, the SIGHUP code 
patched out and ntpd sets a 'time now set' flag and hard bounces 
dnsmasq.  dnsmasq's startup scripts can look for the flag in /tmp and if 
found start in full dnssec checking mode.  The myriad versions of ntpd 
would need investigation as to their own 'time is ok' signalling abilities.

Apologies, this has gone a bit off topic but I think relevant.

Kevin


From david at lang.hm  Mon Jun 13 12:48:08 2016
From: david at lang.hm (David Lang)
Date: Mon, 13 Jun 2016 12:48:08 -0700 (PDT)
Subject: [LEDE-DEV] [PATCH] base-files: seed /dev/urandom
In-Reply-To: <575F0AB0.7020303@darbyshire-bryant.me.uk>
References: <1465627075-13683-1-git-send-email-champetier.etienne@gmail.com>
 <d16a674b-f1f0-67cb-ec02-c40804ed5a83@nbd.name>
 <CAOdf3gq8Yx6M1nUZrOBog-2ziaqP-F1qpapFf1=32XtuVaDYWg@mail.gmail.com>
 <eb1f3f1b-3d2f-f406-9dec-4a45c6c0ea00@phrozen.org>
 <575F0AB0.7020303@darbyshire-bryant.me.uk>
Message-ID: <alpine.DEB.2.02.1606131244060.1801@nftneq.ynat.uz>


Just a FYI in case you didn't see it, Ted Ts'o posted a 7-patch cluster for 
changing urandom that he plans to get into the next kernel

Subject: PATCH-v4 0/7] random: replace urandom pool with a CRNG

https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1166186.html

David Lang


From champetier.etienne at gmail.com  Mon Jun 13 13:10:53 2016
From: champetier.etienne at gmail.com (Etienne Champetier)
Date: Mon, 13 Jun 2016 22:10:53 +0200
Subject: [LEDE-DEV] [PATCH] base-files: seed /dev/urandom
In-Reply-To: <eb1f3f1b-3d2f-f406-9dec-4a45c6c0ea00@phrozen.org>
References: <1465627075-13683-1-git-send-email-champetier.etienne@gmail.com>
 <d16a674b-f1f0-67cb-ec02-c40804ed5a83@nbd.name>
 <CAOdf3gq8Yx6M1nUZrOBog-2ziaqP-F1qpapFf1=32XtuVaDYWg@mail.gmail.com>
 <eb1f3f1b-3d2f-f406-9dec-4a45c6c0ea00@phrozen.org>
Message-ID: <CAOdf3grPLYAgyqzA8Er-Jw+jEjJxZYJkTEXrvJDLiD6rsYtpnw@mail.gmail.com>

Hi John, Felix,

2016-06-13 13:55 GMT+02:00 John Crispin <john at phrozen.org>:
>
>
> On 13/06/2016 00:56, Etienne Champetier wrote:
>> Hi Felix,
>>
>> 2016-06-12 12:45 GMT+02:00 Felix Fietkau <nbd at nbd.name>:
>>> On 2016-06-11 08:37, Etienne CHAMPETIER wrote:
>>>> This commit:
>>>> 1) seed /dev/urandom with a saved seed as early as possible
>>>>    (using /lib/preinit/81_urandom_seed)
>>>> 2) save a new seed using getrandom() so we are sure /dev/urandom
>>>>    pool is initialized (using /etc/init.d/urandom_seed)
>>>>
>>>> seed size is 512 bytes (ie /proc/sys/kernel/random/poolsize / 8)
>>>> it's the same size as in ubuntu 14.04 and all systemd systems
>>>>
>>>> seed file is /etc/urandom.seed (need a writable path)
>>>>
>>>> seeding /dev/urandom doesn't change entropy estimation, so we still have
>>>> "random: ubus urandom read with 4 bits of entropy available"
>>>> messages in the logs, but we can now ignore them
>>>>
>>>> We could also add an urandom.seed at build time to improve first boot
>>> I'm not sure writing to flash on every single boot on every device is a
>>> good default behavior.
>>>
>>
>> Just saw your comment, it endend up in spam ...
>>
>> Reusing the same seed multiple time is not really recommended, as it
>> means all boot with same seed are in the same state.
>> What would be an acceptable behaviour for you?
>> I could wait for ntp and then check if seed is older than X, but
>> that's way less robust.
>>
>> BTW, we are already writing at every boot for dnsmasq/dnssec (/etc/dnsmasq.time)
>>
>
> lets add a system.system.write_state_to_flash_on_boot=0/1 uci option and
> lock this and the dnssec time stuff with it and default it to 0

Security can't be opt in !
When you see "random: ubus urandom read with 4 bits of entropy
available" let's hope it's not security sensitive, because 2^4 will
not take a lot of time to bruteforce...

Before we try to minimize writes, how much writes are we talking about?
my openwrt routers have multiple months of uptime, and even if we get
down to 1 week, that gets us to 53 writes a year.
How much writes can a flash handle these days?

Etienne

>
> ideas what a short/descriptive name for the option would be ?
>
>         John
>
>
>> Etienne
>>
>>> - Felix
>>
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>


From yszhou4tech at gmail.com  Mon Jun 13 20:13:42 2016
From: yszhou4tech at gmail.com (Yousong Zhou)
Date: Tue, 14 Jun 2016 11:13:42 +0800
Subject: [LEDE-DEV] [PATCH 2/2] strace: add option for enabling stack
 trace support
In-Reply-To: <CAECwjAi-YF4dj0o7QGvpUKJhkrF3vgY_7xdMLPbC7R1ueUfEdA@mail.gmail.com>
References: <1465437864-19567-1-git-send-email-yszhou4tech@gmail.com>
 <1465437864-19567-2-git-send-email-yszhou4tech@gmail.com>
 <CADYCxoOi6RViQzyHGoLipB-PKc+dY9FpvKexxkKMhoPbO6DX4Q@mail.gmail.com>
 <CAECwjAi-YF4dj0o7QGvpUKJhkrF3vgY_7xdMLPbC7R1ueUfEdA@mail.gmail.com>
Message-ID: <CAECwjAjy+EaMcUTT4zDS6aG6aVmRVHSwGvHmgz0S0BeCd0dd2A@mail.gmail.com>

On 10 June 2016 at 21:43, Yousong Zhou <yszhou4tech at gmail.com> wrote:
> On 10 June 2016 at 20:52, Sergey Zakharchenko <doublef.mobile at gmail.com> wrote:
>> Hello Yousong,
>>
>> The libunwind-enabled strace builds fine but I'm getting a "Can't
>> initiate libunwind: Invalid argument" error when trying to use it
>> (this is on an Atheros, i.e. MIPS chip). This is just a report, I'm
>> not urging you to anything...
>>
>
> Yeah, the stack trace dump feature seems really fragile.  I noticed
> that once on qemu/malta, then did "make clean" and rebuilt, the
> 'invalid argument' error disappeared later and along with it the -k
> option does not have said effect at all.  But it works partly on
> qemu/x86_64 though at the moment the traces cannot go past libc.
>
>                 yousong

I tried yesterday building a x86_64 firmware with glibc and strace -k
works quite well there.  However the situation of the glibc-mips
combination is the same as with musl-mips.

My current guess is that libunwind may need some patching to work with
musl-libc.

Regards,
                yousong


From john at klam.ca  Mon Jun 13 22:08:59 2016
From: john at klam.ca (John Allen)
Date: Tue, 14 Jun 2016 01:08:59 -0400
Subject: [LEDE-DEV] BUG - SQM will not install
Message-ID: <6c546d00-bd40-c635-635e-c4c895520aa9@klam.ca>

Name: Lede-ar7xx-wndr3700v2

device: Netgear wndr3700v2

Error when trying to install sqm using Luci-app-sqm:

Installing luci-app-sqm (1.0.7-1) to root...
Downloadinghttp://downloads.lede-project.org/snapshots/packages/mips_34kc/packages/luci-app-sqm_1.0.7-1_all.ipk.

Collected errors:
  * satisfy_dependencies_for: Cannot satisfy the following dependencies for luci-app-sqm:
  * 	kernel (= 4.4.13-1-a83a26db62b1bebd721f9af8b3c0f461)
  * 	kernel (= 4.4.13-1-a83a26db62b1bebd721f9af8b3c0f461)
  * 	kernel (= 4.4.13-1-a83a26db62b1bebd721f9af8b3c0f461)
  * 	kernel (= 4.4.13-1-a83a26db62b1bebd721f9af8b3c0f461)
  * 	kernel (= 4.4.13-1-a83a26db62b1bebd721f9af8b3c0f461)
  *
  * opkg_install_cmd: Cannot install package luci-app-sqm.
  




From john at phrozen.org  Mon Jun 13 23:55:54 2016
From: john at phrozen.org (John Crispin)
Date: Tue, 14 Jun 2016 08:55:54 +0200
Subject: [LEDE-DEV] mqmaker witi board - battery
Message-ID: <79b80149-c569-3d1c-5e8b-9657e4a5491e@phrozen.org>

Hi,

i have a mqmaker witi board on my desk and wanted to use it to very the
RTC support and add functionality to procd that it will apply hw rtc
time to the system after the early boot state.

unfortunately there is no battery inserted into the slot. anyone know
what kind of battery cell is needed ? is this a CR1130 ?

	John


From nbd at nbd.name  Tue Jun 14 00:08:42 2016
From: nbd at nbd.name (Felix Fietkau)
Date: Tue, 14 Jun 2016 09:08:42 +0200
Subject: [LEDE-DEV] [PATCH] base-files: seed /dev/urandom
In-Reply-To: <CAOdf3grPLYAgyqzA8Er-Jw+jEjJxZYJkTEXrvJDLiD6rsYtpnw@mail.gmail.com>
References: <1465627075-13683-1-git-send-email-champetier.etienne@gmail.com>
 <d16a674b-f1f0-67cb-ec02-c40804ed5a83@nbd.name>
 <CAOdf3gq8Yx6M1nUZrOBog-2ziaqP-F1qpapFf1=32XtuVaDYWg@mail.gmail.com>
 <eb1f3f1b-3d2f-f406-9dec-4a45c6c0ea00@phrozen.org>
 <CAOdf3grPLYAgyqzA8Er-Jw+jEjJxZYJkTEXrvJDLiD6rsYtpnw@mail.gmail.com>
Message-ID: <3e6b2474-7096-fda5-db0a-6351d2f6be9c@nbd.name>

On 2016-06-13 22:10, Etienne Champetier wrote:
> Hi John, Felix,
> 
> 2016-06-13 13:55 GMT+02:00 John Crispin <john at phrozen.org>:
>>
>>
>> On 13/06/2016 00:56, Etienne Champetier wrote:
>>> Hi Felix,
>>>
>>> 2016-06-12 12:45 GMT+02:00 Felix Fietkau <nbd at nbd.name>:
>>>> On 2016-06-11 08:37, Etienne CHAMPETIER wrote:
>>>>> This commit:
>>>>> 1) seed /dev/urandom with a saved seed as early as possible
>>>>>    (using /lib/preinit/81_urandom_seed)
>>>>> 2) save a new seed using getrandom() so we are sure /dev/urandom
>>>>>    pool is initialized (using /etc/init.d/urandom_seed)
>>>>>
>>>>> seed size is 512 bytes (ie /proc/sys/kernel/random/poolsize / 8)
>>>>> it's the same size as in ubuntu 14.04 and all systemd systems
>>>>>
>>>>> seed file is /etc/urandom.seed (need a writable path)
>>>>>
>>>>> seeding /dev/urandom doesn't change entropy estimation, so we still have
>>>>> "random: ubus urandom read with 4 bits of entropy available"
>>>>> messages in the logs, but we can now ignore them
>>>>>
>>>>> We could also add an urandom.seed at build time to improve first boot
>>>> I'm not sure writing to flash on every single boot on every device is a
>>>> good default behavior.
>>>>
>>>
>>> Just saw your comment, it endend up in spam ...
>>>
>>> Reusing the same seed multiple time is not really recommended, as it
>>> means all boot with same seed are in the same state.
>>> What would be an acceptable behaviour for you?
>>> I could wait for ntp and then check if seed is older than X, but
>>> that's way less robust.
>>>
>>> BTW, we are already writing at every boot for dnsmasq/dnssec (/etc/dnsmasq.time)
>>>
>>
>> lets add a system.system.write_state_to_flash_on_boot=0/1 uci option and
>> lock this and the dnssec time stuff with it and default it to 0
> 
> Security can't be opt in !
> When you see "random: ubus urandom read with 4 bits of entropy
> available" let's hope it's not security sensitive, because 2^4 will
> not take a lot of time to bruteforce...
First of all, the kernel entropy estimation is *really* pessimistic, so
there will be a lot more random bits at this point than just 4.

> Before we try to minimize writes, how much writes are we talking about?
> my openwrt routers have multiple months of uptime, and even if we get
> down to 1 week, that gets us to 53 writes a year.
> How much writes can a flash handle these days?
I'm more concerned about the worst case than the average case here.
There are people that do a forced reboot every day (as a stability
workaround), or only power up their devices during specific times of the
day (multiple reboots per day). This can easily add up to bigger numbers.

Also, adding something like this makes other people want to add even
more stuff that writes to flash on every boot, as you've so clearly
demonstrated by pointing out that this behavior are already done for
dnssec/dnsmasq.

- Felix


From champetier.etienne at gmail.com  Tue Jun 14 01:13:02 2016
From: champetier.etienne at gmail.com (Etienne Champetier)
Date: Tue, 14 Jun 2016 10:13:02 +0200
Subject: [LEDE-DEV] [PATCH] base-files: seed /dev/urandom
In-Reply-To: <3e6b2474-7096-fda5-db0a-6351d2f6be9c@nbd.name>
References: <1465627075-13683-1-git-send-email-champetier.etienne@gmail.com>
 <d16a674b-f1f0-67cb-ec02-c40804ed5a83@nbd.name>
 <CAOdf3gq8Yx6M1nUZrOBog-2ziaqP-F1qpapFf1=32XtuVaDYWg@mail.gmail.com>
 <eb1f3f1b-3d2f-f406-9dec-4a45c6c0ea00@phrozen.org>
 <CAOdf3grPLYAgyqzA8Er-Jw+jEjJxZYJkTEXrvJDLiD6rsYtpnw@mail.gmail.com>
 <3e6b2474-7096-fda5-db0a-6351d2f6be9c@nbd.name>
Message-ID: <CAOdf3gqgY1p33uP+UDrMZgjujiLhKp4os82zP8eb0n51Je5nAA@mail.gmail.com>

2016-06-14 9:08 GMT+02:00 Felix Fietkau <nbd at nbd.name>:
> On 2016-06-13 22:10, Etienne Champetier wrote:
>> Hi John, Felix,
>>
>> 2016-06-13 13:55 GMT+02:00 John Crispin <john at phrozen.org>:
>>>
>>>
>>> On 13/06/2016 00:56, Etienne Champetier wrote:
>>>> Hi Felix,
>>>>
>>>> 2016-06-12 12:45 GMT+02:00 Felix Fietkau <nbd at nbd.name>:
>>>>> On 2016-06-11 08:37, Etienne CHAMPETIER wrote:
>>>>>> This commit:
>>>>>> 1) seed /dev/urandom with a saved seed as early as possible
>>>>>>    (using /lib/preinit/81_urandom_seed)
>>>>>> 2) save a new seed using getrandom() so we are sure /dev/urandom
>>>>>>    pool is initialized (using /etc/init.d/urandom_seed)
>>>>>>
>>>>>> seed size is 512 bytes (ie /proc/sys/kernel/random/poolsize / 8)
>>>>>> it's the same size as in ubuntu 14.04 and all systemd systems
>>>>>>
>>>>>> seed file is /etc/urandom.seed (need a writable path)
>>>>>>
>>>>>> seeding /dev/urandom doesn't change entropy estimation, so we still have
>>>>>> "random: ubus urandom read with 4 bits of entropy available"
>>>>>> messages in the logs, but we can now ignore them
>>>>>>
>>>>>> We could also add an urandom.seed at build time to improve first boot
>>>>> I'm not sure writing to flash on every single boot on every device is a
>>>>> good default behavior.
>>>>>
>>>>
>>>> Just saw your comment, it endend up in spam ...
>>>>
>>>> Reusing the same seed multiple time is not really recommended, as it
>>>> means all boot with same seed are in the same state.
>>>> What would be an acceptable behaviour for you?
>>>> I could wait for ntp and then check if seed is older than X, but
>>>> that's way less robust.
>>>>
>>>> BTW, we are already writing at every boot for dnsmasq/dnssec (/etc/dnsmasq.time)
>>>>
>>>
>>> lets add a system.system.write_state_to_flash_on_boot=0/1 uci option and
>>> lock this and the dnssec time stuff with it and default it to 0
>>
>> Security can't be opt in !
>> When you see "random: ubus urandom read with 4 bits of entropy
>> available" let's hope it's not security sensitive, because 2^4 will
>> not take a lot of time to bruteforce...
> First of all, the kernel entropy estimation is *really* pessimistic, so
> there will be a lot more random bits at this point than just 4.
>
>> Before we try to minimize writes, how much writes are we talking about?
>> my openwrt routers have multiple months of uptime, and even if we get
>> down to 1 week, that gets us to 53 writes a year.
>> How much writes can a flash handle these days?
> I'm more concerned about the worst case than the average case here.
> There are people that do a forced reboot every day (as a stability
> workaround), or only power up their devices during specific times of the
> day (multiple reboots per day). This can easily add up to bigger numbers.
>
> Also, adding something like this makes other people want to add even
> more stuff that writes to flash on every boot, as you've so clearly
> demonstrated by pointing out that this behavior are already done for
> dnssec/dnsmasq.

Ok, let's find a middle ground :)
What about saving a seed if there is none (on boot), and then using an
ntp hotplug (stratum event) and save a new seed if older than say 1
week?

Etienne

>
> - Felix


From nbd at nbd.name  Tue Jun 14 01:34:28 2016
From: nbd at nbd.name (Felix Fietkau)
Date: Tue, 14 Jun 2016 10:34:28 +0200
Subject: [LEDE-DEV] [PATCH] base-files: seed /dev/urandom
In-Reply-To: <CAOdf3gqgY1p33uP+UDrMZgjujiLhKp4os82zP8eb0n51Je5nAA@mail.gmail.com>
References: <1465627075-13683-1-git-send-email-champetier.etienne@gmail.com>
 <d16a674b-f1f0-67cb-ec02-c40804ed5a83@nbd.name>
 <CAOdf3gq8Yx6M1nUZrOBog-2ziaqP-F1qpapFf1=32XtuVaDYWg@mail.gmail.com>
 <eb1f3f1b-3d2f-f406-9dec-4a45c6c0ea00@phrozen.org>
 <CAOdf3grPLYAgyqzA8Er-Jw+jEjJxZYJkTEXrvJDLiD6rsYtpnw@mail.gmail.com>
 <3e6b2474-7096-fda5-db0a-6351d2f6be9c@nbd.name>
 <CAOdf3gqgY1p33uP+UDrMZgjujiLhKp4os82zP8eb0n51Je5nAA@mail.gmail.com>
Message-ID: <003524c2-f067-69ba-40c6-ef35e1bf7ff6@nbd.name>

On 2016-06-14 10:13, Etienne Champetier wrote:
>>> Before we try to minimize writes, how much writes are we talking about?
>>> my openwrt routers have multiple months of uptime, and even if we get
>>> down to 1 week, that gets us to 53 writes a year.
>>> How much writes can a flash handle these days?
>> I'm more concerned about the worst case than the average case here.
>> There are people that do a forced reboot every day (as a stability
>> workaround), or only power up their devices during specific times of the
>> day (multiple reboots per day). This can easily add up to bigger numbers.
>>
>> Also, adding something like this makes other people want to add even
>> more stuff that writes to flash on every boot, as you've so clearly
>> demonstrated by pointing out that this behavior are already done for
>> dnssec/dnsmasq.
> 
> Ok, let's find a middle ground :)
> What about saving a seed if there is none (on boot), and then using an
> ntp hotplug (stratum event) and save a new seed if older than say 1
> week?
I think that's reasonable.

- Felix


From kevin at darbyshire-bryant.me.uk  Tue Jun 14 02:05:24 2016
From: kevin at darbyshire-bryant.me.uk (Kevin Darbyshire-Bryant)
Date: Tue, 14 Jun 2016 10:05:24 +0100
Subject: [LEDE-DEV] [PATCH] base-files: seed /dev/urandom
In-Reply-To: <CAOdf3gqgY1p33uP+UDrMZgjujiLhKp4os82zP8eb0n51Je5nAA@mail.gmail.com>
References: <1465627075-13683-1-git-send-email-champetier.etienne@gmail.com>
 <d16a674b-f1f0-67cb-ec02-c40804ed5a83@nbd.name>
 <CAOdf3gq8Yx6M1nUZrOBog-2ziaqP-F1qpapFf1=32XtuVaDYWg@mail.gmail.com>
 <eb1f3f1b-3d2f-f406-9dec-4a45c6c0ea00@phrozen.org>
 <CAOdf3grPLYAgyqzA8Er-Jw+jEjJxZYJkTEXrvJDLiD6rsYtpnw@mail.gmail.com>
 <3e6b2474-7096-fda5-db0a-6351d2f6be9c@nbd.name>
 <CAOdf3gqgY1p33uP+UDrMZgjujiLhKp4os82zP8eb0n51Je5nAA@mail.gmail.com>
Message-ID: <575FC8D4.8030507@darbyshire-bryant.me.uk>



On 14/06/16 09:13, Etienne Champetier wrote:
> 2016-06-14 9:08 GMT+02:00 Felix Fietkau <nbd at nbd.name>:
>> On 2016-06-13 22:10, Etienne Champetier wrote:
>>> Hi John, Felix,
>>>
>>> 2016-06-13 13:55 GMT+02:00 John Crispin <john at phrozen.org>:
>>>>
>>>> On 13/06/2016 00:56, Etienne Champetier wrote:
>>>>> Hi Felix,
>>>>>
>>>>> 2016-06-12 12:45 GMT+02:00 Felix Fietkau <nbd at nbd.name>:
>>>>>> On 2016-06-11 08:37, Etienne CHAMPETIER wrote:
>>>>>>> This commit:
>>>>>>> 1) seed /dev/urandom with a saved seed as early as possible
>>>>>>>     (using /lib/preinit/81_urandom_seed)
>>>>>>> 2) save a new seed using getrandom() so we are sure /dev/urandom
>>>>>>>     pool is initialized (using /etc/init.d/urandom_seed)
>>>>>>>
>>>>>>> seed size is 512 bytes (ie /proc/sys/kernel/random/poolsize / 8)
>>>>>>> it's the same size as in ubuntu 14.04 and all systemd systems
>>>>>>>
>>>>>>> seed file is /etc/urandom.seed (need a writable path)
>>>>>>>
>>>>>>> seeding /dev/urandom doesn't change entropy estimation, so we still have
>>>>>>> "random: ubus urandom read with 4 bits of entropy available"
>>>>>>> messages in the logs, but we can now ignore them
>>>>>>>
>>>>>>> We could also add an urandom.seed at build time to improve first boot
>>>>>> I'm not sure writing to flash on every single boot on every device is a
>>>>>> good default behavior.
>>>>>>
>>>>> Just saw your comment, it endend up in spam ...
>>>>>
>>>>> Reusing the same seed multiple time is not really recommended, as it
>>>>> means all boot with same seed are in the same state.
>>>>> What would be an acceptable behaviour for you?
>>>>> I could wait for ntp and then check if seed is older than X, but
>>>>> that's way less robust.
>>>>>
>>>>> BTW, we are already writing at every boot for dnsmasq/dnssec (/etc/dnsmasq.time)
>>>>>
>>>> lets add a system.system.write_state_to_flash_on_boot=0/1 uci option and
>>>> lock this and the dnssec time stuff with it and default it to 0
>>> Security can't be opt in !
>>> When you see "random: ubus urandom read with 4 bits of entropy
>>> available" let's hope it's not security sensitive, because 2^4 will
>>> not take a lot of time to bruteforce...
>> First of all, the kernel entropy estimation is *really* pessimistic, so
>> there will be a lot more random bits at this point than just 4.
>>
>>> Before we try to minimize writes, how much writes are we talking about?
>>> my openwrt routers have multiple months of uptime, and even if we get
>>> down to 1 week, that gets us to 53 writes a year.
>>> How much writes can a flash handle these days?
>> I'm more concerned about the worst case than the average case here.
>> There are people that do a forced reboot every day (as a stability
>> workaround), or only power up their devices during specific times of the
>> day (multiple reboots per day). This can easily add up to bigger numbers.
>>
>> Also, adding something like this makes other people want to add even
>> more stuff that writes to flash on every boot, as you've so clearly
>> demonstrated by pointing out that this behavior are already done for
>> dnssec/dnsmasq.
> Ok, let's find a middle ground :)
> What about saving a seed if there is none (on boot), and then using an
> ntp hotplug (stratum event) and save a new seed if older than say 1
> week?
>
> Etienne
And I'll look at getting dnsmasq/dnssec to work with ntp hotplug as 
well.  I'm not a quick or elegant coder ;-)
>> - Felix
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev



From zajec5 at gmail.com  Tue Jun 14 03:55:41 2016
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Tue, 14 Jun 2016 12:55:41 +0200
Subject: [LEDE-DEV] [PATCH] kernel: rename B53 symbols to avoid upstream
	kernel conflict
Message-ID: <1465901741-17589-1-git-send-email-zajec5@gmail.com>

In kernel 4.7 there is upstreamed b53 driver using (mostly?) the same
symbols as our b53 does. Change our symbols so both drivers can coexist
in kernel tree.

Signed-off-by: Rafa? Mi?ecki <zajec5 at gmail.com>
---
 target/linux/bcm53xx/config-4.4                    |  8 ++++----
 target/linux/brcm47xx/config-4.1                   | 10 +++++-----
 target/linux/brcm47xx/config-4.4                   | 10 +++++-----
 target/linux/brcm63xx/config-4.4                   | 12 ++++++------
 target/linux/generic/config-3.18                   |  4 ++--
 target/linux/generic/config-4.1                    |  4 ++--
 target/linux/generic/config-4.4                    |  4 ++--
 .../generic/files/drivers/net/phy/b53/Kconfig      | 22 +++++++++++-----------
 .../generic/files/drivers/net/phy/b53/Makefile     | 14 +++++++-------
 .../linux/generic/patches-3.18/730-phy_b53.patch   |  2 +-
 target/linux/generic/patches-4.1/730-phy_b53.patch |  2 +-
 target/linux/generic/patches-4.4/730-phy_b53.patch |  2 +-
 target/linux/sunxi/config-4.4                      | 10 +++++-----
 13 files changed, 52 insertions(+), 52 deletions(-)

diff --git a/target/linux/bcm53xx/config-4.4 b/target/linux/bcm53xx/config-4.4
index aace5e7..58fbb52 100644
--- a/target/linux/bcm53xx/config-4.4
+++ b/target/linux/bcm53xx/config-4.4
@@ -54,10 +54,10 @@ CONFIG_ARM_THUMB=y
 CONFIG_ARM_VIRT_EXT=y
 CONFIG_ATAGS=y
 CONFIG_AUTO_ZRELADDR=y
-CONFIG_B53=y
-# CONFIG_B53_MMAP_DRIVER is not set
-# CONFIG_B53_PHY_DRIVER is not set
-CONFIG_B53_SRAB_DRIVER=y
+CONFIG_SWCONFIG_B53=y
+# CONFIG_SWCONFIG_B53_MMAP_DRIVER is not set
+# CONFIG_SWCONFIG_B53_PHY_DRIVER is not set
+CONFIG_SWCONFIG_B53_SRAB_DRIVER=y
 CONFIG_BCM47XX_NVRAM=y
 CONFIG_BCM47XX_SPROM=y
 CONFIG_BCM47XX_WDT=y
diff --git a/target/linux/brcm47xx/config-4.1 b/target/linux/brcm47xx/config-4.1
index 0b812d5..5cf8550 100644
--- a/target/linux/brcm47xx/config-4.1
+++ b/target/linux/brcm47xx/config-4.1
@@ -12,11 +12,11 @@ CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y
 CONFIG_ARCH_SUSPEND_POSSIBLE=y
 CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
 CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
-CONFIG_B53=y
-# CONFIG_B53_MMAP_DRIVER is not set
-CONFIG_B53_PHY_DRIVER=y
-CONFIG_B53_PHY_FIXUP=y
-# CONFIG_B53_SRAB_DRIVER is not set
+CONFIG_SWCONFIG_B53=y
+# CONFIG_SWCONFIG_B53_MMAP_DRIVER is not set
+CONFIG_SWCONFIG_B53_PHY_DRIVER=y
+CONFIG_SWCONFIG_B53_PHY_FIXUP=y
+# CONFIG_SWCONFIG_B53_SRAB_DRIVER is not set
 CONFIG_BCM47XX=y
 CONFIG_BCM47XX_BCMA=y
 CONFIG_BCM47XX_SSB=y
diff --git a/target/linux/brcm47xx/config-4.4 b/target/linux/brcm47xx/config-4.4
index b72a724..492b12b 100644
--- a/target/linux/brcm47xx/config-4.4
+++ b/target/linux/brcm47xx/config-4.4
@@ -14,11 +14,11 @@ CONFIG_ARCH_SUSPEND_POSSIBLE=y
 CONFIG_ARCH_USE_BUILTIN_BSWAP=y
 CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
 CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
-CONFIG_B53=y
-# CONFIG_B53_MMAP_DRIVER is not set
-CONFIG_B53_PHY_DRIVER=y
-CONFIG_B53_PHY_FIXUP=y
-# CONFIG_B53_SRAB_DRIVER is not set
+CONFIG_SWCONFIG_B53=y
+# CONFIG_SWCONFIG_B53_MMAP_DRIVER is not set
+CONFIG_SWCONFIG_B53_PHY_DRIVER=y
+CONFIG_SWCONFIG_B53_PHY_FIXUP=y
+# CONFIG_SWCONFIG_B53_SRAB_DRIVER is not set
 CONFIG_BCM47XX=y
 CONFIG_BCM47XX_BCMA=y
 CONFIG_BCM47XX_NVRAM=y
diff --git a/target/linux/brcm63xx/config-4.4 b/target/linux/brcm63xx/config-4.4
index a0ec048..99022b1 100644
--- a/target/linux/brcm63xx/config-4.4
+++ b/target/linux/brcm63xx/config-4.4
@@ -13,12 +13,12 @@ CONFIG_ARCH_SUPPORTS_UPROBES=y
 CONFIG_ARCH_SUSPEND_POSSIBLE=y
 CONFIG_ARCH_USE_BUILTIN_BSWAP=y
 CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
-CONFIG_B53=y
-CONFIG_B53_MMAP_DRIVER=y
-CONFIG_B53_PHY_DRIVER=y
-CONFIG_B53_PHY_FIXUP=y
-CONFIG_B53_SPI_DRIVER=y
-# CONFIG_B53_SRAB_DRIVER is not set
+CONFIG_SWCONFIG_B53=y
+CONFIG_SWCONFIG_B53_MMAP_DRIVER=y
+CONFIG_SWCONFIG_B53_PHY_DRIVER=y
+CONFIG_SWCONFIG_B53_PHY_FIXUP=y
+CONFIG_SWCONFIG_B53_SPI_DRIVER=y
+# CONFIG_SWCONFIG_B53_SRAB_DRIVER is not set
 CONFIG_BCM6345_EXT_IRQ=y
 CONFIG_BCM6345_PERIPH_IRQ=y
 CONFIG_BCM63XX=y
diff --git a/target/linux/generic/config-3.18 b/target/linux/generic/config-3.18
index 9185255..a2c81c2 100644
--- a/target/linux/generic/config-3.18
+++ b/target/linux/generic/config-3.18
@@ -330,8 +330,8 @@ CONFIG_ATM_CLIP_NO_ICMP=y
 # CONFIG_B43 is not set
 # CONFIG_B43LEGACY is not set
 # CONFIG_B44 is not set
-# CONFIG_B53 is not set
-# CONFIG_B53_SPI_DRIVER is not set
+# CONFIG_SWCONFIG_B53 is not set
+# CONFIG_SWCONFIG_B53_SPI_DRIVER is not set
 # CONFIG_BACKLIGHT_BD6107 is not set
 # CONFIG_BACKLIGHT_GPIO is not set
 # CONFIG_BACKLIGHT_LCD_SUPPORT is not set
diff --git a/target/linux/generic/config-4.1 b/target/linux/generic/config-4.1
index bdc4f13..fa95759 100644
--- a/target/linux/generic/config-4.1
+++ b/target/linux/generic/config-4.1
@@ -344,8 +344,8 @@ CONFIG_ATM_CLIP_NO_ICMP=y
 # CONFIG_B43 is not set
 # CONFIG_B43LEGACY is not set
 # CONFIG_B44 is not set
-# CONFIG_B53 is not set
-# CONFIG_B53_SPI_DRIVER is not set
+# CONFIG_SWCONFIG_B53 is not set
+# CONFIG_SWCONFIG_B53_SPI_DRIVER is not set
 # CONFIG_BACKLIGHT_ADP8860 is not set 
 # CONFIG_BACKLIGHT_ADP8870 is not set
 # CONFIG_BACKLIGHT_BD6107 is not set
diff --git a/target/linux/generic/config-4.4 b/target/linux/generic/config-4.4
index 3bf0534..c9e8dda 100644
--- a/target/linux/generic/config-4.4
+++ b/target/linux/generic/config-4.4
@@ -321,8 +321,8 @@ CONFIG_ATM_CLIP_NO_ICMP=y
 # CONFIG_B43 is not set
 # CONFIG_B43LEGACY is not set
 # CONFIG_B44 is not set
-# CONFIG_B53 is not set
-# CONFIG_B53_SPI_DRIVER is not set
+# CONFIG_SWCONFIG_B53 is not set
+# CONFIG_SWCONFIG_B53_SPI_DRIVER is not set
 # CONFIG_BACKLIGHT_ADP8860 is not set
 # CONFIG_BACKLIGHT_ADP8870 is not set
 # CONFIG_BACKLIGHT_BD6107 is not set
diff --git a/target/linux/generic/files/drivers/net/phy/b53/Kconfig b/target/linux/generic/files/drivers/net/phy/b53/Kconfig
index 67e053e..08287e7 100644
--- a/target/linux/generic/files/drivers/net/phy/b53/Kconfig
+++ b/target/linux/generic/files/drivers/net/phy/b53/Kconfig
@@ -1,4 +1,4 @@
-menuconfig B53
+menuconfig SWCONFIG_B53
 	tristate "Broadcom bcm53xx managed switch support"
 	depends on SWCONFIG
 	help
@@ -6,32 +6,32 @@ menuconfig B53
 	  BCM5325E, BCM5365, BCM539x, BCM53115 and BCM53125 as well as BCM63XX
 	  integrated switches.
 
-config B53_SPI_DRIVER
+config SWCONFIG_B53_SPI_DRIVER
 	tristate "B53 SPI connected switch driver"
-	depends on B53 && SPI
+	depends on SWCONFIG_B53 && SPI
 	help
 	  Select to enable support for registering switches configured through SPI.
 
-config B53_PHY_DRIVER
+config SWCONFIG_B53_PHY_DRIVER
 	tristate "B53 MDIO connected switch driver"
-	depends on B53
-	select B53_PHY_FIXUP
+	depends on SWCONFIG_B53
+	select SWCONFIG_B53_PHY_FIXUP
 	help
 	  Select to enable support for registering switches configured through MDIO.
 
-config B53_MMAP_DRIVER
+config SWCONFIG_B53_MMAP_DRIVER
 	tristate "B53 MMAP connected switch driver"
-	depends on B53
+	depends on SWCONFIG_B53
 	help
 	  Select to enable support for memory-mapped switches like the BCM63XX
 	  integrated switches.
 
-config B53_SRAB_DRIVER
+config SWCONFIG_B53_SRAB_DRIVER
 	tristate "B53 SRAB connected switch driver"
-	depends on B53
+	depends on SWCONFIG_B53
 	help
 	  Select to enable support for memory-mapped Switch Register Access
 	  Bridge Registers (SRAB) like it is found on the BCM53010
 
-config B53_PHY_FIXUP
+config SWCONFIG_B53_PHY_FIXUP
 	bool
diff --git a/target/linux/generic/files/drivers/net/phy/b53/Makefile b/target/linux/generic/files/drivers/net/phy/b53/Makefile
index 7cc39c7..13ff366 100644
--- a/target/linux/generic/files/drivers/net/phy/b53/Makefile
+++ b/target/linux/generic/files/drivers/net/phy/b53/Makefile
@@ -1,10 +1,10 @@
-obj-$(CONFIG_B53)		+= b53_common.o
+obj-$(CONFIG_SWCONFIG_B53)		+= b53_common.o
 
-obj-$(CONFIG_B53_PHY_FIXUP)	+= b53_phy_fixup.o
+obj-$(CONFIG_SWCONFIG_B53_PHY_FIXUP)	+= b53_phy_fixup.o
 
-obj-$(CONFIG_B53_MMAP_DRIVER)	+= b53_mmap.o
-obj-$(CONFIG_B53_SRAB_DRIVER)	+= b53_srab.o
-obj-$(CONFIG_B53_PHY_DRIVER)	+= b53_mdio.o
-obj-$(CONFIG_B53_SPI_DRIVER)	+= b53_spi.o
+obj-$(CONFIG_SWCONFIG_B53_MMAP_DRIVER)	+= b53_mmap.o
+obj-$(CONFIG_SWCONFIG_B53_SRAB_DRIVER)	+= b53_srab.o
+obj-$(CONFIG_SWCONFIG_B53_PHY_DRIVER)	+= b53_mdio.o
+obj-$(CONFIG_SWCONFIG_B53_SPI_DRIVER)	+= b53_spi.o
 
-ccflags-y			+= -Werror
+ccflags-y				+= -Werror
diff --git a/target/linux/generic/patches-3.18/730-phy_b53.patch b/target/linux/generic/patches-3.18/730-phy_b53.patch
index c2dfcfa..03fc369 100644
--- a/target/linux/generic/patches-3.18/730-phy_b53.patch
+++ b/target/linux/generic/patches-3.18/730-phy_b53.patch
@@ -15,7 +15,7 @@
  obj-$(CONFIG_RTL8367B_PHY)	+= rtl8367b.o
  obj-$(CONFIG_LSI_ET1011C_PHY)	+= et1011c.o
  obj-$(CONFIG_PSB6970_PHY)	+= psb6970.o
-+obj-$(CONFIG_B53)		+= b53/
++obj-$(CONFIG_SWCONFIG_B53)	+= b53/
  obj-$(CONFIG_FIXED_PHY)		+= fixed.o
  obj-$(CONFIG_MDIO_BITBANG)	+= mdio-bitbang.o
  obj-$(CONFIG_MDIO_GPIO)		+= mdio-gpio.o
diff --git a/target/linux/generic/patches-4.1/730-phy_b53.patch b/target/linux/generic/patches-4.1/730-phy_b53.patch
index bdcfba6..ff16689 100644
--- a/target/linux/generic/patches-4.1/730-phy_b53.patch
+++ b/target/linux/generic/patches-4.1/730-phy_b53.patch
@@ -15,7 +15,7 @@
  obj-$(CONFIG_RTL8367B_PHY)	+= rtl8367b.o
  obj-$(CONFIG_LSI_ET1011C_PHY)	+= et1011c.o
  obj-$(CONFIG_PSB6970_PHY)	+= psb6970.o
-+obj-$(CONFIG_B53)		+= b53/
++obj-$(CONFIG_SWCONFIG_B53)	+= b53/
  obj-$(CONFIG_FIXED_PHY)		+= fixed_phy.o
  obj-$(CONFIG_MDIO_BITBANG)	+= mdio-bitbang.o
  obj-$(CONFIG_MDIO_GPIO)		+= mdio-gpio.o
diff --git a/target/linux/generic/patches-4.4/730-phy_b53.patch b/target/linux/generic/patches-4.4/730-phy_b53.patch
index 71a53fd..1a6de96 100644
--- a/target/linux/generic/patches-4.4/730-phy_b53.patch
+++ b/target/linux/generic/patches-4.4/730-phy_b53.patch
@@ -15,7 +15,7 @@
  obj-$(CONFIG_RTL8367B_PHY)	+= rtl8367b.o
  obj-$(CONFIG_LSI_ET1011C_PHY)	+= et1011c.o
  obj-$(CONFIG_PSB6970_PHY)	+= psb6970.o
-+obj-$(CONFIG_B53)		+= b53/
++obj-$(CONFIG_SWCONFIG_B53)	+= b53/
  obj-$(CONFIG_FIXED_PHY)		+= fixed_phy.o
  obj-$(CONFIG_MDIO_BITBANG)	+= mdio-bitbang.o
  obj-$(CONFIG_MDIO_GPIO)		+= mdio-gpio.o
diff --git a/target/linux/sunxi/config-4.4 b/target/linux/sunxi/config-4.4
index 568bcb7..b05446c 100644
--- a/target/linux/sunxi/config-4.4
+++ b/target/linux/sunxi/config-4.4
@@ -57,11 +57,11 @@ CONFIG_AUDIT=y
 CONFIG_AUDIT_GENERIC=y
 CONFIG_AUTO_ZRELADDR=y
 CONFIG_AXP20X_POWER=y
-CONFIG_B53=y
-# CONFIG_B53_MMAP_DRIVER is not set
-CONFIG_B53_PHY_DRIVER=y
-CONFIG_B53_PHY_FIXUP=y
-# CONFIG_B53_SRAB_DRIVER is not set
+CONFIG_SWCONFIG_B53=y
+# CONFIG_SWCONFIG_B53_MMAP_DRIVER is not set
+CONFIG_SWCONFIG_B53_PHY_DRIVER=y
+CONFIG_SWCONFIG_B53_PHY_FIXUP=y
+# CONFIG_SWCONFIG_B53_SRAB_DRIVER is not set
 CONFIG_BACKLIGHT_CLASS_DEVICE=y
 CONFIG_BACKLIGHT_LCD_SUPPORT=y
 CONFIG_BACKLIGHT_PWM=y
-- 
1.8.4.5



From kevin at darbyshire-bryant.me.uk  Tue Jun 14 04:33:43 2016
From: kevin at darbyshire-bryant.me.uk (Kevin Darbyshire-Bryant)
Date: Tue, 14 Jun 2016 12:33:43 +0100
Subject: [LEDE-DEV] [PATCH] base-files: seed /dev/urandom
In-Reply-To: <575FC8D4.8030507@darbyshire-bryant.me.uk>
References: <1465627075-13683-1-git-send-email-champetier.etienne@gmail.com>
 <d16a674b-f1f0-67cb-ec02-c40804ed5a83@nbd.name>
 <CAOdf3gq8Yx6M1nUZrOBog-2ziaqP-F1qpapFf1=32XtuVaDYWg@mail.gmail.com>
 <eb1f3f1b-3d2f-f406-9dec-4a45c6c0ea00@phrozen.org>
 <CAOdf3grPLYAgyqzA8Er-Jw+jEjJxZYJkTEXrvJDLiD6rsYtpnw@mail.gmail.com>
 <3e6b2474-7096-fda5-db0a-6351d2f6be9c@nbd.name>
 <CAOdf3gqgY1p33uP+UDrMZgjujiLhKp4os82zP8eb0n51Je5nAA@mail.gmail.com>
 <575FC8D4.8030507@darbyshire-bryant.me.uk>
Message-ID: <575FEB97.8020509@darbyshire-bryant.me.uk>



On 14/06/16 10:05, Kevin Darbyshire-Bryant wrote:
>
>
> On 14/06/16 09:13, Etienne Champetier wrote:
>> Ok, let's find a middle ground :)
>> What about saving a seed if there is none (on boot), and then using an
>> ntp hotplug (stratum event) and save a new seed if older than say 1
>> week?
>>
>> Etienne
> And I'll look at getting dnsmasq/dnssec to work with ntp hotplug as 
> well.  I'm not a quick or elegant coder ;-)
https://github.com/lede-project/source/pull/119  - very RFC!



From daniel at daniel.thecshore.com  Mon Jun 13 18:40:55 2016
From: daniel at daniel.thecshore.com (Daniel Curran-Dickinson)
Date: Mon, 13 Jun 2016 21:40:55 -0400
Subject: [LEDE-DEV] lede integration issues remaining from the detrius
 of cerowrt
In-Reply-To: <f6898485-e1d4-ec35-4563-4591512d2d84@mein.io>
References: <CAA93jw7=bHNXJqmjWmg3CHHH-biua17wK4AHfn_wB0wPWs=EqQ@mail.gmail.com>
 <CAJOqq5TB4qki1iWHZd71kzXYoA=A3+4BeycoNPKqRXFWZ6bMZQ@mail.gmail.com>
 <f6898485-e1d4-ec35-4563-4591512d2d84@mein.io>
Message-ID: <1465868455.2580.35.camel@homehost>


On Mon, 2016-06-13 at 11:17 +0200, Jo-Philipp Wich wrote: 
> Hi,
> 
> no need to overreact :)  I think parts of the topics are about the

Hope you're referring to Pinney and not me!  I was concerned because
Dave Taht's email and David Lang's post) seemed to me to imply changing the
defaults to suit bigger iron as the default rather than simply making
it a supported option.  I also think that talking about a 5-10 plan as
the basis if making decision of what to include by default in *current* builds
is rather foolish thinking.  Yes planning for the future is important but to
it reminds of a quote from when I was religious: "Don't be so heavenly-minded
you're no earthly good".  Basically here and now needs not to be forgotten in
dreams of future wonders.

There are still enough users of LEDE/OpenWrt who are frustrated by what they see
as excessive bloat that makes it unusable on their existing devices.  I myself
am torn.  I hate obsoleting hardware that I think ought to be perfectly useful
for some things and isn't like keeping an old CRT around vs getting flat screen in
terms of issues like energy efficiency and maybe better, maybe worse when you add
up all the actual physical / environmental costs of getting rid of old vs going with
new.  This is comes down to whether there is a will to make the effort (and it does
take effort, that I will not argue) to keep old hardware going, or whether to only
go for 'new, shiny' and forget about what currently exists.

To a certain extent though, I question the need for something as restricted as OpenWrt
for the new bigger devices anyway; there are elements like netifd that would be good to
see continue, but I'm not sure that most of OpenWrt really makes as much sense when you're
not needing to squeeze maximum use out of very erase block, and that therefore, while it
may be a smaller market/mindshare, that focussing on the the true embedded type scenario,
seems to be more of what LEDE's niche is.

Regards,

Daniel




From daniel at daniel.thecshore.com  Mon Jun 13 20:50:15 2016
From: daniel at daniel.thecshore.com (Daniel Curran-Dickinson)
Date: Mon, 13 Jun 2016 23:50:15 -0400
Subject: [LEDE-DEV] [PATCH] base-files: seed /dev/urandom
In-Reply-To: <CAOdf3grPLYAgyqzA8Er-Jw+jEjJxZYJkTEXrvJDLiD6rsYtpnw@mail.gmail.com>
References: <1465627075-13683-1-git-send-email-champetier.etienne@gmail.com>
 <d16a674b-f1f0-67cb-ec02-c40804ed5a83@nbd.name>
 <CAOdf3gq8Yx6M1nUZrOBog-2ziaqP-F1qpapFf1=32XtuVaDYWg@mail.gmail.com>
 <eb1f3f1b-3d2f-f406-9dec-4a45c6c0ea00@phrozen.org>
 <CAOdf3grPLYAgyqzA8Er-Jw+jEjJxZYJkTEXrvJDLiD6rsYtpnw@mail.gmail.com>
Message-ID: <1465876215.2580.44.camel@homehost>

On Mon, 2016-06-13 at 22:10 +0200, Etienne Champetier wrote:

> Before we try to minimize writes, how much writes are we talking about?
> my openwrt routers have multiple months of uptime, and even if we get
> down to 1 week, that gets us to 53 writes a year.
> How much writes can a flash handle these days?

I'm told that even cheap wear-levelling and flash chips from 4-5 years
ago with even 4 MB flash that it's really non-issue (and done the math
for what would be the case if wear levelling worked as claimed, on all
blocks, not just currently unwritten; the real question is whether
wear-levelling works as claimed, or more to the point whether there is
any *hard data* that says wear levelling does *not* work as claimed, or
whether persistent anecdotal stories of worn out flash are based on
urban legends, or classic mis-attribution).

Regards,

Daniel



From koen.vandeputte at ncentric.com  Tue Jun 14 07:34:13 2016
From: koen.vandeputte at ncentric.com (Koen Vandeputte)
Date: Tue, 14 Jun 2016 16:34:13 +0200
Subject: [LEDE-DEV] Bug - spinlock loop in cns3xxx_eth.c
In-Reply-To: <CAJ+vNU0JxQJJZxjW+VHWDA4O-ujBh0T3ydu4GdNYtxumAFNW0A@mail.gmail.com>
References: <575EDB77.4040400@ncentric.com>
 <CAJ+vNU0JxQJJZxjW+VHWDA4O-ujBh0T3ydu4GdNYtxumAFNW0A@mail.gmail.com>
Message-ID: <576015E5.7060106@ncentric.com>

Hi Tim,

I fully understand the reason for the check.

However,
I think the bug has nothing to do with the rotting packet issue.


The bug is actually:
- eth_schedule_poll() gets called as it's detected that the ring is full 
after IRQ_enable. (cown flag is set in the previous slot of the ring)
--> During this extra loop,  _0_ packets are received/processed! The 
ring still seems to be full, and another reschedule takes place .. and 
so on ..


Iv'e added 3 debug counters in the code:    (see below after the patch)
- Loop --> Top of eth_poll()
- IRQ --> Top of eth_rx_irq()
- Resched --> Inside the reschedule check




Patch:

--- a/drivers/net/ethernet/cavium/cns3xxx_eth.c
+++ b/drivers/net/ethernet/cavium/cns3xxx_eth.c
@@ -308,6 +308,8 @@ static int ports_open;
  static struct port *switch_port_tab[4];
  struct net_device *napi_dev;

+static int CntIRQ;
+
  static int cns3xxx_mdio_cmd(struct mii_bus *bus, int phy_id, int location,
                 int write, u16 cmd)
  {
@@ -437,7 +439,10 @@ static void cns3xxx_adjust_link(struct n
  static void eth_schedule_poll(struct sw *sw)
  {
      if (unlikely(!napi_schedule_prep(&sw->napi)))
+    {
+        //printk(KERN_ERR "sched err\n");
          return;
+    }

      disable_irq_nosync(sw->rx_irq);
      __napi_schedule(&sw->napi);
@@ -447,6 +452,7 @@ irqreturn_t eth_rx_irq(int irq, void *pd
  {
      struct net_device *dev = pdev;
      struct sw *sw = netdev_priv(dev);
+    CntIRQ++;
      eth_schedule_poll(sw);
      return (IRQ_HANDLED);
  }
@@ -617,6 +623,7 @@ static void eth_complete_tx(struct sw *s

  static int eth_poll(struct napi_struct *napi, int budget)
  {
+    static int Loop = 0;
      struct sw *sw = container_of(napi, struct sw, napi);
      struct _rx_ring *rx_ring = &sw->rx_ring;
      int received = 0;
@@ -712,6 +719,9 @@ static int eth_poll(struct napi_struct *
      }

      rx_ring->cur_index = i;
+
+    Loop++;
+
      if (!received) {
          napi_complete(napi);
          enable_irq(sw->rx_irq);
@@ -719,7 +729,12 @@ static int eth_poll(struct napi_struct *

          /* if rx descriptors are full schedule another poll */
          if (rx_ring->desc[(i-1) & (RX_DESCS-1)].cown)
+        {
+            static int Sched = 0;
+
+            printk(KERN_ERR "Loop: %d irq: %d ReSched: %d\n", Loop, 
CntIRQ, ++Sched);
              eth_schedule_poll(sw);
+        }
      }

      spin_lock_bh(&tx_lock);



When the bug triggers, you can see below that consecutive loops in 
eth_poll(), triggered by a reschedule, doesn't process any RX packets at 
all ..
(As the ReSched counter increases linear with the loop counter and 
ReSched can only be incremented when "!received")


Also
Checking /proc/interrupts shows that gig_switch IRQ counter goes berserk 
(+10k IRQ/s)


[  477.440000] Loop: 835307 irq: 300583 ReSched: 1
[  477.440000] Loop: 835308 irq: 300583 ReSched: 2
[  477.440000] Loop: 835310 irq: 300583 ReSched: 3
[  477.440000] Loop: 835311 irq: 300583 ReSched: 4
[  477.440000] Loop: 835312 irq: 300583 ReSched: 5
[  477.440000] Loop: 835313 irq: 300583 ReSched: 6
[  477.440000] Loop: 835314 irq: 300583 ReSched: 7
[  477.440000] Loop: 835315 irq: 300583 ReSched: 8
[  477.440000] Loop: 835316 irq: 300583 ReSched: 9
[  477.440000] Loop: 835317 irq: 300583 ReSched: 10
[  477.440000] Loop: 835318 irq: 300583 ReSched: 11
[  477.440000] Loop: 835319 irq: 300583 ReSched: 12
[  477.440000] Loop: 835320 irq: 300583 ReSched: 13
[  477.440000] Loop: 835321 irq: 300583 ReSched: 14
[  477.440000] Loop: 835322 irq: 300583 ReSched: 15
[  477.440000] Loop: 835323 irq: 300583 ReSched: 16
[  477.440000] Loop: 835324 irq: 300583 ReSched: 17
[  477.440000] Loop: 835325 irq: 300583 ReSched: 18
[  477.440000] Loop: 835326 irq: 300583 ReSched: 19
[  477.440000] Loop: 835327 irq: 300583 ReSched: 20
[  477.440000] Loop: 835328 irq: 300583 ReSched: 21
[  477.440000] Loop: 835329 irq: 300583 ReSched: 22
[  477.440000] Loop: 835330 irq: 300583 ReSched: 23
[  477.440000] Loop: 835331 irq: 300583 ReSched: 24
[  477.440000] Loop: 835332 irq: 300583 ReSched: 25
[  477.440000] Loop: 835333 irq: 300583 ReSched: 26
[  477.440000] Loop: 835334 irq: 300583 ReSched: 27
[  477.440000] Loop: 835335 irq: 300583 ReSched: 28
[  477.440000] Loop: 835336 irq: 300583 ReSched: 29
[  477.440000] Loop: 835337 irq: 300583 ReSched: 30
[  477.440000] Loop: 835338 irq: 300583 ReSched: 31
[  477.440000] Loop: 835339 irq: 300583 ReSched: 32
[  477.440000] Loop: 835340 irq: 300583 ReSched: 33
[  477.440000] Loop: 835341 irq: 300583 ReSched: 34
[  477.440000] Loop: 835342 irq: 300583 ReSched: 35
[  477.440000] Loop: 835343 irq: 300583 ReSched: 36
[  477.440000] Loop: 835344 irq: 300583 ReSched: 37
[  477.440000] Loop: 835345 irq: 300583 ReSched: 38
[  477.440000] Loop: 835346 irq: 300583 ReSched: 39
[  477.440000] Loop: 835347 irq: 300583 ReSched: 40
[  477.440000] Loop: 835348 irq: 300583 ReSched: 41
[  477.440000] Loop: 835349 irq: 300583 ReSched: 42
[  477.440000] Loop: 835350 irq: 300583 ReSched: 43
[  477.440000] Loop: 835351 irq: 300583 ReSched: 44
[  477.440000] Loop: 835352 irq: 300583 ReSched: 45
[  477.440000] Loop: 835353 irq: 300583 ReSched: 46
[  477.440000] Loop: 835354 irq: 300583 ReSched: 47
[  477.440000] Loop: 835355 irq: 300583 ReSched: 48
[  477.440000] Loop: 835356 irq: 300583 ReSched: 49
[  477.440000] Loop: 835357 irq: 300583 ReSched: 50
[  477.440000] Loop: 835358 irq: 300583 ReSched: 51
[  477.440000] Loop: 835359 irq: 300583 ReSched: 52
[  477.440000] Loop: 835360 irq: 300583 ReSched: 53
[  477.440000] Loop: 835361 irq: 300583 ReSched: 54
[  477.440000] Loop: 835362 irq: 300583 ReSched: 55
[  477.440000] Loop: 835363 irq: 300583 ReSched: 56
[  477.440000] Loop: 835364 irq: 300583 ReSched: 57
[  477.440000] Loop: 835365 irq: 300583 ReSched: 58
[  477.440000] Loop: 835366 irq: 300583 ReSched: 59
[  477.440000] Loop: 835367 irq: 300583 ReSched: 60
[  477.440000] Loop: 835368 irq: 300583 ReSched: 61
[  477.440000] Loop: 835369 irq: 300583 ReSched: 62
[  477.440000] Loop: 835370 irq: 300583 ReSched: 63
[  477.440000] Loop: 835371 irq: 300583 ReSched: 64
[  477.440000] Loop: 835372 irq: 300583 ReSched: 65
[  477.440000] Loop: 835373 irq: 300583 ReSched: 66
[  477.440000] Loop: 835374 irq: 300583 ReSched: 67
[  477.440000] Loop: 835375 irq: 300583 ReSched: 68
[  477.440000] Loop: 835376 irq: 300583 ReSched: 69
[  477.440000] Loop: 835377 irq: 300583 ReSched: 70
[  477.440000] Loop: 835378 irq: 300583 ReSched: 71
[  477.440000] Loop: 835379 irq: 300583 ReSched: 72
[  477.440000] Loop: 835380 irq: 300583 ReSched: 73
[  477.440000] Loop: 835381 irq: 300583 ReSched: 74
[  477.440000] Loop: 835382 irq: 300583 ReSched: 75
[  477.440000] Loop: 835383 irq: 300583 ReSched: 76
[  477.440000] Loop: 835384 irq: 300583 ReSched: 77
[  477.440000] Loop: 835385 irq: 300583 ReSched: 78
[  477.440000] Loop: 835386 irq: 300583 ReSched: 79
[  477.440000] Loop: 835387 irq: 300583 ReSched: 80
[  477.440000] Loop: 835388 irq: 300583 ReSched: 81
[  477.440000] Loop: 835389 irq: 300583 ReSched: 82
[  477.440000] Loop: 835390 irq: 300583 ReSched: 83
[  477.440000] Loop: 835391 irq: 300583 ReSched: 84
[  477.440000] Loop: 835392 irq: 300583 ReSched: 85
[  477.440000] Loop: 835393 irq: 300583 ReSched: 86
[  477.440000] Loop: 835394 irq: 300583 ReSched: 87
[  477.440000] Loop: 835396 irq: 300583 ReSched: 88
[  477.440000] Loop: 835397 irq: 300583 ReSched: 89
[  477.440000] Loop: 835398 irq: 300583 ReSched: 90
[  477.440000] Loop: 835399 irq: 300583 ReSched: 91
[  477.440000] Loop: 835400 irq: 300583 ReSched: 92
[  477.440000] Loop: 835403 irq: 300583 ReSched: 93
[  477.440000] Loop: 835406 irq: 300583 ReSched: 94
[  477.440000] Loop: 835407 irq: 300583 ReSched: 95
[  477.440000] Loop: 835408 irq: 300583 ReSched: 96
[  477.440000] Loop: 835409 irq: 300583 ReSched: 97
[  477.440000] Loop: 835410 irq: 300583 ReSched: 98
[  477.440000] Loop: 835411 irq: 300583 ReSched: 99
[  477.440000] Loop: 835412 irq: 300583 ReSched: 100
[  477.440000] Loop: 835413 irq: 300583 ReSched: 101
[  477.440000] Loop: 835414 irq: 300583 ReSched: 102
[  477.440000] Loop: 835415 irq: 300583 ReSched: 103
[  477.440000] Loop: 835416 irq: 300583 ReSched: 104
[  477.440000] Loop: 835417 irq: 300583 ReSched: 105
[  477.440000] Loop: 835418 irq: 300583 ReSched: 106
[  477.440000] Loop: 835419 irq: 300583 ReSched: 107
[  477.440000] Loop: 835420 irq: 300583 ReSched: 108
[  477.440000] Loop: 835421 irq: 300583 ReSched: 109
[  477.440000] Loop: 835422 irq: 300583 ReSched: 110
[  477.440000] Loop: 835423 irq: 300583 ReSched: 111
[  477.440000] Loop: 835424 irq: 300583 ReSched: 112
[  477.440000] Loop: 835425 irq: 300583 ReSched: 113
[  477.440000] Loop: 835426 irq: 300583 ReSched: 114
[  477.440000] Loop: 835427 irq: 300583 ReSched: 115
[  477.440000] Loop: 835428 irq: 300583 ReSched: 116
[  477.440000] Loop: 835429 irq: 300583 ReSched: 117
[  477.440000] Loop: 835430 irq: 300583 ReSched: 118
[  477.440000] Loop: 835431 irq: 300583 ReSched: 119
[  477.440000] Loop: 835432 irq: 300583 ReSched: 120
[  477.440000] Loop: 835433 irq: 300583 ReSched: 121
[  477.440000] Loop: 835434 irq: 300583 ReSched: 122
[  477.440000] Loop: 835435 irq: 300583 ReSched: 123
[  477.440000] Loop: 835436 irq: 300583 ReSched: 124
[  477.440000] Loop: 835437 irq: 300583 ReSched: 125
[  477.440000] Loop: 835438 irq: 300583 ReSched: 126
[  477.440000] Loop: 835439 irq: 300583 ReSched: 127
[  477.440000] Loop: 835440 irq: 300583 ReSched: 128
[  477.440000] Loop: 835441 irq: 300583 ReSched: 129
[  477.440000] Loop: 835442 irq: 300583 ReSched: 130
[  477.440000] Loop: 835443 irq: 300583 ReSched: 131
[  477.440000] Loop: 835444 irq: 300583 ReSched: 132
[  477.440000] Loop: 835445 irq: 300583 ReSched: 133
[  477.440000] Loop: 835446 irq: 300583 ReSched: 134
[  477.440000] Loop: 835447 irq: 300583 ReSched: 135
[  477.440000] Loop: 835448 irq: 300583 ReSched: 136
[  477.440000] Loop: 835449 irq: 300583 ReSched: 137
[  477.440000] Loop: 835450 irq: 300583 ReSched: 138
[  477.450000] Loop: 835451 irq: 300583 ReSched: 139
[  477.450000] Loop: 835452 irq: 300583 ReSched: 140
[  477.450000] Loop: 835453 irq: 300583 ReSched: 141
[  477.450000] Loop: 835454 irq: 300583 ReSched: 142
[  477.450000] Loop: 835455 irq: 300583 ReSched: 143
[  477.450000] Loop: 835456 irq: 300583 ReSched: 144
[  477.450000] Loop: 835457 irq: 300583 ReSched: 145
[  477.450000] Loop: 835458 irq: 300583 ReSched: 146
[  477.450000] Loop: 835459 irq: 300583 ReSched: 147
[  477.450000] Loop: 835460 irq: 300583 ReSched: 148
[  477.450000] Loop: 835461 irq: 300583 ReSched: 149
[  477.450000] Loop: 835462 irq: 300583 ReSched: 150
[  477.450000] Loop: 835463 irq: 300583 ReSched: 151
[  477.450000] Loop: 835464 irq: 300583 ReSched: 152
[  477.450000] Loop: 835465 irq: 300583 ReSched: 153
[  477.450000] Loop: 835466 irq: 300583 ReSched: 154
[  477.450000] Loop: 835467 irq: 300583 ReSched: 155
[  477.450000] Loop: 835468 irq: 300583 ReSched: 156
[  477.450000] Loop: 835469 irq: 300583 ReSched: 157
[  477.450000] Loop: 835470 irq: 300583 ReSched: 158
[  477.450000] Loop: 835472 irq: 300583 ReSched: 159
[  477.450000] Loop: 835473 irq: 300583 ReSched: 160
[  477.450000] Loop: 835474 irq: 300583 ReSched: 161
[  477.450000] Loop: 835475 irq: 300583 ReSched: 162
[  477.450000] Loop: 835476 irq: 300583 ReSched: 163
[  477.450000] Loop: 835477 irq: 300583 ReSched: 164
[  477.450000] Loop: 835478 irq: 300583 ReSched: 165
[  477.450000] Loop: 835479 irq: 300583 ReSched: 166
[  477.450000] Loop: 835480 irq: 300583 ReSched: 167
[  477.450000] Loop: 835481 irq: 300583 ReSched: 168
[  477.450000] Loop: 835482 irq: 300583 ReSched: 169
[  477.450000] Loop: 835483 irq: 300583 ReSched: 170
[  477.450000] Loop: 835484 irq: 300583 ReSched: 171
[  477.450000] Loop: 835485 irq: 300583 ReSched: 172
[  477.450000] Loop: 835486 irq: 300583 ReSched: 173
[  477.450000] Loop: 835487 irq: 300583 ReSched: 174
[  477.450000] Loop: 835488 irq: 300583 ReSched: 175
[  477.450000] Loop: 835489 irq: 300583 ReSched: 176
[  477.450000] Loop: 835490 irq: 300583 ReSched: 177
[  477.450000] Loop: 835491 irq: 300583 ReSched: 178
[  477.450000] Loop: 835492 irq: 300583 ReSched: 179
[  477.450000] Loop: 835493 irq: 300583 ReSched: 180
[  477.450000] Loop: 835494 irq: 300583 ReSched: 181
[  477.450000] Loop: 835495 irq: 300583 ReSched: 182
[  477.450000] Loop: 835496 irq: 300583 ReSched: 183
[  477.450000] Loop: 835497 irq: 300583 ReSched: 184
[  477.450000] Loop: 835498 irq: 300583 ReSched: 185
[  477.450000] Loop: 835499 irq: 300583 ReSched: 186
[  477.450000] Loop: 835500 irq: 300583 ReSched: 187
[  477.450000] Loop: 835501 irq: 300583 ReSched: 188
[  477.450000] Loop: 835502 irq: 300583 ReSched: 189
[  477.450000] Loop: 835503 irq: 300583 ReSched: 190
[  477.450000] Loop: 835504 irq: 300583 ReSched: 191
[  477.450000] Loop: 835505 irq: 300583 ReSched: 192
[  477.450000] Loop: 835506 irq: 300583 ReSched: 193
[  477.450000] Loop: 835507 irq: 300583 ReSched: 194
[  477.450000] Loop: 835508 irq: 300583 ReSched: 195
[  477.450000] Loop: 835509 irq: 300583 ReSched: 196
[  477.450000] Loop: 835510 irq: 300583 ReSched: 197
[  477.450000] Loop: 835511 irq: 300583 ReSched: 198
[  477.450000] Loop: 835512 irq: 300583 ReSched: 199
[  477.450000] Loop: 835513 irq: 300583 ReSched: 200
[  477.450000] Loop: 835514 irq: 300583 ReSched: 201
[  477.450000] Loop: 835515 irq: 300583 ReSched: 202
[  477.450000] Loop: 835516 irq: 300583 ReSched: 203
[  477.450000] Loop: 835517 irq: 300583 ReSched: 204
[  477.450000] Loop: 835518 irq: 300583 ReSched: 205
[  477.450000] Loop: 835519 irq: 300583 ReSched: 206
[  477.450000] Loop: 835520 irq: 300583 ReSched: 207
[  477.450000] Loop: 835521 irq: 300583 ReSched: 208
[  477.450000] Loop: 835522 irq: 300583 ReSched: 209
[  477.450000] Loop: 835523 irq: 300583 ReSched: 210
[  477.450000] Loop: 835524 irq: 300583 ReSched: 211
[  477.450000] Loop: 835525 irq: 300583 ReSched: 212
[  477.450000] Loop: 835526 irq: 300583 ReSched: 213
[  477.450000] Loop: 835527 irq: 300583 ReSched: 214
[  477.450000] Loop: 835528 irq: 300583 ReSched: 215
[  477.450000] Loop: 835529 irq: 300583 ReSched: 216
[  477.450000] Loop: 835530 irq: 300583 ReSched: 217
[  478.450000] Loop: 835534 irq: 300584 ReSched: 218
[  478.460000] Loop: 835536 irq: 300585 ReSched: 219
[  478.470000] Loop: 835538 irq: 300586 ReSched: 220
[  478.470000] Loop: 835539 irq: 300586 ReSched: 221
[  478.500000] Loop: 835983 irq: 300586 ReSched: 622
...
[  478.510000] Loop: 836072 irq: 300586 ReSched: 697
[  478.510000] Loop: 836073 irq: 300586 ReSched: 698
[  478.510000] Loop: 836074 irq: 300586 ReSched: 699
[  478.510000] Loop: 836075 irq: 300586 ReSched: 700
[  478.510000] Loop: 836076 irq: 300586 ReSched: 701
[  478.510000] Loop: 836077 irq: 300586 ReSched: 702
[  478.510000] Loop: 836078 irq: 300586 ReSched: 703
[  478.510000] Loop: 836079 irq: 300586 ReSched: 704
[  478.510000] Loop: 836080 irq: 300586 ReSched: 705
[  478.510000] Loop: 836081 irq: 300586 ReSched: 706
[  478.510000] Loop: 836082 irq: 300586 ReSched: 707
[  478.510000] Loop: 836083 irq: 300586 ReSched: 708
[  478.510000] Loop: 836084 irq: 300586 ReSched: 709
[  478.510000] Loop: 836085 irq: 300586 ReSched: 710
[  478.510000] Loop: 836086 irq: 300586 ReSched: 711
[  478.510000] Loop: 836087 irq: 300586 ReSched: 712
[  478.510000] Loop: 836088 irq: 300586 ReSched: 713
[  478.510000] Loop: 836089 irq: 300586 ReSched: 714
[  478.510000] Loop: 836090 irq: 300586 ReSched: 715
[  478.510000] Loop: 836091 irq: 300586 ReSched: 716
[  478.510000] Loop: 836092 irq: 300586 ReSched: 717
[  478.510000] Loop: 836093 irq: 300586 ReSched: 718
[  478.510000] Loop: 836094 irq: 300586 ReSched: 719
[  478.510000] Loop: 836095 irq: 300586 ReSched: 720
[  478.510000] Loop: 836096 irq: 300586 ReSched: 721
[  478.510000] Loop: 836097 irq: 300586 ReSched: 722
[  478.510000] Loop: 836098 irq: 300586 ReSched: 723
[  478.510000] Loop: 836099 irq: 300586 ReSched: 724
[  478.510000] Loop: 836100 irq: 300586 ReSched: 725
[  478.510000] Loop: 836101 irq: 300586 ReSched: 726
[  478.510000] Loop: 836102 irq: 300586 ReSched: 727
[  478.510000] Loop: 836103 irq: 300586 ReSched: 728
[  478.510000] Loop: 836104 irq: 300586 ReSched: 729
[  478.510000] Loop: 836105 irq: 300586 ReSched: 730
[  478.510000] Loop: 836106 irq: 300586 ReSched: 731
[  478.510000] Loop: 836107 irq: 300586 ReSched: 732
[  478.510000] Loop: 836108 irq: 300586 ReSched: 733
[  478.510000] Loop: 836109 irq: 300586 ReSched: 734
[  478.510000] Loop: 836110 irq: 300586 ReSched: 735
[  478.510000] Loop: 836111 irq: 300586 ReSched: 736
[  478.510000] Loop: 836112 irq: 300586 ReSched: 737
[  478.510000] Loop: 836113 irq: 300586 ReSched: 738
[  478.510000] Loop: 836114 irq: 300586 ReSched: 739
[  478.510000] Loop: 836115 irq: 300586 ReSched: 740
[  478.510000] Loop: 836116 irq: 300586 ReSched: 741
[  478.510000] Loop: 836117 irq: 300586 ReSched: 742
[  478.510000] Loop: 836118 irq: 300586 ReSched: 743
[  478.510000] Loop: 836119 irq: 300586 ReSched: 744
[  478.510000] Loop: 836120 irq: 300586 ReSched: 745
[  478.510000] Loop: 836121 irq: 300586 ReSched: 746
[  478.510000] Loop: 836122 irq: 300586 ReSched: 747
[  478.510000] Loop: 836123 irq: 300586 ReSched: 748
[  478.510000] Loop: 836124 irq: 300586 ReSched: 749
[  478.510000] Loop: 836125 irq: 300586 ReSched: 750
[  478.510000] Loop: 836126 irq: 300586 ReSched: 751
[  478.510000] Loop: 836127 irq: 300586 ReSched: 752
[  478.510000] Loop: 836128 irq: 300586 ReSched: 753
[  478.510000] Loop: 836129 irq: 300586 ReSched: 754
[  478.510000] Loop: 836130 irq: 300586 ReSched: 755
[  478.510000] Loop: 836131 irq: 300586 ReSched: 756
[  478.510000] Loop: 836132 irq: 300586 ReSched: 757
[  478.510000] Loop: 836133 irq: 300586 ReSched: 758
[  478.510000] Loop: 836134 irq: 300586 ReSched: 759


Koen

On 2016-06-13 20:17, Tim Harvey wrote:
> On Mon, Jun 13, 2016 at 9:12 AM, Koen Vandeputte
> <koen.vandeputte at ncentric.com> wrote:
>> Hi All,
>>
>> There seems to be a bug in the function eth_poll() in this driver
>>
>> When the RX ring gets full once, the re-schedule is called forever, even
>> when the ring is empty afterwards.
>>
>>
>>      if (!received) {
>>          napi_complete(napi);
>>          enable_irq(sw->rx_irq);
>>          budget = 0;
>>
>>          /* if rx descriptors are full schedule another poll */
>>          if (rx_ring->desc[(i-1) & (RX_DESCS-1)].cown)
>>          {
>>              eth_schedule_poll(sw);    <----  Gets called on each function
>> entry
>>          }
>>      }
>>
>>
>> This causes SoftIRQ to fully load a core forever.
>>
>>
>> I didn't fix it yet, but should I be the first, i'll supply a patch ..
>>
> Koen,
>
> We have seen this before, but admittedly don't understand why we enter
> into the same condition on each subsequent call to eth_poll(). The
> check is to catch the condition described as irq rot [1] and is to
> catch the case where after processing the full budget, we are
> immediately full again (a situation which is easily re-producible with
> a flood-ping). If this occurs we will no longer get an rx interrupt
> (because the descriptors are full) and our napi function will never
> get called again (unless transmitting packets).
>
> What is your proposed patch?
>
> Tim
>
> 1 .http://www.linuxfoundation.org/collaborate/workgroups/networking/napi#IRQ_race_a.k.a_rotting_packet



From david at lang.hm  Tue Jun 14 10:21:06 2016
From: david at lang.hm (David Lang)
Date: Tue, 14 Jun 2016 10:21:06 -0700 (PDT)
Subject: [LEDE-DEV] [PATCH] base-files: seed /dev/urandom
In-Reply-To: <CAOdf3gqgY1p33uP+UDrMZgjujiLhKp4os82zP8eb0n51Je5nAA@mail.gmail.com>
References: <1465627075-13683-1-git-send-email-champetier.etienne@gmail.com>
 <d16a674b-f1f0-67cb-ec02-c40804ed5a83@nbd.name>
 <CAOdf3gq8Yx6M1nUZrOBog-2ziaqP-F1qpapFf1=32XtuVaDYWg@mail.gmail.com>
 <eb1f3f1b-3d2f-f406-9dec-4a45c6c0ea00@phrozen.org>
 <CAOdf3grPLYAgyqzA8Er-Jw+jEjJxZYJkTEXrvJDLiD6rsYtpnw@mail.gmail.com>
 <3e6b2474-7096-fda5-db0a-6351d2f6be9c@nbd.name>
 <CAOdf3gqgY1p33uP+UDrMZgjujiLhKp4os82zP8eb0n51Je5nAA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1606141020080.24139@nftneq.ynat.uz>

On Tue, 14 Jun 2016, Etienne Champetier wrote:

> 2016-06-14 9:08 GMT+02:00 Felix Fietkau <nbd at nbd.name>:
>> On 2016-06-13 22:10, Etienne Champetier wrote:
>>> Hi John, Felix,
>>>
>>> 2016-06-13 13:55 GMT+02:00 John Crispin <john at phrozen.org>:
>>>>
>>>>
>>>> On 13/06/2016 00:56, Etienne Champetier wrote:
>>>>> Hi Felix,
>>>>>
>>>>> 2016-06-12 12:45 GMT+02:00 Felix Fietkau <nbd at nbd.name>:
>>>>>> On 2016-06-11 08:37, Etienne CHAMPETIER wrote:
>>>>
>>>> lets add a system.system.write_state_to_flash_on_boot=0/1 uci option and
>>>> lock this and the dnssec time stuff with it and default it to 0
>>>
>>> Security can't be opt in !
>>> When you see "random: ubus urandom read with 4 bits of entropy
>>> available" let's hope it's not security sensitive, because 2^4 will
>>> not take a lot of time to bruteforce...
>> First of all, the kernel entropy estimation is *really* pessimistic, so
>> there will be a lot more random bits at this point than just 4.
>>
>>> Before we try to minimize writes, how much writes are we talking about?
>>> my openwrt routers have multiple months of uptime, and even if we get
>>> down to 1 week, that gets us to 53 writes a year.
>>> How much writes can a flash handle these days?
>> I'm more concerned about the worst case than the average case here.
>> There are people that do a forced reboot every day (as a stability
>> workaround), or only power up their devices during specific times of the
>> day (multiple reboots per day). This can easily add up to bigger numbers.
>>
>> Also, adding something like this makes other people want to add even
>> more stuff that writes to flash on every boot, as you've so clearly
>> demonstrated by pointing out that this behavior are already done for
>> dnssec/dnsmasq.
>
> Ok, let's find a middle ground :)
> What about saving a seed if there is none (on boot), and then using an
> ntp hotplug (stratum event) and save a new seed if older than say 1
> week?

The worst thing that you can do is to use the same seed on multiple boots.

David Lang


From champetier.etienne at gmail.com  Tue Jun 14 10:37:08 2016
From: champetier.etienne at gmail.com (Etienne Champetier)
Date: Tue, 14 Jun 2016 20:37:08 +0300
Subject: [LEDE-DEV] [PATCH] base-files: seed /dev/urandom
In-Reply-To: <alpine.DEB.2.02.1606141020080.24139@nftneq.ynat.uz>
References: <1465627075-13683-1-git-send-email-champetier.etienne@gmail.com>
 <d16a674b-f1f0-67cb-ec02-c40804ed5a83@nbd.name>
 <CAOdf3gq8Yx6M1nUZrOBog-2ziaqP-F1qpapFf1=32XtuVaDYWg@mail.gmail.com>
 <eb1f3f1b-3d2f-f406-9dec-4a45c6c0ea00@phrozen.org>
 <CAOdf3grPLYAgyqzA8Er-Jw+jEjJxZYJkTEXrvJDLiD6rsYtpnw@mail.gmail.com>
 <3e6b2474-7096-fda5-db0a-6351d2f6be9c@nbd.name>
 <CAOdf3gqgY1p33uP+UDrMZgjujiLhKp4os82zP8eb0n51Je5nAA@mail.gmail.com>
 <alpine.DEB.2.02.1606141020080.24139@nftneq.ynat.uz>
Message-ID: <CAOdf3gqoWNZF8D0g5Q08QQryU+k6_+gCBFfKKvX82GEbeKAXHQ@mail.gmail.com>

Hi David,

2016-06-14 20:21 GMT+03:00 David Lang <david at lang.hm>:
> On Tue, 14 Jun 2016, Etienne Champetier wrote:
>
>> 2016-06-14 9:08 GMT+02:00 Felix Fietkau <nbd at nbd.name>:
>>>
>>> On 2016-06-13 22:10, Etienne Champetier wrote:
>>>>
>>>> Hi John, Felix,
>>>>
>>>> 2016-06-13 13:55 GMT+02:00 John Crispin <john at phrozen.org>:
>>>>>
>>>>>
>>>>>
>>>>> On 13/06/2016 00:56, Etienne Champetier wrote:
>>>>>>
>>>>>> Hi Felix,
>>>>>>
>>>>>> 2016-06-12 12:45 GMT+02:00 Felix Fietkau <nbd at nbd.name>:
>>>>>>>
>>>>>>> On 2016-06-11 08:37, Etienne CHAMPETIER wrote:
>>>>>
>>>>>
>>>>> lets add a system.system.write_state_to_flash_on_boot=0/1 uci option
>>>>> and
>>>>> lock this and the dnssec time stuff with it and default it to 0
>>>>
>>>>
>>>> Security can't be opt in !
>>>> When you see "random: ubus urandom read with 4 bits of entropy
>>>> available" let's hope it's not security sensitive, because 2^4 will
>>>> not take a lot of time to bruteforce...
>>>
>>> First of all, the kernel entropy estimation is *really* pessimistic, so
>>> there will be a lot more random bits at this point than just 4.
>>>
>>>> Before we try to minimize writes, how much writes are we talking about?
>>>> my openwrt routers have multiple months of uptime, and even if we get
>>>> down to 1 week, that gets us to 53 writes a year.
>>>> How much writes can a flash handle these days?
>>>
>>> I'm more concerned about the worst case than the average case here.
>>> There are people that do a forced reboot every day (as a stability
>>> workaround), or only power up their devices during specific times of the
>>> day (multiple reboots per day). This can easily add up to bigger numbers.
>>>
>>> Also, adding something like this makes other people want to add even
>>> more stuff that writes to flash on every boot, as you've so clearly
>>> demonstrated by pointing out that this behavior are already done for
>>> dnssec/dnsmasq.
>>
>>
>> Ok, let's find a middle ground :)
>> What about saving a seed if there is none (on boot), and then using an
>> ntp hotplug (stratum event) and save a new seed if older than say 1
>> week?
>
>
> The worst thing that you can do is to use the same seed on multiple boots.

I agree that we should use a new seed each time,
but are you suggesting that using the same seed is worse than no seed?
Do you have some links to back your claim?

Seeding here is just writing 512 bytes from getrandom() back into
/dev/urandom, so this gets mixed with what's already available without
affecting entropy estimation

>
> David Lang


From david at lang.hm  Tue Jun 14 10:47:33 2016
From: david at lang.hm (David Lang)
Date: Tue, 14 Jun 2016 10:47:33 -0700 (PDT)
Subject: [LEDE-DEV] [PATCH] base-files: seed /dev/urandom
In-Reply-To: <1465876215.2580.44.camel@homehost>
References: <1465627075-13683-1-git-send-email-champetier.etienne@gmail.com>
 <d16a674b-f1f0-67cb-ec02-c40804ed5a83@nbd.name>
 <CAOdf3gq8Yx6M1nUZrOBog-2ziaqP-F1qpapFf1=32XtuVaDYWg@mail.gmail.com>
 <eb1f3f1b-3d2f-f406-9dec-4a45c6c0ea00@phrozen.org>
 <CAOdf3grPLYAgyqzA8Er-Jw+jEjJxZYJkTEXrvJDLiD6rsYtpnw@mail.gmail.com>
 <1465876215.2580.44.camel@homehost>
Message-ID: <alpine.DEB.2.02.1606141046140.2494@nftneq.ynat.uz>

On Mon, 13 Jun 2016, Daniel Curran-Dickinson wrote:

> On Mon, 2016-06-13 at 22:10 +0200, Etienne Champetier wrote:
>
>> Before we try to minimize writes, how much writes are we talking about?
>> my openwrt routers have multiple months of uptime, and even if we get
>> down to 1 week, that gets us to 53 writes a year.
>> How much writes can a flash handle these days?
>
> I'm told that even cheap wear-levelling and flash chips from 4-5 years
> ago with even 4 MB flash that it's really non-issue (and done the math
> for what would be the case if wear levelling worked as claimed, on all
> blocks, not just currently unwritten; the real question is whether
> wear-levelling works as claimed, or more to the point whether there is
> any *hard data* that says wear levelling does *not* work as claimed, or
> whether persistent anecdotal stories of worn out flash are based on
> urban legends, or classic mis-attribution).

Well, we don't have a layer that will implement wear leveling in OpenWRT/LEDE do 
we? We use the raw flash and the filesystem, so unless the filesystem is moving 
directories they will be hot spots.

But even in that case, aren't we talking hundreds of thousands to millions of 
writes before there is a problem?

David Lang


From david at lang.hm  Tue Jun 14 11:05:16 2016
From: david at lang.hm (David Lang)
Date: Tue, 14 Jun 2016 11:05:16 -0700 (PDT)
Subject: [LEDE-DEV] lede integration issues remaining from the detrius
 of cerowrt
In-Reply-To: <1465868455.2580.35.camel@homehost>
References: <CAA93jw7=bHNXJqmjWmg3CHHH-biua17wK4AHfn_wB0wPWs=EqQ@mail.gmail.com>
 <CAJOqq5TB4qki1iWHZd71kzXYoA=A3+4BeycoNPKqRXFWZ6bMZQ@mail.gmail.com>
 <f6898485-e1d4-ec35-4563-4591512d2d84@mein.io>
 <1465868455.2580.35.camel@homehost>
Message-ID: <alpine.DEB.2.02.1606141048400.2494@nftneq.ynat.uz>

On Mon, 13 Jun 2016, Daniel Curran-Dickinson wrote:

> On Mon, 2016-06-13 at 11:17 +0200, Jo-Philipp Wich wrote:
>> Hi,
>>
>> no need to overreact :)  I think parts of the topics are about the
>
> Hope you're referring to Pinney and not me!  I was concerned because
> Dave Taht's email and David Lang's post) seemed to me to imply changing the
> defaults to suit bigger iron as the default rather than simply making
> it a supported option.

I think you misunderstood our comments and concerns. We want the bigger hardware 
to be a supported option, and don't like the response that this initially got of 
"that's something only needed for bigger hardware, we shouldn't have it as an 
option in LEDE"

Both of us play with very small hardware as well, we don't want to close out the 
low end devices.

> I also think that talking about a 5-10 plan as
> the basis if making decision of what to include by default in *current* builds
> is rather foolish thinking.  Yes planning for the future is important but to
> it reminds of a quote from when I was religious: "Don't be so heavenly-minded
> you're no earthly good".  Basically here and now needs not to be forgotten in
> dreams of future wonders.

Agreed, but at the same time you shouldn't ignore support for the larger 
hardware.

Remember, this thread started with the request to support hard drives >2TB and 
the reaction was "we don't need that routers only have a few tens of KB of 
flash" (even though it turned out that the support has already been included)

<agreement on the need to support old/small hardware>
>
> To a certain extent though, I question the need for something as restricted as OpenWrt
> for the new bigger devices anyway; there are elements like netifd that would be good to
> see continue, but I'm not sure that most of OpenWrt really makes as much sense when you're
> not needing to squeeze maximum use out of very erase block, and that therefore, while it
> may be a smaller market/mindshare, that focussing on the the true embedded type scenario,
> seems to be more of what LEDE's niche is.

LEDE/OpenWRT is a good fit for any device that operates on raw flash instead of 
a hard drive or ssd with wear leveling. Once you have storage that you don't 
worry about wearing out and is large enough to hold a normal Linux Distro, it 
makes sense to move to such a distro and update packages individually.

But when you have a limited amount of boot/OS storage that does not have wear 
leveling in place, then the OpenWRT/LEDE approach of a complete filesystem image 
that gets updated as a whole still makes sense.

Even when we have a few Gb of flash storage available, we will still want to use 
compressed, read-only filesystems for the main OS packages.

David Lang


From arjen+lede at de-korte.org  Tue Jun 14 11:11:53 2016
From: arjen+lede at de-korte.org (Arjen de Korte)
Date: Tue, 14 Jun 2016 20:11:53 +0200
Subject: [LEDE-DEV] [PATCH] base-files: seed /dev/urandom
In-Reply-To: <alpine.DEB.2.02.1606141046140.2494@nftneq.ynat.uz>
References: <1465627075-13683-1-git-send-email-champetier.etienne@gmail.com>
 <d16a674b-f1f0-67cb-ec02-c40804ed5a83@nbd.name>
 <CAOdf3gq8Yx6M1nUZrOBog-2ziaqP-F1qpapFf1=32XtuVaDYWg@mail.gmail.com>
 <eb1f3f1b-3d2f-f406-9dec-4a45c6c0ea00@phrozen.org>
 <CAOdf3grPLYAgyqzA8Er-Jw+jEjJxZYJkTEXrvJDLiD6rsYtpnw@mail.gmail.com>
 <1465876215.2580.44.camel@homehost>
 <alpine.DEB.2.02.1606141046140.2494@nftneq.ynat.uz>
Message-ID: <20160614201153.Horde.b-1nxX6RZMBjydGH47QtLeS@mail.de-korte.org>

Citeren David Lang <david at lang.hm>:

> On Mon, 13 Jun 2016, Daniel Curran-Dickinson wrote:
>
>> On Mon, 2016-06-13 at 22:10 +0200, Etienne Champetier wrote:
>>
>>> Before we try to minimize writes, how much writes are we talking about?
>>> my openwrt routers have multiple months of uptime, and even if we get
>>> down to 1 week, that gets us to 53 writes a year.
>>> How much writes can a flash handle these days?
>>
>> I'm told that even cheap wear-levelling and flash chips from 4-5 years
>> ago with even 4 MB flash that it's really non-issue (and done the math
>> for what would be the case if wear levelling worked as claimed, on all
>> blocks, not just currently unwritten; the real question is whether
>> wear-levelling works as claimed, or more to the point whether there is
>> any *hard data* that says wear levelling does *not* work as claimed, or
>> whether persistent anecdotal stories of worn out flash are based on
>> urban legends, or classic mis-attribution).
>
> Well, we don't have a layer that will implement wear leveling in  
> OpenWRT/LEDE do we? We use the raw flash and the filesystem, so  
> unless the filesystem is moving directories they will be hot spots.

Indeed.

> But even in that case, aren't we talking hundreds of thousands to  
> millions of writes before there is a problem?

Not really. Assuming NOR flash (which is most common in the 4-16 MB  
range), write endurance is usually typically something in the order of  
100.000 times or more. It's the drop in retention time that worries  
me. See

https://www.micron.com/~/media/documents/products/technical-note/nor-flash/tn1230_nor_flash_cycling_endurance_data_retention.pdf

At a temperature of 55 degrees C or above, retention times can be in  
the order of 1 year (or less) for flash that is written a lot. You  
should always keep writes to a minumum (< 1000). On the other hand, if  
writing to flash once every boot is will be an issue, you have bigger  
problems to worry about.

Arjen



From david at lang.hm  Tue Jun 14 11:15:55 2016
From: david at lang.hm (David Lang)
Date: Tue, 14 Jun 2016 11:15:55 -0700 (PDT)
Subject: [LEDE-DEV] [PATCH] base-files: seed /dev/urandom
In-Reply-To: <CAOdf3gqoWNZF8D0g5Q08QQryU+k6_+gCBFfKKvX82GEbeKAXHQ@mail.gmail.com>
References: <1465627075-13683-1-git-send-email-champetier.etienne@gmail.com>
 <d16a674b-f1f0-67cb-ec02-c40804ed5a83@nbd.name>
 <CAOdf3gq8Yx6M1nUZrOBog-2ziaqP-F1qpapFf1=32XtuVaDYWg@mail.gmail.com>
 <eb1f3f1b-3d2f-f406-9dec-4a45c6c0ea00@phrozen.org>
 <CAOdf3grPLYAgyqzA8Er-Jw+jEjJxZYJkTEXrvJDLiD6rsYtpnw@mail.gmail.com>
 <3e6b2474-7096-fda5-db0a-6351d2f6be9c@nbd.name>
 <CAOdf3gqgY1p33uP+UDrMZgjujiLhKp4os82zP8eb0n51Je5nAA@mail.gmail.com>
 <alpine.DEB.2.02.1606141020080.24139@nftneq.ynat.uz>
 <CAOdf3gqoWNZF8D0g5Q08QQryU+k6_+gCBFfKKvX82GEbeKAXHQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1606141105360.2494@nftneq.ynat.uz>

On Tue, 14 Jun 2016, Etienne Champetier wrote:

> Hi David,
>
> 2016-06-14 20:21 GMT+03:00 David Lang <david at lang.hm>:
>> On Tue, 14 Jun 2016, Etienne Champetier wrote:
>>
>>> 2016-06-14 9:08 GMT+02:00 Felix Fietkau <nbd at nbd.name>:
>>>>
>>>> On 2016-06-13 22:10, Etienne Champetier wrote:
>>>>>
>>>>> Hi John, Felix,
>>>>>
>>>>> 2016-06-13 13:55 GMT+02:00 John Crispin <john at phrozen.org>:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 13/06/2016 00:56, Etienne Champetier wrote:
>>>>>>>
>>>>>>> Hi Felix,
>>>>>>>
>>>>>>> 2016-06-12 12:45 GMT+02:00 Felix Fietkau <nbd at nbd.name>:
>>>>>>>>
>>>>>>>> On 2016-06-11 08:37, Etienne CHAMPETIER wrote:
>>>>>>
>>>>>>
>>>>>> lets add a system.system.write_state_to_flash_on_boot=0/1 uci option
>>>>>> and
>>>>>> lock this and the dnssec time stuff with it and default it to 0
>>>>>
>>>>>
>>>>> Security can't be opt in !
>>>>> When you see "random: ubus urandom read with 4 bits of entropy
>>>>> available" let's hope it's not security sensitive, because 2^4 will
>>>>> not take a lot of time to bruteforce...
>>>>
>>>> First of all, the kernel entropy estimation is *really* pessimistic, so
>>>> there will be a lot more random bits at this point than just 4.
>>>>
>>>>> Before we try to minimize writes, how much writes are we talking about?
>>>>> my openwrt routers have multiple months of uptime, and even if we get
>>>>> down to 1 week, that gets us to 53 writes a year.
>>>>> How much writes can a flash handle these days?
>>>>
>>>> I'm more concerned about the worst case than the average case here.
>>>> There are people that do a forced reboot every day (as a stability
>>>> workaround), or only power up their devices during specific times of the
>>>> day (multiple reboots per day). This can easily add up to bigger numbers.
>>>>
>>>> Also, adding something like this makes other people want to add even
>>>> more stuff that writes to flash on every boot, as you've so clearly
>>>> demonstrated by pointing out that this behavior are already done for
>>>> dnssec/dnsmasq.
>>>
>>>
>>> Ok, let's find a middle ground :)
>>> What about saving a seed if there is none (on boot), and then using an
>>> ntp hotplug (stratum event) and save a new seed if older than say 1
>>> week?
>>
>>
>> The worst thing that you can do is to use the same seed on multiple boots.
>
> I agree that we should use a new seed each time,
> but are you suggesting that using the same seed is worse than no seed?

I would argue that from a technical point of view that the difference between 
using no seed and using the same seed for a week or so at a time is so small as 
to be almost meaningless in practice.

>From a Social point of view, adding such a thing in is a net negative because it 
gives a false sense of security and encourages others to fall into the same 
trap.

Doing this at first boot (once sufficiant randomness is available) so that not 
every device out there with the same build starts out with an identical pool, 
but beyond that, either do it every boot or don't bother.

> Do you have some links to back your claim?

google for "security theater" and you will find lots of discussion about the 
problems of things that people do to feel safer that end up being net negative.

> Seeding here is just writing 512 bytes from getrandom() back into
> /dev/urandom, so this gets mixed with what's already available without
> affecting entropy estimation

and even if this is written out hourly (by a system frequently rebooting), 
hitting a very conservative 100,000 writes would take 11 years.

If you haven't been following it, it's worth going back and reading the 
discussion on urandom that has been taking place on the kernel mailing list over 
the last couple of months. There is a re-work of urandom planned to go into the 
next release, specifically targeting OpenWRT/LEDE type devices.

David Lang


From drew at nixcores.com  Tue Jun 14 11:56:55 2016
From: drew at nixcores.com (Drew from NixCore)
Date: Tue, 14 Jun 2016 14:56:55 -0400
Subject: [LEDE-DEV] [PATCH] [ramips] Added NixCore X1 target V3
In-Reply-To: <e0469793-f5a6-fe81-a047-ce4ed9ab45cb@phrozen.org>
References: <5759C4EB.5080203@nixcores.com>
 <zgYTGkNqNXAsBg4LZWbgrWX87g4XN49vqurgh8zI2120@mailpile>
 <5759E16C.1080904@nixcores.com>
 <e0469793-f5a6-fe81-a047-ce4ed9ab45cb@phrozen.org>
Message-ID: <57605377.2000106@nixcores.com>

John,

I originally was working on a git clone of the repo master branch from 
June 5th.  https://github.com/nixcore/lede-fork1 Rather than do a git 
pull request I just generated the patch for the mailing list. I've 
applied the same patch (via git apply) to the current HEAD of source.git 
repo and while there appear to be some whitespace warnings the patch 
applies correctly from the .patch file.  Maybe the formatting got messed 
up in the submit.

Drew

On 06/10/2016 02:38 AM, John Crispin wrote:
>
> On 09/06/2016 23:36, Drew from NixCore wrote:
>> I have no problem with a common dtsi, can I get these changes in first
>> and then do the dtsi as I continue work?
>>
>> Drew
>>
>> On 06/09/2016 03:12 PM, Karl Palsson wrote:
>>> If the 8 and 16 meg files only differ in their memory, should
>>> they perhaps just have a common .dtsi file for them both? instead
>>> of duplicating the entire dts? I've snipped the only differences
>>> between them below...
>>>
>>> Sincerely,
>>> Karl P
>>>
>>>
>>> Drew from NixCore <drew at nixcores.com> wrote:
>>>> Added NixCore X1 ramips target http://nixcores.com. This builds
>>>> 8M and 16M images. V3 updates the dts to support LEDE updated
>>>> format
> Hi Drew,
>
> i just wanted to fix the dtsi stuff myself however the patch is
> whitespace broken and does not apply. i went on to manually fix the
> whitespace breakage to find that you did not generate this patch against
> our latest source.git and that it wont apply.
>
> which tree at what rev did you use to generate the patch ?
>
> 	John
>
>
>
>
>
>
>
>
>>>> Signed-off-by: Drew Gaylo <drew at nixcores.com>
>>>> diff --git
>>>> diff --git a/target/linux/ramips/dts/NIXCOREX1-16M.dts
>>>> b/target/linux/ramips/dts/NIXCOREX1-16M.dts new file mode
>>>> 100644 index 0000000..1e1a205
>>>> --- /dev/null
>>>> +++ b/target/linux/ramips/dts/NIXCOREX1-16M.dts
>>> snip
>>>
>>>> +        partition at 50000 {
>>>> +            label = "firmware";
>>>> +            reg = <0x50000 0xfb0000>;
>>>> +        };
>>>> +    };
>>>> +};
>>>> +
>>>> diff --git a/target/linux/ramips/dts/NIXCOREX1-8M.dts
>>>> b/target/linux/ramips/dts/NIXCOREX1-8M.dts new file mode 100644
>>>> index 0000000..c514860
>>>> --- /dev/null
>>>> +++ b/target/linux/ramips/dts/NIXCOREX1-8M.dts
>>> snip
>>>
>>>> +        partition at 50000 {
>>>> +            label = "firmware";
>>>> +            reg = <0x50000 0x7b0000>;
>>>> +        };
>>>> +    };
>>>> +};
>>>> +
>>>>
>>>>
>>>> _______________________________________________
>>>> Lede-dev mailing list
>>>> Lede-dev at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev



From champetier.etienne at gmail.com  Tue Jun 14 13:14:24 2016
From: champetier.etienne at gmail.com (Etienne Champetier)
Date: Tue, 14 Jun 2016 23:14:24 +0300
Subject: [LEDE-DEV] [PATCH] base-files: seed /dev/urandom
In-Reply-To: <alpine.DEB.2.02.1606141105360.2494@nftneq.ynat.uz>
References: <1465627075-13683-1-git-send-email-champetier.etienne@gmail.com>
 <d16a674b-f1f0-67cb-ec02-c40804ed5a83@nbd.name>
 <CAOdf3gq8Yx6M1nUZrOBog-2ziaqP-F1qpapFf1=32XtuVaDYWg@mail.gmail.com>
 <eb1f3f1b-3d2f-f406-9dec-4a45c6c0ea00@phrozen.org>
 <CAOdf3grPLYAgyqzA8Er-Jw+jEjJxZYJkTEXrvJDLiD6rsYtpnw@mail.gmail.com>
 <3e6b2474-7096-fda5-db0a-6351d2f6be9c@nbd.name>
 <CAOdf3gqgY1p33uP+UDrMZgjujiLhKp4os82zP8eb0n51Je5nAA@mail.gmail.com>
 <alpine.DEB.2.02.1606141020080.24139@nftneq.ynat.uz>
 <CAOdf3gqoWNZF8D0g5Q08QQryU+k6_+gCBFfKKvX82GEbeKAXHQ@mail.gmail.com>
 <alpine.DEB.2.02.1606141105360.2494@nftneq.ynat.uz>
Message-ID: <CAOdf3gqGyx_r8208N37y9TmEg82mnHL-wf0U4VyZAz1v-Gzs1w@mail.gmail.com>

2016-06-14 21:15 GMT+03:00 David Lang <david at lang.hm>:
> On Tue, 14 Jun 2016, Etienne Champetier wrote:
>
>> Hi David,
>>
>> 2016-06-14 20:21 GMT+03:00 David Lang <david at lang.hm>:
>>>
>>> On Tue, 14 Jun 2016, Etienne Champetier wrote:
>>>
>>>> 2016-06-14 9:08 GMT+02:00 Felix Fietkau <nbd at nbd.name>:
>>>>>
>>>>>
>>>>> On 2016-06-13 22:10, Etienne Champetier wrote:
>>>>>>
>>>>>>
>>>>>> Hi John, Felix,
>>>>>>
>>>>>> 2016-06-13 13:55 GMT+02:00 John Crispin <john at phrozen.org>:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 13/06/2016 00:56, Etienne Champetier wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi Felix,
>>>>>>>>
>>>>>>>> 2016-06-12 12:45 GMT+02:00 Felix Fietkau <nbd at nbd.name>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2016-06-11 08:37, Etienne CHAMPETIER wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> lets add a system.system.write_state_to_flash_on_boot=0/1 uci option
>>>>>>> and
>>>>>>> lock this and the dnssec time stuff with it and default it to 0
>>>>>>
>>>>>>
>>>>>>
>>>>>> Security can't be opt in !
>>>>>> When you see "random: ubus urandom read with 4 bits of entropy
>>>>>> available" let's hope it's not security sensitive, because 2^4 will
>>>>>> not take a lot of time to bruteforce...
>>>>>
>>>>>
>>>>> First of all, the kernel entropy estimation is *really* pessimistic, so
>>>>> there will be a lot more random bits at this point than just 4.
>>>>>
>>>>>> Before we try to minimize writes, how much writes are we talking
>>>>>> about?
>>>>>> my openwrt routers have multiple months of uptime, and even if we get
>>>>>> down to 1 week, that gets us to 53 writes a year.
>>>>>> How much writes can a flash handle these days?
>>>>>
>>>>>
>>>>> I'm more concerned about the worst case than the average case here.
>>>>> There are people that do a forced reboot every day (as a stability
>>>>> workaround), or only power up their devices during specific times of
>>>>> the
>>>>> day (multiple reboots per day). This can easily add up to bigger
>>>>> numbers.
>>>>>
>>>>> Also, adding something like this makes other people want to add even
>>>>> more stuff that writes to flash on every boot, as you've so clearly
>>>>> demonstrated by pointing out that this behavior are already done for
>>>>> dnssec/dnsmasq.
>>>>
>>>>
>>>>
>>>> Ok, let's find a middle ground :)
>>>> What about saving a seed if there is none (on boot), and then using an
>>>> ntp hotplug (stratum event) and save a new seed if older than say 1
>>>> week?
>>>
>>>
>>>
>>> The worst thing that you can do is to use the same seed on multiple
>>> boots.
>>
>>
>> I agree that we should use a new seed each time,
>> but are you suggesting that using the same seed is worse than no seed?
>
>
> I would argue that from a technical point of view that the difference
> between using no seed and using the same seed for a week or so at a time is
> so small as to be almost meaningless in practice.
>
> From a Social point of view, adding such a thing in is a net negative
> because it gives a false sense of security and encourages others to fall
> into the same trap.
>
> Doing this at first boot (once sufficiant randomness is available) so that
> not every device out there with the same build starts out with an identical
> pool, but beyond that, either do it every boot or don't bother.

I agree that giving false sense of security should be avoided.

>
>> Do you have some links to back your claim?
>
>
> google for "security theater" and you will find lots of discussion about the
> problems of things that people do to feel safer that end up being net
> negative.
>
>> Seeding here is just writing 512 bytes from getrandom() back into
>> /dev/urandom, so this gets mixed with what's already available without
>> affecting entropy estimation
>
>
> and even if this is written out hourly (by a system frequently rebooting),
> hitting a very conservative 100,000 writes would take 11 years.

Also agree...

Felix, John, is your nack on writing on every boot final?

>
> If you haven't been following it, it's worth going back and reading the
> discussion on urandom that has been taking place on the kernel mailing list
> over the last couple of months. There is a re-work of urandom planned to go
> into the next release, specifically targeting OpenWRT/LEDE type devices.

I just read the link you provided (thanks), not the previous
discussions (i will try to read it)

Etienne

>
> David Lang


From smithbone at gmail.com  Tue Jun 14 13:54:58 2016
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 14 Jun 2016 16:54:58 -0400
Subject: [LEDE-DEV] [Cerowrt-devel]  WRT1900ACS Testing
In-Reply-To: <CAA93jw6QAtWxGJsouztj0VgnrAjjhnW2TVmSmu933swjFGqq4g@mail.gmail.com>
References: <CAA93jw6QAtWxGJsouztj0VgnrAjjhnW2TVmSmu933swjFGqq4g@mail.gmail.com>
Message-ID: <57606F22.2060704@gmail.com>

On 05/20/2016 05:16 PM, Dave Taht wrote:
> We had found some pretty major performance problems on this hardware
> as of a few months ago. I am curious if they still exist? A whole
> bunch of benchmarks went by on the cerowrt-devel list, also.

Sorry I'm late on a response.  I've been buried with work lately and 
haven't been paying much attention to mailing lists.

> They were:
>
> 1) broken local ethernet network stack - running 4 copies of netperf
> against it - one would grab all the bandwidth and the other three
> barely even start or hang completely.

I confirmed your behavior on the 1900ACS using OpenWRT.  I opted for 
flent rrul_be and rrul tests rather than multiple netperfs though.

I'm happy to rejigger my build to be LEDE, rebuild, install, and run the 
test again.

> 2) No BQL in the ethernet driver

Dunno about this one.

> 3) Wifi was horribly overbuffered in general
> 4) Wifi would crash against flent's rrul test.

I certainly saw these behaviors as well but I've not run rrul against 
the WiFi in quite a while and I seem to remember a wireless firmware 
update happening since I last ran the test.

I'll re-run and see.

-- 
Richard A. Smith


From ldpinney at gmail.com  Tue Jun 14 14:01:36 2016
From: ldpinney at gmail.com (L. D. Pinney)
Date: Tue, 14 Jun 2016 16:01:36 -0500
Subject: [LEDE-DEV] [Cerowrt-devel] WRT1900ACS Testing
In-Reply-To: <57606F22.2060704@gmail.com>
References: <CAA93jw6QAtWxGJsouztj0VgnrAjjhnW2TVmSmu933swjFGqq4g@mail.gmail.com>
 <57606F22.2060704@gmail.com>
Message-ID: <CAJOqq5TAVgz3E9HftNuu-iN57QJwh4u_oyBo+0Gx=Y2nm8cZLQ@mail.gmail.com>

Yet another example of cross-posted DRIVEL

On Tue, Jun 14, 2016 at 3:54 PM, Richard Smith <smithbone at gmail.com> wrote:
> On 05/20/2016 05:16 PM, Dave Taht wrote:
>>
>> We had found some pretty major performance problems on this hardware
>> as of a few months ago. I am curious if they still exist? A whole
>> bunch of benchmarks went by on the cerowrt-devel list, also.
>
>
> Sorry I'm late on a response.  I've been buried with work lately and haven't
> been paying much attention to mailing lists.
>
>> They were:
>>
>> 1) broken local ethernet network stack - running 4 copies of netperf
>> against it - one would grab all the bandwidth and the other three
>> barely even start or hang completely.
>
>
> I confirmed your behavior on the 1900ACS using OpenWRT.  I opted for flent
> rrul_be and rrul tests rather than multiple netperfs though.
>
> I'm happy to rejigger my build to be LEDE, rebuild, install, and run the
> test again.
>
>> 2) No BQL in the ethernet driver
>
>
> Dunno about this one.
>
>> 3) Wifi was horribly overbuffered in general
>> 4) Wifi would crash against flent's rrul test.
>
>
> I certainly saw these behaviors as well but I've not run rrul against the
> WiFi in quite a while and I seem to remember a wireless firmware update
> happening since I last ran the test.
>
> I'll re-run and see.
>
> --
> Richard A. Smith
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


From lede at daniel.thecshore.com  Tue Jun 14 08:03:46 2016
From: lede at daniel.thecshore.com (Daniel Dickinson)
Date: Tue, 14 Jun 2016 11:03:46 -0400
Subject: [LEDE-DEV] Will be quite slowed down for a while
Message-ID: <1465916626.2580.61.camel@homehost>


Hi all,

Much to my regret I've had to, and will continue to have to for some
time, slow down on LEDE/package/luci contributions due to life getting
quite busy, for various reasons.

Regards,

Daniel





From rogerpueyo at rogerpueyo.com  Tue Jun 14 17:27:19 2016
From: rogerpueyo at rogerpueyo.com (Roger Pueyo Centelles)
Date: Wed, 15 Jun 2016 02:27:19 +0200
Subject: [LEDE-DEV] mqmaker witi board - battery
In-Reply-To: <79b80149-c569-3d1c-5e8b-9657e4a5491e@phrozen.org>
References: <79b80149-c569-3d1c-5e8b-9657e4a5491e@phrozen.org>
Message-ID: <4653d5fa-1bd8-3a14-96c7-82bbc9f10e87@rogerpueyo.com>


Hi John,

As of http://ftp.mqmaker.com/WiTi/Pictures/WiTi_front1.png and OpenWrt's 
wiki its a LIR1220, but I haven't tested it.

Roger

El 14/06/16 a les 08:55, John Crispin ha escrit:
> Hi,
>
> i have a mqmaker witi board on my desk and wanted to use it to very the
> RTC support and add functionality to procd that it will apply hw rtc
> time to the system after the early boot state.
>
> unfortunately there is no battery inserted into the slot. anyone know
> what kind of battery cell is needed ? is this a CR1130 ?
>
> 	John
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
>
>




From john at phrozen.org  Tue Jun 14 22:32:35 2016
From: john at phrozen.org (John Crispin)
Date: Wed, 15 Jun 2016 07:32:35 +0200
Subject: [LEDE-DEV] mqmaker witi board - battery
In-Reply-To: <4653d5fa-1bd8-3a14-96c7-82bbc9f10e87@rogerpueyo.com>
References: <79b80149-c569-3d1c-5e8b-9657e4a5491e@phrozen.org>
 <4653d5fa-1bd8-3a14-96c7-82bbc9f10e87@rogerpueyo.com>
Message-ID: <128aa4e4-adf9-a948-1703-76b4fad32d0a@phrozen.org>

Hi,

i have ordered a LIR1220. look slike they are 3,6V and the CR1220 are
only 3V.

lets hope it arrives soon.

	John

On 15/06/2016 02:27, Roger Pueyo Centelles wrote:
> 
> Hi John,
> 
> As of http://ftp.mqmaker.com/WiTi/Pictures/WiTi_front1.png and OpenWrt's
> wiki its a LIR1220, but I haven't tested it.
> 
> Roger
> 
> El 14/06/16 a les 08:55, John Crispin ha escrit:
>> Hi,
>>
>> i have a mqmaker witi board on my desk and wanted to use it to very the
>> RTC support and add functionality to procd that it will apply hw rtc
>> time to the system after the early boot state.
>>
>> unfortunately there is no battery inserted into the slot. anyone know
>> what kind of battery cell is needed ? is this a CR1130 ?
>>
>>     John
>>
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>
>>
> 
> 
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


From john at phrozen.org  Tue Jun 14 22:43:25 2016
From: john at phrozen.org (John Crispin)
Date: Wed, 15 Jun 2016 07:43:25 +0200
Subject: [LEDE-DEV] [PATCH] base-files: seed /dev/urandom
In-Reply-To: <CAOdf3gqGyx_r8208N37y9TmEg82mnHL-wf0U4VyZAz1v-Gzs1w@mail.gmail.com>
References: <1465627075-13683-1-git-send-email-champetier.etienne@gmail.com>
 <d16a674b-f1f0-67cb-ec02-c40804ed5a83@nbd.name>
 <CAOdf3gq8Yx6M1nUZrOBog-2ziaqP-F1qpapFf1=32XtuVaDYWg@mail.gmail.com>
 <eb1f3f1b-3d2f-f406-9dec-4a45c6c0ea00@phrozen.org>
 <CAOdf3grPLYAgyqzA8Er-Jw+jEjJxZYJkTEXrvJDLiD6rsYtpnw@mail.gmail.com>
 <3e6b2474-7096-fda5-db0a-6351d2f6be9c@nbd.name>
 <CAOdf3gqgY1p33uP+UDrMZgjujiLhKp4os82zP8eb0n51Je5nAA@mail.gmail.com>
 <alpine.DEB.2.02.1606141020080.24139@nftneq.ynat.uz>
 <CAOdf3gqoWNZF8D0g5Q08QQryU+k6_+gCBFfKKvX82GEbeKAXHQ@mail.gmail.com>
 <alpine.DEB.2.02.1606141105360.2494@nftneq.ynat.uz>
 <CAOdf3gqGyx_r8208N37y9TmEg82mnHL-wf0U4VyZAz1v-Gzs1w@mail.gmail.com>
Message-ID: <232d5350-57b3-d7e8-97b0-704727a5c6dd@phrozen.org>



On 14/06/2016 22:14, Etienne Champetier wrote:
> Felix, John, is your nack on writing on every boot final?

if there is an alternate way to do so then yes. as i said before, adding
a optin/out option should be possible. i always went by the rule that
writing a sector more than 1000 times should be avoided. i thin that is
called convergence and had to do with environmental temperatures. would
need to look it up and find a link. so even 2 boots/day would mean the
unit is dead after 2 years. please keep in mind that latest chips might
handle lots of writes but not everyone has a spanking new unit. lots of
people use 5-10 year old routers.

to be honest, this discussion span off topic a bit and i only marginally
followed it.


From john at phrozen.org  Wed Jun 15 00:28:24 2016
From: john at phrozen.org (John Crispin)
Date: Wed, 15 Jun 2016 09:28:24 +0200
Subject: [LEDE-DEV] looking for au1000 testers
Message-ID: <805771a0-2cc0-4522-5af0-8284ce097e82@phrozen.org>

Hi,

the au1000 fails to boot properly with v4.4

we need someone to pick up the maintainer ship and fix this issue. i
have no longer got any hw that can be used for testing. we need this
fixed for it to be part of the release.

	John


From john at phrozen.org  Wed Jun 15 00:29:31 2016
From: john at phrozen.org (John Crispin)
Date: Wed, 15 Jun 2016 09:29:31 +0200
Subject: [LEDE-DEV] looking for ar7 testers
Message-ID: <3031035b-004b-2cea-63ec-580fcfd83bab@phrozen.org>

Hi,

the ar7 boots with v4.4 but ethernet apparently passes no traffic and
atm is untested.

we need someone to pick up the maintainer ship and fix this issue. i
have no longer got any hw that can be used for testing. we need this
fixed for it to be part of the release.

	John


From i at conorogorman.net  Wed Jun 15 02:06:07 2016
From: i at conorogorman.net (Conor O'Gorman)
Date: Wed, 15 Jun 2016 10:06:07 +0100
Subject: [LEDE-DEV] [PATCH v2 netifd 1/3] device: Fix device find
 failure in avl list due to device name change
In-Reply-To: <1465217913-20861-1-git-send-email-dedeckeh@gmail.com>
References: <1465217913-20861-1-git-send-email-dedeckeh@gmail.com>
Message-ID: <57611A7F.2060701@conorogorman.net>

On 06/06/16 13:58, Hans Dedecker wrote:
> diff --git a/vlan.c b/vlan.c
> index ac434ce..7f8697b 100644
> --- a/vlan.c
> +++ b/vlan.c
> @@ -63,8 +63,11 @@ static int vlan_set_device_state(struct device *dev, bool up)
>   
>   static void vlan_dev_set_name(struct vlan_device *vldev, struct device *dev)
>   {
> +	char name[IFNAMSIZ];
> +
>   	vldev->dev.hidden = dev->hidden;
> -	snprintf(vldev->dev.ifname, IFNAMSIZ, "%s.%d", dev->ifname, vldev->id);
> +	snprintf(name, IFNAMSIZ, "%s.%d", dev->ifname, vldev->id);
>
I'll be pedantic and mention that this is only one format for vlan 
device naming.
See VLAN_NAME_TYPE_*


From i at conorogorman.net  Wed Jun 15 02:39:54 2016
From: i at conorogorman.net (Conor O'Gorman)
Date: Wed, 15 Jun 2016 10:39:54 +0100
Subject: [LEDE-DEV] [PATCH] uloop: use a waker for notifying sigchld and
 loop cancel events
In-Reply-To: <1465438832-20133-1-git-send-email-yszhou4tech@gmail.com>
References: <1465438832-20133-1-git-send-email-yszhou4tech@gmail.com>
Message-ID: <5761226A.5070404@conorogorman.net>

On 09/06/16 03:20, Yousong Zhou wrote:
> Fix a race condition when do_sigchld, uloop_cancelled were set just
> before epoll_wait(timeout=-1), resulting the loop stuck in the syscall
> without noticing the events just happened
>
> Signed-off-by: Yousong Zhou <yszhou4tech at gmail.com>
> ---
>   uloop-epoll.c  |  2 +-
>   uloop-kqueue.c |  2 +-
>   uloop.c        | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++++++----
>   3 files changed, 63 insertions(+), 6 deletions(-)
>
Why not change the timeout?


From nbd at nbd.name  Wed Jun 15 02:58:04 2016
From: nbd at nbd.name (Felix Fietkau)
Date: Wed, 15 Jun 2016 11:58:04 +0200
Subject: [LEDE-DEV] [PATCH] uloop: use a waker for notifying sigchld and
 loop cancel events
In-Reply-To: <1465438832-20133-1-git-send-email-yszhou4tech@gmail.com>
References: <1465438832-20133-1-git-send-email-yszhou4tech@gmail.com>
Message-ID: <6c34a33b-422f-bc63-71ca-ab37e2b61956@nbd.name>

On 2016-06-09 04:20, Yousong Zhou wrote:
> Fix a race condition when do_sigchld, uloop_cancelled were set just
> before epoll_wait(timeout=-1), resulting the loop stuck in the syscall
> without noticing the events just happened
> 
> Signed-off-by: Yousong Zhou <yszhou4tech at gmail.com>
I found a few bugs and inconsistencies in that patch, and pushed a
fixed version here:
https://git.lede-project.org/?p=project/libubox.git;a=commitdiff;h=4e3a47a4cb438866bc4b9cb2f5d16226ffb48502

Please review and test it some more before I push an update to LEDE.

Thanks,

- Felix


From nbd at nbd.name  Wed Jun 15 02:58:55 2016
From: nbd at nbd.name (Felix Fietkau)
Date: Wed, 15 Jun 2016 11:58:55 +0200
Subject: [LEDE-DEV] [PATCH] uloop: use a waker for notifying sigchld and
 loop cancel events
In-Reply-To: <5761226A.5070404@conorogorman.net>
References: <1465438832-20133-1-git-send-email-yszhou4tech@gmail.com>
 <5761226A.5070404@conorogorman.net>
Message-ID: <f0d60d41-75a7-0cf5-2f37-ff0915d2b44f@nbd.name>

On 2016-06-15 11:39, Conor O'Gorman wrote:
> On 09/06/16 03:20, Yousong Zhou wrote:
>> Fix a race condition when do_sigchld, uloop_cancelled were set just
>> before epoll_wait(timeout=-1), resulting the loop stuck in the syscall
>> without noticing the events just happened
>>
>> Signed-off-by: Yousong Zhou <yszhou4tech at gmail.com>
>> ---
>>   uloop-epoll.c  |  2 +-
>>   uloop-kqueue.c |  2 +-
>>   uloop.c        | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++++++----
>>   3 files changed, 63 insertions(+), 6 deletions(-)
>>
> Why not change the timeout?
Changing the timeout would not fix the race, and it would lead to
unnecessary process wakeups and extra latency for signal processing.

- Felix


From joshbendavid at gmail.com  Wed Jun 15 03:33:29 2016
From: joshbendavid at gmail.com (Josh Bendavid)
Date: Wed, 15 Jun 2016 12:33:29 +0200
Subject: [LEDE-DEV] skb_warn_bad_offload + crash at high load on ipq806x
Message-ID: <CAD1MEwdz99Sjq66u+nsy+kmtAxPPPKnSR0fh3_h06CnKibZfww@mail.gmail.com>

Hi,
Testing with Tp-Link Archer C2600 (ipq806x) after latest changes (move
to 4.4 kernel + restore dma ethernet corruption fix), I have random
reboots on high wired network load.

Managed to get the kernel output during the crash below*.  Note that I
also had similar crashes with 3.18 kernel, but did not get the kernel
output from those to strictly confirm they are the same.

Not clear to me whether this is a platform specific issue, a more
general upstream bug, or something related to openwrt/lede patches.

*
Wed Jun 15 04:24:09 2016 kern.warn kernel: [  693.925294]
------------[ cut here ]------------
Wed Jun 15 04:24:09 2016 kern.warn kernel: [  693.925337] WARNING:
CPU: 0 PID: 3 at net/core/dev.c:2422 skb_warn_bad_offload+0xe4/0xf8()
Wed Jun 15 04:24:09 2016 kern.warn kernel: [  693.929065] br-lan:
caps=(0x000000801fd978a9, 0x0000000000000000) len=1500 data_len=0
gso_size=3426 gso_type=35530 ip_summed=1
Wed Jun 15 04:24:09 2016 kern.warn kernel: [  693.937164] Modules
linked in: pppoe ppp_async iptable_nat pppox ppp_generic nf_nat_ipv4
nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT ipt_MASQUERADE xt_time
xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_id
xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_CT slhc
nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_nat
nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache
nf_conntrack iptable_raw iptable_mangle iptable_fWed Jun 15 04:24:09
2016 kern.warn kernel: [  694.027758] CPU: 0 PID: 3 Comm: ksoftirqd/0
Not tainted 4.4.13 #1
Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.028021] Hardware
name: Qualcomm (Flattened Device Tree)
Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.034118] [<c021fea4>]
(unwind_backtrace) from [<c021cb0c>] (show_stack+0x10/0x14)
Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.039497] [<c021cb0c>]
(show_stack) from [<c03a18e8>] (dump_stack+0x88/0x9c)
Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.047482] [<c03a18e8>]
(dump_stack) from [<c0227a4c>] (warn_slowpath_common+0x94/0xb0)
Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.054510] [<c0227a4c>]
(warn_slowpath_common) from [<c0227a98>] (warn_slowpath_fmt+0x30/0x40)
Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.062759] [<c0227a98>]
(warn_slowpath_fmt) from [<c04c50a8>] (skb_warn_bad_offload+0xe4/0xf8)
Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.071179] [<c04c50a8>]
(skb_warn_bad_offload) from [<c04c95e0>] (__skb_gso_segment+0x4c/0xd0)
Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.079858] [<c04c95e0>]
(__skb_gso_segment) from [<c04fb00c>] (ip_finish_output+0x12c/0x1fc)
Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.088536] [<c04fb00c>]
(ip_finish_output) from [<c04fb994>] (ip_output+0x4c/0xb8)
Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.097223] [<c04fb994>]
(ip_output) from [<c04f84ac>] (ip_forward+0x278/0x38c)
Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.104680] [<c04f84ac>]
(ip_forward) from [<c04f7138>] (ip_rcv+0x244/0x2cc)
Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.111971] [<c04f7138>]
(ip_rcv) from [<c04c59ec>] (__netif_receive_skb_core+0x640/0x7a4)
Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.119265] [<c04c59ec>]
(__netif_receive_skb_core) from [<c04c82f4>]
(process_backlog+0x9c/0x134)
Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.127340] [<c04c82f4>]
(process_backlog) from [<c04c7a5c>] (net_rx_action+0x120/0x2c8)
Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.136282] [<c04c7a5c>]
(net_rx_action) from [<c022b2c0>] (__do_softirq+0xe0/0x21c)
Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.144529] [<c022b2c0>]
(__do_softirq) from [<c022b420>] (run_ksoftirqd+0x24/0x44)
Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.152255] [<c022b420>]
(run_ksoftirqd) from [<c0243fcc>] (smpboot_thread_fn+0x24c/0x288)
Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.159638] [<c0243fcc>]
(smpboot_thread_fn) from [<c0241540>] (kthread+0xf0/0xf8)
Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.167966] [<c0241540>]
(kthread) from [<c0209cb8>] (ret_from_fork+0x14/0x3c)
Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.175575] ---[ end
trace 26d6bdf0ce98e93b ]---
Wed Jun 15 04:24:14 2016 kern.alert kernel: [  694.182754] Unable to
handle kernel paging request at virtual address e20fe366
Wed Jun 15 04:24:14 2016 kern.alert kernel: [  694.187486] pgd = da464000
Wed Jun 15 04:24:14 2016 kern.alert kernel: [  694.194510] [e20fe366]
*pgd=00000000
Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.200587] Internal
error: Oops: 5 [#1] PREEMPT SMP ARM
Wed Jun 15 04:24:14 2016 kern.warn kernel: [  694.200853] Modules
linked in: pppoe ppp_async iptable_nat pppox ppp_generic nf_nat_ipv4
nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT ipt_MASQUERADE xt_time
xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_id
xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_CT slhc
nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_nat
nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache
nf_conntrack iptable_raw iptable_mangle iptable_fWed Jun 15 04:24:14
2016 kern.warn kernel: [  694.285396] CPU: 0 PID: 3 Comm: ksoftirqd/0
Tainted: G        W       4.4.13 #1
Wed Jun 15 04:24:14 2016 kern.warn kernel: [  694.285663] Hardware
name: Qualcomm (Flattened Device Tree)
Wed Jun 15 04:24:14 2016 kern.warn kernel: [  694.292779] task:
dd448880 ti: dd456000 task.ti: dd456000
Wed Jun 15 04:24:14 2016 kern.warn kernel: [  694.298340] PC is at
put_page+0x0/0x5c
Wed Jun 15 04:24:14 2016 kern.warn kernel: [  694.303894] LR is at
skb_release_data+0x6c/0xd4
Wed Jun 15 04:24:14 2016 kern.warn kernel: [  694.307536] pc :
[<c02a6898>]    lr : [<c04b9434>]    psr: 80000013
Wed Jun 15 04:24:14 2016 kern.warn kernel: [  694.307536] sp :
dd457d40  ip : 00000000  fp : c07736b0
Wed Jun 15 04:24:14 2016 kern.warn kernel: [  694.311972] r10:
da983bf0  r9 : dd41405c  r8 : ffffffea
Wed Jun 15 04:24:14 2016 kern.warn kernel: [  694.323420] r7 :
da983b40  r6 : d9d436c0  r5 : d9d436f0  r4 : 00000001
Wed Jun 15 04:24:14 2016 kern.warn kernel: [  694.328631] r3 :
000000f4  r2 : 00000000  r1 : 00000000  r0 : e20fe366
Wed Jun 15 04:24:14 2016 kern.warn kernel: [  694.335230] Flags: Nzcv
IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
Wed Jun 15 04:24:14 2016 kern.warn kernel: [  694.341740] Control:
10c5787d  Table: 5c46406a  DAC: 00000051
Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.348942] Process
ksoftirqd/0 (pid: 3, stack limit = 0xdd456210)
Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.354672] Stack:
(0xdd457d40 to 0xdd458000)
Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.360757] 7d40:
da983b40 000005dc c07a69c0 00000000 ffffffea c04b952c da983b40
c04fb0b8
Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.365189] 7d60:
00000001 c04f0f9c da983b40 c07a69c0 00000000 d9d43090 00000008
dd41405c
Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.373351] 7d80:
da983bf0 c04fb994 da983b40 00000004 80000000 dd457d02 00000000
dc909000
Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.381509] 7da0:
00000000 c07a69c0 c07a6f5c c04faee0 da983b40 dd414000 c07a69c0
c04f84ac
Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.389669] 7dc0:
bf280284 00000002 80000000 dd457e02 dd414000 dc909000 00000000
c07a69c0
Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.397830] 7de0:
c07a6f4c c04f81e8 da983b40 dd414000 d9d43090 dd414000 00000008
c04f7138
Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.405989] 7e00:
05eb0404 00000000 80000000 c04c5a02 dd414000 00000000 00000000
c07a69c0
Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.414147] 7e20:
c07a6f3c c04f6af4 da983b40 c077486c c04f6ef4 c04c59ec c0772100
00000000
Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.422306] 7e40:
00000001 00002f54 ddc1e840 da983b40 00000001 da983b40 ddc138b8
00000002
Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.430468] 7e60:
ddc13848 00000000 00000001 00000040 ddc138a4 c04c82f4 00000001
ddc138b0
Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.438629] 7e80:
c0772100 ddc138b8 00000001 00000040 0000012c 000099df c076e840
dd457ec0
Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.446787] 7ea0:
c0772100 c04c7a5c 00000003 1d4a5000 ddc13840 c077680c c07736b0
c07736b0
Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.454947] 7ec0:
dd415600 dd414600 dd457ec8 dd457ec8 dca8cd98 00000000 00000003
c077208c
Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.463107] 7ee0:
c0772080 40000003 dd456000 00000100 c0772080 c022b2c0 c0776d48
ddc12e40
Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.471265] 7f00:
dd457ef8 c07ae8c0 00000004 000099de c0772100 04208040 dd404d00
dd456000
Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.479424] 7f20:
dd404d00 00000000 00000001 c0778374 00000002 00000000 00000000
c022b420
Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.487584] 7f40:
dd456000 c0243fcc 00000000 dd404d40 dd404d00 c0243d80 00000000
00000000
Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.495745] 7f60:
00000000 c0241540 10106041 00000001 00000000 dd404d00 00000000
00030003
Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.503907] 7f80:
dd457f80 dd457f80 00000000 00000000 dd457f90 dd457f90 dd457fac
dd404d40
Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.512064] 7fa0:
c0241450 00000000 00000000 c0209cb8 00000000 00000000 00000000
00000000
Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.520223] 7fc0:
00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.528384] 7fe0:
00000000 00000000 00000000 00000000 00000013 00000000 90000018
41070000
Wed Jun 15 04:24:14 2016 kern.warn kernel: [  694.536545] [<c02a6898>]
(put_page) from [<c04b9434>] (skb_release_data+0x6c/0xd4)
Wed Jun 15 04:24:14 2016 kern.warn kernel: [  694.544698] [<c04b9434>]
(skb_release_data) from [<c04b952c>] (kfree_skb+0x54/0x60)
Wed Jun 15 04:24:14 2016 kern.warn kernel: [  694.552162] [<c04b952c>]
(kfree_skb) from [<c04fb0b8>] (ip_finish_output+0x1d8/0x1fc)
Wed Jun 15 04:24:14 2016 kern.warn kernel: [  694.559715] [<c04fb0b8>]
(ip_finish_output) from [<c04fb994>] (ip_output+0x4c/0xb8)
Wed Jun 15 04:24:14 2016 kern.warn kernel: [  694.567708] [<c04fb994>]
(ip_output) from [<c04f84ac>] (ip_forward+0x278/0x38c)


From yszhou4tech at gmail.com  Wed Jun 15 04:20:29 2016
From: yszhou4tech at gmail.com (Yousong Zhou)
Date: Wed, 15 Jun 2016 19:20:29 +0800
Subject: [LEDE-DEV] [PATCH] uloop: use a waker for notifying sigchld and
 loop cancel events
In-Reply-To: <6c34a33b-422f-bc63-71ca-ab37e2b61956@nbd.name>
References: <1465438832-20133-1-git-send-email-yszhou4tech@gmail.com>
 <6c34a33b-422f-bc63-71ca-ab37e2b61956@nbd.name>
Message-ID: <CAECwjAj8+93DEOd=dB1inffFswqg_EzEAQqpbZmyzAbc1ns1pg@mail.gmail.com>

On 15 June 2016 at 17:58, Felix Fietkau <nbd at nbd.name> wrote:
> On 2016-06-09 04:20, Yousong Zhou wrote:
>> Fix a race condition when do_sigchld, uloop_cancelled were set just
>> before epoll_wait(timeout=-1), resulting the loop stuck in the syscall
>> without noticing the events just happened
>>
>> Signed-off-by: Yousong Zhou <yszhou4tech at gmail.com>
> I found a few bugs and inconsistencies in that patch, and pushed a
> fixed version here:
> https://git.lede-project.org/?p=project/libubox.git;a=commitdiff;h=4e3a47a4cb438866bc4b9cb2f5d16226ffb48502
>
> Please review and test it some more before I push an update to LEDE.
>
> Thanks,
>
> - Felix

Ack from me.

The patch looks better.  Thanks

                yousong


From mats.dev.list at gmail.com  Wed Jun 15 06:07:25 2016
From: mats.dev.list at gmail.com (Mats Karrman)
Date: Wed, 15 Jun 2016 15:07:25 +0200
Subject: [LEDE-DEV] [PATCH] uloop: use a waker for notifying sigchld and
 loop cancel events
In-Reply-To: <CAECwjAj8+93DEOd=dB1inffFswqg_EzEAQqpbZmyzAbc1ns1pg@mail.gmail.com>
References: <1465438832-20133-1-git-send-email-yszhou4tech@gmail.com>
 <6c34a33b-422f-bc63-71ca-ab37e2b61956@nbd.name>
 <CAECwjAj8+93DEOd=dB1inffFswqg_EzEAQqpbZmyzAbc1ns1pg@mail.gmail.com>
Message-ID: <5761530D.6010509@gmail.com>


On 2016-06-15 13:20, Yousong Zhou wrote:
> On 15 June 2016 at 17:58, Felix Fietkau <nbd at nbd.name> wrote:
>> On 2016-06-09 04:20, Yousong Zhou wrote:
>>> Fix a race condition when do_sigchld, uloop_cancelled were set just
>>> before epoll_wait(timeout=-1), resulting the loop stuck in the syscall
>>> without noticing the events just happened
>>>
>>> Signed-off-by: Yousong Zhou <yszhou4tech at gmail.com>
>> I found a few bugs and inconsistencies in that patch, and pushed a
>> fixed version here:
>> https://git.lede-project.org/?p=project/libubox.git;a=commitdiff;h=4e3a47a4cb438866bc4b9cb2f5d16226ffb48502
>>
>> Please review and test it some more before I push an update to LEDE.
>>
>> Thanks,
>>
>> - Felix
> Ack from me.
>
> The patch looks better.  Thanks
>
>                  yousong
Tried this version together with procd-2016-03-09 
(b12bb150ed38a4409bef5127c77b060ee616b860)
but I still see the same behavior/error.

BR // Mats


From koen.vandeputte at ncentric.com  Wed Jun 15 06:13:16 2016
From: koen.vandeputte at ncentric.com (Koen Vandeputte)
Date: Wed, 15 Jun 2016 15:13:16 +0200
Subject: [LEDE-DEV] [PATCH] spinlock loop in cns3xxx_eth.c
In-Reply-To: <576015E5.7060106@ncentric.com>
References: <575EDB77.4040400@ncentric.com>
 <CAJ+vNU0JxQJJZxjW+VHWDA4O-ujBh0T3ydu4GdNYtxumAFNW0A@mail.gmail.com>
 <576015E5.7060106@ncentric.com>
Message-ID: <5761546C.8010409@ncentric.com>

Hi All,

I found the bug and was able to fix it.

Tested on 4 identical gateworks gw2388-4 (cns3xxx) boards.

- iperf in dual direction between board 1s & 2    (without patch)
- iperf in dual direction between board 3s & 4    (with patch)

Boards 1 and 2 go in spinlock after a few minutes on each try
Boards 3 and 4 have been running for hours without the error

To avoid any hardware delta, I retested with the patch only present on 
board 1 & 2
Board 1 & 2 now worked perfectly while 3 & 4 showed the loop issue



Patch:


 From 9338467c36b27bf1099dbdabd7591470c2a371df Mon Sep 17 00:00:00 2001
From: Koen Vandeputte <koen.vandeputte at ncentric.com>
Date: Wed, 15 Jun 2016 14:59:49 +0200
Subject: cns3xxx: fix RX softIRQ loop

Already reschedule when 1 or more frames came in.

Checking for a full queue could produce a re-schedule loop as
the checked RX ring location could contain undefined values
depending on activity in previous loops.

Signed-off-by: Koen Vandeputte <koen.vandeputte at ncentric.com>

diff --git 
a/target/linux/cns3xxx/files/drivers/net/ethernet/cavium/cns3xxx_eth.c 
b/target/linux/cns3xxx/files/drivers/net/ethernet/cavium/cns3xxx_eth.c
index 2f232c1..51b0187 100644
--- a/target/linux/cns3xxx/files/drivers/net/ethernet/cavium/cns3xxx_eth.c
+++ b/target/linux/cns3xxx/files/drivers/net/ethernet/cavium/cns3xxx_eth.c
@@ -717,8 +717,8 @@ static int eth_poll(struct napi_struct *napi, int 
budget)
          enable_irq(sw->rx_irq);
          budget = 0;

-        /* if rx descriptors are full schedule another poll */
-        if (rx_ring->desc[(i-1) & (RX_DESCS-1)].cown)
+        /* If 1 or more frames came in during IRQ enable, re-schedule */
+        if (rx_ring->desc[i].cown)
              eth_schedule_poll(sw);
      }



Kind regards,

Koen


On 2016-06-14 16:34, Koen Vandeputte wrote:
> Hi Tim,
>
> I fully understand the reason for the check.
>
> However,
> I think the bug has nothing to do with the rotting packet issue.
>
>
> The bug is actually:
> - eth_schedule_poll() gets called as it's detected that the ring is 
> full after IRQ_enable. (cown flag is set in the previous slot of the 
> ring)
> --> During this extra loop,  _0_ packets are received/processed! The 
> ring still seems to be full, and another reschedule takes place .. and 
> so on ..
>
>
> Iv'e added 3 debug counters in the code:    (see below after the patch)
> - Loop --> Top of eth_poll()
> - IRQ --> Top of eth_rx_irq()
> - Resched --> Inside the reschedule check
>
>
>
>
> Patch:
>
> --- a/drivers/net/ethernet/cavium/cns3xxx_eth.c
> +++ b/drivers/net/ethernet/cavium/cns3xxx_eth.c
> @@ -308,6 +308,8 @@ static int ports_open;
>  static struct port *switch_port_tab[4];
>  struct net_device *napi_dev;
>
> +static int CntIRQ;
> +
>  static int cns3xxx_mdio_cmd(struct mii_bus *bus, int phy_id, int 
> location,
>                 int write, u16 cmd)
>  {
> @@ -437,7 +439,10 @@ static void cns3xxx_adjust_link(struct n
>  static void eth_schedule_poll(struct sw *sw)
>  {
>      if (unlikely(!napi_schedule_prep(&sw->napi)))
> +    {
> +        //printk(KERN_ERR "sched err\n");
>          return;
> +    }
>
>      disable_irq_nosync(sw->rx_irq);
>      __napi_schedule(&sw->napi);
> @@ -447,6 +452,7 @@ irqreturn_t eth_rx_irq(int irq, void *pd
>  {
>      struct net_device *dev = pdev;
>      struct sw *sw = netdev_priv(dev);
> +    CntIRQ++;
>      eth_schedule_poll(sw);
>      return (IRQ_HANDLED);
>  }
> @@ -617,6 +623,7 @@ static void eth_complete_tx(struct sw *s
>
>  static int eth_poll(struct napi_struct *napi, int budget)
>  {
> +    static int Loop = 0;
>      struct sw *sw = container_of(napi, struct sw, napi);
>      struct _rx_ring *rx_ring = &sw->rx_ring;
>      int received = 0;
> @@ -712,6 +719,9 @@ static int eth_poll(struct napi_struct *
>      }
>
>      rx_ring->cur_index = i;
> +
> +    Loop++;
> +
>      if (!received) {
>          napi_complete(napi);
>          enable_irq(sw->rx_irq);
> @@ -719,7 +729,12 @@ static int eth_poll(struct napi_struct *
>
>          /* if rx descriptors are full schedule another poll */
>          if (rx_ring->desc[(i-1) & (RX_DESCS-1)].cown)
> +        {
> +            static int Sched = 0;
> +
> +            printk(KERN_ERR "Loop: %d irq: %d ReSched: %d\n", Loop, 
> CntIRQ, ++Sched);
>              eth_schedule_poll(sw);
> +        }
>      }
>
>      spin_lock_bh(&tx_lock);
>
>
>
> When the bug triggers, you can see below that consecutive loops in 
> eth_poll(), triggered by a reschedule, doesn't process any RX packets 
> at all ..
> (As the ReSched counter increases linear with the loop counter and 
> ReSched can only be incremented when "!received")
>
>
> Also
> Checking /proc/interrupts shows that gig_switch IRQ counter goes 
> berserk (+10k IRQ/s)
>
>
> [  477.440000] Loop: 835307 irq: 300583 ReSched: 1
> [  477.440000] Loop: 835308 irq: 300583 ReSched: 2
> [  477.440000] Loop: 835310 irq: 300583 ReSched: 3
> [  477.440000] Loop: 835311 irq: 300583 ReSched: 4
> [  477.440000] Loop: 835312 irq: 300583 ReSched: 5
> [  477.440000] Loop: 835313 irq: 300583 ReSched: 6
> [  477.440000] Loop: 835314 irq: 300583 ReSched: 7
> [  477.440000] Loop: 835315 irq: 300583 ReSched: 8
> [  477.440000] Loop: 835316 irq: 300583 ReSched: 9
> [  477.440000] Loop: 835317 irq: 300583 ReSched: 10
> [  477.440000] Loop: 835318 irq: 300583 ReSched: 11
> [  477.440000] Loop: 835319 irq: 300583 ReSched: 12
> [  477.440000] Loop: 835320 irq: 300583 ReSched: 13
> [  477.440000] Loop: 835321 irq: 300583 ReSched: 14
> [  477.440000] Loop: 835322 irq: 300583 ReSched: 15
> [  477.440000] Loop: 835323 irq: 300583 ReSched: 16
> [  477.440000] Loop: 835324 irq: 300583 ReSched: 17
> [  477.440000] Loop: 835325 irq: 300583 ReSched: 18
> [  477.440000] Loop: 835326 irq: 300583 ReSched: 19
> [  477.440000] Loop: 835327 irq: 300583 ReSched: 20
> [  477.440000] Loop: 835328 irq: 300583 ReSched: 21
> [  477.440000] Loop: 835329 irq: 300583 ReSched: 22
> [  477.440000] Loop: 835330 irq: 300583 ReSched: 23
> [  477.440000] Loop: 835331 irq: 300583 ReSched: 24
> [  477.440000] Loop: 835332 irq: 300583 ReSched: 25
> [  477.440000] Loop: 835333 irq: 300583 ReSched: 26
> [  477.440000] Loop: 835334 irq: 300583 ReSched: 27
> [  477.440000] Loop: 835335 irq: 300583 ReSched: 28
> [  477.440000] Loop: 835336 irq: 300583 ReSched: 29
> [  477.440000] Loop: 835337 irq: 300583 ReSched: 30
> [  477.440000] Loop: 835338 irq: 300583 ReSched: 31
> [  477.440000] Loop: 835339 irq: 300583 ReSched: 32
> [  477.440000] Loop: 835340 irq: 300583 ReSched: 33
> [  477.440000] Loop: 835341 irq: 300583 ReSched: 34
> [  477.440000] Loop: 835342 irq: 300583 ReSched: 35
> [  477.440000] Loop: 835343 irq: 300583 ReSched: 36
> [  477.440000] Loop: 835344 irq: 300583 ReSched: 37
> [  477.440000] Loop: 835345 irq: 300583 ReSched: 38
> [  477.440000] Loop: 835346 irq: 300583 ReSched: 39
> [  477.440000] Loop: 835347 irq: 300583 ReSched: 40
> [  477.440000] Loop: 835348 irq: 300583 ReSched: 41
> [  477.440000] Loop: 835349 irq: 300583 ReSched: 42
> [  477.440000] Loop: 835350 irq: 300583 ReSched: 43
> [  477.440000] Loop: 835351 irq: 300583 ReSched: 44
> [  477.440000] Loop: 835352 irq: 300583 ReSched: 45
> [  477.440000] Loop: 835353 irq: 300583 ReSched: 46
> [  477.440000] Loop: 835354 irq: 300583 ReSched: 47
> [  477.440000] Loop: 835355 irq: 300583 ReSched: 48
> [  477.440000] Loop: 835356 irq: 300583 ReSched: 49
> [  477.440000] Loop: 835357 irq: 300583 ReSched: 50
> [  477.440000] Loop: 835358 irq: 300583 ReSched: 51
> [  477.440000] Loop: 835359 irq: 300583 ReSched: 52
> [  477.440000] Loop: 835360 irq: 300583 ReSched: 53
> [  477.440000] Loop: 835361 irq: 300583 ReSched: 54
> [  477.440000] Loop: 835362 irq: 300583 ReSched: 55
> [  477.440000] Loop: 835363 irq: 300583 ReSched: 56
> [  477.440000] Loop: 835364 irq: 300583 ReSched: 57
> [  477.440000] Loop: 835365 irq: 300583 ReSched: 58
> [  477.440000] Loop: 835366 irq: 300583 ReSched: 59
> [  477.440000] Loop: 835367 irq: 300583 ReSched: 60
> [  477.440000] Loop: 835368 irq: 300583 ReSched: 61
> [  477.440000] Loop: 835369 irq: 300583 ReSched: 62
> [  477.440000] Loop: 835370 irq: 300583 ReSched: 63
> [  477.440000] Loop: 835371 irq: 300583 ReSched: 64
> [  477.440000] Loop: 835372 irq: 300583 ReSched: 65
> [  477.440000] Loop: 835373 irq: 300583 ReSched: 66
> [  477.440000] Loop: 835374 irq: 300583 ReSched: 67
> [  477.440000] Loop: 835375 irq: 300583 ReSched: 68
> [  477.440000] Loop: 835376 irq: 300583 ReSched: 69
> [  477.440000] Loop: 835377 irq: 300583 ReSched: 70
> [  477.440000] Loop: 835378 irq: 300583 ReSched: 71
> [  477.440000] Loop: 835379 irq: 300583 ReSched: 72
> [  477.440000] Loop: 835380 irq: 300583 ReSched: 73
> [  477.440000] Loop: 835381 irq: 300583 ReSched: 74
> [  477.440000] Loop: 835382 irq: 300583 ReSched: 75
> [  477.440000] Loop: 835383 irq: 300583 ReSched: 76
> [  477.440000] Loop: 835384 irq: 300583 ReSched: 77
> [  477.440000] Loop: 835385 irq: 300583 ReSched: 78
> [  477.440000] Loop: 835386 irq: 300583 ReSched: 79
> [  477.440000] Loop: 835387 irq: 300583 ReSched: 80
> [  477.440000] Loop: 835388 irq: 300583 ReSched: 81
> [  477.440000] Loop: 835389 irq: 300583 ReSched: 82
> [  477.440000] Loop: 835390 irq: 300583 ReSched: 83
> [  477.440000] Loop: 835391 irq: 300583 ReSched: 84
> [  477.440000] Loop: 835392 irq: 300583 ReSched: 85
> [  477.440000] Loop: 835393 irq: 300583 ReSched: 86
> [  477.440000] Loop: 835394 irq: 300583 ReSched: 87
> [  477.440000] Loop: 835396 irq: 300583 ReSched: 88
> [  477.440000] Loop: 835397 irq: 300583 ReSched: 89
> [  477.440000] Loop: 835398 irq: 300583 ReSched: 90
> [  477.440000] Loop: 835399 irq: 300583 ReSched: 91
> [  477.440000] Loop: 835400 irq: 300583 ReSched: 92
> [  477.440000] Loop: 835403 irq: 300583 ReSched: 93
> [  477.440000] Loop: 835406 irq: 300583 ReSched: 94
> [  477.440000] Loop: 835407 irq: 300583 ReSched: 95
> [  477.440000] Loop: 835408 irq: 300583 ReSched: 96
> [  477.440000] Loop: 835409 irq: 300583 ReSched: 97
> [  477.440000] Loop: 835410 irq: 300583 ReSched: 98
> [  477.440000] Loop: 835411 irq: 300583 ReSched: 99
> [  477.440000] Loop: 835412 irq: 300583 ReSched: 100
> [  477.440000] Loop: 835413 irq: 300583 ReSched: 101
> [  477.440000] Loop: 835414 irq: 300583 ReSched: 102
> [  477.440000] Loop: 835415 irq: 300583 ReSched: 103
> [  477.440000] Loop: 835416 irq: 300583 ReSched: 104
> [  477.440000] Loop: 835417 irq: 300583 ReSched: 105
> [  477.440000] Loop: 835418 irq: 300583 ReSched: 106
> [  477.440000] Loop: 835419 irq: 300583 ReSched: 107
> [  477.440000] Loop: 835420 irq: 300583 ReSched: 108
> [  477.440000] Loop: 835421 irq: 300583 ReSched: 109
> [  477.440000] Loop: 835422 irq: 300583 ReSched: 110
> [  477.440000] Loop: 835423 irq: 300583 ReSched: 111
> [  477.440000] Loop: 835424 irq: 300583 ReSched: 112
> [  477.440000] Loop: 835425 irq: 300583 ReSched: 113
> [  477.440000] Loop: 835426 irq: 300583 ReSched: 114
> [  477.440000] Loop: 835427 irq: 300583 ReSched: 115
> [  477.440000] Loop: 835428 irq: 300583 ReSched: 116
> [  477.440000] Loop: 835429 irq: 300583 ReSched: 117
> [  477.440000] Loop: 835430 irq: 300583 ReSched: 118
> [  477.440000] Loop: 835431 irq: 300583 ReSched: 119
> [  477.440000] Loop: 835432 irq: 300583 ReSched: 120
> [  477.440000] Loop: 835433 irq: 300583 ReSched: 121
> [  477.440000] Loop: 835434 irq: 300583 ReSched: 122
> [  477.440000] Loop: 835435 irq: 300583 ReSched: 123
> [  477.440000] Loop: 835436 irq: 300583 ReSched: 124
> [  477.440000] Loop: 835437 irq: 300583 ReSched: 125
> [  477.440000] Loop: 835438 irq: 300583 ReSched: 126
> [  477.440000] Loop: 835439 irq: 300583 ReSched: 127
> [  477.440000] Loop: 835440 irq: 300583 ReSched: 128
> [  477.440000] Loop: 835441 irq: 300583 ReSched: 129
> [  477.440000] Loop: 835442 irq: 300583 ReSched: 130
> [  477.440000] Loop: 835443 irq: 300583 ReSched: 131
> [  477.440000] Loop: 835444 irq: 300583 ReSched: 132
> [  477.440000] Loop: 835445 irq: 300583 ReSched: 133
> [  477.440000] Loop: 835446 irq: 300583 ReSched: 134
> [  477.440000] Loop: 835447 irq: 300583 ReSched: 135
> [  477.440000] Loop: 835448 irq: 300583 ReSched: 136
> [  477.440000] Loop: 835449 irq: 300583 ReSched: 137
> [  477.440000] Loop: 835450 irq: 300583 ReSched: 138
> [  477.450000] Loop: 835451 irq: 300583 ReSched: 139
> [  477.450000] Loop: 835452 irq: 300583 ReSched: 140
> [  477.450000] Loop: 835453 irq: 300583 ReSched: 141
> [  477.450000] Loop: 835454 irq: 300583 ReSched: 142
> [  477.450000] Loop: 835455 irq: 300583 ReSched: 143
> [  477.450000] Loop: 835456 irq: 300583 ReSched: 144
> [  477.450000] Loop: 835457 irq: 300583 ReSched: 145
> [  477.450000] Loop: 835458 irq: 300583 ReSched: 146
> [  477.450000] Loop: 835459 irq: 300583 ReSched: 147
> [  477.450000] Loop: 835460 irq: 300583 ReSched: 148
> [  477.450000] Loop: 835461 irq: 300583 ReSched: 149
> [  477.450000] Loop: 835462 irq: 300583 ReSched: 150
> [  477.450000] Loop: 835463 irq: 300583 ReSched: 151
> [  477.450000] Loop: 835464 irq: 300583 ReSched: 152
> [  477.450000] Loop: 835465 irq: 300583 ReSched: 153
> [  477.450000] Loop: 835466 irq: 300583 ReSched: 154
> [  477.450000] Loop: 835467 irq: 300583 ReSched: 155
> [  477.450000] Loop: 835468 irq: 300583 ReSched: 156
> [  477.450000] Loop: 835469 irq: 300583 ReSched: 157
> [  477.450000] Loop: 835470 irq: 300583 ReSched: 158
> [  477.450000] Loop: 835472 irq: 300583 ReSched: 159
> [  477.450000] Loop: 835473 irq: 300583 ReSched: 160
> [  477.450000] Loop: 835474 irq: 300583 ReSched: 161
> [  477.450000] Loop: 835475 irq: 300583 ReSched: 162
> [  477.450000] Loop: 835476 irq: 300583 ReSched: 163
> [  477.450000] Loop: 835477 irq: 300583 ReSched: 164
> [  477.450000] Loop: 835478 irq: 300583 ReSched: 165
> [  477.450000] Loop: 835479 irq: 300583 ReSched: 166
> [  477.450000] Loop: 835480 irq: 300583 ReSched: 167
> [  477.450000] Loop: 835481 irq: 300583 ReSched: 168
> [  477.450000] Loop: 835482 irq: 300583 ReSched: 169
> [  477.450000] Loop: 835483 irq: 300583 ReSched: 170
> [  477.450000] Loop: 835484 irq: 300583 ReSched: 171
> [  477.450000] Loop: 835485 irq: 300583 ReSched: 172
> [  477.450000] Loop: 835486 irq: 300583 ReSched: 173
> [  477.450000] Loop: 835487 irq: 300583 ReSched: 174
> [  477.450000] Loop: 835488 irq: 300583 ReSched: 175
> [  477.450000] Loop: 835489 irq: 300583 ReSched: 176
> [  477.450000] Loop: 835490 irq: 300583 ReSched: 177
> [  477.450000] Loop: 835491 irq: 300583 ReSched: 178
> [  477.450000] Loop: 835492 irq: 300583 ReSched: 179
> [  477.450000] Loop: 835493 irq: 300583 ReSched: 180
> [  477.450000] Loop: 835494 irq: 300583 ReSched: 181
> [  477.450000] Loop: 835495 irq: 300583 ReSched: 182
> [  477.450000] Loop: 835496 irq: 300583 ReSched: 183
> [  477.450000] Loop: 835497 irq: 300583 ReSched: 184
> [  477.450000] Loop: 835498 irq: 300583 ReSched: 185
> [  477.450000] Loop: 835499 irq: 300583 ReSched: 186
> [  477.450000] Loop: 835500 irq: 300583 ReSched: 187
> [  477.450000] Loop: 835501 irq: 300583 ReSched: 188
> [  477.450000] Loop: 835502 irq: 300583 ReSched: 189
> [  477.450000] Loop: 835503 irq: 300583 ReSched: 190
> [  477.450000] Loop: 835504 irq: 300583 ReSched: 191
> [  477.450000] Loop: 835505 irq: 300583 ReSched: 192
> [  477.450000] Loop: 835506 irq: 300583 ReSched: 193
> [  477.450000] Loop: 835507 irq: 300583 ReSched: 194
> [  477.450000] Loop: 835508 irq: 300583 ReSched: 195
> [  477.450000] Loop: 835509 irq: 300583 ReSched: 196
> [  477.450000] Loop: 835510 irq: 300583 ReSched: 197
> [  477.450000] Loop: 835511 irq: 300583 ReSched: 198
> [  477.450000] Loop: 835512 irq: 300583 ReSched: 199
> [  477.450000] Loop: 835513 irq: 300583 ReSched: 200
> [  477.450000] Loop: 835514 irq: 300583 ReSched: 201
> [  477.450000] Loop: 835515 irq: 300583 ReSched: 202
> [  477.450000] Loop: 835516 irq: 300583 ReSched: 203
> [  477.450000] Loop: 835517 irq: 300583 ReSched: 204
> [  477.450000] Loop: 835518 irq: 300583 ReSched: 205
> [  477.450000] Loop: 835519 irq: 300583 ReSched: 206
> [  477.450000] Loop: 835520 irq: 300583 ReSched: 207
> [  477.450000] Loop: 835521 irq: 300583 ReSched: 208
> [  477.450000] Loop: 835522 irq: 300583 ReSched: 209
> [  477.450000] Loop: 835523 irq: 300583 ReSched: 210
> [  477.450000] Loop: 835524 irq: 300583 ReSched: 211
> [  477.450000] Loop: 835525 irq: 300583 ReSched: 212
> [  477.450000] Loop: 835526 irq: 300583 ReSched: 213
> [  477.450000] Loop: 835527 irq: 300583 ReSched: 214
> [  477.450000] Loop: 835528 irq: 300583 ReSched: 215
> [  477.450000] Loop: 835529 irq: 300583 ReSched: 216
> [  477.450000] Loop: 835530 irq: 300583 ReSched: 217
> [  478.450000] Loop: 835534 irq: 300584 ReSched: 218
> [  478.460000] Loop: 835536 irq: 300585 ReSched: 219
> [  478.470000] Loop: 835538 irq: 300586 ReSched: 220
> [  478.470000] Loop: 835539 irq: 300586 ReSched: 221
> [  478.500000] Loop: 835983 irq: 300586 ReSched: 622
> ...
> [  478.510000] Loop: 836072 irq: 300586 ReSched: 697
> [  478.510000] Loop: 836073 irq: 300586 ReSched: 698
> [  478.510000] Loop: 836074 irq: 300586 ReSched: 699
> [  478.510000] Loop: 836075 irq: 300586 ReSched: 700
> [  478.510000] Loop: 836076 irq: 300586 ReSched: 701
> [  478.510000] Loop: 836077 irq: 300586 ReSched: 702
> [  478.510000] Loop: 836078 irq: 300586 ReSched: 703
> [  478.510000] Loop: 836079 irq: 300586 ReSched: 704
> [  478.510000] Loop: 836080 irq: 300586 ReSched: 705
> [  478.510000] Loop: 836081 irq: 300586 ReSched: 706
> [  478.510000] Loop: 836082 irq: 300586 ReSched: 707
> [  478.510000] Loop: 836083 irq: 300586 ReSched: 708
> [  478.510000] Loop: 836084 irq: 300586 ReSched: 709
> [  478.510000] Loop: 836085 irq: 300586 ReSched: 710
> [  478.510000] Loop: 836086 irq: 300586 ReSched: 711
> [  478.510000] Loop: 836087 irq: 300586 ReSched: 712
> [  478.510000] Loop: 836088 irq: 300586 ReSched: 713
> [  478.510000] Loop: 836089 irq: 300586 ReSched: 714
> [  478.510000] Loop: 836090 irq: 300586 ReSched: 715
> [  478.510000] Loop: 836091 irq: 300586 ReSched: 716
> [  478.510000] Loop: 836092 irq: 300586 ReSched: 717
> [  478.510000] Loop: 836093 irq: 300586 ReSched: 718
> [  478.510000] Loop: 836094 irq: 300586 ReSched: 719
> [  478.510000] Loop: 836095 irq: 300586 ReSched: 720
> [  478.510000] Loop: 836096 irq: 300586 ReSched: 721
> [  478.510000] Loop: 836097 irq: 300586 ReSched: 722
> [  478.510000] Loop: 836098 irq: 300586 ReSched: 723
> [  478.510000] Loop: 836099 irq: 300586 ReSched: 724
> [  478.510000] Loop: 836100 irq: 300586 ReSched: 725
> [  478.510000] Loop: 836101 irq: 300586 ReSched: 726
> [  478.510000] Loop: 836102 irq: 300586 ReSched: 727
> [  478.510000] Loop: 836103 irq: 300586 ReSched: 728
> [  478.510000] Loop: 836104 irq: 300586 ReSched: 729
> [  478.510000] Loop: 836105 irq: 300586 ReSched: 730
> [  478.510000] Loop: 836106 irq: 300586 ReSched: 731
> [  478.510000] Loop: 836107 irq: 300586 ReSched: 732
> [  478.510000] Loop: 836108 irq: 300586 ReSched: 733
> [  478.510000] Loop: 836109 irq: 300586 ReSched: 734
> [  478.510000] Loop: 836110 irq: 300586 ReSched: 735
> [  478.510000] Loop: 836111 irq: 300586 ReSched: 736
> [  478.510000] Loop: 836112 irq: 300586 ReSched: 737
> [  478.510000] Loop: 836113 irq: 300586 ReSched: 738
> [  478.510000] Loop: 836114 irq: 300586 ReSched: 739
> [  478.510000] Loop: 836115 irq: 300586 ReSched: 740
> [  478.510000] Loop: 836116 irq: 300586 ReSched: 741
> [  478.510000] Loop: 836117 irq: 300586 ReSched: 742
> [  478.510000] Loop: 836118 irq: 300586 ReSched: 743
> [  478.510000] Loop: 836119 irq: 300586 ReSched: 744
> [  478.510000] Loop: 836120 irq: 300586 ReSched: 745
> [  478.510000] Loop: 836121 irq: 300586 ReSched: 746
> [  478.510000] Loop: 836122 irq: 300586 ReSched: 747
> [  478.510000] Loop: 836123 irq: 300586 ReSched: 748
> [  478.510000] Loop: 836124 irq: 300586 ReSched: 749
> [  478.510000] Loop: 836125 irq: 300586 ReSched: 750
> [  478.510000] Loop: 836126 irq: 300586 ReSched: 751
> [  478.510000] Loop: 836127 irq: 300586 ReSched: 752
> [  478.510000] Loop: 836128 irq: 300586 ReSched: 753
> [  478.510000] Loop: 836129 irq: 300586 ReSched: 754
> [  478.510000] Loop: 836130 irq: 300586 ReSched: 755
> [  478.510000] Loop: 836131 irq: 300586 ReSched: 756
> [  478.510000] Loop: 836132 irq: 300586 ReSched: 757
> [  478.510000] Loop: 836133 irq: 300586 ReSched: 758
> [  478.510000] Loop: 836134 irq: 300586 ReSched: 759
>
>
> Koen
>
> On 2016-06-13 20:17, Tim Harvey wrote:
>> On Mon, Jun 13, 2016 at 9:12 AM, Koen Vandeputte
>> <koen.vandeputte at ncentric.com> wrote:
>>> Hi All,
>>>
>>> There seems to be a bug in the function eth_poll() in this driver
>>>
>>> When the RX ring gets full once, the re-schedule is called forever, 
>>> even
>>> when the ring is empty afterwards.
>>>
>>>
>>>      if (!received) {
>>>          napi_complete(napi);
>>>          enable_irq(sw->rx_irq);
>>>          budget = 0;
>>>
>>>          /* if rx descriptors are full schedule another poll */
>>>          if (rx_ring->desc[(i-1) & (RX_DESCS-1)].cown)
>>>          {
>>>              eth_schedule_poll(sw);    <----  Gets called on each 
>>> function
>>> entry
>>>          }
>>>      }
>>>
>>>
>>> This causes SoftIRQ to fully load a core forever.
>>>
>>>
>>> I didn't fix it yet, but should I be the first, i'll supply a patch ..
>>>
>> Koen,
>>
>> We have seen this before, but admittedly don't understand why we enter
>> into the same condition on each subsequent call to eth_poll(). The
>> check is to catch the condition described as irq rot [1] and is to
>> catch the case where after processing the full budget, we are
>> immediately full again (a situation which is easily re-producible with
>> a flood-ping). If this occurs we will no longer get an rx interrupt
>> (because the descriptors are full) and our napi function will never
>> get called again (unless transmitting packets).
>>
>> What is your proposed patch?
>>
>> Tim
>>
>> 1 
>> .http://www.linuxfoundation.org/collaborate/workgroups/networking/napi#IRQ_race_a.k.a_rotting_packet
>



From dedeckeh at gmail.com  Wed Jun 15 06:13:52 2016
From: dedeckeh at gmail.com (Hans Dedecker)
Date: Wed, 15 Jun 2016 15:13:52 +0200
Subject: [LEDE-DEV] [PATCH] uloop: use a waker for notifying sigchld and
 loop cancel events
In-Reply-To: <f0d60d41-75a7-0cf5-2f37-ff0915d2b44f@nbd.name>
References: <1465438832-20133-1-git-send-email-yszhou4tech@gmail.com>
 <5761226A.5070404@conorogorman.net>
 <f0d60d41-75a7-0cf5-2f37-ff0915d2b44f@nbd.name>
Message-ID: <CAJLcKsFNT3uXTkYihzQYQ0HoQ7oc=FKArLOTR6OSe0WCPMCjTw@mail.gmail.com>

On Wed, Jun 15, 2016 at 11:58 AM, Felix Fietkau <nbd at nbd.name> wrote:
> On 2016-06-15 11:39, Conor O'Gorman wrote:
>> On 09/06/16 03:20, Yousong Zhou wrote:
>>> Fix a race condition when do_sigchld, uloop_cancelled were set just
>>> before epoll_wait(timeout=-1), resulting the loop stuck in the syscall
>>> without noticing the events just happened
>>>
>>> Signed-off-by: Yousong Zhou <yszhou4tech at gmail.com>
>>> ---
>>>   uloop-epoll.c  |  2 +-
>>>   uloop-kqueue.c |  2 +-
>>>   uloop.c        | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++++++----
>>>   3 files changed, 63 insertions(+), 6 deletions(-)
>>>
>> Why not change the timeout?
> Changing the timeout would not fix the race, and it would lead to
> unnecessary process wakeups and extra latency for signal processing.
>
> - Felix
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
Could it be that the wiker_pipe does not get properly initialized as
waker_pipe never is assigned a fd value ?

Br,
Hans


From nbd at nbd.name  Wed Jun 15 06:16:06 2016
From: nbd at nbd.name (Felix Fietkau)
Date: Wed, 15 Jun 2016 15:16:06 +0200
Subject: [LEDE-DEV] [PATCH] uloop: use a waker for notifying sigchld and
 loop cancel events
In-Reply-To: <CAJLcKsFNT3uXTkYihzQYQ0HoQ7oc=FKArLOTR6OSe0WCPMCjTw@mail.gmail.com>
References: <1465438832-20133-1-git-send-email-yszhou4tech@gmail.com>
 <5761226A.5070404@conorogorman.net>
 <f0d60d41-75a7-0cf5-2f37-ff0915d2b44f@nbd.name>
 <CAJLcKsFNT3uXTkYihzQYQ0HoQ7oc=FKArLOTR6OSe0WCPMCjTw@mail.gmail.com>
Message-ID: <02a2e110-8b78-d4a0-40ce-5e780073c83e@nbd.name>

On 2016-06-15 15:13, Hans Dedecker wrote:
> On Wed, Jun 15, 2016 at 11:58 AM, Felix Fietkau <nbd at nbd.name> wrote:
>> On 2016-06-15 11:39, Conor O'Gorman wrote:
>>> On 09/06/16 03:20, Yousong Zhou wrote:
>>>> Fix a race condition when do_sigchld, uloop_cancelled were set just
>>>> before epoll_wait(timeout=-1), resulting the loop stuck in the syscall
>>>> without noticing the events just happened
>>>>
>>>> Signed-off-by: Yousong Zhou <yszhou4tech at gmail.com>
>>>> ---
>>>>   uloop-epoll.c  |  2 +-
>>>>   uloop-kqueue.c |  2 +-
>>>>   uloop.c        | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++++++----
>>>>   3 files changed, 63 insertions(+), 6 deletions(-)
>>>>
>>> Why not change the timeout?
>> Changing the timeout would not fix the race, and it would lead to
>> unnecessary process wakeups and extra latency for signal processing.
>>
>> - Felix
>>
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
> Could it be that the wiker_pipe does not get properly initialized as
> waker_pipe never is assigned a fd value ?
I accidentally dropped that in a copy&paste screwup. Fix pushed to git.

Thanks,

- Felix


From john at phrozen.org  Wed Jun 15 07:02:45 2016
From: john at phrozen.org (John Crispin)
Date: Wed, 15 Jun 2016 16:02:45 +0200
Subject: [LEDE-DEV] DGN3500 nas mac
Message-ID: <94da699d-a26e-fb99-3696-1c241bd20d90@phrozen.org>

Hi,

492964e741f1e0254b6ed7c0a095551a31d25dc9 slipped by me without me
realizing that it is broken.

i staged a fix in my tree for this
https://git.lede-project.org/?p=lede/blogic/staging.git;a=commit;h=08eb51390bd898a2f2b8023515c0f6482887faa7

however the esi stuff needs to be changed to apply the mac from wan to
the nas interface.

maybe we can add this as an init.d script as part of the esi package ?

	John


From olivier.hardouin at gmail.com  Wed Jun 15 07:10:21 2016
From: olivier.hardouin at gmail.com (olivier.hardouin at gmail.com)
Date: Wed, 15 Jun 2016 16:10:21 +0200
Subject: [LEDE-DEV] [PATCH mountd 1/4] align fs_names table to indexes
	defined in include/fs.h
Message-ID: <1465999824-20936-1-git-send-email-olivier.hardouin@gmail.com>

Signed-off-by: Olivier Hardouin <olivier.hardouin at gmail.com>
---
 mount.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/mount.c b/mount.c
index 8892040..36b99f5 100644
--- a/mount.c
+++ b/mount.c
@@ -59,6 +59,7 @@ char *fs_names[] = {
 	"",
 	"NTFS",
 	"",
+	"EXFAT",
 	"EXT4"
 };
 
-- 
1.9.1



From olivier.hardouin at gmail.com  Wed Jun 15 07:10:23 2016
From: olivier.hardouin at gmail.com (olivier.hardouin at gmail.com)
Date: Wed, 15 Jun 2016 16:10:23 +0200
Subject: [LEDE-DEV] [PATCH mountd 3/4] add hotplug events
In-Reply-To: <1465999824-20936-1-git-send-email-olivier.hardouin@gmail.com>
References: <1465999824-20936-1-git-send-email-olivier.hardouin@gmail.com>
Message-ID: <1465999824-20936-3-git-send-email-olivier.hardouin@gmail.com>

add hotplug events (add, remove) to inform other subsystems
remove obsolete /etc/mountd/event call

Signed-off-by: Olivier Hardouin <olivier.hardouin at gmail.com>
---
 mount.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mount.c b/mount.c
index aaddb70..219146b 100644
--- a/mount.c
+++ b/mount.c
@@ -161,6 +161,7 @@ static void mount_add_list(char *name, char *dev, char *serial,
 		snprintf(tmp2, 64, "/tmp/run/mountd/%s", dev);
 		symlink(tmp2, tmp);
 		mount_new("/tmp/run/mountd/", dev);
+		system_printf("ACTION=add DEVICE=%s NAME=%s /sbin/hotplug-call mount", dev, name);
 	}
 }
 
@@ -734,7 +735,7 @@ static void mount_enum_drives(void)
 			log_printf("removing %s\n", q->dev);
 			snprintf(tmp, 64, "%s%s", uci_path, q->name);
 			unlink(tmp);
-			system_printf("/etc/mountd/event remove %s %s", q->dev, q->name);
+			system_printf("ACTION=remove DEVICE=%s NAME=%s /sbin/hotplug-call mount", q->dev, q->name);
 			free(q);
 			mount_dump_uci_state();
 			system_printf("/etc/fonstated/ReloadSamba");
-- 
1.9.1



From olivier.hardouin at gmail.com  Wed Jun 15 07:10:22 2016
From: olivier.hardouin at gmail.com (olivier.hardouin at gmail.com)
Date: Wed, 15 Jun 2016 16:10:22 +0200
Subject: [LEDE-DEV] [PATCH mountd 2/4] fix crash if no uci config file
	present
In-Reply-To: <1465999824-20936-1-git-send-email-olivier.hardouin@gmail.com>
References: <1465999824-20936-1-git-send-email-olivier.hardouin@gmail.com>
Message-ID: <1465999824-20936-2-git-send-email-olivier.hardouin@gmail.com>

fix also possible null dereferenced pointers 

Signed-off-by: Olivier Hardouin <olivier.hardouin at gmail.com>
---
 uci.c  | 6 ++++++
 ucix.c | 9 ++++++++-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/uci.c b/uci.c
index f5aad02..46c3922 100644
--- a/uci.c
+++ b/uci.c
@@ -54,6 +54,9 @@ char* uci_get_option(struct uci_context *ctx, char *section, char *option)
 	char *value = NULL;
 	struct uci_ptr ptr;
 
+	if (!p)
+		return NULL;
+
 	memset(&ptr, 0, sizeof(ptr));
 	ptr.package = p->e.name;
 	ptr.section = section;
@@ -101,6 +104,9 @@ void uci_for_each_section_type(char *type, void (*cb)(char*, void*), void *priv)
 {
 	struct uci_element *e;
 
+	if (!p)
+		return;
+
 	uci_foreach_element(&p->sections, e)
 		if (!strcmp(type, uci_to_section(e)->type))
 			cb(e->name, priv);
diff --git a/ucix.c b/ucix.c
index e2a6780..1e4d1e6 100644
--- a/ucix.c
+++ b/ucix.c
@@ -18,6 +18,8 @@ static inline int ucix_get_ptr(struct uci_context *ctx, const char *p, const cha
 struct uci_context* ucix_init(const char *config_file)
 {
 	struct uci_context *ctx = uci_alloc_context();
+	if(!ctx)
+		return NULL;
 	uci_add_delta_path(ctx, "/var/state");
 	if(uci_load(ctx, config_file, NULL) != UCI_OK)
 	{
@@ -30,6 +32,8 @@ struct uci_context* ucix_init(const char *config_file)
 struct uci_context* ucix_init_path(const char *path, const char *config_file)
 {
 	struct uci_context *ctx = uci_alloc_context();
+	if(!ctx)
+		return NULL;
 	if(path)
 	{
 		uci_set_savedir(ctx, path);
@@ -44,7 +48,10 @@ struct uci_context* ucix_init_path(const char *path, const char *config_file)
 
 void ucix_cleanup(struct uci_context *ctx)
 {
-	uci_free_context(ctx);
+	if(ctx)
+	{
+		uci_free_context(ctx);
+	}
 }
 
 int ucix_save(struct uci_context *ctx, const char *p)
-- 
1.9.1



From olivier.hardouin at gmail.com  Wed Jun 15 07:10:24 2016
From: olivier.hardouin at gmail.com (olivier.hardouin at gmail.com)
Date: Wed, 15 Jun 2016 16:10:24 +0200
Subject: [LEDE-DEV] [PATCH mountd 4/4] filesystem mount options in uci as
	optional parameter
In-Reply-To: <1465999824-20936-1-git-send-email-olivier.hardouin@gmail.com>
References: <1465999824-20936-1-git-send-email-olivier.hardouin@gmail.com>
Message-ID: <1465999824-20936-4-git-send-email-olivier.hardouin@gmail.com>

Possibility to overwrite the default hardcoded settings by adding 'options' 
and 'fstype' in the uci configuration. The fs names are changed in lowercase 
to comply with UCI general naming.

Signed-off-by: Olivier Hardouin <olivier.hardouin at gmail.com>
---
replaces patch "filesystem mount options in uci config" according to review comments
obsoletes patch "uci config for mountd fileystem options"

 mount.c | 63 +++++++++++++++++++++++++++++++++++++++++----------------------
 1 file changed, 41 insertions(+), 22 deletions(-)

diff --git a/mount.c b/mount.c
index 36b99f5..aaddb70 100644
--- a/mount.c
+++ b/mount.c
@@ -51,16 +51,16 @@ struct mount {
 char *fs_names[] = {
 	"",
 	"",
-	"MBR",
-	"EXT2",
-	"EXT3",
-	"FAT",
-	"HFSPLUS",
+	"mbr",
+	"ext2",
+	"ext3",
+	"fat",
+	"hfsplus",
 	"",
-	"NTFS",
+	"ntfs",
 	"",
-	"EXFAT",
-	"EXT4"
+	"exfat",
+	"ext4"
 };
 
 #define MAX_MOUNTED		32
@@ -228,40 +228,59 @@ int mount_new(char *path, char *dev)
 	pid = autofs_safe_fork();
 	if(!pid)
 	{
+		char *options, *fstype;
 		if(mount->fs == EXFAT)
 		{
-			log_printf("mount -t exfat -o rw,uid=1000,gid=1000 /dev/%s %s", mount->dev, tmp);
-			ret = system_printf("mount -t exfat -o rw,uid=1000,gid=1000 /dev/%s %s", mount->dev, tmp);
+			options = "rw,uid=1000,gid=1000";
+			fstype = "exfat";
 		}
 		if(mount->fs == FAT)
 		{
-			log_printf("mount -t vfat -o rw,uid=1000,gid=1000 /dev/%s %s", mount->dev, tmp);
-			ret = system_printf("mount -t vfat -o rw,uid=1000,gid=1000 /dev/%s %s", mount->dev, tmp);
+			options = "rw,uid=1000,gid=1000";
+			fstype = "vfat";
 		}
 		if(mount->fs == EXT4)
 		{
-			log_printf("mount -t ext4 -o rw,defaults /dev/%s %s", mount->dev, tmp);
-			ret = system_printf("mount -t ext4 -o rw,defaults /dev/%s %s", mount->dev, tmp);
+			options = "rw,defaults";
+			fstype = "ext4";
 		}
 		if(mount->fs == EXT3)
 		{
-			log_printf("mount -t ext3 -o rw,defaults /dev/%s %s", mount->dev, tmp);
-			ret = system_printf("mount -t ext3 -o rw,defaults /dev/%s %s", mount->dev, tmp);
+			options = "rw,defaults";
+			fstype = "ext3";
 		}
 		if(mount->fs == EXT2)
 		{
-			log_printf("mount -t ext2 -o rw,defaults /dev/%s %s", mount->dev, tmp);
-			ret = system_printf("mount -t ext2 -o rw,defaults /dev/%s %s", mount->dev, tmp);
+			options = "rw,defaults";
+			fstype = "ext2";
 		}
 		if(mount->fs == HFSPLUS)
 		{
-			log_printf("mount -t hfsplus -o rw,defaults,uid=1000,gid=1000 /dev/%s %s", mount->dev, tmp);
-			ret = system_printf("mount -t hfsplus -o rw,defaults,uid=1000,gid=1000 /dev/%s %s", mount->dev, tmp);
+			options = "rw,defaults,uid=1000,gid=1000";
+			fstype = "hfsplus";
 		}
 		if(mount->fs == NTFS)
 		{
-			log_printf("ntfs-3g /dev/%s %s -o force", mount->dev, tmp);
-			ret = system_printf("ntfs-3g /dev/%s %s -o force", mount->dev, tmp);
+			options = "force";
+			fstype = "ntfs-3g";
+		}
+		if(mount->fs > MBR && mount->fs <= EXT4)
+		{
+			struct uci_context *ctx;
+			char *uci_options, *uci_fstype;
+			ctx = ucix_init("mountd");
+			if(fs_names[mount->fs])
+			{
+				uci_options = ucix_get_option(ctx, "mountd", fs_names[mount->fs], "options");
+				uci_fstype = ucix_get_option(ctx, "mountd", fs_names[mount->fs], "fstype");
+				if(uci_options)
+					options = uci_options;
+				if(uci_fstype)
+					fstype = uci_fstype;
+				log_printf("mount -t %s -o %s /dev/%s %s", fstype, options, mount->dev, tmp);
+				ret = system_printf("mount -t %s -o %s /dev/%s %s", fstype, options, mount->dev, tmp);
+			}
+			ucix_cleanup(ctx);
 		}
 		exit(WEXITSTATUS(ret));
 	}
-- 
1.9.1



From alin.nastac at gmail.com  Wed Jun 15 07:27:53 2016
From: alin.nastac at gmail.com (Alin Nastac)
Date: Wed, 15 Jun 2016 16:27:53 +0200
Subject: [LEDE-DEV] [PATCH] libnetfilter_queue: fix UDP checksum computation
Message-ID: <1466000873-14857-1-git-send-email-alin.nastac@gmail.com>

This patch was copied from
http://www.spinics.net/lists/netfilter/msg56704.html .
---
 .../patches/100-udp_checksum_computation.patch     | 95 ++++++++++++++++++++++
 1 file changed, 95 insertions(+)
 create mode 100644 package/libs/libnetfilter-queue/patches/100-udp_checksum_computation.patch

diff --git a/package/libs/libnetfilter-queue/patches/100-udp_checksum_computation.patch b/package/libs/libnetfilter-queue/patches/100-udp_checksum_computation.patch
new file mode 100644
index 0000000..9939b83
--- /dev/null
+++ b/package/libs/libnetfilter-queue/patches/100-udp_checksum_computation.patch
@@ -0,0 +1,95 @@
+--- libnetfilter_queue-1.0.2.orig/src/extra/checksum.c
++++ libnetfilter_queue-1.0.2/src/extra/checksum.c
+@@ -35,7 +35,7 @@ uint16_t checksum(uint32_t sum, uint16_t
+ 	return (uint16_t)(~sum);
+ }
+ 
+-uint16_t checksum_tcpudp_ipv4(struct iphdr *iph)
++uint16_t checksum_tcpudp_ipv4(struct iphdr *iph, uint16_t protocol_id)
+ {
+ 	uint32_t sum = 0;
+ 	uint32_t iph_len = iph->ihl*4;
+@@ -46,13 +46,13 @@ uint16_t checksum_tcpudp_ipv4(struct iph
+ 	sum += (iph->saddr) & 0xFFFF;
+ 	sum += (iph->daddr >> 16) & 0xFFFF;
+ 	sum += (iph->daddr) & 0xFFFF;
+-	sum += htons(IPPROTO_TCP);
++	sum += htons(protocol_id);
+ 	sum += htons(len);
+ 
+ 	return checksum(sum, (uint16_t *)payload, len);
+ }
+ 
+-uint16_t checksum_tcpudp_ipv6(struct ip6_hdr *ip6h, void *transport_hdr)
++uint16_t checksum_tcpudp_ipv6(struct ip6_hdr *ip6h, void *transport_hdr, uint16_t protocol_id)
+ {
+ 	uint32_t sum = 0;
+ 	uint32_t hdr_len = (uint32_t *)transport_hdr - (uint32_t *)ip6h;
+@@ -68,7 +68,7 @@ uint16_t checksum_tcpudp_ipv6(struct ip6
+ 		sum += (ip6h->ip6_dst.s6_addr16[i] >> 16) & 0xFFFF;
+ 		sum += (ip6h->ip6_dst.s6_addr16[i]) & 0xFFFF;
+ 	}
+-	sum += htons(IPPROTO_TCP);
++	sum += htons(protocol_id);
+ 	sum += htons(ip6h->ip6_plen);
+ 
+ 	return checksum(sum, (uint16_t *)payload, len);
+Index: libnetfilter_queue-1.0.2/src/extra/tcp.c
+===================================================================
+--- libnetfilter_queue-1.0.2.orig/src/extra/tcp.c
++++ libnetfilter_queue-1.0.2/src/extra/tcp.c
+@@ -91,7 +91,7 @@ nfq_tcp_compute_checksum_ipv4(struct tcp
+ {
+ 	/* checksum field in header needs to be zero for calculation. */
+ 	tcph->check = 0;
+-	tcph->check = checksum_tcpudp_ipv4(iph);
++	tcph->check = checksum_tcpudp_ipv4(iph, IPPROTO_TCP);
+ }
+ EXPORT_SYMBOL(nfq_tcp_compute_checksum_ipv4);
+ 
+@@ -105,7 +105,7 @@ nfq_tcp_compute_checksum_ipv6(struct tcp
+ {
+ 	/* checksum field in header needs to be zero for calculation. */
+ 	tcph->check = 0;
+-	tcph->check = checksum_tcpudp_ipv6(ip6h, tcph);
++	tcph->check = checksum_tcpudp_ipv6(ip6h, tcph, IPPROTO_TCP);
+ }
+ EXPORT_SYMBOL(nfq_tcp_compute_checksum_ipv6);
+ 
+Index: libnetfilter_queue-1.0.2/src/extra/udp.c
+===================================================================
+--- libnetfilter_queue-1.0.2.orig/src/extra/udp.c
++++ libnetfilter_queue-1.0.2/src/extra/udp.c
+@@ -91,7 +91,7 @@ nfq_udp_compute_checksum_ipv4(struct udp
+ {
+ 	/* checksum field in header needs to be zero for calculation. */
+ 	udph->check = 0;
+-	udph->check = checksum_tcpudp_ipv4(iph);
++	udph->check = checksum_tcpudp_ipv4(iph, IPPROTO_UDP);
+ }
+ EXPORT_SYMBOL(nfq_udp_compute_checksum_ipv4);
+ 
+@@ -110,7 +110,7 @@ nfq_udp_compute_checksum_ipv6(struct udp
+ {
+ 	/* checksum field in header needs to be zero for calculation. */
+ 	udph->check = 0;
+-	udph->check = checksum_tcpudp_ipv6(ip6h, udph);
++	udph->check = checksum_tcpudp_ipv6(ip6h, udph, IPPROTO_UDP);
+ }
+ EXPORT_SYMBOL(nfq_udp_compute_checksum_ipv6);
+ 
+Index: libnetfilter_queue-1.0.2/src/internal.h
+===================================================================
+--- libnetfilter_queue-1.0.2.orig/src/internal.h
++++ libnetfilter_queue-1.0.2/src/internal.h
+@@ -13,8 +13,8 @@ struct iphdr;
+ struct ip6_hdr;
+ 
+ uint16_t checksum(uint32_t sum, uint16_t *buf, int size);
+-uint16_t checksum_tcpudp_ipv4(struct iphdr *iph);
+-uint16_t checksum_tcpudp_ipv6(struct ip6_hdr *ip6h, void *transport_hdr);
++uint16_t checksum_tcpudp_ipv4(struct iphdr *iph, uint16_t protocol_id);
++uint16_t checksum_tcpudp_ipv6(struct ip6_hdr *ip6h, void *transport_hdr, uint16_t protocol_id);
+ 
+ struct pkt_buff {
+ 	uint8_t *mac_header;
-- 
1.7.12.4



From alin.nastac at gmail.com  Wed Jun 15 07:30:06 2016
From: alin.nastac at gmail.com (Alin Nastac)
Date: Wed, 15 Jun 2016 16:30:06 +0200
Subject: [LEDE-DEV] [PATCH] [NG-57971] libnetfilter_queue: fix UDP checksum
	computation
Message-ID: <1466001006-14923-1-git-send-email-alin.nastac@gmail.com>

This patch was copied from
http://www.spinics.net/lists/netfilter/msg56704.html .

Signed-off-by: Alin Nastac <alin.nastac at gmail.com>
---
 .../patches/100-udp_checksum_computation.patch     | 95 ++++++++++++++++++++++
 1 file changed, 95 insertions(+)
 create mode 100644 package/libs/libnetfilter-queue/patches/100-udp_checksum_computation.patch

diff --git a/package/libs/libnetfilter-queue/patches/100-udp_checksum_computation.patch b/package/libs/libnetfilter-queue/patches/100-udp_checksum_computation.patch
new file mode 100644
index 0000000..9939b83
--- /dev/null
+++ b/package/libs/libnetfilter-queue/patches/100-udp_checksum_computation.patch
@@ -0,0 +1,95 @@
+--- libnetfilter_queue-1.0.2.orig/src/extra/checksum.c
++++ libnetfilter_queue-1.0.2/src/extra/checksum.c
+@@ -35,7 +35,7 @@ uint16_t checksum(uint32_t sum, uint16_t
+ 	return (uint16_t)(~sum);
+ }
+ 
+-uint16_t checksum_tcpudp_ipv4(struct iphdr *iph)
++uint16_t checksum_tcpudp_ipv4(struct iphdr *iph, uint16_t protocol_id)
+ {
+ 	uint32_t sum = 0;
+ 	uint32_t iph_len = iph->ihl*4;
+@@ -46,13 +46,13 @@ uint16_t checksum_tcpudp_ipv4(struct iph
+ 	sum += (iph->saddr) & 0xFFFF;
+ 	sum += (iph->daddr >> 16) & 0xFFFF;
+ 	sum += (iph->daddr) & 0xFFFF;
+-	sum += htons(IPPROTO_TCP);
++	sum += htons(protocol_id);
+ 	sum += htons(len);
+ 
+ 	return checksum(sum, (uint16_t *)payload, len);
+ }
+ 
+-uint16_t checksum_tcpudp_ipv6(struct ip6_hdr *ip6h, void *transport_hdr)
++uint16_t checksum_tcpudp_ipv6(struct ip6_hdr *ip6h, void *transport_hdr, uint16_t protocol_id)
+ {
+ 	uint32_t sum = 0;
+ 	uint32_t hdr_len = (uint32_t *)transport_hdr - (uint32_t *)ip6h;
+@@ -68,7 +68,7 @@ uint16_t checksum_tcpudp_ipv6(struct ip6
+ 		sum += (ip6h->ip6_dst.s6_addr16[i] >> 16) & 0xFFFF;
+ 		sum += (ip6h->ip6_dst.s6_addr16[i]) & 0xFFFF;
+ 	}
+-	sum += htons(IPPROTO_TCP);
++	sum += htons(protocol_id);
+ 	sum += htons(ip6h->ip6_plen);
+ 
+ 	return checksum(sum, (uint16_t *)payload, len);
+Index: libnetfilter_queue-1.0.2/src/extra/tcp.c
+===================================================================
+--- libnetfilter_queue-1.0.2.orig/src/extra/tcp.c
++++ libnetfilter_queue-1.0.2/src/extra/tcp.c
+@@ -91,7 +91,7 @@ nfq_tcp_compute_checksum_ipv4(struct tcp
+ {
+ 	/* checksum field in header needs to be zero for calculation. */
+ 	tcph->check = 0;
+-	tcph->check = checksum_tcpudp_ipv4(iph);
++	tcph->check = checksum_tcpudp_ipv4(iph, IPPROTO_TCP);
+ }
+ EXPORT_SYMBOL(nfq_tcp_compute_checksum_ipv4);
+ 
+@@ -105,7 +105,7 @@ nfq_tcp_compute_checksum_ipv6(struct tcp
+ {
+ 	/* checksum field in header needs to be zero for calculation. */
+ 	tcph->check = 0;
+-	tcph->check = checksum_tcpudp_ipv6(ip6h, tcph);
++	tcph->check = checksum_tcpudp_ipv6(ip6h, tcph, IPPROTO_TCP);
+ }
+ EXPORT_SYMBOL(nfq_tcp_compute_checksum_ipv6);
+ 
+Index: libnetfilter_queue-1.0.2/src/extra/udp.c
+===================================================================
+--- libnetfilter_queue-1.0.2.orig/src/extra/udp.c
++++ libnetfilter_queue-1.0.2/src/extra/udp.c
+@@ -91,7 +91,7 @@ nfq_udp_compute_checksum_ipv4(struct udp
+ {
+ 	/* checksum field in header needs to be zero for calculation. */
+ 	udph->check = 0;
+-	udph->check = checksum_tcpudp_ipv4(iph);
++	udph->check = checksum_tcpudp_ipv4(iph, IPPROTO_UDP);
+ }
+ EXPORT_SYMBOL(nfq_udp_compute_checksum_ipv4);
+ 
+@@ -110,7 +110,7 @@ nfq_udp_compute_checksum_ipv6(struct udp
+ {
+ 	/* checksum field in header needs to be zero for calculation. */
+ 	udph->check = 0;
+-	udph->check = checksum_tcpudp_ipv6(ip6h, udph);
++	udph->check = checksum_tcpudp_ipv6(ip6h, udph, IPPROTO_UDP);
+ }
+ EXPORT_SYMBOL(nfq_udp_compute_checksum_ipv6);
+ 
+Index: libnetfilter_queue-1.0.2/src/internal.h
+===================================================================
+--- libnetfilter_queue-1.0.2.orig/src/internal.h
++++ libnetfilter_queue-1.0.2/src/internal.h
+@@ -13,8 +13,8 @@ struct iphdr;
+ struct ip6_hdr;
+ 
+ uint16_t checksum(uint32_t sum, uint16_t *buf, int size);
+-uint16_t checksum_tcpudp_ipv4(struct iphdr *iph);
+-uint16_t checksum_tcpudp_ipv6(struct ip6_hdr *ip6h, void *transport_hdr);
++uint16_t checksum_tcpudp_ipv4(struct iphdr *iph, uint16_t protocol_id);
++uint16_t checksum_tcpudp_ipv6(struct ip6_hdr *ip6h, void *transport_hdr, uint16_t protocol_id);
+ 
+ struct pkt_buff {
+ 	uint8_t *mac_header;
-- 
1.7.12.4



From dave.taht at gmail.com  Mon Jun 13 09:13:49 2016
From: dave.taht at gmail.com (Dave Taht)
Date: Mon, 13 Jun 2016 09:13:49 -0700
Subject: [LEDE-DEV] Fwd: ultrafast broadband conference june 27-30
In-Reply-To: <CAA93jw4UPnTR8geArA0RdL1Z=ksTb6UiVhvi7EANo10NgZBtDg@mail.gmail.com>
References: <CAA93jw4UPnTR8geArA0RdL1Z=ksTb6UiVhvi7EANo10NgZBtDg@mail.gmail.com>
Message-ID: <CAA93jw6sPTT7kO3MiDfhUZLa-niDfEEcUO95TqyBeEu-=j+CKw@mail.gmail.com>

Anyone from lede going to this?

http://www.ultrafastbroadband.nl/

I see there is a "carrier grade openwrt" talk...

http://www.ultrafastbroadband.nl/schedule/



---------- Forwarded message ----------
From: Dave Taht <dave.taht at gmail.com>
Date: Mon, Jun 13, 2016 at 9:05 AM
Subject: ultrafast broadband conference june 27-30
To: bloat <bloat at lists.bufferbloat.net>


Is anyone going to this? I sure hope the g.fast technologies have
their uplink bloat fixed, at least.

http://www.ultrafastbroadband.nl/

--
Dave T?ht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org


-- 
Dave T?ht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org


From xinxing.huchn at gmail.com  Wed Jun 15 07:35:31 2016
From: xinxing.huchn at gmail.com (Xinxing Hu)
Date: Wed, 15 Jun 2016 16:35:31 +0200
Subject: [LEDE-DEV] [PATCH] uloop: use a waker for notifying sigchld and
 loop cancel events
Message-ID: <CAMAB+h_J+YbitQuWjxfi9U1+8LCRXT6nF9HKjJQ1DhvQzysa8w@mail.gmail.com>

Hi Mats,

I think you should try the latest one. Felix made a mistake in this
commit and waker_pipe was not initialized correctly.

Best Regards,
Xinxing


> Date: Wed, 15 Jun 2016 15:07:25 +0200
> From: Mats Karrman <mats.dev.list at gmail.com>
> To: Yousong Zhou <yszhou4tech at gmail.com>, Felix Fietkau <nbd at nbd.name>
> Cc: lede-dev at lists.infradead.org
> Subject: Re: [LEDE-DEV] [PATCH] uloop: use a waker for notifying
>         sigchld and loop cancel events
> Message-ID: <5761530D.6010509 at gmail.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
>
> On 2016-06-15 13:20, Yousong Zhou wrote:
>> On 15 June 2016 at 17:58, Felix Fietkau <nbd at nbd.name> wrote:
>>> On 2016-06-09 04:20, Yousong Zhou wrote:
>>>> Fix a race condition when do_sigchld, uloop_cancelled were set just
>>>> before epoll_wait(timeout=-1), resulting the loop stuck in the syscall
>>>> without noticing the events just happened
>>>>
>>>> Signed-off-by: Yousong Zhou <yszhou4tech at gmail.com>
>>> I found a few bugs and inconsistencies in that patch, and pushed a
>>> fixed version here:
>>> https://git.lede-project.org/?p=project/libubox.git;a=commitdiff;h=4e3a47a4cb438866bc4b9cb2f5d16226ffb48502
>>>
>>> Please review and test it some more before I push an update to LEDE.
>>>
>>> Thanks,
>>>
>>> - Felix
>> Ack from me.
>>
>> The patch looks better.  Thanks
>>
>>                  yousong
> Tried this version together with procd-2016-03-09
> (b12bb150ed38a4409bef5127c77b060ee616b860)
> but I still see the same behavior/error.
>
> BR // Mats
>
>
>
> ------------------------------
>

-- 
Sincerely
Xinxing Hu


From mats.dev.list at gmail.com  Wed Jun 15 07:54:53 2016
From: mats.dev.list at gmail.com (Mats Karrman)
Date: Wed, 15 Jun 2016 16:54:53 +0200
Subject: [LEDE-DEV] [PATCH] uloop: use a waker for notifying sigchld and
 loop cancel events
In-Reply-To: <02a2e110-8b78-d4a0-40ce-5e780073c83e@nbd.name>
References: <1465438832-20133-1-git-send-email-yszhou4tech@gmail.com>
 <5761226A.5070404@conorogorman.net>
 <f0d60d41-75a7-0cf5-2f37-ff0915d2b44f@nbd.name>
 <CAJLcKsFNT3uXTkYihzQYQ0HoQ7oc=FKArLOTR6OSe0WCPMCjTw@mail.gmail.com>
 <02a2e110-8b78-d4a0-40ce-5e780073c83e@nbd.name>
Message-ID: <57616C3D.5020905@gmail.com>


On 2016-06-15 15:16, Felix Fietkau wrote:
> On 2016-06-15 15:13, Hans Dedecker wrote:  >> On Wed, Jun 15, 2016 at 11:58 AM, Felix Fietkau <nbd at nbd.name> >> 
wrote: >>> On 2016-06-15 11:39, Conor O'Gorman wrote: >>>> On 09/06/16 
03:20, Yousong Zhou wrote: >>>>> Fix a race condition when do_sigchld, 
uloop_cancelled were >>>>> set just before epoll_wait(timeout=-1), 
resulting the loop >>>>> stuck in the syscall without noticing the 
events just >>>>> happened >>>>> >>>>> Signed-off-by: Yousong Zhou 
<yszhou4tech at gmail.com> --- >>>>> uloop-epoll.c  |  2 +- uloop-kqueue.c 
|  2 +- uloop.c >>>>> | 65 >>>>> 
++++++++++++++++++++++++++++++++++++++++++++++++++++++---- 3 >>>>> files 
changed, 63 insertions(+), 6 deletions(-) >>>>> >>>> Why not change the 
timeout? >>> Changing the timeout would not fix the race, and it would 
lead >>> to unnecessary process wakeups and extra latency for signal >>> 
processing. >>> >>> - Felix >>> >>> 
_______________________________________________ Lede-dev mailing >>> 
list Lede-dev at lists.infradead.org >>> 
http://lists.infradead.org/mailman/listinfo/lede-dev >> Could it be that 
the wiker_pipe does not get properly initialized >> as waker_pipe never 
is assigned a fd value ? > I accidentally dropped that in a copy&paste 
screwup. Fix pushed to > git. > > Thanks, > > - Felix
Ran 118 reboots with this fix without any problem so there is a good 
chance that
the latest version of libubox (c2f2c47f3e9a2d709ec82a79f6fadd3124c18781)
finally fixed the issue.
:-) // Mats



From nbd at nbd.name  Wed Jun 15 08:01:57 2016
From: nbd at nbd.name (Felix Fietkau)
Date: Wed, 15 Jun 2016 17:01:57 +0200
Subject: [LEDE-DEV] [PATCH] uloop: use a waker for notifying sigchld and
 loop cancel events
In-Reply-To: <57616C3D.5020905@gmail.com>
References: <1465438832-20133-1-git-send-email-yszhou4tech@gmail.com>
 <5761226A.5070404@conorogorman.net>
 <f0d60d41-75a7-0cf5-2f37-ff0915d2b44f@nbd.name>
 <CAJLcKsFNT3uXTkYihzQYQ0HoQ7oc=FKArLOTR6OSe0WCPMCjTw@mail.gmail.com>
 <02a2e110-8b78-d4a0-40ce-5e780073c83e@nbd.name> <57616C3D.5020905@gmail.com>
Message-ID: <1b44c458-20c8-258d-0edd-703a38282415@nbd.name>

On 2016-06-15 16:54, Mats Karrman wrote:
> Ran 118 reboots with this fix without any problem so there is a good 
> chance that
> the latest version of libubox (c2f2c47f3e9a2d709ec82a79f6fadd3124c18781)
> finally fixed the issue.
> :-) // Mats
Pushed out the update to the LEDE tree, thanks for testing.

- Felix



From i at conorogorman.net  Wed Jun 15 09:07:07 2016
From: i at conorogorman.net (Conor O'Gorman)
Date: Wed, 15 Jun 2016 17:07:07 +0100
Subject: [LEDE-DEV] [PATCH mountd 2/4] fix crash if no uci config file
 present
In-Reply-To: <1465999824-20936-2-git-send-email-olivier.hardouin@gmail.com>
References: <1465999824-20936-1-git-send-email-olivier.hardouin@gmail.com>
 <1465999824-20936-2-git-send-email-olivier.hardouin@gmail.com>
Message-ID: <57617D2B.3020404@conorogorman.net>

On 15/06/16 15:10, olivier.hardouin at gmail.com wrote:
> fix also possible null dereferenced pointers
>
> Signed-off-by: Olivier Hardouin <olivier.hardouin at gmail.com>
> ---
>   uci.c  | 6 ++++++
>   ucix.c | 9 ++++++++-
>   2 files changed, 14 insertions(+), 1 deletion(-)
>
The code design appears to be that uci_init() is called before any 
others. It initialises p.
I would argue for a runtime warning and fail rather than a silent return 
for these errors?


From john at phrozen.org  Wed Jun 15 09:58:07 2016
From: john at phrozen.org (John Crispin)
Date: Wed, 15 Jun 2016 18:58:07 +0200
Subject: [LEDE-DEV] [PATCH mountd 2/4] fix crash if no uci config file
 present
In-Reply-To: <57617D2B.3020404@conorogorman.net>
References: <1465999824-20936-1-git-send-email-olivier.hardouin@gmail.com>
 <1465999824-20936-2-git-send-email-olivier.hardouin@gmail.com>
 <57617D2B.3020404@conorogorman.net>
Message-ID: <049ca8cc-9e30-413f-c58f-f7fdbdceb2ce@phrozen.org>



On 15/06/2016 18:07, Conor O'Gorman wrote:
> On 15/06/16 15:10, olivier.hardouin at gmail.com wrote:
>> fix also possible null dereferenced pointers
>>
>> Signed-off-by: Olivier Hardouin <olivier.hardouin at gmail.com>
>> ---
>>   uci.c  | 6 ++++++
>>   ucix.c | 9 ++++++++-
>>   2 files changed, 14 insertions(+), 1 deletion(-)
>>
> The code design appears to be that uci_init() is called before any
> others. It initialises p.
> I would argue for a runtime warning and fail rather than a silent return
> for these errors?
> 

not worth the effort, i plan to rewrite this as part of the block tool
and nuke mountd.

	John


From eschultz at prplfoundation.org  Wed Jun 15 11:40:27 2016
From: eschultz at prplfoundation.org (Eric Schultz)
Date: Wed, 15 Jun 2016 13:40:27 -0500
Subject: [LEDE-DEV] In-person TR-069 & OpenWrt Meeting - June 28 & 29
Message-ID: <5761A11B.1050305@prplfoundation.org>

I'm happy to announce that an in-person meeting on TR-069 and OpenWrt
will occur on June 28 & June 29 at Softathome's office in Paris. We'll
further discuss the current implementations of TR-069 and other
protocols and develop a clear plan forward that meets needs of everyone
in the community as best as possible. While most of the discussion will
happen in person, I'll do what I can to keep everyone who isn't there
involved in the discussion (I'd welcome suggestions on ways to do this
on short notice!).

Since Wojtek needs a count in order to reserve a meeting room in
advance, please RSVP as soon as possible. We'll also talk about this
more at the TR-069 and OpenWrt Fuze meeting this Friday at 7AM PT
(announcement to come soon).

Thanks all,

Eric
-- 
Eric Schultz, Community Manager, prpl Foundation
http://www.prplfoundation.org
eschultz at prplfoundation.org
cell: 920-539-0404
skype: ericschultzwi
@EricPrpl


From eschultz at prplfoundation.org  Wed Jun 15 13:28:02 2016
From: eschultz at prplfoundation.org (Eric Schultz)
Date: Wed, 15 Jun 2016 15:28:02 -0500
Subject: [LEDE-DEV] TR-069 and OpenWrt Fuze Meeting - June 17, 7AM PT
Message-ID: <5761BA52.8030806@prplfoundation.org>

As mentioned at last week's meeting, I wanted to announce that we'll
have another discussion on TR-069 and OpenWrt on Fuze on Friday June 17
at 7AM PT. We'll discuss any steps that need to be taken before the
in-person meeting and, depending on time, address other topics.

I've contacted Fuze and it seems like the new connection info I have
below fixes the problems we had this week. It works on Firefox and
Chrome on both Windows and Linux. Apologies again for the problems last
week.

I'm looking forward to seeing everyone there.

Thanks,

Eric

--
To join the web meeting click or copy and paste this URL into your browser:


https://fuzemeeting.com/browser/#login and enter you name and the
meeting number: 32924366

To join the audio portion of this meeting:

Internet Audio: Simply select the internet audio option after joining.

Toll / Intl #: +12014794595

Toll free #: +18553463893

You can find international access numbers at
https://www.fuze.com/extras/symphony

If prompted, enter the meeting number: 32924366, then press #.

For the optimal experience, download Fuze:
www.fuzebox.com/products/download

Need help? You can connect to our Customer Support Team or access
self-help tools at www.fuzebox.com/support
-- 
Eric Schultz, Community Manager, prpl Foundation
http://www.prplfoundation.org
eschultz at prplfoundation.org
cell: 920-539-0404
skype: ericschultzwi
@EricPrpl


From eschultz at prplfoundation.org  Wed Jun 15 13:31:37 2016
From: eschultz at prplfoundation.org (Eric Schultz)
Date: Wed, 15 Jun 2016 15:31:37 -0500
Subject: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
Message-ID: <5761BB29.8020303@prplfoundation.org>

As we continue the TR-069 support discussion, I wanted to ask folks
whether they want me to continue to cross post to these list in addition
to the prplwrt list at openwrt at lists.prplfoundation.org. I have no
problem doing either way, but I don't want to fill people's inbox will
stuff they feel is off topic. Just wanted to get a sense of what people
would prefer.

Thanks,

Eric
-- 
Eric Schultz, Community Manager, prpl Foundation
http://www.prplfoundation.org
eschultz at prplfoundation.org
cell: 920-539-0404
skype: ericschultzwi
@EricPrpl


From drew at nixcores.com  Wed Jun 15 13:35:13 2016
From: drew at nixcores.com (Drew from NixCore)
Date: Wed, 15 Jun 2016 16:35:13 -0400
Subject: [LEDE-DEV] [PATCH] [ramips] Added NixCore X1 target V4
Message-ID: <5761BC01.5080409@nixcores.com>

Added NixCore X1 ramips targethttp://nixcores.com. <http://nixcores.com./>  This builds 8M and 16M images.  V4 updates the patch to fix whitespace issues in V3

Signed-off-by: Drew Gaylo <drew at nixcores.com>
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network b/target/linux/ramips/base-files/etc/board.d/02_network
index 4728c75..69c0125 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -77,6 +77,7 @@ ramips_setup_interfaces()
  	mt7628|\
  	mzk-750dhp|\
  	mzk-w300nh2|\
+	nixcore|\
  	oy-0001|\
  	pbr-m1|\
  	psg1208|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh b/target/linux/ramips/base-files/lib/ramips.sh
index cbe455d..76f0e43 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -316,6 +316,9 @@ ramips_board_detect() {
  	*"NCS601W")
  		name="ncs601w"
  		;;
+    *"NixcoreX1")
+		name="nixcore-x1"
+		;;
  	*"NW718")
  		name="nw718"
  		;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 91c9997..0094568 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -94,6 +94,7 @@ platform_check_image() {
  	mzk-w300nh2|\
  	mzk-wdpr|\
  	nbg-419n|\
+    nixcore|\
  	nw718|\
  	oy-0001|\
  	pbr-m1|\
diff --git a/target/linux/ramips/dts/NIXCOREX1-16M.dts b/target/linux/ramips/dts/NIXCOREX1-16M.dts
new file mode 100644
index 0000000..1e1a205
--- /dev/null
+++ b/target/linux/ramips/dts/NIXCOREX1-16M.dts
@@ -0,0 +1,182 @@
+/dts-v1/;
+
+/include/ "rt5350.dtsi"
+
+/ {
+	compatible = "NixcoreX1", "ralink,rt5350-soc";
+	model = "NixcoreX1";
+
+    chosen{
+        bootargs = "console=ttyS1,57600";
+    };
+
+    gpio-export {
+        compatible = "gpio-export";
+        #size-cells = <0>;
+
+        gpio0 {
+            gpio-export,name = "gpio0";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio0 0 0>;
+        };
+        /* GPIOs 1-6 are I2C,SPI */
+
+        /* GPIO 7-14 are uart1 */
+
+        /* GPIOs 15 & 16 are uart2 */
+
+		/* JTAG */
+		gpio17 {
+			/* JTAG_TDO */
+			gpio-export,name = "gpio17";
+			gpio-export,direction_may_change = <1>;
+			gpios = <&gpio0 17 0>;
+		};
+		gpio18 {
+			/* JTAG_TDI */
+			gpio-export,name = "gpio18";
+			gpio-export,direction_may_change = <1>;
+			gpios = <&gpio0 18 0>;
+		};
+		gpio19 {
+			/* JTAG_TMS */
+			gpio-export,name = "gpio19";
+			gpio-export,direction_may_change = <1>;
+			gpios = <&gpio0 19 0>;
+		};
+		gpio20 {
+			/* JTAG_TCLK */
+			gpio-export,name = "gpio20";
+			gpio-export,direction_may_change = <1>;
+			gpios = <&gpio0 20 0>;
+		};
+		gpio21 {
+			/* JTAG_TRST_N */
+			gpio-export,name = "gpio21";
+			gpio-export,direction_may_change = <1>;
+			gpios = <&gpio0 21 0>;
+		};
+
+		/* ETH LEDs */
+        /*
+        gpio22 {
+			gpio-export,name = "gpio22";
+			gpio-export,direction_may_change = <1>;
+			gpios = <&gpio1 0 0>;
+		};
+        gpio23 {
+			gpio-export,name = "gpio23";
+			gpio-export,direction_may_change = <1>;
+			gpios = <&gpio1 1 0>;
+		};
+        gpio24 {
+			gpio-export,name = "gpio24";
+			gpio-export,direction_may_change = <1>;
+			gpios = <&gpio1 2 0>;
+		};
+		gpio25 {
+			gpio-export,name = "gpio25";
+			gpio-export,direction_may_change = <1>;
+			gpios = <&gpio1 3 0>;
+		};
+        */
+
+		gpio26 {
+			/* ETH4_LED */
+			gpio-export,name = "gpio26";
+			gpio-export,direction_may_change = <1>;
+			gpios = <&gpio1 4 0>;
+		};
+
+        gpio27 {
+			/* spi_cs1 */
+			gpio-export,name = "gpio27";
+			gpio-export,direction_may_change = <1>;
+			gpios = <&gpio1 5 0>;
+		};
+    };
+
+};
+
+&gpio0{
+    status = "okay";
+};
+
+&gpio1{
+    status = "okay";
+};
+
+&i2c{
+    status = "okay";
+};
+&uart{
+    status = "okay";
+    /* Mix of uart and gpio */
+    reset-names = "gpio uartf";
+};
+&spi0{
+    status = "okay";
+
+    m25p80 at 0 {
+        #address-cells = <1>;
+        #size-cells = <1>;
+        compatible = "s25fl064k";
+        reg = <0>;
+        linux,modalias = "m25p80", "s25fl064k";
+        spi-max-frequency = <10000000>;
+
+        partition at 0 {
+            label = "uboot";
+            reg = <0x0 0x30000>;
+            read-only;
+        };
+
+        partition at 30000 {
+            label = "uboot-env";
+            reg = <0x30000 0x10000>;
+            read-only;
+        };
+
+        factory: partition at 40000 {
+            label = "factory";
+            reg = <0x40000 0x10000>;
+            read-only;
+        };
+
+        partition at 50000 {
+            label = "firmware";
+            reg = <0x50000 0xfb0000>;
+        };
+    };
+};
+
+&pinctrl {
+    state_default: pinctrl0 {
+        gpio {
+            /* Associate the tjag, uartf and led groups with gpio */
+            ralink,group = "jtag", "led", "spi_cs1";
+            /* How do we set individual pins? */
+            ralink,function = "gpio";
+        };
+    };
+};
+
+&ethernet {
+    mtd-mac-address = <&factory 0x4>;
+};
+
+&esw {
+    ralink,portmap = <0x17>;
+};
+
+&wmac {
+    ralink,mtd-eeprom = <&factory 0>;
+};
+
+&ehci {
+    status = "okay";
+};
+
+&ohci {
+    status = "okay";
+};
diff --git a/target/linux/ramips/dts/NIXCOREX1-8M.dts b/target/linux/ramips/dts/NIXCOREX1-8M.dts
new file mode 100644
index 0000000..c514860
--- /dev/null
+++ b/target/linux/ramips/dts/NIXCOREX1-8M.dts
@@ -0,0 +1,183 @@
+/dts-v1/;
+
+/include/ "rt5350.dtsi"
+
+/ {
+	compatible = "NixcoreX1", "ralink,rt5350-soc";
+	model = "NixcoreX1";
+
+    chosen{
+        bootargs = "console=ttyS1,57600";
+    };
+
+    gpio-export {
+        compatible = "gpio-export";
+        #size-cells = <0>;
+
+        gpio0 {
+            gpio-export,name = "gpio0";
+            gpio-export,direction_may_change = <1>;
+            gpios = <&gpio0 0 0>;
+        };
+        /* GPIOs 1-6 are I2C,SPI */
+
+        /* GPIO 7-14 are uart1 */
+
+        /* GPIOs 15 & 16 are uart2 */
+
+		/* JTAG */
+		gpio17 {
+			/* JTAG_TDO */
+			gpio-export,name = "gpio17";
+			gpio-export,direction_may_change = <1>;
+			gpios = <&gpio0 17 0>;
+		};
+		gpio18 {
+			/* JTAG_TDI */
+			gpio-export,name = "gpio18";
+			gpio-export,direction_may_change = <1>;
+			gpios = <&gpio0 18 0>;
+		};
+		gpio19 {
+			/* JTAG_TMS */
+			gpio-export,name = "gpio19";
+			gpio-export,direction_may_change = <1>;
+			gpios = <&gpio0 19 0>;
+		};
+		gpio20 {
+			/* JTAG_TCLK */
+			gpio-export,name = "gpio20";
+			gpio-export,direction_may_change = <1>;
+			gpios = <&gpio0 20 0>;
+		};
+		gpio21 {
+			/* JTAG_TRST_N */
+			gpio-export,name = "gpio21";
+			gpio-export,direction_may_change = <1>;
+			gpios = <&gpio0 21 0>;
+		};
+
+		/* ETH LEDs */
+        /*
+        gpio22 {
+			gpio-export,name = "gpio22";
+			gpio-export,direction_may_change = <1>;
+			gpios = <&gpio1 0 0>;
+		};
+        gpio23 {
+			gpio-export,name = "gpio23";
+			gpio-export,direction_may_change = <1>;
+			gpios = <&gpio1 1 0>;
+		};
+        gpio24 {
+			gpio-export,name = "gpio24";
+			gpio-export,direction_may_change = <1>;
+			gpios = <&gpio1 2 0>;
+		};
+		gpio25 {
+			gpio-export,name = "gpio25";
+			gpio-export,direction_may_change = <1>;
+			gpios = <&gpio1 3 0>;
+		};
+        */
+
+		gpio26 {
+			/* ETH4_LED */
+			gpio-export,name = "gpio26";
+			gpio-export,direction_may_change = <1>;
+			gpios = <&gpio1 4 0>;
+		};
+
+        gpio27 {
+			/* spi_cs1 */
+			gpio-export,name = "gpio27";
+			gpio-export,direction_may_change = <1>;
+			gpios = <&gpio1 5 0>;
+		};
+    };
+
+};
+
+&gpio0{
+    status = "okay";
+};
+
+&gpio1{
+    status = "okay";
+};
+
+&i2c{
+    status = "okay";
+};
+&uart{
+    status = "okay";
+    /* Mix of uart and gpio */
+    reset-names = "gpio uartf";
+};
+&spi0{
+    status = "okay";
+
+    m25p80 at 0 {
+        #address-cells = <1>;
+        #size-cells = <1>;
+        compatible = "s25fl064k";
+        reg = <0>;
+        linux,modalias = "m25p80", "s25fl064k";
+        spi-max-frequency = <10000000>;
+
+        partition at 0 {
+            label = "uboot";
+            reg = <0x0 0x30000>;
+            read-only;
+        };
+
+        partition at 30000 {
+            label = "uboot-env";
+            reg = <0x30000 0x10000>;
+            read-only;
+        };
+
+        factory: partition at 40000 {
+            label = "factory";
+            reg = <0x40000 0x10000>;
+            read-only;
+        };
+
+        partition at 50000 {
+            label = "firmware";
+            reg = <0x50000 0x7b0000>;
+        };
+    };
+};
+
+&pinctrl {
+    state_default: pinctrl0 {
+        gpio {
+            /* Associate the tjag, uartf and led groups with gpio */
+            ralink,group = "jtag", "led", "spi_cs1";
+            /* How do we set individual pins? */
+            ralink,function = "gpio";
+        };
+    };
+};
+
+&ethernet {
+    mtd-mac-address = <&factory 0x4>;
+};
+
+&esw {
+    ralink,portmap = <0x17>;
+};
+
+&wmac {
+    ralink,mtd-eeprom = <&factory 0>;
+};
+
+&ehci {
+    status = "okay";
+};
+
+&ohci {
+    status = "okay";
+};
+
diff --git a/target/linux/ramips/image/rt305x.mk b/target/linux/ramips/image/rt305x.mk
index da7fc46..db12a8e 100644
--- a/target/linux/ramips/image/rt305x.mk
+++ b/target/linux/ramips/image/rt305x.mk
@@ -100,6 +100,21 @@ define BuildFirmware/HLKRM04/initramfs
  	mkhilinkfw -e -i$(call imgname,$(1),$(2))-uImage.bin -o $(call imgname,$(1),$(2))-factory.bin;
  endef
  
+# This is called to build the nixcore image.  Build both 8MB and 16MB
+nixcore_8mb_mtd_size=8060928
+nixcore_16mb_mtd_size=16449536
+define BuildFirmware/NIXCOREX1/squashfs
+# Args are XXX, nixcore-mM and NIXCOREX1-xM
+	$(call BuildFirmware/CustomFlash/$(1),$(1),$(2)-8M,$(3)-8M,$(nixcore_8mb_mtd_size))
+	$(call BuildFirmware/CustomFlash/$(1),$(1),$(2)-16M,$(3)-16M,$(nixcore_16mb_mtd_size))
+	# Can do somethings here after the build?
+endef
+define BuildFirmware/NIXCOREX1/initramfs
+# Args are XXXX, nixcore-mM and NIXCOREX1-xM
+	$(call BuildFirmware/OF/initramfs,$(1),$(2)-8M,$(3)-8M)
+	$(call BuildFirmware/OF/initramfs,$(1),$(2)-16M,$(3)-16M)
+endef
+
  vocore_8mb_mtd_size=8060928
  vocore_16mb_mtd_size=16449536
  define BuildFirmware/VOCORE/squashfs
@@ -257,6 +272,7 @@ Image/Build/Profile/NBG-419N=$(call BuildFirmware/Default4M/$(1),$(1),nbg-419n,N
  Image/Build/Profile/MZKW300NH2=$(call BuildFirmware/Edimax/$(1),$(1),mzk-w300nh2,MZK-W300NH2,$(mzkw300nh2_mtd_size),CSYS,RN52,0x50000,0xc0000)
  Image/Build/Profile/MZKWDPR=$(call BuildFirmware/Default8M/$(1),$(1),mzk-wdpr,MZK-WDPR)
  Image/Build/Profile/NCS601W=$(call BuildFirmware/Default8M/$(1),$(1),ncs601W,NCS601W)
+Image/Build/Profile/NIXCOREX1=$(call BuildFirmware/NIXCOREX1/$(1),$(1),nixcorex1,NIXCOREX1)
  nw718_mtd_size=3801088
  Image/Build/Profile/NW718=$(call BuildFirmware/CustomFlashFactory/$(1),$(1),nw718m,NW718,$(nw718_mtd_size),ARA1B4NCRNW718;1,factory)
  Image/Build/Profile/M2M=$(call BuildFirmware/Default8M/$(1),$(1),m2m,M2M,Linux Kernel Image)
@@ -353,6 +369,7 @@ define Image/Build/Profile/Default
  	$(call Image/Build/Profile/MZKWDPR,$(1))
  	$(call Image/Build/Profile/NBG-419N,$(1))
  	$(call Image/Build/Profile/NCS601W,$(1))
+	$(call Image/Build/Profile/NIXCOREX1,$(1))
  	$(call Image/Build/Profile/NW718,$(1))
  	$(call Image/Build/Profile/MINIEMBWIFI,$(1))
  	$(call Image/Build/Profile/MINIEMBPLUG,$(1))
diff --git a/target/linux/ramips/rt305x/profiles/nixcore.mk b/target/linux/ramips/rt305x/profiles/nixcore.mk
new file mode 100644
index 0000000..22dee9b
--- /dev/null
+++ b/target/linux/ramips/rt305x/profiles/nixcore.mk
@@ -0,0 +1,20 @@
+#
+# Copyright (C) 2014 OpenWrt.org
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+
+define Profile/NIXCOREX1
+	NAME:=NixcoreX1
+	PACKAGES:=\
+		kmod-usb-core kmod-usb-ohci kmod-usb2 \
+		kmod-i2c-core kmod-i2c-ralink \
+		kmod-spi-dev
+endef
+
+define Profile/NIXCOREX1/Description
+	Package set for Nixcore X1 board
+endef
+
+$(eval $(call Profile,NIXCOREX1))



From psidhu at gateworks.com  Wed Jun 15 14:23:41 2016
From: psidhu at gateworks.com (Pushpal Sidhu)
Date: Wed, 15 Jun 2016 14:23:41 -0700
Subject: [LEDE-DEV] [PATCH] spinlock loop in cns3xxx_eth.c
In-Reply-To: <CAH8g=oGgex-jRdnPdh_oB_Y6qnhVjqGY80jU6+Vt+HThFoaATg@mail.gmail.com>
References: <575EDB77.4040400@ncentric.com>
 <CAJ+vNU0JxQJJZxjW+VHWDA4O-ujBh0T3ydu4GdNYtxumAFNW0A@mail.gmail.com>
 <576015E5.7060106@ncentric.com> <5761546C.8010409@ncentric.com>
 <CAD1M063s4=fvzwFixPA8-Uha8R_jp5fjQcCz_=HWNVzvumodzg@mail.gmail.com>
 <CAH8g=oGgex-jRdnPdh_oB_Y6qnhVjqGY80jU6+Vt+HThFoaATg@mail.gmail.com>
Message-ID: <CAD1M060514efEhNSWofoDEtduw60emtDgnuMG7nNat4hVM+P9A@mail.gmail.com>

Hi,

On Wed, Jun 15, 2016 at 2:16 PM, Koen Vandeputte
<koen.vandeputte at ncentric.com> wrote:
>
> Hi Pushpal,
>
> In our usecase the repro rate was 100% within a few minutes on every single board we have.
>
> Apologies for the patch format.
> it's my first commit ever to an external project so I still have some learning to do..

No worries. In general, you'll want to respond inline as well in
threads like this instead of top-posting (and send emails in
plaintext). A good starting point for patch formatting can be found
here: https://www.kernel.org/doc/Documentation/SubmittingPatches

Every project is different, so you'll have to read up on their
specific method of accepting patches.

- Pushpal

> Thanks for taking the time to verify the patch.

Thanks for providing a fix :)

- Pushpal

> Kind regards,
>
> Koen
>
> Koen,
>
> I've looked into this problem, and it does appear your patch correctly solves this issue. In the past, we've had an incredibly difficult time reproducing this issue and found that either having a perfect RF scenario or absolutely low RF scenario would not make the problem occur. Instead, I had to get the MCS to jump around in an inconsistent fashion before I could reproduce the problem. I'm not sure if this is because the processor load is going up and down or something else.
>
> However, your patch format is kind of funny. I would recommend using 'git send-email' to send your patch instead of in-lining the patch. Though that is up to whoever is going to commit this patch (probably Felix).
>
> Tested-by: Pushpal Sidhu <psidhu at gateworks.com>
>
> - Pushpal
>
> On Wed, Jun 15, 2016 at 6:13 AM, Koen Vandeputte <koen.vandeputte at ncentric.com> wrote:
>>
>> Hi All,
>>
>> I found the bug and was able to fix it.
>>
>> Tested on 4 identical gateworks gw2388-4 (cns3xxx) boards.
>>
>> - iperf in dual direction between board 1s & 2    (without patch)
>> - iperf in dual direction between board 3s & 4    (with patch)
>>
>> Boards 1 and 2 go in spinlock after a few minutes on each try
>> Boards 3 and 4 have been running for hours without the error
>>
>> To avoid any hardware delta, I retested with the patch only present on board 1 & 2
>> Board 1 & 2 now worked perfectly while 3 & 4 showed the loop issue
>>
>>
>>
>> Patch:
>>
>>
>> From 9338467c36b27bf1099dbdabd7591470c2a371df Mon Sep 17 00:00:00 2001
>> From: Koen Vandeputte <koen.vandeputte at ncentric.com>
>> Date: Wed, 15 Jun 2016 14:59:49 +0200
>> Subject: cns3xxx: fix RX softIRQ loop
>>
>> Already reschedule when 1 or more frames came in.
>>
>> Checking for a full queue could produce a re-schedule loop as
>> the checked RX ring location could contain undefined values
>> depending on activity in previous loops.
>>
>> Signed-off-by: Koen Vandeputte <koen.vandeputte at ncentric.com>
>>
>> diff --git a/target/linux/cns3xxx/files/drivers/net/ethernet/cavium/cns3xxx_eth.c b/target/linux/cns3xxx/files/drivers/net/ethernet/cavium/cns3xxx_eth.c
>> index 2f232c1..51b0187 100644
>> --- a/target/linux/cns3xxx/files/drivers/net/ethernet/cavium/cns3xxx_eth.c
>> +++ b/target/linux/cns3xxx/files/drivers/net/ethernet/cavium/cns3xxx_eth.c
>> @@ -717,8 +717,8 @@ static int eth_poll(struct napi_struct *napi, int budget)
>>          enable_irq(sw->rx_irq);
>>          budget = 0;
>>
>> -        /* if rx descriptors are full schedule another poll */
>> -        if (rx_ring->desc[(i-1) & (RX_DESCS-1)].cown)
>> +        /* If 1 or more frames came in during IRQ enable, re-schedule */
>> +        if (rx_ring->desc[i].cown)
>>              eth_schedule_poll(sw);
>>      }
>>
>>
>>
>> Kind regards,
>>
>> Koen
>>
>>
>> On 2016-06-14 16:34, Koen Vandeputte wrote:
>>>
>>> Hi Tim,
>>>
>>> I fully understand the reason for the check.
>>>
>>> However,
>>> I think the bug has nothing to do with the rotting packet issue.
>>>
>>>
>>> The bug is actually:
>>> - eth_schedule_poll() gets called as it's detected that the ring is full after IRQ_enable. (cown flag is set in the previous slot of the ring)
>>> --> During this extra loop,  _0_ packets are received/processed! The ring still seems to be full, and another reschedule takes place .. and so on ..
>>>
>>>
>>> Iv'e added 3 debug counters in the code:    (see below after the patch)
>>> - Loop --> Top of eth_poll()
>>> - IRQ --> Top of eth_rx_irq()
>>> - Resched --> Inside the reschedule check
>>>
>>>
>>>
>>>
>>> Patch:
>>>
>>> --- a/drivers/net/ethernet/cavium/cns3xxx_eth.c
>>> +++ b/drivers/net/ethernet/cavium/cns3xxx_eth.c
>>> @@ -308,6 +308,8 @@ static int ports_open;
>>>  static struct port *switch_port_tab[4];
>>>  struct net_device *napi_dev;
>>>
>>> +static int CntIRQ;
>>> +
>>>  static int cns3xxx_mdio_cmd(struct mii_bus *bus, int phy_id, int location,
>>>                 int write, u16 cmd)
>>>  {
>>> @@ -437,7 +439,10 @@ static void cns3xxx_adjust_link(struct n
>>>  static void eth_schedule_poll(struct sw *sw)
>>>  {
>>>      if (unlikely(!napi_schedule_prep(&sw->napi)))
>>> +    {
>>> +        //printk(KERN_ERR "sched err\n");
>>>          return;
>>> +    }
>>>
>>>      disable_irq_nosync(sw->rx_irq);
>>>      __napi_schedule(&sw->napi);
>>> @@ -447,6 +452,7 @@ irqreturn_t eth_rx_irq(int irq, void *pd
>>>  {
>>>      struct net_device *dev = pdev;
>>>      struct sw *sw = netdev_priv(dev);
>>> +    CntIRQ++;
>>>      eth_schedule_poll(sw);
>>>      return (IRQ_HANDLED);
>>>  }
>>> @@ -617,6 +623,7 @@ static void eth_complete_tx(struct sw *s
>>>
>>>  static int eth_poll(struct napi_struct *napi, int budget)
>>>  {
>>> +    static int Loop = 0;
>>>      struct sw *sw = container_of(napi, struct sw, napi);
>>>      struct _rx_ring *rx_ring = &sw->rx_ring;
>>>      int received = 0;
>>> @@ -712,6 +719,9 @@ static int eth_poll(struct napi_struct *
>>>      }
>>>
>>>      rx_ring->cur_index = i;
>>> +
>>> +    Loop++;
>>> +
>>>      if (!received) {
>>>          napi_complete(napi);
>>>          enable_irq(sw->rx_irq);
>>> @@ -719,7 +729,12 @@ static int eth_poll(struct napi_struct *
>>>
>>>          /* if rx descriptors are full schedule another poll */
>>>          if (rx_ring->desc[(i-1) & (RX_DESCS-1)].cown)
>>> +        {
>>> +            static int Sched = 0;
>>> +
>>> +            printk(KERN_ERR "Loop: %d irq: %d ReSched: %d\n", Loop, CntIRQ, ++Sched);
>>>              eth_schedule_poll(sw);
>>> +        }
>>>      }
>>>
>>>      spin_lock_bh(&tx_lock);
>>>
>>>
>>>
>>> When the bug triggers, you can see below that consecutive loops in eth_poll(), triggered by a reschedule, doesn't process any RX packets at all ..
>>> (As the ReSched counter increases linear with the loop counter and ReSched can only be incremented when "!received")
>>>
>>>
>>> Also
>>> Checking /proc/interrupts shows that gig_switch IRQ counter goes berserk (+10k IRQ/s)
>>>
>>>
>>> [  477.440000] Loop: 835307 irq: 300583 ReSched: 1
>>> [  477.440000] Loop: 835308 irq: 300583 ReSched: 2
>>> [  477.440000] Loop: 835310 irq: 300583 ReSched: 3
>>> [  477.440000] Loop: 835311 irq: 300583 ReSched: 4
>>> [  477.440000] Loop: 835312 irq: 300583 ReSched: 5
>>> [  477.440000] Loop: 835313 irq: 300583 ReSched: 6
>>> [  477.440000] Loop: 835314 irq: 300583 ReSched: 7
>>> [  477.440000] Loop: 835315 irq: 300583 ReSched: 8
>>> [  477.440000] Loop: 835316 irq: 300583 ReSched: 9
>>> [  477.440000] Loop: 835317 irq: 300583 ReSched: 10
>>> [  477.440000] Loop: 835318 irq: 300583 ReSched: 11
>>> [  477.440000] Loop: 835319 irq: 300583 ReSched: 12
>>> [  477.440000] Loop: 835320 irq: 300583 ReSched: 13
>>> [  477.440000] Loop: 835321 irq: 300583 ReSched: 14
>>> [  477.440000] Loop: 835322 irq: 300583 ReSched: 15
>>> [  477.440000] Loop: 835323 irq: 300583 ReSched: 16
>>> [  477.440000] Loop: 835324 irq: 300583 ReSched: 17
>>> [  477.440000] Loop: 835325 irq: 300583 ReSched: 18
>>> [  477.440000] Loop: 835326 irq: 300583 ReSched: 19
>>> [  477.440000] Loop: 835327 irq: 300583 ReSched: 20
>>> [  477.440000] Loop: 835328 irq: 300583 ReSched: 21
>>> [  477.440000] Loop: 835329 irq: 300583 ReSched: 22
>>> [  477.440000] Loop: 835330 irq: 300583 ReSched: 23
>>> [  477.440000] Loop: 835331 irq: 300583 ReSched: 24
>>> [  477.440000] Loop: 835332 irq: 300583 ReSched: 25
>>> [  477.440000] Loop: 835333 irq: 300583 ReSched: 26
>>> [  477.440000] Loop: 835334 irq: 300583 ReSched: 27
>>> [  477.440000] Loop: 835335 irq: 300583 ReSched: 28
>>> [  477.440000] Loop: 835336 irq: 300583 ReSched: 29
>>> [  477.440000] Loop: 835337 irq: 300583 ReSched: 30
>>> [  477.440000] Loop: 835338 irq: 300583 ReSched: 31
>>> [  477.440000] Loop: 835339 irq: 300583 ReSched: 32
>>> [  477.440000] Loop: 835340 irq: 300583 ReSched: 33
>>> [  477.440000] Loop: 835341 irq: 300583 ReSched: 34
>>> [  477.440000] Loop: 835342 irq: 300583 ReSched: 35
>>> [  477.440000] Loop: 835343 irq: 300583 ReSched: 36
>>> [  477.440000] Loop: 835344 irq: 300583 ReSched: 37
>>> [  477.440000] Loop: 835345 irq: 300583 ReSched: 38
>>> [  477.440000] Loop: 835346 irq: 300583 ReSched: 39
>>> [  477.440000] Loop: 835347 irq: 300583 ReSched: 40
>>> [  477.440000] Loop: 835348 irq: 300583 ReSched: 41
>>> [  477.440000] Loop: 835349 irq: 300583 ReSched: 42
>>> [  477.440000] Loop: 835350 irq: 300583 ReSched: 43
>>> [  477.440000] Loop: 835351 irq: 300583 ReSched: 44
>>> [  477.440000] Loop: 835352 irq: 300583 ReSched: 45
>>> [  477.440000] Loop: 835353 irq: 300583 ReSched: 46
>>> [  477.440000] Loop: 835354 irq: 300583 ReSched: 47
>>> [  477.440000] Loop: 835355 irq: 300583 ReSched: 48
>>> [  477.440000] Loop: 835356 irq: 300583 ReSched: 49
>>> [  477.440000] Loop: 835357 irq: 300583 ReSched: 50
>>> [  477.440000] Loop: 835358 irq: 300583 ReSched: 51
>>> [  477.440000] Loop: 835359 irq: 300583 ReSched: 52
>>> [  477.440000] Loop: 835360 irq: 300583 ReSched: 53
>>> [  477.440000] Loop: 835361 irq: 300583 ReSched: 54
>>> [  477.440000] Loop: 835362 irq: 300583 ReSched: 55
>>> [  477.440000] Loop: 835363 irq: 300583 ReSched: 56
>>> [  477.440000] Loop: 835364 irq: 300583 ReSched: 57
>>> [  477.440000] Loop: 835365 irq: 300583 ReSched: 58
>>> [  477.440000] Loop: 835366 irq: 300583 ReSched: 59
>>> [  477.440000] Loop: 835367 irq: 300583 ReSched: 60
>>> [  477.440000] Loop: 835368 irq: 300583 ReSched: 61
>>> [  477.440000] Loop: 835369 irq: 300583 ReSched: 62
>>> [  477.440000] Loop: 835370 irq: 300583 ReSched: 63
>>> [  477.440000] Loop: 835371 irq: 300583 ReSched: 64
>>> [  477.440000] Loop: 835372 irq: 300583 ReSched: 65
>>> [  477.440000] Loop: 835373 irq: 300583 ReSched: 66
>>> [  477.440000] Loop: 835374 irq: 300583 ReSched: 67
>>> [  477.440000] Loop: 835375 irq: 300583 ReSched: 68
>>> [  477.440000] Loop: 835376 irq: 300583 ReSched: 69
>>> [  477.440000] Loop: 835377 irq: 300583 ReSched: 70
>>> [  477.440000] Loop: 835378 irq: 300583 ReSched: 71
>>> [  477.440000] Loop: 835379 irq: 300583 ReSched: 72
>>> [  477.440000] Loop: 835380 irq: 300583 ReSched: 73
>>> [  477.440000] Loop: 835381 irq: 300583 ReSched: 74
>>> [  477.440000] Loop: 835382 irq: 300583 ReSched: 75
>>> [  477.440000] Loop: 835383 irq: 300583 ReSched: 76
>>> [  477.440000] Loop: 835384 irq: 300583 ReSched: 77
>>> [  477.440000] Loop: 835385 irq: 300583 ReSched: 78
>>> [  477.440000] Loop: 835386 irq: 300583 ReSched: 79
>>> [  477.440000] Loop: 835387 irq: 300583 ReSched: 80
>>> [  477.440000] Loop: 835388 irq: 300583 ReSched: 81
>>> [  477.440000] Loop: 835389 irq: 300583 ReSched: 82
>>> [  477.440000] Loop: 835390 irq: 300583 ReSched: 83
>>> [  477.440000] Loop: 835391 irq: 300583 ReSched: 84
>>> [  477.440000] Loop: 835392 irq: 300583 ReSched: 85
>>> [  477.440000] Loop: 835393 irq: 300583 ReSched: 86
>>> [  477.440000] Loop: 835394 irq: 300583 ReSched: 87
>>> [  477.440000] Loop: 835396 irq: 300583 ReSched: 88
>>> [  477.440000] Loop: 835397 irq: 300583 ReSched: 89
>>> [  477.440000] Loop: 835398 irq: 300583 ReSched: 90
>>> [  477.440000] Loop: 835399 irq: 300583 ReSched: 91
>>> [  477.440000] Loop: 835400 irq: 300583 ReSched: 92
>>> [  477.440000] Loop: 835403 irq: 300583 ReSched: 93
>>> [  477.440000] Loop: 835406 irq: 300583 ReSched: 94
>>> [  477.440000] Loop: 835407 irq: 300583 ReSched: 95
>>> [  477.440000] Loop: 835408 irq: 300583 ReSched: 96
>>> [  477.440000] Loop: 835409 irq: 300583 ReSched: 97
>>> [  477.440000] Loop: 835410 irq: 300583 ReSched: 98
>>> [  477.440000] Loop: 835411 irq: 300583 ReSched: 99
>>> [  477.440000] Loop: 835412 irq: 300583 ReSched: 100
>>> [  477.440000] Loop: 835413 irq: 300583 ReSched: 101
>>> [  477.440000] Loop: 835414 irq: 300583 ReSched: 102
>>> [  477.440000] Loop: 835415 irq: 300583 ReSched: 103
>>> [  477.440000] Loop: 835416 irq: 300583 ReSched: 104
>>> [  477.440000] Loop: 835417 irq: 300583 ReSched: 105
>>> [  477.440000] Loop: 835418 irq: 300583 ReSched: 106
>>> [  477.440000] Loop: 835419 irq: 300583 ReSched: 107
>>> [  477.440000] Loop: 835420 irq: 300583 ReSched: 108
>>> [  477.440000] Loop: 835421 irq: 300583 ReSched: 109
>>> [  477.440000] Loop: 835422 irq: 300583 ReSched: 110
>>> [  477.440000] Loop: 835423 irq: 300583 ReSched: 111
>>> [  477.440000] Loop: 835424 irq: 300583 ReSched: 112
>>> [  477.440000] Loop: 835425 irq: 300583 ReSched: 113
>>> [  477.440000] Loop: 835426 irq: 300583 ReSched: 114
>>> [  477.440000] Loop: 835427 irq: 300583 ReSched: 115
>>> [  477.440000] Loop: 835428 irq: 300583 ReSched: 116
>>> [  477.440000] Loop: 835429 irq: 300583 ReSched: 117
>>> [  477.440000] Loop: 835430 irq: 300583 ReSched: 118
>>> [  477.440000] Loop: 835431 irq: 300583 ReSched: 119
>>> [  477.440000] Loop: 835432 irq: 300583 ReSched: 120
>>> [  477.440000] Loop: 835433 irq: 300583 ReSched: 121
>>> [  477.440000] Loop: 835434 irq: 300583 ReSched: 122
>>> [  477.440000] Loop: 835435 irq: 300583 ReSched: 123
>>> [  477.440000] Loop: 835436 irq: 300583 ReSched: 124
>>> [  477.440000] Loop: 835437 irq: 300583 ReSched: 125
>>> [  477.440000] Loop: 835438 irq: 300583 ReSched: 126
>>> [  477.440000] Loop: 835439 irq: 300583 ReSched: 127
>>> [  477.440000] Loop: 835440 irq: 300583 ReSched: 128
>>> [  477.440000] Loop: 835441 irq: 300583 ReSched: 129
>>> [  477.440000] Loop: 835442 irq: 300583 ReSched: 130
>>> [  477.440000] Loop: 835443 irq: 300583 ReSched: 131
>>> [  477.440000] Loop: 835444 irq: 300583 ReSched: 132
>>> [  477.440000] Loop: 835445 irq: 300583 ReSched: 133
>>> [  477.440000] Loop: 835446 irq: 300583 ReSched: 134
>>> [  477.440000] Loop: 835447 irq: 300583 ReSched: 135
>>> [  477.440000] Loop: 835448 irq: 300583 ReSched: 136
>>> [  477.440000] Loop: 835449 irq: 300583 ReSched: 137
>>> [  477.440000] Loop: 835450 irq: 300583 ReSched: 138
>>> [  477.450000] Loop: 835451 irq: 300583 ReSched: 139
>>> [  477.450000] Loop: 835452 irq: 300583 ReSched: 140
>>> [  477.450000] Loop: 835453 irq: 300583 ReSched: 141
>>> [  477.450000] Loop: 835454 irq: 300583 ReSched: 142
>>> [  477.450000] Loop: 835455 irq: 300583 ReSched: 143
>>> [  477.450000] Loop: 835456 irq: 300583 ReSched: 144
>>> [  477.450000] Loop: 835457 irq: 300583 ReSched: 145
>>> [  477.450000] Loop: 835458 irq: 300583 ReSched: 146
>>> [  477.450000] Loop: 835459 irq: 300583 ReSched: 147
>>> [  477.450000] Loop: 835460 irq: 300583 ReSched: 148
>>> [  477.450000] Loop: 835461 irq: 300583 ReSched: 149
>>> [  477.450000] Loop: 835462 irq: 300583 ReSched: 150
>>> [  477.450000] Loop: 835463 irq: 300583 ReSched: 151
>>> [  477.450000] Loop: 835464 irq: 300583 ReSched: 152
>>> [  477.450000] Loop: 835465 irq: 300583 ReSched: 153
>>> [  477.450000] Loop: 835466 irq: 300583 ReSched: 154
>>> [  477.450000] Loop: 835467 irq: 300583 ReSched: 155
>>> [  477.450000] Loop: 835468 irq: 300583 ReSched: 156
>>> [  477.450000] Loop: 835469 irq: 300583 ReSched: 157
>>> [  477.450000] Loop: 835470 irq: 300583 ReSched: 158
>>> [  477.450000] Loop: 835472 irq: 300583 ReSched: 159
>>> [  477.450000] Loop: 835473 irq: 300583 ReSched: 160
>>> [  477.450000] Loop: 835474 irq: 300583 ReSched: 161
>>> [  477.450000] Loop: 835475 irq: 300583 ReSched: 162
>>> [  477.450000] Loop: 835476 irq: 300583 ReSched: 163
>>> [  477.450000] Loop: 835477 irq: 300583 ReSched: 164
>>> [  477.450000] Loop: 835478 irq: 300583 ReSched: 165
>>> [  477.450000] Loop: 835479 irq: 300583 ReSched: 166
>>> [  477.450000] Loop: 835480 irq: 300583 ReSched: 167
>>> [  477.450000] Loop: 835481 irq: 300583 ReSched: 168
>>> [  477.450000] Loop: 835482 irq: 300583 ReSched: 169
>>> [  477.450000] Loop: 835483 irq: 300583 ReSched: 170
>>> [  477.450000] Loop: 835484 irq: 300583 ReSched: 171
>>> [  477.450000] Loop: 835485 irq: 300583 ReSched: 172
>>> [  477.450000] Loop: 835486 irq: 300583 ReSched: 173
>>> [  477.450000] Loop: 835487 irq: 300583 ReSched: 174
>>> [  477.450000] Loop: 835488 irq: 300583 ReSched: 175
>>> [  477.450000] Loop: 835489 irq: 300583 ReSched: 176
>>> [  477.450000] Loop: 835490 irq: 300583 ReSched: 177
>>> [  477.450000] Loop: 835491 irq: 300583 ReSched: 178
>>> [  477.450000] Loop: 835492 irq: 300583 ReSched: 179
>>> [  477.450000] Loop: 835493 irq: 300583 ReSched: 180
>>> [  477.450000] Loop: 835494 irq: 300583 ReSched: 181
>>> [  477.450000] Loop: 835495 irq: 300583 ReSched: 182
>>> [  477.450000] Loop: 835496 irq: 300583 ReSched: 183
>>> [  477.450000] Loop: 835497 irq: 300583 ReSched: 184
>>> [  477.450000] Loop: 835498 irq: 300583 ReSched: 185
>>> [  477.450000] Loop: 835499 irq: 300583 ReSched: 186
>>> [  477.450000] Loop: 835500 irq: 300583 ReSched: 187
>>> [  477.450000] Loop: 835501 irq: 300583 ReSched: 188
>>> [  477.450000] Loop: 835502 irq: 300583 ReSched: 189
>>> [  477.450000] Loop: 835503 irq: 300583 ReSched: 190
>>> [  477.450000] Loop: 835504 irq: 300583 ReSched: 191
>>> [  477.450000] Loop: 835505 irq: 300583 ReSched: 192
>>> [  477.450000] Loop: 835506 irq: 300583 ReSched: 193
>>> [  477.450000] Loop: 835507 irq: 300583 ReSched: 194
>>> [  477.450000] Loop: 835508 irq: 300583 ReSched: 195
>>> [  477.450000] Loop: 835509 irq: 300583 ReSched: 196
>>> [  477.450000] Loop: 835510 irq: 300583 ReSched: 197
>>> [  477.450000] Loop: 835511 irq: 300583 ReSched: 198
>>> [  477.450000] Loop: 835512 irq: 300583 ReSched: 199
>>> [  477.450000] Loop: 835513 irq: 300583 ReSched: 200
>>> [  477.450000] Loop: 835514 irq: 300583 ReSched: 201
>>> [  477.450000] Loop: 835515 irq: 300583 ReSched: 202
>>> [  477.450000] Loop: 835516 irq: 300583 ReSched: 203
>>> [  477.450000] Loop: 835517 irq: 300583 ReSched: 204
>>> [  477.450000] Loop: 835518 irq: 300583 ReSched: 205
>>> [  477.450000] Loop: 835519 irq: 300583 ReSched: 206
>>> [  477.450000] Loop: 835520 irq: 300583 ReSched: 207
>>> [  477.450000] Loop: 835521 irq: 300583 ReSched: 208
>>> [  477.450000] Loop: 835522 irq: 300583 ReSched: 209
>>> [  477.450000] Loop: 835523 irq: 300583 ReSched: 210
>>> [  477.450000] Loop: 835524 irq: 300583 ReSched: 211
>>> [  477.450000] Loop: 835525 irq: 300583 ReSched: 212
>>> [  477.450000] Loop: 835526 irq: 300583 ReSched: 213
>>> [  477.450000] Loop: 835527 irq: 300583 ReSched: 214
>>> [  477.450000] Loop: 835528 irq: 300583 ReSched: 215
>>> [  477.450000] Loop: 835529 irq: 300583 ReSched: 216
>>> [  477.450000] Loop: 835530 irq: 300583 ReSched: 217
>>> [  478.450000] Loop: 835534 irq: 300584 ReSched: 218
>>> [  478.460000] Loop: 835536 irq: 300585 ReSched: 219
>>> [  478.470000] Loop: 835538 irq: 300586 ReSched: 220
>>> [  478.470000] Loop: 835539 irq: 300586 ReSched: 221
>>> [  478.500000] Loop: 835983 irq: 300586 ReSched: 622
>>> ...
>>> [  478.510000] Loop: 836072 irq: 300586 ReSched: 697
>>> [  478.510000] Loop: 836073 irq: 300586 ReSched: 698
>>> [  478.510000] Loop: 836074 irq: 300586 ReSched: 699
>>> [  478.510000] Loop: 836075 irq: 300586 ReSched: 700
>>> [  478.510000] Loop: 836076 irq: 300586 ReSched: 701
>>> [  478.510000] Loop: 836077 irq: 300586 ReSched: 702
>>> [  478.510000] Loop: 836078 irq: 300586 ReSched: 703
>>> [  478.510000] Loop: 836079 irq: 300586 ReSched: 704
>>> [  478.510000] Loop: 836080 irq: 300586 ReSched: 705
>>> [  478.510000] Loop: 836081 irq: 300586 ReSched: 706
>>> [  478.510000] Loop: 836082 irq: 300586 ReSched: 707
>>> [  478.510000] Loop: 836083 irq: 300586 ReSched: 708
>>> [  478.510000] Loop: 836084 irq: 300586 ReSched: 709
>>> [  478.510000] Loop: 836085 irq: 300586 ReSched: 710
>>> [  478.510000] Loop: 836086 irq: 300586 ReSched: 711
>>> [  478.510000] Loop: 836087 irq: 300586 ReSched: 712
>>> [  478.510000] Loop: 836088 irq: 300586 ReSched: 713
>>> [  478.510000] Loop: 836089 irq: 300586 ReSched: 714
>>> [  478.510000] Loop: 836090 irq: 300586 ReSched: 715
>>> [  478.510000] Loop: 836091 irq: 300586 ReSched: 716
>>> [  478.510000] Loop: 836092 irq: 300586 ReSched: 717
>>> [  478.510000] Loop: 836093 irq: 300586 ReSched: 718
>>> [  478.510000] Loop: 836094 irq: 300586 ReSched: 719
>>> [  478.510000] Loop: 836095 irq: 300586 ReSched: 720
>>> [  478.510000] Loop: 836096 irq: 300586 ReSched: 721
>>> [  478.510000] Loop: 836097 irq: 300586 ReSched: 722
>>> [  478.510000] Loop: 836098 irq: 300586 ReSched: 723
>>> [  478.510000] Loop: 836099 irq: 300586 ReSched: 724
>>> [  478.510000] Loop: 836100 irq: 300586 ReSched: 725
>>> [  478.510000] Loop: 836101 irq: 300586 ReSched: 726
>>> [  478.510000] Loop: 836102 irq: 300586 ReSched: 727
>>> [  478.510000] Loop: 836103 irq: 300586 ReSched: 728
>>> [  478.510000] Loop: 836104 irq: 300586 ReSched: 729
>>> [  478.510000] Loop: 836105 irq: 300586 ReSched: 730
>>> [  478.510000] Loop: 836106 irq: 300586 ReSched: 731
>>> [  478.510000] Loop: 836107 irq: 300586 ReSched: 732
>>> [  478.510000] Loop: 836108 irq: 300586 ReSched: 733
>>> [  478.510000] Loop: 836109 irq: 300586 ReSched: 734
>>> [  478.510000] Loop: 836110 irq: 300586 ReSched: 735
>>> [  478.510000] Loop: 836111 irq: 300586 ReSched: 736
>>> [  478.510000] Loop: 836112 irq: 300586 ReSched: 737
>>> [  478.510000] Loop: 836113 irq: 300586 ReSched: 738
>>> [  478.510000] Loop: 836114 irq: 300586 ReSched: 739
>>> [  478.510000] Loop: 836115 irq: 300586 ReSched: 740
>>> [  478.510000] Loop: 836116 irq: 300586 ReSched: 741
>>> [  478.510000] Loop: 836117 irq: 300586 ReSched: 742
>>> [  478.510000] Loop: 836118 irq: 300586 ReSched: 743
>>> [  478.510000] Loop: 836119 irq: 300586 ReSched: 744
>>> [  478.510000] Loop: 836120 irq: 300586 ReSched: 745
>>> [  478.510000] Loop: 836121 irq: 300586 ReSched: 746
>>> [  478.510000] Loop: 836122 irq: 300586 ReSched: 747
>>> [  478.510000] Loop: 836123 irq: 300586 ReSched: 748
>>> [  478.510000] Loop: 836124 irq: 300586 ReSched: 749
>>> [  478.510000] Loop: 836125 irq: 300586 ReSched: 750
>>> [  478.510000] Loop: 836126 irq: 300586 ReSched: 751
>>> [  478.510000] Loop: 836127 irq: 300586 ReSched: 752
>>> [  478.510000] Loop: 836128 irq: 300586 ReSched: 753
>>> [  478.510000] Loop: 836129 irq: 300586 ReSched: 754
>>> [  478.510000] Loop: 836130 irq: 300586 ReSched: 755
>>> [  478.510000] Loop: 836131 irq: 300586 ReSched: 756
>>> [  478.510000] Loop: 836132 irq: 300586 ReSched: 757
>>> [  478.510000] Loop: 836133 irq: 300586 ReSched: 758
>>> [  478.510000] Loop: 836134 irq: 300586 ReSched: 759
>>>
>>>
>>> Koen
>>>
>>> On 2016-06-13 20:17, Tim Harvey wrote:
>>>>
>>>> On Mon, Jun 13, 2016 at 9:12 AM, Koen Vandeputte
>>>> <koen.vandeputte at ncentric.com> wrote:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> There seems to be a bug in the function eth_poll() in this driver
>>>>>
>>>>> When the RX ring gets full once, the re-schedule is called forever, even
>>>>> when the ring is empty afterwards.
>>>>>
>>>>>
>>>>>      if (!received) {
>>>>>          napi_complete(napi);
>>>>>          enable_irq(sw->rx_irq);
>>>>>          budget = 0;
>>>>>
>>>>>          /* if rx descriptors are full schedule another poll */
>>>>>          if (rx_ring->desc[(i-1) & (RX_DESCS-1)].cown)
>>>>>          {
>>>>>              eth_schedule_poll(sw);    <----  Gets called on each function
>>>>> entry
>>>>>          }
>>>>>      }
>>>>>
>>>>>
>>>>> This causes SoftIRQ to fully load a core forever.
>>>>>
>>>>>
>>>>> I didn't fix it yet, but should I be the first, i'll supply a patch ..
>>>>>
>>>> Koen,
>>>>
>>>> We have seen this before, but admittedly don't understand why we enter
>>>> into the same condition on each subsequent call to eth_poll(). The
>>>> check is to catch the condition described as irq rot [1] and is to
>>>> catch the case where after processing the full budget, we are
>>>> immediately full again (a situation which is easily re-producible with
>>>> a flood-ping). If this occurs we will no longer get an rx interrupt
>>>> (because the descriptors are full) and our napi function will never
>>>> get called again (unless transmitting packets).
>>>>
>>>> What is your proposed patch?
>>>>
>>>> Tim
>>>>
>>>> 1 .http://www.linuxfoundation.org/collaborate/workgroups/networking/napi#IRQ_race_a.k.a_rotting_packet
>>>
>>>
>>
>>
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
>
>


From ldpinney at gmail.com  Wed Jun 15 14:29:08 2016
From: ldpinney at gmail.com (L. D. Pinney)
Date: Wed, 15 Jun 2016 16:29:08 -0500
Subject: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
In-Reply-To: <5761BB29.8020303@prplfoundation.org>
References: <5761BB29.8020303@prplfoundation.org>
Message-ID: <CAJOqq5S314FgBswNo2KheO6VzvFr6jaMP=khXEWONSBnogJYLg@mail.gmail.com>

Postings to the LEDE Development List should be devoted to technical
development issues.

Persons from prplfoundation et.al should respect conventional mail list
etiquette such as found here :

http://www.arm.linux.org.uk/mailinglists/etiquette.php

Pay particular attention to 4, 7, and 10 on the above etiquitte list.

I see prplfoundation as a hostile takeover of LEDE / OpenWrt by a
corporate conspiracy.

Free Software is meant to be free ...

Free from the manipulation of governments and corporations.

Pushing your corporate backed agenda on the Development List(s)
torques me off every time.

On Wed, Jun 15, 2016 at 3:31 PM, Eric Schultz
<eschultz at prplfoundation.org> wrote:
> As we continue the TR-069 support discussion, I wanted to ask folks
> whether they want me to continue to cross post to these list in addition
> to the prplwrt list at openwrt at lists.prplfoundation.org. I have no
> problem doing either way, but I don't want to fill people's inbox will
> stuff they feel is off topic. Just wanted to get a sense of what people
> would prefer.
>
> Thanks,
>
> Eric
> --
> Eric Schultz, Community Manager, prpl Foundation
> http://www.prplfoundation.org
> eschultz at prplfoundation.org
> cell: 920-539-0404
> skype: ericschultzwi
> @EricPrpl
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


From daniel at gimpelevich.san-francisco.ca.us  Wed Jun 15 14:50:13 2016
From: daniel at gimpelevich.san-francisco.ca.us (Daniel Gimpelevich)
Date: Wed, 15 Jun 2016 14:50:13 -0700
Subject: [LEDE-DEV] DGN3500 nas mac
In-Reply-To: <94da699d-a26e-fb99-3696-1c241bd20d90@phrozen.org>
References: <94da699d-a26e-fb99-3696-1c241bd20d90@phrozen.org>
Message-ID: <1466027413.10303.7.camel@chimera>

On Wed, 2016-06-15 at 16:02 +0200, John Crispin wrote:
> Hi,
> 
> 492964e741f1e0254b6ed7c0a095551a31d25dc9 slipped by me without me
> realizing that it is broken.
> 
> i staged a fix in my tree for this
> https://git.lede-project.org/?p=lede/blogic/staging.git;a=commit;h=08eb51390bd898a2f2b8023515c0f6482887faa7
> 
> however the esi stuff needs to be changed to apply the mac from wan to
> the nas interface.
> 
> maybe we can add this as an init.d script as part of the esi package ?
> 
> 	John

Neither the merged patch nor the staged fix (which I already tried
myself) work properly. I have a fix for this I haven't pushed yet,
because it still does not fix the separate but related issue of a random
wifi macaddr which resists userspace changes. I now remember this was
the reason I kept insisting on the kernel parameters. Once Jonas ACK's
the relevant change to his patch, I'll rewrite the removed 997.patch to
make use of it, and I'll push both fixes to Github for a PR.



From david at lang.hm  Wed Jun 15 15:03:00 2016
From: david at lang.hm (David Lang)
Date: Wed, 15 Jun 2016 15:03:00 -0700 (PDT)
Subject: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
In-Reply-To: <CAJOqq5S314FgBswNo2KheO6VzvFr6jaMP=khXEWONSBnogJYLg@mail.gmail.com>
References: <5761BB29.8020303@prplfoundation.org>
 <CAJOqq5S314FgBswNo2KheO6VzvFr6jaMP=khXEWONSBnogJYLg@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1606151502140.2494@nftneq.ynat.uz>

Is it really pushing a corporate agenda to coordinate efforts to make 
LEDE/OpenWRT support remote management protocols?

Just because a company works on something doesn't make it evil.

David Lang

On Wed, 15 Jun 2016, L. D. Pinney wrote:

> Date: Wed, 15 Jun 2016 16:29:08 -0500
> From: L. D. Pinney <ldpinney at gmail.com>
> To: LEDE Development List <lede-dev at lists.infradead.org>
> Subject: Re: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
> 
> Postings to the LEDE Development List should be devoted to technical
> development issues.
>
> Persons from prplfoundation et.al should respect conventional mail list
> etiquette such as found here :
>
> http://www.arm.linux.org.uk/mailinglists/etiquette.php
>
> Pay particular attention to 4, 7, and 10 on the above etiquitte list.
>
> I see prplfoundation as a hostile takeover of LEDE / OpenWrt by a
> corporate conspiracy.
>
> Free Software is meant to be free ...
>
> Free from the manipulation of governments and corporations.
>
> Pushing your corporate backed agenda on the Development List(s)
> torques me off every time.
>
> On Wed, Jun 15, 2016 at 3:31 PM, Eric Schultz
> <eschultz at prplfoundation.org> wrote:
>> As we continue the TR-069 support discussion, I wanted to ask folks
>> whether they want me to continue to cross post to these list in addition
>> to the prplwrt list at openwrt at lists.prplfoundation.org. I have no
>> problem doing either way, but I don't want to fill people's inbox will
>> stuff they feel is off topic. Just wanted to get a sense of what people
>> would prefer.
>>
>> Thanks,
>>
>> Eric
>> --
>> Eric Schultz, Community Manager, prpl Foundation
>> http://www.prplfoundation.org
>> eschultz at prplfoundation.org
>> cell: 920-539-0404
>> skype: ericschultzwi
>> @EricPrpl
>>
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
>


From ldpinney at gmail.com  Wed Jun 15 15:10:36 2016
From: ldpinney at gmail.com (L. D. Pinney)
Date: Wed, 15 Jun 2016 17:10:36 -0500
Subject: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
In-Reply-To: <alpine.DEB.2.02.1606151502140.2494@nftneq.ynat.uz>
References: <5761BB29.8020303@prplfoundation.org>
 <CAJOqq5S314FgBswNo2KheO6VzvFr6jaMP=khXEWONSBnogJYLg@mail.gmail.com>
 <alpine.DEB.2.02.1606151502140.2494@nftneq.ynat.uz>
Message-ID: <CAJOqq5SxXQH_BG3wP=1W7FVN9kptQvkdLc4V5r+ad4u4dRhw=Q@mail.gmail.com>

Just because a company works on something doesn't make it evil.
Yes of course large corporations are well known for altruistic behavior.

On Wed, Jun 15, 2016 at 5:03 PM, David Lang <david at lang.hm> wrote:
> Is it really pushing a corporate agenda to coordinate efforts to make
> LEDE/OpenWRT support remote management protocols?
>
> Just because a company works on something doesn't make it evil.
>
> David Lang
>
> On Wed, 15 Jun 2016, L. D. Pinney wrote:
>
>> Date: Wed, 15 Jun 2016 16:29:08 -0500
>> From: L. D. Pinney <ldpinney at gmail.com>
>> To: LEDE Development List <lede-dev at lists.infradead.org>
>> Subject: Re: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
>>
>>
>> Postings to the LEDE Development List should be devoted to technical
>> development issues.
>>
>> Persons from prplfoundation et.al should respect conventional mail list
>> etiquette such as found here :
>>
>> http://www.arm.linux.org.uk/mailinglists/etiquette.php
>>
>> Pay particular attention to 4, 7, and 10 on the above etiquitte list.
>>
>> I see prplfoundation as a hostile takeover of LEDE / OpenWrt by a
>> corporate conspiracy.
>>
>> Free Software is meant to be free ...
>>
>> Free from the manipulation of governments and corporations.
>>
>> Pushing your corporate backed agenda on the Development List(s)
>> torques me off every time.
>>
>> On Wed, Jun 15, 2016 at 3:31 PM, Eric Schultz
>> <eschultz at prplfoundation.org> wrote:
>>>
>>> As we continue the TR-069 support discussion, I wanted to ask folks
>>> whether they want me to continue to cross post to these list in addition
>>> to the prplwrt list at openwrt at lists.prplfoundation.org. I have no
>>> problem doing either way, but I don't want to fill people's inbox will
>>> stuff they feel is off topic. Just wanted to get a sense of what people
>>> would prefer.
>>>
>>> Thanks,
>>>
>>> Eric
>>> --
>>> Eric Schultz, Community Manager, prpl Foundation
>>> http://www.prplfoundation.org
>>> eschultz at prplfoundation.org
>>> cell: 920-539-0404
>>> skype: ericschultzwi
>>> @EricPrpl
>>>
>>> _______________________________________________
>>> Lede-dev mailing list
>>> Lede-dev at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>
>>
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>
>


From david at lang.hm  Wed Jun 15 15:14:11 2016
From: david at lang.hm (David Lang)
Date: Wed, 15 Jun 2016 15:14:11 -0700 (PDT)
Subject: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
In-Reply-To: <CAJOqq5SxXQH_BG3wP=1W7FVN9kptQvkdLc4V5r+ad4u4dRhw=Q@mail.gmail.com>
References: <5761BB29.8020303@prplfoundation.org>
 <CAJOqq5S314FgBswNo2KheO6VzvFr6jaMP=khXEWONSBnogJYLg@mail.gmail.com>
 <alpine.DEB.2.02.1606151502140.2494@nftneq.ynat.uz>
 <CAJOqq5SxXQH_BG3wP=1W7FVN9kptQvkdLc4V5r+ad4u4dRhw=Q@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1606151512470.2494@nftneq.ynat.uz>

Like individuals, companies do things that benefit them. Almost all Open Source 
software development is done by people who benefit from the results. If 
benefiting from the results makes it that the LEDE project doesn't want to hear 
from you, the project will die _really_ fast.

I hope your hostile attitude doesn't spread.

David Lang

On Wed, 15 Jun 2016, L. D. Pinney wrote:

> Date: Wed, 15 Jun 2016 17:10:36 -0500
> From: L. D. Pinney <ldpinney at gmail.com>
> To: David Lang <david at lang.hm>
> Cc: LEDE Development List <lede-dev at lists.infradead.org>
> Subject: Re: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
> 
> Just because a company works on something doesn't make it evil.
> Yes of course large corporations are well known for altruistic behavior.
>
> On Wed, Jun 15, 2016 at 5:03 PM, David Lang <david at lang.hm> wrote:
>> Is it really pushing a corporate agenda to coordinate efforts to make
>> LEDE/OpenWRT support remote management protocols?
>>
>> Just because a company works on something doesn't make it evil.
>>
>> David Lang
>>
>> On Wed, 15 Jun 2016, L. D. Pinney wrote:
>>
>>> Date: Wed, 15 Jun 2016 16:29:08 -0500
>>> From: L. D. Pinney <ldpinney at gmail.com>
>>> To: LEDE Development List <lede-dev at lists.infradead.org>
>>> Subject: Re: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
>>>
>>>
>>> Postings to the LEDE Development List should be devoted to technical
>>> development issues.
>>>
>>> Persons from prplfoundation et.al should respect conventional mail list
>>> etiquette such as found here :
>>>
>>> http://www.arm.linux.org.uk/mailinglists/etiquette.php
>>>
>>> Pay particular attention to 4, 7, and 10 on the above etiquitte list.
>>>
>>> I see prplfoundation as a hostile takeover of LEDE / OpenWrt by a
>>> corporate conspiracy.
>>>
>>> Free Software is meant to be free ...
>>>
>>> Free from the manipulation of governments and corporations.
>>>
>>> Pushing your corporate backed agenda on the Development List(s)
>>> torques me off every time.
>>>
>>> On Wed, Jun 15, 2016 at 3:31 PM, Eric Schultz
>>> <eschultz at prplfoundation.org> wrote:
>>>>
>>>> As we continue the TR-069 support discussion, I wanted to ask folks
>>>> whether they want me to continue to cross post to these list in addition
>>>> to the prplwrt list at openwrt at lists.prplfoundation.org. I have no
>>>> problem doing either way, but I don't want to fill people's inbox will
>>>> stuff they feel is off topic. Just wanted to get a sense of what people
>>>> would prefer.
>>>>
>>>> Thanks,
>>>>
>>>> Eric
>>>> --
>>>> Eric Schultz, Community Manager, prpl Foundation
>>>> http://www.prplfoundation.org
>>>> eschultz at prplfoundation.org
>>>> cell: 920-539-0404
>>>> skype: ericschultzwi
>>>> @EricPrpl
>>>>
>>>> _______________________________________________
>>>> Lede-dev mailing list
>>>> Lede-dev at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>>
>>>
>>> _______________________________________________
>>> Lede-dev mailing list
>>> Lede-dev at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>>
>>
>


From ldpinney at gmail.com  Wed Jun 15 15:22:17 2016
From: ldpinney at gmail.com (L. D. Pinney)
Date: Wed, 15 Jun 2016 17:22:17 -0500
Subject: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
In-Reply-To: <alpine.DEB.2.02.1606151512470.2494@nftneq.ynat.uz>
References: <5761BB29.8020303@prplfoundation.org>
 <CAJOqq5S314FgBswNo2KheO6VzvFr6jaMP=khXEWONSBnogJYLg@mail.gmail.com>
 <alpine.DEB.2.02.1606151502140.2494@nftneq.ynat.uz>
 <CAJOqq5SxXQH_BG3wP=1W7FVN9kptQvkdLc4V5r+ad4u4dRhw=Q@mail.gmail.com>
 <alpine.DEB.2.02.1606151512470.2494@nftneq.ynat.uz>
Message-ID: <CAJOqq5TYpOKn0mmtO+fSmCoHyZr9Rvss_cGbZfRnEOqbwTLXEw@mail.gmail.com>

It's a Development List ... no place for corporate agendas.

The problem is more pervasive than just TR-069.

It's about cross-posting and pushing forwards about who's going to the
corporate sponsored events and other drivel.

These things have little or nothing to do with the PRIMARY reason of a
Development List.

IF these people have something to contribute such as a [PATCH] this
would be correct mailing list...otherwise it's BS

On Wed, Jun 15, 2016 at 5:14 PM, David Lang <david at lang.hm> wrote:
> Like individuals, companies do things that benefit them. Almost all Open
> Source software development is done by people who benefit from the results.
> If benefiting from the results makes it that the LEDE project doesn't want
> to hear from you, the project will die _really_ fast.
>
> I hope your hostile attitude doesn't spread.
>
> David Lang
>
> On Wed, 15 Jun 2016, L. D. Pinney wrote:
>
>> Date: Wed, 15 Jun 2016 17:10:36 -0500
>> From: L. D. Pinney <ldpinney at gmail.com>
>> To: David Lang <david at lang.hm>
>> Cc: LEDE Development List <lede-dev at lists.infradead.org>
>>
>> Subject: Re: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
>>
>> Just because a company works on something doesn't make it evil.
>> Yes of course large corporations are well known for altruistic behavior.
>>
>> On Wed, Jun 15, 2016 at 5:03 PM, David Lang <david at lang.hm> wrote:
>>>
>>> Is it really pushing a corporate agenda to coordinate efforts to make
>>> LEDE/OpenWRT support remote management protocols?
>>>
>>> Just because a company works on something doesn't make it evil.
>>>
>>> David Lang
>>>
>>> On Wed, 15 Jun 2016, L. D. Pinney wrote:
>>>
>>>> Date: Wed, 15 Jun 2016 16:29:08 -0500
>>>> From: L. D. Pinney <ldpinney at gmail.com>
>>>> To: LEDE Development List <lede-dev at lists.infradead.org>
>>>> Subject: Re: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
>>>>
>>>>
>>>> Postings to the LEDE Development List should be devoted to technical
>>>> development issues.
>>>>
>>>> Persons from prplfoundation et.al should respect conventional mail list
>>>> etiquette such as found here :
>>>>
>>>> http://www.arm.linux.org.uk/mailinglists/etiquette.php
>>>>
>>>> Pay particular attention to 4, 7, and 10 on the above etiquitte list.
>>>>
>>>> I see prplfoundation as a hostile takeover of LEDE / OpenWrt by a
>>>> corporate conspiracy.
>>>>
>>>> Free Software is meant to be free ...
>>>>
>>>> Free from the manipulation of governments and corporations.
>>>>
>>>> Pushing your corporate backed agenda on the Development List(s)
>>>> torques me off every time.
>>>>
>>>> On Wed, Jun 15, 2016 at 3:31 PM, Eric Schultz
>>>> <eschultz at prplfoundation.org> wrote:
>>>>>
>>>>>
>>>>> As we continue the TR-069 support discussion, I wanted to ask folks
>>>>> whether they want me to continue to cross post to these list in
>>>>> addition
>>>>> to the prplwrt list at openwrt at lists.prplfoundation.org. I have no
>>>>> problem doing either way, but I don't want to fill people's inbox will
>>>>> stuff they feel is off topic. Just wanted to get a sense of what people
>>>>> would prefer.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Eric
>>>>> --
>>>>> Eric Schultz, Community Manager, prpl Foundation
>>>>> http://www.prplfoundation.org
>>>>> eschultz at prplfoundation.org
>>>>> cell: 920-539-0404
>>>>> skype: ericschultzwi
>>>>> @EricPrpl
>>>>>
>>>>> _______________________________________________
>>>>> Lede-dev mailing list
>>>>> Lede-dev at lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Lede-dev mailing list
>>>> Lede-dev at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>>>
>>>
>>
>


From david at lang.hm  Wed Jun 15 16:05:24 2016
From: david at lang.hm (David Lang)
Date: Wed, 15 Jun 2016 16:05:24 -0700 (PDT)
Subject: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
In-Reply-To: <CAJOqq5TYpOKn0mmtO+fSmCoHyZr9Rvss_cGbZfRnEOqbwTLXEw@mail.gmail.com>
References: <5761BB29.8020303@prplfoundation.org>
 <CAJOqq5S314FgBswNo2KheO6VzvFr6jaMP=khXEWONSBnogJYLg@mail.gmail.com>
 <alpine.DEB.2.02.1606151502140.2494@nftneq.ynat.uz>
 <CAJOqq5SxXQH_BG3wP=1W7FVN9kptQvkdLc4V5r+ad4u4dRhw=Q@mail.gmail.com>
 <alpine.DEB.2.02.1606151512470.2494@nftneq.ynat.uz>
 <CAJOqq5TYpOKn0mmtO+fSmCoHyZr9Rvss_cGbZfRnEOqbwTLXEw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1606151551400.2494@nftneq.ynat.uz>

On Wed, 15 Jun 2016, L. D. Pinney wrote:

> It's a Development List ... no place for corporate agendas.

if adding a feature is a corporate agenda because a company is interested in it 
working correctly, you are shutting down all development.

> The problem is more pervasive than just TR-069.
>
> It's about cross-posting and pushing forwards about who's going to the
> corporate sponsored events and other drivel.

Some amount of cross posting is very reasonable. In this case, they are talking 
about what developers are going to go to this event to coordinate their 
development work. If they were talking about what CxO folks they were getting 
together it would be less relevant (but I'll point out that LEDE doesn't have 
any list to coordinate management/publicity/etc stuff, so it may very well end 
up here anyway)

If this was a non-profit organizing a similar meeting would you be telling them 
to go away, that their contributions are not wanted?

> These things have little or nothing to do with the PRIMARY reason of a
> Development List.
>
> IF these people have something to contribute such as a [PATCH] this
> would be correct mailing list...otherwise it's BS

There is more to development than just [PATCH] e-mails.

In this case there are multiple people/companies have code that they are 
releasing and looking to get integrated, and they want to coordinate instead of 
fighting each other. This is generally considered a good thing.

Driving people away because they aren't helping in exactly the way that you 
consider ideal is a good way to kill a project.

David Lang

> On Wed, Jun 15, 2016 at 5:14 PM, David Lang <david at lang.hm> wrote:
>> Like individuals, companies do things that benefit them. Almost all Open
>> Source software development is done by people who benefit from the results.
>> If benefiting from the results makes it that the LEDE project doesn't want
>> to hear from you, the project will die _really_ fast.
>>
>> I hope your hostile attitude doesn't spread.
>>
>> David Lang
>>
>> On Wed, 15 Jun 2016, L. D. Pinney wrote:
>>
>>> Date: Wed, 15 Jun 2016 17:10:36 -0500
>>> From: L. D. Pinney <ldpinney at gmail.com>
>>> To: David Lang <david at lang.hm>
>>> Cc: LEDE Development List <lede-dev at lists.infradead.org>
>>>
>>> Subject: Re: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
>>>
>>> Just because a company works on something doesn't make it evil.
>>> Yes of course large corporations are well known for altruistic behavior.
>>>
>>> On Wed, Jun 15, 2016 at 5:03 PM, David Lang <david at lang.hm> wrote:
>>>>
>>>> Is it really pushing a corporate agenda to coordinate efforts to make
>>>> LEDE/OpenWRT support remote management protocols?
>>>>
>>>> Just because a company works on something doesn't make it evil.
>>>>
>>>> David Lang
>>>>
>>>> On Wed, 15 Jun 2016, L. D. Pinney wrote:
>>>>
>>>>> Date: Wed, 15 Jun 2016 16:29:08 -0500
>>>>> From: L. D. Pinney <ldpinney at gmail.com>
>>>>> To: LEDE Development List <lede-dev at lists.infradead.org>
>>>>> Subject: Re: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
>>>>>
>>>>>
>>>>> Postings to the LEDE Development List should be devoted to technical
>>>>> development issues.
>>>>>
>>>>> Persons from prplfoundation et.al should respect conventional mail list
>>>>> etiquette such as found here :
>>>>>
>>>>> http://www.arm.linux.org.uk/mailinglists/etiquette.php
>>>>>
>>>>> Pay particular attention to 4, 7, and 10 on the above etiquitte list.
>>>>>
>>>>> I see prplfoundation as a hostile takeover of LEDE / OpenWrt by a
>>>>> corporate conspiracy.
>>>>>
>>>>> Free Software is meant to be free ...
>>>>>
>>>>> Free from the manipulation of governments and corporations.
>>>>>
>>>>> Pushing your corporate backed agenda on the Development List(s)
>>>>> torques me off every time.
>>>>>
>>>>> On Wed, Jun 15, 2016 at 3:31 PM, Eric Schultz
>>>>> <eschultz at prplfoundation.org> wrote:
>>>>>>
>>>>>>
>>>>>> As we continue the TR-069 support discussion, I wanted to ask folks
>>>>>> whether they want me to continue to cross post to these list in
>>>>>> addition
>>>>>> to the prplwrt list at openwrt at lists.prplfoundation.org. I have no
>>>>>> problem doing either way, but I don't want to fill people's inbox will
>>>>>> stuff they feel is off topic. Just wanted to get a sense of what people
>>>>>> would prefer.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Eric
>>>>>> --
>>>>>> Eric Schultz, Community Manager, prpl Foundation
>>>>>> http://www.prplfoundation.org
>>>>>> eschultz at prplfoundation.org
>>>>>> cell: 920-539-0404
>>>>>> skype: ericschultzwi
>>>>>> @EricPrpl
>>>>>>
>>>>>> _______________________________________________
>>>>>> Lede-dev mailing list
>>>>>> Lede-dev at lists.infradead.org
>>>>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Lede-dev mailing list
>>>>> Lede-dev at lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>>>>
>>>>
>>>
>>
>


From ldpinney at gmail.com  Wed Jun 15 16:38:23 2016
From: ldpinney at gmail.com (L. D. Pinney)
Date: Wed, 15 Jun 2016 18:38:23 -0500
Subject: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
In-Reply-To: <alpine.DEB.2.02.1606151551400.2494@nftneq.ynat.uz>
References: <5761BB29.8020303@prplfoundation.org>
 <CAJOqq5S314FgBswNo2KheO6VzvFr6jaMP=khXEWONSBnogJYLg@mail.gmail.com>
 <alpine.DEB.2.02.1606151502140.2494@nftneq.ynat.uz>
 <CAJOqq5SxXQH_BG3wP=1W7FVN9kptQvkdLc4V5r+ad4u4dRhw=Q@mail.gmail.com>
 <alpine.DEB.2.02.1606151512470.2494@nftneq.ynat.uz>
 <CAJOqq5TYpOKn0mmtO+fSmCoHyZr9Rvss_cGbZfRnEOqbwTLXEw@mail.gmail.com>
 <alpine.DEB.2.02.1606151551400.2494@nftneq.ynat.uz>
Message-ID: <CAJOqq5Q7ztL_issqj+jL_1UmNAbneOraWDbUNysj0Zz=8EC0zw@mail.gmail.com>

Eric asked :

"I wanted to ask folks whether they want me to continue to cross post to these"

And "Just wanted to get a sense of what people would prefer."

I posted my answer followed by my reasons.

I find cross posting annoying...and in most cases irrelevant.

I hope your hostile attitude doesn't spread.
It's not likely to spread...IF and WHEN the BS stops.

Stick to Development concerns and the only thing you will hear from me
will have [PATCH] in the subject line or perhaps relevant comments.

Prpl is nothing short of a corporate conspiracy ... by and for some of
the same companies and people that refused to comply with the GPL code
requirements that started the OpenWrt project.

I really don't care if you "don't see it my way"

I'm not here to win friends and influence idiots ... I'll leave that
to politicians



On Wed, Jun 15, 2016 at 6:05 PM, David Lang <david at lang.hm> wrote:
> On Wed, 15 Jun 2016, L. D. Pinney wrote:
>
>> It's a Development List ... no place for corporate agendas.
>
>
> if adding a feature is a corporate agenda because a company is interested in
> it working correctly, you are shutting down all development.
>
>> The problem is more pervasive than just TR-069.
>>
>> It's about cross-posting and pushing forwards about who's going to the
>> corporate sponsored events and other drivel.
>
>
> Some amount of cross posting is very reasonable. In this case, they are
> talking about what developers are going to go to this event to coordinate
> their development work. If they were talking about what CxO folks they were
> getting together it would be less relevant (but I'll point out that LEDE
> doesn't have any list to coordinate management/publicity/etc stuff, so it
> may very well end up here anyway)
>
> If this was a non-profit organizing a similar meeting would you be telling
> them to go away, that their contributions are not wanted?
>
>> These things have little or nothing to do with the PRIMARY reason of a
>> Development List.
>>
>> IF these people have something to contribute such as a [PATCH] this
>> would be correct mailing list...otherwise it's BS
>
>
> There is more to development than just [PATCH] e-mails.
>
> In this case there are multiple people/companies have code that they are
> releasing and looking to get integrated, and they want to coordinate instead
> of fighting each other. This is generally considered a good thing.
>
> Driving people away because they aren't helping in exactly the way that you
> consider ideal is a good way to kill a project.
>
> David Lang
>
>
>> On Wed, Jun 15, 2016 at 5:14 PM, David Lang <david at lang.hm> wrote:
>>>
>>> Like individuals, companies do things that benefit them. Almost all Open
>>> Source software development is done by people who benefit from the
>>> results.
>>> If benefiting from the results makes it that the LEDE project doesn't
>>> want
>>> to hear from you, the project will die _really_ fast.
>>>
>>> I hope your hostile attitude doesn't spread.
>>>
>>> David Lang
>>>
>>> On Wed, 15 Jun 2016, L. D. Pinney wrote:
>>>
>>>> Date: Wed, 15 Jun 2016 17:10:36 -0500
>>>> From: L. D. Pinney <ldpinney at gmail.com>
>>>> To: David Lang <david at lang.hm>
>>>> Cc: LEDE Development List <lede-dev at lists.infradead.org>
>>>>
>>>> Subject: Re: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
>>>>
>>>> Just because a company works on something doesn't make it evil.
>>>> Yes of course large corporations are well known for altruistic behavior.
>>>>
>>>> On Wed, Jun 15, 2016 at 5:03 PM, David Lang <david at lang.hm> wrote:
>>>>>
>>>>>
>>>>> Is it really pushing a corporate agenda to coordinate efforts to make
>>>>> LEDE/OpenWRT support remote management protocols?
>>>>>
>>>>> Just because a company works on something doesn't make it evil.
>>>>>
>>>>> David Lang
>>>>>
>>>>> On Wed, 15 Jun 2016, L. D. Pinney wrote:
>>>>>
>>>>>> Date: Wed, 15 Jun 2016 16:29:08 -0500
>>>>>> From: L. D. Pinney <ldpinney at gmail.com>
>>>>>> To: LEDE Development List <lede-dev at lists.infradead.org>
>>>>>> Subject: Re: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
>>>>>>
>>>>>>
>>>>>> Postings to the LEDE Development List should be devoted to technical
>>>>>> development issues.
>>>>>>
>>>>>> Persons from prplfoundation et.al should respect conventional mail
>>>>>> list
>>>>>> etiquette such as found here :
>>>>>>
>>>>>> http://www.arm.linux.org.uk/mailinglists/etiquette.php
>>>>>>
>>>>>> Pay particular attention to 4, 7, and 10 on the above etiquitte list.
>>>>>>
>>>>>> I see prplfoundation as a hostile takeover of LEDE / OpenWrt by a
>>>>>> corporate conspiracy.
>>>>>>
>>>>>> Free Software is meant to be free ...
>>>>>>
>>>>>> Free from the manipulation of governments and corporations.
>>>>>>
>>>>>> Pushing your corporate backed agenda on the Development List(s)
>>>>>> torques me off every time.
>>>>>>
>>>>>> On Wed, Jun 15, 2016 at 3:31 PM, Eric Schultz
>>>>>> <eschultz at prplfoundation.org> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> As we continue the TR-069 support discussion, I wanted to ask folks
>>>>>>> whether they want me to continue to cross post to these list in
>>>>>>> addition
>>>>>>> to the prplwrt list at openwrt at lists.prplfoundation.org. I have no
>>>>>>> problem doing either way, but I don't want to fill people's inbox
>>>>>>> will
>>>>>>> stuff they feel is off topic. Just wanted to get a sense of what
>>>>>>> people
>>>>>>> would prefer.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Eric
>>>>>>> --
>>>>>>> Eric Schultz, Community Manager, prpl Foundation
>>>>>>> http://www.prplfoundation.org
>>>>>>> eschultz at prplfoundation.org
>>>>>>> cell: 920-539-0404
>>>>>>> skype: ericschultzwi
>>>>>>> @EricPrpl
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Lede-dev mailing list
>>>>>>> Lede-dev at lists.infradead.org
>>>>>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Lede-dev mailing list
>>>>>> Lede-dev at lists.infradead.org
>>>>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>>>>>
>>>>>
>>>>
>>>
>>
>


From greearb at candelatech.com  Wed Jun 15 16:45:09 2016
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 15 Jun 2016 16:45:09 -0700
Subject: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
In-Reply-To: <CAJOqq5Q7ztL_issqj+jL_1UmNAbneOraWDbUNysj0Zz=8EC0zw@mail.gmail.com>
References: <5761BB29.8020303@prplfoundation.org>
 <CAJOqq5S314FgBswNo2KheO6VzvFr6jaMP=khXEWONSBnogJYLg@mail.gmail.com>
 <alpine.DEB.2.02.1606151502140.2494@nftneq.ynat.uz>
 <CAJOqq5SxXQH_BG3wP=1W7FVN9kptQvkdLc4V5r+ad4u4dRhw=Q@mail.gmail.com>
 <alpine.DEB.2.02.1606151512470.2494@nftneq.ynat.uz>
 <CAJOqq5TYpOKn0mmtO+fSmCoHyZr9Rvss_cGbZfRnEOqbwTLXEw@mail.gmail.com>
 <alpine.DEB.2.02.1606151551400.2494@nftneq.ynat.uz>
 <CAJOqq5Q7ztL_issqj+jL_1UmNAbneOraWDbUNysj0Zz=8EC0zw@mail.gmail.com>
Message-ID: <5761E885.7060305@candelatech.com>

On 06/15/2016 04:38 PM, L. D. Pinney wrote:
> Eric asked :
>
> "I wanted to ask folks whether they want me to continue to cross post to these"
>
> And "Just wanted to get a sense of what people would prefer."
>
> I posted my answer followed by my reasons.
>
> I find cross posting annoying...and in most cases irrelevant.
>
> I hope your hostile attitude doesn't spread.
> It's not likely to spread...IF and WHEN the BS stops.
>
> Stick to Development concerns and the only thing you will hear from me
> will have [PATCH] in the subject line or perhaps relevant comments.
>
> Prpl is nothing short of a corporate conspiracy ... by and for some of
> the same companies and people that refused to comply with the GPL code
> requirements that started the OpenWrt project.

Good lord, someone is trying to give code away, and probably going to a lot
of effort to make it work.

You've said your piece, the rest of this is just more noise on the list.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From dave.taht at gmail.com  Wed Jun 15 16:55:57 2016
From: dave.taht at gmail.com (Dave Taht)
Date: Wed, 15 Jun 2016 16:55:57 -0700
Subject: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
In-Reply-To: <CAJOqq5TYpOKn0mmtO+fSmCoHyZr9Rvss_cGbZfRnEOqbwTLXEw@mail.gmail.com>
References: <5761BB29.8020303@prplfoundation.org>
 <CAJOqq5S314FgBswNo2KheO6VzvFr6jaMP=khXEWONSBnogJYLg@mail.gmail.com>
 <alpine.DEB.2.02.1606151502140.2494@nftneq.ynat.uz>
 <CAJOqq5SxXQH_BG3wP=1W7FVN9kptQvkdLc4V5r+ad4u4dRhw=Q@mail.gmail.com>
 <alpine.DEB.2.02.1606151512470.2494@nftneq.ynat.uz>
 <CAJOqq5TYpOKn0mmtO+fSmCoHyZr9Rvss_cGbZfRnEOqbwTLXEw@mail.gmail.com>
Message-ID: <CAA93jw4FR0Evpkm4CNuEvZqJK-uqzyUn8LZnM5AqFd5Jh3piow@mail.gmail.com>

On Wed, Jun 15, 2016 at 3:22 PM, L. D. Pinney <ldpinney at gmail.com> wrote:
> It's a Development List ... no place for corporate agendas.

I think you are making a good point here, being that there is only one
lede list, presently, and devs would like to just see dev related
traffic....

Personally I find it incredibly difficult to sort through the patch
volume on this (and linux-wireless), and would welcome a forum (web or
email) to be able to discuss other matters.  I was invited several
times by openwrt folk to discuss things on openwrt-hackers, but my
applications there were never approved, so I'd hoped that with ledes
new governance there'd be a place to do that.

irc is difficult for me, as I am I california right now, and I tend to
be working with folk in europe, australia, and china. 24 hours is not
enough time in the day, so I fall back on async methods like email. I
think the proposal for liquiddemocracy ( I think it was called? ) was
nifty, for governance here.

...

But I have to ask: what corporation do you think I have an agenda for?
For whom did just go toe to toe with the FCC?

http://fqcodel.bufferbloat.net/~d/fcc_saner_software_practices.pdf

What is your interpretation of my agenda?

Perhaps I should try to write up why I've been involved with trying to
help openwrt, often in spite of itself, for so many years?

> The problem is more pervasive than just TR-069.

Well the cross posting thus far has been kind of limited, and in both
contexts there was a potential -dev impact. I personally welcome the
light of day being shone on one or more TR-69 implementations whether
they end up in openwrt/lede or not. There are certain tricky pieces
that I think are desirable (dns delegation being one) that kind of
need a back and forth api of some sort, and certainly better queue
management as well.

As for cleaning up the detritus of the cerowrt effort, which also
triggered your hostility, all the *really good stuff* landed in
openwrt (and now lede) long ago (good), most of the core cerowrt devs
are now openwrt/lede devs (good), and I was trying to clean out the
last pieces remaining, which seemed to require some discussion, and a
few loose pieces (hncp and mdns proxying, notably), that could use
love or the wastebin.

I'd meant to re-open an old discussion on stateless firewalling and
the use of nftables going fowards, but now I don't know where to start
that.

As for my last big priority -  getting the make-wifi-fast pieces into
lede... well, I'm kind of hoping the benefits to this distro being so
obvious that people will leap all over it, as soon as it stablizes a
bit more in linux mainline. There's a mailing list for that, and no
reason to cross post until a backport arrives.

> It's about cross-posting and pushing forwards about who's going to the
> corporate sponsored events and other drivel.


>
> These things have little or nothing to do with the PRIMARY reason of a
> Development List.
>
> IF these people have something to contribute such as a [PATCH] this
> would be correct mailing list...otherwise it's BS

In my world, git has supplanted most of what I used to use a -dev
mailing list for, but I think I understand where you are coming from
better.

>
> On Wed, Jun 15, 2016 at 5:14 PM, David Lang <david at lang.hm> wrote:
>> Like individuals, companies do things that benefit them. Almost all Open
>> Source software development is done by people who benefit from the results.
>> If benefiting from the results makes it that the LEDE project doesn't want
>> to hear from you, the project will die _really_ fast.
>>
>> I hope your hostile attitude doesn't spread.
>>
>> David Lang
>>
>> On Wed, 15 Jun 2016, L. D. Pinney wrote:
>>
>>> Date: Wed, 15 Jun 2016 17:10:36 -0500
>>> From: L. D. Pinney <ldpinney at gmail.com>
>>> To: David Lang <david at lang.hm>
>>> Cc: LEDE Development List <lede-dev at lists.infradead.org>
>>>
>>> Subject: Re: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
>>>
>>> Just because a company works on something doesn't make it evil.
>>> Yes of course large corporations are well known for altruistic behavior.
>>>
>>> On Wed, Jun 15, 2016 at 5:03 PM, David Lang <david at lang.hm> wrote:
>>>>
>>>> Is it really pushing a corporate agenda to coordinate efforts to make
>>>> LEDE/OpenWRT support remote management protocols?
>>>>
>>>> Just because a company works on something doesn't make it evil.
>>>>
>>>> David Lang
>>>>
>>>> On Wed, 15 Jun 2016, L. D. Pinney wrote:
>>>>
>>>>> Date: Wed, 15 Jun 2016 16:29:08 -0500
>>>>> From: L. D. Pinney <ldpinney at gmail.com>
>>>>> To: LEDE Development List <lede-dev at lists.infradead.org>
>>>>> Subject: Re: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
>>>>>
>>>>>
>>>>> Postings to the LEDE Development List should be devoted to technical
>>>>> development issues.
>>>>>
>>>>> Persons from prplfoundation et.al should respect conventional mail list
>>>>> etiquette such as found here :
>>>>>
>>>>> http://www.arm.linux.org.uk/mailinglists/etiquette.php
>>>>>
>>>>> Pay particular attention to 4, 7, and 10 on the above etiquitte list.
>>>>>
>>>>> I see prplfoundation as a hostile takeover of LEDE / OpenWrt by a
>>>>> corporate conspiracy.
>>>>>
>>>>> Free Software is meant to be free ...
>>>>>
>>>>> Free from the manipulation of governments and corporations.
>>>>>
>>>>> Pushing your corporate backed agenda on the Development List(s)
>>>>> torques me off every time.
>>>>>
>>>>> On Wed, Jun 15, 2016 at 3:31 PM, Eric Schultz
>>>>> <eschultz at prplfoundation.org> wrote:
>>>>>>
>>>>>>
>>>>>> As we continue the TR-069 support discussion, I wanted to ask folks
>>>>>> whether they want me to continue to cross post to these list in
>>>>>> addition
>>>>>> to the prplwrt list at openwrt at lists.prplfoundation.org. I have no
>>>>>> problem doing either way, but I don't want to fill people's inbox will
>>>>>> stuff they feel is off topic. Just wanted to get a sense of what people
>>>>>> would prefer.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Eric
>>>>>> --
>>>>>> Eric Schultz, Community Manager, prpl Foundation
>>>>>> http://www.prplfoundation.org
>>>>>> eschultz at prplfoundation.org
>>>>>> cell: 920-539-0404
>>>>>> skype: ericschultzwi
>>>>>> @EricPrpl
>>>>>>
>>>>>> _______________________________________________
>>>>>> Lede-dev mailing list
>>>>>> Lede-dev at lists.infradead.org
>>>>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Lede-dev mailing list
>>>>> Lede-dev at lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>>>>
>>>>
>>>
>>
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev



-- 
Dave T?ht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org


From drew at nixcores.com  Wed Jun 15 17:15:52 2016
From: drew at nixcores.com (Drew from NixCore)
Date: Wed, 15 Jun 2016 20:15:52 -0400
Subject: [LEDE-DEV] [PATCH] [ramips] Added NixCore X1 target V4
In-Reply-To: <5761BC01.5080409@nixcores.com>
References: <5761BC01.5080409@nixcores.com>
Message-ID: <5761EFB8.2020404@nixcores.com>

So it appears that this patch doesn't apply either.  I have re-checked 
out the latest source and made the changes manually rather than using tools.

This patch is invalid and I will be submitting V5.  Please bear with me 
as this is my first submission to LEDE

Drew

On 06/15/2016 04:35 PM, Drew from NixCore wrote:
> Added NixCore X1 ramips targethttp://nixcores.com. 
> <http://nixcores.com./>  This builds 8M and 16M images.  V4 updates 
> the patch to fix whitespace issues in V3
>
> Signed-off-by: Drew Gaylo <drew at nixcores.com>
> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
> b/target/linux/ramips/base-files/etc/board.d/02_network
> index 4728c75..69c0125 100755
> --- a/target/linux/ramips/base-files/etc/board.d/02_network
> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
> @@ -77,6 +77,7 @@ ramips_setup_interfaces()
>      mt7628|\
>      mzk-750dhp|\
>      mzk-w300nh2|\
> +    nixcore|\
>      oy-0001|\
>      pbr-m1|\
>      psg1208|\
> diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
> b/target/linux/ramips/base-files/lib/ramips.sh
> index cbe455d..76f0e43 100755
> --- a/target/linux/ramips/base-files/lib/ramips.sh
> +++ b/target/linux/ramips/base-files/lib/ramips.sh
> @@ -316,6 +316,9 @@ ramips_board_detect() {
>      *"NCS601W")
>          name="ncs601w"
>          ;;
> +    *"NixcoreX1")
> +        name="nixcore-x1"
> +        ;;
>      *"NW718")
>          name="nw718"
>          ;;
> diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
> b/target/linux/ramips/base-files/lib/upgrade/platform.sh
> index 91c9997..0094568 100755
> --- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
> @@ -94,6 +94,7 @@ platform_check_image() {
>      mzk-w300nh2|\
>      mzk-wdpr|\
>      nbg-419n|\
> +    nixcore|\
>      nw718|\
>      oy-0001|\
>      pbr-m1|\
> diff --git a/target/linux/ramips/dts/NIXCOREX1-16M.dts 
> b/target/linux/ramips/dts/NIXCOREX1-16M.dts
> new file mode 100644
> index 0000000..1e1a205
> --- /dev/null
> +++ b/target/linux/ramips/dts/NIXCOREX1-16M.dts
> @@ -0,0 +1,182 @@
> +/dts-v1/;
> +
> +/include/ "rt5350.dtsi"
> +
> +/ {
> +    compatible = "NixcoreX1", "ralink,rt5350-soc";
> +    model = "NixcoreX1";
> +
> +    chosen{
> +        bootargs = "console=ttyS1,57600";
> +    };
> +
> +    gpio-export {
> +        compatible = "gpio-export";
> +        #size-cells = <0>;
> +
> +        gpio0 {
> +            gpio-export,name = "gpio0";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio0 0 0>;
> +        };
> +        /* GPIOs 1-6 are I2C,SPI */
> +
> +        /* GPIO 7-14 are uart1 */
> +
> +        /* GPIOs 15 & 16 are uart2 */
> +
> +        /* JTAG */
> +        gpio17 {
> +            /* JTAG_TDO */
> +            gpio-export,name = "gpio17";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio0 17 0>;
> +        };
> +        gpio18 {
> +            /* JTAG_TDI */
> +            gpio-export,name = "gpio18";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio0 18 0>;
> +        };
> +        gpio19 {
> +            /* JTAG_TMS */
> +            gpio-export,name = "gpio19";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio0 19 0>;
> +        };
> +        gpio20 {
> +            /* JTAG_TCLK */
> +            gpio-export,name = "gpio20";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio0 20 0>;
> +        };
> +        gpio21 {
> +            /* JTAG_TRST_N */
> +            gpio-export,name = "gpio21";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio0 21 0>;
> +        };
> +
> +        /* ETH LEDs */
> +        /*
> +        gpio22 {
> +            gpio-export,name = "gpio22";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio1 0 0>;
> +        };
> +        gpio23 {
> +            gpio-export,name = "gpio23";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio1 1 0>;
> +        };
> +        gpio24 {
> +            gpio-export,name = "gpio24";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio1 2 0>;
> +        };
> +        gpio25 {
> +            gpio-export,name = "gpio25";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio1 3 0>;
> +        };
> +        */
> +
> +        gpio26 {
> +            /* ETH4_LED */
> +            gpio-export,name = "gpio26";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio1 4 0>;
> +        };
> +
> +        gpio27 {
> +            /* spi_cs1 */
> +            gpio-export,name = "gpio27";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio1 5 0>;
> +        };
> +    };
> +
> +};
> +
> +&gpio0{
> +    status = "okay";
> +};
> +
> +&gpio1{
> +    status = "okay";
> +};
> +
> +&i2c{
> +    status = "okay";
> +};
> +&uart{
> +    status = "okay";
> +    /* Mix of uart and gpio */
> +    reset-names = "gpio uartf";
> +};
> +&spi0{
> +    status = "okay";
> +
> +    m25p80 at 0 {
> +        #address-cells = <1>;
> +        #size-cells = <1>;
> +        compatible = "s25fl064k";
> +        reg = <0>;
> +        linux,modalias = "m25p80", "s25fl064k";
> +        spi-max-frequency = <10000000>;
> +
> +        partition at 0 {
> +            label = "uboot";
> +            reg = <0x0 0x30000>;
> +            read-only;
> +        };
> +
> +        partition at 30000 {
> +            label = "uboot-env";
> +            reg = <0x30000 0x10000>;
> +            read-only;
> +        };
> +
> +        factory: partition at 40000 {
> +            label = "factory";
> +            reg = <0x40000 0x10000>;
> +            read-only;
> +        };
> +
> +        partition at 50000 {
> +            label = "firmware";
> +            reg = <0x50000 0xfb0000>;
> +        };
> +    };
> +};
> +
> +&pinctrl {
> +    state_default: pinctrl0 {
> +        gpio {
> +            /* Associate the tjag, uartf and led groups with gpio */
> +            ralink,group = "jtag", "led", "spi_cs1";
> +            /* How do we set individual pins? */
> +            ralink,function = "gpio";
> +        };
> +    };
> +};
> +
> +&ethernet {
> +    mtd-mac-address = <&factory 0x4>;
> +};
> +
> +&esw {
> +    ralink,portmap = <0x17>;
> +};
> +
> +&wmac {
> +    ralink,mtd-eeprom = <&factory 0>;
> +};
> +
> +&ehci {
> +    status = "okay";
> +};
> +
> +&ohci {
> +    status = "okay";
> +};
> diff --git a/target/linux/ramips/dts/NIXCOREX1-8M.dts 
> b/target/linux/ramips/dts/NIXCOREX1-8M.dts
> new file mode 100644
> index 0000000..c514860
> --- /dev/null
> +++ b/target/linux/ramips/dts/NIXCOREX1-8M.dts
> @@ -0,0 +1,183 @@
> +/dts-v1/;
> +
> +/include/ "rt5350.dtsi"
> +
> +/ {
> +    compatible = "NixcoreX1", "ralink,rt5350-soc";
> +    model = "NixcoreX1";
> +
> +    chosen{
> +        bootargs = "console=ttyS1,57600";
> +    };
> +
> +    gpio-export {
> +        compatible = "gpio-export";
> +        #size-cells = <0>;
> +
> +        gpio0 {
> +            gpio-export,name = "gpio0";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio0 0 0>;
> +        };
> +        /* GPIOs 1-6 are I2C,SPI */
> +
> +        /* GPIO 7-14 are uart1 */
> +
> +        /* GPIOs 15 & 16 are uart2 */
> +
> +        /* JTAG */
> +        gpio17 {
> +            /* JTAG_TDO */
> +            gpio-export,name = "gpio17";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio0 17 0>;
> +        };
> +        gpio18 {
> +            /* JTAG_TDI */
> +            gpio-export,name = "gpio18";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio0 18 0>;
> +        };
> +        gpio19 {
> +            /* JTAG_TMS */
> +            gpio-export,name = "gpio19";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio0 19 0>;
> +        };
> +        gpio20 {
> +            /* JTAG_TCLK */
> +            gpio-export,name = "gpio20";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio0 20 0>;
> +        };
> +        gpio21 {
> +            /* JTAG_TRST_N */
> +            gpio-export,name = "gpio21";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio0 21 0>;
> +        };
> +
> +        /* ETH LEDs */
> +        /*
> +        gpio22 {
> +            gpio-export,name = "gpio22";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio1 0 0>;
> +        };
> +        gpio23 {
> +            gpio-export,name = "gpio23";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio1 1 0>;
> +        };
> +        gpio24 {
> +            gpio-export,name = "gpio24";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio1 2 0>;
> +        };
> +        gpio25 {
> +            gpio-export,name = "gpio25";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio1 3 0>;
> +        };
> +        */
> +
> +        gpio26 {
> +            /* ETH4_LED */
> +            gpio-export,name = "gpio26";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio1 4 0>;
> +        };
> +
> +        gpio27 {
> +            /* spi_cs1 */
> +            gpio-export,name = "gpio27";
> +            gpio-export,direction_may_change = <1>;
> +            gpios = <&gpio1 5 0>;
> +        };
> +    };
> +
> +};
> +
> +&gpio0{
> +    status = "okay";
> +};
> +
> +&gpio1{
> +    status = "okay";
> +};
> +
> +&i2c{
> +    status = "okay";
> +};
> +&uart{
> +    status = "okay";
> +    /* Mix of uart and gpio */
> +    reset-names = "gpio uartf";
> +};
> +&spi0{
> +    status = "okay";
> +
> +    m25p80 at 0 {
> +        #address-cells = <1>;
> +        #size-cells = <1>;
> +        compatible = "s25fl064k";
> +        reg = <0>;
> +        linux,modalias = "m25p80", "s25fl064k";
> +        spi-max-frequency = <10000000>;
> +
> +        partition at 0 {
> +            label = "uboot";
> +            reg = <0x0 0x30000>;
> +            read-only;
> +        };
> +
> +        partition at 30000 {
> +            label = "uboot-env";
> +            reg = <0x30000 0x10000>;
> +            read-only;
> +        };
> +
> +        factory: partition at 40000 {
> +            label = "factory";
> +            reg = <0x40000 0x10000>;
> +            read-only;
> +        };
> +
> +        partition at 50000 {
> +            label = "firmware";
> +            reg = <0x50000 0x7b0000>;
> +        };
> +    };
> +};
> +
> +&pinctrl {
> +    state_default: pinctrl0 {
> +        gpio {
> +            /* Associate the tjag, uartf and led groups with gpio */
> +            ralink,group = "jtag", "led", "spi_cs1";
> +            /* How do we set individual pins? */
> +            ralink,function = "gpio";
> +        };
> +    };
> +};
> +
> +&ethernet {
> +    mtd-mac-address = <&factory 0x4>;
> +};
> +
> +&esw {
> +    ralink,portmap = <0x17>;
> +};
> +
> +&wmac {
> +    ralink,mtd-eeprom = <&factory 0>;
> +};
> +
> +&ehci {
> +    status = "okay";
> +};
> +
> +&ohci {
> +    status = "okay";
> +};
> +
> diff --git a/target/linux/ramips/image/rt305x.mk 
> b/target/linux/ramips/image/rt305x.mk
> index da7fc46..db12a8e 100644
> --- a/target/linux/ramips/image/rt305x.mk
> +++ b/target/linux/ramips/image/rt305x.mk
> @@ -100,6 +100,21 @@ define BuildFirmware/HLKRM04/initramfs
>      mkhilinkfw -e -i$(call imgname,$(1),$(2))-uImage.bin -o $(call 
> imgname,$(1),$(2))-factory.bin;
>  endef
>
> +# This is called to build the nixcore image.  Build both 8MB and 16MB
> +nixcore_8mb_mtd_size=8060928
> +nixcore_16mb_mtd_size=16449536
> +define BuildFirmware/NIXCOREX1/squashfs
> +# Args are XXX, nixcore-mM and NIXCOREX1-xM
> +    $(call 
> BuildFirmware/CustomFlash/$(1),$(1),$(2)-8M,$(3)-8M,$(nixcore_8mb_mtd_size))
> +    $(call 
> BuildFirmware/CustomFlash/$(1),$(1),$(2)-16M,$(3)-16M,$(nixcore_16mb_mtd_size))
> +    # Can do somethings here after the build?
> +endef
> +define BuildFirmware/NIXCOREX1/initramfs
> +# Args are XXXX, nixcore-mM and NIXCOREX1-xM
> +    $(call BuildFirmware/OF/initramfs,$(1),$(2)-8M,$(3)-8M)
> +    $(call BuildFirmware/OF/initramfs,$(1),$(2)-16M,$(3)-16M)
> +endef
> +
>  vocore_8mb_mtd_size=8060928
>  vocore_16mb_mtd_size=16449536
>  define BuildFirmware/VOCORE/squashfs
> @@ -257,6 +272,7 @@ Image/Build/Profile/NBG-419N=$(call 
> BuildFirmware/Default4M/$(1),$(1),nbg-419n,N
>  Image/Build/Profile/MZKW300NH2=$(call 
> BuildFirmware/Edimax/$(1),$(1),mzk-w300nh2,MZK-W300NH2,$(mzkw300nh2_mtd_size),CSYS,RN52,0x50000,0xc0000)
>  Image/Build/Profile/MZKWDPR=$(call 
> BuildFirmware/Default8M/$(1),$(1),mzk-wdpr,MZK-WDPR)
>  Image/Build/Profile/NCS601W=$(call 
> BuildFirmware/Default8M/$(1),$(1),ncs601W,NCS601W)
> +Image/Build/Profile/NIXCOREX1=$(call 
> BuildFirmware/NIXCOREX1/$(1),$(1),nixcorex1,NIXCOREX1)
>  nw718_mtd_size=3801088
>  Image/Build/Profile/NW718=$(call 
> BuildFirmware/CustomFlashFactory/$(1),$(1),nw718m,NW718,$(nw718_mtd_size),ARA1B4NCRNW718;1,factory)
>  Image/Build/Profile/M2M=$(call 
> BuildFirmware/Default8M/$(1),$(1),m2m,M2M,Linux Kernel Image)
> @@ -353,6 +369,7 @@ define Image/Build/Profile/Default
>      $(call Image/Build/Profile/MZKWDPR,$(1))
>      $(call Image/Build/Profile/NBG-419N,$(1))
>      $(call Image/Build/Profile/NCS601W,$(1))
> +    $(call Image/Build/Profile/NIXCOREX1,$(1))
>      $(call Image/Build/Profile/NW718,$(1))
>      $(call Image/Build/Profile/MINIEMBWIFI,$(1))
>      $(call Image/Build/Profile/MINIEMBPLUG,$(1))
> diff --git a/target/linux/ramips/rt305x/profiles/nixcore.mk 
> b/target/linux/ramips/rt305x/profiles/nixcore.mk
> new file mode 100644
> index 0000000..22dee9b
> --- /dev/null
> +++ b/target/linux/ramips/rt305x/profiles/nixcore.mk
> @@ -0,0 +1,20 @@
> +#
> +# Copyright (C) 2014 OpenWrt.org
> +#
> +# This is free software, licensed under the GNU General Public 
> License v2.
> +# See /LICENSE for more information.
> +#
> +
> +define Profile/NIXCOREX1
> +    NAME:=NixcoreX1
> +    PACKAGES:=\
> +        kmod-usb-core kmod-usb-ohci kmod-usb2 \
> +        kmod-i2c-core kmod-i2c-ralink \
> +        kmod-spi-dev
> +endef
> +
> +define Profile/NIXCOREX1/Description
> +    Package set for Nixcore X1 board
> +endef
> +
> +$(eval $(call Profile,NIXCOREX1))
>
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev



From drew at nixcores.com  Wed Jun 15 17:37:00 2016
From: drew at nixcores.com (Drew from NixCore)
Date: Wed, 15 Jun 2016 20:37:00 -0400
Subject: [LEDE-DEV] [PATCH] [ramips] Added NixCore X1 target V5
Message-ID: <5761F4AC.1010805@nixcores.com>

Added NixCore X1 ramips target http://nixcores.com.  This builds 8M and 
16M images.  V5 updates the patch to work with the latest source.git

Signed-off-by: Drew Gaylo <drew at nixcores.com>
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index be1912a..ebcf619 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -77,6 +77,7 @@ ramips_setup_interfaces()
      mt7628|\
      mzk-750dhp|\
      mzk-w300nh2|\
+    nixcore|\
      oy-0001|\
      pbr-m1|\
      psg1208|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index bd4f33d..340a628 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -322,6 +322,9 @@ ramips_board_detect() {
      *"NCS601W")
          name="ncs601w"
          ;;
+    *"NixcoreX1")
+        name="nixcore-x1"
+        ;;
      *"NW718")
          name="nw718"
          ;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 0b3d8c7..8749c99 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -95,6 +95,7 @@ platform_check_image() {
      mzk-w300nh2|\
      mzk-wdpr|\
      nbg-419n|\
+    nixcore|\
      nw718|\
      oy-0001|\
      pbr-m1|\
diff --git a/target/linux/ramips/dts/NIXCOREX1-16M.dts 
b/target/linux/ramips/dts/NIXCOREX1-16M.dts
new file mode 100644
index 0000000..2ffcbb2
--- /dev/null
+++ b/target/linux/ramips/dts/NIXCOREX1-16M.dts
@@ -0,0 +1,95 @@
+/dts-v1/;
+
+/include/ "rt5350.dtsi"
+
+/ {
+    compatible = "NixcoreX1", "ralink,rt5350-soc";
+    model = "NixcoreX1";
+
+    chosen{
+        bootargs = "console=ttyS1,57600";
+    };
+};
+
+&gpio0{
+    status = "okay";
+};
+
+&gpio1{
+    status = "okay";
+};
+
+&i2c{
+    status = "okay";
+};
+&uart{
+    status = "okay";
+    /* Mix of uart and gpio */
+    reset-names = "gpio uartf";
+};
+&spi0{
+    status = "okay";
+
+    m25p80 at 0 {
+        #address-cells = <1>;
+        #size-cells = <1>;
+        compatible = "s25fl064k";
+        reg = <0>;
+        linux,modalias = "m25p80", "s25fl064k";
+        spi-max-frequency = <10000000>;
+
+        partition at 0 {
+            label = "uboot";
+            reg = <0x0 0x30000>;
+            read-only;
+        };
+
+        partition at 30000 {
+            label = "uboot-env";
+            reg = <0x30000 0x10000>;
+            read-only;
+        };
+
+        factory: partition at 40000 {
+            label = "factory";
+            reg = <0x40000 0x10000>;
+            read-only;
+        };
+
+        partition at 50000 {
+            label = "firmware";
+            reg = <0x50000 0xfb0000>;
+        };
+    };
+};
+
+&pinctrl {
+    state_default: pinctrl0 {
+        gpio {
+            /* Associate the tjag, uartf and led groups with gpio */
+            ralink,group = "jtag", "led", "spi_cs1";
+            /* How do we set individual pins? */
+            ralink,function = "gpio";
+        };
+    };
+};
+
+&ethernet {
+    mtd-mac-address = <&factory 0x4>;
+};
+
+&esw {
+    ralink,portmap = <0x17>;
+};
+
+&wmac {
+    ralink,mtd-eeprom = <&factory 0>;
+};
+
+&ehci {
+    status = "okay";
+};
+
+&ohci {
+    status = "okay";
+};
diff --git a/target/linux/ramips/dts/NIXCOREX1-8M.dts 
b/target/linux/ramips/dts/NIXCOREX1-8M.dts
new file mode 100644
index 0000000..ca557fd
--- /dev/null
+++ b/target/linux/ramips/dts/NIXCOREX1-8M.dts
@@ -0,0 +1,95 @@
+/dts-v1/;
+
+/include/ "rt5350.dtsi"
+
+/ {
+    compatible = "NixcoreX1", "ralink,rt5350-soc";
+    model = "NixcoreX1";
+
+    chosen{
+        bootargs = "console=ttyS1,57600";
+    };
+};
+
+&gpio0{
+    status = "okay";
+};
+
+&gpio1{
+    status = "okay";
+};
+
+&i2c{
+    status = "okay";
+};
+&uart{
+    status = "okay";
+    /* Mix of uart and gpio */
+    reset-names = "gpio uartf";
+};
+&spi0{
+    status = "okay";
+
+    m25p80 at 0 {
+        #address-cells = <1>;
+        #size-cells = <1>;
+        compatible = "s25fl064k";
+        reg = <0>;
+        linux,modalias = "m25p80", "s25fl064k";
+        spi-max-frequency = <10000000>;
+
+        partition at 0 {
+            label = "uboot";
+            reg = <0x0 0x30000>;
+            read-only;
+        };
+
+        partition at 30000 {
+            label = "uboot-env";
+            reg = <0x30000 0x10000>;
+            read-only;
+        };
+
+        factory: partition at 40000 {
+            label = "factory";
+            reg = <0x40000 0x10000>;
+            read-only;
+        };
+
+        partition at 50000 {
+            label = "firmware";
+            reg = <0x50000 0x7b0000>;
+        };
+    };
+};
+
+&pinctrl {
+    state_default: pinctrl0 {
+        gpio {
+            /* Associate the tjag, uartf and led groups with gpio */
+            ralink,group = "jtag", "led", "spi_cs1";
+            /* How do we set individual pins? */
+            ralink,function = "gpio";
+        };
+    };
+};
+
+&ethernet {
+    mtd-mac-address = <&factory 0x4>;
+};
+
+&esw {
+    ralink,portmap = <0x17>;
+};
+
+&wmac {
+    ralink,mtd-eeprom = <&factory 0>;
+};
+
+&ehci {
+    status = "okay";
+};
+
+&ohci {
+    status = "okay";
+};
diff --git a/target/linux/ramips/image/rt305x.mk 
b/target/linux/ramips/image/rt305x.mk
index da7fc46..db12a8e 100644
--- a/target/linux/ramips/image/rt305x.mk
+++ b/target/linux/ramips/image/rt305x.mk
@@ -100,6 +100,21 @@ define BuildFirmware/HLKRM04/initramfs
      mkhilinkfw -e -i$(call imgname,$(1),$(2))-uImage.bin -o $(call 
imgname,$(1),$(2))-factory.bin;
  endef

+# This is called to build the nixcore image.  Build both 8MB and 16MB
+nixcore_8mb_mtd_size=8060928
+nixcore_16mb_mtd_size=16449536
+define BuildFirmware/NIXCOREX1/squashfs
+# Args are XXX, nixcore-mM and NIXCOREX1-xM
+    $(call 
BuildFirmware/CustomFlash/$(1),$(1),$(2)-8M,$(3)-8M,$(nixcore_8mb_mtd_size))
+    $(call 
BuildFirmware/CustomFlash/$(1),$(1),$(2)-16M,$(3)-16M,$(nixcore_16mb_mtd_size))
+    # Can do somethings here after the build?
+endef
+define BuildFirmware/NIXCOREX1/initramfs
+# Args are XXXX, nixcore-mM and NIXCOREX1-xM
+    $(call BuildFirmware/OF/initramfs,$(1),$(2)-8M,$(3)-8M)
+    $(call BuildFirmware/OF/initramfs,$(1),$(2)-16M,$(3)-16M)
+endef
+
  vocore_8mb_mtd_size=8060928
  vocore_16mb_mtd_size=16449536
  define BuildFirmware/VOCORE/squashfs
@@ -257,6 +272,7 @@ Image/Build/Profile/NBG-419N=$(call 
BuildFirmware/Default4M/$(1),$(1),nbg-419n,N
  Image/Build/Profile/MZKW300NH2=$(call 
BuildFirmware/Edimax/$(1),$(1),mzk-w300nh2,MZK-W300NH2,$(mzkw300nh2_mtd_size),CSYS,RN52,0x50000,0xc0000)
  Image/Build/Profile/MZKWDPR=$(call 
BuildFirmware/Default8M/$(1),$(1),mzk-wdpr,MZK-WDPR)
  Image/Build/Profile/NCS601W=$(call 
BuildFirmware/Default8M/$(1),$(1),ncs601W,NCS601W)
+Image/Build/Profile/NIXCOREX1=$(call 
BuildFirmware/NIXCOREX1/$(1),$(1),nixcorex1,NIXCOREX1)
  nw718_mtd_size=3801088
  Image/Build/Profile/NW718=$(call 
BuildFirmware/CustomFlashFactory/$(1),$(1),nw718m,NW718,$(nw718_mtd_size),ARA1B4NCRNW718;1,factory)
  Image/Build/Profile/M2M=$(call 
BuildFirmware/Default8M/$(1),$(1),m2m,M2M,Linux Kernel Image)
@@ -353,6 +369,7 @@ define Image/Build/Profile/Default
      $(call Image/Build/Profile/MZKWDPR,$(1))
      $(call Image/Build/Profile/NBG-419N,$(1))
      $(call Image/Build/Profile/NCS601W,$(1))
+    $(call Image/Build/Profile/NIXCOREX1,$(1))
      $(call Image/Build/Profile/NW718,$(1))
      $(call Image/Build/Profile/MINIEMBWIFI,$(1))
      $(call Image/Build/Profile/MINIEMBPLUG,$(1))
diff --git a/target/linux/ramips/rt305x/profiles/nixcore.mk 
b/target/linux/ramips/rt305x/profiles/nixcore.mk
new file mode 100644
index 0000000..22dee9b
--- /dev/null
+++ b/target/linux/ramips/rt305x/profiles/nixcore.mk
@@ -0,0 +1,20 @@
+#
+# Copyright (C) 2014 OpenWrt.org
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+
+define Profile/NIXCOREX1
+    NAME:=NixcoreX1
+    PACKAGES:=\
+        kmod-usb-core kmod-usb-ohci kmod-usb2 \
+        kmod-i2c-core kmod-i2c-ralink \
+        kmod-spi-dev
+endef
+
+define Profile/NIXCOREX1/Description
+    Package set for Nixcore X1 board
+endef
+
+$(eval $(call Profile,NIXCOREX1))



From john at klam.ca  Wed Jun 15 17:38:00 2016
From: john at klam.ca (John Allen)
Date: Wed, 15 Jun 2016 20:38:00 -0400
Subject: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
In-Reply-To: <CAJOqq5SxXQH_BG3wP=1W7FVN9kptQvkdLc4V5r+ad4u4dRhw=Q@mail.gmail.com>
References: <5761BB29.8020303@prplfoundation.org>
 <CAJOqq5S314FgBswNo2KheO6VzvFr6jaMP=khXEWONSBnogJYLg@mail.gmail.com>
 <alpine.DEB.2.02.1606151502140.2494@nftneq.ynat.uz>
 <CAJOqq5SxXQH_BG3wP=1W7FVN9kptQvkdLc4V5r+ad4u4dRhw=Q@mail.gmail.com>
Message-ID: <ab942f91-6e75-41b4-5573-ae533cceb18b@klam.ca>

Yes, I would like Eric to continue posting "here". However, I think we 
need to define "here", I think we need a couple more lists dedicated to 
Lede, a "I've got a question/Help list" and "the think tank list". 
Conversation about the future direction of Lede including this 
conversation about TR-069 should probably be held in the "think tank". 
Whether these should be moderated or not is up to the you!

JohnA


On 2016-06-15 6:10 PM, L. D. Pinney wrote:
> Just because a company works on something doesn't make it evil.
> Yes of course large corporations are well known for altruistic behavior.
>
> On Wed, Jun 15, 2016 at 5:03 PM, David Lang <david at lang.hm> wrote:
>> Is it really pushing a corporate agenda to coordinate efforts to make
>> LEDE/OpenWRT support remote management protocols?
>>
>> Just because a company works on something doesn't make it evil.
>>
>> David Lang
>>
>> On Wed, 15 Jun 2016, L. D. Pinney wrote:
>>
>>> Date: Wed, 15 Jun 2016 16:29:08 -0500
>>> From: L. D. Pinney <ldpinney at gmail.com>
>>> To: LEDE Development List <lede-dev at lists.infradead.org>
>>> Subject: Re: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
>>>
>>>
>>> Postings to the LEDE Development List should be devoted to technical
>>> development issues.
>>>
>>> Persons from prplfoundation et.al should respect conventional mail list
>>> etiquette such as found here :
>>>
>>> http://www.arm.linux.org.uk/mailinglists/etiquette.php
>>>
>>> Pay particular attention to 4, 7, and 10 on the above etiquitte list.
>>>
>>> I see prplfoundation as a hostile takeover of LEDE / OpenWrt by a
>>> corporate conspiracy.
>>>
>>> Free Software is meant to be free ...
>>>
>>> Free from the manipulation of governments and corporations.
>>>
>>> Pushing your corporate backed agenda on the Development List(s)
>>> torques me off every time.
>>>
>>> On Wed, Jun 15, 2016 at 3:31 PM, Eric Schultz
>>> <eschultz at prplfoundation.org> wrote:
>>>> As we continue the TR-069 support discussion, I wanted to ask folks
>>>> whether they want me to continue to cross post to these list in addition
>>>> to the prplwrt list at openwrt at lists.prplfoundation.org. I have no
>>>> problem doing either way, but I don't want to fill people's inbox will
>>>> stuff they feel is off topic. Just wanted to get a sense of what people
>>>> would prefer.
>>>>
>>>> Thanks,
>>>>
>>>> Eric
>>>> --
>>>> Eric Schultz, Community Manager, prpl Foundation
>>>> http://www.prplfoundation.org
>>>> eschultz at prplfoundation.org
>>>> cell: 920-539-0404
>>>> skype: ericschultzwi
>>>> @EricPrpl
>>>>
>>>> _______________________________________________
>>>> Lede-dev mailing list
>>>> Lede-dev at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>>
>>> _______________________________________________
>>> Lede-dev mailing list
>>> Lede-dev at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev



From david at lang.hm  Wed Jun 15 19:52:34 2016
From: david at lang.hm (David Lang)
Date: Wed, 15 Jun 2016 19:52:34 -0700 (PDT)
Subject: [LEDE-DEV] looking for ar7 testers
In-Reply-To: <3031035b-004b-2cea-63ec-580fcfd83bab@phrozen.org>
References: <3031035b-004b-2cea-63ec-580fcfd83bab@phrozen.org>
Message-ID: <alpine.DEB.2.02.1606150125080.6774@nftneq.ynat.uz>

Is there a list of hardware that is needed? (or do you want donations of money 
for the project to buy hardware)?

David Lang

On Wed, 15 Jun 2016, John Crispin wrote:

> Date: Wed, 15 Jun 2016 09:29:31 +0200
> From: John Crispin <john at phrozen.org>
> To: LEDE Development List <lede-dev at lists.infradead.org>
> Subject: [LEDE-DEV] looking for ar7 testers
> 
> Hi,
>
> the ar7 boots with v4.4 but ethernet apparently passes no traffic and
> atm is untested.
>
> we need someone to pick up the maintainer ship and fix this issue. i
> have no longer got any hw that can be used for testing. we need this
> fixed for it to be part of the release.
>
> 	John
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
>


From daniel at gimpelevich.san-francisco.ca.us  Wed Jun 15 21:42:57 2016
From: daniel at gimpelevich.san-francisco.ca.us (Daniel Gimpelevich)
Date: Wed, 15 Jun 2016 21:42:57 -0700
Subject: [LEDE-DEV] looking for ar7 testers
In-Reply-To: <alpine.DEB.2.02.1606150125080.6774@nftneq.ynat.uz>
References: <3031035b-004b-2cea-63ec-580fcfd83bab@phrozen.org>
 <alpine.DEB.2.02.1606150125080.6774@nftneq.ynat.uz>
Message-ID: <1466052177.7651.9.camel@chimera>

Ethernet support on ar7 had to be shoehorn-hacked in for each device
individually. What would fix it on one would break it on another. I had
been in process of trying to come up with a unifying Ethernet hack a few
years ago, but I became discouraged by the incomplete GPL tarballs, the
lack of a wireless driver for the 1350A chipset, the kludgey state of
ATM support, and the shortage of RAM on pretty much every supported
device.

On Wed, 2016-06-15 at 19:52 -0700, David Lang wrote:
> Is there a list of hardware that is needed? (or do you want donations of money 
> for the project to buy hardware)?
> 
> David Lang
> 
> On Wed, 15 Jun 2016, John Crispin wrote:
> 
> > Date: Wed, 15 Jun 2016 09:29:31 +0200
> > From: John Crispin <john at phrozen.org>
> > To: LEDE Development List <lede-dev at lists.infradead.org>
> > Subject: [LEDE-DEV] looking for ar7 testers
> > 
> > Hi,
> >
> > the ar7 boots with v4.4 but ethernet apparently passes no traffic and
> > atm is untested.
> >
> > we need someone to pick up the maintainer ship and fix this issue. i
> > have no longer got any hw that can be used for testing. we need this
> > fixed for it to be part of the release.
> >
> > 	John
> >
> > _______________________________________________
> > Lede-dev mailing list
> > Lede-dev at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/lede-dev




From david at lang.hm  Wed Jun 15 21:54:47 2016
From: david at lang.hm (David Lang)
Date: Wed, 15 Jun 2016 21:54:47 -0700 (PDT)
Subject: [LEDE-DEV] looking for ar7 testers
In-Reply-To: <1466052177.7651.9.camel@chimera>
References: <3031035b-004b-2cea-63ec-580fcfd83bab@phrozen.org>
 <alpine.DEB.2.02.1606150125080.6774@nftneq.ynat.uz>
 <1466052177.7651.9.camel@chimera>
Message-ID: <alpine.DEB.2.02.1606152153070.6774@nftneq.ynat.uz>

Ok, so it sounds like this particular hardware is not wanted and support may be 
dropped.

But for the general case, my question still stands. What hardware (including 
brand-new devices, wishlists for future devices, etc) is wanted, how can it be 
donated?

David Lang

On Wed, 15 Jun 2016, Daniel Gimpelevich wrote:

> Ethernet support on ar7 had to be shoehorn-hacked in for each device
> individually. What would fix it on one would break it on another. I had
> been in process of trying to come up with a unifying Ethernet hack a few
> years ago, but I became discouraged by the incomplete GPL tarballs, the
> lack of a wireless driver for the 1350A chipset, the kludgey state of
> ATM support, and the shortage of RAM on pretty much every supported
> device.
>
> On Wed, 2016-06-15 at 19:52 -0700, David Lang wrote:
>> Is there a list of hardware that is needed? (or do you want donations of money
>> for the project to buy hardware)?
>>
>> David Lang
>>
>> On Wed, 15 Jun 2016, John Crispin wrote:
>>
>>> Date: Wed, 15 Jun 2016 09:29:31 +0200
>>> From: John Crispin <john at phrozen.org>
>>> To: LEDE Development List <lede-dev at lists.infradead.org>
>>> Subject: [LEDE-DEV] looking for ar7 testers
>>>
>>> Hi,
>>>
>>> the ar7 boots with v4.4 but ethernet apparently passes no traffic and
>>> atm is untested.
>>>
>>> we need someone to pick up the maintainer ship and fix this issue. i
>>> have no longer got any hw that can be used for testing. we need this
>>> fixed for it to be part of the release.
>>>
>>> 	John
>>>
>>> _______________________________________________
>>> Lede-dev mailing list
>>> Lede-dev at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>
>
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
>


From john at phrozen.org  Wed Jun 15 22:25:46 2016
From: john at phrozen.org (John Crispin)
Date: Thu, 16 Jun 2016 07:25:46 +0200
Subject: [LEDE-DEV] DGN3500 nas mac
In-Reply-To: <1466027413.10303.7.camel@chimera>
References: <94da699d-a26e-fb99-3696-1c241bd20d90@phrozen.org>
 <1466027413.10303.7.camel@chimera>
Message-ID: <19650aae-4ff4-cd87-781d-bea3b0c97415@phrozen.org>



On 15/06/2016 23:50, Daniel Gimpelevich wrote:
> On Wed, 2016-06-15 at 16:02 +0200, John Crispin wrote:
>> Hi,
>>
>> 492964e741f1e0254b6ed7c0a095551a31d25dc9 slipped by me without me
>> realizing that it is broken.
>>
>> i staged a fix in my tree for this
>> https://git.lede-project.org/?p=lede/blogic/staging.git;a=commit;h=08eb51390bd898a2f2b8023515c0f6482887faa7
>>
>> however the esi stuff needs to be changed to apply the mac from wan to
>> the nas interface.
>>
>> maybe we can add this as an init.d script as part of the esi package ?
>>
>> 	John
> 
> Neither the merged patch nor the staged fix (which I already tried
> myself) work properly. I have a fix for this I haven't pushed yet,
> because it still does not fix the separate but related issue of a random
> wifi macaddr which resists userspace changes. I now remember this was
> the reason I kept insisting on the kernel parameters. Once Jonas ACK's
> the relevant change to his patch, I'll rewrite the removed 997.patch to
> make use of it, and I'll push both fixes to Github for a PR.
> 

kevin tested the staged fix and it makes his unit have a valid lan and
wan mac. please explain why this is incorrect.

	John

> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 


From daniel at gimpelevich.san-francisco.ca.us  Wed Jun 15 22:39:48 2016
From: daniel at gimpelevich.san-francisco.ca.us (Daniel Gimpelevich)
Date: Wed, 15 Jun 2016 22:39:48 -0700
Subject: [LEDE-DEV] DGN3500 nas mac
In-Reply-To: <19650aae-4ff4-cd87-781d-bea3b0c97415@phrozen.org>
References: <94da699d-a26e-fb99-3696-1c241bd20d90@phrozen.org>
 <1466027413.10303.7.camel@chimera>
 <19650aae-4ff4-cd87-781d-bea3b0c97415@phrozen.org>
Message-ID: <1466055588.7651.20.camel@chimera>

On Thu, 2016-06-16 at 07:25 +0200, John Crispin wrote:
> kevin tested the staged fix and it makes his unit have a valid lan and
> wan mac. please explain why this is incorrect.
>         John

The LAN macaddr is set only for the bridge. If you change the VLAN
config to allow separate out individual LAN ports, they do not have a
valid macaddr. I wouldn't have expected Kevin to test that, but I have a
use case for it. I successfully tested an alternate patch which makes
this work, but I've unstaged it because it does not fix the wifi
macaddr. As for WAN, my eventual PR will contain a patch I have prepared
to the Lantiq ADSL app package which takes care of this even if
everything else is left as is.




From john at phrozen.org  Wed Jun 15 23:11:54 2016
From: john at phrozen.org (John Crispin)
Date: Thu, 16 Jun 2016 08:11:54 +0200
Subject: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
In-Reply-To: <ab942f91-6e75-41b4-5573-ae533cceb18b@klam.ca>
References: <5761BB29.8020303@prplfoundation.org>
 <CAJOqq5S314FgBswNo2KheO6VzvFr6jaMP=khXEWONSBnogJYLg@mail.gmail.com>
 <alpine.DEB.2.02.1606151502140.2494@nftneq.ynat.uz>
 <CAJOqq5SxXQH_BG3wP=1W7FVN9kptQvkdLc4V5r+ad4u4dRhw=Q@mail.gmail.com>
 <ab942f91-6e75-41b4-5573-ae533cceb18b@klam.ca>
Message-ID: <922b01ca-bde3-7818-421f-2fb7bf69f7c0@phrozen.org>

what an utterly bizarre conversation to wake up to.

the list is  non-subscribe/public post for a reason. i dont see why
there is a need for X mailing lists. If you dont like it, then dont read it.

this is a development related discussion and the rules clearly state
that we would prefer companies to hold them in public. fair enough its
not about actual source code yet, but it aims to get people involved in
creating such code.

if there is anything we should ask people not to do, then it is having
these 40 email threads which divert from the original topic.

this is a free community project. lets keep it free and not try to
impose any rules beyond the "be nice to each other" and "be
open/transparent" ones.

anyone still recall what OP actually wanted ?

	John




On 16/06/2016 02:38, John Allen wrote:
> Yes, I would like Eric to continue posting "here". However, I think we
> need to define "here", I think we need a couple more lists dedicated to
> Lede, a "I've got a question/Help list" and "the think tank list".
> Conversation about the future direction of Lede including this
> conversation about TR-069 should probably be held in the "think tank".
> Whether these should be moderated or not is up to the you!
> 
> JohnA
> 
> 
> On 2016-06-15 6:10 PM, L. D. Pinney wrote:
>> Just because a company works on something doesn't make it evil.
>> Yes of course large corporations are well known for altruistic behavior.
>>
>> On Wed, Jun 15, 2016 at 5:03 PM, David Lang <david at lang.hm> wrote:
>>> Is it really pushing a corporate agenda to coordinate efforts to make
>>> LEDE/OpenWRT support remote management protocols?
>>>
>>> Just because a company works on something doesn't make it evil.
>>>
>>> David Lang
>>>
>>> On Wed, 15 Jun 2016, L. D. Pinney wrote:
>>>
>>>> Date: Wed, 15 Jun 2016 16:29:08 -0500
>>>> From: L. D. Pinney <ldpinney at gmail.com>
>>>> To: LEDE Development List <lede-dev at lists.infradead.org>
>>>> Subject: Re: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
>>>>
>>>>
>>>> Postings to the LEDE Development List should be devoted to technical
>>>> development issues.
>>>>
>>>> Persons from prplfoundation et.al should respect conventional mail list
>>>> etiquette such as found here :
>>>>
>>>> http://www.arm.linux.org.uk/mailinglists/etiquette.php
>>>>
>>>> Pay particular attention to 4, 7, and 10 on the above etiquitte list.
>>>>
>>>> I see prplfoundation as a hostile takeover of LEDE / OpenWrt by a
>>>> corporate conspiracy.
>>>>
>>>> Free Software is meant to be free ...
>>>>
>>>> Free from the manipulation of governments and corporations.
>>>>
>>>> Pushing your corporate backed agenda on the Development List(s)
>>>> torques me off every time.
>>>>
>>>> On Wed, Jun 15, 2016 at 3:31 PM, Eric Schultz
>>>> <eschultz at prplfoundation.org> wrote:
>>>>> As we continue the TR-069 support discussion, I wanted to ask folks
>>>>> whether they want me to continue to cross post to these list in
>>>>> addition
>>>>> to the prplwrt list at openwrt at lists.prplfoundation.org. I have no
>>>>> problem doing either way, but I don't want to fill people's inbox will
>>>>> stuff they feel is off topic. Just wanted to get a sense of what
>>>>> people
>>>>> would prefer.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Eric
>>>>> -- 
>>>>> Eric Schultz, Community Manager, prpl Foundation
>>>>> http://www.prplfoundation.org
>>>>> eschultz at prplfoundation.org
>>>>> cell: 920-539-0404
>>>>> skype: ericschultzwi
>>>>> @EricPrpl
>>>>>
>>>>> _______________________________________________
>>>>> Lede-dev mailing list
>>>>> Lede-dev at lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>>>
>>>> _______________________________________________
>>>> Lede-dev mailing list
>>>> Lede-dev at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>>>
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
> 
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


From john at phrozen.org  Wed Jun 15 23:14:16 2016
From: john at phrozen.org (John Crispin)
Date: Thu, 16 Jun 2016 08:14:16 +0200
Subject: [LEDE-DEV] looking for ar7 testers
In-Reply-To: <alpine.DEB.2.02.1606152153070.6774@nftneq.ynat.uz>
References: <3031035b-004b-2cea-63ec-580fcfd83bab@phrozen.org>
 <alpine.DEB.2.02.1606150125080.6774@nftneq.ynat.uz>
 <1466052177.7651.9.camel@chimera>
 <alpine.DEB.2.02.1606152153070.6774@nftneq.ynat.uz>
Message-ID: <d35c82a2-58eb-d47f-5f71-8b3a132f50da@phrozen.org>



On 16/06/2016 06:54, David Lang wrote:
> Ok, so it sounds like this particular hardware is not wanted and support
> may be dropped.

that is what i am trying to figure out

> 
> But for the general case, my question still stands. What hardware
> (including brand-new devices, wishlists for future devices, etc) is
> wanted, how can it be donated?

talk to your local developer and support him as per need i guess.

personally i am right now looking for donations of ipq hardware that is
not locked down.



> David Lang
> 
> On Wed, 15 Jun 2016, Daniel Gimpelevich wrote:
> 
>> Ethernet support on ar7 had to be shoehorn-hacked in for each device
>> individually. What would fix it on one would break it on another. I had
>> been in process of trying to come up with a unifying Ethernet hack a few
>> years ago, but I became discouraged by the incomplete GPL tarballs, the
>> lack of a wireless driver for the 1350A chipset, the kludgey state of
>> ATM support, and the shortage of RAM on pretty much every supported
>> device.
>>
>> On Wed, 2016-06-15 at 19:52 -0700, David Lang wrote:
>>> Is there a list of hardware that is needed? (or do you want donations
>>> of money
>>> for the project to buy hardware)?
>>>
>>> David Lang
>>>
>>> On Wed, 15 Jun 2016, John Crispin wrote:
>>>
>>>> Date: Wed, 15 Jun 2016 09:29:31 +0200
>>>> From: John Crispin <john at phrozen.org>
>>>> To: LEDE Development List <lede-dev at lists.infradead.org>
>>>> Subject: [LEDE-DEV] looking for ar7 testers
>>>>
>>>> Hi,
>>>>
>>>> the ar7 boots with v4.4 but ethernet apparently passes no traffic and
>>>> atm is untested.
>>>>
>>>> we need someone to pick up the maintainer ship and fix this issue. i
>>>> have no longer got any hw that can be used for testing. we need this
>>>> fixed for it to be part of the release.
>>>>
>>>>     John
>>>>
>>>> _______________________________________________
>>>> Lede-dev mailing list
>>>> Lede-dev at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>
>>
>>
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


From daniel at daniel.thecshore.com  Tue Jun 14 14:30:39 2016
From: daniel at daniel.thecshore.com (Daniel Curran-Dickinson)
Date: Tue, 14 Jun 2016 17:30:39 -0400
Subject: [LEDE-DEV] lede integration issues remaining from the detrius
 of cerowrt
In-Reply-To: <alpine.DEB.2.02.1606141048400.2494@nftneq.ynat.uz>
References: <CAA93jw7=bHNXJqmjWmg3CHHH-biua17wK4AHfn_wB0wPWs=EqQ@mail.gmail.com>
 <CAJOqq5TB4qki1iWHZd71kzXYoA=A3+4BeycoNPKqRXFWZ6bMZQ@mail.gmail.com>
 <f6898485-e1d4-ec35-4563-4591512d2d84@mein.io>
 <1465868455.2580.35.camel@homehost>
 <alpine.DEB.2.02.1606141048400.2494@nftneq.ynat.uz>
Message-ID: <1465939839.2633.29.camel@homehost>


On Tue, 2016-06-14 at 11:05 -0700, David Lang wrote: 
> On Mon, 13 Jun 2016, Daniel Curran-Dickinson wrote:
> 
> > On Mon, 2016-06-13 at 11:17 +0200, Jo-Philipp Wich wrote:
> >> Hi,
> >>
> >> no need to overreact :)  I think parts of the topics are about the
> >
> > Hope you're referring to Pinney and not me!  I was concerned because
> > Dave Taht's email and David Lang's post) seemed to me to imply changing the
> > defaults to suit bigger iron as the default rather than simply making
> > it a supported option.
> 
> I think you misunderstood our comments and concerns. We want the bigger hardware 
> to be a supported option, and don't like the response that this initially got of 
> "that's something only needed for bigger hardware, we shouldn't have it as an 
> option in LEDE"

I think you misunderstood my reaction.  I didn't mean that I didn't
think bigger hardware/VMs should be supported - in fact I have some
patches in queue for exactly that kind of scenario - I just was
concerned that it appeared to be a request to alter the defaults, not
just allow the support.

> 
> Both of us play with very small hardware as well, we don't want to close out the 
> low end devices.
> 
> > I also think that talking about a 5-10 plan as
> > the basis if making decision of what to include by default in *current* builds
> > is rather foolish thinking.  Yes planning for the future is important but to
> > it reminds of a quote from when I was religious: "Don't be so heavenly-minded
> > you're no earthly good".  Basically here and now needs not to be forgotten in
> > dreams of future wonders.
> 
> Agreed, but at the same time you shouldn't ignore support for the larger 
> hardware.
> 
> Remember, this thread started with the request to support hard drives >2TB and 
> the reaction was "we don't need that routers only have a few tens of KB of 
> flash" (even though it turned out that the support has already been included)

Again I think you read too much into what I said (admittedly I do the
same myself, at times, as you well know), but I wasn't saying there is
no use case for it, only that it's not the 'primary', or 'default' use
case.

By all means, I'm game for maximum flexibility that doesn't hurt the
primary use case. 

In the case the 2TB+ drives, I was concerned that such support would come
*at the expense of* the primary use; fortunately it doesn't, but if it did,
I would argue against kernel options (for example) for making the support
the *default* (e.g. in buildbot builds), except maybe for something like x86
boards/use cases (in the case of x86 I'm not sure that limiting hardware
support to save space is in most cases necessary; other cases like default
userspace I'd argue should be kept consistent and changes from default
management with things like ImageBuilder.

In general I'm a fan of ImageBuilder because, provided the kernel support is there,
you can use the SDK and build whatever packages you want to add on, and use
ImageBuilder to generate images that use those packages (along with the standard
ones you still want), without getting in the way of the primary use case.

> >
> > To a certain extent though, I question the need for something as restricted as OpenWrt
> > for the new bigger devices anyway; there are elements like netifd that would be good to
> > see continue, but I'm not sure that most of OpenWrt really makes as much sense when you're
> > not needing to squeeze maximum use out of very erase block, and that therefore, while it
> > may be a smaller market/mindshare, that focussing on the the true embedded type scenario,
> > seems to be more of what LEDE's niche is.
> 
> LEDE/OpenWRT is a good fit for any device that operates on raw flash instead of 
> a hard drive or ssd with wear leveling. Once you have storage that you don't 
> worry about wearing out and is large enough to hold a normal Linux Distro, it 
> makes sense to move to such a distro and update packages individually.

Hmmm...the wear levelling thing is confusing.  I was told by someone who I thought knew
what they were talking about, that flash chips included some form of hardware-based
wear levelling built in already.  Apparently that is was inaccurate (hardware-level
support is something I only having minor knowledge of; it's not the part the interests me,
nor where I have worked on it for any length of time; I'm more interested in what you can
do with existing hardware support combined with software rather developing the core support
itself).

> But when you have a limited amount of boot/OS storage that does not have wear 
> leveling in place, then the OpenWRT/LEDE approach of a complete filesystem image 
> that gets updated as a whole still makes sense.
> 
> Even when we have a few Gb of flash storage available, we will still want to use 
> compressed, read-only filesystems for the main OS packages.

Actually I'm rather a fan of the squashfs / overlay, or alpine-style LBU
thing where you revert to 'factory defaults' by removing all changes
from flashed (or stored on read-only partition in the case of alpine)
image.  Also squashfs shrinks the size requirements quite nicely for
things you know in advance you need.

Whether that means whole LEDE stack remains useful on bigger iron, or
whether it simply provides some good starting points, is something I'm
of two minds about.

I'm not 100% how I feel about LEDE/OpenWrt on larger devices; in some
respects I want to make LEDE/OpenWrt useful for e.g. NAS/IoT and/or
lightweight containers/VMs, OTH I'm not sure that's a useful way to
spend my time, given other alternatives that are already available.

Regards,

Daniel 






From champetier.etienne at gmail.com  Thu Jun 16 00:07:03 2016
From: champetier.etienne at gmail.com (Etienne Champetier)
Date: Thu, 16 Jun 2016 09:07:03 +0200
Subject: [LEDE-DEV] /var/run world writable
Message-ID: <CAOdf3gruA-xhG4XCDNZO9y4NSc=j89jk7UO-v_R6HXah7cYZ_Q@mail.gmail.com>

Hi,

since this procd commit from 2013
https://git.lede-project.org/?p=project/procd.git;a=blob;f=early.c;h=063e1a6abcc8ecdf22b9c8c11b2e81cc2460bcea;hb=be950c5e56b86509e1e237931d0ac8203372be82

/var/run (also /var/state and /var/lock) is world writable, with no
sticky bit, which means unpriviledge process can delete root files (or
many other attacks).

Do you remember if there was a reason to make it 0777 ?
I think before procd this was only handled by /etc/init.d/boot and it was 0755

On ubuntu 15.10 it's 0755 for /var/run and 1777 for /var/state and /var/lock
see also FHS stating that /run (new /var/run) should not be world writable
http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s15.html#idm236092622080

Regards
Etienne


From john at phrozen.org  Thu Jun 16 00:11:05 2016
From: john at phrozen.org (John Crispin)
Date: Thu, 16 Jun 2016 09:11:05 +0200
Subject: [LEDE-DEV] /var/run world writable
In-Reply-To: <CAOdf3gruA-xhG4XCDNZO9y4NSc=j89jk7UO-v_R6HXah7cYZ_Q@mail.gmail.com>
References: <CAOdf3gruA-xhG4XCDNZO9y4NSc=j89jk7UO-v_R6HXah7cYZ_Q@mail.gmail.com>
Message-ID: <5356fbc8-dd82-9a3d-819d-99ab02a67dde@phrozen.org>

no reason feel free to send a patch to fix it.

	John

On 16/06/2016 09:07, Etienne Champetier wrote:
> Hi,
> 
> since this procd commit from 2013
> https://git.lede-project.org/?p=project/procd.git;a=blob;f=early.c;h=063e1a6abcc8ecdf22b9c8c11b2e81cc2460bcea;hb=be950c5e56b86509e1e237931d0ac8203372be82
> 
> /var/run (also /var/state and /var/lock) is world writable, with no
> sticky bit, which means unpriviledge process can delete root files (or
> many other attacks).
> 
> Do you remember if there was a reason to make it 0777 ?
> I think before procd this was only handled by /etc/init.d/boot and it was 0755
> 
> On ubuntu 15.10 it's 0755 for /var/run and 1777 for /var/state and /var/lock
> see also FHS stating that /run (new /var/run) should not be world writable
> http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s15.html#idm236092622080
> 
> Regards
> Etienne
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 


From ldpinney at gmail.com  Thu Jun 16 00:18:55 2016
From: ldpinney at gmail.com (L. D. Pinney)
Date: Thu, 16 Jun 2016 02:18:55 -0500
Subject: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
In-Reply-To: <CAJOqq5SdZf=xjQRJsaaYaSunueNtBnzd8pNMHeh+rooAEDy2JA@mail.gmail.com>
References: <5761BB29.8020303@prplfoundation.org>
 <CAJOqq5S314FgBswNo2KheO6VzvFr6jaMP=khXEWONSBnogJYLg@mail.gmail.com>
 <alpine.DEB.2.02.1606151502140.2494@nftneq.ynat.uz>
 <CAJOqq5SxXQH_BG3wP=1W7FVN9kptQvkdLc4V5r+ad4u4dRhw=Q@mail.gmail.com>
 <ab942f91-6e75-41b4-5573-ae533cceb18b@klam.ca>
 <922b01ca-bde3-7818-421f-2fb7bf69f7c0@phrozen.org>
 <CAJOqq5SdZf=xjQRJsaaYaSunueNtBnzd8pNMHeh+rooAEDy2JA@mail.gmail.com>
Message-ID: <CAJOqq5TXNNFteDq2fm79Gu7aojsMqJHP7PaQUaa_gYJfiod2TA@mail.gmail.com>

OP wants to know if it's OK to cross post about old subjects.

Particularly TR-069 already available as packages for LEDE.

Notably freecwmp and easycwmp

NAK... use reasonable mailing list etiquette.

On Thu, Jun 16, 2016 at 2:17 AM, L. D. Pinney <ldpinney at gmail.com> wrote:
> OP wants to know if it's OK to cross post about old subjects.
>
> Particularly TR-069 already available as packages for LEDE.
>
> Notably freecwmp and easycwmp
>
> NAK... use reasonable mailing list etiquette.
>
>
>
>
> On Thu, Jun 16, 2016 at 1:11 AM, John Crispin <john at phrozen.org> wrote:
>>
>> what an utterly bizarre conversation to wake up to.
>>
>> the list is  non-subscribe/public post for a reason. i dont see why
>> there is a need for X mailing lists. If you dont like it, then dont read
>> it.
>>
>> this is a development related discussion and the rules clearly state
>> that we would prefer companies to hold them in public. fair enough its
>> not about actual source code yet, but it aims to get people involved in
>> creating such code.
>>
>> if there is anything we should ask people not to do, then it is having
>> these 40 email threads which divert from the original topic.
>>
>> this is a free community project. lets keep it free and not try to
>> impose any rules beyond the "be nice to each other" and "be
>> open/transparent" ones.
>>
>> anyone still recall what OP actually wanted ?
>>
>>         John
>>
>>
>>
>>
>> On 16/06/2016 02:38, John Allen wrote:
>> > Yes, I would like Eric to continue posting "here". However, I think we
>> > need to define "here", I think we need a couple more lists dedicated to
>> > Lede, a "I've got a question/Help list" and "the think tank list".
>> > Conversation about the future direction of Lede including this
>> > conversation about TR-069 should probably be held in the "think tank".
>> > Whether these should be moderated or not is up to the you!
>> >
>> > JohnA
>> >
>> >
>> > On 2016-06-15 6:10 PM, L. D. Pinney wrote:
>> >> Just because a company works on something doesn't make it evil.
>> >> Yes of course large corporations are well known for altruistic
>> >> behavior.
>> >>
>> >> On Wed, Jun 15, 2016 at 5:03 PM, David Lang <david at lang.hm> wrote:
>> >>> Is it really pushing a corporate agenda to coordinate efforts to make
>> >>> LEDE/OpenWRT support remote management protocols?
>> >>>
>> >>> Just because a company works on something doesn't make it evil.
>> >>>
>> >>> David Lang
>> >>>
>> >>> On Wed, 15 Jun 2016, L. D. Pinney wrote:
>> >>>
>> >>>> Date: Wed, 15 Jun 2016 16:29:08 -0500
>> >>>> From: L. D. Pinney <ldpinney at gmail.com>
>> >>>> To: LEDE Development List <lede-dev at lists.infradead.org>
>> >>>> Subject: Re: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
>> >>>>
>> >>>>
>> >>>> Postings to the LEDE Development List should be devoted to technical
>> >>>> development issues.
>> >>>>
>> >>>> Persons from prplfoundation et.al should respect conventional mail
>> >>>> list
>> >>>> etiquette such as found here :
>> >>>>
>> >>>> http://www.arm.linux.org.uk/mailinglists/etiquette.php
>> >>>>
>> >>>> Pay particular attention to 4, 7, and 10 on the above etiquitte list.
>> >>>>
>> >>>> I see prplfoundation as a hostile takeover of LEDE / OpenWrt by a
>> >>>> corporate conspiracy.
>> >>>>
>> >>>> Free Software is meant to be free ...
>> >>>>
>> >>>> Free from the manipulation of governments and corporations.
>> >>>>
>> >>>> Pushing your corporate backed agenda on the Development List(s)
>> >>>> torques me off every time.
>> >>>>
>> >>>> On Wed, Jun 15, 2016 at 3:31 PM, Eric Schultz
>> >>>> <eschultz at prplfoundation.org> wrote:
>> >>>>> As we continue the TR-069 support discussion, I wanted to ask folks
>> >>>>> whether they want me to continue to cross post to these list in
>> >>>>> addition
>> >>>>> to the prplwrt list at openwrt at lists.prplfoundation.org. I have no
>> >>>>> problem doing either way, but I don't want to fill people's inbox
>> >>>>> will
>> >>>>> stuff they feel is off topic. Just wanted to get a sense of what
>> >>>>> people
>> >>>>> would prefer.
>> >>>>>
>> >>>>> Thanks,
>> >>>>>
>> >>>>> Eric
>> >>>>> --
>> >>>>> Eric Schultz, Community Manager, prpl Foundation
>> >>>>> http://www.prplfoundation.org
>> >>>>> eschultz at prplfoundation.org
>> >>>>> cell: 920-539-0404
>> >>>>> skype: ericschultzwi
>> >>>>> @EricPrpl
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> Lede-dev mailing list
>> >>>>> Lede-dev at lists.infradead.org
>> >>>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>> >>>>
>> >>>> _______________________________________________
>> >>>> Lede-dev mailing list
>> >>>> Lede-dev at lists.infradead.org
>> >>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>> >>>>
>> >> _______________________________________________
>> >> Lede-dev mailing list
>> >> Lede-dev at lists.infradead.org
>> >> http://lists.infradead.org/mailman/listinfo/lede-dev
>> >
>> >
>> > _______________________________________________
>> > Lede-dev mailing list
>> > Lede-dev at lists.infradead.org
>> > http://lists.infradead.org/mailman/listinfo/lede-dev
>
>


From dedeckeh at gmail.com  Thu Jun 16 00:26:58 2016
From: dedeckeh at gmail.com (Hans Dedecker)
Date: Thu, 16 Jun 2016 09:26:58 +0200
Subject: [LEDE-DEV] [PATCH] uloop: use a waker for notifying sigchld and
 loop cancel events
In-Reply-To: <57616C3D.5020905@gmail.com>
References: <1465438832-20133-1-git-send-email-yszhou4tech@gmail.com>
 <5761226A.5070404@conorogorman.net>
 <f0d60d41-75a7-0cf5-2f37-ff0915d2b44f@nbd.name>
 <CAJLcKsFNT3uXTkYihzQYQ0HoQ7oc=FKArLOTR6OSe0WCPMCjTw@mail.gmail.com>
 <02a2e110-8b78-d4a0-40ce-5e780073c83e@nbd.name> <57616C3D.5020905@gmail.com>
Message-ID: <CAJLcKsFhWri97e8Y213hxOSe54TqO88jnWqB2oqt-uFiXSqV7w@mail.gmail.com>

On Wed, Jun 15, 2016 at 4:54 PM, Mats Karrman <mats.dev.list at gmail.com> wrote:
>
> On 2016-06-15 15:16, Felix Fietkau wrote:
>>
>> On 2016-06-15 15:13, Hans Dedecker wrote:  >> On Wed, Jun 15, 2016 at
>> 11:58 AM, Felix Fietkau <nbd at nbd.name> >>
>
> wrote: >>> On 2016-06-15 11:39, Conor O'Gorman wrote: >>>> On 09/06/16
> 03:20, Yousong Zhou wrote: >>>>> Fix a race condition when do_sigchld,
> uloop_cancelled were >>>>> set just before epoll_wait(timeout=-1), resulting
> the loop >>>>> stuck in the syscall without noticing the events just >>>>>
> happened >>>>> >>>>> Signed-off-by: Yousong Zhou <yszhou4tech at gmail.com> ---
>>>>>> uloop-epoll.c  |  2 +- uloop-kqueue.c |  2 +- uloop.c >>>>> | 65 >>>>>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++---- 3 >>>>> files
> changed, 63 insertions(+), 6 deletions(-) >>>>> >>>> Why not change the
> timeout? >>> Changing the timeout would not fix the race, and it would lead
>>>> to unnecessary process wakeups and extra latency for signal >>>
> processing. >>> >>> - Felix >>> >>>
> _______________________________________________ Lede-dev mailing >>> list
> Lede-dev at lists.infradead.org >>>
> http://lists.infradead.org/mailman/listinfo/lede-dev >> Could it be that the
> wiker_pipe does not get properly initialized >> as waker_pipe never is
> assigned a fd value ? > I accidentally dropped that in a copy&paste screwup.
> Fix pushed to > git. > > Thanks, > > - Felix
> Ran 118 reboots with this fix without any problem so there is a good chance
> that
> the latest version of libubox (c2f2c47f3e9a2d709ec82a79f6fadd3124c18781)
> finally fixed the issue.
> :-) // Mats
>
Same result here after a night of testing; no hanging reboots observed anymore.

Thx,
Hans


From david at lang.hm  Thu Jun 16 00:34:02 2016
From: david at lang.hm (David Lang)
Date: Thu, 16 Jun 2016 00:34:02 -0700 (PDT)
Subject: [LEDE-DEV] looking for ar7 testers
In-Reply-To: <d35c82a2-58eb-d47f-5f71-8b3a132f50da@phrozen.org>
References: <3031035b-004b-2cea-63ec-580fcfd83bab@phrozen.org>
 <alpine.DEB.2.02.1606150125080.6774@nftneq.ynat.uz>
 <1466052177.7651.9.camel@chimera>
 <alpine.DEB.2.02.1606152153070.6774@nftneq.ynat.uz>
 <d35c82a2-58eb-d47f-5f71-8b3a132f50da@phrozen.org>
Message-ID: <alpine.DEB.2.02.1606160030490.1832@nftneq.ynat.uz>

On Thu, 16 Jun 2016, John Crispin wrote:

>> But for the general case, my question still stands. What hardware
>> (including brand-new devices, wishlists for future devices, etc) is
>> wanted, how can it be donated?
>
> talk to your local developer and support him as per need i guess.

Ok, who is 'local' to Los Angeles, California, the US, or the western 
hemisphere? ( with e-mail lists, this is not always obvious :-)

> personally i am right now looking for donations of ipq hardware that is
> not locked down.

If you can point at such hardware on amazon/e-bay or similar, I can pay for it, 
but I don't know enough to know what qualifies.

David Lang


From john at phrozen.org  Thu Jun 16 00:49:30 2016
From: john at phrozen.org (John Crispin)
Date: Thu, 16 Jun 2016 09:49:30 +0200
Subject: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
In-Reply-To: <CAJOqq5TXNNFteDq2fm79Gu7aojsMqJHP7PaQUaa_gYJfiod2TA@mail.gmail.com>
References: <5761BB29.8020303@prplfoundation.org>
 <CAJOqq5S314FgBswNo2KheO6VzvFr6jaMP=khXEWONSBnogJYLg@mail.gmail.com>
 <alpine.DEB.2.02.1606151502140.2494@nftneq.ynat.uz>
 <CAJOqq5SxXQH_BG3wP=1W7FVN9kptQvkdLc4V5r+ad4u4dRhw=Q@mail.gmail.com>
 <ab942f91-6e75-41b4-5573-ae533cceb18b@klam.ca>
 <922b01ca-bde3-7818-421f-2fb7bf69f7c0@phrozen.org>
 <CAJOqq5SdZf=xjQRJsaaYaSunueNtBnzd8pNMHeh+rooAEDy2JA@mail.gmail.com>
 <CAJOqq5TXNNFteDq2fm79Gu7aojsMqJHP7PaQUaa_gYJfiod2TA@mail.gmail.com>
Message-ID: <e9a077f6-eda5-7ace-794b-14e6c8ca463b@phrozen.org>



On 16/06/2016 09:18, L. D. Pinney wrote:
> OP wants to know if it's OK to cross post about old subjects.

no he did not, he never asked that


> Particularly TR-069 already available as packages for LEDE.
> 

ok you did not understand the purpose of the thread was.



> Notably freecwmp and easycwmp

yeah works great everyone is happy that is why they are looking for
alternatives


> NAK... use reasonable mailing list etiquette.
> 

ok, 1 nak form someone that missed the point and a pile of folks that
think its good and welcome that prpl is starting to work in public
rather than doing back room deals behind closed doors.

</thread>


> On Thu, Jun 16, 2016 at 2:17 AM, L. D. Pinney <ldpinney at gmail.com> wrote:
>> OP wants to know if it's OK to cross post about old subjects.
>>
>> Particularly TR-069 already available as packages for LEDE.
>>
>> Notably freecwmp and easycwmp
>>
>> NAK... use reasonable mailing list etiquette.
>>
>>
>>
>>
>> On Thu, Jun 16, 2016 at 1:11 AM, John Crispin <john at phrozen.org> wrote:
>>>
>>> what an utterly bizarre conversation to wake up to.
>>>
>>> the list is  non-subscribe/public post for a reason. i dont see why
>>> there is a need for X mailing lists. If you dont like it, then dont read
>>> it.
>>>
>>> this is a development related discussion and the rules clearly state
>>> that we would prefer companies to hold them in public. fair enough its
>>> not about actual source code yet, but it aims to get people involved in
>>> creating such code.
>>>
>>> if there is anything we should ask people not to do, then it is having
>>> these 40 email threads which divert from the original topic.
>>>
>>> this is a free community project. lets keep it free and not try to
>>> impose any rules beyond the "be nice to each other" and "be
>>> open/transparent" ones.
>>>
>>> anyone still recall what OP actually wanted ?
>>>
>>>         John
>>>
>>>
>>>
>>>
>>> On 16/06/2016 02:38, John Allen wrote:
>>>> Yes, I would like Eric to continue posting "here". However, I think we
>>>> need to define "here", I think we need a couple more lists dedicated to
>>>> Lede, a "I've got a question/Help list" and "the think tank list".
>>>> Conversation about the future direction of Lede including this
>>>> conversation about TR-069 should probably be held in the "think tank".
>>>> Whether these should be moderated or not is up to the you!
>>>>
>>>> JohnA
>>>>
>>>>
>>>> On 2016-06-15 6:10 PM, L. D. Pinney wrote:
>>>>> Just because a company works on something doesn't make it evil.
>>>>> Yes of course large corporations are well known for altruistic
>>>>> behavior.
>>>>>
>>>>> On Wed, Jun 15, 2016 at 5:03 PM, David Lang <david at lang.hm> wrote:
>>>>>> Is it really pushing a corporate agenda to coordinate efforts to make
>>>>>> LEDE/OpenWRT support remote management protocols?
>>>>>>
>>>>>> Just because a company works on something doesn't make it evil.
>>>>>>
>>>>>> David Lang
>>>>>>
>>>>>> On Wed, 15 Jun 2016, L. D. Pinney wrote:
>>>>>>
>>>>>>> Date: Wed, 15 Jun 2016 16:29:08 -0500
>>>>>>> From: L. D. Pinney <ldpinney at gmail.com>
>>>>>>> To: LEDE Development List <lede-dev at lists.infradead.org>
>>>>>>> Subject: Re: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
>>>>>>>
>>>>>>>
>>>>>>> Postings to the LEDE Development List should be devoted to technical
>>>>>>> development issues.
>>>>>>>
>>>>>>> Persons from prplfoundation et.al should respect conventional mail
>>>>>>> list
>>>>>>> etiquette such as found here :
>>>>>>>
>>>>>>> http://www.arm.linux.org.uk/mailinglists/etiquette.php
>>>>>>>
>>>>>>> Pay particular attention to 4, 7, and 10 on the above etiquitte list.
>>>>>>>
>>>>>>> I see prplfoundation as a hostile takeover of LEDE / OpenWrt by a
>>>>>>> corporate conspiracy.
>>>>>>>
>>>>>>> Free Software is meant to be free ...
>>>>>>>
>>>>>>> Free from the manipulation of governments and corporations.
>>>>>>>
>>>>>>> Pushing your corporate backed agenda on the Development List(s)
>>>>>>> torques me off every time.
>>>>>>>
>>>>>>> On Wed, Jun 15, 2016 at 3:31 PM, Eric Schultz
>>>>>>> <eschultz at prplfoundation.org> wrote:
>>>>>>>> As we continue the TR-069 support discussion, I wanted to ask folks
>>>>>>>> whether they want me to continue to cross post to these list in
>>>>>>>> addition
>>>>>>>> to the prplwrt list at openwrt at lists.prplfoundation.org. I have no
>>>>>>>> problem doing either way, but I don't want to fill people's inbox
>>>>>>>> will
>>>>>>>> stuff they feel is off topic. Just wanted to get a sense of what
>>>>>>>> people
>>>>>>>> would prefer.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Eric
>>>>>>>> --
>>>>>>>> Eric Schultz, Community Manager, prpl Foundation
>>>>>>>> http://www.prplfoundation.org
>>>>>>>> eschultz at prplfoundation.org
>>>>>>>> cell: 920-539-0404
>>>>>>>> skype: ericschultzwi
>>>>>>>> @EricPrpl
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Lede-dev mailing list
>>>>>>>> Lede-dev at lists.infradead.org
>>>>>>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Lede-dev mailing list
>>>>>>> Lede-dev at lists.infradead.org
>>>>>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>>>>>>
>>>>> _______________________________________________
>>>>> Lede-dev mailing list
>>>>> Lede-dev at lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> Lede-dev mailing list
>>>> Lede-dev at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>
>>


From ldpinney at gmail.com  Thu Jun 16 00:50:43 2016
From: ldpinney at gmail.com (L. D. Pinney)
Date: Thu, 16 Jun 2016 02:50:43 -0500
Subject: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
In-Reply-To: <e9a077f6-eda5-7ace-794b-14e6c8ca463b@phrozen.org>
References: <5761BB29.8020303@prplfoundation.org>
 <CAJOqq5S314FgBswNo2KheO6VzvFr6jaMP=khXEWONSBnogJYLg@mail.gmail.com>
 <alpine.DEB.2.02.1606151502140.2494@nftneq.ynat.uz>
 <CAJOqq5SxXQH_BG3wP=1W7FVN9kptQvkdLc4V5r+ad4u4dRhw=Q@mail.gmail.com>
 <ab942f91-6e75-41b4-5573-ae533cceb18b@klam.ca>
 <922b01ca-bde3-7818-421f-2fb7bf69f7c0@phrozen.org>
 <CAJOqq5SdZf=xjQRJsaaYaSunueNtBnzd8pNMHeh+rooAEDy2JA@mail.gmail.com>
 <CAJOqq5TXNNFteDq2fm79Gu7aojsMqJHP7PaQUaa_gYJfiod2TA@mail.gmail.com>
 <e9a077f6-eda5-7ace-794b-14e6c8ca463b@phrozen.org>
Message-ID: <CAJOqq5RYiXzc8Dx3HSZBcYYXaaZsbNvZeN1i8F3Ypdwt+Jb_1w@mail.gmail.com>

>From the OP

I wanted to ask folks whether they want me to continue to cross post to these

On Thu, Jun 16, 2016 at 2:49 AM, John Crispin <john at phrozen.org> wrote:
>
>
> On 16/06/2016 09:18, L. D. Pinney wrote:
>> OP wants to know if it's OK to cross post about old subjects.
>
> no he did not, he never asked that
>
>
>> Particularly TR-069 already available as packages for LEDE.
>>
>
> ok you did not understand the purpose of the thread was.
>
>
>
>> Notably freecwmp and easycwmp
>
> yeah works great everyone is happy that is why they are looking for
> alternatives
>
>
>> NAK... use reasonable mailing list etiquette.
>>
>
> ok, 1 nak form someone that missed the point and a pile of folks that
> think its good and welcome that prpl is starting to work in public
> rather than doing back room deals behind closed doors.
>
> </thread>
>
>
>> On Thu, Jun 16, 2016 at 2:17 AM, L. D. Pinney <ldpinney at gmail.com> wrote:
>>> OP wants to know if it's OK to cross post about old subjects.
>>>
>>> Particularly TR-069 already available as packages for LEDE.
>>>
>>> Notably freecwmp and easycwmp
>>>
>>> NAK... use reasonable mailing list etiquette.
>>>
>>>
>>>
>>>
>>> On Thu, Jun 16, 2016 at 1:11 AM, John Crispin <john at phrozen.org> wrote:
>>>>
>>>> what an utterly bizarre conversation to wake up to.
>>>>
>>>> the list is  non-subscribe/public post for a reason. i dont see why
>>>> there is a need for X mailing lists. If you dont like it, then dont read
>>>> it.
>>>>
>>>> this is a development related discussion and the rules clearly state
>>>> that we would prefer companies to hold them in public. fair enough its
>>>> not about actual source code yet, but it aims to get people involved in
>>>> creating such code.
>>>>
>>>> if there is anything we should ask people not to do, then it is having
>>>> these 40 email threads which divert from the original topic.
>>>>
>>>> this is a free community project. lets keep it free and not try to
>>>> impose any rules beyond the "be nice to each other" and "be
>>>> open/transparent" ones.
>>>>
>>>> anyone still recall what OP actually wanted ?
>>>>
>>>>         John
>>>>
>>>>
>>>>
>>>>
>>>> On 16/06/2016 02:38, John Allen wrote:
>>>>> Yes, I would like Eric to continue posting "here". However, I think we
>>>>> need to define "here", I think we need a couple more lists dedicated to
>>>>> Lede, a "I've got a question/Help list" and "the think tank list".
>>>>> Conversation about the future direction of Lede including this
>>>>> conversation about TR-069 should probably be held in the "think tank".
>>>>> Whether these should be moderated or not is up to the you!
>>>>>
>>>>> JohnA
>>>>>
>>>>>
>>>>> On 2016-06-15 6:10 PM, L. D. Pinney wrote:
>>>>>> Just because a company works on something doesn't make it evil.
>>>>>> Yes of course large corporations are well known for altruistic
>>>>>> behavior.
>>>>>>
>>>>>> On Wed, Jun 15, 2016 at 5:03 PM, David Lang <david at lang.hm> wrote:
>>>>>>> Is it really pushing a corporate agenda to coordinate efforts to make
>>>>>>> LEDE/OpenWRT support remote management protocols?
>>>>>>>
>>>>>>> Just because a company works on something doesn't make it evil.
>>>>>>>
>>>>>>> David Lang
>>>>>>>
>>>>>>> On Wed, 15 Jun 2016, L. D. Pinney wrote:
>>>>>>>
>>>>>>>> Date: Wed, 15 Jun 2016 16:29:08 -0500
>>>>>>>> From: L. D. Pinney <ldpinney at gmail.com>
>>>>>>>> To: LEDE Development List <lede-dev at lists.infradead.org>
>>>>>>>> Subject: Re: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
>>>>>>>>
>>>>>>>>
>>>>>>>> Postings to the LEDE Development List should be devoted to technical
>>>>>>>> development issues.
>>>>>>>>
>>>>>>>> Persons from prplfoundation et.al should respect conventional mail
>>>>>>>> list
>>>>>>>> etiquette such as found here :
>>>>>>>>
>>>>>>>> http://www.arm.linux.org.uk/mailinglists/etiquette.php
>>>>>>>>
>>>>>>>> Pay particular attention to 4, 7, and 10 on the above etiquitte list.
>>>>>>>>
>>>>>>>> I see prplfoundation as a hostile takeover of LEDE / OpenWrt by a
>>>>>>>> corporate conspiracy.
>>>>>>>>
>>>>>>>> Free Software is meant to be free ...
>>>>>>>>
>>>>>>>> Free from the manipulation of governments and corporations.
>>>>>>>>
>>>>>>>> Pushing your corporate backed agenda on the Development List(s)
>>>>>>>> torques me off every time.
>>>>>>>>
>>>>>>>> On Wed, Jun 15, 2016 at 3:31 PM, Eric Schultz
>>>>>>>> <eschultz at prplfoundation.org> wrote:
>>>>>>>>> As we continue the TR-069 support discussion, I wanted to ask folks
>>>>>>>>> whether they want me to continue to cross post to these list in
>>>>>>>>> addition
>>>>>>>>> to the prplwrt list at openwrt at lists.prplfoundation.org. I have no
>>>>>>>>> problem doing either way, but I don't want to fill people's inbox
>>>>>>>>> will
>>>>>>>>> stuff they feel is off topic. Just wanted to get a sense of what
>>>>>>>>> people
>>>>>>>>> would prefer.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Eric
>>>>>>>>> --
>>>>>>>>> Eric Schultz, Community Manager, prpl Foundation
>>>>>>>>> http://www.prplfoundation.org
>>>>>>>>> eschultz at prplfoundation.org
>>>>>>>>> cell: 920-539-0404
>>>>>>>>> skype: ericschultzwi
>>>>>>>>> @EricPrpl
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Lede-dev mailing list
>>>>>>>>> Lede-dev at lists.infradead.org
>>>>>>>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Lede-dev mailing list
>>>>>>>> Lede-dev at lists.infradead.org
>>>>>>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>>>>>>>
>>>>>> _______________________________________________
>>>>>> Lede-dev mailing list
>>>>>> Lede-dev at lists.infradead.org
>>>>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Lede-dev mailing list
>>>>> Lede-dev at lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>>
>>>


From david at lang.hm  Thu Jun 16 01:03:52 2016
From: david at lang.hm (David Lang)
Date: Thu, 16 Jun 2016 01:03:52 -0700 (PDT)
Subject: [LEDE-DEV] lede integration issues remaining from the detrius
 of cerowrt
In-Reply-To: <1465939839.2633.29.camel@homehost>
References: <CAA93jw7=bHNXJqmjWmg3CHHH-biua17wK4AHfn_wB0wPWs=EqQ@mail.gmail.com>
 <CAJOqq5TB4qki1iWHZd71kzXYoA=A3+4BeycoNPKqRXFWZ6bMZQ@mail.gmail.com>
 <f6898485-e1d4-ec35-4563-4591512d2d84@mein.io>
 <1465868455.2580.35.camel@homehost>
 <alpine.DEB.2.02.1606141048400.2494@nftneq.ynat.uz>
 <1465939839.2633.29.camel@homehost>
Message-ID: <alpine.DEB.2.02.1606160046050.1832@nftneq.ynat.uz>

On Tue, 14 Jun 2016, Daniel Curran-Dickinson wrote:

> On Tue, 2016-06-14 at 11:05 -0700, David Lang wrote:
>> On Mon, 13 Jun 2016, Daniel Curran-Dickinson wrote:
>>
>>> On Mon, 2016-06-13 at 11:17 +0200, Jo-Philipp Wich wrote:
>>>> Hi,
>>>>
> Again I think you read too much into what I said (admittedly I do the
> same myself, at times, as you well know)

fair enough, now we've both clarified and find that we are pretty much in 
agreement.

> , but I wasn't saying there is
> no use case for it, only that it's not the 'primary', or 'default' use
> case.
>
> By all means, I'm game for maximum flexibility that doesn't hurt the
> primary use case.
>
> In the case the 2TB+ drives, I was concerned that such support would come
> *at the expense of* the primary use; fortunately it doesn't, but if it did,
> I would argue against kernel options (for example) for making the support
> the *default* (e.g. in buildbot builds), except maybe for something like x86
> boards/use cases (in the case of x86 I'm not sure that limiting hardware
> support to save space is in most cases necessary; other cases like default
> userspace I'd argue should be kept consistent and changes from default
> management with things like ImageBuilder.
>
> In general I'm a fan of ImageBuilder because, provided the kernel support is there,
> you can use the SDK and build whatever packages you want to add on, and use
> ImageBuilder to generate images that use those packages (along with the standard
> ones you still want), without getting in the way of the primary use case.

I generally compile my own images because I am tweaking even kernel options 
(disabling connection tracking on any build that's not a firewall for example), 
but getting better images and image generation would be very good.

With Imagebuilder and things pre-compiled, what does it take to create an image? 
I'm wondering if this is something that can be converted to a web UI where we 
could have someone select stuff (or upload a config file) and have the system 
spit out a custom tailored image a few seconds later.

Something like this could do wonders to move people away from the 'base image 
must contain what I need' mentality.

>>> To a certain extent though, I question the need for something as restricted as OpenWrt
>>> for the new bigger devices anyway; there are elements like netifd that would be good to
>>> see continue, but I'm not sure that most of OpenWrt really makes as much sense when you're
>>> not needing to squeeze maximum use out of very erase block, and that therefore, while it
>>> may be a smaller market/mindshare, that focussing on the the true embedded type scenario,
>>> seems to be more of what LEDE's niche is.
>>
>> LEDE/OpenWRT is a good fit for any device that operates on raw flash instead of
>> a hard drive or ssd with wear leveling. Once you have storage that you don't
>> worry about wearing out and is large enough to hold a normal Linux Distro, it
>> makes sense to move to such a distro and update packages individually.
>
> Hmmm...the wear levelling thing is confusing.  I was told by someone who I thought knew
> what they were talking about, that flash chips included some form of hardware-based
> wear levelling built in already.  Apparently that is was inaccurate (hardware-level
> support is something I only having minor knowledge of; it's not the part the interests me,
> nor where I have worked on it for any length of time; I'm more interested in what you can
> do with existing hardware support combined with software rather developing the core support
> itself).

raw flash chips like we have in a router have nothing.

flash chips packaged in SD cards, USB drives, etc commonly have very primitive 
wear leveling (in many cases only targeted at the places that the FAT filesystem 
is going to use)

flash chips packaged into SSD drives or anything more sophisticated tend to have 
very extensive wear leveling setups, and will move existing, unmodified data if 
needed to balance things.

I haven't looked recently, but a couple years ago the idea of having an 
in-kernel flash wear leveling capability was getting a lot of discussion on the 
kernel mailing list. I din't remember seeing what finally happened with that.

For the very tiny devices, it doesn't make sense to try and make use of 
something like that (it takes more space ond isn't going to apply to a static, 
pre-build compressed filesystem)

But for the overlay filesystem where new stuff may get added on newer devices 
that have the much larger NAND flash, it may be something to look into, even 
though it complicates the base config for such systems.

David Lang


From champetier.etienne at gmail.com  Thu Jun 16 01:09:15 2016
From: champetier.etienne at gmail.com (Etienne CHAMPETIER)
Date: Thu, 16 Jun 2016 08:09:15 +0000
Subject: [LEDE-DEV] [PATCH] make /var/{run, lock,
	state} not world writable (0755)
Message-ID: <1466064555-112759-1-git-send-email-champetier.etienne@gmail.com>

since commit be950c5e56b86509e1e237931d0ac8203372be82 (09/03/2013)
/var/{run,lock,state} are world writable (0777) which is a security issue
before that they were created by /etc/init.d/boot with normal
permissions (0755), so revert to that state

Signed-off-by: Etienne CHAMPETIER <champetier.etienne at gmail.com>
---
 initd/early.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/initd/early.c b/initd/early.c
index accfc1d..bf519f6 100644
--- a/initd/early.c
+++ b/initd/early.c
@@ -73,9 +73,9 @@ early_mounts(void)
 		mount("tmpfs", "/tmp/shm", "tmpfs", MS_NOSUID | MS_NODEV | MS_NOATIME,
 				"mode=01777");
 	}
-	mkdir("/tmp/run", 0777);
-	mkdir("/tmp/lock", 0777);
-	mkdir("/tmp/state", 0777);
+	mkdir("/tmp/run", 0755);
+	mkdir("/tmp/lock", 0755);
+	mkdir("/tmp/state", 0755);
 	umask(oldumask);
 }
 
-- 
1.9.1



From jo at mein.io  Thu Jun 16 01:58:10 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Thu, 16 Jun 2016 10:58:10 +0200
Subject: [LEDE-DEV] lede integration issues remaining from the detrius
 of cerowrt
In-Reply-To: <alpine.DEB.2.02.1606160046050.1832@nftneq.ynat.uz>
References: <CAA93jw7=bHNXJqmjWmg3CHHH-biua17wK4AHfn_wB0wPWs=EqQ@mail.gmail.com>
 <CAJOqq5TB4qki1iWHZd71kzXYoA=A3+4BeycoNPKqRXFWZ6bMZQ@mail.gmail.com>
 <f6898485-e1d4-ec35-4563-4591512d2d84@mein.io>
 <1465868455.2580.35.camel@homehost>
 <alpine.DEB.2.02.1606141048400.2494@nftneq.ynat.uz>
 <1465939839.2633.29.camel@homehost>
 <alpine.DEB.2.02.1606160046050.1832@nftneq.ynat.uz>
Message-ID: <b78f06ea-f081-3b19-d552-a325eca28753@mein.io>

Hi,

> With Imagebuilder and things pre-compiled, what does it take to create
> an image? I'm wondering if this is something that can be converted to a
> web UI where we could have someone select stuff (or upload a config
> file) and have the system spit out a custom tailored image a few seconds
> later.
> 
> Something like this could do wonders to move people away from the 'base
> image must contain what I need' mentality.

Such technology exists already and is used by some Freifunk communities
in Germany, see https://meshkit.freifunk.net/

It is not hard to wrap the IB into a gui, scheduling builds and
distributing resources (storage etc.) is the only difficult task about it.


~ Jo


From champetier.etienne at gmail.com  Thu Jun 16 02:38:11 2016
From: champetier.etienne at gmail.com (Etienne CHAMPETIER)
Date: Thu, 16 Jun 2016 09:38:11 +0000
Subject: [LEDE-DEV] [PATCH v4] base-files: seed /dev/urandom
Message-ID: <1466069891-28577-1-git-send-email-champetier.etienne@gmail.com>

This commit:
1) seed /dev/urandom with a saved seed as early as possible
   (see /lib/preinit/81_urandom_seed)
2) save a new seed if system. at system[0].write_urandom_seed_on_boot == 1
   or if none exists. We use getrandom() so we are sure /dev/urandom
   pool is initialized (see /etc/init.d/urandom_seed)

seed size is 512 bytes (ie /proc/sys/kernel/random/poolsize / 8)
it's the same size as in ubuntu 14.04 and all systemd systems

seed file is /etc/urandom.seed (need a writable path)

seeding /dev/urandom doesn't change entropy estimation, so we still have
"random: ubus urandom read with 4 bits of entropy available"
messages in the logs, but we can now ignore them if
after "urandom-seed: Seeding with ..." message

for now saving a new seed is disabled by default as Felix and John
are concerned we might write too much and destroy the flash

v2: log preinit messages to /dev/kmsg
v3: use non generic function name for logging, as /lib/preinit/ files
    are all sourced together in /etc/preinit
v4: after a lot of discussion on the ML, use a config param

Signed-off-by: Etienne CHAMPETIER <champetier.etienne at gmail.com>
---
 package/base-files/files/bin/config_generate       |  1 +
 package/base-files/files/etc/init.d/urandom_seed   | 28 ++++++++++++++++++++++
 .../base-files/files/lib/preinit/81_urandom_seed   | 19 +++++++++++++++
 3 files changed, 48 insertions(+)
 create mode 100755 package/base-files/files/etc/init.d/urandom_seed
 create mode 100644 package/base-files/files/lib/preinit/81_urandom_seed

diff --git a/package/base-files/files/bin/config_generate b/package/base-files/files/bin/config_generate
index 8002bc4..9bccead 100755
--- a/package/base-files/files/bin/config_generate
+++ b/package/base-files/files/bin/config_generate
@@ -230,6 +230,7 @@ generate_static_system() {
 		set system. at system[-1].timezone='UTC'
 		set system. at system[-1].ttylogin='0'
 		set system. at system[-1].log_size='64'
+		set system. at system[-1].write_urandom_seed_on_boot='0'
 
 		delete system.ntp
 		set system.ntp='timeserver'
diff --git a/package/base-files/files/etc/init.d/urandom_seed b/package/base-files/files/etc/init.d/urandom_seed
new file mode 100755
index 0000000..f950685
--- /dev/null
+++ b/package/base-files/files/etc/init.d/urandom_seed
@@ -0,0 +1,28 @@
+#!/bin/sh /etc/rc.common
+
+START=99
+
+EXTRA_COMMANDS="save"
+
+SEED=/etc/urandom.seed
+
+error_exit() {
+    logger -t urandom_seed "$1"
+    exit 1
+}
+
+save() {
+    touch $SEED.tmp || error_exit "touch failed"
+    chown root:root $SEED.tmp || error_exit "chown failed"
+    chmod 600 $SEED.tmp || error_exit "chmod failed"
+    getrandom 512 > $SEED.tmp || error_exit "getrandom failed"
+    mv $SEED.tmp $SEED || error_exit "mv failed"
+}
+
+boot() {
+    [ -f $SEED ] || {
+        save
+        exit 0
+    }
+    [ "$(uci get system. at system[0].write_urandom_seed_on_boot)" == "1" ] && save
+}
diff --git a/package/base-files/files/lib/preinit/81_urandom_seed b/package/base-files/files/lib/preinit/81_urandom_seed
new file mode 100644
index 0000000..a1457aa
--- /dev/null
+++ b/package/base-files/files/lib/preinit/81_urandom_seed
@@ -0,0 +1,19 @@
+#!/bin/sh
+
+log_urandom_seed() {
+    echo "urandom-seed: $1" > /dev/kmsg
+}
+
+do_urandom_seed() {
+    S=/etc/urandom.seed
+    U=/dev/urandom
+
+    [ -c $U ] || { log_urandom_seed "Something is wrong with $U"; return; }
+    [ -f $S ] || { log_urandom_seed "Seed file not found ($S)"; return; }
+    [ -O $S -a -G $S -a ! -x $S ] || { log_urandom_seed "Wrong owner / permissions for $S"; return; }
+
+    log_urandom_seed "Seeding with $S"
+    cat $S > $U
+}
+
+boot_hook_add preinit_main do_urandom_seed
-- 
1.9.1



From john at phrozen.org  Thu Jun 16 04:45:40 2016
From: john at phrozen.org (John Crispin)
Date: Thu, 16 Jun 2016 13:45:40 +0200
Subject: [LEDE-DEV] [PATCH] [ramips] Added NixCore X1 target V5
In-Reply-To: <5761F4AC.1010805@nixcores.com>
References: <5761F4AC.1010805@nixcores.com>
Message-ID: <651aaa54-c389-7edb-8603-56b5d9b226d5@phrozen.org>

Hi,

patch does not apply. please go here

--> http://patchwork.ozlabs.org/patch/636150/

click on "download mbox" and you will see that it is line wrapped at 80
characters.

	John


On 16/06/2016 02:37, Drew from NixCore wrote:
> Added NixCore X1 ramips target http://nixcores.com.  This builds 8M and
> 16M images.  V5 updates the patch to work with the latest source.git
> 
> Signed-off-by: Drew Gaylo <drew at nixcores.com>
> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
> b/target/linux/ramips/base-files/etc/board.d/02_network
> index be1912a..ebcf619 100755
> --- a/target/linux/ramips/base-files/etc/board.d/02_network
> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
> @@ -77,6 +77,7 @@ ramips_setup_interfaces()
>      mt7628|\
>      mzk-750dhp|\
>      mzk-w300nh2|\
> +    nixcore|\
>      oy-0001|\
>      pbr-m1|\
>      psg1208|\
> diff --git a/target/linux/ramips/base-files/lib/ramips.sh
> b/target/linux/ramips/base-files/lib/ramips.sh
> index bd4f33d..340a628 100755
> --- a/target/linux/ramips/base-files/lib/ramips.sh
> +++ b/target/linux/ramips/base-files/lib/ramips.sh
> @@ -322,6 +322,9 @@ ramips_board_detect() {
>      *"NCS601W")
>          name="ncs601w"
>          ;;
> +    *"NixcoreX1")
> +        name="nixcore-x1"
> +        ;;
>      *"NW718")
>          name="nw718"
>          ;;
> diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh
> b/target/linux/ramips/base-files/lib/upgrade/platform.sh
> index 0b3d8c7..8749c99 100755
> --- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
> @@ -95,6 +95,7 @@ platform_check_image() {
>      mzk-w300nh2|\
>      mzk-wdpr|\
>      nbg-419n|\
> +    nixcore|\
>      nw718|\
>      oy-0001|\
>      pbr-m1|\
> diff --git a/target/linux/ramips/dts/NIXCOREX1-16M.dts
> b/target/linux/ramips/dts/NIXCOREX1-16M.dts
> new file mode 100644
> index 0000000..2ffcbb2
> --- /dev/null
> +++ b/target/linux/ramips/dts/NIXCOREX1-16M.dts
> @@ -0,0 +1,95 @@
> +/dts-v1/;
> +
> +/include/ "rt5350.dtsi"
> +
> +/ {
> +    compatible = "NixcoreX1", "ralink,rt5350-soc";
> +    model = "NixcoreX1";
> +
> +    chosen{
> +        bootargs = "console=ttyS1,57600";
> +    };
> +};
> +
> +&gpio0{
> +    status = "okay";
> +};
> +
> +&gpio1{
> +    status = "okay";
> +};
> +
> +&i2c{
> +    status = "okay";
> +};
> +&uart{
> +    status = "okay";
> +    /* Mix of uart and gpio */
> +    reset-names = "gpio uartf";
> +};
> +&spi0{
> +    status = "okay";
> +
> +    m25p80 at 0 {
> +        #address-cells = <1>;
> +        #size-cells = <1>;
> +        compatible = "s25fl064k";
> +        reg = <0>;
> +        linux,modalias = "m25p80", "s25fl064k";
> +        spi-max-frequency = <10000000>;
> +
> +        partition at 0 {
> +            label = "uboot";
> +            reg = <0x0 0x30000>;
> +            read-only;
> +        };
> +
> +        partition at 30000 {
> +            label = "uboot-env";
> +            reg = <0x30000 0x10000>;
> +            read-only;
> +        };
> +
> +        factory: partition at 40000 {
> +            label = "factory";
> +            reg = <0x40000 0x10000>;
> +            read-only;
> +        };
> +
> +        partition at 50000 {
> +            label = "firmware";
> +            reg = <0x50000 0xfb0000>;
> +        };
> +    };
> +};
> +
> +&pinctrl {
> +    state_default: pinctrl0 {
> +        gpio {
> +            /* Associate the tjag, uartf and led groups with gpio */
> +            ralink,group = "jtag", "led", "spi_cs1";
> +            /* How do we set individual pins? */
> +            ralink,function = "gpio";
> +        };
> +    };
> +};
> +
> +&ethernet {
> +    mtd-mac-address = <&factory 0x4>;
> +};
> +
> +&esw {
> +    ralink,portmap = <0x17>;
> +};
> +
> +&wmac {
> +    ralink,mtd-eeprom = <&factory 0>;
> +};
> +
> +&ehci {
> +    status = "okay";
> +};
> +
> +&ohci {
> +    status = "okay";
> +};
> diff --git a/target/linux/ramips/dts/NIXCOREX1-8M.dts
> b/target/linux/ramips/dts/NIXCOREX1-8M.dts
> new file mode 100644
> index 0000000..ca557fd
> --- /dev/null
> +++ b/target/linux/ramips/dts/NIXCOREX1-8M.dts
> @@ -0,0 +1,95 @@
> +/dts-v1/;
> +
> +/include/ "rt5350.dtsi"
> +
> +/ {
> +    compatible = "NixcoreX1", "ralink,rt5350-soc";
> +    model = "NixcoreX1";
> +
> +    chosen{
> +        bootargs = "console=ttyS1,57600";
> +    };
> +};
> +
> +&gpio0{
> +    status = "okay";
> +};
> +
> +&gpio1{
> +    status = "okay";
> +};
> +
> +&i2c{
> +    status = "okay";
> +};
> +&uart{
> +    status = "okay";
> +    /* Mix of uart and gpio */
> +    reset-names = "gpio uartf";
> +};
> +&spi0{
> +    status = "okay";
> +
> +    m25p80 at 0 {
> +        #address-cells = <1>;
> +        #size-cells = <1>;
> +        compatible = "s25fl064k";
> +        reg = <0>;
> +        linux,modalias = "m25p80", "s25fl064k";
> +        spi-max-frequency = <10000000>;
> +
> +        partition at 0 {
> +            label = "uboot";
> +            reg = <0x0 0x30000>;
> +            read-only;
> +        };
> +
> +        partition at 30000 {
> +            label = "uboot-env";
> +            reg = <0x30000 0x10000>;
> +            read-only;
> +        };
> +
> +        factory: partition at 40000 {
> +            label = "factory";
> +            reg = <0x40000 0x10000>;
> +            read-only;
> +        };
> +
> +        partition at 50000 {
> +            label = "firmware";
> +            reg = <0x50000 0x7b0000>;
> +        };
> +    };
> +};
> +
> +&pinctrl {
> +    state_default: pinctrl0 {
> +        gpio {
> +            /* Associate the tjag, uartf and led groups with gpio */
> +            ralink,group = "jtag", "led", "spi_cs1";
> +            /* How do we set individual pins? */
> +            ralink,function = "gpio";
> +        };
> +    };
> +};
> +
> +&ethernet {
> +    mtd-mac-address = <&factory 0x4>;
> +};
> +
> +&esw {
> +    ralink,portmap = <0x17>;
> +};
> +
> +&wmac {
> +    ralink,mtd-eeprom = <&factory 0>;
> +};
> +
> +&ehci {
> +    status = "okay";
> +};
> +
> +&ohci {
> +    status = "okay";
> +};
> diff --git a/target/linux/ramips/image/rt305x.mk
> b/target/linux/ramips/image/rt305x.mk
> index da7fc46..db12a8e 100644
> --- a/target/linux/ramips/image/rt305x.mk
> +++ b/target/linux/ramips/image/rt305x.mk
> @@ -100,6 +100,21 @@ define BuildFirmware/HLKRM04/initramfs
>      mkhilinkfw -e -i$(call imgname,$(1),$(2))-uImage.bin -o $(call
> imgname,$(1),$(2))-factory.bin;
>  endef
> 
> +# This is called to build the nixcore image.  Build both 8MB and 16MB
> +nixcore_8mb_mtd_size=8060928
> +nixcore_16mb_mtd_size=16449536
> +define BuildFirmware/NIXCOREX1/squashfs
> +# Args are XXX, nixcore-mM and NIXCOREX1-xM
> +    $(call
> BuildFirmware/CustomFlash/$(1),$(1),$(2)-8M,$(3)-8M,$(nixcore_8mb_mtd_size))
> 
> +    $(call
> BuildFirmware/CustomFlash/$(1),$(1),$(2)-16M,$(3)-16M,$(nixcore_16mb_mtd_size))
> 
> +    # Can do somethings here after the build?
> +endef
> +define BuildFirmware/NIXCOREX1/initramfs
> +# Args are XXXX, nixcore-mM and NIXCOREX1-xM
> +    $(call BuildFirmware/OF/initramfs,$(1),$(2)-8M,$(3)-8M)
> +    $(call BuildFirmware/OF/initramfs,$(1),$(2)-16M,$(3)-16M)
> +endef
> +
>  vocore_8mb_mtd_size=8060928
>  vocore_16mb_mtd_size=16449536
>  define BuildFirmware/VOCORE/squashfs
> @@ -257,6 +272,7 @@ Image/Build/Profile/NBG-419N=$(call
> BuildFirmware/Default4M/$(1),$(1),nbg-419n,N
>  Image/Build/Profile/MZKW300NH2=$(call
> BuildFirmware/Edimax/$(1),$(1),mzk-w300nh2,MZK-W300NH2,$(mzkw300nh2_mtd_size),CSYS,RN52,0x50000,0xc0000)
> 
>  Image/Build/Profile/MZKWDPR=$(call
> BuildFirmware/Default8M/$(1),$(1),mzk-wdpr,MZK-WDPR)
>  Image/Build/Profile/NCS601W=$(call
> BuildFirmware/Default8M/$(1),$(1),ncs601W,NCS601W)
> +Image/Build/Profile/NIXCOREX1=$(call
> BuildFirmware/NIXCOREX1/$(1),$(1),nixcorex1,NIXCOREX1)
>  nw718_mtd_size=3801088
>  Image/Build/Profile/NW718=$(call
> BuildFirmware/CustomFlashFactory/$(1),$(1),nw718m,NW718,$(nw718_mtd_size),ARA1B4NCRNW718;1,factory)
> 
>  Image/Build/Profile/M2M=$(call
> BuildFirmware/Default8M/$(1),$(1),m2m,M2M,Linux Kernel Image)
> @@ -353,6 +369,7 @@ define Image/Build/Profile/Default
>      $(call Image/Build/Profile/MZKWDPR,$(1))
>      $(call Image/Build/Profile/NBG-419N,$(1))
>      $(call Image/Build/Profile/NCS601W,$(1))
> +    $(call Image/Build/Profile/NIXCOREX1,$(1))
>      $(call Image/Build/Profile/NW718,$(1))
>      $(call Image/Build/Profile/MINIEMBWIFI,$(1))
>      $(call Image/Build/Profile/MINIEMBPLUG,$(1))
> diff --git a/target/linux/ramips/rt305x/profiles/nixcore.mk
> b/target/linux/ramips/rt305x/profiles/nixcore.mk
> new file mode 100644
> index 0000000..22dee9b
> --- /dev/null
> +++ b/target/linux/ramips/rt305x/profiles/nixcore.mk
> @@ -0,0 +1,20 @@
> +#
> +# Copyright (C) 2014 OpenWrt.org
> +#
> +# This is free software, licensed under the GNU General Public License v2.
> +# See /LICENSE for more information.
> +#
> +
> +define Profile/NIXCOREX1
> +    NAME:=NixcoreX1
> +    PACKAGES:=\
> +        kmod-usb-core kmod-usb-ohci kmod-usb2 \
> +        kmod-i2c-core kmod-i2c-ralink \
> +        kmod-spi-dev
> +endef
> +
> +define Profile/NIXCOREX1/Description
> +    Package set for Nixcore X1 board
> +endef
> +
> +$(eval $(call Profile,NIXCOREX1))
> 
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


From zajec5 at gmail.com  Thu Jun 16 05:10:05 2016
From: zajec5 at gmail.com (=?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?=)
Date: Thu, 16 Jun 2016 14:10:05 +0200
Subject: [LEDE-DEV] [PATCH uclient] http: allow sending message body for
	DELETE request
Message-ID: <1466079005-17531-1-git-send-email-zajec5@gmail.com>

Sending entity within DELETE is not forbidden by RFC 7231, see section
4.3.5. DELETE:
> A payload within a DELETE request message has no defined semantics;
> sending a payload body on a DELETE request might cause some existing
> implementations to reject the request.

Signed-off-by: Rafa? Mi?ecki <zajec5 at gmail.com>
---
 uclient-http.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/uclient-http.c b/uclient-http.c
index c6336a6..f0451cc 100644
--- a/uclient-http.c
+++ b/uclient-http.c
@@ -286,6 +286,18 @@ static void uclient_http_process_headers(struct uclient_http *uh)
 	uh->auth_type = uclient_http_update_auth_type(uh);
 }
 
+static bool uclient_request_supports_body(enum request_type req_type)
+{
+	switch (req_type) {
+	case REQ_POST:
+	case REQ_PUT:
+	case REQ_DELETE:
+		return true;
+	default:
+		return false;
+	}
+}
+
 static void
 uclient_http_add_auth_basic(struct uclient_http *uh)
 {
@@ -564,7 +576,7 @@ uclient_http_send_headers(struct uclient_http *uh)
 	blobmsg_for_each_attr(cur, uh->headers.head, rem)
 		ustream_printf(uh->us, "%s: %s\r\n", blobmsg_name(cur), (char *) blobmsg_data(cur));
 
-	if (uh->req_type == REQ_POST || uh->req_type == REQ_PUT)
+	if (uclient_request_supports_body(uh->req_type))
 		ustream_printf(uh->us, "Transfer-Encoding: chunked\r\n");
 
 	uclient_http_add_auth_header(uh);
@@ -992,7 +1004,7 @@ uclient_http_request_done(struct uclient *cl)
 		return -1;
 
 	uclient_http_send_headers(uh);
-	if (uh->req_type == REQ_POST || uh->req_type == REQ_PUT)
+	if (uclient_request_supports_body(uh->req_type))
 		ustream_printf(uh->us, "0\r\n\r\n");
 	uh->state = HTTP_STATE_REQUEST_DONE;
 
-- 
1.8.4.5



From ianchi74 at outlook.com  Thu Jun 16 07:07:50 2016
From: ianchi74 at outlook.com (Adrian Panella)
Date: Thu, 16 Jun 2016 09:07:50 -0500
Subject: [LEDE-DEV] looking for ar7 testers
In-Reply-To: <d35c82a2-58eb-d47f-5f71-8b3a132f50da@phrozen.org>
References: <3031035b-004b-2cea-63ec-580fcfd83bab@phrozen.org>
 <alpine.DEB.2.02.1606150125080.6774@nftneq.ynat.uz>
 <1466052177.7651.9.camel@chimera>
 <alpine.DEB.2.02.1606152153070.6774@nftneq.ynat.uz>
 <d35c82a2-58eb-d47f-5f71-8b3a132f50da@phrozen.org>
Message-ID: <BLU405-EAS29300781AB25551E89613EADB560@phx.gbl>


-----Original Message-----
From: Lede-dev [mailto:lede-dev-bounces at lists.infradead.org] On Behalf Of
John Crispin
Sent: jueves, 16 de junio de 2016 01:14 a.m.
To: David Lang; Daniel Gimpelevich
Cc: lede-dev at lists.infradead.org
Subject: Re: [LEDE-DEV] looking for ar7 testers


> talk to your local developer and support him as per need i guess.

I don't think any of the core devs are local to my city, and anyway I
believe nowadays we are all "local" to the world

> personally i am right now looking for donations of ipq hardware that is
not locked down.

I'd like to help with that, but as I said, I'm a bit far away. I think there
should be an "official" Lede paypal account, or something, so that it is
easy for anyone willing to make a donation. Then LEDE should assign the
money, (or in the donation one could state which target you wish to fund).
Sending hw directly to a dev means that they have to disclose their address,
and it is also more complicated to the donor, which in the end may
discourage donations.
 


From aczlan+ledev at gmail.com  Thu Jun 16 07:34:39 2016
From: aczlan+ledev at gmail.com (Aaron Z)
Date: Thu, 16 Jun 2016 10:34:39 -0400
Subject: [LEDE-DEV] lede integration issues remaining from the detrius
	of cerowrt
In-Reply-To: <alpine.DEB.2.02.1606160046050.1832@nftneq.ynat.uz>
References: <CAA93jw7=bHNXJqmjWmg3CHHH-biua17wK4AHfn_wB0wPWs=EqQ@mail.gmail.com>
 <CAJOqq5TB4qki1iWHZd71kzXYoA=A3+4BeycoNPKqRXFWZ6bMZQ@mail.gmail.com>
 <f6898485-e1d4-ec35-4563-4591512d2d84@mein.io>
 <1465868455.2580.35.camel@homehost>
 <alpine.DEB.2.02.1606141048400.2494@nftneq.ynat.uz>
 <1465939839.2633.29.camel@homehost>
 <alpine.DEB.2.02.1606160046050.1832@nftneq.ynat.uz>
Message-ID: <CAKNoO9oLbR6ipAG2X_GAvn2CeVdfapP4qhH-Mut=CjrC3iBUkg@mail.gmail.com>

On Thu, Jun 16, 2016 at 4:03 AM, David Lang <david at lang.hm> wrote:
> With Imagebuilder and things pre-compiled, what does it take to create an
> image? I'm wondering if this is something that can be converted to a web UI
> where we could have someone select stuff (or upload a config file) and have
> the system spit out a custom tailored image a few seconds later.
>
> Something like this could do wonders to move people away from the 'base
> image must contain what I need' mentality.
Personally, I would like that (and wouldn't have a problem with
waiting a half hour or an hour for a build to be done).
For example, I don't need PPOE support on any of the hardware I use,
many of the devices don't have a USB port, so I don't need USB
support, its internal on an IPV4 network, so I don't need IPV6
support, it would be nice to have Nano installed by default (hard to
use vi over ssh from a phone that doesn't have an escape key :D).
But that's just the perspective of a end user/sysadmin who has been
using OpenWrt (and now LEDE) for 7-10 years.

Aaron Z


From champetier.etienne at gmail.com  Thu Jun 16 07:45:31 2016
From: champetier.etienne at gmail.com (Etienne Champetier)
Date: Thu, 16 Jun 2016 16:45:31 +0200
Subject: [LEDE-DEV] ujail bug/feature with file replacement with mv
Message-ID: <CAOdf3gpt6M0wvzr7OLSm_JCuAU9DN2L4GhpZdWfZQ+w=ShVduw@mail.gmail.com>

Hi,

Just a heads up,
ujail uses "bind mount" to include file and directories into the jail,
so if you include a file named aaa (procd_add_jail_mount(_rw) aaa),
and then replace it outside of the jail using "mv bbb aaa",
in the jail you will still have file aaa.

Workaround is to use a directory instead of a file.
This might be usefull to remember if you try to change a config file
atomically with mv and signal the process.

Regards
Etienne


From drew at nixcores.com  Thu Jun 16 09:53:48 2016
From: drew at nixcores.com (Drew from NixCore)
Date: Thu, 16 Jun 2016 12:53:48 -0400
Subject: [LEDE-DEV] [PATCH] [ramips] Added NixCore X1 target V5
In-Reply-To: <651aaa54-c389-7edb-8603-56b5d9b226d5@phrozen.org>
References: <5761F4AC.1010805@nixcores.com>
 <651aaa54-c389-7edb-8603-56b5d9b226d5@phrozen.org>
Message-ID: <5762D99C.50602@nixcores.com>

Ok, why is this wrapping at 80 characters, I am using an email client 
set as text only without wrapping.

Here is a test
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890

Is this a server setting?

On 06/16/2016 07:45 AM, John Crispin wrote:
> Hi,
>
> patch does not apply. please go here
>
> --> http://patchwork.ozlabs.org/patch/636150/
>
> click on "download mbox" and you will see that it is line wrapped at 80
> characters.
>
> 	John
>
>
> On 16/06/2016 02:37, Drew from NixCore wrote:
>> Added NixCore X1 ramips target http://nixcores.com.  This builds 8M and
>> 16M images.  V5 updates the patch to work with the latest source.git
>>
>> Signed-off-by: Drew Gaylo <drew at nixcores.com>
>> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
>> b/target/linux/ramips/base-files/etc/board.d/02_network
>> index be1912a..ebcf619 100755
>> --- a/target/linux/ramips/base-files/etc/board.d/02_network
>> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
>> @@ -77,6 +77,7 @@ ramips_setup_interfaces()
>>       mt7628|\
>>       mzk-750dhp|\
>>       mzk-w300nh2|\
>> +    nixcore|\
>>       oy-0001|\
>>       pbr-m1|\
>>       psg1208|\
>> diff --git a/target/linux/ramips/base-files/lib/ramips.sh
>> b/target/linux/ramips/base-files/lib/ramips.sh
>> index bd4f33d..340a628 100755
>> --- a/target/linux/ramips/base-files/lib/ramips.sh
>> +++ b/target/linux/ramips/base-files/lib/ramips.sh
>> @@ -322,6 +322,9 @@ ramips_board_detect() {
>>       *"NCS601W")
>>           name="ncs601w"
>>           ;;
>> +    *"NixcoreX1")
>> +        name="nixcore-x1"
>> +        ;;
>>       *"NW718")
>>           name="nw718"
>>           ;;
>> diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh
>> b/target/linux/ramips/base-files/lib/upgrade/platform.sh
>> index 0b3d8c7..8749c99 100755
>> --- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
>> +++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
>> @@ -95,6 +95,7 @@ platform_check_image() {
>>       mzk-w300nh2|\
>>       mzk-wdpr|\
>>       nbg-419n|\
>> +    nixcore|\
>>       nw718|\
>>       oy-0001|\
>>       pbr-m1|\
>> diff --git a/target/linux/ramips/dts/NIXCOREX1-16M.dts
>> b/target/linux/ramips/dts/NIXCOREX1-16M.dts
>> new file mode 100644
>> index 0000000..2ffcbb2
>> --- /dev/null
>> +++ b/target/linux/ramips/dts/NIXCOREX1-16M.dts
>> @@ -0,0 +1,95 @@
>> +/dts-v1/;
>> +
>> +/include/ "rt5350.dtsi"
>> +
>> +/ {
>> +    compatible = "NixcoreX1", "ralink,rt5350-soc";
>> +    model = "NixcoreX1";
>> +
>> +    chosen{
>> +        bootargs = "console=ttyS1,57600";
>> +    };
>> +};
>> +
>> +&gpio0{
>> +    status = "okay";
>> +};
>> +
>> +&gpio1{
>> +    status = "okay";
>> +};
>> +
>> +&i2c{
>> +    status = "okay";
>> +};
>> +&uart{
>> +    status = "okay";
>> +    /* Mix of uart and gpio */
>> +    reset-names = "gpio uartf";
>> +};
>> +&spi0{
>> +    status = "okay";
>> +
>> +    m25p80 at 0 {
>> +        #address-cells = <1>;
>> +        #size-cells = <1>;
>> +        compatible = "s25fl064k";
>> +        reg = <0>;
>> +        linux,modalias = "m25p80", "s25fl064k";
>> +        spi-max-frequency = <10000000>;
>> +
>> +        partition at 0 {
>> +            label = "uboot";
>> +            reg = <0x0 0x30000>;
>> +            read-only;
>> +        };
>> +
>> +        partition at 30000 {
>> +            label = "uboot-env";
>> +            reg = <0x30000 0x10000>;
>> +            read-only;
>> +        };
>> +
>> +        factory: partition at 40000 {
>> +            label = "factory";
>> +            reg = <0x40000 0x10000>;
>> +            read-only;
>> +        };
>> +
>> +        partition at 50000 {
>> +            label = "firmware";
>> +            reg = <0x50000 0xfb0000>;
>> +        };
>> +    };
>> +};
>> +
>> +&pinctrl {
>> +    state_default: pinctrl0 {
>> +        gpio {
>> +            /* Associate the tjag, uartf and led groups with gpio */
>> +            ralink,group = "jtag", "led", "spi_cs1";
>> +            /* How do we set individual pins? */
>> +            ralink,function = "gpio";
>> +        };
>> +    };
>> +};
>> +
>> +&ethernet {
>> +    mtd-mac-address = <&factory 0x4>;
>> +};
>> +
>> +&esw {
>> +    ralink,portmap = <0x17>;
>> +};
>> +
>> +&wmac {
>> +    ralink,mtd-eeprom = <&factory 0>;
>> +};
>> +
>> +&ehci {
>> +    status = "okay";
>> +};
>> +
>> +&ohci {
>> +    status = "okay";
>> +};
>> diff --git a/target/linux/ramips/dts/NIXCOREX1-8M.dts
>> b/target/linux/ramips/dts/NIXCOREX1-8M.dts
>> new file mode 100644
>> index 0000000..ca557fd
>> --- /dev/null
>> +++ b/target/linux/ramips/dts/NIXCOREX1-8M.dts
>> @@ -0,0 +1,95 @@
>> +/dts-v1/;
>> +
>> +/include/ "rt5350.dtsi"
>> +
>> +/ {
>> +    compatible = "NixcoreX1", "ralink,rt5350-soc";
>> +    model = "NixcoreX1";
>> +
>> +    chosen{
>> +        bootargs = "console=ttyS1,57600";
>> +    };
>> +};
>> +
>> +&gpio0{
>> +    status = "okay";
>> +};
>> +
>> +&gpio1{
>> +    status = "okay";
>> +};
>> +
>> +&i2c{
>> +    status = "okay";
>> +};
>> +&uart{
>> +    status = "okay";
>> +    /* Mix of uart and gpio */
>> +    reset-names = "gpio uartf";
>> +};
>> +&spi0{
>> +    status = "okay";
>> +
>> +    m25p80 at 0 {
>> +        #address-cells = <1>;
>> +        #size-cells = <1>;
>> +        compatible = "s25fl064k";
>> +        reg = <0>;
>> +        linux,modalias = "m25p80", "s25fl064k";
>> +        spi-max-frequency = <10000000>;
>> +
>> +        partition at 0 {
>> +            label = "uboot";
>> +            reg = <0x0 0x30000>;
>> +            read-only;
>> +        };
>> +
>> +        partition at 30000 {
>> +            label = "uboot-env";
>> +            reg = <0x30000 0x10000>;
>> +            read-only;
>> +        };
>> +
>> +        factory: partition at 40000 {
>> +            label = "factory";
>> +            reg = <0x40000 0x10000>;
>> +            read-only;
>> +        };
>> +
>> +        partition at 50000 {
>> +            label = "firmware";
>> +            reg = <0x50000 0x7b0000>;
>> +        };
>> +    };
>> +};
>> +
>> +&pinctrl {
>> +    state_default: pinctrl0 {
>> +        gpio {
>> +            /* Associate the tjag, uartf and led groups with gpio */
>> +            ralink,group = "jtag", "led", "spi_cs1";
>> +            /* How do we set individual pins? */
>> +            ralink,function = "gpio";
>> +        };
>> +    };
>> +};
>> +
>> +&ethernet {
>> +    mtd-mac-address = <&factory 0x4>;
>> +};
>> +
>> +&esw {
>> +    ralink,portmap = <0x17>;
>> +};
>> +
>> +&wmac {
>> +    ralink,mtd-eeprom = <&factory 0>;
>> +};
>> +
>> +&ehci {
>> +    status = "okay";
>> +};
>> +
>> +&ohci {
>> +    status = "okay";
>> +};
>> diff --git a/target/linux/ramips/image/rt305x.mk
>> b/target/linux/ramips/image/rt305x.mk
>> index da7fc46..db12a8e 100644
>> --- a/target/linux/ramips/image/rt305x.mk
>> +++ b/target/linux/ramips/image/rt305x.mk
>> @@ -100,6 +100,21 @@ define BuildFirmware/HLKRM04/initramfs
>>       mkhilinkfw -e -i$(call imgname,$(1),$(2))-uImage.bin -o $(call
>> imgname,$(1),$(2))-factory.bin;
>>   endef
>>
>> +# This is called to build the nixcore image.  Build both 8MB and 16MB
>> +nixcore_8mb_mtd_size=8060928
>> +nixcore_16mb_mtd_size=16449536
>> +define BuildFirmware/NIXCOREX1/squashfs
>> +# Args are XXX, nixcore-mM and NIXCOREX1-xM
>> +    $(call
>> BuildFirmware/CustomFlash/$(1),$(1),$(2)-8M,$(3)-8M,$(nixcore_8mb_mtd_size))
>>
>> +    $(call
>> BuildFirmware/CustomFlash/$(1),$(1),$(2)-16M,$(3)-16M,$(nixcore_16mb_mtd_size))
>>
>> +    # Can do somethings here after the build?
>> +endef
>> +define BuildFirmware/NIXCOREX1/initramfs
>> +# Args are XXXX, nixcore-mM and NIXCOREX1-xM
>> +    $(call BuildFirmware/OF/initramfs,$(1),$(2)-8M,$(3)-8M)
>> +    $(call BuildFirmware/OF/initramfs,$(1),$(2)-16M,$(3)-16M)
>> +endef
>> +
>>   vocore_8mb_mtd_size=8060928
>>   vocore_16mb_mtd_size=16449536
>>   define BuildFirmware/VOCORE/squashfs
>> @@ -257,6 +272,7 @@ Image/Build/Profile/NBG-419N=$(call
>> BuildFirmware/Default4M/$(1),$(1),nbg-419n,N
>>   Image/Build/Profile/MZKW300NH2=$(call
>> BuildFirmware/Edimax/$(1),$(1),mzk-w300nh2,MZK-W300NH2,$(mzkw300nh2_mtd_size),CSYS,RN52,0x50000,0xc0000)
>>
>>   Image/Build/Profile/MZKWDPR=$(call
>> BuildFirmware/Default8M/$(1),$(1),mzk-wdpr,MZK-WDPR)
>>   Image/Build/Profile/NCS601W=$(call
>> BuildFirmware/Default8M/$(1),$(1),ncs601W,NCS601W)
>> +Image/Build/Profile/NIXCOREX1=$(call
>> BuildFirmware/NIXCOREX1/$(1),$(1),nixcorex1,NIXCOREX1)
>>   nw718_mtd_size=3801088
>>   Image/Build/Profile/NW718=$(call
>> BuildFirmware/CustomFlashFactory/$(1),$(1),nw718m,NW718,$(nw718_mtd_size),ARA1B4NCRNW718;1,factory)
>>
>>   Image/Build/Profile/M2M=$(call
>> BuildFirmware/Default8M/$(1),$(1),m2m,M2M,Linux Kernel Image)
>> @@ -353,6 +369,7 @@ define Image/Build/Profile/Default
>>       $(call Image/Build/Profile/MZKWDPR,$(1))
>>       $(call Image/Build/Profile/NBG-419N,$(1))
>>       $(call Image/Build/Profile/NCS601W,$(1))
>> +    $(call Image/Build/Profile/NIXCOREX1,$(1))
>>       $(call Image/Build/Profile/NW718,$(1))
>>       $(call Image/Build/Profile/MINIEMBWIFI,$(1))
>>       $(call Image/Build/Profile/MINIEMBPLUG,$(1))
>> diff --git a/target/linux/ramips/rt305x/profiles/nixcore.mk
>> b/target/linux/ramips/rt305x/profiles/nixcore.mk
>> new file mode 100644
>> index 0000000..22dee9b
>> --- /dev/null
>> +++ b/target/linux/ramips/rt305x/profiles/nixcore.mk
>> @@ -0,0 +1,20 @@
>> +#
>> +# Copyright (C) 2014 OpenWrt.org
>> +#
>> +# This is free software, licensed under the GNU General Public License v2.
>> +# See /LICENSE for more information.
>> +#
>> +
>> +define Profile/NIXCOREX1
>> +    NAME:=NixcoreX1
>> +    PACKAGES:=\
>> +        kmod-usb-core kmod-usb-ohci kmod-usb2 \
>> +        kmod-i2c-core kmod-i2c-ralink \
>> +        kmod-spi-dev
>> +endef
>> +
>> +define Profile/NIXCOREX1/Description
>> +    Package set for Nixcore X1 board
>> +endef
>> +
>> +$(eval $(call Profile,NIXCOREX1))
>>
>>
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev



From drew at nixcores.com  Thu Jun 16 10:00:37 2016
From: drew at nixcores.com (Drew from NixCore)
Date: Thu, 16 Jun 2016 13:00:37 -0400
Subject: [LEDE-DEV] [PATCH] [ramips] Added NixCore X1 target V5
In-Reply-To: <651aaa54-c389-7edb-8603-56b5d9b226d5@phrozen.org>
References: <5761F4AC.1010805@nixcores.com>
 <651aaa54-c389-7edb-8603-56b5d9b226d5@phrozen.org>
Message-ID: <5762DB35.7050804@nixcores.com>

Anther test with a segment of the patch that is wrapping

@@ -257,6 +272,7 @@ Image/Build/Profile/NBG-419N=$(call 
BuildFirmware/Default4M/$(1),$(1),nbg-419n,N
  Image/Build/Profile/MZKW300NH2=$(call 
BuildFirmware/Edimax/$(1),$(1),mzk-w300nh2,MZK-W300NH2,$(mzkw300nh2_mtd_size),CSYS,RN52,0x50000,0xc0000)
  Image/Build/Profile/MZKWDPR=$(call 
BuildFirmware/Default8M/$(1),$(1),mzk-wdpr,MZK-WDPR)
  Image/Build/Profile/NCS601W=$(call 
BuildFirmware/Default8M/$(1),$(1),ncs601W,NCS601W)
+Image/Build/Profile/NIXCOREX1=$(call 
BuildFirmware/NIXCOREX1/$(1),$(1),nixcorex1,NIXCOREX1)
  nw718_mtd_size=3801088
  Image/Build/Profile/NW718=$(call 
BuildFirmware/CustomFlashFactory/$(1),$(1),nw718m,NW718,$(nw718_mtd_size),ARA1B4NCRNW718;1,factory)
  Image/Build/Profile/M2M=$(call 
BuildFirmware/Default8M/$(1),$(1),m2m,M2M,Linux Kernel Image)
@@ -353,6 +369,7 @@ define Image/Build/Profile/Default
      $(call Image/Build/Profile/MZKWDPR,$(1))
      $(call Image/Build/Profile/NBG-419N,$(1))
      $(call Image/Build/Profile/NCS601W,$(1))
+    $(call Image/Build/Profile/NIXCOREX1,$(1))
      $(call Image/Build/Profile/NW718,$(1))
      $(call Image/Build/Profile/MINIEMBWIFI,$(1))
      $(call Image/Build/Profile/MINIEMBPLUG,$(1))

On 06/16/2016 07:45 AM, John Crispin wrote:
> Hi,
>
> patch does not apply. please go here
>
> --> http://patchwork.ozlabs.org/patch/636150/
>
> click on "download mbox" and you will see that it is line wrapped at 80
> characters.
>
> 	John
>
>
> On 16/06/2016 02:37, Drew from NixCore wrote:
>> Added NixCore X1 ramips target http://nixcores.com.  This builds 8M and
>> 16M images.  V5 updates the patch to work with the latest source.git
>>
>> Signed-off-by: Drew Gaylo <drew at nixcores.com>
>> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
>> b/target/linux/ramips/base-files/etc/board.d/02_network
>> index be1912a..ebcf619 100755
>> --- a/target/linux/ramips/base-files/etc/board.d/02_network
>> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
>> @@ -77,6 +77,7 @@ ramips_setup_interfaces()
>>       mt7628|\
>>       mzk-750dhp|\
>>       mzk-w300nh2|\
>> +    nixcore|\
>>       oy-0001|\
>>       pbr-m1|\
>>       psg1208|\
>> diff --git a/target/linux/ramips/base-files/lib/ramips.sh
>> b/target/linux/ramips/base-files/lib/ramips.sh
>> index bd4f33d..340a628 100755
>> --- a/target/linux/ramips/base-files/lib/ramips.sh
>> +++ b/target/linux/ramips/base-files/lib/ramips.sh
>> @@ -322,6 +322,9 @@ ramips_board_detect() {
>>       *"NCS601W")
>>           name="ncs601w"
>>           ;;
>> +    *"NixcoreX1")
>> +        name="nixcore-x1"
>> +        ;;
>>       *"NW718")
>>           name="nw718"
>>           ;;
>> diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh
>> b/target/linux/ramips/base-files/lib/upgrade/platform.sh
>> index 0b3d8c7..8749c99 100755
>> --- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
>> +++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
>> @@ -95,6 +95,7 @@ platform_check_image() {
>>       mzk-w300nh2|\
>>       mzk-wdpr|\
>>       nbg-419n|\
>> +    nixcore|\
>>       nw718|\
>>       oy-0001|\
>>       pbr-m1|\
>> diff --git a/target/linux/ramips/dts/NIXCOREX1-16M.dts
>> b/target/linux/ramips/dts/NIXCOREX1-16M.dts
>> new file mode 100644
>> index 0000000..2ffcbb2
>> --- /dev/null
>> +++ b/target/linux/ramips/dts/NIXCOREX1-16M.dts
>> @@ -0,0 +1,95 @@
>> +/dts-v1/;
>> +
>> +/include/ "rt5350.dtsi"
>> +
>> +/ {
>> +    compatible = "NixcoreX1", "ralink,rt5350-soc";
>> +    model = "NixcoreX1";
>> +
>> +    chosen{
>> +        bootargs = "console=ttyS1,57600";
>> +    };
>> +};
>> +
>> +&gpio0{
>> +    status = "okay";
>> +};
>> +
>> +&gpio1{
>> +    status = "okay";
>> +};
>> +
>> +&i2c{
>> +    status = "okay";
>> +};
>> +&uart{
>> +    status = "okay";
>> +    /* Mix of uart and gpio */
>> +    reset-names = "gpio uartf";
>> +};
>> +&spi0{
>> +    status = "okay";
>> +
>> +    m25p80 at 0 {
>> +        #address-cells = <1>;
>> +        #size-cells = <1>;
>> +        compatible = "s25fl064k";
>> +        reg = <0>;
>> +        linux,modalias = "m25p80", "s25fl064k";
>> +        spi-max-frequency = <10000000>;
>> +
>> +        partition at 0 {
>> +            label = "uboot";
>> +            reg = <0x0 0x30000>;
>> +            read-only;
>> +        };
>> +
>> +        partition at 30000 {
>> +            label = "uboot-env";
>> +            reg = <0x30000 0x10000>;
>> +            read-only;
>> +        };
>> +
>> +        factory: partition at 40000 {
>> +            label = "factory";
>> +            reg = <0x40000 0x10000>;
>> +            read-only;
>> +        };
>> +
>> +        partition at 50000 {
>> +            label = "firmware";
>> +            reg = <0x50000 0xfb0000>;
>> +        };
>> +    };
>> +};
>> +
>> +&pinctrl {
>> +    state_default: pinctrl0 {
>> +        gpio {
>> +            /* Associate the tjag, uartf and led groups with gpio */
>> +            ralink,group = "jtag", "led", "spi_cs1";
>> +            /* How do we set individual pins? */
>> +            ralink,function = "gpio";
>> +        };
>> +    };
>> +};
>> +
>> +&ethernet {
>> +    mtd-mac-address = <&factory 0x4>;
>> +};
>> +
>> +&esw {
>> +    ralink,portmap = <0x17>;
>> +};
>> +
>> +&wmac {
>> +    ralink,mtd-eeprom = <&factory 0>;
>> +};
>> +
>> +&ehci {
>> +    status = "okay";
>> +};
>> +
>> +&ohci {
>> +    status = "okay";
>> +};
>> diff --git a/target/linux/ramips/dts/NIXCOREX1-8M.dts
>> b/target/linux/ramips/dts/NIXCOREX1-8M.dts
>> new file mode 100644
>> index 0000000..ca557fd
>> --- /dev/null
>> +++ b/target/linux/ramips/dts/NIXCOREX1-8M.dts
>> @@ -0,0 +1,95 @@
>> +/dts-v1/;
>> +
>> +/include/ "rt5350.dtsi"
>> +
>> +/ {
>> +    compatible = "NixcoreX1", "ralink,rt5350-soc";
>> +    model = "NixcoreX1";
>> +
>> +    chosen{
>> +        bootargs = "console=ttyS1,57600";
>> +    };
>> +};
>> +
>> +&gpio0{
>> +    status = "okay";
>> +};
>> +
>> +&gpio1{
>> +    status = "okay";
>> +};
>> +
>> +&i2c{
>> +    status = "okay";
>> +};
>> +&uart{
>> +    status = "okay";
>> +    /* Mix of uart and gpio */
>> +    reset-names = "gpio uartf";
>> +};
>> +&spi0{
>> +    status = "okay";
>> +
>> +    m25p80 at 0 {
>> +        #address-cells = <1>;
>> +        #size-cells = <1>;
>> +        compatible = "s25fl064k";
>> +        reg = <0>;
>> +        linux,modalias = "m25p80", "s25fl064k";
>> +        spi-max-frequency = <10000000>;
>> +
>> +        partition at 0 {
>> +            label = "uboot";
>> +            reg = <0x0 0x30000>;
>> +            read-only;
>> +        };
>> +
>> +        partition at 30000 {
>> +            label = "uboot-env";
>> +            reg = <0x30000 0x10000>;
>> +            read-only;
>> +        };
>> +
>> +        factory: partition at 40000 {
>> +            label = "factory";
>> +            reg = <0x40000 0x10000>;
>> +            read-only;
>> +        };
>> +
>> +        partition at 50000 {
>> +            label = "firmware";
>> +            reg = <0x50000 0x7b0000>;
>> +        };
>> +    };
>> +};
>> +
>> +&pinctrl {
>> +    state_default: pinctrl0 {
>> +        gpio {
>> +            /* Associate the tjag, uartf and led groups with gpio */
>> +            ralink,group = "jtag", "led", "spi_cs1";
>> +            /* How do we set individual pins? */
>> +            ralink,function = "gpio";
>> +        };
>> +    };
>> +};
>> +
>> +&ethernet {
>> +    mtd-mac-address = <&factory 0x4>;
>> +};
>> +
>> +&esw {
>> +    ralink,portmap = <0x17>;
>> +};
>> +
>> +&wmac {
>> +    ralink,mtd-eeprom = <&factory 0>;
>> +};
>> +
>> +&ehci {
>> +    status = "okay";
>> +};
>> +
>> +&ohci {
>> +    status = "okay";
>> +};
>> diff --git a/target/linux/ramips/image/rt305x.mk
>> b/target/linux/ramips/image/rt305x.mk
>> index da7fc46..db12a8e 100644
>> --- a/target/linux/ramips/image/rt305x.mk
>> +++ b/target/linux/ramips/image/rt305x.mk
>> @@ -100,6 +100,21 @@ define BuildFirmware/HLKRM04/initramfs
>>       mkhilinkfw -e -i$(call imgname,$(1),$(2))-uImage.bin -o $(call
>> imgname,$(1),$(2))-factory.bin;
>>   endef
>>
>> +# This is called to build the nixcore image.  Build both 8MB and 16MB
>> +nixcore_8mb_mtd_size=8060928
>> +nixcore_16mb_mtd_size=16449536
>> +define BuildFirmware/NIXCOREX1/squashfs
>> +# Args are XXX, nixcore-mM and NIXCOREX1-xM
>> +    $(call
>> BuildFirmware/CustomFlash/$(1),$(1),$(2)-8M,$(3)-8M,$(nixcore_8mb_mtd_size))
>>
>> +    $(call
>> BuildFirmware/CustomFlash/$(1),$(1),$(2)-16M,$(3)-16M,$(nixcore_16mb_mtd_size))
>>
>> +    # Can do somethings here after the build?
>> +endef
>> +define BuildFirmware/NIXCOREX1/initramfs
>> +# Args are XXXX, nixcore-mM and NIXCOREX1-xM
>> +    $(call BuildFirmware/OF/initramfs,$(1),$(2)-8M,$(3)-8M)
>> +    $(call BuildFirmware/OF/initramfs,$(1),$(2)-16M,$(3)-16M)
>> +endef
>> +
>>   vocore_8mb_mtd_size=8060928
>>   vocore_16mb_mtd_size=16449536
>>   define BuildFirmware/VOCORE/squashfs
>> @@ -257,6 +272,7 @@ Image/Build/Profile/NBG-419N=$(call
>> BuildFirmware/Default4M/$(1),$(1),nbg-419n,N
>>   Image/Build/Profile/MZKW300NH2=$(call
>> BuildFirmware/Edimax/$(1),$(1),mzk-w300nh2,MZK-W300NH2,$(mzkw300nh2_mtd_size),CSYS,RN52,0x50000,0xc0000)
>>
>>   Image/Build/Profile/MZKWDPR=$(call
>> BuildFirmware/Default8M/$(1),$(1),mzk-wdpr,MZK-WDPR)
>>   Image/Build/Profile/NCS601W=$(call
>> BuildFirmware/Default8M/$(1),$(1),ncs601W,NCS601W)
>> +Image/Build/Profile/NIXCOREX1=$(call
>> BuildFirmware/NIXCOREX1/$(1),$(1),nixcorex1,NIXCOREX1)
>>   nw718_mtd_size=3801088
>>   Image/Build/Profile/NW718=$(call
>> BuildFirmware/CustomFlashFactory/$(1),$(1),nw718m,NW718,$(nw718_mtd_size),ARA1B4NCRNW718;1,factory)
>>
>>   Image/Build/Profile/M2M=$(call
>> BuildFirmware/Default8M/$(1),$(1),m2m,M2M,Linux Kernel Image)
>> @@ -353,6 +369,7 @@ define Image/Build/Profile/Default
>>       $(call Image/Build/Profile/MZKWDPR,$(1))
>>       $(call Image/Build/Profile/NBG-419N,$(1))
>>       $(call Image/Build/Profile/NCS601W,$(1))
>> +    $(call Image/Build/Profile/NIXCOREX1,$(1))
>>       $(call Image/Build/Profile/NW718,$(1))
>>       $(call Image/Build/Profile/MINIEMBWIFI,$(1))
>>       $(call Image/Build/Profile/MINIEMBPLUG,$(1))
>> diff --git a/target/linux/ramips/rt305x/profiles/nixcore.mk
>> b/target/linux/ramips/rt305x/profiles/nixcore.mk
>> new file mode 100644
>> index 0000000..22dee9b
>> --- /dev/null
>> +++ b/target/linux/ramips/rt305x/profiles/nixcore.mk
>> @@ -0,0 +1,20 @@
>> +#
>> +# Copyright (C) 2014 OpenWrt.org
>> +#
>> +# This is free software, licensed under the GNU General Public License v2.
>> +# See /LICENSE for more information.
>> +#
>> +
>> +define Profile/NIXCOREX1
>> +    NAME:=NixcoreX1
>> +    PACKAGES:=\
>> +        kmod-usb-core kmod-usb-ohci kmod-usb2 \
>> +        kmod-i2c-core kmod-i2c-ralink \
>> +        kmod-spi-dev
>> +endef
>> +
>> +define Profile/NIXCOREX1/Description
>> +    Package set for Nixcore X1 board
>> +endef
>> +
>> +$(eval $(call Profile,NIXCOREX1))
>>
>>
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev



From david at lang.hm  Thu Jun 16 10:42:13 2016
From: david at lang.hm (David Lang)
Date: Thu, 16 Jun 2016 10:42:13 -0700 (PDT)
Subject: [LEDE-DEV] lede integration issues remaining from the detrius
 of cerowrt
In-Reply-To: <CAKNoO9oLbR6ipAG2X_GAvn2CeVdfapP4qhH-Mut=CjrC3iBUkg@mail.gmail.com>
References: <CAA93jw7=bHNXJqmjWmg3CHHH-biua17wK4AHfn_wB0wPWs=EqQ@mail.gmail.com>
 <CAJOqq5TB4qki1iWHZd71kzXYoA=A3+4BeycoNPKqRXFWZ6bMZQ@mail.gmail.com>
 <f6898485-e1d4-ec35-4563-4591512d2d84@mein.io>
 <1465868455.2580.35.camel@homehost>
 <alpine.DEB.2.02.1606141048400.2494@nftneq.ynat.uz>
 <1465939839.2633.29.camel@homehost>
 <alpine.DEB.2.02.1606160046050.1832@nftneq.ynat.uz>
 <CAKNoO9oLbR6ipAG2X_GAvn2CeVdfapP4qhH-Mut=CjrC3iBUkg@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1606161040150.3043@nftneq.ynat.uz>

On Thu, 16 Jun 2016, Aaron Z wrote:

> it would be nice to have Nano installed by default (hard to
> use vi over ssh from a phone that doesn't have an escape key :D).

If you are using Android, look at the hacker keyboard

https://play.google.com/store/apps/details?id=org.pocketworkstation.pckeyboard

it gives you a traditional keyboard (including escape)

David Lang


From knaack.h at gmx.de  Thu Jun 16 11:05:23 2016
From: knaack.h at gmx.de (Hartmut Knaack)
Date: Thu, 16 Jun 2016 20:05:23 +0200
Subject: [LEDE-DEV] [PATCH] [ramips] Added NixCore X1 target V4
In-Reply-To: <5761EFB8.2020404@nixcores.com>
References: <5761BC01.5080409@nixcores.com> <5761EFB8.2020404@nixcores.com>
Message-ID: <5762EA63.7090906@gmx.de>

Drew from NixCore schrieb am 16.06.2016 um 02:15:
> So it appears that this patch doesn't apply either.  I have re-checked 
> out the latest source and made the changes manually rather than using tools.
> 
> This patch is invalid and I will be submitting V5.  Please bear with me 
> as this is my first submission to LEDE
> 
> Drew

Hi Drew,
not sure if your mail-client is to blame, but some indentation got messed up
a bit due to spaces used, while tabs are the better choice.
Also have a look at the -v option of git format-patch.
Thanks,

Hartmut

> 
> On 06/15/2016 04:35 PM, Drew from NixCore wrote:
>> Added NixCore X1 ramips targethttp://nixcores.com. 
>> <http://nixcores.com./>  This builds 8M and 16M images.  V4 updates 
>> the patch to fix whitespace issues in V3
>>
>> Signed-off-by: Drew Gaylo <drew at nixcores.com>
>> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
>> b/target/linux/ramips/base-files/etc/board.d/02_network
>> index 4728c75..69c0125 100755
>> --- a/target/linux/ramips/base-files/etc/board.d/02_network
>> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
>> @@ -77,6 +77,7 @@ ramips_setup_interfaces()
>>      mt7628|\
>>      mzk-750dhp|\
>>      mzk-w300nh2|\
>> +    nixcore|\
>>      oy-0001|\
>>      pbr-m1|\
>>      psg1208|\
>> diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
>> b/target/linux/ramips/base-files/lib/ramips.sh
>> index cbe455d..76f0e43 100755
>> --- a/target/linux/ramips/base-files/lib/ramips.sh
>> +++ b/target/linux/ramips/base-files/lib/ramips.sh
>> @@ -316,6 +316,9 @@ ramips_board_detect() {
>>      *"NCS601W")
>>          name="ncs601w"
>>          ;;
>> +    *"NixcoreX1")
>> +        name="nixcore-x1"
>> +        ;;
>>      *"NW718")
>>          name="nw718"
>>          ;;
>> diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
>> b/target/linux/ramips/base-files/lib/upgrade/platform.sh
>> index 91c9997..0094568 100755
>> --- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
>> +++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
>> @@ -94,6 +94,7 @@ platform_check_image() {
>>      mzk-w300nh2|\
>>      mzk-wdpr|\
>>      nbg-419n|\
>> +    nixcore|\
>>      nw718|\
>>      oy-0001|\
>>      pbr-m1|\
>> diff --git a/target/linux/ramips/dts/NIXCOREX1-16M.dts 
>> b/target/linux/ramips/dts/NIXCOREX1-16M.dts
>> new file mode 100644
>> index 0000000..1e1a205
>> --- /dev/null
>> +++ b/target/linux/ramips/dts/NIXCOREX1-16M.dts
>> @@ -0,0 +1,182 @@
>> +/dts-v1/;
>> +
>> +/include/ "rt5350.dtsi"
>> +
>> +/ {
>> +    compatible = "NixcoreX1", "ralink,rt5350-soc";
>> +    model = "NixcoreX1";
>> +
>> +    chosen{
>> +        bootargs = "console=ttyS1,57600";
>> +    };
>> +
>> +    gpio-export {
>> +        compatible = "gpio-export";
>> +        #size-cells = <0>;
>> +
>> +        gpio0 {
>> +            gpio-export,name = "gpio0";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 0 0>;
>> +        };
>> +        /* GPIOs 1-6 are I2C,SPI */
>> +
>> +        /* GPIO 7-14 are uart1 */
>> +
>> +        /* GPIOs 15 & 16 are uart2 */
>> +
>> +        /* JTAG */
>> +        gpio17 {
>> +            /* JTAG_TDO */
>> +            gpio-export,name = "gpio17";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 17 0>;
>> +        };
>> +        gpio18 {
>> +            /* JTAG_TDI */
>> +            gpio-export,name = "gpio18";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 18 0>;
>> +        };
>> +        gpio19 {
>> +            /* JTAG_TMS */
>> +            gpio-export,name = "gpio19";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 19 0>;
>> +        };
>> +        gpio20 {
>> +            /* JTAG_TCLK */
>> +            gpio-export,name = "gpio20";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 20 0>;
>> +        };
>> +        gpio21 {
>> +            /* JTAG_TRST_N */
>> +            gpio-export,name = "gpio21";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 21 0>;
>> +        };
>> +
>> +        /* ETH LEDs */
>> +        /*
>> +        gpio22 {
>> +            gpio-export,name = "gpio22";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 0 0>;
>> +        };
>> +        gpio23 {
>> +            gpio-export,name = "gpio23";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 1 0>;
>> +        };
>> +        gpio24 {
>> +            gpio-export,name = "gpio24";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 2 0>;
>> +        };
>> +        gpio25 {
>> +            gpio-export,name = "gpio25";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 3 0>;
>> +        };
>> +        */
>> +
>> +        gpio26 {
>> +            /* ETH4_LED */
>> +            gpio-export,name = "gpio26";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 4 0>;
>> +        };
>> +
>> +        gpio27 {
>> +            /* spi_cs1 */
>> +            gpio-export,name = "gpio27";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 5 0>;
>> +        };
>> +    };
>> +
>> +};
>> +
>> +&gpio0{
>> +    status = "okay";
>> +};
>> +
>> +&gpio1{
>> +    status = "okay";
>> +};
>> +
>> +&i2c{
>> +    status = "okay";
>> +};
>> +&uart{
>> +    status = "okay";
>> +    /* Mix of uart and gpio */
>> +    reset-names = "gpio uartf";
>> +};
>> +&spi0{
>> +    status = "okay";
>> +
>> +    m25p80 at 0 {
>> +        #address-cells = <1>;
>> +        #size-cells = <1>;
>> +        compatible = "s25fl064k";
>> +        reg = <0>;
>> +        linux,modalias = "m25p80", "s25fl064k";
>> +        spi-max-frequency = <10000000>;
>> +
>> +        partition at 0 {
>> +            label = "uboot";
>> +            reg = <0x0 0x30000>;
>> +            read-only;
>> +        };
>> +
>> +        partition at 30000 {
>> +            label = "uboot-env";
>> +            reg = <0x30000 0x10000>;
>> +            read-only;
>> +        };
>> +
>> +        factory: partition at 40000 {
>> +            label = "factory";
>> +            reg = <0x40000 0x10000>;
>> +            read-only;
>> +        };
>> +
>> +        partition at 50000 {
>> +            label = "firmware";
>> +            reg = <0x50000 0xfb0000>;
>> +        };
>> +    };
>> +};
>> +
>> +&pinctrl {
>> +    state_default: pinctrl0 {
>> +        gpio {
>> +            /* Associate the tjag, uartf and led groups with gpio */
>> +            ralink,group = "jtag", "led", "spi_cs1";
>> +            /* How do we set individual pins? */
>> +            ralink,function = "gpio";
>> +        };
>> +    };
>> +};
>> +
>> +&ethernet {
>> +    mtd-mac-address = <&factory 0x4>;
>> +};
>> +
>> +&esw {
>> +    ralink,portmap = <0x17>;
>> +};
>> +
>> +&wmac {
>> +    ralink,mtd-eeprom = <&factory 0>;
>> +};
>> +
>> +&ehci {
>> +    status = "okay";
>> +};
>> +
>> +&ohci {
>> +    status = "okay";
>> +};
>> diff --git a/target/linux/ramips/dts/NIXCOREX1-8M.dts 
>> b/target/linux/ramips/dts/NIXCOREX1-8M.dts
>> new file mode 100644
>> index 0000000..c514860
>> --- /dev/null
>> +++ b/target/linux/ramips/dts/NIXCOREX1-8M.dts
>> @@ -0,0 +1,183 @@
>> +/dts-v1/;
>> +
>> +/include/ "rt5350.dtsi"
>> +
>> +/ {
>> +    compatible = "NixcoreX1", "ralink,rt5350-soc";
>> +    model = "NixcoreX1";
>> +
>> +    chosen{
>> +        bootargs = "console=ttyS1,57600";
>> +    };
>> +
>> +    gpio-export {
>> +        compatible = "gpio-export";
>> +        #size-cells = <0>;
>> +
>> +        gpio0 {
>> +            gpio-export,name = "gpio0";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 0 0>;
>> +        };
>> +        /* GPIOs 1-6 are I2C,SPI */
>> +
>> +        /* GPIO 7-14 are uart1 */
>> +
>> +        /* GPIOs 15 & 16 are uart2 */
>> +
>> +        /* JTAG */
>> +        gpio17 {
>> +            /* JTAG_TDO */
>> +            gpio-export,name = "gpio17";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 17 0>;
>> +        };
>> +        gpio18 {
>> +            /* JTAG_TDI */
>> +            gpio-export,name = "gpio18";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 18 0>;
>> +        };
>> +        gpio19 {
>> +            /* JTAG_TMS */
>> +            gpio-export,name = "gpio19";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 19 0>;
>> +        };
>> +        gpio20 {
>> +            /* JTAG_TCLK */
>> +            gpio-export,name = "gpio20";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 20 0>;
>> +        };
>> +        gpio21 {
>> +            /* JTAG_TRST_N */
>> +            gpio-export,name = "gpio21";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio0 21 0>;
>> +        };
>> +
>> +        /* ETH LEDs */
>> +        /*
>> +        gpio22 {
>> +            gpio-export,name = "gpio22";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 0 0>;
>> +        };
>> +        gpio23 {
>> +            gpio-export,name = "gpio23";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 1 0>;
>> +        };
>> +        gpio24 {
>> +            gpio-export,name = "gpio24";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 2 0>;
>> +        };
>> +        gpio25 {
>> +            gpio-export,name = "gpio25";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 3 0>;
>> +        };
>> +        */
>> +
>> +        gpio26 {
>> +            /* ETH4_LED */
>> +            gpio-export,name = "gpio26";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 4 0>;
>> +        };
>> +
>> +        gpio27 {
>> +            /* spi_cs1 */
>> +            gpio-export,name = "gpio27";
>> +            gpio-export,direction_may_change = <1>;
>> +            gpios = <&gpio1 5 0>;
>> +        };
>> +    };
>> +
>> +};
>> +
>> +&gpio0{
>> +    status = "okay";
>> +};
>> +
>> +&gpio1{
>> +    status = "okay";
>> +};
>> +
>> +&i2c{
>> +    status = "okay";
>> +};
>> +&uart{
>> +    status = "okay";
>> +    /* Mix of uart and gpio */
>> +    reset-names = "gpio uartf";
>> +};
>> +&spi0{
>> +    status = "okay";
>> +
>> +    m25p80 at 0 {
>> +        #address-cells = <1>;
>> +        #size-cells = <1>;
>> +        compatible = "s25fl064k";
>> +        reg = <0>;
>> +        linux,modalias = "m25p80", "s25fl064k";
>> +        spi-max-frequency = <10000000>;
>> +
>> +        partition at 0 {
>> +            label = "uboot";
>> +            reg = <0x0 0x30000>;
>> +            read-only;
>> +        };
>> +
>> +        partition at 30000 {
>> +            label = "uboot-env";
>> +            reg = <0x30000 0x10000>;
>> +            read-only;
>> +        };
>> +
>> +        factory: partition at 40000 {
>> +            label = "factory";
>> +            reg = <0x40000 0x10000>;
>> +            read-only;
>> +        };
>> +
>> +        partition at 50000 {
>> +            label = "firmware";
>> +            reg = <0x50000 0x7b0000>;
>> +        };
>> +    };
>> +};
>> +
>> +&pinctrl {
>> +    state_default: pinctrl0 {
>> +        gpio {
>> +            /* Associate the tjag, uartf and led groups with gpio */
>> +            ralink,group = "jtag", "led", "spi_cs1";
>> +            /* How do we set individual pins? */
>> +            ralink,function = "gpio";
>> +        };
>> +    };
>> +};
>> +
>> +&ethernet {
>> +    mtd-mac-address = <&factory 0x4>;
>> +};
>> +
>> +&esw {
>> +    ralink,portmap = <0x17>;
>> +};
>> +
>> +&wmac {
>> +    ralink,mtd-eeprom = <&factory 0>;
>> +};
>> +
>> +&ehci {
>> +    status = "okay";
>> +};
>> +
>> +&ohci {
>> +    status = "okay";
>> +};
>> +
>> diff --git a/target/linux/ramips/image/rt305x.mk 
>> b/target/linux/ramips/image/rt305x.mk
>> index da7fc46..db12a8e 100644
>> --- a/target/linux/ramips/image/rt305x.mk
>> +++ b/target/linux/ramips/image/rt305x.mk
>> @@ -100,6 +100,21 @@ define BuildFirmware/HLKRM04/initramfs
>>      mkhilinkfw -e -i$(call imgname,$(1),$(2))-uImage.bin -o $(call 
>> imgname,$(1),$(2))-factory.bin;
>>  endef
>>
>> +# This is called to build the nixcore image.  Build both 8MB and 16MB
>> +nixcore_8mb_mtd_size=8060928
>> +nixcore_16mb_mtd_size=16449536
>> +define BuildFirmware/NIXCOREX1/squashfs
>> +# Args are XXX, nixcore-mM and NIXCOREX1-xM
>> +    $(call 
>> BuildFirmware/CustomFlash/$(1),$(1),$(2)-8M,$(3)-8M,$(nixcore_8mb_mtd_size))
>> +    $(call 
>> BuildFirmware/CustomFlash/$(1),$(1),$(2)-16M,$(3)-16M,$(nixcore_16mb_mtd_size))
>> +    # Can do somethings here after the build?
>> +endef
>> +define BuildFirmware/NIXCOREX1/initramfs
>> +# Args are XXXX, nixcore-mM and NIXCOREX1-xM
>> +    $(call BuildFirmware/OF/initramfs,$(1),$(2)-8M,$(3)-8M)
>> +    $(call BuildFirmware/OF/initramfs,$(1),$(2)-16M,$(3)-16M)
>> +endef
>> +
>>  vocore_8mb_mtd_size=8060928
>>  vocore_16mb_mtd_size=16449536
>>  define BuildFirmware/VOCORE/squashfs
>> @@ -257,6 +272,7 @@ Image/Build/Profile/NBG-419N=$(call 
>> BuildFirmware/Default4M/$(1),$(1),nbg-419n,N
>>  Image/Build/Profile/MZKW300NH2=$(call 
>> BuildFirmware/Edimax/$(1),$(1),mzk-w300nh2,MZK-W300NH2,$(mzkw300nh2_mtd_size),CSYS,RN52,0x50000,0xc0000)
>>  Image/Build/Profile/MZKWDPR=$(call 
>> BuildFirmware/Default8M/$(1),$(1),mzk-wdpr,MZK-WDPR)
>>  Image/Build/Profile/NCS601W=$(call 
>> BuildFirmware/Default8M/$(1),$(1),ncs601W,NCS601W)
>> +Image/Build/Profile/NIXCOREX1=$(call 
>> BuildFirmware/NIXCOREX1/$(1),$(1),nixcorex1,NIXCOREX1)
>>  nw718_mtd_size=3801088
>>  Image/Build/Profile/NW718=$(call 
>> BuildFirmware/CustomFlashFactory/$(1),$(1),nw718m,NW718,$(nw718_mtd_size),ARA1B4NCRNW718;1,factory)
>>  Image/Build/Profile/M2M=$(call 
>> BuildFirmware/Default8M/$(1),$(1),m2m,M2M,Linux Kernel Image)
>> @@ -353,6 +369,7 @@ define Image/Build/Profile/Default
>>      $(call Image/Build/Profile/MZKWDPR,$(1))
>>      $(call Image/Build/Profile/NBG-419N,$(1))
>>      $(call Image/Build/Profile/NCS601W,$(1))
>> +    $(call Image/Build/Profile/NIXCOREX1,$(1))
>>      $(call Image/Build/Profile/NW718,$(1))
>>      $(call Image/Build/Profile/MINIEMBWIFI,$(1))
>>      $(call Image/Build/Profile/MINIEMBPLUG,$(1))
>> diff --git a/target/linux/ramips/rt305x/profiles/nixcore.mk 
>> b/target/linux/ramips/rt305x/profiles/nixcore.mk
>> new file mode 100644
>> index 0000000..22dee9b
>> --- /dev/null
>> +++ b/target/linux/ramips/rt305x/profiles/nixcore.mk
>> @@ -0,0 +1,20 @@
>> +#
>> +# Copyright (C) 2014 OpenWrt.org
>> +#
>> +# This is free software, licensed under the GNU General Public 
>> License v2.
>> +# See /LICENSE for more information.
>> +#
>> +
>> +define Profile/NIXCOREX1
>> +    NAME:=NixcoreX1
>> +    PACKAGES:=\
>> +        kmod-usb-core kmod-usb-ohci kmod-usb2 \
>> +        kmod-i2c-core kmod-i2c-ralink \
>> +        kmod-spi-dev
>> +endef
>> +
>> +define Profile/NIXCOREX1/Description
>> +    Package set for Nixcore X1 board
>> +endef
>> +
>> +$(eval $(call Profile,NIXCOREX1))
>>
>>
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
> 
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xFAC89148.asc
Type: application/pgp-keys
Size: 3104 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20160616/7b0fe4a0/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20160616/7b0fe4a0/attachment.sig>

From joshbendavid at gmail.com  Thu Jun 16 11:48:46 2016
From: joshbendavid at gmail.com (Josh Bendavid)
Date: Thu, 16 Jun 2016 20:48:46 +0200
Subject: [LEDE-DEV] skb_warn_bad_offload + crash at high load on ipq806x
In-Reply-To: <CAD1MEwdz99Sjq66u+nsy+kmtAxPPPKnSR0fh3_h06CnKibZfww@mail.gmail.com>
References: <CAD1MEwdz99Sjq66u+nsy+kmtAxPPPKnSR0fh3_h06CnKibZfww@mail.gmail.com>
Message-ID: <CAD1MEwd_p2C2Eum7py1R8hzCyExYwxM+_CZX_PA8bDYgYvRFWQ@mail.gmail.com>

Ok,
Interestingly triggering a crash again, I get a somewhat different
stack trace.  (attached)

On 15 June 2016 at 12:33, Josh Bendavid <joshbendavid at gmail.com> wrote:
> Hi,
> Testing with Tp-Link Archer C2600 (ipq806x) after latest changes (move
> to 4.4 kernel + restore dma ethernet corruption fix), I have random
> reboots on high wired network load.
>
> Managed to get the kernel output during the crash below*.  Note that I
> also had similar crashes with 3.18 kernel, but did not get the kernel
> output from those to strictly confirm they are the same.
>
> Not clear to me whether this is a platform specific issue, a more
> general upstream bug, or something related to openwrt/lede patches.
>
> *
> Wed Jun 15 04:24:09 2016 kern.warn kernel: [  693.925294]
> ------------[ cut here ]------------
> Wed Jun 15 04:24:09 2016 kern.warn kernel: [  693.925337] WARNING:
> CPU: 0 PID: 3 at net/core/dev.c:2422 skb_warn_bad_offload+0xe4/0xf8()
> Wed Jun 15 04:24:09 2016 kern.warn kernel: [  693.929065] br-lan:
> caps=(0x000000801fd978a9, 0x0000000000000000) len=1500 data_len=0
> gso_size=3426 gso_type=35530 ip_summed=1
> Wed Jun 15 04:24:09 2016 kern.warn kernel: [  693.937164] Modules
> linked in: pppoe ppp_async iptable_nat pppox ppp_generic nf_nat_ipv4
> nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT ipt_MASQUERADE xt_time
> xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_id
> xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_CT slhc
> nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_nat
> nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache
> nf_conntrack iptable_raw iptable_mangle iptable_fWed Jun 15 04:24:09
> 2016 kern.warn kernel: [  694.027758] CPU: 0 PID: 3 Comm: ksoftirqd/0
> Not tainted 4.4.13 #1
> Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.028021] Hardware
> name: Qualcomm (Flattened Device Tree)
> Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.034118] [<c021fea4>]
> (unwind_backtrace) from [<c021cb0c>] (show_stack+0x10/0x14)
> Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.039497] [<c021cb0c>]
> (show_stack) from [<c03a18e8>] (dump_stack+0x88/0x9c)
> Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.047482] [<c03a18e8>]
> (dump_stack) from [<c0227a4c>] (warn_slowpath_common+0x94/0xb0)
> Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.054510] [<c0227a4c>]
> (warn_slowpath_common) from [<c0227a98>] (warn_slowpath_fmt+0x30/0x40)
> Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.062759] [<c0227a98>]
> (warn_slowpath_fmt) from [<c04c50a8>] (skb_warn_bad_offload+0xe4/0xf8)
> Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.071179] [<c04c50a8>]
> (skb_warn_bad_offload) from [<c04c95e0>] (__skb_gso_segment+0x4c/0xd0)
> Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.079858] [<c04c95e0>]
> (__skb_gso_segment) from [<c04fb00c>] (ip_finish_output+0x12c/0x1fc)
> Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.088536] [<c04fb00c>]
> (ip_finish_output) from [<c04fb994>] (ip_output+0x4c/0xb8)
> Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.097223] [<c04fb994>]
> (ip_output) from [<c04f84ac>] (ip_forward+0x278/0x38c)
> Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.104680] [<c04f84ac>]
> (ip_forward) from [<c04f7138>] (ip_rcv+0x244/0x2cc)
> Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.111971] [<c04f7138>]
> (ip_rcv) from [<c04c59ec>] (__netif_receive_skb_core+0x640/0x7a4)
> Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.119265] [<c04c59ec>]
> (__netif_receive_skb_core) from [<c04c82f4>]
> (process_backlog+0x9c/0x134)
> Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.127340] [<c04c82f4>]
> (process_backlog) from [<c04c7a5c>] (net_rx_action+0x120/0x2c8)
> Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.136282] [<c04c7a5c>]
> (net_rx_action) from [<c022b2c0>] (__do_softirq+0xe0/0x21c)
> Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.144529] [<c022b2c0>]
> (__do_softirq) from [<c022b420>] (run_ksoftirqd+0x24/0x44)
> Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.152255] [<c022b420>]
> (run_ksoftirqd) from [<c0243fcc>] (smpboot_thread_fn+0x24c/0x288)
> Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.159638] [<c0243fcc>]
> (smpboot_thread_fn) from [<c0241540>] (kthread+0xf0/0xf8)
> Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.167966] [<c0241540>]
> (kthread) from [<c0209cb8>] (ret_from_fork+0x14/0x3c)
> Wed Jun 15 04:24:09 2016 kern.warn kernel: [  694.175575] ---[ end
> trace 26d6bdf0ce98e93b ]---
> Wed Jun 15 04:24:14 2016 kern.alert kernel: [  694.182754] Unable to
> handle kernel paging request at virtual address e20fe366
> Wed Jun 15 04:24:14 2016 kern.alert kernel: [  694.187486] pgd = da464000
> Wed Jun 15 04:24:14 2016 kern.alert kernel: [  694.194510] [e20fe366]
> *pgd=00000000
> Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.200587] Internal
> error: Oops: 5 [#1] PREEMPT SMP ARM
> Wed Jun 15 04:24:14 2016 kern.warn kernel: [  694.200853] Modules
> linked in: pppoe ppp_async iptable_nat pppox ppp_generic nf_nat_ipv4
> nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT ipt_MASQUERADE xt_time
> xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_id
> xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_CT slhc
> nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_nat
> nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache
> nf_conntrack iptable_raw iptable_mangle iptable_fWed Jun 15 04:24:14
> 2016 kern.warn kernel: [  694.285396] CPU: 0 PID: 3 Comm: ksoftirqd/0
> Tainted: G        W       4.4.13 #1
> Wed Jun 15 04:24:14 2016 kern.warn kernel: [  694.285663] Hardware
> name: Qualcomm (Flattened Device Tree)
> Wed Jun 15 04:24:14 2016 kern.warn kernel: [  694.292779] task:
> dd448880 ti: dd456000 task.ti: dd456000
> Wed Jun 15 04:24:14 2016 kern.warn kernel: [  694.298340] PC is at
> put_page+0x0/0x5c
> Wed Jun 15 04:24:14 2016 kern.warn kernel: [  694.303894] LR is at
> skb_release_data+0x6c/0xd4
> Wed Jun 15 04:24:14 2016 kern.warn kernel: [  694.307536] pc :
> [<c02a6898>]    lr : [<c04b9434>]    psr: 80000013
> Wed Jun 15 04:24:14 2016 kern.warn kernel: [  694.307536] sp :
> dd457d40  ip : 00000000  fp : c07736b0
> Wed Jun 15 04:24:14 2016 kern.warn kernel: [  694.311972] r10:
> da983bf0  r9 : dd41405c  r8 : ffffffea
> Wed Jun 15 04:24:14 2016 kern.warn kernel: [  694.323420] r7 :
> da983b40  r6 : d9d436c0  r5 : d9d436f0  r4 : 00000001
> Wed Jun 15 04:24:14 2016 kern.warn kernel: [  694.328631] r3 :
> 000000f4  r2 : 00000000  r1 : 00000000  r0 : e20fe366
> Wed Jun 15 04:24:14 2016 kern.warn kernel: [  694.335230] Flags: Nzcv
> IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
> Wed Jun 15 04:24:14 2016 kern.warn kernel: [  694.341740] Control:
> 10c5787d  Table: 5c46406a  DAC: 00000051
> Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.348942] Process
> ksoftirqd/0 (pid: 3, stack limit = 0xdd456210)
> Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.354672] Stack:
> (0xdd457d40 to 0xdd458000)
> Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.360757] 7d40:
> da983b40 000005dc c07a69c0 00000000 ffffffea c04b952c da983b40
> c04fb0b8
> Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.365189] 7d60:
> 00000001 c04f0f9c da983b40 c07a69c0 00000000 d9d43090 00000008
> dd41405c
> Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.373351] 7d80:
> da983bf0 c04fb994 da983b40 00000004 80000000 dd457d02 00000000
> dc909000
> Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.381509] 7da0:
> 00000000 c07a69c0 c07a6f5c c04faee0 da983b40 dd414000 c07a69c0
> c04f84ac
> Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.389669] 7dc0:
> bf280284 00000002 80000000 dd457e02 dd414000 dc909000 00000000
> c07a69c0
> Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.397830] 7de0:
> c07a6f4c c04f81e8 da983b40 dd414000 d9d43090 dd414000 00000008
> c04f7138
> Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.405989] 7e00:
> 05eb0404 00000000 80000000 c04c5a02 dd414000 00000000 00000000
> c07a69c0
> Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.414147] 7e20:
> c07a6f3c c04f6af4 da983b40 c077486c c04f6ef4 c04c59ec c0772100
> 00000000
> Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.422306] 7e40:
> 00000001 00002f54 ddc1e840 da983b40 00000001 da983b40 ddc138b8
> 00000002
> Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.430468] 7e60:
> ddc13848 00000000 00000001 00000040 ddc138a4 c04c82f4 00000001
> ddc138b0
> Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.438629] 7e80:
> c0772100 ddc138b8 00000001 00000040 0000012c 000099df c076e840
> dd457ec0
> Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.446787] 7ea0:
> c0772100 c04c7a5c 00000003 1d4a5000 ddc13840 c077680c c07736b0
> c07736b0
> Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.454947] 7ec0:
> dd415600 dd414600 dd457ec8 dd457ec8 dca8cd98 00000000 00000003
> c077208c
> Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.463107] 7ee0:
> c0772080 40000003 dd456000 00000100 c0772080 c022b2c0 c0776d48
> ddc12e40
> Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.471265] 7f00:
> dd457ef8 c07ae8c0 00000004 000099de c0772100 04208040 dd404d00
> dd456000
> Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.479424] 7f20:
> dd404d00 00000000 00000001 c0778374 00000002 00000000 00000000
> c022b420
> Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.487584] 7f40:
> dd456000 c0243fcc 00000000 dd404d40 dd404d00 c0243d80 00000000
> 00000000
> Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.495745] 7f60:
> 00000000 c0241540 10106041 00000001 00000000 dd404d00 00000000
> 00030003
> Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.503907] 7f80:
> dd457f80 dd457f80 00000000 00000000 dd457f90 dd457f90 dd457fac
> dd404d40
> Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.512064] 7fa0:
> c0241450 00000000 00000000 c0209cb8 00000000 00000000 00000000
> 00000000
> Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.520223] 7fc0:
> 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 00000000
> Wed Jun 15 04:24:14 2016 kern.emerg kernel: [  694.528384] 7fe0:
> 00000000 00000000 00000000 00000000 00000013 00000000 90000018
> 41070000
> Wed Jun 15 04:24:14 2016 kern.warn kernel: [  694.536545] [<c02a6898>]
> (put_page) from [<c04b9434>] (skb_release_data+0x6c/0xd4)
> Wed Jun 15 04:24:14 2016 kern.warn kernel: [  694.544698] [<c04b9434>]
> (skb_release_data) from [<c04b952c>] (kfree_skb+0x54/0x60)
> Wed Jun 15 04:24:14 2016 kern.warn kernel: [  694.552162] [<c04b952c>]
> (kfree_skb) from [<c04fb0b8>] (ip_finish_output+0x1d8/0x1fc)
> Wed Jun 15 04:24:14 2016 kern.warn kernel: [  694.559715] [<c04fb0b8>]
> (ip_finish_output) from [<c04fb994>] (ip_output+0x4c/0xb8)
> Wed Jun 15 04:24:14 2016 kern.warn kernel: [  694.567708] [<c04fb994>]
> (ip_output) from [<c04f84ac>] (ip_forward+0x278/0x38c)
-------------- next part --------------
Thu Jun 16 20:43:19 2016 kern.alert kernel: [ 3010.792756] Unable to handle kernel paging request at virtual address aa24bb10
Thu Jun 16 20:43:19 2016 kern.alert kernel: [ 3010.792787] pgd = c0204000
Thu Jun 16 20:43:19 2016 kern.alert kernel: [ 3010.798878] [aa24bb10] *pgd=00000000
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3010.805024] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3010.805203] Modules linked in: pppoe ppp_async iptable_nat pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT ipt_MASQUERADE xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_id xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_CT slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack iptable_raw iptable_mangle iptable_fThu Jun 16 20:43:19 2016 kern.warn kernel: [ 3010.889747] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G        W       4.4.13 #1
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3010.890014] Hardware name: Qualcomm (Flattened Device Tree)
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3010.897132] task: dd44aec0 ti: dd470000 task.ti: dd470000
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3010.902519] PC is at kmap_atomic+0x2c/0x158
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3010.908066] LR is at kmap_atomic+0x10/0x158
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3010.912060] pc : [<c0224310>]    lr : [<c02242f4>]    psr: 80000113
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3010.912060] sp : dd471df0  ip : 00000000  fp : 02080020
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3010.916236] r10: 00000005  r9 : dd41405c  r8 : da834cc0
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3010.927687] r7 : ddfc1c00  r6 : 00000001  r5 : d8dbaf80  r4 : aa24bb10
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3010.932894] r3 : 00000001  r2 : dd44aec0  r1 : 00000000  r0 : 00000001
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3010.939494] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3010.946004] Control: 10c5787d  Table: 5c47c06a  DAC: 00000051
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3010.953207] Process swapper/1 (pid: 0, stack limit = 0xdd470210)
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3010.958937] Stack: (0xdd471df0 to 0xdd472000)
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3010.965018] 1de0:                                     00000000 d8dbaf80 00000001 ddfc1c00
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3010.969282] 1e00: da834cc0 c04b74cc 00000001 5af7e97e dd414000 da834cc0 c077486c dd414048
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3010.977440] 1e20: dd414000 00000008 dd41405c da834d70 c07736b0 c04c59c8 dd471e38 00000000
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3010.985601] 1e40: c076de40 dd41e900 00000001 da834cc0 00000000 da834cc0 ddc1e8b8 0000000c
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3010.993759] 1e60: ddc1e848 00000000 00000001 00000040 ddc1e8a4 c04c82f4 dd4499c8 ddc1e8b0
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3011.001922] 1e80: dd4499c8 ddc1e8b8 00000001 00000040 0000012c 000422e2 c076e840 dd471ec0
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3011.010078] 1ea0: c0772100 c04c7a5c c0772088 1d4b0000 ddc1e840 c077680c c07736b0 c07736b0
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3011.018239] 1ec0: dd471ec0 dd471ec0 dd471ec8 dd471ec8 dd44b184 00000000 00000003 c077208c
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3011.026399] 1ee0: c0772080 40000003 dd470000 00000101 c0772080 c022b2c0 ddc1bde0 00000000
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3011.034559] 1f00: dd471ef8 c07ae8c0 0000000a 000422e1 c0772100 00200040 ddc1e840 c076c268
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3011.042717] 1f20: 00000001 00000004 00000000 c076c268 dd471f88 dd471fe0 c0772488 c022b68c
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3011.050879] 1f40: c076c268 c021f1a0 c077ee70 c0772f54 de80200c dd471f88 de802000 de803000
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3011.059037] 1f60: dd471fe0 c020943c c0219d58 60000013 ffffffff dd471fbc 00000000 c076b2e4
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3011.067199] 1f80: dd471fe0 c020a594 00000001 00000000 00000000 c020b4a0 dd470000 c0772480
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3011.075358] 1fa0: c067da5c 00000000 00000000 c076b2e4 dd471fe0 c0772488 c0772140 dd471fd8
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3011.083519] 1fc0: c0219d54 c0219d58 60000013 ffffffff 00000051 00000000 dd470000 c025c95c
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3011.091680] 1fe0: c076d310 c077670f 5f45806a c07ae2e0 00000000 422094ec 92202202 a6803404
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3011.099839] [<c0224310>] (kmap_atomic) from [<c04b74cc>] (skb_copy_ubufs+0x68/0x158)
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3011.107997] [<c04b74cc>] (skb_copy_ubufs) from [<c04c59c8>] (__netif_receive_skb_core+0x61c/0x7a4)
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3011.115808] [<c04c59c8>] (__netif_receive_skb_core) from [<c04c82f4>] (process_backlog+0x9c/0x134)
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3011.124572] [<c04c82f4>] (process_backlog) from [<c04c7a5c>] (net_rx_action+0x120/0x2c8)
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3011.133516] [<c04c7a5c>] (net_rx_action) from [<c022b2c0>] (__do_softirq+0xe0/0x21c)
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3011.141762] [<c022b2c0>] (__do_softirq) from [<c022b68c>] (irq_exit+0x98/0xec)
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3011.149489] [<c022b68c>] (irq_exit) from [<c021f1a0>] (handle_IPI+0xdc/0x1c0)
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3011.156516] [<c021f1a0>] (handle_IPI) from [<c020943c>] (gic_handle_irq+0x80/0x94)
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3011.163720] [<c020943c>] (gic_handle_irq) from [<c020a594>] (__irq_svc+0x54/0x90)
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3011.171178] Exception stack(0xdd471f88 to 0xdd471fd0)
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3011.178736] 1f80:                   00000001 00000000 00000000 c020b4a0 dd470000 c0772480
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3011.183776] 1fa0: c067da5c 00000000 00000000 c076b2e4 dd471fe0 c0772488 c0772140 dd471fd8
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3011.191930] 1fc0: c0219d54 c0219d58 60000013 ffffffff
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3011.200088] [<c020a594>] (__irq_svc) from [<c0219d58>] (arch_cpu_idle+0x34/0x50)
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3011.205129] [<c0219d58>] (arch_cpu_idle) from [<c025c95c>] (cpu_startup_entry+0x178/0x24c)
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3011.212592] [<c025c95c>] (cpu_startup_entry) from [<422094ec>] (0x422094ec)
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3011.220666] Code: e593200c e59233f8 e2833001 e58233f8 (e5943000) 
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3011.227601] ---[ end trace 032deba5e46749ed ]---

From joshbendavid at gmail.com  Thu Jun 16 11:50:42 2016
From: joshbendavid at gmail.com (Josh Bendavid)
Date: Thu, 16 Jun 2016 20:50:42 +0200
Subject: [LEDE-DEV] skb_warn_bad_offload + crash at high load on ipq806x
In-Reply-To: <CAD1MEwd_p2C2Eum7py1R8hzCyExYwxM+_CZX_PA8bDYgYvRFWQ@mail.gmail.com>
References: <CAD1MEwdz99Sjq66u+nsy+kmtAxPPPKnSR0fh3_h06CnKibZfww@mail.gmail.com>
 <CAD1MEwd_p2C2Eum7py1R8hzCyExYwxM+_CZX_PA8bDYgYvRFWQ@mail.gmail.com>
Message-ID: <CAD1MEwcXWj_Da-dRCuCAwGYVueLroYpzH=8LSCa4A=NuCLe+_w@mail.gmail.com>

Sorry for top-posting.

The second stack trace is this one in case the previous mail is too
hard to read:
-------------- next part --------------
Thu Jun 16 20:43:19 2016 kern.alert kernel: [ 3010.792756] Unable to handle kernel paging request at virtual address aa24bb10
Thu Jun 16 20:43:19 2016 kern.alert kernel: [ 3010.792787] pgd = c0204000
Thu Jun 16 20:43:19 2016 kern.alert kernel: [ 3010.798878] [aa24bb10] *pgd=00000000
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3010.805024] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3010.805203] Modules linked in: pppoe ppp_async iptable_nat pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT ipt_MASQUERADE xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_id xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_CT slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack iptable_raw iptable_mangle iptable_fThu Jun 16 20:43:19 2016 kern.warn kernel: [ 3010.889747] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G        W       4.4.13 #1
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3010.890014] Hardware name: Qualcomm (Flattened Device Tree)
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3010.897132] task: dd44aec0 ti: dd470000 task.ti: dd470000
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3010.902519] PC is at kmap_atomic+0x2c/0x158
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3010.908066] LR is at kmap_atomic+0x10/0x158
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3010.912060] pc : [<c0224310>]    lr : [<c02242f4>]    psr: 80000113
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3010.912060] sp : dd471df0  ip : 00000000  fp : 02080020
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3010.916236] r10: 00000005  r9 : dd41405c  r8 : da834cc0
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3010.927687] r7 : ddfc1c00  r6 : 00000001  r5 : d8dbaf80  r4 : aa24bb10
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3010.932894] r3 : 00000001  r2 : dd44aec0  r1 : 00000000  r0 : 00000001
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3010.939494] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3010.946004] Control: 10c5787d  Table: 5c47c06a  DAC: 00000051
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3010.953207] Process swapper/1 (pid: 0, stack limit = 0xdd470210)
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3010.958937] Stack: (0xdd471df0 to 0xdd472000)
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3010.965018] 1de0:                                     00000000 d8dbaf80 00000001 ddfc1c00
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3010.969282] 1e00: da834cc0 c04b74cc 00000001 5af7e97e dd414000 da834cc0 c077486c dd414048
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3010.977440] 1e20: dd414000 00000008 dd41405c da834d70 c07736b0 c04c59c8 dd471e38 00000000
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3010.985601] 1e40: c076de40 dd41e900 00000001 da834cc0 00000000 da834cc0 ddc1e8b8 0000000c
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3010.993759] 1e60: ddc1e848 00000000 00000001 00000040 ddc1e8a4 c04c82f4 dd4499c8 ddc1e8b0
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3011.001922] 1e80: dd4499c8 ddc1e8b8 00000001 00000040 0000012c 000422e2 c076e840 dd471ec0
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3011.010078] 1ea0: c0772100 c04c7a5c c0772088 1d4b0000 ddc1e840 c077680c c07736b0 c07736b0
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3011.018239] 1ec0: dd471ec0 dd471ec0 dd471ec8 dd471ec8 dd44b184 00000000 00000003 c077208c
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3011.026399] 1ee0: c0772080 40000003 dd470000 00000101 c0772080 c022b2c0 ddc1bde0 00000000
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3011.034559] 1f00: dd471ef8 c07ae8c0 0000000a 000422e1 c0772100 00200040 ddc1e840 c076c268
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3011.042717] 1f20: 00000001 00000004 00000000 c076c268 dd471f88 dd471fe0 c0772488 c022b68c
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3011.050879] 1f40: c076c268 c021f1a0 c077ee70 c0772f54 de80200c dd471f88 de802000 de803000
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3011.059037] 1f60: dd471fe0 c020943c c0219d58 60000013 ffffffff dd471fbc 00000000 c076b2e4
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3011.067199] 1f80: dd471fe0 c020a594 00000001 00000000 00000000 c020b4a0 dd470000 c0772480
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3011.075358] 1fa0: c067da5c 00000000 00000000 c076b2e4 dd471fe0 c0772488 c0772140 dd471fd8
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3011.083519] 1fc0: c0219d54 c0219d58 60000013 ffffffff 00000051 00000000 dd470000 c025c95c
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3011.091680] 1fe0: c076d310 c077670f 5f45806a c07ae2e0 00000000 422094ec 92202202 a6803404
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3011.099839] [<c0224310>] (kmap_atomic) from [<c04b74cc>] (skb_copy_ubufs+0x68/0x158)
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3011.107997] [<c04b74cc>] (skb_copy_ubufs) from [<c04c59c8>] (__netif_receive_skb_core+0x61c/0x7a4)
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3011.115808] [<c04c59c8>] (__netif_receive_skb_core) from [<c04c82f4>] (process_backlog+0x9c/0x134)
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3011.124572] [<c04c82f4>] (process_backlog) from [<c04c7a5c>] (net_rx_action+0x120/0x2c8)
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3011.133516] [<c04c7a5c>] (net_rx_action) from [<c022b2c0>] (__do_softirq+0xe0/0x21c)
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3011.141762] [<c022b2c0>] (__do_softirq) from [<c022b68c>] (irq_exit+0x98/0xec)
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3011.149489] [<c022b68c>] (irq_exit) from [<c021f1a0>] (handle_IPI+0xdc/0x1c0)
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3011.156516] [<c021f1a0>] (handle_IPI) from [<c020943c>] (gic_handle_irq+0x80/0x94)
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3011.163720] [<c020943c>] (gic_handle_irq) from [<c020a594>] (__irq_svc+0x54/0x90)
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3011.171178] Exception stack(0xdd471f88 to 0xdd471fd0)
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3011.178736] 1f80:                   00000001 00000000 00000000 c020b4a0 dd470000 c0772480
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3011.183776] 1fa0: c067da5c 00000000 00000000 c076b2e4 dd471fe0 c0772488 c0772140 dd471fd8
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3011.191930] 1fc0: c0219d54 c0219d58 60000013 ffffffff
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3011.200088] [<c020a594>] (__irq_svc) from [<c0219d58>] (arch_cpu_idle+0x34/0x50)
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3011.205129] [<c0219d58>] (arch_cpu_idle) from [<c025c95c>] (cpu_startup_entry+0x178/0x24c)
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3011.212592] [<c025c95c>] (cpu_startup_entry) from [<422094ec>] (0x422094ec)
Thu Jun 16 20:43:19 2016 kern.emerg kernel: [ 3011.220666] Code: e593200c e59233f8 e2833001 e58233f8 (e5943000) 
Thu Jun 16 20:43:19 2016 kern.warn kernel: [ 3011.227601] ---[ end trace 032deba5e46749ed ]---

From adron at yapic.net  Thu Jun 16 12:04:51 2016
From: adron at yapic.net (adron at yapic.net)
Date: Thu, 16 Jun 2016 22:04:51 +0300
Subject: [LEDE-DEV] [PATCH] build: Adds the ability to disable personal
	initramfs build for target device
Message-ID: <1466103891-30447-1-git-send-email-adron@yapic.net>

From: Sergey Sergeev <adron at yapic.net>

 If KERNEL_INITRAMFS := in the target/linux/*/image/Makefile->Device/%NAME% section is set to ''
 then personal initramfs file for this target device will not be created.
 This var is similar to the Device/Build/kernel KERNEL_INSTALL :=

Signed-off-by: Sergey Sergeev <adron at yapic.net>
---
 include/image.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/image.mk b/include/image.mk
index f8291f4..3a27a40 100644
--- a/include/image.mk
+++ b/include/image.mk
@@ -351,7 +351,7 @@ endef
 ifndef IB
 define Device/Build/initramfs
   $(call Device/Export,$(KDIR)/tmp/$$(KERNEL_INITRAMFS_IMAGE),$(1))
-  $$(_TARGET): $(BIN_DIR)/$$(KERNEL_INITRAMFS_IMAGE)
+  $$(_TARGET): $$(if $$(KERNEL_INITRAMFS),$(BIN_DIR)/$$(KERNEL_INITRAMFS_IMAGE))
 
   $(KDIR)/$$(KERNEL_INITRAMFS_NAME):: image_prepare
   $(BIN_DIR)/$$(KERNEL_INITRAMFS_IMAGE): $(KDIR)/tmp/$$(KERNEL_INITRAMFS_IMAGE)
-- 
1.9.1



From joshbendavid at gmail.com  Thu Jun 16 12:12:49 2016
From: joshbendavid at gmail.com (Josh Bendavid)
Date: Thu, 16 Jun 2016 21:12:49 +0200
Subject: [LEDE-DEV] skb_warn_bad_offload + crash at high load on ipq806x
In-Reply-To: <CAD1MEwcXWj_Da-dRCuCAwGYVueLroYpzH=8LSCa4A=NuCLe+_w@mail.gmail.com>
References: <CAD1MEwdz99Sjq66u+nsy+kmtAxPPPKnSR0fh3_h06CnKibZfww@mail.gmail.com>
 <CAD1MEwd_p2C2Eum7py1R8hzCyExYwxM+_CZX_PA8bDYgYvRFWQ@mail.gmail.com>
 <CAD1MEwcXWj_Da-dRCuCAwGYVueLroYpzH=8LSCa4A=NuCLe+_w@mail.gmail.com>
Message-ID: <CAD1MEwcCXoEaesHnDV8u7e0NT_Wvw7S0WJgOrVjXZPGp7Q08cw@mail.gmail.com>

This seems vaguely similar to
http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/25030/focus=25031

Was there ever a resolution/understanding of that for brcm47xx?


From nbd at nbd.name  Thu Jun 16 12:15:21 2016
From: nbd at nbd.name (Felix Fietkau)
Date: Thu, 16 Jun 2016 21:15:21 +0200
Subject: [LEDE-DEV] [PATCH] build: Adds the ability to disable personal
 initramfs build for target device
In-Reply-To: <1466103891-30447-1-git-send-email-adron@yapic.net>
References: <1466103891-30447-1-git-send-email-adron@yapic.net>
Message-ID: <f2d9b8b4-d6d4-513b-54a8-9682393ecae1@nbd.name>

On 2016-06-16 21:04, adron at yapic.net wrote:
> From: Sergey Sergeev <adron at yapic.net>
> 
>  If KERNEL_INITRAMFS := in the target/linux/*/image/Makefile->Device/%NAME% section is set to ''
>  then personal initramfs file for this target device will not be created.
>  This var is similar to the Device/Build/kernel KERNEL_INSTALL :=
> 
> Signed-off-by: Sergey Sergeev <adron at yapic.net>
What devices do you need to disable initramfs for, and why?

- Felix



From adron at yapic.net  Thu Jun 16 12:59:27 2016
From: adron at yapic.net (=?UTF-8?B?0KHQtdGA0LPQtdC10LIg0KHQtdGA0LPQtdC5?=)
Date: Thu, 16 Jun 2016 22:59:27 +0300
Subject: [LEDE-DEV] [PATCH] build: Adds the ability to disable personal
 initramfs build for target device
In-Reply-To: <f2d9b8b4-d6d4-513b-54a8-9682393ecae1@nbd.name>
References: <1466103891-30447-1-git-send-email-adron@yapic.net>
 <f2d9b8b4-d6d4-513b-54a8-9682393ecae1@nbd.name>
Message-ID: <5763051F.7060109@yapic.net>

16.06.2016 22:15, Felix Fietkau ?????:
> On 2016-06-16 21:04, adron at yapic.net wrote:
>> From: Sergey Sergeev <adron at yapic.net>
>>
>>   If KERNEL_INITRAMFS := in the target/linux/*/image/Makefile->Device/%NAME% section is set to ''
>>   then personal initramfs file for this target device will not be created.
>>   This var is similar to the Device/Build/kernel KERNEL_INSTALL :=
>>
>> Signed-off-by: Sergey Sergeev <adron at yapic.net>
> What devices do you need to disable initramfs for, and why?
>
> - Felix
>
>
Hello. I need a Mikrotik devices.

I'm working on support for normal(ubi + jffs2 for NAND and jffs2 for 
NOR) sysupgrade system for all Mikrotiks devices.
This devices hasthree types of flash memory:
NAND flash with blocksize = 512b and oob = 16b  and ecc
   NAND flash with blocksize = 2048b and oob = 64b and ecc
   NOR flash with blocksize = 1024b and without oob and ecc.
So i create 3 type of devices:

ifeq ($(SUBTARGET),mikrotik)

define Device/rb-common
   LOADER_TYPE := elf
   KERNEL_INSTALL :=
   KERNEL = kernel-bin | lzma | loader-kernel | kernel2minor 
$$(KERNEL2MINOR_ARGS)
   KERNEL_INITRAMFS := kernel-bin | lzma | loader-kernel
   IMAGES := sysupgrade.bin
   IMAGE/sysupgrade.bin = append-rootfs | pad-rootfs | combined-image | 
check-size $$$$(IMAGE_SIZE)
endef

define Device/NOR
$(Device/rb-common)
   DEVICE_PROFILE := MikrotikDefault MikrotikNorFlash
   BLOCKSIZE := 64k
   IMAGE_SIZE := 16000k
   KERNEL2MINOR_ARGS := -s 1024 -i 0 -p NOR01024 -e
endef
TARGET_DEVICES += NOR

define Device/NAND-2048b
$(Device/rb-common)
   DEVICE_PROFILE := MikrotikDefault MikrotikNorFlash
   BLOCKSIZE := 128k
   IMAGE_SIZE := 32000k
   KERNEL2MINOR_ARGS := -s 2048 -i 65536 -p NND02048 -e -c
endef
TARGET_DEVICES += NAND-2048b

define Device/NAND-512b
$(Device/rb-common)
   DEVICE_PROFILE := MikrotikDefault MikrotikNorFlash
   BLOCKSIZE := 16k
   IMAGE_SIZE := 32000k
   KERNEL2MINOR_ARGS := -s 512 -i 65536 -p NND00512 -e -c
endef
TARGET_DEVICES += NAND-512b

endif # ifeq ($(SUBTARGET),mikrotik)

and after do make I get the following files:
cat ./bin/ar71xx/md5sums
1f5415c6fa8c9ac86ca04ab8d2bb7eaa 
*openwrt-ar71xx-mikrotik-vmlinux-initramfs.bin
74d5315b86e6d6285657097cb88330f1 
*openwrt-ar71xx-mikrotik-vmlinux-initramfs.lzma
8426e37778fb487839553a66f3a5e760 
*openwrt-ar71xx-mikrotik-vmlinux-initramfs.elf
a3d42d184fa59780fda2517062007064 
*openwrt-ar71xx-mikrotik-NAND-2048b-initramfs-kernel.bin
a3d42d184fa59780fda2517062007064 
*openwrt-ar71xx-mikrotik-NAND-512b-initramfs-kernel.bin
a3d42d184fa59780fda2517062007064 
*openwrt-ar71xx-mikrotik-NOR-initramfs-kernel.bin
a3d42d184fa59780fda2517062007064 
*openwrt-ar71xx-mikrotik-vmlinux-initramfs-lzma.elf
a518ab1349dd193f84ff3e00399ba4ce 
*openwrt-ar71xx-mikrotik-vmlinux-initramfs.gz
a9ec346db00358038ed02d2c6759776d 
*openwrt-ar71xx-mikrotik-NOR-squashfs-sysupgrade.bin
adb5078c694fe049d773c6d2c46e4b62 
*openwrt-ar71xx-mikrotik-NAND-512b-squashfs-sysupgrade.bin
b2b003c9ade18a24e64d12de4d6396b2 
*openwrt-ar71xx-mikrotik-NAND-2048b-squashfs-sysupgrade.bin
...

As you can see we have 4identicalfiles:
openwrt-ar71xx-mikrotik-NAND-2048b-initramfs-kernel.bin,
penwrt-ar71xx-mikrotik-NAND-512b-initramfs-kernel.bin,
openwrt-ar71xx-mikrotik-NOR-initramfs-kernel.bin,
openwrt-ar71xx-mikrotik-vmlinux-initramfs-lzma.elf
So i want to use KERNEL_INITRAMFS := and leave only one initramfs 
file(openwrt-ar71xx-mikrotik-vmlinux-initramfs-lzma.elf) and three 
sysupgrade files.




From lynxis at fe80.eu  Thu Jun 16 22:49:55 2016
From: lynxis at fe80.eu (Alexander Couzens)
Date: Thu, 16 Jun 2016 22:49:55 -0700
Subject: [LEDE-DEV] calib table can damage some cpe510's
Message-ID: <20160616224955.5176ccf7@lazus.yip>

Hi,

it turned out the second calibration table (high power) could
damage some devices within the rf part. Even it was tested on hardware,
I guess it depends on the hardware revision *and* the used frequency.

It means that we have to use the gravelly bumpy way to fix the txgain
and patching the tx gain table for this particular device.

The calibration table patch bf27ac019c137e7baf90ca6ef0e40945ae871797
got reverted.

Best,
lynxis
-- 
Alexander Couzens

mail: lynxis at fe80.eu
jabber: lynxis at fe80.eu
mobile: +4915123277221
gpg: 390D CF78 8BF9 AA50 4F8F  F1E2 C29E 9DA6 A0DF 8604
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20160616/2457113c/attachment.sig>

From john at phrozen.org  Fri Jun 17 00:05:37 2016
From: john at phrozen.org (John Crispin)
Date: Fri, 17 Jun 2016 09:05:37 +0200
Subject: [LEDE-DEV] ralink i2c / i2s update
Message-ID: <b6ce3aba-d18a-e054-d788-28dff7485fdf@phrozen.org>

Hi Michael,

i have been testing the update on real HW and at least the I2C update
breaks the i2c bus on mt7620 and mt7621. i will see if i can find the cause.

if i cant find out the cause i would have to revert
d8202a84096831d4e6e2a522476bd6a0d46e6413. could you also look into this
? the mqmaker witi board for example fails to talk to its RTC with the
i2c update patch applied.

	John


From yszhou4tech at gmail.com  Fri Jun 17 01:10:37 2016
From: yszhou4tech at gmail.com (Yousong Zhou)
Date: Fri, 17 Jun 2016 16:10:37 +0800
Subject: [LEDE-DEV] ar71xx kernel size starts getting oversized
In-Reply-To: <CAECwjAi_6yZQevUOKB=A=___8gQnG3dELahEvDjvXysKGNNNPA@mail.gmail.com>
References: <CAECwjAi_6yZQevUOKB=A=___8gQnG3dELahEvDjvXysKGNNNPA@mail.gmail.com>
Message-ID: <CAECwjAikcwVAV2DH8r6b3JLwx=wX0jcFDSxQiProxRK0ZhUO0w@mail.gmail.com>

On 4 June 2016 at 12:49, Yousong Zhou <yszhou4tech at gmail.com> wrote:
> Several days ago I tried to build a firmware for HiWiFi-HC6361 with
> LEDE master branch.  Yet the firmware was not present in
> bin/targets/ar71xx/generic after the build completed.  I checked the
> downloads.lede-project.org the firmware was also missing there.
>
> The problem is that mtdparts layout of HC6361 requires the kernel part
> to be not bigger than 1280KB (1310720 bytes).  Yet the lzma-compressed
> kernel uImage has exceeded this size limit.
>
> The current size of lede-ar71xx-generic-uImage-lzma.bin in
> downloads.lede-project.org is 1367988
>
> The corresponding file in OpenWrt downloads site are as follows
>
>     snapshot         1295637
>     15.05.1            1176662
>     14.07               1107048
>
> My device is currently running 4.1.16 with OpenWrt r48975.  So the
> bloat probably comes from the 4.4 bump.  Sorry that at the moment I
> can just bring the issue up and cannot find time to do further
> investigation.

Comparing config-4.1 before the bump with config-4.4, and config-3.10
from bb branch and config-4.4, it seems that the size increase
probably comes from Open Firmware device tree support recently
introduced to ath79 mach  :(

                yousong

>
> Regards
>
>                 yousong


From john at phrozen.org  Fri Jun 17 01:28:11 2016
From: john at phrozen.org (John Crispin)
Date: Fri, 17 Jun 2016 10:28:11 +0200
Subject: [LEDE-DEV] ar71xx kernel size starts getting oversized
In-Reply-To: <CAECwjAikcwVAV2DH8r6b3JLwx=wX0jcFDSxQiProxRK0ZhUO0w@mail.gmail.com>
References: <CAECwjAi_6yZQevUOKB=A=___8gQnG3dELahEvDjvXysKGNNNPA@mail.gmail.com>
 <CAECwjAikcwVAV2DH8r6b3JLwx=wX0jcFDSxQiProxRK0ZhUO0w@mail.gmail.com>
Message-ID: <289d6d78-39b9-67b1-2de8-361741af212c@phrozen.org>



On 17/06/2016 10:10, Yousong Zhou wrote:
> On 4 June 2016 at 12:49, Yousong Zhou <yszhou4tech at gmail.com> wrote:
>> Several days ago I tried to build a firmware for HiWiFi-HC6361 with
>> LEDE master branch.  Yet the firmware was not present in
>> bin/targets/ar71xx/generic after the build completed.  I checked the
>> downloads.lede-project.org the firmware was also missing there.
>>
>> The problem is that mtdparts layout of HC6361 requires the kernel part
>> to be not bigger than 1280KB (1310720 bytes).  Yet the lzma-compressed
>> kernel uImage has exceeded this size limit.
>>
>> The current size of lede-ar71xx-generic-uImage-lzma.bin in
>> downloads.lede-project.org is 1367988
>>
>> The corresponding file in OpenWrt downloads site are as follows
>>
>>     snapshot         1295637
>>     15.05.1            1176662
>>     14.07               1107048
>>
>> My device is currently running 4.1.16 with OpenWrt r48975.  So the
>> bloat probably comes from the 4.4 bump.  Sorry that at the moment I
>> can just bring the issue up and cannot find time to do further
>> investigation.
> 
> Comparing config-4.1 before the bump with config-4.4, and config-3.10
> from bb branch and config-4.4, it seems that the size increase
> probably comes from Open Firmware device tree support recently
> introduced to ath79 mach  :(
> 
>                 yousong
> 
>>
>> Regards
>>
>>                 yousong
> 

i plan to work on converting the target to full dts support after the
release. this will safe us around 25k of mach files and platform code in
the kernel

	John


> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 


From john at phrozen.org  Fri Jun 17 02:07:48 2016
From: john at phrozen.org (John Crispin)
Date: Fri, 17 Jun 2016 11:07:48 +0200
Subject: [LEDE-DEV] [PATCH] kernel: mtdsplit: calculate kernel partition
 precisely for Seama
In-Reply-To: <1465601769-8234-1-git-send-email-zajec5@gmail.com>
References: <1465601769-8234-1-git-send-email-zajec5@gmail.com>
Message-ID: <3b29df2b-0333-d313-477c-f94d0839861c@phrozen.org>



On 11/06/2016 01:36, Rafa? Mi?ecki wrote:
> So far "kernel" partition didn't contain just a kernel. It also included
> Seama header and meta data. This was making kernel update complex and it
> wasn't trivial to read kernel size.
> Fix it by making "kernel" parition contain just a kernel image.
> 
> Signed-off-by: Rafa? Mi?ecki <zajec5 at gmail.com>

looks good. i just had a look and all the ralink targets using the
header use the firmware partition for sysupgrade so it wont break that
process.

> ---
>  target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_seama.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_seama.c b/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_seama.c
> index ee0444a..9fe1311 100644
> --- a/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_seama.c
> +++ b/target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_seama.c
> @@ -79,8 +79,8 @@ static int mtdsplit_parse_seama(struct mtd_info *master,
>  		return -ENOMEM;
>  
>  	parts[0].name = KERNEL_PART_NAME;
> -	parts[0].offset = 0;
> -	parts[0].size = rootfs_offset;
> +	parts[0].offset = sizeof hdr + be16_to_cpu(hdr.metasize);
> +	parts[0].size = rootfs_offset - parts[0].offset;
>  
>  	if (type == MTDSPLIT_PART_TYPE_UBI)
>  		parts[1].name = UBI_PART_NAME;
> 


From xinglp at gmail.com  Fri Jun 17 04:19:48 2016
From: xinglp at gmail.com (xinglp)
Date: Fri, 17 Jun 2016 19:19:48 +0800
Subject: [LEDE-DEV]  [PATCH uclient] enable --post-file,
 use "Content-Length" instead of chunked encoding
Message-ID: <CAHQM780agD+6-cCQmWuHzguHYVQiKiS-xAw+R7u=a_PLvKP3Cg@mail.gmail.com>

--post-file parameter only support text file not binary file.
"Content-Length" is more compatible to the http server world.

Signed-off-by: xinglp <xinglp at gmail.com>
---
diff --git a/uclient-fetch.c b/uclient-fetch.c
index 065742e..13f2fe2 100644
--- a/uclient-fetch.c
+++ b/uclient-fetch.c
@@ -43,6 +43,7 @@

 static const char *user_agent = "uclient-fetch";
 static const char *post_data;
+static char *post_file_content;
 static struct ustream_ssl_ctx *ssl_ctx;
 static const struct ustream_ssl_ops *ssl_ops;
 static int quiet = false;
@@ -449,6 +450,7 @@ static int usage(const char *progname)
  " --password=<password> HTTP authentication password\n"
  " --user-agent|-U <str> Set HTTP user agent\n"
  " --post-data=STRING use the POST method; send STRING as the data\n"
+ " --post-file=FILE use the POST method; send contents of FILE\n"
  " --spider|-s Spider mode - only check file existence\n"
  " --timeout=N|-T N Set connect/request timeout to N seconds\n"
  " --proxy=on|off|-Y on|off Enable/disable env var configured proxy\n"
@@ -491,6 +493,30 @@ static int no_ssl(const char *progname)
  return 1;
 }

+static ssize_t load_file(const char *path, char **buf)
+{
+ int fd;
+ if ((fd = open(path, O_RDONLY)) < 0) {
+ if (!quiet)
+ fprintf(stderr, "open %s: %s\n", path, strerror(errno));
+ return -1;
+ }
+ struct stat st;
+ if (fstat(fd, &st)) {
+ if (!quiet)
+ fprintf(stderr, "fstat %s: %s\n", path, strerror(errno));
+ return -1;
+ }
+ *buf = malloc(st.st_size);
+ if(st.st_size != read(fd, *buf, st.st_size)) {
+ if (!quiet)
+ fprintf(stderr, "read size different from fstat %s\n", path);
+ return -1;
+ }
+ close(fd);
+ return st.st_size;
+}
+
 enum {
  L_NO_CHECK_CERTIFICATE,
  L_CA_CERTIFICATE,
@@ -498,6 +524,7 @@ enum {
  L_PASSWORD,
  L_USER_AGENT,
  L_POST_DATA,
+ L_POST_FILE,
  L_SPIDER,
  L_TIMEOUT,
  L_CONTINUE,
@@ -512,6 +539,7 @@ static const struct option longopts[] = {
  [L_PASSWORD] = { "password", required_argument },
  [L_USER_AGENT] = { "user-agent", required_argument },
  [L_POST_DATA] = { "post-data", required_argument },
+ [L_POST_FILE] = { "post-file", required_argument },
  [L_SPIDER] = { "spider", no_argument },
  [L_TIMEOUT] = { "timeout", required_argument },
  [L_CONTINUE] = { "continue", no_argument },
@@ -568,6 +596,11 @@ int main(int argc, char **argv)
  case L_POST_DATA:
  post_data = optarg;
  break;
+ case L_POST_FILE:
+ if(load_file(optarg, &post_file_content) < 0)
+ exit(1);
+ post_data = post_file_content;
+ break;
  case L_SPIDER:
  no_output = true;
  break;
@@ -697,5 +730,8 @@ int main(int argc, char **argv)
  if (ssl_ctx)
  ssl_ops->context_free(ssl_ctx);

+ if (post_file_content)
+ free(post_file_content);
+
  return error_ret;
 }
diff --git a/uclient-http.c b/uclient-http.c
index f0451cc..07de2d4 100644
--- a/uclient-http.c
+++ b/uclient-http.c
@@ -286,18 +286,6 @@ static void uclient_http_process_headers(struct
uclient_http *uh)
  uh->auth_type = uclient_http_update_auth_type(uh);
 }

-static bool uclient_request_supports_body(enum request_type req_type)
-{
- switch (req_type) {
- case REQ_POST:
- case REQ_PUT:
- case REQ_DELETE:
- return true;
- default:
- return false;
- }
-}
-
 static void
 uclient_http_add_auth_basic(struct uclient_http *uh)
 {
@@ -576,9 +564,6 @@ uclient_http_send_headers(struct uclient_http *uh)
  blobmsg_for_each_attr(cur, uh->headers.head, rem)
  ustream_printf(uh->us, "%s: %s\r\n", blobmsg_name(cur), (char *)
blobmsg_data(cur));

- if (uclient_request_supports_body(uh->req_type))
- ustream_printf(uh->us, "Transfer-Encoding: chunked\r\n");
-
  uclient_http_add_auth_header(uh);

  ustream_printf(uh->us, "\r\n");
@@ -984,12 +969,16 @@ uclient_http_send_data(struct uclient *cl, const
char *buf, unsigned int len)
  if (uh->state >= HTTP_STATE_REQUEST_DONE)
  return -1;

+ if (len > 0) {
+ char buf[32];
+ sprintf(buf, "%d", len);
+ uclient_http_set_header(cl, "Content-Length", buf);
+ }
+
  uclient_http_send_headers(uh);

  if (len > 0) {
- ustream_printf(uh->us, "%X\r\n", len);
  ustream_write(uh->us, buf, len, false);
- ustream_printf(uh->us, "\r\n");
  }

  return len;
@@ -1004,8 +993,6 @@ uclient_http_request_done(struct uclient *cl)
  return -1;

  uclient_http_send_headers(uh);
- if (uclient_request_supports_body(uh->req_type))
- ustream_printf(uh->us, "0\r\n\r\n");
  uh->state = HTTP_STATE_REQUEST_DONE;

  return 0;


From yszhou4tech at gmail.com  Fri Jun 17 07:57:49 2016
From: yszhou4tech at gmail.com (Yousong Zhou)
Date: Fri, 17 Jun 2016 22:57:49 +0800
Subject: [LEDE-DEV] ar71xx kernel size starts getting oversized
In-Reply-To: <289d6d78-39b9-67b1-2de8-361741af212c@phrozen.org>
References: <CAECwjAi_6yZQevUOKB=A=___8gQnG3dELahEvDjvXysKGNNNPA@mail.gmail.com>
 <CAECwjAikcwVAV2DH8r6b3JLwx=wX0jcFDSxQiProxRK0ZhUO0w@mail.gmail.com>
 <289d6d78-39b9-67b1-2de8-361741af212c@phrozen.org>
Message-ID: <CAECwjAiHhjJYfQtsJchVQhV3ZVBkJUA4h90BE_DrKPAAkoQjRw@mail.gmail.com>

                yousong


On 17 June 2016 at 16:28, John Crispin <john at phrozen.org> wrote:
>
>
> On 17/06/2016 10:10, Yousong Zhou wrote:
>> On 4 June 2016 at 12:49, Yousong Zhou <yszhou4tech at gmail.com> wrote:
>>> Several days ago I tried to build a firmware for HiWiFi-HC6361 with
>>> LEDE master branch.  Yet the firmware was not present in
>>> bin/targets/ar71xx/generic after the build completed.  I checked the
>>> downloads.lede-project.org the firmware was also missing there.
>>>
>>> The problem is that mtdparts layout of HC6361 requires the kernel part
>>> to be not bigger than 1280KB (1310720 bytes).  Yet the lzma-compressed
>>> kernel uImage has exceeded this size limit.
>>>
>>> The current size of lede-ar71xx-generic-uImage-lzma.bin in
>>> downloads.lede-project.org is 1367988
>>>
>>> The corresponding file in OpenWrt downloads site are as follows
>>>
>>>     snapshot         1295637
>>>     15.05.1            1176662
>>>     14.07               1107048
>>>
>>> My device is currently running 4.1.16 with OpenWrt r48975.  So the
>>> bloat probably comes from the 4.4 bump.  Sorry that at the moment I
>>> can just bring the issue up and cannot find time to do further
>>> investigation.
>>
>> Comparing config-4.1 before the bump with config-4.4, and config-3.10
>> from bb branch and config-4.4, it seems that the size increase
>> probably comes from Open Firmware device tree support recently
>> introduced to ath79 mach  :(
>>
>>                 yousong
>>
>>>
>>> Regards
>>>
>>>                 yousong
>>
>
> i plan to work on converting the target to full dts support after the
> release. this will safe us around 25k of mach files and platform code in
> the kernel
>
>         John

It should be possible to lift the size limit on kernel and rootfs part
with mtdsplit.  I will git it a try and see if it can catch up with
the release schedule :)

                yousong


From nbd at nbd.name  Fri Jun 17 08:31:50 2016
From: nbd at nbd.name (Felix Fietkau)
Date: Fri, 17 Jun 2016 17:31:50 +0200
Subject: [LEDE-DEV] [PATCH uclient] enable --post-file,
 use "Content-Length" instead of chunked encoding
In-Reply-To: <CAHQM780agD+6-cCQmWuHzguHYVQiKiS-xAw+R7u=a_PLvKP3Cg@mail.gmail.com>
References: <CAHQM780agD+6-cCQmWuHzguHYVQiKiS-xAw+R7u=a_PLvKP3Cg@mail.gmail.com>
Message-ID: <f724017d-138c-1709-8305-baf11e75312a@nbd.name>

On 2016-06-17 13:19, xinglp wrote:
> --post-file parameter only support text file not binary file.
> "Content-Length" is more compatible to the http server world.
Your patch cannot apply due to whitespace damage. Also, the library
supports delivering POST data in multiple calls to send_data - your
patch is breaking that completely.
If you want to support using content_length instead of chunked encoding,
please do so in an optional way that does not break the existing code.
Could you please also provide some information why you're replacing
chunked encoding with content-length? What servers do not accept this?
And why are you saying it "only support text file not binary file"?

- Felix



From joshbendavid at gmail.com  Fri Jun 17 12:42:24 2016
From: joshbendavid at gmail.com (Josh Bendavid)
Date: Fri, 17 Jun 2016 21:42:24 +0200
Subject: [LEDE-DEV] skb_warn_bad_offload + crash at high load on ipq806x
In-Reply-To: <CAD1MEwcCXoEaesHnDV8u7e0NT_Wvw7S0WJgOrVjXZPGp7Q08cw@mail.gmail.com>
References: <CAD1MEwdz99Sjq66u+nsy+kmtAxPPPKnSR0fh3_h06CnKibZfww@mail.gmail.com>
 <CAD1MEwd_p2C2Eum7py1R8hzCyExYwxM+_CZX_PA8bDYgYvRFWQ@mail.gmail.com>
 <CAD1MEwcXWj_Da-dRCuCAwGYVueLroYpzH=8LSCa4A=NuCLe+_w@mail.gmail.com>
 <CAD1MEwcCXoEaesHnDV8u7e0NT_Wvw7S0WJgOrVjXZPGp7Q08cw@mail.gmail.com>
Message-ID: <CAD1MEwdzSwCSck1QW=bviXYC+CdiKbzk_m8B6rcq-vjKAWwdPQ@mail.gmail.com>

Further update in case anyone has any ideas.

The C2600 device on which I'm testing has two ethernet adapters with
their own dedicated connection to the switch, with the default config
such that eth0 is WAN and eth1 is LAN, configured with untagged vlans
on the switch.

I've tried two alternate configurations
1) Using eth0 only as LAN and WAN using vlan tagging as on platforms
with only one ethernet interface+switch connection
2) Same as above, but using only eth1

Configuration 1) leads to similar results as the default with both
interfaces.  Configuration 2) seems rock solid.  (But will continue to
push it a bit longer.)

So it sounds like there's something not right about the
configuration/initialization of eth0 on this platform.

Since the ap148 and netgear R7500/D7800 are configured in the same
way, it might be useful if someone with one of those can try to
reproduce.

There was also some strange ethernet behaviour on the Linksys EA8500
which Adrian and I were discussing in
https://github.com/lede-project/source/pull/6 which may turn out to be
related.

Thanks,
Josh


From ash.benz at bk.ru  Fri Jun 17 14:28:10 2016
From: ash.benz at bk.ru (A. Benz)
Date: Sat, 18 Jun 2016 05:28:10 +0800
Subject: [LEDE-DEV] skb_warn_bad_offload + crash at high load on ipq806x
In-Reply-To: <CAD1MEwdzSwCSck1QW=bviXYC+CdiKbzk_m8B6rcq-vjKAWwdPQ@mail.gmail.com>
References: <CAD1MEwdz99Sjq66u+nsy+kmtAxPPPKnSR0fh3_h06CnKibZfww@mail.gmail.com>
 <CAD1MEwd_p2C2Eum7py1R8hzCyExYwxM+_CZX_PA8bDYgYvRFWQ@mail.gmail.com>
 <CAD1MEwcXWj_Da-dRCuCAwGYVueLroYpzH=8LSCa4A=NuCLe+_w@mail.gmail.com>
 <CAD1MEwcCXoEaesHnDV8u7e0NT_Wvw7S0WJgOrVjXZPGp7Q08cw@mail.gmail.com>
 <CAD1MEwdzSwCSck1QW=bviXYC+CdiKbzk_m8B6rcq-vjKAWwdPQ@mail.gmail.com>
Message-ID: <dc49356d-6355-b793-81e2-e9e97d5535f7@bk.ru>

Nice find. I will test on my C2600 as well.

Can you show the switch part of your network config?

Thanks.

Regards,
A. Benz

On 06/18/16 03:42, Josh Bendavid wrote:
> Further update in case anyone has any ideas.
>
> The C2600 device on which I'm testing has two ethernet adapters with
> their own dedicated connection to the switch, with the default config
> such that eth0 is WAN and eth1 is LAN, configured with untagged vlans
> on the switch.
>
> I've tried two alternate configurations
> 1) Using eth0 only as LAN and WAN using vlan tagging as on platforms
> with only one ethernet interface+switch connection
> 2) Same as above, but using only eth1
>
> Configuration 1) leads to similar results as the default with both
> interfaces.  Configuration 2) seems rock solid.  (But will continue to
> push it a bit longer.)
>
> So it sounds like there's something not right about the
> configuration/initialization of eth0 on this platform.
>
> Since the ap148 and netgear R7500/D7800 are configured in the same
> way, it might be useful if someone with one of those can try to
> reproduce.
>
> There was also some strange ethernet behaviour on the Linksys EA8500
> which Adrian and I were discussing in
> https://github.com/lede-project/source/pull/6 which may turn out to be
> related.
>
> Thanks,
> Josh
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
>


From xinglp at gmail.com  Fri Jun 17 20:09:32 2016
From: xinglp at gmail.com (xinglp)
Date: Sat, 18 Jun 2016 11:09:32 +0800
Subject: [LEDE-DEV] [PATCH uclient] enable --post-file,
 use "Content-Length" instead of chunked encoding
In-Reply-To: <f724017d-138c-1709-8305-baf11e75312a@nbd.name>
References: <CAHQM780agD+6-cCQmWuHzguHYVQiKiS-xAw+R7u=a_PLvKP3Cg@mail.gmail.com>
 <f724017d-138c-1709-8305-baf11e75312a@nbd.name>
Message-ID: <CAHQM7826Du9zJBZfK4SA53L5PtDbxWvWoE4b1PP07YdE-oCc-A@mail.gmail.com>

2016-06-17 23:31 GMT+08:00 Felix Fietkau <nbd at nbd.name>:
> On 2016-06-17 13:19, xinglp wrote:
>> --post-file parameter only support text file not binary file.
>> "Content-Length" is more compatible to the http server world.
> Your patch cannot apply due to whitespace damage. Also, the library
> supports delivering POST data in multiple calls to send_data - your
> patch is breaking that completely.
Now, there is an attachment.
I saw uclient_http_send_data() was only called once in
uclient-2016-06-16, what did I missed ?
> If you want to support using content_length instead of chunked encoding,
> please do so in an optional way that does not break the existing code.
That's a easy work, but where the multiple calls to send_data is
needed on earth, wget does not use that at all.
> Could you please also provide some information why you're replacing
> chunked encoding with content-length? What servers do not accept this?
Some APPs's server side are "homemade" http server, which may not
support client to server chunked encoding transport.
And most of the browsers use content-length to post data, I only saw
chunked encoding was used in server to client transport.
> And why are you saying it "only support text file not binary file"?
Check this:
uclient-fetch.c line 337
if (post_data) {
    uclient_http_set_header(cl, "Content-Type",
"application/x-www-form-urlencoded");
    uclient_write(cl, post_data, strlen(post_data));
}

>
> - Felix
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uclient-post-file.patch
Type: application/octet-stream
Size: 4266 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20160618/5a5fdb12/attachment.obj>

From ianchi74 at outlook.com  Fri Jun 17 21:21:07 2016
From: ianchi74 at outlook.com (Adrian Panella)
Date: Fri, 17 Jun 2016 23:21:07 -0500
Subject: [LEDE-DEV] [RFC] rootfs_data on different MTD outside firmware image
Message-ID: <BLU436-SMTP157F4C63D33C1EE18028D98DB280@phx.gbl>

Hi, some Linksys devices (i.e WRT1900AC, EA4500, EA8500,...) have two 
different partitions for dual boot, and an additional partition that 
Linksys uses for system config (sysconf).
Each of these partitions is of a considerable size (23-37 mb, varying 
between devices).

As far as I could see, the ports already in Owrt/LEDE (Kirkwook & Mvebu) 
use only one partition at a time for the overlayfs, so total 23-37mb 
shared among squashfs rom and ubifs overlay.
In some cases the third partition (sysconf) is mounted, but in /mmt, not 
taking part in the overlay, and so not directly useful for installing 
additional packages.

I believe that a way to better profit all this available space would be 
to leave one partition for the rom squashfs alone (23-37mb there) and 
share the 3rd partition between alternative boots as the ubifs overlay 
(another 23-37mb here). In total we double the space up to a full 74mb 
for packages, reducing the need for extroot.


Have you found any serious disadvantage on this approach, and that's why 
it is not implemented in mvebu/kirkwood? If so, which one?

If we leave ubifs outside the image, and only squash in one MTD, does it 
add any benefit to have squash image on top of an UBI layer? Erase 
counters would be lost between firmware flashes anyway and no other 
write would occur in between. On the other hand, in the third MTD (i.e. 
sysconf) the erase counters could be preserved between firmware updates, 
as the ubi block doesn't need to be recreated each time, and only a 
ubiformat could be performed on flash.

I'm planning on switching ipq806x/EA8500 to this scheme, and would 
appreciate opinions first.





From nbd at nbd.name  Fri Jun 17 22:01:02 2016
From: nbd at nbd.name (Felix Fietkau)
Date: Sat, 18 Jun 2016 07:01:02 +0200
Subject: [LEDE-DEV] [PATCH uclient] enable --post-file,
 use "Content-Length" instead of chunked encoding
In-Reply-To: <CAHQM7826Du9zJBZfK4SA53L5PtDbxWvWoE4b1PP07YdE-oCc-A@mail.gmail.com>
References: <CAHQM780agD+6-cCQmWuHzguHYVQiKiS-xAw+R7u=a_PLvKP3Cg@mail.gmail.com>
 <f724017d-138c-1709-8305-baf11e75312a@nbd.name>
 <CAHQM7826Du9zJBZfK4SA53L5PtDbxWvWoE4b1PP07YdE-oCc-A@mail.gmail.com>
Message-ID: <d2c028ff-347a-24f6-d262-c2de0d658eb6@nbd.name>

On 2016-06-18 05:09, xinglp wrote:
> 2016-06-17 23:31 GMT+08:00 Felix Fietkau <nbd at nbd.name>:
>> On 2016-06-17 13:19, xinglp wrote:
>>> --post-file parameter only support text file not binary file.
>>> "Content-Length" is more compatible to the http server world.
>> Your patch cannot apply due to whitespace damage. Also, the library
>> supports delivering POST data in multiple calls to send_data - your
>> patch is breaking that completely.
> Now, there is an attachment.
I would recommend using git send-email to avoid such issues in the future.

> I saw uclient_http_send_data() was only called once in
> uclient-2016-06-16, what did I missed ?
What you missed is the fact uclient-fetch is not the only user of the
library code. The uclient library is used in a few other projects as
well, some of which are not in the LEDE tree yet.

Please make sure that any change you come up with to support --post-file
does not break the library API.

>> If you want to support using content_length instead of chunked encoding,
>> please do so in an optional way that does not break the existing code.
> That's a easy work, but where the multiple calls to send_data is
> needed on earth, wget does not use that at all.
If you upload a large file, it makes sense to not need to have it in
memory completely.

>> Could you please also provide some information why you're replacing
>> chunked encoding with content-length? What servers do not accept this?
> Some APPs's server side are "homemade" http server, which may not
> support client to server chunked encoding transport.

> And most of the browsers use content-length to post data, I only saw
> chunked encoding was used in server to client transport.
>> And why are you saying it "only support text file not binary file"?
> Check this:
> uclient-fetch.c line 337
> if (post_data) {
>     uclient_http_set_header(cl, "Content-Type",
> "application/x-www-form-urlencoded");
>     uclient_write(cl, post_data, strlen(post_data));
> }
Ah, okay. I was confused for a moment because you wrote "--post-file" in
that sentence in the original description.

- Felix


From john at phrozen.org  Fri Jun 17 23:31:39 2016
From: john at phrozen.org (John Crispin)
Date: Sat, 18 Jun 2016 08:31:39 +0200
Subject: [LEDE-DEV] [RFC] rootfs_data on different MTD outside firmware
 image
In-Reply-To: <BLU436-SMTP157F4C63D33C1EE18028D98DB280@phx.gbl>
References: <BLU436-SMTP157F4C63D33C1EE18028D98DB280@phx.gbl>
Message-ID: <19320057-521e-ae6d-e6a7-59557ad55016@phrozen.org>



On 18/06/2016 06:21, Adrian Panella wrote:
> Hi, some Linksys devices (i.e WRT1900AC, EA4500, EA8500,...) have two
> different partitions for dual boot, and an additional partition that
> Linksys uses for system config (sysconf).
> Each of these partitions is of a considerable size (23-37 mb, varying
> between devices).
> 
> As far as I could see, the ports already in Owrt/LEDE (Kirkwook & Mvebu)
> use only one partition at a time for the overlayfs, so total 23-37mb
> shared among squashfs rom and ubifs overlay.
> In some cases the third partition (sysconf) is mounted, but in /mmt, not
> taking part in the overlay, and so not directly useful for installing
> additional packages.
> 
> I believe that a way to better profit all this available space would be
> to leave one partition for the rom squashfs alone (23-37mb there) and
> share the 3rd partition between alternative boots as the ubifs overlay
> (another 23-37mb here). In total we double the space up to a full 74mb
> for packages, reducing the need for extroot.
> 
> 
> Have you found any serious disadvantage on this approach, and that's why
> it is not implemented in mvebu/kirkwood? If so, which one?
> 
> If we leave ubifs outside the image, and only squash in one MTD, does it
> add any benefit to have squash image on top of an UBI layer? Erase
> counters would be lost between firmware flashes anyway and no other
> write would occur in between. On the other hand, in the third MTD (i.e.
> sysconf) the erase counters could be preserved between firmware updates,
> as the ubi block doesn't need to be recreated each time, and only a
> ubiformat could be performed on flash.
> 
> I'm planning on switching ipq806x/EA8500 to this scheme, and would
> appreciate opinions first.

sharing a rootfs between 2 different kernels is not good as the kernel
modules wont be in sync with the kernel version magic. inside th eubi
you will have a squash +overlay which is the best approach imho. we
could create a special data area however the kernel should always go
hand in hand with its squashfs and overlay area. if you flash the
kernel+rootfs from within the running installation then the erase
counters will not get lost.


From daniel at makrotopia.org  Sat Jun 18 03:06:52 2016
From: daniel at makrotopia.org (Daniel Golle)
Date: Sat, 18 Jun 2016 12:06:52 +0200
Subject: [LEDE-DEV] [RFC] rootfs_data on different MTD outside firmware
 image
In-Reply-To: <BLU436-SMTP157F4C63D33C1EE18028D98DB280@phx.gbl>
References: <BLU436-SMTP157F4C63D33C1EE18028D98DB280@phx.gbl>
Message-ID: <20160618100652.GA1270@makrotopia.org>

Hi Adrian,


On Fri, Jun 17, 2016 at 11:21:07PM -0500, Adrian Panella wrote:
> Hi, some Linksys devices (i.e WRT1900AC, EA4500, EA8500,...) have two
> different partitions for dual boot, and an additional partition that Linksys
> uses for system config (sysconf).
> Each of these partitions is of a considerable size (23-37 mb, varying
> between devices).
> 
> As far as I could see, the ports already in Owrt/LEDE (Kirkwook & Mvebu) use
> only one partition at a time for the overlayfs, so total 23-37mb shared
> among squashfs rom and ubifs overlay.
> In some cases the third partition (sysconf) is mounted, but in /mmt, not
> taking part in the overlay, and so not directly useful for installing
> additional packages.
> 
> I believe that a way to better profit all this available space would be to
> leave one partition for the rom squashfs alone (23-37mb there) and share the
> 3rd partition between alternative boots as the ubifs overlay (another
> 23-37mb here). In total we double the space up to a full 74mb for packages,
> reducing the need for extroot.
> 
> 
> Have you found any serious disadvantage on this approach, and that's why it
> is not implemented in mvebu/kirkwood? If so, which one?

John explained that in another reply to your mail.

> 
> If we leave ubifs outside the image, and only squash in one MTD, does it add
> any benefit to have squash image on top of an UBI layer? Erase counters
> would be lost between firmware flashes anyway and no other write would occur
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

NACK. As we do ubiupdatevol for sysupgrade, the erase counters will be
preserved. Even ubiformat would preserve them, and we never write to
ubi-formatted NAND in any other way than either using ubiformat or
ubiupdatevol.

> in between. On the other hand, in the third MTD (i.e. sysconf) the erase
> counters could be preserved between firmware updates, as the ubi block
> doesn't need to be recreated each time, and only a ubiformat could be
> performed on flash.

I don't get what you are talking about.


Cheers


Daniel


> 
> I'm planning on switching ipq806x/EA8500 to this scheme, and would
> appreciate opinions first.
> 
> 
> 
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


From joshbendavid at gmail.com  Sat Jun 18 03:38:26 2016
From: joshbendavid at gmail.com (Josh Bendavid)
Date: Sat, 18 Jun 2016 12:38:26 +0200
Subject: [LEDE-DEV] Linksys ea8500 switch configuration
Message-ID: <CAD1MEwedbMi+tWf3wk4Q7dcb20LQbMHa=vfMtq8GUsSBwkU=CQ@mail.gmail.com>

Hi Adrian,
Thinking a bit more about the discussion we were having in
https://github.com/lede-project/source/pull/6 about the ethernet and
switch configuration on the ea8500.

Given that the stock firmware apparently doesn't enable VLAN on the
switch, I suspect that this router actually has a different
configuration than AP148.

AP148:  gmac1 (eth0) -> rgmii -> switch port 0
              gmac2 (eth1) -> sgmii -> switch port 6
              switch ports 1-4-> PHYs on LAN ports
               switch port 5 -> PHY on WAN port

Suspected configuration of ea8500:
              gmac1 (eth0) -> rgmii -> switch port 0
              gmac2 (eth1) -> rmgii -> PHY on WAN port (bypassing the
switch but using the PHY normally connected to swich port 5)
              switch ports 1-4-> PHYs on LAN ports
              (switch port 5 is then unused)

In that case no vlans would be needed for the standard 1 WAN 1 LAN
configuration.

A bit of a guess on what would be needed in the device tree to handle
this is attached for the gmac and switch parts (but note the ??? in
pinctrl-0 for gmac2, since I'm not sure what to put here, and possibly
an additional block needs to be defined in the pinmux.)
-------------- next part --------------
		gmac1: ethernet at 37200000 {
			status = "ok";
			phy-mode = "rgmii";
			qcom,id = <1>;

			pinctrl-0 = <&rgmii2_pins>;
			pinctrl-names = "default";

			fixed-link {
				speed = <1000>;
				full-duplex;
			};
		};

		gmac2: ethernet at 37400000 {
			status = "ok";
			phy-mode = "rgmii";
			qcom,id = <2>;
			
			pinctrl-0 = ????
			pinctrl-names = "default";			

			fixed-link {
				speed = <1000>;
				full-duplex;
			};
		};
		


			phy0: ethernet-phy at 0 {
				device_type = "ethernet-phy";
				reg = <0>;
				qca,ar8327-initvals = <
					0x00004 0x7600000   /* PAD0_MODE */
					0x00008 0x7600000   /* PAD5_MODE */
					0x0000c 0x80        /* PAD6_MODE */
					0x000e4 0xea545     /* MAC_POWER_SEL */
					0x0007c 0x4e        /* PORT0_STATUS */
					0x00094 0x4e        /* PORT6_STATUS */
					>;
			};

From xinglp at gmail.com  Sat Jun 18 03:38:13 2016
From: xinglp at gmail.com (xinglp)
Date: Sat, 18 Jun 2016 18:38:13 +0800
Subject: [LEDE-DEV] [PATCH uclient] enable --post-file,
 use "Content-Length" instead of chunked encoding
In-Reply-To: <d2c028ff-347a-24f6-d262-c2de0d658eb6@nbd.name>
References: <CAHQM780agD+6-cCQmWuHzguHYVQiKiS-xAw+R7u=a_PLvKP3Cg@mail.gmail.com>
 <f724017d-138c-1709-8305-baf11e75312a@nbd.name>
 <CAHQM7826Du9zJBZfK4SA53L5PtDbxWvWoE4b1PP07YdE-oCc-A@mail.gmail.com>
 <d2c028ff-347a-24f6-d262-c2de0d658eb6@nbd.name>
Message-ID: <CAHQM780syGWZG4a+5FDUVzw7WkrSY7KUBQO2-fi0u0aWEBeEAQ@mail.gmail.com>

2016-06-18 13:01 GMT+08:00 Felix Fietkau <nbd at nbd.name>:
> If you upload a large file, it makes sense to not need to have it in
> memory completely.
Please review this one.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uclient-fixed-length.patch
Type: application/octet-stream
Size: 6370 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20160618/4c069c14/attachment.obj>

From xinglp at gmail.com  Sat Jun 18 03:40:01 2016
From: xinglp at gmail.com (xinglp)
Date: Sat, 18 Jun 2016 18:40:01 +0800
Subject: [LEDE-DEV] [PATCH uclient] enable --post-file,
 use "Content-Length" instead of chunked encoding
In-Reply-To: <CAHQM780syGWZG4a+5FDUVzw7WkrSY7KUBQO2-fi0u0aWEBeEAQ@mail.gmail.com>
References: <CAHQM780agD+6-cCQmWuHzguHYVQiKiS-xAw+R7u=a_PLvKP3Cg@mail.gmail.com>
 <f724017d-138c-1709-8305-baf11e75312a@nbd.name>
 <CAHQM7826Du9zJBZfK4SA53L5PtDbxWvWoE4b1PP07YdE-oCc-A@mail.gmail.com>
 <d2c028ff-347a-24f6-d262-c2de0d658eb6@nbd.name>
 <CAHQM780syGWZG4a+5FDUVzw7WkrSY7KUBQO2-fi0u0aWEBeEAQ@mail.gmail.com>
Message-ID: <CAHQM780qfeiepyBsS1d1KfLMbH75gRHic5cou_U5Y-rM+6_RMA@mail.gmail.com>

2016-06-18 18:38 GMT+08:00 xinglp <xinglp at gmail.com>:
> 2016-06-18 13:01 GMT+08:00 Felix Fietkau <nbd at nbd.name>:
>> If you upload a large file, it makes sense to not need to have it in
>> memory completely.
> Please review this one.
Last patch still won't work for file larger than memory, but it
supports binary file.


From xinglp at gmail.com  Sat Jun 18 03:48:24 2016
From: xinglp at gmail.com (xinglp)
Date: Sat, 18 Jun 2016 18:48:24 +0800
Subject: [LEDE-DEV] [PATCH uclient] enable --post-file,
 use "Content-Length" instead of chunked encoding
In-Reply-To: <CAHQM780qfeiepyBsS1d1KfLMbH75gRHic5cou_U5Y-rM+6_RMA@mail.gmail.com>
References: <CAHQM780agD+6-cCQmWuHzguHYVQiKiS-xAw+R7u=a_PLvKP3Cg@mail.gmail.com>
 <f724017d-138c-1709-8305-baf11e75312a@nbd.name>
 <CAHQM7826Du9zJBZfK4SA53L5PtDbxWvWoE4b1PP07YdE-oCc-A@mail.gmail.com>
 <d2c028ff-347a-24f6-d262-c2de0d658eb6@nbd.name>
 <CAHQM780syGWZG4a+5FDUVzw7WkrSY7KUBQO2-fi0u0aWEBeEAQ@mail.gmail.com>
 <CAHQM780qfeiepyBsS1d1KfLMbH75gRHic5cou_U5Y-rM+6_RMA@mail.gmail.com>
Message-ID: <CAHQM7830EnEMMXx4C+GR_zSh4utOJ2W5+NNYVLVyOvCfBR3FjQ@mail.gmail.com>

2016-06-18 18:40 GMT+08:00 xinglp <xinglp at gmail.com>:
> 2016-06-18 18:38 GMT+08:00 xinglp <xinglp at gmail.com>:
>> 2016-06-18 13:01 GMT+08:00 Felix Fietkau <nbd at nbd.name>:
>>> If you upload a large file, it makes sense to not need to have it in
>>> memory completely.
>> Please review this one.
> Last patch still won't work for file larger than memory, but it
> supports binary file.
last patch has a mistake, try this one.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uclient-fixed-length.patch
Type: application/octet-stream
Size: 6368 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20160618/560ec5cf/attachment-0001.obj>

From joshbendavid at gmail.com  Sat Jun 18 03:49:48 2016
From: joshbendavid at gmail.com (Josh Bendavid)
Date: Sat, 18 Jun 2016 12:49:48 +0200
Subject: [LEDE-DEV] skb_warn_bad_offload + crash at high load on ipq806x
In-Reply-To: <CAD1MEwdzSwCSck1QW=bviXYC+CdiKbzk_m8B6rcq-vjKAWwdPQ@mail.gmail.com>
References: <CAD1MEwdz99Sjq66u+nsy+kmtAxPPPKnSR0fh3_h06CnKibZfww@mail.gmail.com>
 <CAD1MEwd_p2C2Eum7py1R8hzCyExYwxM+_CZX_PA8bDYgYvRFWQ@mail.gmail.com>
 <CAD1MEwcXWj_Da-dRCuCAwGYVueLroYpzH=8LSCa4A=NuCLe+_w@mail.gmail.com>
 <CAD1MEwcCXoEaesHnDV8u7e0NT_Wvw7S0WJgOrVjXZPGp7Q08cw@mail.gmail.com>
 <CAD1MEwdzSwCSck1QW=bviXYC+CdiKbzk_m8B6rcq-vjKAWwdPQ@mail.gmail.com>
Message-ID: <CAD1MEwerWfOjj_gydGMs8uYaR+kGak7UG+OF0SFf5GRCe2xwwg@mail.gmail.com>

This is resolved by https://github.com/lede-project/source/pull/134
for the record.


From xinglp at gmail.com  Sat Jun 18 04:25:46 2016
From: xinglp at gmail.com (xinglp)
Date: Sat, 18 Jun 2016 19:25:46 +0800
Subject: [LEDE-DEV] [PATCH uclient] enable --post-file,
 use "Content-Length" instead of chunked encoding
In-Reply-To: <d2c028ff-347a-24f6-d262-c2de0d658eb6@nbd.name>
References: <CAHQM780agD+6-cCQmWuHzguHYVQiKiS-xAw+R7u=a_PLvKP3Cg@mail.gmail.com>
 <f724017d-138c-1709-8305-baf11e75312a@nbd.name>
 <CAHQM7826Du9zJBZfK4SA53L5PtDbxWvWoE4b1PP07YdE-oCc-A@mail.gmail.com>
 <d2c028ff-347a-24f6-d262-c2de0d658eb6@nbd.name>
Message-ID: <CAHQM782rntE+LQ64DtiBti4PqaC9d44ebK16Nit=DSLqStZdmA@mail.gmail.com>

2016-06-18 13:01 GMT+08:00 Felix Fietkau <nbd at nbd.name>:

>> I saw uclient_http_send_data() was only called once in
>> uclient-2016-06-16, what did I missed ?
> What you missed is the fact uclient-fetch is not the only user of the
> library code. The uclient library is used in a few other projects as
> well, some of which are not in the LEDE tree yet.
>
> Please make sure that any change you come up with to support --post-file
> does not break the library API.
>
>>> If you want to support using content_length instead of chunked encoding,
>>> please do so in an optional way that does not break the existing code.
>> That's a easy work, but where the multiple calls to send_data is
>> needed on earth, wget does not use that at all.
> If you upload a large file, it makes sense to not need to have it in
> memory completely.

I think this patch is better than others I posted.
It will behave same as wget while not break the library API.

I add an new API:
int uclient_http_set_contentlength(struct uclient *cl, int len);
We can call this first when we know the exact total length before send
data, it wont break uclient_http_send_data().
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uclient-fixed-length.patch
Type: application/octet-stream
Size: 6048 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20160618/a996f9ff/attachment.obj>

From jonas.gorski at gmail.com  Sat Jun 18 04:55:25 2016
From: jonas.gorski at gmail.com (Jonas Gorski)
Date: Sat, 18 Jun 2016 13:55:25 +0200
Subject: [LEDE-DEV] [PATCH] kernel: rename B53 symbols to avoid upstream
 kernel conflict
In-Reply-To: <1465901741-17589-1-git-send-email-zajec5@gmail.com>
References: <1465901741-17589-1-git-send-email-zajec5@gmail.com>
Message-ID: <CAOiHx=kP-97DWiAg3YD5D1H7=j5yWfQPQvT9zz5nfPOZRLKyLQ@mail.gmail.com>

Hi,

On 14 June 2016 at 12:55, Rafa? Mi?ecki <zajec5 at gmail.com> wrote:
> In kernel 4.7 there is upstreamed b53 driver using (mostly?) the same
> symbols as our b53 does. Change our symbols so both drivers can coexist
> in kernel tree.
>
> Signed-off-by: Rafa? Mi?ecki <zajec5 at gmail.com>

Makes sense, so

Acked-by: Jonas Gorski <jonas.gorski at gmail.com>


Jonas


From mike+lede at mgoodwin.net  Sat Jun 18 08:08:21 2016
From: mike+lede at mgoodwin.net (Mike Goodwin)
Date: Sat, 18 Jun 2016 15:08:21 +0000
Subject: [LEDE-DEV] Octeon (er and erlite) squashfs build size on
 downloads.lede-project.org
Message-ID: <01000155640e37e1-8812ee6c-3d12-467f-8c72-a73375c77004-000000@email.amazonses.com>

Hi Gents, 

Subscribing to the mailing list here because I have a few questions about the 
Octeon builds. I'm looking to use LEDE with my Ubiquiti EdgeRouter Lite 3, and 
the only documentation I can find to do so is here:

https://wiki.openwrt.org/toh/ubiquiti/edgerouter.lite#installation_wip

The main discrepancy here are the size of the "lede-octeon-erlite-squashfs-
sysupgrade.tar" build and also the -er build ... currently around 7MB. 

https://downloads.lede-project.org/snapshots/targets/octeon/generic/

In the instructions from above you can see that the size is supposed to be 
around 50.33MB

I noticed this when I was about to `dd` the image to a spare USB I wanted to 
test from, and thought it very peculiar that it was so tiny. 

I see that the "*-ext4-sysupgrade.tar" is of a more comparable size, but was 
hoping to have this working with squashfs instead.

Another thing of note is that the sister..parent (I don't know I don't want to 
offend anyone) repository for OpenWRT images is having the same "issue":

https://downloads.openwrt.org/chaos_calmer/15.05/octeon/generic/openwrt-15.05-octeon-erlite-squashfs-sysupgrade.tar 6.4MB

What's going on here? 

Are the builds broken?

Is only ext4 planned for the future?

Do the ext4 builds work presently?

Thanks!

-Mike


From ash.benz at bk.ru  Sat Jun 18 08:30:18 2016
From: ash.benz at bk.ru (A. Benz)
Date: Sat, 18 Jun 2016 23:30:18 +0800
Subject: [LEDE-DEV] skb_warn_bad_offload + crash at high load on ipq806x
In-Reply-To: <CAD1MEwerWfOjj_gydGMs8uYaR+kGak7UG+OF0SFf5GRCe2xwwg@mail.gmail.com>
References: <CAD1MEwdz99Sjq66u+nsy+kmtAxPPPKnSR0fh3_h06CnKibZfww@mail.gmail.com>
 <CAD1MEwd_p2C2Eum7py1R8hzCyExYwxM+_CZX_PA8bDYgYvRFWQ@mail.gmail.com>
 <CAD1MEwcXWj_Da-dRCuCAwGYVueLroYpzH=8LSCa4A=NuCLe+_w@mail.gmail.com>
 <CAD1MEwcCXoEaesHnDV8u7e0NT_Wvw7S0WJgOrVjXZPGp7Q08cw@mail.gmail.com>
 <CAD1MEwdzSwCSck1QW=bviXYC+CdiKbzk_m8B6rcq-vjKAWwdPQ@mail.gmail.com>
 <CAD1MEwerWfOjj_gydGMs8uYaR+kGak7UG+OF0SFf5GRCe2xwwg@mail.gmail.com>
Message-ID: <ae47548d-1282-666e-6931-060d0431e46b@bk.ru>

Great find

The observation below is no longer relevant, but after the eth0 report 
in your earlier email I adjusted my network as follows:


config interface 'lan'
         option ifname 'eth1.1'

config interface 'wan'
         option ifname 'eth1.200'

config switch
         option name 'switch0'
         option reset '1'
         option enable_vlan '1'

config switch_vlan
         option device 'switch0'
         option vlan '1'
         option ports '1 2 3 4 6t'

config switch_vlan
         option device 'switch0'
         option vlan '2'
         option vid '200'
         option ports '5t 6t'

It dialed to ISP right away, and been very stable. I tried reproducing 
what would normally crash the router but its stable.

I was expecting to assign one of the LAN ports to WAN, but the physical 
WAN port was still usable.. I found that strange.

Regards,
A. Benz

On 06/18/16 18:49, Josh Bendavid wrote:
> This is resolved by https://github.com/lede-project/source/pull/134
> for the record.
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
>


From joshbendavid at gmail.com  Sat Jun 18 08:32:27 2016
From: joshbendavid at gmail.com (Josh Bendavid)
Date: Sat, 18 Jun 2016 17:32:27 +0200
Subject: [LEDE-DEV] skb_warn_bad_offload + crash at high load on ipq806x
In-Reply-To: <ae47548d-1282-666e-6931-060d0431e46b@bk.ru>
References: <CAD1MEwdz99Sjq66u+nsy+kmtAxPPPKnSR0fh3_h06CnKibZfww@mail.gmail.com>
 <CAD1MEwd_p2C2Eum7py1R8hzCyExYwxM+_CZX_PA8bDYgYvRFWQ@mail.gmail.com>
 <CAD1MEwcXWj_Da-dRCuCAwGYVueLroYpzH=8LSCa4A=NuCLe+_w@mail.gmail.com>
 <CAD1MEwcCXoEaesHnDV8u7e0NT_Wvw7S0WJgOrVjXZPGp7Q08cw@mail.gmail.com>
 <CAD1MEwdzSwCSck1QW=bviXYC+CdiKbzk_m8B6rcq-vjKAWwdPQ@mail.gmail.com>
 <CAD1MEwerWfOjj_gydGMs8uYaR+kGak7UG+OF0SFf5GRCe2xwwg@mail.gmail.com>
 <ae47548d-1282-666e-6931-060d0431e46b@bk.ru>
Message-ID: <CAD1MEwc5y9rkaNMp-mFb-whBEKVWnCao9Fb6j=W1Sn4sK8ZOXA@mail.gmail.com>

The switch is a full 7 port switch with 5 connected to the external
ports and 2 connected to the cpu.  So there is no restriction on which
cpu port can connect to which combination of external ports.


From ianchi74 at outlook.com  Sat Jun 18 10:41:28 2016
From: ianchi74 at outlook.com (Adrian Panella)
Date: Sat, 18 Jun 2016 12:41:28 -0500
Subject: [LEDE-DEV] Linksys ea8500 switch configuration
In-Reply-To: <CAD1MEwedbMi+tWf3wk4Q7dcb20LQbMHa=vfMtq8GUsSBwkU=CQ@mail.gmail.com>
References: <CAD1MEwedbMi+tWf3wk4Q7dcb20LQbMHa=vfMtq8GUsSBwkU=CQ@mail.gmail.com>
Message-ID: <BLU405-EAS32472F8F21C1FF5D9712B6EDB280@phx.gbl>



> El 18/06/2016, a las 5:38 a.m., Josh Bendavid <joshbendavid at gmail.com> escribi?:
> 
> Hi Adrian,
> Thinking a bit more about the discussion we were having in
> https://github.com/lede-project/source/pull/6 about the ethernet and
> switch configuration on the ea8500.

Thanks for your help on this!

> 
> Given that the stock firmware apparently doesn't enable VLAN on the
> switch, I suspect that this router actually has a different
> configuration than AP148.
> 
> AP148:  gmac1 (eth0) -> rgmii -> switch port 0
>              gmac2 (eth1) -> sgmii -> switch port 6
>              switch ports 1-4-> PHYs on LAN ports
>               switch port 5 -> PHY on WAN port
> 
> Suspected configuration of ea8500:
>              gmac1 (eth0) -> rgmii -> switch port 0
>              gmac2 (eth1) -> rmgii -> PHY on WAN port (bypassing the
> switch but using the PHY normally connected to swich port 5)
>              switch ports 1-4-> PHYs on LAN ports
>              (switch port 5 is then unused)
> 

From what I saw in the Linksys GPL source, port 6 is in SGMII mode, and should be like AP148.
But I will give your idea a try and will come back with the results.
It is an intriguing matter. And more so, as eth0, the only working, seems to be somehow related to pcie2. That pcie theoretically is not connected to anything. But if I disable it I completely loose wired networking....



> In that case no vlans would be needed for the standard 1 WAN 1 LAN
> configuration.
> 
> A bit of a guess on what would be needed in the device tree to handle
> this is attached for the gmac and switch parts (but note the ??? in
> pinctrl-0 for gmac2, since I'm not sure what to put here, and possibly
> an additional block needs to be defined in the pinmux.)
> <ea8500switchgmac.txt>

From joshbendavid at gmail.com  Sat Jun 18 10:51:06 2016
From: joshbendavid at gmail.com (Josh Bendavid)
Date: Sat, 18 Jun 2016 19:51:06 +0200
Subject: [LEDE-DEV] Linksys ea8500 switch configuration
In-Reply-To: <BLU405-EAS32472F8F21C1FF5D9712B6EDB280@phx.gbl>
References: <CAD1MEwedbMi+tWf3wk4Q7dcb20LQbMHa=vfMtq8GUsSBwkU=CQ@mail.gmail.com>
 <BLU405-EAS32472F8F21C1FF5D9712B6EDB280@phx.gbl>
Message-ID: <CAD1MEwfX=7nfRsWQch4wXKFExmHAnX3hUKH7YcZpnFMP12fXSw@mail.gmail.com>

Ok.  If the configuration I am suspecting for the stock firmware is
correct, then port 6 is unused and it shouldn't matter how it's
configured.

Actually it's possible that some of this is anyways dynamically
configurable through the switch registers.  (ie even if the stock
firmware has the eth1 connected directly to the WAN phy as I suspect,
it might still be possible/preferable to configure the switch so that
it is more like AP148 with gmacX (eth1) -> rgmii -> switch port 6

Actually I don't think gmac2 even supports rgmii, so if both ethernet
interfaces are connected to the switch chip/PHY's with rgmii then they
would have to be gmac0 and gmac1...


From ianchi74 at outlook.com  Sat Jun 18 11:16:14 2016
From: ianchi74 at outlook.com (Adrian Panella)
Date: Sat, 18 Jun 2016 13:16:14 -0500
Subject: [LEDE-DEV] Linksys ea8500 switch configuration
In-Reply-To: <CAD1MEwfX=7nfRsWQch4wXKFExmHAnX3hUKH7YcZpnFMP12fXSw@mail.gmail.com>
References: <CAD1MEwedbMi+tWf3wk4Q7dcb20LQbMHa=vfMtq8GUsSBwkU=CQ@mail.gmail.com>
 <BLU405-EAS32472F8F21C1FF5D9712B6EDB280@phx.gbl>
 <CAD1MEwfX=7nfRsWQch4wXKFExmHAnX3hUKH7YcZpnFMP12fXSw@mail.gmail.com>
Message-ID: <BLU405-EAS340EE973130E5D1E1E5B2A4DB280@phx.gbl>



> El 18/06/2016, a las 12:51 p.m., Josh Bendavid <joshbendavid at gmail.com> escribi?:
> 
> Ok.  If the configuration I am suspecting for the stock firmware is
> correct, then port 6 is unused and it shouldn't matter how it's
> configured.
> 
> Actually it's possible that some of this is anyways dynamically
> configurable through the switch registers.  (ie even if the stock
> firmware has the eth1 connected directly to the WAN phy as I suspect,
> it might still be possible/preferable to configure the switch so that
> it is more like AP148 with gmacX (eth1) -> rgmii -> switch port 6

Is there any way I can dump all registers from the switch? I could flash back stock FW and see how it is set up.


> 
> Actually I don't think gmac2 even supports rgmii, so if both ethernet
> interfaces are connected to the switch chip/PHY's with rgmii then they
> would have to be gmac0 and gmac1...

From dev at kresin.me  Sat Jun 18 15:59:03 2016
From: dev at kresin.me (Mathias Kresin)
Date: Sun, 19 Jun 2016 00:59:03 +0200
Subject: [LEDE-DEV] [PATCH] lantiq: ltq-atm: fix xrx200 depends
Message-ID: <1466290743-5790-1-git-send-email-dev@kresin.me>

This one was missed by abc346db0e191ebeeb122ce26d1831469fadee1c.

Signed-off-by: Mathias Kresin <dev at kresin.me>
---

This patches fixes bug #16.

 package/kernel/lantiq/ltq-atm/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/kernel/lantiq/ltq-atm/Makefile b/package/kernel/lantiq/ltq-atm/Makefile
index 25ee0c6..12e758d 100644
--- a/package/kernel/lantiq/ltq-atm/Makefile
+++ b/package/kernel/lantiq/ltq-atm/Makefile
@@ -31,7 +31,7 @@ KernelPackage/ltq-atm-ar9=$(call KernelPackage/ltq-atm-template,ar9,TARGET_lanti
 KernelPackage/ltq-atm-ase=$(call KernelPackage/ltq-atm-template,ase,TARGET_lantiq_ase)
 
 define KernelPackage/ltq-atm-vr9
-  $(call KernelPackage/ltq-atm-template,vr9,xrx200)
+  $(call KernelPackage/ltq-atm-template,vr9,TARGET_lantiq_xrx200)
   AUTOLOAD:=
 endef
 
-- 
1.9.1



From chinawrj at gmail.com  Sat Jun 18 21:16:16 2016
From: chinawrj at gmail.com (Wang Linetkux)
Date: Sun, 19 Jun 2016 12:16:16 +0800
Subject: [LEDE-DEV] [UBUS] [PATCH] Issue of msgbuf_data_len in ubus_context
Message-ID: <CANQnsBpZvnwyon4zuKQ_FQdUC7cWCvp58S+8f-SQHNH1idUTog@mail.gmail.com>

Hi, Guys
  Since I cannot find other places to send this patch, so I send it
here, and hope it does not bother you.
  "alloc_msg_buf" function in "ubus/libubus-io.c" has the feature that
expand or shrink msg buffer when necessary. But I have noticed that
"msgbuf_data_len" has been properly set after msg buffer is expanded,
and it still stays with its origin value. I have generated one patch
for this bug. Feel free to talk with me, just in case I am wrong.

ubus repo on lede:
https://git.lede-project.org/?p=project/ubus.git;a=summary


Rujun
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-the-length-of-msg-buffer-after-realloc.patch
Type: application/octet-stream
Size: 608 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20160619/7d3aa807/attachment.obj>

From chinawrj at gmail.com  Sat Jun 18 21:21:17 2016
From: chinawrj at gmail.com (Wang Linetkux)
Date: Sun, 19 Jun 2016 12:21:17 +0800
Subject: [LEDE-DEV] [UBUS] [PATCH] Issue of msgbuf_data_len in
	ubus_context
In-Reply-To: <CANQnsBpZvnwyon4zuKQ_FQdUC7cWCvp58S+8f-SQHNH1idUTog@mail.gmail.com>
References: <CANQnsBpZvnwyon4zuKQ_FQdUC7cWCvp58S+8f-SQHNH1idUTog@mail.gmail.com>
Message-ID: <CANQnsBowyqcGbygwLUfQJGffDg-kZ-uhQR=Qrur1KC6xQb92kA@mail.gmail.com>

Sorry, forgot to paste the patch in the email for easy reading.

---

 libubus-io.c | 1 +

 1 file changed, 1 insertion(+)



diff --git a/libubus-io.c b/libubus-io.c

index 9320bf3..0582ff7 100644

--- a/libubus-io.c

+++ b/libubus-io.c

@@ -259,6 +259,7 @@ static bool alloc_msg_buf(struct ubus_context
*ctx, int len)

                return false;



        ctx->msgbuf.data = ptr;

+       ctx->msgbuf_data_len = len;

        return true;

 }







2016-06-19 12:16 GMT+08:00 Wang Linetkux <chinawrj at gmail.com>:
> Hi, Guys
>   Since I cannot find other places to send this patch, so I send it
> here, and hope it does not bother you.
>   "alloc_msg_buf" function in "ubus/libubus-io.c" has the feature that
> expand or shrink msg buffer when necessary. But I have noticed that
> "msgbuf_data_len" has been properly set after msg buffer is expanded,
> and it still stays with its origin value. I have generated one patch
> for this bug. Feel free to talk with me, just in case I am wrong.
>
> ubus repo on lede:
> https://git.lede-project.org/?p=project/ubus.git;a=summary
>
>
> Rujun


From joshbendavid at gmail.com  Sun Jun 19 00:25:50 2016
From: joshbendavid at gmail.com (Josh Bendavid)
Date: Sun, 19 Jun 2016 09:25:50 +0200
Subject: [LEDE-DEV] jffs issues on sysupgrade with keeping old config
Message-ID: <CAD1MEwePdEwcn-YDMd8uW8mmH-7+EONDGwto2ArJG15FjRQssg@mail.gmail.com>

Hi,
Having some issues with sysupgrade on Archer C2600 (ipq806x with NOR flash).
(from the discussion at
https://forum.openwrt.org/viewtopic.php?pid=327671#p327671)

When doing sysupgrade without keeping config files, everything goes
ok.  In that case at first boot I get

Sat Jun 18 09:50:48 2016 user.notice kernel: [    9.003952]
mount_root: jffs2 not ready yet, using temporary tmpfs overlay

and then later
Sat Jun 18 09:52:21 2016 daemon.info mount_root: performing overlay whiteout

Which I interpret as "jffs not ready at the beginning of init, so use
the ram overlay temporarily, then switch to jffs2 later when it is
ready at the end of the init"

Now instead, running sysupgrade and keeping the configuration, we end
up with the attached log, where somehow the system thinks that jffs2
is ready to use, even if it isn't fully ready, and then there is a
crash when there is an attempt to write to it.

Any ideas here?  It almost looks to me that the check on whether jffs2
is ready at this stage is not strict enough.  (But maybe there is
something else wrong).

Thanks,
Josh


From josua.mayer97 at gmail.com  Sun Jun 19 04:59:00 2016
From: josua.mayer97 at gmail.com (Josua Mayer)
Date: Sun, 19 Jun 2016 13:59:00 +0200
Subject: [LEDE-DEV] fstools: ext4 overlay support - rootfs mounted twice bug
Message-ID: <5768f92a-d15a-37f5-28c7-e7a78d6703ac@gmail.com>

Hi everybody,

Some of you might remember that there was a bug where an ext4 rootfs was
mounted twice, first as / and then as overlay.
After staring down the mount_root.c file I think I spotted the reason
for it. Sadly I was not able to reproduce the original problem so I am
looking for somebody who had this issue and would be willing to try out
a patch of mine.
Please get back at me if you can.

For any interested people I am attaching the patch to this mail (this is
not yet a patch submission, just discussion).

br
Josua Mayer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-fstools-support-for-ext4fs-overlay.patch
Type: text/x-patch
Size: 7579 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20160619/5dcc17d0/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-mount_root-Don-t-mount-ext4-rootfs-twice.patch
Type: text/x-patch
Size: 2318 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20160619/5dcc17d0/attachment-0003.bin>

From dev at kresin.me  Sun Jun 19 07:30:55 2016
From: dev at kresin.me (Mathias Kresin)
Date: Sun, 19 Jun 2016 16:30:55 +0200
Subject: [LEDE-DEV] [PATCH] lantiq: fix network in failsafe
Message-ID: <1466346655-25914-1-git-send-email-dev@kresin.me>

So far the network in failsafe is setup only for one board. Use the
eth0 interface as lan interface for all boards for now.

If a board has its lan interface(s) on another eth, a special
handling based on the board name can be added.

Signed-off-by: Mathias Kresin <dev at kresin.me>
---
 .../lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq  | 10 +---------
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq b/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
index 3d7fabf..7ed0fab 100644
--- a/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
+++ b/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
@@ -3,15 +3,7 @@
 . /lib/functions/lantiq.sh
 
 set_preinit_iface() {
-
-	board=$(lantiq_board_name)
-
-	case "$board" in
-	TDW8970)
-		ifname=eth0
-		;;
-	esac
-
+	ifname=eth0
 }
 
 boot_hook_add preinit_main set_preinit_iface
-- 
1.9.1



From dev at kresin.me  Sun Jun 19 07:32:47 2016
From: dev at kresin.me (Mathias Kresin)
Date: Sun, 19 Jun 2016 16:32:47 +0200
Subject: [LEDE-DEV] [PATCH] lantiq: fix build of NAND sysupgrade images
Message-ID: <1466346767-26128-1-git-send-email-dev@kresin.me>

The *_UBIFS_OPTS variables need to be prefixed with DEVICE_ to match
the profile name.

The conditions need to be evaluated after the *_UBIFS_OPTS are set,
otherwise the variables are always empty.

Do not append or pass the DEVICE_ prefixed profile name to the images.
Use the name that is passed by the Image/Build/Profile/ step.

Signed-off-by: Mathias Kresin <dev at kresin.me>

---

The changes have been only tested with the BTHOMEHUBV5A profile but
should work for all (u-boot) NAND images. EVA NAND images are
completely untested.

 target/linux/lantiq/image/Makefile | 102 ++++++++++++++++---------------------
 1 file changed, 45 insertions(+), 57 deletions(-)

diff --git a/target/linux/lantiq/image/Makefile b/target/linux/lantiq/image/Makefile
index d9424f8..e75d634 100644
--- a/target/linux/lantiq/image/Makefile
+++ b/target/linux/lantiq/image/Makefile
@@ -57,14 +57,6 @@ define Image/Build/squashfs
 	$(call prepare_generic_squashfs,$(BIN_DIR)/$(IMG_PREFIX)-$(2)-$(1).image)
 endef
 
-ifneq ($($(PROFILE)_UBI_OPTS),)
-  define Image/BuildNAND/squashfs
-	$(call prepare_generic_squashfs,$(KDIR)/root.$(1))
-	$(call Image/Build/UbinizeImage,$(PROFILE),,squashfs,$($(PROFILE)_UBI_OPTS))
-	$(call Image/Build/SysupgradeNAND,$(PROFILE),$(1),$(KDIR)/uImage-$(PROFILE))
-  endef
-endif
-
 DGN3500_SKERNEL=0x50000
 DGN3500_SKERNEL_DECIMAL=327680
 define Image/BuildDGN3500/squashfs
@@ -107,19 +99,6 @@ define Image/BuildEVA/squashfs
 	$(call prepare_generic_squashfs,$(BIN_DIR)/$(IMG_PREFIX)-$(2)-$(1).image.eva)
 endef
 
-ifneq ($($(PROFILE)_UBIFS_OPTS),)
-  define Image/BuildEVA/ubifs
-	$(CP) $(KDIR)/root.ubifs $(BIN_DIR)/$(IMG_PREFIX)-$(PROFILE)-rootfs.ubifs
-  endef
-endif
-
-ifneq ($($(PROFILE)_UBI_OPTS),)
-  define Image/BuildEVA/ubi
-	$(CP) $(KDIR)/root.ubi $(BIN_DIR)/$(IMG_PREFIX)-$(PROFILE)-rootfs.ubi
-	$(CP) $(KDIR)/root-overlay.ubi $(BIN_DIR)/$(IMG_PREFIX)-$(PROFILE)-rootfs-overlay.ubi
-  endef
-endif
-
 define Image/BuildLoader/squashfs
 	dd if=$(KDIR)/loader-$(2).bin of=$(KDIR)/loader-$(2).bin.padded bs=3072k conv=sync
 	cat $(KDIR)/loader-$(2).bin.padded $(KDIR)/root.$(1) > $(BIN_DIR)/$(IMG_PREFIX)-$(2)-$(1).image
@@ -145,30 +124,6 @@ define Image/Build/jffs2-256k
 	cat $(KDIR)/uImage-$(2)-$(1) $(KDIR)/root.$(1) > $(BIN_DIR)/$(IMG_PREFIX)-$(2)-$(1).image
 endef
 
-ifneq ($($(PROFILE)_UBIFS_OPTS),)
-  define Image/Build/ubifs
-	$(CP) $(KDIR)/root.ubifs $(BIN_DIR)/$(IMG_PREFIX)-$(PROFILE)-rootfs.ubifs
-  endef
-endif
-
-ifneq ($($(PROFILE)_UBI_OPTS),)
-  define Image/Build/ubi
-	$(CP) $(KDIR)/root.ubi $(BIN_DIR)/$(IMG_PREFIX)-$(PROFILE)-rootfs.ubi
-	$(CP) $(KDIR)/root-overlay.ubi $(BIN_DIR)/$(IMG_PREFIX)-$(PROFILE)-rootfs-overlay.ubi
-  endef
-endif
-
-
-ifneq ($($(PROFILE)_UBIFS_OPTS),)
-ifneq ($($(PROFILE)_UBI_OPTS),)
-  define Image/BuildNAND/ubifs
-	$(call Image/Build/UbinizeImage,$(PROFILE),,ubifs,$($(PROFILE)_UBI_OPTS))
-	$(call Image/Build/SysupgradeNAND,$(PROFILE),$(1),$(KDIR)/uImage-$(PROFILE))
-  endef
-endif
-endif
-
-
 ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),)
   define Image/BuildKernel/InitramfsTemplate
 	$(call PatchKernelLzma,$(1),-initramfs)
@@ -326,8 +281,8 @@ endif
 ifeq ($(SUBTARGET),xway)
 
 # Danube
-BTHOMEHUBV2B_UBIFS_OPTS:="-m 512 -e 15872 -c 1959"
-BTHOMEHUBV2B_UBI_OPTS:="-m 512 -p 16KiB -s 256"
+DEVICE_BTHOMEHUBV2B_UBIFS_OPTS:="-m 512 -e 15872 -c 1959"
+DEVICE_BTHOMEHUBV2B_UBI_OPTS:="-m 512 -p 16KiB -s 256"
 
 Image/BuildKernel/Profile/BTHOMEHUBV2B=$(call Image/BuildKernel/Template,BTHOMEHUBV2B)
 Image/Build/Profile/BTHOMEHUBV2B=$(call Image/BuildNAND/$(1),$(1),BTHOMEHUBV2B)
@@ -497,8 +452,8 @@ TARGET_DEVICES += GIGASX76X
 
 
 # AR9
-BTHOMEHUBV3A_UBIFS_OPTS:="-m 512 -e 15872 -c 1959"
-BTHOMEHUBV3A_UBI_OPTS:="-m 512 -p 16KiB -s 256"
+DEVICE_BTHOMEHUBV3A_UBIFS_OPTS:="-m 512 -e 15872 -c 1959"
+DEVICE_BTHOMEHUBV3A_UBI_OPTS:="-m 512 -p 16KiB -s 256"
 
 Image/BuildKernel/Profile/BTHOMEHUBV3A=$(call Image/BuildKernel/Template,BTHOMEHUBV3A)
 Image/Build/Profile/BTHOMEHUBV3A=$(call Image/BuildNAND/$(1),$(1),BTHOMEHUBV3A)
@@ -627,8 +582,8 @@ endif
 ifeq ($(SUBTARGET),xrx200)
 
 # VR9
-P2812HNUF1_UBIFS_OPTS:="-m 2048 -e 126KiB -c 4096"
-P2812HNUF1_UBI_OPTS:="-m 2048 -p 128KiB -s 512"
+DEVICE_P2812HNUF1_UBIFS_OPTS:="-m 2048 -e 126KiB -c 4096"
+DEVICE_P2812HNUF1_UBI_OPTS:="-m 2048 -p 128KiB -s 512"
 
 Image/BuildKernel/Profile/P2812HNUF1=$(call Image/BuildKernel/Template,P2812HNUF1)
 Image/Build/Profile/P2812HNUF1=$(call Image/BuildNAND/$(1),$(1),P2812HNUF1)
@@ -639,8 +594,8 @@ define LegacyDevice/P2812HNUF1
 endef
 LEGACY_DEVICES += P2812HNUF1
 
-P2812HNUF3_UBIFS_OPTS:="-m 2048 -e 126KiB -c 4096"
-P2812HNUF3_UBI_OPTS:="-m 2048 -p 128KiB -s 512"
+DEVICE_P2812HNUF3_UBIFS_OPTS:="-m 2048 -e 126KiB -c 4096"
+DEVICE_P2812HNUF3_UBI_OPTS:="-m 2048 -p 128KiB -s 512"
 
 Image/BuildKernel/Profile/P2812HNUF3=$(call Image/BuildKernel/Template,P2812HNUF3)
 Image/Build/Profile/P2812HNUF3=$(call Image/BuildNAND/$(1),$(1),P2812HNUF3)
@@ -660,8 +615,8 @@ endef
 TARGET_DEVICES += ARV7519RW22
 
 
-BTHOMEHUBV5A_UBIFS_OPTS:="-m 2048 -e 126KiB -c 4096"
-BTHOMEHUBV5A_UBI_OPTS:="-m 2048 -p 128KiB -s 512"
+DEVICE_BTHOMEHUBV5A_UBIFS_OPTS:="-m 2048 -e 126KiB -c 4096"
+DEVICE_BTHOMEHUBV5A_UBI_OPTS:="-m 2048 -p 128KiB -s 512"
 
 Image/BuildKernel/Profile/BTHOMEHUBV5A=$(call Image/BuildKernel/Template,BTHOMEHUBV5A)
 Image/Build/Profile/BTHOMEHUBV5A=$(call Image/BuildNAND/$(1),$(1),BTHOMEHUBV5A)
@@ -689,8 +644,8 @@ endef
 TARGET_DEVICES += EASY80920NOR
 
 
-FRITZ3370_UBIFS_OPTS:="-m 2048 -e 126KiB -c 4096"
-FRITZ3370_UBI_OPTS:="-m 2048 -p 128KiB -s 512"
+DEVICE_FRITZ3370_UBIFS_OPTS:="-m 2048 -e 126KiB -c 4096"
+DEVICE_FRITZ3370_UBI_OPTS:="-m 2048 -p 128KiB -s 512"
 
 Image/BuildKernel/Profile/FRITZ3370=$(call Image/BuildKernelEVA/Template,FRITZ3370)
 Image/Build/Profile/FRITZ3370=$(call Image/BuildEVA/$(1),$(1),FRITZ3370)
@@ -771,6 +726,39 @@ TARGET_DEVICES += VGV7519BRN
 
 endif
 
+ifneq ($($(PROFILE)_UBI_OPTS),)
+  define Image/BuildNAND/squashfs
+	$(call prepare_generic_squashfs,$(KDIR)/root.$(1))
+	$(call Image/Build/UbinizeImage,$(2),,squashfs,$($(PROFILE)_UBI_OPTS))
+	$(call Image/Build/SysupgradeNAND,$(2),$(1),$(KDIR)/uImage-$(2))
+  endef
+
+  define Image/Build/ubifs
+	$(CP) $(KDIR)/root.ubifs $(BIN_DIR)/$(IMG_PREFIX)-$(2)-rootfs.ubifs
+  endef
+
+  define Image/Build/ubi
+	$(CP) $(KDIR)/root.ubi $(BIN_DIR)/$(IMG_PREFIX)-$(2)-rootfs.ubi
+	$(CP) $(KDIR)/root-overlay.ubi $(BIN_DIR)/$(IMG_PREFIX)-$(2)-rootfs-overlay.ubi
+  endef
+
+  define Image/BuildEVA/ubi
+	$(CP) $(KDIR)/root.ubi $(BIN_DIR)/$(IMG_PREFIX)-$(2)-rootfs.ubi
+	$(CP) $(KDIR)/root-overlay.ubi $(BIN_DIR)/$(IMG_PREFIX)-$(2)-rootfs-overlay.ubi
+  endef
+
+ifneq ($($(PROFILE)_UBIFS_OPTS),)
+  define Image/BuildNAND/ubifs
+	$(call Image/Build/UbinizeImage,$(2),,ubifs,$($(PROFILE)_UBI_OPTS))
+	$(call Image/Build/SysupgradeNAND,$(2),$(1),$(KDIR)/uImage-$(2))
+  endef
+
+  define Image/BuildEVA/ubifs
+	$(CP) $(KDIR)/root.ubifs $(BIN_DIR)/$(IMG_PREFIX)-$(2)-rootfs.ubifs
+  endef
+endif
+endif
+
 define Image/Prepare/Profile
 	$(call Image/Prepare/Profile/$(1))
 endef
-- 
1.9.1



From dev at kresin.me  Sun Jun 19 07:33:44 2016
From: dev at kresin.me (Mathias Kresin)
Date: Sun, 19 Jun 2016 16:33:44 +0200
Subject: [LEDE-DEV] [PATCH] lantiq: diag - switch off the power led on
	failsafe
Message-ID: <1466346824-26282-1-git-send-email-dev@kresin.me>

This patch is a follow up to commit 4cf3fd4 "add support for indicating
the boot state using three leds".

At the time of writing the patch, I wasn't aware that it's possible to
switch info failsafe after boot (factory reset).

Enabling the failsafe led without disabling the running led causes an
unexpected led colour on devices using a single multicolour led to
indicate the boot state.

Signed-off-by: Mathias Kresin <dev at kresin.me>
---
 target/linux/lantiq/base-files/etc/diag.sh | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/target/linux/lantiq/base-files/etc/diag.sh b/target/linux/lantiq/base-files/etc/diag.sh
index 71d6f3e..f6363b3 100644
--- a/target/linux/lantiq/base-files/etc/diag.sh
+++ b/target/linux/lantiq/base-files/etc/diag.sh
@@ -17,6 +17,10 @@ set_state() {
 		;;
 	failsafe)
 		status_led_off
+		[ -n "$running" ] && {
+			status_led="$running"
+			status_led_off
+		}
 		status_led="$failsafe"
 		status_led_blink_failsafe
 		;;
-- 
1.9.1



From dev at kresin.me  Sun Jun 19 07:34:47 2016
From: dev at kresin.me (Mathias Kresin)
Date: Sun, 19 Jun 2016 16:34:47 +0200
Subject: [LEDE-DEV] [PATCH] lantiq: BTHOMEHUBV5A - use the power event code
	for the restart button
Message-ID: <1466346887-26459-1-git-send-email-dev@kresin.me>

The restart event code is used in LEDE to trigger a factory reset on
long press as well.

By using the power event code, the restart functionality can be used
without being prone to trigger a factory reset.

Signed-off-by: Mathias Kresin <dev at kresin.me>
---
 target/linux/lantiq/dts/BTHOMEHUBV5A.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/lantiq/dts/BTHOMEHUBV5A.dts b/target/linux/lantiq/dts/BTHOMEHUBV5A.dts
index e62a18d..2013b31 100644
--- a/target/linux/lantiq/dts/BTHOMEHUBV5A.dts
+++ b/target/linux/lantiq/dts/BTHOMEHUBV5A.dts
@@ -158,7 +158,7 @@
 		restart {
 			label = "restart";
 			gpios = <&gpio 39 1>;
-			linux,code = <0x198>;
+			linux,code = <0x74>;
 		};
 	};
 
-- 
1.9.1



From daniel at daniel.thecshore.com  Sat Jun 18 19:14:41 2016
From: daniel at daniel.thecshore.com (Daniel Curran-Dickinson)
Date: Sat, 18 Jun 2016 22:14:41 -0400
Subject: [LEDE-DEV] Me prioritizing work on automated bug report data
	collection
Message-ID: <1466302481.2745.5.camel@homehost>

Hi,

I'm thinking since I'll be having limited time to LEDE for a while that
once we know what we're doing for bug report system that I should
prioritize the LuCI and command line bug report info tool (to maximize
usefulness of bug reports) and that's probably the most useful thing I
can work on in the short term for the project as a whole.

Does that make sense?

In the meantime I'm compile testing the ACL patch for the two kernels I
can run an image on, as well as retesting fully on ar71xx, because it's
something just about read to go that I said I'd work on.

I also intend to respect Felix's working on the multi profile things and
get at least ar71xx converted completely.  (Other archs except x86 where
it doesn't really apply, I can't actually test so I'm not sure much
sense it makes for me to work on them).

Regards,

Daniel



From daniel at daniel.thecshore.com  Sun Jun 19 11:05:33 2016
From: daniel at daniel.thecshore.com (Daniel Curran-Dickinson)
Date: Sun, 19 Jun 2016 14:05:33 -0400
Subject: [LEDE-DEV] lede integration issues remaining from the detrius
 of cerowrt
In-Reply-To: <alpine.DEB.2.02.1606160046050.1832@nftneq.ynat.uz>
References: <CAA93jw7=bHNXJqmjWmg3CHHH-biua17wK4AHfn_wB0wPWs=EqQ@mail.gmail.com>
 <CAJOqq5TB4qki1iWHZd71kzXYoA=A3+4BeycoNPKqRXFWZ6bMZQ@mail.gmail.com>
 <f6898485-e1d4-ec35-4563-4591512d2d84@mein.io>
 <1465868455.2580.35.camel@homehost>
 <alpine.DEB.2.02.1606141048400.2494@nftneq.ynat.uz>
 <1465939839.2633.29.camel@homehost>
 <alpine.DEB.2.02.1606160046050.1832@nftneq.ynat.uz>
Message-ID: <1466359533.2745.9.camel@homehost>

Hi David,

Thanks for the good info on wear levelling; apparently I was misinformed
on the topic.


On Thu, 2016-06-16 at 01:03 -0700, David Lang wrote: [snip] 
> >>> To a certain extent though, I question the need for something as restricted as OpenWrt
> >>> for the new bigger devices anyway; there are elements like netifd that would be good to
> >>> see continue, but I'm not sure that most of OpenWrt really makes as much sense when you're
> >>> not needing to squeeze maximum use out of very erase block, and that therefore, while it
> >>> may be a smaller market/mindshare, that focussing on the the true embedded type scenario,
> >>> seems to be more of what LEDE's niche is.
> >>
> >> LEDE/OpenWRT is a good fit for any device that operates on raw flash instead of
> >> a hard drive or ssd with wear leveling. Once you have storage that you don't
> >> worry about wearing out and is large enough to hold a normal Linux Distro, it
> >
> > makes sense to move to such a distro and update packages individually.
> >
> > Hmmm...the wear levelling thing is confusing.  I was told by someone who I thought knew
> > what they were talking about, that flash chips included some form of hardware-based
> > wear levelling built in already.  Apparently that is was inaccurate (hardware-level
> > support is something I only having minor knowledge of; it's not the part the interests me,
> > nor where I have worked on it for any length of time; I'm more interested in what you can
> > do with existing hardware support combined with software rather developing the core support
> > itself).
> 
> raw flash chips like we have in a router have nothing.
> 
> flash chips packaged in SD cards, USB drives, etc commonly have very primitive 
> wear leveling (in many cases only targeted at the places that the FAT filesystem 
> is going to use)
> 
> flash chips packaged into SSD drives or anything more sophisticated tend to have 
> very extensive wear leveling setups, and will move existing, unmodified data if 
> needed to balance things.
> 
> I haven't looked recently, but a couple years ago the idea of having an 
> in-kernel flash wear leveling capability was getting a lot of discussion on the 
> kernel mailing list. I din't remember seeing what finally happened with that.
> 
> For the very tiny devices, it doesn't make sense to try and make use of 
> something like that (it takes more space ond isn't going to apply to a static, 
> pre-build compressed filesystem)
> 
> But for the overlay filesystem where new stuff may get added on newer devices 
> that have the much larger NAND flash, it may be something to look into, even 
> though it complicates the base config for such systems.
> 

Okay, I understand a lot better where you are coming from now, since I
was under a misapprehension about the capabilities of the hardware.  In
this case I agree we need to do some work to support these bigger
devices including things like wear-levelling, and that this is
definitely a space in which LEDE can be relevant going forward.

Regards,

Daniel 



From daniel at daniel.thecshore.com  Sun Jun 19 11:08:09 2016
From: daniel at daniel.thecshore.com (Daniel Curran-Dickinson)
Date: Sun, 19 Jun 2016 14:08:09 -0400
Subject: [LEDE-DEV] lede integration issues remaining from the detrius
 of cerowrt
In-Reply-To: <CAKNoO9oLbR6ipAG2X_GAvn2CeVdfapP4qhH-Mut=CjrC3iBUkg@mail.gmail.com>
References: <CAA93jw7=bHNXJqmjWmg3CHHH-biua17wK4AHfn_wB0wPWs=EqQ@mail.gmail.com>
 <CAJOqq5TB4qki1iWHZd71kzXYoA=A3+4BeycoNPKqRXFWZ6bMZQ@mail.gmail.com>
 <f6898485-e1d4-ec35-4563-4591512d2d84@mein.io>
 <1465868455.2580.35.camel@homehost>
 <alpine.DEB.2.02.1606141048400.2494@nftneq.ynat.uz>
 <1465939839.2633.29.camel@homehost>
 <alpine.DEB.2.02.1606160046050.1832@nftneq.ynat.uz>
 <CAKNoO9oLbR6ipAG2X_GAvn2CeVdfapP4qhH-Mut=CjrC3iBUkg@mail.gmail.com>
Message-ID: <1466359689.2745.11.camel@homehost>

On Thu, 2016-06-16 at 10:34 -0400, Aaron Z wrote: 
> On Thu, Jun 16, 2016 at 4:03 AM, David Lang <david at lang.hm> wrote:
> > With Imagebuilder and things pre-compiled, what does it take to create an
> > image? I'm wondering if this is something that can be converted to a web UI
> > where we could have someone select stuff (or upload a config file) and have
> > the system spit out a custom tailored image a few seconds later.
> >
> > Something like this could do wonders to move people away from the 'base
> > image must contain what I need' mentality.
> Personally, I would like that (and wouldn't have a problem with
> waiting a half hour or an hour for a build to be done).
> For example, I don't need PPOE support on any of the hardware I use,
> many of the devices don't have a USB port, so I don't need USB
> support, its internal on an IPV4 network, so I don't need IPV6
> support, it would be nice to have Nano installed by default (hard to
> use vi over ssh from a phone that doesn't have an escape key :D).
> But that's just the perspective of a end user/sysadmin who has been
> using OpenWrt (and now LEDE) for 7-10 years.

TBH I think the biggest reasons this hasn't already is:

1) People who want it don't care enough to work on it, or are the people
who don't know how to work it and and can't/don't fund someone who does.
2) Infrastructure:  You need a server to host on and storage etc, and
this costs money or donations.



From david at lang.hm  Sun Jun 19 12:35:37 2016
From: david at lang.hm (David Lang)
Date: Sun, 19 Jun 2016 12:35:37 -0700 (PDT)
Subject: [LEDE-DEV] lede integration issues remaining from the detrius
 of cerowrt
In-Reply-To: <1466359689.2745.11.camel@homehost>
References: <CAA93jw7=bHNXJqmjWmg3CHHH-biua17wK4AHfn_wB0wPWs=EqQ@mail.gmail.com>
 <CAJOqq5TB4qki1iWHZd71kzXYoA=A3+4BeycoNPKqRXFWZ6bMZQ@mail.gmail.com>
 <f6898485-e1d4-ec35-4563-4591512d2d84@mein.io>
 <1465868455.2580.35.camel@homehost>
 <alpine.DEB.2.02.1606141048400.2494@nftneq.ynat.uz>
 <1465939839.2633.29.camel@homehost>
 <alpine.DEB.2.02.1606160046050.1832@nftneq.ynat.uz>
 <CAKNoO9oLbR6ipAG2X_GAvn2CeVdfapP4qhH-Mut=CjrC3iBUkg@mail.gmail.com>
 <1466359689.2745.11.camel@homehost>
Message-ID: <alpine.DEB.2.02.1606191234020.2259@nftneq.ynat.uz>

On Sun, 19 Jun 2016, Daniel Curran-Dickinson wrote:

> On Thu, 2016-06-16 at 10:34 -0400, Aaron Z wrote:
>> On Thu, Jun 16, 2016 at 4:03 AM, David Lang <david at lang.hm> wrote:
>>> With Imagebuilder and things pre-compiled, what does it take to create an
>>> image? I'm wondering if this is something that can be converted to a web UI
>>> where we could have someone select stuff (or upload a config file) and have
>>> the system spit out a custom tailored image a few seconds later.
>>>
>>> Something like this could do wonders to move people away from the 'base
>>> image must contain what I need' mentality.
>> Personally, I would like that (and wouldn't have a problem with
>> waiting a half hour or an hour for a build to be done).
>> For example, I don't need PPOE support on any of the hardware I use,
>> many of the devices don't have a USB port, so I don't need USB
>> support, its internal on an IPV4 network, so I don't need IPV6
>> support, it would be nice to have Nano installed by default (hard to
>> use vi over ssh from a phone that doesn't have an escape key :D).
>> But that's just the perspective of a end user/sysadmin who has been
>> using OpenWrt (and now LEDE) for 7-10 years.
>
> TBH I think the biggest reasons this hasn't already is:
>
> 1) People who want it don't care enough to work on it, or are the people
> who don't know how to work it and and can't/don't fund someone who does.
> 2) Infrastructure:  You need a server to host on and storage etc, and
> this costs money or donations.

or don't know how to contribute funds to make something like this work.

the LEDE home page under the "how can I help" talks about development and the 
mailing list. I says nothing about how to contribute money or equipment.

David Lang


From daniel at daniel.thecshore.com  Sun Jun 19 11:38:33 2016
From: daniel at daniel.thecshore.com (Daniel Curran-Dickinson)
Date: Sun, 19 Jun 2016 14:38:33 -0400
Subject: [LEDE-DEV] looking for ar7 testers
In-Reply-To: <alpine.DEB.2.02.1606150125080.6774@nftneq.ynat.uz>
References: <3031035b-004b-2cea-63ec-580fcfd83bab@phrozen.org>
 <alpine.DEB.2.02.1606150125080.6774@nftneq.ynat.uz>
Message-ID: <1466361513.2745.25.camel@homehost>

On Wed, 2016-06-15 at 19:52 -0700, David Lang wrote: 
> Is there a list of hardware that is needed? (or do you want donations of money 
> for the project to buy hardware)?

TBH I'm not sure how useful random hardware donations are.  For example
getting a router which is more than just updating image generation
specifics (and assuming there is even enough information available via
flash browsing etc to do that, which isn't always the case), there is
the problem most chips manufacturers don't talk to random developer X,
and only want to give data sheets and programming information to people
who sign an NDA and have a support contract, presumably with contracts
to by X units from ODM who is actually the one making the information
available, or enabling the request).

Dealing with unsupported hardware is not something developers can often
do something about simply by having random device X.  If it's just image
generation usually it can be figured out, but beyond that it normally
requires some level of information that isn't easy to discover simply by
having a device.

Regards,

Daniel



From daniel at daniel.thecshore.com  Sun Jun 19 11:17:09 2016
From: daniel at daniel.thecshore.com (Daniel Curran-Dickinson)
Date: Sun, 19 Jun 2016 14:17:09 -0400
Subject: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
In-Reply-To: <CAJOqq5RYiXzc8Dx3HSZBcYYXaaZsbNvZeN1i8F3Ypdwt+Jb_1w@mail.gmail.com>
References: <5761BB29.8020303@prplfoundation.org>
 <CAJOqq5S314FgBswNo2KheO6VzvFr6jaMP=khXEWONSBnogJYLg@mail.gmail.com>
 <alpine.DEB.2.02.1606151502140.2494@nftneq.ynat.uz>
 <CAJOqq5SxXQH_BG3wP=1W7FVN9kptQvkdLc4V5r+ad4u4dRhw=Q@mail.gmail.com>
 <ab942f91-6e75-41b4-5573-ae533cceb18b@klam.ca>
 <922b01ca-bde3-7818-421f-2fb7bf69f7c0@phrozen.org>
 <CAJOqq5SdZf=xjQRJsaaYaSunueNtBnzd8pNMHeh+rooAEDy2JA@mail.gmail.com>
 <CAJOqq5TXNNFteDq2fm79Gu7aojsMqJHP7PaQUaa_gYJfiod2TA@mail.gmail.com>
 <e9a077f6-eda5-7ace-794b-14e6c8ca463b@phrozen.org>
 <CAJOqq5RYiXzc8Dx3HSZBcYYXaaZsbNvZeN1i8F3Ypdwt+Jb_1w@mail.gmail.com>
Message-ID: <1466360229.2745.19.camel@homehost>

On Thu, 2016-06-16 at 02:50 -0500, L. D. Pinney wrote: 
> From the OP
> 
> I wanted to ask folks whether they want me to continue to cross post to these
> 

Quite frankly I think it's great that companies are stepping up and
contributing back - I think the lack of that is a frustration that more
than just I have experienced.

The reality is that if it benefits the community there is not reason to
not accept corporate input, and in fact getting paid work to help the
project is essentially and the main way that happens in open source is
if companies feel inspired to contribute back to the project because it
benefits them.

The linux kernel would not be where it is today (in a lot of good ways)
without paid corporate input.

In case you have failed to notice these statistics, the vast majority of
work done on open source projects *as a whole* is not by unpaid
volunteers such as myself (who have limited time to devote to such
pursuits) but by people who have corporate sponsorship to do the work.
I don't know about you, but I have to work to pay for the things my
family needs, and unless you're *lucky* that work typically doesn't
involve an ideal world chance to work on open source projects without
any concerns about IP etc from management.

You seem to be even more hostile than I sometimes get (and now have
implemented a solution so I "don't post impulsively").  I've arranged it
so I make myself think before I post and I think most folks will agree
that is a good thing.

Regards,

Daniel



From daniel at daniel.thecshore.com  Sun Jun 19 13:59:26 2016
From: daniel at daniel.thecshore.com (Daniel Curran-Dickinson)
Date: Sun, 19 Jun 2016 16:59:26 -0400
Subject: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?
In-Reply-To: <CAA93jw4FR0Evpkm4CNuEvZqJK-uqzyUn8LZnM5AqFd5Jh3piow@mail.gmail.com>
References: <5761BB29.8020303@prplfoundation.org>
 <CAJOqq5S314FgBswNo2KheO6VzvFr6jaMP=khXEWONSBnogJYLg@mail.gmail.com>
 <alpine.DEB.2.02.1606151502140.2494@nftneq.ynat.uz>
 <CAJOqq5SxXQH_BG3wP=1W7FVN9kptQvkdLc4V5r+ad4u4dRhw=Q@mail.gmail.com>
 <alpine.DEB.2.02.1606151512470.2494@nftneq.ynat.uz>
 <CAJOqq5TYpOKn0mmtO+fSmCoHyZr9Rvss_cGbZfRnEOqbwTLXEw@mail.gmail.com>
 <CAA93jw4FR0Evpkm4CNuEvZqJK-uqzyUn8LZnM5AqFd5Jh3piow@mail.gmail.com>
Message-ID: <1466369966.2745.29.camel@homehost>

On Wed, 2016-06-15 at 16:55 -0700, Dave Taht wrote: 
> On Wed, Jun 15, 2016 at 3:22 PM, L. D. Pinney <ldpinney at gmail.com> wrote:
> > It's a Development List ... no place for corporate agendas.
> 
> I think you are making a good point here, being that there is only one
> lede list, presently, and devs would like to just see dev related
> traffic....
> 
> Personally I find it incredibly difficult to sort through the patch
> volume on this (and linux-wireless), and would welcome a forum (web or
> email) to be able to discuss other matters.  I was invited several

Silly question, but when you're interested in topics other than patches,
wouldn't a simple filter that shoves [PATCH] subjects in another folder
mitigate the majority of this?

Regards,

Daniel



From daniel at daniel.thecshore.com  Sun Jun 19 13:27:24 2016
From: daniel at daniel.thecshore.com (Daniel Curran-Dickinson)
Date: Sun, 19 Jun 2016 16:27:24 -0400
Subject: [LEDE-DEV] lede integration issues remaining from the detrius
 of cerowrt
In-Reply-To: <alpine.DEB.2.02.1606191234020.2259@nftneq.ynat.uz>
References: <CAA93jw7=bHNXJqmjWmg3CHHH-biua17wK4AHfn_wB0wPWs=EqQ@mail.gmail.com>
 <CAJOqq5TB4qki1iWHZd71kzXYoA=A3+4BeycoNPKqRXFWZ6bMZQ@mail.gmail.com>
 <f6898485-e1d4-ec35-4563-4591512d2d84@mein.io>
 <1465868455.2580.35.camel@homehost>
 <alpine.DEB.2.02.1606141048400.2494@nftneq.ynat.uz>
 <1465939839.2633.29.camel@homehost>
 <alpine.DEB.2.02.1606160046050.1832@nftneq.ynat.uz>
 <CAKNoO9oLbR6ipAG2X_GAvn2CeVdfapP4qhH-Mut=CjrC3iBUkg@mail.gmail.com>
 <1466359689.2745.11.camel@homehost>
 <alpine.DEB.2.02.1606191234020.2259@nftneq.ynat.uz>
Message-ID: <1466368044.2745.27.camel@homehost>

On Sun, 2016-06-19 at 12:35 -0700, David Lang wrote: 
> On Sun, 19 Jun 2016, Daniel Curran-Dickinson wrote:
> 
> > On Thu, 2016-06-16 at 10:34 -0400, Aaron Z wrote:
> >> On Thu, Jun 16, 2016 at 4:03 AM, David Lang <david at lang.hm> wrote:
> >>> With Imagebuilder and things pre-compiled, what does it take to create an
> >>> image? I'm wondering if this is something that can be converted to a web UI
> >>> where we could have someone select stuff (or upload a config file) and have
> >>> the system spit out a custom tailored image a few seconds later.
> >>>
> >>> Something like this could do wonders to move people away from the 'base
> >>> image must contain what I need' mentality.
> >> Personally, I would like that (and wouldn't have a problem with
> >> waiting a half hour or an hour for a build to be done).
> >> For example, I don't need PPOE support on any of the hardware I use,
> >> many of the devices don't have a USB port, so I don't need USB
> >> support, its internal on an IPV4 network, so I don't need IPV6
> >> support, it would be nice to have Nano installed by default (hard to
> >> use vi over ssh from a phone that doesn't have an escape key :D).
> >> But that's just the perspective of a end user/sysadmin who has been
> >> using OpenWrt (and now LEDE) for 7-10 years.
> >
> > TBH I think the biggest reasons this hasn't already is:
> >
> > 1) People who want it don't care enough to work on it, or are the people
> > who don't know how to work it and and can't/don't fund someone who does.
> > 2) Infrastructure:  You need a server to host on and storage etc, and
> > this costs money or donations.
> 
> or don't know how to contribute funds to make something like this work.

That's what I meant by can't (and I agree that having some means of
hooking up community funders with community developers would be helpfu;
kind of like prpl but for community).

> 
> the LEDE home page under the "how can I help" talks about development and the 
> mailing list. I says nothing about how to contribute money or equipment.
> 
> David Lang
> 





From david at lang.hm  Sun Jun 19 17:45:48 2016
From: david at lang.hm (David Lang)
Date: Sun, 19 Jun 2016 17:45:48 -0700 (PDT)
Subject: [LEDE-DEV] lede integration issues remaining from the detrius
 of cerowrt
In-Reply-To: <1466368044.2745.27.camel@homehost>
References: <CAA93jw7=bHNXJqmjWmg3CHHH-biua17wK4AHfn_wB0wPWs=EqQ@mail.gmail.com>
 <CAJOqq5TB4qki1iWHZd71kzXYoA=A3+4BeycoNPKqRXFWZ6bMZQ@mail.gmail.com>
 <f6898485-e1d4-ec35-4563-4591512d2d84@mein.io>
 <1465868455.2580.35.camel@homehost> 
 <alpine.DEB.2.02.1606141048400.2494@nftneq.ynat.uz>
 <1465939839.2633.29.camel@homehost>
 <alpine.DEB.2.02.1606160046050.1832@nftneq.ynat.uz>
 <CAKNoO9oLbR6ipAG2X_GAvn2CeVdfapP4qhH-Mut=CjrC3iBUkg@mail.gmail.com>
 <1466359689.2745.11.camel@homehost> 
 <alpine.DEB.2.02.1606191234020.2259@nftneq.ynat.uz>
 <1466368044.2745.27.camel@homehost>
Message-ID: <alpine.DEB.2.02.1606191743240.3135@nftneq.ynat.uz>

On Sun, 19 Jun 2016, Daniel Curran-Dickinson wrote:

> On Sun, 2016-06-19 at 12:35 -0700, David Lang wrote:
>> On Sun, 19 Jun 2016, Daniel Curran-Dickinson wrote:
>>
>>> On Thu, 2016-06-16 at 10:34 -0400, Aaron Z wrote:
>>>> On Thu, Jun 16, 2016 at 4:03 AM, David Lang <david at lang.hm> wrote:
>>>>> With Imagebuilder and things pre-compiled, what does it take to create an
>>>>> image? I'm wondering if this is something that can be converted to a web UI
>>>>> where we could have someone select stuff (or upload a config file) and have
>>>>> the system spit out a custom tailored image a few seconds later.
>>>>>
>>>>> Something like this could do wonders to move people away from the 'base
>>>>> image must contain what I need' mentality.
>>>> Personally, I would like that (and wouldn't have a problem with
>>>> waiting a half hour or an hour for a build to be done).
>>>> For example, I don't need PPOE support on any of the hardware I use,
>>>> many of the devices don't have a USB port, so I don't need USB
>>>> support, its internal on an IPV4 network, so I don't need IPV6
>>>> support, it would be nice to have Nano installed by default (hard to
>>>> use vi over ssh from a phone that doesn't have an escape key :D).
>>>> But that's just the perspective of a end user/sysadmin who has been
>>>> using OpenWrt (and now LEDE) for 7-10 years.
>>>
>>> TBH I think the biggest reasons this hasn't already is:
>>>
>>> 1) People who want it don't care enough to work on it, or are the people
>>> who don't know how to work it and and can't/don't fund someone who does.
>>> 2) Infrastructure:  You need a server to host on and storage etc, and
>>> this costs money or donations.
>>
>> or don't know how to contribute funds to make something like this work.
>
> That's what I meant by can't (and I agree that having some means of
> hooking up community funders with community developers would be helpfu;
> kind of like prpl but for community).

I was calling out the difference between "I don't have money to contribute" and 
"I have money I could send, but I don't know who to give it to"

The first is something the project can't do anything about, the second will cost 
some effort (setting up the ability to receive donations and policies/processes 
to use the donations), but properly done (assuming people are willing to send 
money/equipment) could be a net win for the project.

David Lang


From david at lang.hm  Sun Jun 19 17:51:29 2016
From: david at lang.hm (David Lang)
Date: Sun, 19 Jun 2016 17:51:29 -0700 (PDT)
Subject: [LEDE-DEV] looking for ar7 testers
In-Reply-To: <1466361513.2745.25.camel@homehost>
References: <3031035b-004b-2cea-63ec-580fcfd83bab@phrozen.org>
 <alpine.DEB.2.02.1606150125080.6774@nftneq.ynat.uz>
 <1466361513.2745.25.camel@homehost>
Message-ID: <alpine.DEB.2.02.1606191746180.3135@nftneq.ynat.uz>

On Sun, 19 Jun 2016, Daniel Curran-Dickinson wrote:

> On Wed, 2016-06-15 at 19:52 -0700, David Lang wrote:
>> Is there a list of hardware that is needed? (or do you want donations of money
>> for the project to buy hardware)?
>
> TBH I'm not sure how useful random hardware donations are.  For example
> getting a router which is more than just updating image generation
> specifics (and assuming there is even enough information available via
> flash browsing etc to do that, which isn't always the case), there is
> the problem most chips manufacturers don't talk to random developer X,
> and only want to give data sheets and programming information to people
> who sign an NDA and have a support contract, presumably with contracts
> to by X units from ODM who is actually the one making the information
> available, or enabling the request).
>
> Dealing with unsupported hardware is not something developers can often
> do something about simply by having random device X.  If it's just image
> generation usually it can be figured out, but beyond that it normally
> requires some level of information that isn't easy to discover simply by
> having a device.

Well, I'll point out that the thread I'm replying to started off with "I no 
longer have the hardware to test this"

I agree that random, unsolicited donations are likely to be less useful, but 
donations of hardware to solve the "I can't test this" or add to a test farm are 
directly useful.

And getting a new piece of equipment can get a developer interested enough to go 
after the NDAs needed to make it work well.

In some cases the vendors involved are known to 'not play well with others' and 
so donations of their hardware will do no good.

But those of us out in the wild can't tell the difference between the different 
categories.

That's why I asked for a list of what would be useful to donate :-)

David Lang


From gang.zhao.42 at gmail.com  Sun Jun 19 20:15:43 2016
From: gang.zhao.42 at gmail.com (Zhao, Gang)
Date: Mon, 20 Jun 2016 11:15:43 +0800
Subject: [LEDE-DEV] [PATCH] lantiq: fix network in failsafe
In-Reply-To: <1466346655-25914-1-git-send-email-dev@kresin.me>
References: <1466346655-25914-1-git-send-email-dev@kresin.me>
Message-ID: <CAA3=zZh7ZpkfvOi5oAVB92WM7vWDjJh=WG_VpG3ewO+6vr=dGQ@mail.gmail.com>

Hi, Mathias Kresin

On Sun, Jun 19, 2016 at 10:30 PM, Mathias Kresin <dev at kresin.me> wrote:
> So far the network in failsafe is setup only for one board. Use the
> eth0 interface as lan interface for all boards for now.
>
> If a board has its lan interface(s) on another eth, a special
> handling based on the board name can be added.
>
> Signed-off-by: Mathias Kresin <dev at kresin.me>
> ---
>  .../lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq  | 10 +---------
>  1 file changed, 1 insertion(+), 9 deletions(-)
>
> diff --git a/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq b/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
> index 3d7fabf..7ed0fab 100644
> --- a/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
> +++ b/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
> @@ -3,15 +3,7 @@
>  . /lib/functions/lantiq.sh
>
>  set_preinit_iface() {
> -
> -       board=$(lantiq_board_name)
> -
> -       case "$board" in
> -       TDW8970)
> -               ifname=eth0
> -               ;;
> -       esac
> -
> +       ifname=eth0

What about to add a default branch in case statement?

*)
    ifname=eth0
;;

>  }
>
>  boot_hook_add preinit_main set_preinit_iface
> --
> 1.9.1
>
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


From john at phrozen.org  Sun Jun 19 22:15:55 2016
From: john at phrozen.org (John Crispin)
Date: Mon, 20 Jun 2016 07:15:55 +0200
Subject: [LEDE-DEV] looking for ar7 testers
In-Reply-To: <alpine.DEB.2.02.1606191746180.3135@nftneq.ynat.uz>
References: <3031035b-004b-2cea-63ec-580fcfd83bab@phrozen.org>
 <alpine.DEB.2.02.1606150125080.6774@nftneq.ynat.uz>
 <1466361513.2745.25.camel@homehost>
 <alpine.DEB.2.02.1606191746180.3135@nftneq.ynat.uz>
Message-ID: <bc5b3e3f-5e3b-21ff-3fb1-72906a12cdb8@phrozen.org>



On 20/06/2016 02:51, David Lang wrote:
> On Sun, 19 Jun 2016, Daniel Curran-Dickinson wrote:
> 
>> On Wed, 2016-06-15 at 19:52 -0700, David Lang wrote:
>>> Is there a list of hardware that is needed? (or do you want donations
>>> of money
>>> for the project to buy hardware)?
>>
>> TBH I'm not sure how useful random hardware donations are.  For example
>> getting a router which is more than just updating image generation
>> specifics (and assuming there is even enough information available via
>> flash browsing etc to do that, which isn't always the case), there is
>> the problem most chips manufacturers don't talk to random developer X,
>> and only want to give data sheets and programming information to people
>> who sign an NDA and have a support contract, presumably with contracts
>> to by X units from ODM who is actually the one making the information
>> available, or enabling the request).
>>
>> Dealing with unsupported hardware is not something developers can often
>> do something about simply by having random device X.  If it's just image
>> generation usually it can be figured out, but beyond that it normally
>> requires some level of information that isn't easy to discover simply by
>> having a device.
> 
> Well, I'll point out that the thread I'm replying to started off with "I
> no longer have the hardware to test this"
> 
> I agree that random, unsolicited donations are likely to be less useful,
> but donations of hardware to solve the "I can't test this" or add to a
> test farm are directly useful.
> 
> And getting a new piece of equipment can get a developer interested
> enough to go after the NDAs needed to make it work well.
> 
> In some cases the vendors involved are known to 'not play well with
> others' and so donations of their hardware will do no good.
> 
> But those of us out in the wild can't tell the difference between the
> different categories.
> 
> That's why I asked for a list of what would be useful to donate :-)
> 
> David Lang

how is this related to "i am looking for ar7 maintainers and testers" ?
please try to stay on topic


From john at phrozen.org  Sun Jun 19 22:19:29 2016
From: john at phrozen.org (John Crispin)
Date: Mon, 20 Jun 2016 07:19:29 +0200
Subject: [LEDE-DEV] [PATCH] lantiq: fix network in failsafe
In-Reply-To: <CAA3=zZh7ZpkfvOi5oAVB92WM7vWDjJh=WG_VpG3ewO+6vr=dGQ@mail.gmail.com>
References: <1466346655-25914-1-git-send-email-dev@kresin.me>
 <CAA3=zZh7ZpkfvOi5oAVB92WM7vWDjJh=WG_VpG3ewO+6vr=dGQ@mail.gmail.com>
Message-ID: <d7c745f5-6a07-3a7a-31bf-af0abc20fbd5@phrozen.org>



On 20/06/2016 05:15, Zhao, Gang wrote:
> Hi, Mathias Kresin
> 
> On Sun, Jun 19, 2016 at 10:30 PM, Mathias Kresin <dev at kresin.me> wrote:
>> So far the network in failsafe is setup only for one board. Use the
>> eth0 interface as lan interface for all boards for now.
>>
>> If a board has its lan interface(s) on another eth, a special
>> handling based on the board name can be added.
>>
>> Signed-off-by: Mathias Kresin <dev at kresin.me>
>> ---
>>  .../lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq  | 10 +---------
>>  1 file changed, 1 insertion(+), 9 deletions(-)
>>
>> diff --git a/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq b/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
>> index 3d7fabf..7ed0fab 100644
>> --- a/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
>> +++ b/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
>> @@ -3,15 +3,7 @@
>>  . /lib/functions/lantiq.sh
>>
>>  set_preinit_iface() {
>> -
>> -       board=$(lantiq_board_name)
>> -
>> -       case "$board" in
>> -       TDW8970)
>> -               ifname=eth0
>> -               ;;
>> -       esac
>> -
>> +       ifname=eth0
> 
> What about to add a default branch in case statement?
> 
> *)
>     ifname=eth0
> ;;
> 

i am wondering if we should add a switch default config here or simply
reset the switch with vlans turned off

	John

>>  }
>>
>>  boot_hook_add preinit_main set_preinit_iface
>> --
>> 1.9.1
>>
>>
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 


From eyal.birger at gmail.com  Sun Jun 19 22:36:47 2016
From: eyal.birger at gmail.com (Eyal Birger)
Date: Mon, 20 Jun 2016 08:36:47 +0300
Subject: [LEDE-DEV] [PATCH] uloop: handle waker pipe write() return value
Message-ID: <1466401007-30322-1-git-send-email-eyal.birger@gmail.com>

Recent glibc warns if result of read() or write() is unused.

Added a retry in case of EINTR, all other faults are silently discarded.

Signed-off-by: Eyal Birger <eyal.birger at gmail.com>

-----
- I was not able to reproduce the EINTR case, but it seems to be the right
  thing to do
- Retrying on EAGAIN in this case would be weird as there is no one to read
  from the other end of the pipe. We could call waker_consume() directly but
  since the size of the message is just one byte, I think this would be dead
  code
---
 uloop.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/uloop.c b/uloop.c
index e60fb09..fd315c0 100644
--- a/uloop.c
+++ b/uloop.c
@@ -386,7 +386,13 @@ static void uloop_handle_processes(void)
 
 static void uloop_signal_wake(void)
 {
-	write(waker_pipe, "w", 1);
+	do {
+		if (write(waker_pipe, "w", 1) < 0) {
+			if (errno == EINTR)
+				continue;
+		}
+		break;
+	} while (1);
 }
 
 static void uloop_handle_sigint(int signo)
-- 
1.9.1



From dev at kresin.me  Sun Jun 19 22:39:21 2016
From: dev at kresin.me (Mathias Kresin)
Date: Mon, 20 Jun 2016 07:39:21 +0200
Subject: [LEDE-DEV] [PATCH] lantiq: fix network in failsafe
In-Reply-To: <d7c745f5-6a07-3a7a-31bf-af0abc20fbd5@phrozen.org>
References: <1466346655-25914-1-git-send-email-dev@kresin.me>
 <CAA3=zZh7ZpkfvOi5oAVB92WM7vWDjJh=WG_VpG3ewO+6vr=dGQ@mail.gmail.com>
 <d7c745f5-6a07-3a7a-31bf-af0abc20fbd5@phrozen.org>
Message-ID: <57678189.60000@kresin.me>

Am 20.06.2016 um 07:19 schrieb John Crispin:
>
>
> On 20/06/2016 05:15, Zhao, Gang wrote:
>> Hi, Mathias Kresin
>>
>> On Sun, Jun 19, 2016 at 10:30 PM, Mathias Kresin <dev at kresin.me> wrote:
>>> So far the network in failsafe is setup only for one board. Use the
>>> eth0 interface as lan interface for all boards for now.
>>>
>>> If a board has its lan interface(s) on another eth, a special
>>> handling based on the board name can be added.
>>>
>>> Signed-off-by: Mathias Kresin <dev at kresin.me>
>>> ---
>>>   .../lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq  | 10 +---------
>>>   1 file changed, 1 insertion(+), 9 deletions(-)
>>>
>>> diff --git a/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq b/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
>>> index 3d7fabf..7ed0fab 100644
>>> --- a/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
>>> +++ b/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
>>> @@ -3,15 +3,7 @@
>>>   . /lib/functions/lantiq.sh
>>>
>>>   set_preinit_iface() {
>>> -
>>> -       board=$(lantiq_board_name)
>>> -
>>> -       case "$board" in
>>> -       TDW8970)
>>> -               ifname=eth0
>>> -               ;;
>>> -       esac
>>> -
>>> +       ifname=eth0
>>
>> What about to add a default branch in case statement?
>>
>> *)
>>      ifname=eth0
>> ;;
>>
>
> i am wondering if we should add a switch default config here or simply
> reset the switch with vlans turned off

Is it really necessary? I mean the failsafe kicks in long before the 
network config and vlan setup is done.

I've tested this with a board using the xrx200 in-SoC switch and a board 
using a RTL8306G switch. In both cases it wasn't necessary to turn off 
the vlans since they had not yet been configured.

Mathias



From john at phrozen.org  Sun Jun 19 22:40:30 2016
From: john at phrozen.org (John Crispin)
Date: Mon, 20 Jun 2016 07:40:30 +0200
Subject: [LEDE-DEV] [PATCH] lantiq: fix network in failsafe
In-Reply-To: <57678189.60000@kresin.me>
References: <1466346655-25914-1-git-send-email-dev@kresin.me>
 <CAA3=zZh7ZpkfvOi5oAVB92WM7vWDjJh=WG_VpG3ewO+6vr=dGQ@mail.gmail.com>
 <d7c745f5-6a07-3a7a-31bf-af0abc20fbd5@phrozen.org> <57678189.60000@kresin.me>
Message-ID: <d8147dfa-31a4-95f4-d9f5-4a46918b1728@phrozen.org>



On 20/06/2016 07:39, Mathias Kresin wrote:
> Am 20.06.2016 um 07:19 schrieb John Crispin:
>>
>>
>> On 20/06/2016 05:15, Zhao, Gang wrote:
>>> Hi, Mathias Kresin
>>>
>>> On Sun, Jun 19, 2016 at 10:30 PM, Mathias Kresin <dev at kresin.me> wrote:
>>>> So far the network in failsafe is setup only for one board. Use the
>>>> eth0 interface as lan interface for all boards for now.
>>>>
>>>> If a board has its lan interface(s) on another eth, a special
>>>> handling based on the board name can be added.
>>>>
>>>> Signed-off-by: Mathias Kresin <dev at kresin.me>
>>>> ---
>>>>   .../lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq  |
>>>> 10 +---------
>>>>   1 file changed, 1 insertion(+), 9 deletions(-)
>>>>
>>>> diff --git
>>>> a/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
>>>> b/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
>>>>
>>>> index 3d7fabf..7ed0fab 100644
>>>> ---
>>>> a/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
>>>>
>>>> +++
>>>> b/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
>>>>
>>>> @@ -3,15 +3,7 @@
>>>>   . /lib/functions/lantiq.sh
>>>>
>>>>   set_preinit_iface() {
>>>> -
>>>> -       board=$(lantiq_board_name)
>>>> -
>>>> -       case "$board" in
>>>> -       TDW8970)
>>>> -               ifname=eth0
>>>> -               ;;
>>>> -       esac
>>>> -
>>>> +       ifname=eth0
>>>
>>> What about to add a default branch in case statement?
>>>
>>> *)
>>>      ifname=eth0
>>> ;;
>>>
>>
>> i am wondering if we should add a switch default config here or simply
>> reset the switch with vlans turned off
> 
> Is it really necessary? I mean the failsafe kicks in long before the
> network config and vlan setup is done.
> 
> I've tested this with a board using the xrx200 in-SoC switch and a board
> using a RTL8306G switch. In both cases it wasn't necessary to turn off
> the vlans since they had not yet been configured.
> 
> Mathias
> 
this code also runs on danubes with rtl and ar8327 switches. some of
which have a default vlan setup provided by the bootloader

	John


From dev at kresin.me  Sun Jun 19 22:52:59 2016
From: dev at kresin.me (Mathias Kresin)
Date: Mon, 20 Jun 2016 07:52:59 +0200
Subject: [LEDE-DEV] [PATCH] lantiq: fix network in failsafe
In-Reply-To: <CAA3=zZh7ZpkfvOi5oAVB92WM7vWDjJh=WG_VpG3ewO+6vr=dGQ@mail.gmail.com>
References: <1466346655-25914-1-git-send-email-dev@kresin.me>
 <CAA3=zZh7ZpkfvOi5oAVB92WM7vWDjJh=WG_VpG3ewO+6vr=dGQ@mail.gmail.com>
Message-ID: <576784BB.8060608@kresin.me>

Am 20.06.2016 um 05:15 schrieb Zhao, Gang:
> Hi, Mathias Kresin
>
> On Sun, Jun 19, 2016 at 10:30 PM, Mathias Kresin <dev at kresin.me> wrote:
>> So far the network in failsafe is setup only for one board. Use the
>> eth0 interface as lan interface for all boards for now.
>>
>> If a board has its lan interface(s) on another eth, a special
>> handling based on the board name can be added.
>>
>> Signed-off-by: Mathias Kresin <dev at kresin.me>
>> ---
>>   .../lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq  | 10 +---------
>>   1 file changed, 1 insertion(+), 9 deletions(-)
>>
>> diff --git a/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq b/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
>> index 3d7fabf..7ed0fab 100644
>> --- a/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
>> +++ b/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
>> @@ -3,15 +3,7 @@
>>   . /lib/functions/lantiq.sh
>>
>>   set_preinit_iface() {
>> -
>> -       board=$(lantiq_board_name)
>> -
>> -       case "$board" in
>> -       TDW8970)
>> -               ifname=eth0
>> -               ;;
>> -       esac
>> -
>> +       ifname=eth0
>
> What about to add a default branch in case statement?
>
> *)
>      ifname=eth0
> ;;

Adding a default branch doesn't make any sense to me as long as the only 
value set in the default branch is the same as the one in the only 
conditional.

I had changed the case statement to only consists of a default case, to 
make obvious how to add a different config for a specific board. But in 
the end I dropped the whole case since it was just unused code.


From dev at kresin.me  Sun Jun 19 23:08:00 2016
From: dev at kresin.me (Mathias Kresin)
Date: Mon, 20 Jun 2016 08:08:00 +0200
Subject: [LEDE-DEV] [PATCH] lantiq: fix network in failsafe
In-Reply-To: <d8147dfa-31a4-95f4-d9f5-4a46918b1728@phrozen.org>
References: <1466346655-25914-1-git-send-email-dev@kresin.me>
 <CAA3=zZh7ZpkfvOi5oAVB92WM7vWDjJh=WG_VpG3ewO+6vr=dGQ@mail.gmail.com>
 <d7c745f5-6a07-3a7a-31bf-af0abc20fbd5@phrozen.org> <57678189.60000@kresin.me>
 <d8147dfa-31a4-95f4-d9f5-4a46918b1728@phrozen.org>
Message-ID: <57678840.6040400@kresin.me>

Am 20.06.2016 um 07:40 schrieb John Crispin:
>
>
> On 20/06/2016 07:39, Mathias Kresin wrote:
>> Am 20.06.2016 um 07:19 schrieb John Crispin:
>>>
>>>
>>> On 20/06/2016 05:15, Zhao, Gang wrote:
>>>> Hi, Mathias Kresin
>>>>
>>>> On Sun, Jun 19, 2016 at 10:30 PM, Mathias Kresin <dev at kresin.me> wrote:
>>>>> So far the network in failsafe is setup only for one board. Use the
>>>>> eth0 interface as lan interface for all boards for now.
>>>>>
>>>>> If a board has its lan interface(s) on another eth, a special
>>>>> handling based on the board name can be added.
>>>>>
>>>>> Signed-off-by: Mathias Kresin <dev at kresin.me>
>>>>> ---
>>>>>    .../lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq  |
>>>>> 10 +---------
>>>>>    1 file changed, 1 insertion(+), 9 deletions(-)
>>>>>
>>>>> diff --git
>>>>> a/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
>>>>> b/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
>>>>>
>>>>> index 3d7fabf..7ed0fab 100644
>>>>> ---
>>>>> a/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
>>>>>
>>>>> +++
>>>>> b/target/linux/lantiq/base-files/lib/preinit/05_set_preinit_iface_lantiq
>>>>>
>>>>> @@ -3,15 +3,7 @@
>>>>>    . /lib/functions/lantiq.sh
>>>>>
>>>>>    set_preinit_iface() {
>>>>> -
>>>>> -       board=$(lantiq_board_name)
>>>>> -
>>>>> -       case "$board" in
>>>>> -       TDW8970)
>>>>> -               ifname=eth0
>>>>> -               ;;
>>>>> -       esac
>>>>> -
>>>>> +       ifname=eth0
>>>>
>>>> What about to add a default branch in case statement?
>>>>
>>>> *)
>>>>       ifname=eth0
>>>> ;;
>>>>
>>>
>>> i am wondering if we should add a switch default config here or simply
>>> reset the switch with vlans turned off
>>
>> Is it really necessary? I mean the failsafe kicks in long before the
>> network config and vlan setup is done.
>>
>> I've tested this with a board using the xrx200 in-SoC switch and a board
>> using a RTL8306G switch. In both cases it wasn't necessary to turn off
>> the vlans since they had not yet been configured.
>>
>> Mathias
>>
> this code also runs on danubes with rtl and ar8327 switches. some of
> which have a default vlan setup provided by the bootloader
>
> 	John
>

Indeed, for these boards a reset of the vlan config, depending on the 
particular bootloader vlan config, might be necessary.

But I don't like the idea of adding a default switch config for boards 
where it isn't strictly required. Especially in a failsafe script. The 
more code we add, the more likely is a breakage or an unconsidered 
side-effect of a change.

Since I don't have any of the affected danube boards, adding support for 
this special case to the patch is out of scope for me. I don't like to 
add untested code.

Mathias


From mschiffer at universe-factory.net  Mon Jun 20 00:59:46 2016
From: mschiffer at universe-factory.net (Matthias Schiffer)
Date: Mon, 20 Jun 2016 09:59:46 +0200
Subject: [LEDE-DEV] [PATCH libubox 2/3] loop: make uloop_run() return the
	cancelling signal
In-Reply-To: <ad8ab0cdf8d6148e7a514dcb90a8492fd272fe37.1466409587.git.mschiffer@universe-factory.net>
References: <ad8ab0cdf8d6148e7a514dcb90a8492fd272fe37.1466409587.git.mschiffer@universe-factory.net>
Message-ID: <22d591176c7b3512ceabddf439a6d6ab682288d1.1466409587.git.mschiffer@universe-factory.net>

When a process quits in response to a signal it handles, it should to so
be re-sending the signal to itself. This especially important for SIGINT,
as is explained in [1].

uloop currently hides the reason for quitting uloop_run(). Fix this by
returning the signal that caused the loop to quit (or 0 when uloop_end()
was used), so a program using loop an comply with [1].

uloop_cancelled is renamed to uloop_status, so accidentially running a
process compiled with one uloop_cancelled definition against the other is
not possible.

[1] https://www.cons.org/cracauer/sigint.html

Signed-off-by: Matthias Schiffer <mschiffer at universe-factory.net>
---
 uloop.c | 14 ++++++++------
 uloop.h |  6 +++---
 2 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/uloop.c b/uloop.c
index cd3de85..fa3544d 100644
--- a/uloop.c
+++ b/uloop.c
@@ -57,7 +57,7 @@ static struct list_head timeouts = LIST_HEAD_INIT(timeouts);
 static struct list_head processes = LIST_HEAD_INIT(processes);
 
 static int poll_fd = -1;
-bool uloop_cancelled = false;
+int uloop_status = -1;
 static bool do_sigchld = false;
 
 static struct uloop_fd_event cur_fds[ULOOP_MAX_EVENTS];
@@ -330,7 +330,7 @@ static void uloop_handle_processes(void)
 
 static void uloop_handle_sigint(int signo)
 {
-	uloop_cancelled = true;
+	uloop_status = signo;
 }
 
 static void uloop_sigchld(int signo)
@@ -443,7 +443,7 @@ static void uloop_clear_processes(void)
 		uloop_process_delete(p);
 }
 
-void uloop_run(void)
+int uloop_run(void)
 {
 	static int recursive_calls = 0;
 	struct timeval tv;
@@ -455,8 +455,8 @@ void uloop_run(void)
 	if (!recursive_calls++)
 		uloop_setup_signals(true);
 
-	uloop_cancelled = false;
-	while(!uloop_cancelled)
+	uloop_status = -1;
+	while (uloop_status < 0)
 	{
 		uloop_gettime(&tv);
 		uloop_process_timeouts(&tv);
@@ -464,7 +464,7 @@ void uloop_run(void)
 		if (do_sigchld)
 			uloop_handle_processes();
 
-		if (uloop_cancelled)
+		if (uloop_status >= 0)
 			break;
 
 		uloop_gettime(&tv);
@@ -473,6 +473,8 @@ void uloop_run(void)
 
 	if (!--recursive_calls)
 		uloop_setup_signals(false);
+
+	return uloop_status;
 }
 
 void uloop_done(void)
diff --git a/uloop.h b/uloop.h
index 7564514..4d87d46 100644
--- a/uloop.h
+++ b/uloop.h
@@ -83,7 +83,7 @@ struct uloop_process
 	pid_t pid;
 };
 
-extern bool uloop_cancelled;
+extern int uloop_status;
 extern bool uloop_handle_sigchld;
 
 int uloop_fd_add(struct uloop_fd *sock, unsigned int flags);
@@ -99,11 +99,11 @@ int uloop_process_delete(struct uloop_process *p);
 
 static inline void uloop_end(void)
 {
-	uloop_cancelled = true;
+	uloop_status = 0;
 }
 
 int uloop_init(void);
-void uloop_run(void);
+int uloop_run(void);
 void uloop_done(void);
 
 #endif
-- 
2.9.0



From mschiffer at universe-factory.net  Mon Jun 20 00:59:47 2016
From: mschiffer at universe-factory.net (Matthias Schiffer)
Date: Mon, 20 Jun 2016 09:59:47 +0200
Subject: [LEDE-DEV] [PATCH libubox 3/3] blobmsg_json: add new functions
	blobmsg_format_json_value*
In-Reply-To: <ad8ab0cdf8d6148e7a514dcb90a8492fd272fe37.1466409587.git.mschiffer@universe-factory.net>
References: <ad8ab0cdf8d6148e7a514dcb90a8492fd272fe37.1466409587.git.mschiffer@universe-factory.net>
Message-ID: <0d27b4291afc8ba7137f9f03ddd4a17512b5f8f8.1466409587.git.mschiffer@universe-factory.net>

The current blobmsg_format_json* functions will return invalid JSON when
the "list" argument is given as false (blobmsg_format_element() will
output the name of the blob_attr as if the value is printed as part of a
JSON object).

To avoid breaking software relying on this behaviour, introduce new
functions which will never print the blob_attr name and thus always
produce valid JSON.

Signed-off-by: Matthias Schiffer <mschiffer at universe-factory.net>
---
 blobmsg_json.c | 61 ++++++++++++++++++++++++++++++++++++++++++++--------------
 blobmsg_json.h | 14 ++++++++++++++
 2 files changed, 61 insertions(+), 14 deletions(-)

diff --git a/blobmsg_json.c b/blobmsg_json.c
index 33f3969..115d575 100644
--- a/blobmsg_json.c
+++ b/blobmsg_json.c
@@ -210,7 +210,7 @@ static void blobmsg_format_string(struct strbuf *s, const char *str)
 
 static void blobmsg_format_json_list(struct strbuf *s, struct blob_attr *attr, int len, bool array);
 
-static void blobmsg_format_element(struct strbuf *s, struct blob_attr *attr, bool array, bool head)
+static void blobmsg_format_element(struct strbuf *s, struct blob_attr *attr, bool without_name, bool head)
 {
 	const char *data_str;
 	char buf[32];
@@ -220,7 +220,7 @@ static void blobmsg_format_element(struct strbuf *s, struct blob_attr *attr, boo
 	if (!blobmsg_check_attr(attr, false))
 		return;
 
-	if (!array && blobmsg_name(attr)[0]) {
+	if (!without_name && blobmsg_name(attr)[0]) {
 		blobmsg_format_string(s, blobmsg_name(attr));
 		blobmsg_puts(s, ": ", s->indent ? 2 : 1);
 	}
@@ -289,27 +289,30 @@ static void blobmsg_format_json_list(struct strbuf *s, struct blob_attr *attr, i
 	blobmsg_puts(s, (array ? "]" : "}"), 1);
 }
 
+static void setup_strbuf(struct strbuf *s, struct blob_attr *attr, blobmsg_json_format_t cb, void *priv, int indent) {
+	s->len = blob_len(attr);
+	s->buf = malloc(s->len);
+	s->pos = 0;
+	s->custom_format = cb;
+	s->priv = priv;
+	s->indent = false;
+
+	if (indent >= 0) {
+		s->indent = true;
+		s->indent_level = indent;
+	}
+}
+
 char *blobmsg_format_json_with_cb(struct blob_attr *attr, bool list, blobmsg_json_format_t cb, void *priv, int indent)
 {
 	struct strbuf s;
 	bool array;
 	char *ret;
 
-	s.len = blob_len(attr);
-	s.pos = 0;
-	s.custom_format = cb;
-	s.priv = priv;
-	s.indent = false;
-
-	s.buf = malloc(s.len);
+	setup_strbuf(&s, attr, cb, priv, indent);
 	if (!s.buf)
 		return NULL;
 
-	if (indent >= 0) {
-		s.indent = true;
-		s.indent_level = indent;
-	}
-
 	array = blob_is_extended(attr) &&
 		blobmsg_type(attr) == BLOBMSG_TYPE_ARRAY;
 
@@ -333,3 +336,33 @@ char *blobmsg_format_json_with_cb(struct blob_attr *attr, bool list, blobmsg_jso
 
 	return ret;
 }
+
+char *blobmsg_format_json_value_with_cb(struct blob_attr *attr, blobmsg_json_format_t cb, void *priv, int indent)
+{
+	struct strbuf s;
+	char *ret;
+
+	setup_strbuf(&s, attr, cb, priv, indent);
+	if (!s.buf)
+		return NULL;
+
+	blobmsg_format_element(&s, attr, true, false);
+
+	if (!s.len) {
+		free(s.buf);
+		return NULL;
+	}
+
+	s.buf = realloc(s.buf, s.pos + 1);
+	s.buf[s.pos] = 0;
+
+	ret = realloc(s.buf, s.pos + 1);
+	if (!ret) {
+		free(s.buf);
+		return NULL;
+	}
+
+	ret[s.pos] = 0;
+
+	return ret;
+}
diff --git a/blobmsg_json.h b/blobmsg_json.h
index cd9ed33..9dfc02d 100644
--- a/blobmsg_json.h
+++ b/blobmsg_json.h
@@ -42,4 +42,18 @@ static inline char *blobmsg_format_json_indent(struct blob_attr *attr, bool list
 	return blobmsg_format_json_with_cb(attr, list, NULL, NULL, indent);
 }
 
+char *blobmsg_format_json_value_with_cb(struct blob_attr *attr,
+					blobmsg_json_format_t cb, void *priv,
+					int indent);
+
+static inline char *blobmsg_format_json_value(struct blob_attr *attr)
+{
+	return blobmsg_format_json_value_with_cb(attr, NULL, NULL, -1);
+}
+
+static inline char *blobmsg_format_json_value_indent(struct blob_attr *attr, int indent)
+{
+	return blobmsg_format_json_value_with_cb(attr, NULL, NULL, indent);
+}
+
 #endif
-- 
2.9.0



From mschiffer at universe-factory.net  Mon Jun 20 00:59:45 2016
From: mschiffer at universe-factory.net (Matthias Schiffer)
Date: Mon, 20 Jun 2016 09:59:45 +0200
Subject: [LEDE-DEV] [PATCH libubox 1/3] Fix various memory management issues
Message-ID: <ad8ab0cdf8d6148e7a514dcb90a8492fd272fe37.1466409587.git.mschiffer@universe-factory.net>

Consistently handle allocation failures. Some functions are changed to
return bool instead of void to allow returning an error.

Also fix a buffer size miscalculation in lua/uloop.

Signed-off-by: Matthias Schiffer <mschiffer at universe-factory.net>
---
 blobmsg.c      | 20 +++++++++++++++-----
 blobmsg.h      |  4 ++--
 blobmsg_json.c | 26 +++++++++++++++++++-------
 jshn.c         |  4 ++++
 json_script.c  | 17 +++++++++++++++--
 kvlist.c       | 11 ++++++++---
 kvlist.h       |  2 +-
 lua/uloop.c    |  5 ++++-
 ustream.c      |  7 +++++++
 utils.c        |  2 ++
 10 files changed, 77 insertions(+), 21 deletions(-)

diff --git a/blobmsg.c b/blobmsg.c
index 80b984a..1529fbc 100644
--- a/blobmsg.c
+++ b/blobmsg.c
@@ -227,29 +227,38 @@ blobmsg_open_nested(struct blob_buf *buf, const char *name, bool array)
 	return (void *)offset;
 }
 
-void
+bool
 blobmsg_vprintf(struct blob_buf *buf, const char *name, const char *format, va_list arg)
 {
 	va_list arg2;
 	char cbuf;
+	char *sbuf;
 	int len;
 
 	va_copy(arg2, arg);
 	len = vsnprintf(&cbuf, sizeof(cbuf), format, arg2);
 	va_end(arg2);
 
-	vsprintf(blobmsg_alloc_string_buffer(buf, name, len + 1), format, arg);
+	sbuf = blobmsg_alloc_string_buffer(buf, name, len + 1);
+	if (!sbuf)
+		return false;
+	vsprintf(sbuf, format, arg);
 	blobmsg_add_string_buffer(buf);
+
+	return true;
 }
 
-void
+bool
 blobmsg_printf(struct blob_buf *buf, const char *name, const char *format, ...)
 {
 	va_list ap;
+	bool ret;
 
 	va_start(ap, format);
-	blobmsg_vprintf(buf, name, format, ap);
+	ret = blobmsg_vprintf(buf, name, format, ap);
 	va_end(ap);
+
+	return ret;
 }
 
 void *
@@ -278,7 +287,8 @@ blobmsg_realloc_string_buffer(struct blob_buf *buf, unsigned int maxlen)
 	if (required <= 0)
 		goto out;
 
-	blob_buf_grow(buf, required);
+	if (!blob_buf_grow(buf, required))
+		return NULL;
 	attr = blob_next(buf->head);
 
 out:
diff --git a/blobmsg.h b/blobmsg.h
index e58f95d..7153565 100644
--- a/blobmsg.h
+++ b/blobmsg.h
@@ -224,8 +224,8 @@ void *blobmsg_alloc_string_buffer(struct blob_buf *buf, const char *name, unsign
 void *blobmsg_realloc_string_buffer(struct blob_buf *buf, unsigned int maxlen);
 void blobmsg_add_string_buffer(struct blob_buf *buf);
 
-void blobmsg_vprintf(struct blob_buf *buf, const char *name, const char *format, va_list arg);
-void blobmsg_printf(struct blob_buf *buf, const char *name, const char *format, ...)
+bool blobmsg_vprintf(struct blob_buf *buf, const char *name, const char *format, va_list arg);
+bool blobmsg_printf(struct blob_buf *buf, const char *name, const char *format, ...)
      __attribute__((format(printf, 3, 4)));
 
 
diff --git a/blobmsg_json.c b/blobmsg_json.c
index 5713948..33f3969 100644
--- a/blobmsg_json.c
+++ b/blobmsg_json.c
@@ -123,10 +123,13 @@ static bool blobmsg_puts(struct strbuf *s, const char *c, int len)
 		return true;
 
 	if (s->pos + len >= s->len) {
-		s->len += 16 + len;
-		s->buf = realloc(s->buf, s->len);
-		if (!s->buf)
+		size_t new_len = s->len + 16 + len;
+		char *new = realloc(s->buf, new_len);
+		if (!new)
 			return false;
+
+		s->len = new_len;
+		s->buf = new;
 	}
 	memcpy(s->buf + s->pos, c, len);
 	s->pos += len;
@@ -290,14 +293,18 @@ char *blobmsg_format_json_with_cb(struct blob_attr *attr, bool list, blobmsg_jso
 {
 	struct strbuf s;
 	bool array;
+	char *ret;
 
 	s.len = blob_len(attr);
-	s.buf = malloc(s.len);
 	s.pos = 0;
 	s.custom_format = cb;
 	s.priv = priv;
 	s.indent = false;
 
+	s.buf = malloc(s.len);
+	if (!s.buf)
+		return NULL;
+
 	if (indent >= 0) {
 		s.indent = true;
 		s.indent_level = indent;
@@ -316,8 +323,13 @@ char *blobmsg_format_json_with_cb(struct blob_attr *attr, bool list, blobmsg_jso
 		return NULL;
 	}
 
-	s.buf = realloc(s.buf, s.pos + 1);
-	s.buf[s.pos] = 0;
+	ret = realloc(s.buf, s.pos + 1);
+	if (!ret) {
+		free(s.buf);
+		return NULL;
+	}
 
-	return s.buf;
+	ret[s.pos] = 0;
+
+	return ret;
 }
diff --git a/jshn.c b/jshn.c
index e2d9022..4989099 100644
--- a/jshn.c
+++ b/jshn.c
@@ -338,6 +338,10 @@ int main(int argc, char **argv)
 	for (i = 0; environ[i]; i++);
 
 	vars = calloc(i, sizeof(*vars));
+	if (!vars) {
+		fprintf(stderr, "%m\n");
+		return -1;
+	}
 	for (i = 0; environ[i]; i++) {
 		char *c;
 
diff --git a/json_script.c b/json_script.c
index b5d414d..552ed61 100644
--- a/json_script.c
+++ b/json_script.c
@@ -45,6 +45,9 @@ json_script_file_from_blobmsg(const char *name, void *data, int len)
 		name_len = strlen(name) + 1;
 
 	f = calloc_a(sizeof(*f) + len, &new_name, name_len);
+	if (!f)
+		return NULL;
+
 	memcpy(f->data, data, len);
 	if (name)
 		f->avl.key = strcpy(new_name, name);
@@ -426,12 +429,15 @@ static int eval_string(struct json_call *call, struct blob_buf *buf, const char
 	char c = '%';
 
 	dest = blobmsg_alloc_string_buffer(buf, name, 1);
+	if (!dest)
+		return -1;
+
 	next = alloca(strlen(pattern) + 1);
 	strcpy(next, pattern);
 
 	for (str = next; str; str = next) {
 		const char *cur;
-		char *end;
+		char *end, *new;
 		int cur_len = 0;
 		bool cur_var = var;
 
@@ -464,7 +470,14 @@ static int eval_string(struct json_call *call, struct blob_buf *buf, const char
 			cur_len = end - str;
 		}
 
-		dest = blobmsg_realloc_string_buffer(buf, len + cur_len + 1);
+		new = blobmsg_realloc_string_buffer(buf, len + cur_len + 1);
+		if (!new) {
+			/* Make eval_string return -1 */
+			var = true;
+			break;
+		}
+
+		dest = new;
 		memcpy(dest + len, cur, cur_len);
 		len += cur_len;
 	}
diff --git a/kvlist.c b/kvlist.c
index e0a8acb..a7b6ea0 100644
--- a/kvlist.c
+++ b/kvlist.c
@@ -71,20 +71,25 @@ bool kvlist_delete(struct kvlist *kv, const char *name)
 	return !!node;
 }
 
-void kvlist_set(struct kvlist *kv, const char *name, const void *data)
+bool kvlist_set(struct kvlist *kv, const char *name, const void *data)
 {
 	struct kvlist_node *node;
 	char *name_buf;
 	int len = kv->get_len(kv, data);
 
-	kvlist_delete(kv, name);
-
 	node = calloc_a(sizeof(struct kvlist_node) + len,
 		&name_buf, strlen(name) + 1);
+	if (!node)
+		return false;
+
+	kvlist_delete(kv, name);
+
 	memcpy(node->data, data, len);
 
 	node->avl.key = strcpy(name_buf, name);
 	avl_insert(&kv->avl, &node->avl);
+
+	return true;
 }
 
 void kvlist_free(struct kvlist *kv)
diff --git a/kvlist.h b/kvlist.h
index 0d35b46..d59ff9e 100644
--- a/kvlist.h
+++ b/kvlist.h
@@ -45,7 +45,7 @@ struct kvlist_node {
 void kvlist_init(struct kvlist *kv, int (*get_len)(struct kvlist *kv, const void *data));
 void kvlist_free(struct kvlist *kv);
 void *kvlist_get(struct kvlist *kv, const char *name);
-void kvlist_set(struct kvlist *kv, const char *name, const void *data);
+bool kvlist_set(struct kvlist *kv, const char *name, const void *data);
 bool kvlist_delete(struct kvlist *kv, const char *name);
 
 int kvlist_strlen(struct kvlist *kv, const void *data);
diff --git a/lua/uloop.c b/lua/uloop.c
index 782b5a5..db89e72 100644
--- a/lua/uloop.c
+++ b/lua/uloop.c
@@ -325,9 +325,12 @@ static int ul_process(lua_State *L)
 		int argn = lua_objlen(L, -3);
 		int envn = lua_objlen(L, -2);
 		char** argp = malloc(sizeof(char*) * (argn + 2));
-		char** envp = malloc(sizeof(char*) * envn + 1);
+		char** envp = malloc(sizeof(char*) * (envn + 1));
 		int i = 1;
 
+		if (!argp || !envp)
+			exit(-1);
+
 		argp[0] = (char*) lua_tostring(L, -4);
 		for (i = 1; i <= argn; i++) {
 			lua_rawgeti(L, -3, i);
diff --git a/ustream.c b/ustream.c
index e7ee9f0..d36ce08 100644
--- a/ustream.c
+++ b/ustream.c
@@ -65,6 +65,9 @@ static int ustream_alloc_default(struct ustream *s, struct ustream_buf_list *l)
 		return -1;
 
 	buf = malloc(sizeof(*buf) + l->buffer_len + s->string_data);
+	if (!buf)
+		return -1;
+
 	ustream_init_buf(buf, l->buffer_len);
 	ustream_add_buf(l, buf);
 
@@ -490,6 +493,8 @@ int ustream_vprintf(struct ustream *s, const char *format, va_list arg)
 			return ustream_write_buffered(s, buf, maxlen, wr);
 		} else {
 			buf = malloc(maxlen + 1);
+			if (!buf)
+				return 0;
 			wr = vsnprintf(buf, maxlen + 1, format, arg);
 			wr = ustream_write(s, buf, wr, false);
 			free(buf);
@@ -517,6 +522,8 @@ int ustream_vprintf(struct ustream *s, const char *format, va_list arg)
 		return wr;
 
 	buf = malloc(maxlen + 1);
+	if (!buf)
+		return wr;
 	maxlen = vsnprintf(buf, maxlen + 1, format, arg);
 	wr = ustream_write_buffered(s, buf + wr, maxlen - wr, wr);
 	free(buf);
diff --git a/utils.c b/utils.c
index 8fd19f4..91dd71e 100644
--- a/utils.c
+++ b/utils.c
@@ -43,6 +43,8 @@ void *__calloc_a(size_t len, ...)
 	va_end(ap1);
 
 	ptr = calloc(1, alloc_len);
+	if (!ptr)
+		return NULL;
 	alloc_len = 0;
 	foreach_arg(ap, cur_addr, cur_len, &ret, len) {
 		*cur_addr = &ptr[alloc_len];
-- 
2.9.0



From por at xs4all.nl  Mon Jun 20 01:21:47 2016
From: por at xs4all.nl (Paul Oranje)
Date: Mon, 20 Jun 2016 10:21:47 +0200
Subject: [LEDE-DEV] looking for ar7 testers
In-Reply-To: <mailman.41531.1466401256.1639.lede-dev@lists.infradead.org>
References: <mailman.41531.1466401256.1639.lede-dev@lists.infradead.org>
Message-ID: <90A58EA4-3556-47A5-BBC5-6DC32E97AC51@xs4all.nl>


> Van: David Lang <david at lang.hm>
> Onderwerp: Antw.: [LEDE-DEV] looking for ar7 testers
> Datum: 20 juni 2016 02:51:29 CEST
> Aan: Daniel Curran-Dickinson <daniel at daniel.thecshore.com>
> Kopie: John Crispin <john at phrozen.org>, LEDE Development List <lede-dev at lists.infradead.org>
> 
> ...
> 
> Well, I'll point out that the thread I'm replying to started off with "I no longer have the hardware to test this"
> 
> I agree that random, unsolicited donations are likely to be less useful, but donations of hardware to solve the "I can't test this" or add to a test farm are directly useful.
> 
> And getting a new piece of equipment can get a developer interested enough to go after the NDAs needed to make it work well.
> 
> In some cases the vendors involved are known to 'not play well with others' and so donations of their hardware will do no good.
> 
> But those of us out in the wild can't tell the difference between the different categories.
> 
> That's why I asked for a list of what would be useful to donate :-)
> 
> David Lang

Nice that you offer help, but NDA?s don?t play well with open source development and are certainly problematic when such development is under a copy left type of licence (GPL/CC SA etc.). Documentation such as datasheets needed for coding should be offered unencumbered by NDA provisions.

Paul Oranje



From mschiffer at universe-factory.net  Mon Jun 20 02:11:39 2016
From: mschiffer at universe-factory.net (Matthias Schiffer)
Date: Mon, 20 Jun 2016 11:11:39 +0200
Subject: [LEDE-DEV] [PATCH libubox 2/3] loop: make uloop_run() return
 the cancelling signal
In-Reply-To: <22d591176c7b3512ceabddf439a6d6ab682288d1.1466409587.git.mschiffer@universe-factory.net>
References: <ad8ab0cdf8d6148e7a514dcb90a8492fd272fe37.1466409587.git.mschiffer@universe-factory.net>
 <22d591176c7b3512ceabddf439a6d6ab682288d1.1466409587.git.mschiffer@universe-factory.net>
Message-ID: <4da1593a-8764-1580-b965-bac66f4381cc@universe-factory.net>

On 06/20/2016 09:59 AM, Matthias Schiffer wrote:
> When a process quits in response to a signal it handles, it should to so
> be re-sending the signal to itself. This especially important for SIGINT,
> as is explained in [1].
> 
> uloop currently hides the reason for quitting uloop_run(). Fix this by
> returning the signal that caused the loop to quit (or 0 when uloop_end()
> was used), so a program using loop an comply with [1].
> 
> uloop_cancelled is renamed to uloop_status, so accidentially running a
> process compiled with one uloop_cancelled definition against the other is
> not possible.

I've just noticed that this will also require a ubus change, as libubus is
accessing uloop_cancelled directly.

Would you prefer to keep uloop_cancelled with its old definition and add
ubus_status as an additional variable to keep this compatible? An
alternative would be to provide a helper uloop_is_cancelled() based on
ubus_status and adjust libubus accordingly.

Regards,
Matthias

> 
> [1] https://www.cons.org/cracauer/sigint.html
> 
> Signed-off-by: Matthias Schiffer <mschiffer at universe-factory.net>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20160620/318f5e26/attachment.sig>

From john at phrozen.org  Mon Jun 20 03:08:37 2016
From: john at phrozen.org (John Crispin)
Date: Mon, 20 Jun 2016 12:08:37 +0200
Subject: [LEDE-DEV] Bug REPORT: Lantiq - XRX200 -UBIFS does not build
In-Reply-To: <3c413401824e406682f9a7b8bca187ed0e76e780aeb34f458e420761c662ef1854fecc13dcf14efc83b4c0dec916ddefDBXPR04MB077F1AF39DB318D985C63B2A62A0@DBXPR04MB077.eurprd04.prod.outlook.com>
References: <3c413401824e406682f9a7b8bca187ed0e76e780aeb34f458e420761c662ef1854fecc13dcf14efc83b4c0dec916ddefDBXPR04MB077F1AF39DB318D985C63B2A62A0@DBXPR04MB077.eurprd04.prod.outlook.com>
Message-ID: <9c902ec6-df1f-8354-5d3d-2cc7bd0a6041@phrozen.org>

fix coming up, doing test builds just now



On 20/06/2016 12:02, Paul Rowland wrote:
> John,
> 
> 
> My attempt to send this bug report to the lede-dev list has failed a
> number of times. It worked some weeks ago.
> 
> 
> PTR.
> 
> 
> ---- cut here ----
> 
> 
> I did a git-pull and make clean this morning, followed by a make for the
> BT Home Hub 5A. The UBIFS target image was not built. The files created are:
> 
> 
> lede-lantiq-xrx200-BTHOMEHUBV5A-uImage
> 
> md5sums
> 
> sha256sums
> 
> kernel-debug.tar.bz2
> 
> 
> together with the Packages.
> 
> 
> In make menuconfig, the Target Images selected are:
> 
> 
> jffs2
> 
> squashfs
> 
> ubifs (the compression option selected is zlib and the free space fixup
> is also selected)
> 
> 
> 


From rgc at rgc1.inka.de  Mon Jun 20 05:10:30 2016
From: rgc at rgc1.inka.de (Claus Regelmann)
Date: Mon, 20 Jun 2016 14:10:30 +0200
Subject: [LEDE-DEV] expired certificate
Message-ID: <5767DD36.3080302@rgc1.inka.de>

Hello,

I get the following cerificate error when i try to build lede.
How can I ignore expired certificates. Can anybody give me a short hint?

thanks
Claus
--------------------------------------
SHELL= flock 
/home/rgc/LEDE/source/tmp/.libubox-2016-05-19-1257a38a6e64511207bb3b077ca7e8e1a3338fc1.tar.gz.flock 
-c ' echo "Checking out files from the git repository..."; mkdir -p 
/home/rgc/LEDE/source/tmp/dl && cd /home/rgc/LEDE/source/tmp/dl && rm 
-rf libubox-2016-05-19 && [ \! -d libubox-2016-05-19 ] && git clone 
https://git.lede-project.org/project/libubox.git libubox-2016-05-19 && 
(cd libubox-2016-05-19 && git checkout 
1257a38a6e64511207bb3b077ca7e8e1a3338fc1 && git submodule update --init 
--recursive) && echo "Packing checkout..." && rm -rf 
libubox-2016-05-19/.git && tar czf 
/home/rgc/LEDE/source/tmp/dl/libubox-2016-05-19-1257a38a6e64511207bb3b077ca7e8e1a3338fc1.tar.gz 
libubox-2016-05-19 && mv 
/home/rgc/LEDE/source/tmp/dl/libubox-2016-05-19-1257a38a6e64511207bb3b077ca7e8e1a3338fc1.tar.gz 
/home/rgc/LEDE/source/dl/ && rm -rf libubox-2016-05-19; '
Checking out files from the git repository...
Cloning into 'libubox-2016-05-19'...
fatal: unable to access 
'https://git.lede-project.org/project/libubox.git/': SSL certificate 
problem: certificate has expired
Makefile:95: recipe for target 
'/home/rgc/LEDE/source/dl/libubox-2016-05-19-1257a38a6e64511207bb3b077ca7e8e1a3338fc1.tar.gz' 
failed
make[3]: *** 
[/home/rgc/LEDE/source/dl/libubox-2016-05-19-1257a38a6e64511207bb3b077ca7e8e1a3338fc1.tar.gz] 
Error 128
make[3]: Leaving directory '/home/rgc/LEDE/source/package/libs/libubox'
package/Makefile:187: recipe for target 'package/libs/libubox/compile' 
failed
make[2]: *** [package/libs/libubox/compile] Error 2
make[2]: Leaving directory '/home/rgc/LEDE/source'
package/Makefile:184: recipe for target 
'/home/rgc/LEDE/source/staging_dir/target-mips_34kc_musl-1.1.14/stamp/.package_compile' 
failed
make[1]: *** 
[/home/rgc/LEDE/source/staging_dir/target-mips_34kc_musl-1.1.14/stamp/.package_compile] 
Error 2
make[1]: Leaving directory '/home/rgc/LEDE/source'
/home/rgc/LEDE/source/include/toplevel.mk:193: recipe for target 'world' 
failed
make: *** [world] Error 2


From yszhou4tech at gmail.com  Mon Jun 20 05:29:30 2016
From: yszhou4tech at gmail.com (Yousong Zhou)
Date: Mon, 20 Jun 2016 20:29:30 +0800
Subject: [LEDE-DEV] expired certificate
In-Reply-To: <5767DD36.3080302@rgc1.inka.de>
References: <5767DD36.3080302@rgc1.inka.de>
Message-ID: <CAECwjAjJGxnmQFQA77iBO2znX0+3F+SvPn31gZnNmmm1tZ69MA@mail.gmail.com>

On 20 June 2016 at 20:10, Claus Regelmann <rgc at rgc1.inka.de> wrote:
> Hello,
>
> I get the following cerificate error when i try to build lede.
> How can I ignore expired certificates. Can anybody give me a short hint?
>

Edit DownloadMethod/git in include/download.mk and add to git the
option "-c http.sslVerify=false" should do the trick (you know the
risk ;)  But the issue is that at the moment cloning with https works
just fine in my dev machine...

                yousong


From zajec5 at gmail.com  Mon Jun 20 05:33:08 2016
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Mon, 20 Jun 2016 14:33:08 +0200
Subject: [LEDE-DEV] bcm53xx: MD5 checksum over too few bytes of firmware
	breaks kernel booting
Message-ID: <CACna6rxfbUuQdCXQJqPmKkZS4a8oTJFhpehrodyLXGKETpuihQ@mail.gmail.com>

My DIR-885L has following partitions:

[    1.034740] Creating 1 MTD partitions on "brcmnand.0":
[    1.039896] 0x000000000000-0x000008000000 : "firmware"
[    1.075568] 2 seama-fw partitions found on MTD device firmware
[    1.081429] 0x000000000040-0x000000400000 : "kernel"
[    1.086983] 0x000000400000-0x000008000000 : "ubi"

As you can guess kernel's content doesn't change and ubi's content
does. It means we should calculate firmware checksum over 0x40000 -
0x40 = 0x3fffc0 bytes.

Unfortunately after executing:
mtd -c 0x3fffc0 fixseama firmware
and rebooting, LEDE's kernel doesn't boot anymore. It hangs as the
last CFE message:
Starting program at 0x00008000

Executing any of following:
mtd -c 0x73ffc0 fixseama firmware
mtd -c 0x72ffc0 fixseama firmware
mtd -c 0x70ffc0 fixseama firmware
mtd -c 0x4fffc0 fixseama firmware
mtd -c 0x4bffc0 fixseama firmware
mtd -c 0x4affc0 fixseama firmware
mtd -c 0x49ffc0 fixseama firmware
mtd -c 0x48ffc0 fixseama firmware
doesn't break anything.

Executing any following:
mtd -c 0x47ffc0 fixseama firmware
mtd -c 0x46ffc0 fixseama firmware
mtd -c 0x45ffc0 fixseama firmware
mtd -c 0x3fffc0 fixseama firmware
breaks kernel booting.

CFE never complains about image, MD5 is always OK:
  image size : 4194240 bytes
verify_seama: signature=[(null)], type=[firmware]
  checksum   : FFC3A82405FB59C67825A0BEAE79BAA2
  digest     : FFC3A82405FB59C67825A0BEAE79BAA2

I also dumped 0x400000 B of firmware data after both commands:
mtd -c 0x48ffc0 fixseama firmware (WORKING)
mtd -c 0x47ffc0 fixseama firmware (NOT WORKING)
and the only difference is size and MD5 in a header.

-- 
Rafa?


From jo at mein.io  Mon Jun 20 05:35:31 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Mon, 20 Jun 2016 14:35:31 +0200
Subject: [LEDE-DEV] Me prioritizing work on automated bug report data
 collection
In-Reply-To: <1466302481.2745.5.camel@homehost>
References: <1466302481.2745.5.camel@homehost>
Message-ID: <eee3973b-4243-e270-8985-1017ac63fb4d@mein.io>

Hi,

> I'm thinking since I'll be having limited time to LEDE for a while that
> once we know what we're doing for bug report system that I should
> prioritize the LuCI and command line bug report info tool (to maximize
> usefulness of bug reports) and that's probably the most useful thing I
> can work on in the short term for the project as a whole.
> 
> Does that make sense?

It does make sense, I'd appreciate some work on the bug reporting.

~ Jo


From yszhou4tech at gmail.com  Mon Jun 20 07:25:50 2016
From: yszhou4tech at gmail.com (Yousong Zhou)
Date: Mon, 20 Jun 2016 22:25:50 +0800
Subject: [LEDE-DEV] [PATCH] ar71xx: hiwifi-hc6361: lift size limit on kernel
	and rootfs parts
Message-ID: <1466432750-16676-1-git-send-email-yszhou4tech@gmail.com>

The patch has been run-tested and the relevant dmsg logs are as the
following

    [    0.762447] Creating 5 MTD partitions on "spi0.0":
    [    0.767217] 0x000000000000-0x000000010000 : "u-boot"
    [    0.775139] 0x000000010000-0x000000020000 : "bdinfo"
    [    0.781014] 0x000000020000-0x000000fe0000 : "firmware"
    [    0.810558] 2 uimage-fw partitions found on MTD device firmware
    [    0.815043] 0x000000020000-0x000000170000 : "kernel"
    [    0.821925] 0x000000170000-0x000000fe0000 : "rootfs"
    [    0.827587] mtd: device 4 (rootfs) set to be root filesystem
    [    0.831937] 1 squashfs-split partitions found on MTD device rootfs
    [    0.837983] 0x0000005c0000-0x000000fe0000 : "rootfs_data"
    [    0.845621] 0x000000fe0000-0x000000ff0000 : "backup"
    [    0.851445] 0x000000ff0000-0x000001000000 : "art"

While at it, convert to new build method

Signed-off-by: Yousong Zhou <yszhou4tech at gmail.com>
---
 target/linux/ar71xx/image/generic.mk | 20 ++++++++++++++++++++
 target/linux/ar71xx/image/legacy.mk  | 19 -------------------
 2 files changed, 20 insertions(+), 19 deletions(-)

diff --git a/target/linux/ar71xx/image/generic.mk b/target/linux/ar71xx/image/generic.mk
index ca79f98..996bc5b 100644
--- a/target/linux/ar71xx/image/generic.mk
+++ b/target/linux/ar71xx/image/generic.mk
@@ -342,3 +342,23 @@ define Device/c-55
 endef
 
 TARGET_DEVICES += c-55
+
+
+define Build/uImageHiWiFi
+	# Field ih_name needs to start with "tw150v1"
+	mkimage -A $(LINUX_KARCH) \
+		-O linux -T kernel \
+		-C $(1) -a $(KERNEL_LOADADDR) -e $(if $(KERNEL_ENTRY),$(KERNEL_ENTRY),$(KERNEL_LOADADDR)) \
+		-n 'tw150v1 $(call toupper,$(LINUX_KARCH)) LEDE Linux-$(LINUX_VERSION)' -d $@ $@.new
+	@mv $@.new $@
+endef
+
+define Device/hiwifi-hc6361
+    BOARDNAME := HiWiFi-HC6361
+    DEVICE_PROFILE := HIWIFI_HC6361
+    IMAGE_SIZE := 16128k
+    KERNEL := kernel-bin | patch-cmdline | lzma | uImageHiWiFi lzma
+    CONSOLE := ttyATH0,115200
+    MTDPARTS := spi0.0:64k(u-boot)ro,64k(bdinfo)ro,16128k(firmware),64k(backup)ro,64k(art)ro
+endef
+TARGET_DEVICES += hiwifi-hc6361
diff --git a/target/linux/ar71xx/image/legacy.mk b/target/linux/ar71xx/image/legacy.mk
index cf3183e..1556573 100644
--- a/target/linux/ar71xx/image/legacy.mk
+++ b/target/linux/ar71xx/image/legacy.mk
@@ -285,7 +285,6 @@ f9k1115v2_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env),14464k(rootfs
 dlrtdev_mtdlayout=mtdparts=spi0.0:256k(uboot)ro,64k(config)ro,6208k(firmware),64k(caldata)ro,640k(certs),960k(unknown)ro,64k at 0x7f0000(caldata_copy)
 dlrtdev_mtdlayout_fat=mtdparts=spi0.0:256k(uboot)ro,64k(config)ro,7168k(firmware),640k(certs),64k(caldata)ro,64k at 0x660000(caldata_orig),6208k at 0x50000(firmware_orig)
 dragino2_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,16000k(firmware),64k(config)ro,64k(art)ro
-hiwifi_hc6361_mtdlayout=mtdparts=spi0.0:64k(u-boot)ro,64k(bdinfo)ro,1280k(kernel),14848k(rootfs),64k(backup)ro,64k(art)ro,16128k at 0x20000(firmware)
 mr12_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,256k(u-boot-env)ro,13440k(rootfs),2304k(kernel),128k(art)ro,15744k at 0x80000(firmware)
 mr16_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,256k(u-boot-env)ro,13440k(rootfs),2304k(kernel),128k(art)ro,15744k at 0x80000(firmware)
 pb92_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,2752k(rootfs),896k(kernel),64k(nvram),64k(art)ro,3648k at 0x50000(firmware)
@@ -577,22 +576,6 @@ Image/Build/EnGenius/buildkernel=$(call MkuImageLzma,$(2),$(3) $(4))
 Image/Build/EnGenius/initramfs=$(call MkuImageLzma/initramfs,$(2),$(3) $(4))
 
 
-define MkuImageHiWiFi
-	# Field ih_name needs to start with "tw150v1"
-	mkimage -A mips -O linux -T kernel -a 0x80060000 -C $(1) $(2) \
-		-e 0x80060000 -n 'tw150v1 MIPS OpenWrt Linux-$(LINUX_VERSION)' \
-		-d $(3) $(4)
-endef
-
-define MkuImageLzmaHiWiFi
-	$(call PatchKernelLzma,$(1),$(2),$(3),$(4))
-	$(call MkuImageHiWiFi,lzma,$(5),$(KDIR_TMP)/vmlinux$(4)-$(1).bin.lzma,$(KDIR_TMP)/vmlinux$(4)-$(1).uImage)
-endef
-
-Image/Build/HiWiFi/buildkernel=$(call MkuImageLzmaHiWiFi,$(2),$(3) $(4))
-Image/Build/HiWiFi=$(call Image/Build/Ath,$(1),$(2),$(3),$(4),$(5),$(6),$(7))
-Image/Build/HiWiFi/initramfs=$(call MkuImageLzma/initramfs,$(2),$(3) $(4))
-
 Image/Build/PB4X/buildkernel=$(call PatchKernelLzma,$(2),$(3))
 
 define Image/Build/PB4X
@@ -1078,8 +1061,6 @@ $(eval $(call SingleProfile,EnGenius,64k,ESR900,esr900,ESR900,ttyS0,115200,$$(es
 $(eval $(call SingleProfile,EnGenius,64k,ESR1750,esr1750,ESR1750,ttyS0,115200,$$(esr1750_mtdlayout),KRuImage,,0x61))
 $(eval $(call SingleProfile,EnGenius,64k,EPG5000,epg5000,EPG5000,ttyS0,115200,$$(epg5000_mtdlayout),KRuImage,,0x71))
 
-$(eval $(call SingleProfile,HiWiFi,64k,HIWIFI_HC6361,hiwifi-hc6361,HiWiFi-HC6361,ttyATH0,115200,$$(hiwifi_hc6361_mtdlayout),KRuImage))
-
 $(eval $(call SingleProfile,MyLoader,64k,WP543_2M,wp543,,ttyS0,115200,0x200000,2M))
 $(eval $(call SingleProfile,MyLoader,64k,WP543_4M,wp543,,ttyS0,115200,0x400000,4M))
 $(eval $(call SingleProfile,MyLoader,64k,WP543_8M,wp543,,ttyS0,115200,0x800000,8M))
-- 
2.6.4



From ben.mulvihill at gmail.com  Mon Jun 20 09:35:52 2016
From: ben.mulvihill at gmail.com (Ben Mulvihill)
Date: Mon, 20 Jun 2016 18:35:52 +0200
Subject: [LEDE-DEV] [PATCH] lantiq: fix type in new image generation
Message-ID: <1466440552.7057.14.camel@merveille.lan>

Fix typo in commit a6f7536a73c93794812d5e810fb41c3d0ff1fb27
(new image generation)

Signed-off-by: Ben Mulvihill <ben.mulvihill at gmail.com>
---
diff -uprN a/target/linux/lantiq/image/Makefile b/target/linux/lantiq/image/Makefile
--- a/target/linux/lantiq/image/Makefile        2016-06-20 08:34:57.534678922 +0200
+++ b/target/linux/lantiq/image/Makefile        2016-06-20 18:29:36.898896510 +0200
@@ -513,7 +513,7 @@ define LegacyDevice/BTHOMEHUBV3A
        kmod-ath9k wpad-mini \
        swconfig uboot-envtools
 endef
-LEGACY_DEVICES += BTHOMEHUBV3AB
+LEGACY_DEVICES += BTHOMEHUBV3A

 Image/BuildKernel/Profile/DGN3500=$(call Image/BuildKernel/Template,DGN3500)
 Image/Build/Profile/DGN3500=$(call Image/BuildDGN3500/$(1),$(1),DGN3500)




From dev at kresin.me  Mon Jun 20 09:47:38 2016
From: dev at kresin.me (Mathias Kresin)
Date: Mon, 20 Jun 2016 18:47:38 +0200
Subject: [LEDE-DEV] [PATCH 1/2] lantiq: add support for ARV7506PW11
	(Alice/O2 IAD 4421)
Message-ID: <1466441259-5074-1-git-send-email-dev@kresin.me>

From: Oswald Buddenhagen <oswald.buddenhagen at gmx.de>

Ethernet, ADSL2+ and LEDs are fully functional.

Supporting the two TAE ports and SIP gateway was not attempted.

The WiFi is unreliable, due to experimental support for rt35xx family
devices by the rt2800pci driver.

Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen at gmx.de>
[rebase to LEDE HEAD]
[switch to normal image instead of brnboot image]
[remove not required pinmux child nodes keys, leds, ebu, exin, pci_in and pci_out]
[remove switch_rst pinmux child node (no support for hw reset in driver/setting a default GPIO value in DT]
[enable usage of the wireless LED]
[fixup mac address configuration]
Sgned-off-by: Mathias Kresin <dev at kresin.me>
---
 target/linux/lantiq/base-files/etc/board.d/01_leds |   3 +
 .../linux/lantiq/base-files/etc/board.d/02_network |   8 ++
 .../etc/hotplug.d/firmware/10-rt2x00-eeprom        |   2 +-
 target/linux/lantiq/dts/ARV7506PW11.dts            | 159 +++++++++++++++++++++
 target/linux/lantiq/image/Makefile                 |  12 ++
 5 files changed, 183 insertions(+), 1 deletion(-)
 create mode 100644 target/linux/lantiq/dts/ARV7506PW11.dts

diff --git a/target/linux/lantiq/base-files/etc/board.d/01_leds b/target/linux/lantiq/base-files/etc/board.d/01_leds
index 4cca17f..c9d9a77 100755
--- a/target/linux/lantiq/base-files/etc/board.d/01_leds
+++ b/target/linux/lantiq/base-files/etc/board.d/01_leds
@@ -27,6 +27,9 @@ board_config_update
 board=$(lantiq_board_name)
 
 case "$board" in
+ARV7506PW11)
+	ucidef_set_led_wlan "wifi" "wifi" "arv7506pw11:green:wlan" "phy0radio"
+	;;
 BTHOMEHUBV5A)
 	ucidef_set_led_default "dimmed" "dimmed" "dimmed" "0"
 	;;
diff --git a/target/linux/lantiq/base-files/etc/board.d/02_network b/target/linux/lantiq/base-files/etc/board.d/02_network
index cafcb0e..e872315 100755
--- a/target/linux/lantiq/base-files/etc/board.d/02_network
+++ b/target/linux/lantiq/base-files/etc/board.d/02_network
@@ -46,6 +46,14 @@ ARV4519PW|ARV7510PW22|ARV7518PW|ARV752DPW22|ARV8539PW22)
 	;;
 
 # rtl8306g
+ARV7506PW11)
+	lan_mac=$(mtd_get_mac_binary board_config 22)
+	wan_mac=$(macaddr_add "$lan_mac" 2)
+	ucidef_add_switch "switch0" \
+		"4:lan:1" "3:lan:2" "2:lan:3" "1:lan:4" "5t at eth0"
+	;;
+
+# rtl8306g
 ARV7519PW)
 	lan_mac=$(mtd_get_mac_binary board_config 22)
 	wan_mac=$(macaddr_add "$lan_mac" 1)
diff --git a/target/linux/lantiq/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom b/target/linux/lantiq/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom
index 5f1cb00..da10797 100644
--- a/target/linux/lantiq/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom
+++ b/target/linux/lantiq/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom
@@ -35,7 +35,7 @@ case "$FIRMWARE" in
 "RT2860.eeprom" )
 	local board=$(lantiq_board_name)
 	case $board in
-	ARV7510PW22|ARV7519PW|ARV752DPW|ARV752DPW22|VGV7519)
+	ARV7506PW11|ARV7510PW22|ARV7519PW|ARV752DPW|ARV752DPW22|VGV7519)
 		rt2x00_eeprom_extract "board_config" 520 256 1
 		;;
 	ARV7525PW)
diff --git a/target/linux/lantiq/dts/ARV7506PW11.dts b/target/linux/lantiq/dts/ARV7506PW11.dts
new file mode 100644
index 0000000..7519e22
--- /dev/null
+++ b/target/linux/lantiq/dts/ARV7506PW11.dts
@@ -0,0 +1,159 @@
+/dts-v1/;
+
+/include/ "danube.dtsi"
+
+/ {
+	model = "ARV7506PW11 - Alice/O2 IAD 4421";
+
+	chosen {
+		leds {
+			boot = &power;
+			failsafe = &power_red;
+			running = &power;
+
+			dsl = &dsl;
+			internet = &internet;
+			wifi = &wlan;
+		};
+	};
+
+	memory at 0 {
+		reg = <0x0 0x4000000>;
+	};
+
+	fpi at 10000000 {
+		localbus at 0 {
+			nor-boot at 0 {
+				compatible = "lantiq,nor";
+				bank-width = <2>;
+				reg = <0 0x0 0x800000>;
+
+				partitions {
+					compatible = "fixed-partitions";
+					#address-cells = <1>;
+					#size-cells = <1>;
+
+					partition at 0 {
+						label = "uboot";
+						reg = <0x00000 0x40000>;
+						read-only;
+					};
+
+					partition at 40000 {
+						label = "uboot_env";
+						reg = <0x40000 0x10000>;
+						read-only;
+					};
+
+					partition at 50000 {
+						label = "firmware";
+						reg = <0x50000 0x7a0000>;
+					};
+
+					partition at 7f0000 {
+						label = "board_config";
+						reg = <0x7f0000 0x10000>;
+						read-only;
+					};
+				};
+			};
+
+			mac_addr {
+				compatible = "lantiq,eth-mac";
+				reg = <0 0x7f0016 0x6>;
+			};
+		};
+
+		gpio: pinmux at E100B10 {
+			pinctrl-names = "default";
+			pinctrl-0 = <&state_default>;
+
+			state_default: pinmux {
+				pci {
+					lantiq,groups = "gnt1";
+					lantiq,function = "pci";
+					lantiq,output = <1>;
+				};
+				pci_rst {
+					lantiq,pins = "io21";
+					lantiq,pull = <2>;
+					lantiq,output = <1>;
+				};
+			};
+		};
+
+		/* GPIO 19: switch reset */
+		etop at E180000 {
+			phy-mode = "rmii";
+		};
+
+		pci at E105400 {
+			status = "okay";
+			gpio-reset = <&gpio 21 0>;
+		};
+	};
+
+	ralink_eep {
+		compatible = "ralink,eeprom";
+		ralink,eeprom = "RT2860.eeprom";
+	};
+
+	gpio-keys-polled {
+		compatible = "gpio-keys-polled";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		poll-interval = <100>;
+
+		rfkill {
+			label = "rfkill";
+			gpios = <&gpio 11 1>;
+			linux,code = <0xf7>;
+		};
+		reset {
+			label = "reset";
+			gpios = <&gpio 30 1>;
+			linux,code = <0x198>;
+		};
+	};
+
+	gpio-leds {
+		compatible = "gpio-leds";
+		wlan: wlan {
+			label = "arv7506pw11:green:wlan";
+			gpios = <&gpio 2 1>;
+		};
+		power: power {
+			label = "arv7506pw11:green:power";
+			gpios = <&gpio 3 1>;
+			default-state = "keep";
+		};
+		dsl: dsl {
+			label = "arv7506pw11:green:dsl";
+			gpios = <&gpio 4 1>;
+		};
+		internet: internet {
+			label = "arv7506pw11:green:internet";
+			gpios = <&gpio 5 1>;
+		};
+		power_red: power_red {
+			label = "arv7506pw11:red:power";
+			gpios = <&gpio 6 1>;
+		};
+		internet_red {
+			label = "arv7506pw11:red:internet";
+			gpios = <&gpio 7 1>;
+		};
+		info {
+			label = "arv7506pw11:green:info";
+			gpios = <&gpio 8 1>;
+		};
+		telefon {
+			label = "arv7506pw11:green:telefon";
+			gpios = <&gpio 9 1>;
+		};
+		info_red {
+			label = "arv7506pw11:red:info";
+			gpios = <&gpio 20 1>;
+		};
+	};
+};
diff --git a/target/linux/lantiq/image/Makefile b/target/linux/lantiq/image/Makefile
index e75d634..026934f 100644
--- a/target/linux/lantiq/image/Makefile
+++ b/target/linux/lantiq/image/Makefile
@@ -354,6 +354,18 @@ define Device/ARV4519PW
 endef
 TARGET_DEVICES += ARV4519PW
 
+define Device/ARV7506PW11
+  DEVICE_PROFILE := ARV7506PW11
+  IMAGE_SIZE := 7808k
+  DEVICE_TITLE := Alice/O2 IAD 4421 - ARV7506PW11
+  DEVICE_PACKAGES := kmod-ltq-adsl-danube-mei kmod-ltq-adsl-danube \
+	kmod-ltq-adsl-danube-fw-b kmod-ltq-atm-danube \
+	ltq-adsl-app ppp-mod-pppoa \
+	kmod-rt2800-pci wpad-mini \
+	swconfig
+endef
+TARGET_DEVICES += ARV7506PW11
+
 define Device/ARV7510PW22
   DEVICE_PROFILE := ARV7510PW22
   IMAGE_SIZE := 31232k
-- 
1.9.1



From dev at kresin.me  Mon Jun 20 09:47:39 2016
From: dev at kresin.me (Mathias Kresin)
Date: Mon, 20 Jun 2016 18:47:39 +0200
Subject: [LEDE-DEV] [PATCH 2/2] uboot-lantiq: Add Arcadyan ARV7506PW11
	support
In-Reply-To: <1466441259-5074-1-git-send-email-dev@kresin.me>
References: <1466441259-5074-1-git-send-email-dev@kresin.me>
Message-ID: <1466441259-5074-2-git-send-email-dev@kresin.me>

Signed-off-by: Mathias Kresin <dev at kresin.me>
---
 package/boot/uboot-lantiq/Makefile                 |  20 ++
 ...dd-board-support-for-Arcadyan-ARV7506PW11.patch | 275 +++++++++++++++++++++
 2 files changed, 295 insertions(+)
 create mode 100644 package/boot/uboot-lantiq/patches/0115-MIPS-add-board-support-for-Arcadyan-ARV7506PW11.patch

diff --git a/package/boot/uboot-lantiq/Makefile b/package/boot/uboot-lantiq/Makefile
index bb4f7db..3ecc1a2 100644
--- a/package/boot/uboot-lantiq/Makefile
+++ b/package/boot/uboot-lantiq/Makefile
@@ -55,6 +55,25 @@ define uboot/arv4519pw_brn
   DEPS:=@TARGET_lantiq_xway
 endef
 
+define uboot/arv7506pw11_ram
+  TITLE:=U-Boot for Arcadyan ARV7506PW11 (RAM)
+  SOC:=danube
+  DDR_SETTINGS:=board/arcadyan/arv7506pw11/ddr_settings.h
+  DEPS:=@TARGET_lantiq_xway
+endef
+
+define uboot/arv7506pw11_nor
+  TITLE:=U-Boot for Arcadyan ARV7506PW11 (NOR)
+  SOC:=danube
+  DEPS:=@TARGET_lantiq_xway
+endef
+
+define uboot/arv7506pw11_brn
+  TITLE:=U-Boot for Arcadyan ARV7506PW11 (BRN)
+  SOC:=danube
+  DEPS:=@TARGET_lantiq_xway
+endef
+
 define uboot/arv7510pw_ram
   TITLE:=U-Boot for Arcadyan arv7510pw (RAM)
   SOC:=danube
@@ -316,6 +335,7 @@ endef
 
 UBOOTS:= \
 	arv4519pw_ram arv4519pw_nor arv4519pw_brn \
+	arv7506pw11_ram arv7506pw11_nor arv7506pw11_brn \
 	arv7510pw_ram arv7510pw_nor arv7510pw_brn \
 	arv7510pw22_ram arv7510pw22_nor arv7510pw22_brn \
 	arv7518pw_ram arv7518pw_nor arv7518pw_brn \
diff --git a/package/boot/uboot-lantiq/patches/0115-MIPS-add-board-support-for-Arcadyan-ARV7506PW11.patch b/package/boot/uboot-lantiq/patches/0115-MIPS-add-board-support-for-Arcadyan-ARV7506PW11.patch
new file mode 100644
index 0000000..b7a8a6a
--- /dev/null
+++ b/package/boot/uboot-lantiq/patches/0115-MIPS-add-board-support-for-Arcadyan-ARV7506PW11.patch
@@ -0,0 +1,275 @@
+--- /dev/null
++++ b/board/arcadyan/arv7506pw11/Makefile
+@@ -0,0 +1,27 @@
++#
++# Copyright (C) 2000-2011 Wolfgang Denk, DENX Software Engineering, wd at denx.de
++#
++# SPDX-License-Identifier:	GPL-2.0+
++#
++
++include $(TOPDIR)/config.mk
++
++LIB	= $(obj)lib$(BOARD).o
++
++COBJS	= $(BOARD).o
++
++SRCS	:= $(SOBJS:.o=.S) $(COBJS:.o=.c)
++OBJS	:= $(addprefix $(obj),$(COBJS))
++SOBJS	:= $(addprefix $(obj),$(SOBJS))
++
++$(LIB):	$(obj).depend $(OBJS) $(SOBJS)
++	$(call cmd_link_o_target, $(OBJS) $(SOBJS))
++
++#########################################################################
++
++# defines $(obj).depend target
++include $(SRCTREE)/rules.mk
++
++sinclude $(obj).depend
++
++#########################################################################
+--- /dev/null
++++ b/board/arcadyan/arv7506pw11/arv7506pw11.c
+@@ -0,0 +1,97 @@
++/*
++ * Copyright (C) 2016 Mathias Kresin <dev at kresin.me>
++ *
++ * SPDX-License-Identifier:	GPL-2.0+
++ */
++
++#include <common.h>
++#include <switch.h>
++#include <asm/gpio.h>
++#include <asm/lantiq/eth.h>
++#include <asm/lantiq/reset.h>
++#include <asm/lantiq/chipid.h>
++
++#if defined(CONFIG_SYS_BOOT_RAM)
++#define do_gpio_init	1
++#elif defined(CONFIG_SYS_BOOT_NOR)
++#define do_gpio_init	1
++#else
++#define do_gpio_init	0
++#endif
++
++#define GPIO_POWER_GREEN	3
++#define GPIO_POWER_RED	6
++#define GPIO_GPHY_RESET 19
++
++static void gpio_init(void)
++{
++	/* Reset switch to have him in a clean state on reboot */
++	gpio_direction_output(GPIO_GPHY_RESET, 0);
++	udelay(20);
++	gpio_direction_output(GPIO_GPHY_RESET, 1);
++
++	/* Turn on the green power LED */
++	gpio_direction_output(GPIO_POWER_GREEN, 0);
++
++	/* Turn off the red power LED */
++	gpio_direction_output(GPIO_POWER_RED, 1);
++}
++
++int board_early_init_f(void)
++{
++	if (do_gpio_init)
++		gpio_init();
++
++	return 0;
++}
++
++int checkboard(void)
++{
++	puts("Board: " CONFIG_BOARD_NAME "\n");
++	ltq_chip_print_info();
++
++	return 0;
++}
++
++void show_boot_progress(int arg)
++{
++	if (!do_gpio_init)
++		return 0;
++
++	if (arg >= 0) {
++		/* Success - turn off the red power LED and turn on the green power LED */
++		gpio_set_value(GPIO_POWER_RED, 1);
++		gpio_set_value(GPIO_POWER_GREEN, 0);
++	} else {
++		/* Failure - turn off green power LED and turn on red power LED */
++		gpio_set_value(GPIO_POWER_GREEN, 1);
++		gpio_set_value(GPIO_POWER_RED, 0);
++	}
++
++	return 0;
++}
++
++static const struct ltq_eth_port_config eth_port_config[] = {
++	/* MAC0: Realtek rtl8306 switch */
++	{ 0, 0x0, LTQ_ETH_PORT_SWITCH, PHY_INTERFACE_MODE_RMII },
++};
++
++static const struct ltq_eth_board_config eth_board_config = {
++	.ports = eth_port_config,
++	.num_ports = ARRAY_SIZE(eth_port_config),
++};
++
++int board_eth_init(bd_t *bis)
++{
++	return ltq_eth_initialize(&eth_board_config);
++}
++static struct switch_device rtl8306_dev = {
++	.name = "rtl8306",
++	.cpu_port = 5,
++	.port_mask = 0xF,
++};
++
++int board_switch_init(void)
++{
++	return switch_device_register(&rtl8306_dev);
++}
+--- /dev/null
++++ b/board/arcadyan/arv7506pw11/config.mk
+@@ -0,0 +1,7 @@
++#
++# Copyright (C) 2011-2013 Daniel Schwierzeck, daniel.schwierzeck at gmail.com
++#
++# SPDX-License-Identifier:	GPL-2.0+
++#
++
++PLATFORM_CPPFLAGS += -I$(TOPDIR)/board/$(BOARDDIR)
+--- /dev/null
++++ b/board/arcadyan/arv7506pw11/ddr_settings.h
+@@ -0,0 +1,55 @@
++/*
++ * Copyright (C) 2011-2013 Luka Perkov <luka at openwrt.org>
++ *
++ * This file has been generated with lantiq_ram_extract_magic.awk script. 
++ *
++ * SPDX-License-Identifier:	GPL-2.0+
++ */
++
++#define MC_DC00_VALUE	0x1B1B
++#define MC_DC01_VALUE	0x0
++#define MC_DC02_VALUE	0x0
++#define MC_DC03_VALUE	0x0
++#define MC_DC04_VALUE	0x0
++#define MC_DC05_VALUE	0x200
++#define MC_DC06_VALUE	0x605
++#define MC_DC07_VALUE	0x303
++#define MC_DC08_VALUE	0x102
++#define MC_DC09_VALUE	0x70A
++#define MC_DC10_VALUE	0x203
++#define MC_DC11_VALUE	0xC02
++#define MC_DC12_VALUE	0x1C8
++#define MC_DC13_VALUE	0x1
++#define MC_DC14_VALUE	0x0
++#define MC_DC15_VALUE	0x142
++#define MC_DC16_VALUE	0xC800
++#define MC_DC17_VALUE	0xD
++#define MC_DC18_VALUE	0x301
++#define MC_DC19_VALUE	0x200
++#define MC_DC20_VALUE	0xA03
++#define MC_DC21_VALUE	0x1300
++#define MC_DC22_VALUE	0x1313
++#define MC_DC23_VALUE	0x0
++#define MC_DC24_VALUE	0x68
++#define MC_DC25_VALUE	0x0
++#define MC_DC26_VALUE	0x0
++#define MC_DC27_VALUE	0x0
++#define MC_DC28_VALUE	0x510
++#define MC_DC29_VALUE	0x4E20
++#define MC_DC30_VALUE	0x8235
++#define MC_DC31_VALUE	0x0
++#define MC_DC32_VALUE	0x0
++#define MC_DC33_VALUE	0x0
++#define MC_DC34_VALUE	0x0
++#define MC_DC35_VALUE	0x0
++#define MC_DC36_VALUE	0x0
++#define MC_DC37_VALUE	0x0
++#define MC_DC38_VALUE	0x0
++#define MC_DC39_VALUE	0x0
++#define MC_DC40_VALUE	0x0
++#define MC_DC41_VALUE	0x0
++#define MC_DC42_VALUE	0x0
++#define MC_DC43_VALUE	0x0
++#define MC_DC44_VALUE	0x0
++#define MC_DC45_VALUE	0x500
++#define MC_DC46_VALUE	0x0
+--- a/boards.cfg
++++ b/boards.cfg
+@@ -505,6 +505,9 @@ Active  mips        mips32         au1x0
+ Active  mips        mips32         danube      arcadyan        arv4519pw           arv4519pw_brn                        arv4519pw:SYS_BOOT_BRN                                                                                                            Luka Perkov <luka at openwrt.org>
+ Active  mips        mips32         danube      arcadyan        arv4519pw           arv4519pw_nor                        arv4519pw:SYS_BOOT_NOR                                                                                                            Luka Perkov <luka at openwrt.org>
+ Active  mips        mips32         danube      arcadyan        arv4519pw           arv4519pw_ram                        arv4519pw:SYS_BOOT_RAM                                                                                                            Luka Perkov <luka at openwrt.org>
++Active  mips        mips32         danube      arcadyan        arv7506pw11         arv7506pw11_brn                      arv7506pw11:SYS_BOOT_BRN                                                                                                          Mathias Kresin <dev at kresin.me>
++Active  mips        mips32         danube      arcadyan        arv7506pw11         arv7506pw11_nor                      arv7506pw11:SYS_BOOT_NOR                                                                                                          Mathias Kresin <dev at kresin.me>
++Active  mips        mips32         danube      arcadyan        arv7506pw11         arv7506pw11_ram                      arv7506pw11:SYS_BOOT_RAM                                                                                                          Mathias Kresin <dev at kresin.me>
+ Active  mips        mips32         danube      arcadyan        arv7510pw           arv7510pw_brn                        arv7510pw:SYS_BOOT_BRN                                                                                                            Luka Perkov <luka at openwrt.org>
+ Active  mips        mips32         danube      arcadyan        arv7510pw           arv7510pw_nor                        arv7510pw:SYS_BOOT_NOR                                                                                                            Luka Perkov <luka at openwrt.org>
+ Active  mips        mips32         danube      arcadyan        arv7510pw           arv7510pw_ram                        arv7510pw:SYS_BOOT_RAM                                                                                                            Luka Perkov <luka at openwrt.org>
+--- /dev/null
++++ b/include/configs/arv7506pw11.h
+@@ -0,0 +1,62 @@
++/*
++ * Copyright (C) 2016 Mathias Kresin <dev at kresin.me>
++ *
++ * SPDX-License-Identifier:	GPL-2.0+
++ */
++
++#ifndef __CONFIG_H
++#define __CONFIG_H
++
++#define CONFIG_MACH_TYPE	"ARV7506PW11"
++#define CONFIG_IDENT_STRING	" "CONFIG_MACH_TYPE
++#define CONFIG_BOARD_NAME	"Arcadyan ARV7506PW11"
++
++/* Configure SoC */
++#define CONFIG_LTQ_SUPPORT_UART		/* Enable ASC and UART */
++
++#define CONFIG_LTQ_SUPPORT_ETHERNET	/* Enable ethernet */
++
++#define CONFIG_LTQ_SUPPORT_NOR_FLASH	/* Have a parallel NOR flash */
++
++/* Switch devices */
++#define CONFIG_SWITCH_MULTI
++#define CONFIG_SWITCH_RTL8306
++
++/* Environment */
++#if defined(CONFIG_SYS_BOOT_BRN)
++#define CONFIG_SYS_TEXT_BASE		0x80002000
++#define CONFIG_SKIP_LOWLEVEL_INIT
++#define CONFIG_SYS_DISABLE_CACHE
++#define CONFIG_ENV_IS_NOWHERE
++#define CONFIG_ENV_OVERWRITE 1
++#elif defined(CONFIG_SYS_BOOT_NOR)
++#define CONFIG_ENV_IS_IN_FLASH
++#define CONFIG_ENV_OVERWRITE
++#define CONFIG_ENV_OFFSET		(256 * 1024)
++#define CONFIG_ENV_SECT_SIZE		(64 * 1024)
++#else
++#define CONFIG_ENV_IS_NOWHERE
++#endif
++
++#define CONFIG_ENV_SIZE			(64 * 1024)
++
++#define CONFIG_LOADADDR			CONFIG_SYS_LOAD_ADDR
++
++/* Console */
++#define CONFIG_LTQ_ADVANCED_CONSOLE
++#define CONFIG_BAUDRATE			115200
++#define CONFIG_CONSOLE_ASC		1
++#define CONFIG_CONSOLE_DEV		"ttyLTQ1"
++
++/* Pull in default board configs for Lantiq XWAY Danube */
++#include <asm/lantiq/config.h>
++#include <asm/arch/config.h>
++
++/* Pull in default OpenWrt configs for Lantiq SoC */
++#include "openwrt-lantiq-common.h"
++
++#define CONFIG_EXTRA_ENV_SETTINGS	\
++	CONFIG_ENV_LANTIQ_DEFAULTS	\
++	"kernel_addr=0xB0050000\0"
++
++#endif /* __CONFIG_H */
-- 
1.9.1



From zajec5 at gmail.com  Mon Jun 20 09:56:03 2016
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Mon, 20 Jun 2016 18:56:03 +0200
Subject: [LEDE-DEV] bcm53xx: MD5 checksum over too few bytes of firmware
 breaks kernel booting
In-Reply-To: <CACna6rxfbUuQdCXQJqPmKkZS4a8oTJFhpehrodyLXGKETpuihQ@mail.gmail.com>
References: <CACna6rxfbUuQdCXQJqPmKkZS4a8oTJFhpehrodyLXGKETpuihQ@mail.gmail.com>
Message-ID: <CACna6rwe5K3typJqqrWJxukqXVLg7qXbkpKj+MgWQ04=C=v_oA@mail.gmail.com>

On 20 June 2016 at 14:33, Rafa? Mi?ecki <zajec5 at gmail.com> wrote:
> My DIR-885L has following partitions:
>
> [    1.034740] Creating 1 MTD partitions on "brcmnand.0":
> [    1.039896] 0x000000000000-0x000008000000 : "firmware"
> [    1.075568] 2 seama-fw partitions found on MTD device firmware
> [    1.081429] 0x000000000040-0x000000400000 : "kernel"
> [    1.086983] 0x000000400000-0x000008000000 : "ubi"
>
> As you can guess kernel's content doesn't change and ubi's content
> does. It means we should calculate firmware checksum over 0x40000 -
> 0x40 = 0x3fffc0 bytes.
>
> Unfortunately after executing:
> mtd -c 0x3fffc0 fixseama firmware
> and rebooting, LEDE's kernel doesn't boot anymore. It hangs as the
> last CFE message:
> Starting program at 0x00008000

This is a regression cased by:

commit b3be33f135f447d56ef9a5461e7e675d5cc35730
Author: Felix Fietkau <nbd at nbd.name>
Date:   Tue Jun 14 12:01:22 2016 +0200

    bcm53xx: use uncompressed zImages

    The boot loader expects LZMA compressed kernel images

    Signed-off-by: Felix Fietkau <nbd at nbd.name>

Reverting this commit from the master makes kernel always booting again.

Felix: any idea what may it be? Can you change be triggering some CFE bug?


From christian at solvare.se  Sat Jun 18 12:35:13 2016
From: christian at solvare.se (Christian Huldt)
Date: Sat, 18 Jun 2016 21:35:13 +0200
Subject: [LEDE-DEV] MPTCP
In-Reply-To: <d7ec44ba-f73e-0bef-cf33-8b01c44a8567@phrozen.org>
References: <c438814f-37a0-cf6f-cd72-3afbba77899c@solvare.se>
 <d7ec44ba-f73e-0bef-cf33-8b01c44a8567@phrozen.org>
Message-ID: <925d0a4e-8413-caac-31ac-5fd2b2bbf4ec@solvare.se>

I'm now having a highly experimental version of MPTCP (as a package) for
15.05, (and one that builds on my old dirty trunk with the old
patches-4.1 still i place)

make menuconfig shows it as possible to mark with <M> which I doubt is
working as it is a kernel patch, how do I kill that?

And where should it be placed in the tree?

(Right now it is at
KernelPackage/mptcp
SUBMENU:=Network Support
but that is mostly to get something to work with)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20160618/03a0d219/attachment.sig>

From greearb at candelatech.com  Mon Jun 20 18:12:58 2016
From: greearb at candelatech.com (greearb at candelatech.com)
Date: Mon, 20 Jun 2016 18:12:58 -0700
Subject: [LEDE-DEV] [PATCH] ath10k-ct: Update to latest 10.4.3 CT firmware
	for 9980 chipsets.
Message-ID: <1466471578-30311-1-git-send-email-greearb@candelatech.com>

From: Ben Greear <greearb at candelatech.com>

This works around regressions added in the 4.7 kernel.

Signed-off-by: Ben Greear <greearb at candelatech.com>
---
 package/firmware/ath10k-firmware/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/firmware/ath10k-firmware/Makefile b/package/firmware/ath10k-firmware/Makefile
index 41eab13..fcd6167 100644
--- a/package/firmware/ath10k-firmware/Makefile
+++ b/package/firmware/ath10k-firmware/Makefile
@@ -39,7 +39,7 @@ endef
 
 QCA988X_FIRMWARE_FILE:=firmware-5.bin_10.2.4.97-1
 QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-16.bin-lede
-QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-7.bin-lede
+QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-7.bin-lede.001
 
 define Download/ath10k-firmware-qca988x
   URL:=https://www.codeaurora.org/cgit/quic/qsdk/oss/firmware/ath10k-firmware/plain/10.2.4/
@@ -58,7 +58,7 @@ $(eval $(call Download,ath10k-firmware-qca988x-ct))
 define Download/ath10k-firmware-qca99x0-ct
   URL:=https://www.candelatech.com/downloads/ath10k-10-4/
   FILE:=$(QCA99X0_FIRMWARE_FILE_CT)
-  MD5SUM:=d01e24eaa7a6fb03db6b5bca44c2394a
+  MD5SUM:=eb710949ff79142954aadae24616169c
 endef
 $(eval $(call Download,ath10k-firmware-qca99x0-ct))
 
-- 
2.4.3



From john at phrozen.org  Tue Jun 21 01:23:46 2016
From: john at phrozen.org (John Crispin)
Date: Tue, 21 Jun 2016 10:23:46 +0200
Subject: [LEDE-DEV] ar71xx - please help test
Message-ID: <bfd64b04-7942-19a8-0eda-911840448cb7@phrozen.org>

Hi,

i have moved all the profiles into the image building code. i have done
some basic testing and already got a bit of feedback from others.

it would be nice if people could help test the following patch from my
staging tree

https://git.lede-project.org/?p=lede/blogic/staging.git;a=commit;h=75773d43cd44ee70e293343fad11db654c35a4ed

	John


From jch at pps.univ-paris-diderot.fr  Tue Jun 21 03:05:08 2016
From: jch at pps.univ-paris-diderot.fr (Juliusz Chroboczek)
Date: Tue, 21 Jun 2016 12:05:08 +0200
Subject: [LEDE-DEV] [OpenWrt-Devel] MPTCP
In-Reply-To: <925d0a4e-8413-caac-31ac-5fd2b2bbf4ec@solvare.se>
References: <c438814f-37a0-cf6f-cd72-3afbba77899c@solvare.se>
 <d7ec44ba-f73e-0bef-cf33-8b01c44a8567@phrozen.org>
 <925d0a4e-8413-caac-31ac-5fd2b2bbf4ec@solvare.se>
Message-ID: <87k2hirh63.wl-jch@pps.univ-paris-diderot.fr>

> I'm now having a highly experimental version of MPTCP (as a package) for
> 15.05, (and one that builds on my old dirty trunk with the old
> patches-4.1 still i place)

Just to make sure people don't get confused -- MP-TCP doesn't need router
support, and OpenWRT/LEDE is quite able to route MP-TCP traffic flowing
through it out of the box.

MP-TCP on the router is only needed for traffic that terminates at the
router.  It's a good idea e.g. if you're running a web server on your
router.

-- Juliusz




From dat_le at compex.com.sg  Tue Jun 21 03:19:20 2016
From: dat_le at compex.com.sg (Dat Le)
Date: Tue, 21 Jun 2016 18:19:20 +0800
Subject: [LEDE-DEV] ar71xx - please help test
In-Reply-To: <bfd64b04-7942-19a8-0eda-911840448cb7@phrozen.org>
References: <bfd64b04-7942-19a8-0eda-911840448cb7@phrozen.org>
Message-ID: <7649394d-a702-9295-63ae-c9782d20f308@compex.com.sg>

Hi,

I will test Compex products WPJ342, WPJ344, WPJ531 and WPJ558.

By the way, please let us* know if you are interested in testing Compex 
products or fixing LEDE bugs for Compex products, we shall arrange you 
sample accordingly.

us = huibo_won at compex.com.sg or dat_le at compex.com.sg

Thanks,
Dat

On 6/21/2016 4:23 PM, John Crispin wrote:
> Hi,
>
> i have moved all the profiles into the image building code. i have done
> some basic testing and already got a bit of feedback from others.
>
> it would be nice if people could help test the following patch from my
> staging tree
>
> https://git.lede-project.org/?p=lede/blogic/staging.git;a=commit;h=75773d43cd44ee70e293343fad11db654c35a4ed
>
> 	John
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev



From jo at mein.io  Tue Jun 21 03:32:48 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Tue, 21 Jun 2016 12:32:48 +0200
Subject: [LEDE-DEV] [PATCH libubox 1/3] Fix various memory management
 issues
In-Reply-To: <ad8ab0cdf8d6148e7a514dcb90a8492fd272fe37.1466409587.git.mschiffer@universe-factory.net>
References: <ad8ab0cdf8d6148e7a514dcb90a8492fd272fe37.1466409587.git.mschiffer@universe-factory.net>
Message-ID: <c923196e-69a2-02d9-6dab-2f661fcbd9ff@mein.io>

Hi,

first of all, thanks for putting work into that - I like the changes in
general. Have a few comments inline below.

~ Jo

> Consistently handle allocation failures. Some functions are changed to
> return bool instead of void to allow returning an error.
> 
> Also fix a buffer size miscalculation in lua/uloop.
> 
> Signed-off-by: Matthias Schiffer <mschiffer at universe-factory.net>
> ---
>  blobmsg.c      | 20 +++++++++++++++-----
>  blobmsg.h      |  4 ++--
>  blobmsg_json.c | 26 +++++++++++++++++++-------
>  jshn.c         |  4 ++++
>  json_script.c  | 17 +++++++++++++++--
>  kvlist.c       | 11 ++++++++---
>  kvlist.h       |  2 +-
>  lua/uloop.c    |  5 ++++-
>  ustream.c      |  7 +++++++
>  utils.c        |  2 ++
>  10 files changed, 77 insertions(+), 21 deletions(-)
> 
> diff --git a/blobmsg.c b/blobmsg.c
> index 80b984a..1529fbc 100644
> --- a/blobmsg.c
> +++ b/blobmsg.c
> @@ -227,29 +227,38 @@ blobmsg_open_nested(struct blob_buf *buf, const char *name, bool array)
>  	return (void *)offset;
>  }
>  
> -void
> +bool
>  blobmsg_vprintf(struct blob_buf *buf, const char *name, const char *format, va_list arg)
>  {
>  	va_list arg2;
>  	char cbuf;
> +	char *sbuf;
>  	int len;
>  
>  	va_copy(arg2, arg);
>  	len = vsnprintf(&cbuf, sizeof(cbuf), format, arg2);
>  	va_end(arg2);
>  
> -	vsprintf(blobmsg_alloc_string_buffer(buf, name, len + 1), format, arg);
> +	sbuf = blobmsg_alloc_string_buffer(buf, name, len + 1);
> +	if (!sbuf)
> +		return false;
> +	vsprintf(sbuf, format, arg);
>  	blobmsg_add_string_buffer(buf);
> +
> +	return true;

The vsprintf() we're wrapping here returns the number of bytes written,
which is useful imho. What about returning >= 0 bytes for success and -1
for error (alloc fail) ?

>  }
>  
> -void
> +bool
>  blobmsg_printf(struct blob_buf *buf, const char *name, const char *format, ...)
>  {
>  	va_list ap;
> +	bool ret;
>  
>  	va_start(ap, format);
> -	blobmsg_vprintf(buf, name, format, ap);
> +	ret = blobmsg_vprintf(buf, name, format, ap);
>  	va_end(ap);
> +
> +	return ret;

Same, if we decide to return the bytes in blobmsg_vprintf() we need to
adjust the return type here.

>  }
>  
>  void *
> @@ -278,7 +287,8 @@ blobmsg_realloc_string_buffer(struct blob_buf *buf, unsigned int maxlen)
>  	if (required <= 0)
>  		goto out;
>  
> -	blob_buf_grow(buf, required);
> +	if (!blob_buf_grow(buf, required))
> +		return NULL;
>  	attr = blob_next(buf->head);
>  
>  out:
> diff --git a/blobmsg.h b/blobmsg.h
> index e58f95d..7153565 100644
> --- a/blobmsg.h
> +++ b/blobmsg.h
> @@ -224,8 +224,8 @@ void *blobmsg_alloc_string_buffer(struct blob_buf *buf, const char *name, unsign
>  void *blobmsg_realloc_string_buffer(struct blob_buf *buf, unsigned int maxlen);
>  void blobmsg_add_string_buffer(struct blob_buf *buf);
>  
> -void blobmsg_vprintf(struct blob_buf *buf, const char *name, const char *format, va_list arg);
> -void blobmsg_printf(struct blob_buf *buf, const char *name, const char *format, ...)
> +bool blobmsg_vprintf(struct blob_buf *buf, const char *name, const char *format, va_list arg);
> +bool blobmsg_printf(struct blob_buf *buf, const char *name, const char *format, ...)
>       __attribute__((format(printf, 3, 4)));
>  
>  
> diff --git a/blobmsg_json.c b/blobmsg_json.c
> index 5713948..33f3969 100644
> --- a/blobmsg_json.c
> +++ b/blobmsg_json.c
> @@ -123,10 +123,13 @@ static bool blobmsg_puts(struct strbuf *s, const char *c, int len)
>  		return true;
>  
>  	if (s->pos + len >= s->len) {
> -		s->len += 16 + len;
> -		s->buf = realloc(s->buf, s->len);
> -		if (!s->buf)
> +		size_t new_len = s->len + 16 + len;
> +		char *new = realloc(s->buf, new_len);

Can we move the declarations to the top of the function and avoid "new"
as it is a C++ reserved word? You could call them "buf" and "buf_len" or
"cpy" and "cpy_len" maybe.

> +		if (!new)
>  			return false;
> +
> +		s->len = new_len;
> +		s->buf = new;
>  	}
>  	memcpy(s->buf + s->pos, c, len);
>  	s->pos += len;
> @@ -290,14 +293,18 @@ char *blobmsg_format_json_with_cb(struct blob_attr *attr, bool list, blobmsg_jso
>  {
>  	struct strbuf s;
>  	bool array;
> +	char *ret;
>  
>  	s.len = blob_len(attr);
> -	s.buf = malloc(s.len);
>  	s.pos = 0;
>  	s.custom_format = cb;
>  	s.priv = priv;
>  	s.indent = false;
>  
> +	s.buf = malloc(s.len);
> +	if (!s.buf)
> +		return NULL;
> +
>  	if (indent >= 0) {
>  		s.indent = true;
>  		s.indent_level = indent;
> @@ -316,8 +323,13 @@ char *blobmsg_format_json_with_cb(struct blob_attr *attr, bool list, blobmsg_jso
>  		return NULL;
>  	}
>  
> -	s.buf = realloc(s.buf, s.pos + 1);
> -	s.buf[s.pos] = 0;
> +	ret = realloc(s.buf, s.pos + 1);
> +	if (!ret) {
> +		free(s.buf);
> +		return NULL;
> +	}
>  
> -	return s.buf;
> +	ret[s.pos] = 0;

Did you forget to assign "ret" to "s.buf" here?

> +
> +	return ret;
>  }
> diff --git a/jshn.c b/jshn.c
> index e2d9022..4989099 100644
> --- a/jshn.c
> +++ b/jshn.c
> @@ -338,6 +338,10 @@ int main(int argc, char **argv)
>  	for (i = 0; environ[i]; i++);
>  
>  	vars = calloc(i, sizeof(*vars));
> +	if (!vars) {
> +		fprintf(stderr, "%m\n");

The "%m" format is a glibc extension, I'd favor an explicit "%s" +
strerror(errno) here just to avoid potential portability hassle.

> +		return -1;
> +	}
>  	for (i = 0; environ[i]; i++) {
>  		char *c;
>  
> diff --git a/json_script.c b/json_script.c
> index b5d414d..552ed61 100644
> --- a/json_script.c
> +++ b/json_script.c
> @@ -45,6 +45,9 @@ json_script_file_from_blobmsg(const char *name, void *data, int len)
>  		name_len = strlen(name) + 1;
>  
>  	f = calloc_a(sizeof(*f) + len, &new_name, name_len);
> +	if (!f)
> +		return NULL;
> +
>  	memcpy(f->data, data, len);
>  	if (name)
>  		f->avl.key = strcpy(new_name, name);
> @@ -426,12 +429,15 @@ static int eval_string(struct json_call *call, struct blob_buf *buf, const char
>  	char c = '%';
>  
>  	dest = blobmsg_alloc_string_buffer(buf, name, 1);
> +	if (!dest)
> +		return -1;
> +
>  	next = alloca(strlen(pattern) + 1);
>  	strcpy(next, pattern);
>  
>  	for (str = next; str; str = next) {
>  		const char *cur;
> -		char *end;
> +		char *end, *new;

Can we avoid "new" here and use "cpy" or "copy" instead?

>  		int cur_len = 0;
>  		bool cur_var = var;
>  
> @@ -464,7 +470,14 @@ static int eval_string(struct json_call *call, struct blob_buf *buf, const char
>  			cur_len = end - str;
>  		}
>  
> -		dest = blobmsg_realloc_string_buffer(buf, len + cur_len + 1);
> +		new = blobmsg_realloc_string_buffer(buf, len + cur_len + 1);
> +		if (!new) {
> +			/* Make eval_string return -1 */
> +			var = true;
> +			break;
> +		}
> +
> +		dest = new;
>  		memcpy(dest + len, cur, cur_len);
>  		len += cur_len;
>  	}
> diff --git a/kvlist.c b/kvlist.c
> index e0a8acb..a7b6ea0 100644
> --- a/kvlist.c
> +++ b/kvlist.c
> @@ -71,20 +71,25 @@ bool kvlist_delete(struct kvlist *kv, const char *name)
>  	return !!node;
>  }
>  
> -void kvlist_set(struct kvlist *kv, const char *name, const void *data)
> +bool kvlist_set(struct kvlist *kv, const char *name, const void *data)
>  {
>  	struct kvlist_node *node;
>  	char *name_buf;
>  	int len = kv->get_len(kv, data);
>  
> -	kvlist_delete(kv, name);
> -
>  	node = calloc_a(sizeof(struct kvlist_node) + len,
>  		&name_buf, strlen(name) + 1);
> +	if (!node)
> +		return false;
> +
> +	kvlist_delete(kv, name);
> +
>  	memcpy(node->data, data, len);
>  
>  	node->avl.key = strcpy(name_buf, name);
>  	avl_insert(&kv->avl, &node->avl);
> +
> +	return true;
>  }
>  
>  void kvlist_free(struct kvlist *kv)
> diff --git a/kvlist.h b/kvlist.h
> index 0d35b46..d59ff9e 100644
> --- a/kvlist.h
> +++ b/kvlist.h
> @@ -45,7 +45,7 @@ struct kvlist_node {
>  void kvlist_init(struct kvlist *kv, int (*get_len)(struct kvlist *kv, const void *data));
>  void kvlist_free(struct kvlist *kv);
>  void *kvlist_get(struct kvlist *kv, const char *name);
> -void kvlist_set(struct kvlist *kv, const char *name, const void *data);
> +bool kvlist_set(struct kvlist *kv, const char *name, const void *data);
>  bool kvlist_delete(struct kvlist *kv, const char *name);
>  
>  int kvlist_strlen(struct kvlist *kv, const void *data);
> diff --git a/lua/uloop.c b/lua/uloop.c
> index 782b5a5..db89e72 100644
> --- a/lua/uloop.c
> +++ b/lua/uloop.c
> @@ -325,9 +325,12 @@ static int ul_process(lua_State *L)
>  		int argn = lua_objlen(L, -3);
>  		int envn = lua_objlen(L, -2);
>  		char** argp = malloc(sizeof(char*) * (argn + 2));
> -		char** envp = malloc(sizeof(char*) * envn + 1);
> +		char** envp = malloc(sizeof(char*) * (envn + 1));
>  		int i = 1;
>  
> +		if (!argp || !envp)
> +			exit(-1);

A "return luaL_error(L, "Out of memory");" might be slightly more
appropriate here.

> +
>  		argp[0] = (char*) lua_tostring(L, -4);
>  		for (i = 1; i <= argn; i++) {
>  			lua_rawgeti(L, -3, i);
> diff --git a/ustream.c b/ustream.c
> index e7ee9f0..d36ce08 100644
> --- a/ustream.c
> +++ b/ustream.c
> @@ -65,6 +65,9 @@ static int ustream_alloc_default(struct ustream *s, struct ustream_buf_list *l)
>  		return -1;
>  
>  	buf = malloc(sizeof(*buf) + l->buffer_len + s->string_data);
> +	if (!buf)
> +		return -1;
> +
>  	ustream_init_buf(buf, l->buffer_len);
>  	ustream_add_buf(l, buf);
>  
> @@ -490,6 +493,8 @@ int ustream_vprintf(struct ustream *s, const char *format, va_list arg)
>  			return ustream_write_buffered(s, buf, maxlen, wr);
>  		} else {
>  			buf = malloc(maxlen + 1);
> +			if (!buf)
> +				return 0;
>  			wr = vsnprintf(buf, maxlen + 1, format, arg);
>  			wr = ustream_write(s, buf, wr, false);
>  			free(buf);
> @@ -517,6 +522,8 @@ int ustream_vprintf(struct ustream *s, const char *format, va_list arg)
>  		return wr;
>  
>  	buf = malloc(maxlen + 1);
> +	if (!buf)
> +		return wr;
>  	maxlen = vsnprintf(buf, maxlen + 1, format, arg);
>  	wr = ustream_write_buffered(s, buf + wr, maxlen - wr, wr);
>  	free(buf);
> diff --git a/utils.c b/utils.c
> index 8fd19f4..91dd71e 100644
> --- a/utils.c
> +++ b/utils.c
> @@ -43,6 +43,8 @@ void *__calloc_a(size_t len, ...)
>  	va_end(ap1);
>  
>  	ptr = calloc(1, alloc_len);
> +	if (!ptr)
> +		return NULL;
>  	alloc_len = 0;
>  	foreach_arg(ap, cur_addr, cur_len, &ret, len) {
>  		*cur_addr = &ptr[alloc_len];
> 



From jo at mein.io  Tue Jun 21 03:34:03 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Tue, 21 Jun 2016 12:34:03 +0200
Subject: [LEDE-DEV] [PATCH libubox 2/3] loop: make uloop_run() return
 the cancelling signal
In-Reply-To: <22d591176c7b3512ceabddf439a6d6ab682288d1.1466409587.git.mschiffer@universe-factory.net>
References: <ad8ab0cdf8d6148e7a514dcb90a8492fd272fe37.1466409587.git.mschiffer@universe-factory.net>
 <22d591176c7b3512ceabddf439a6d6ab682288d1.1466409587.git.mschiffer@universe-factory.net>
Message-ID: <80e5bb56-91ef-3f5b-7365-aedff62ba45d@mein.io>

On 06/20/2016 09:59 AM, Matthias Schiffer wrote:
> When a process quits in response to a signal it handles, it should to so
> be re-sending the signal to itself. This especially important for SIGINT,
> as is explained in [1].
> 
> uloop currently hides the reason for quitting uloop_run(). Fix this by
> returning the signal that caused the loop to quit (or 0 when uloop_end()
> was used), so a program using loop an comply with [1].
> 
> uloop_cancelled is renamed to uloop_status, so accidentially running a
> process compiled with one uloop_cancelled definition against the other is
> not possible.
> 
> [1] https://www.cons.org/cracauer/sigint.html
> 
> Signed-off-by: Matthias Schiffer <mschiffer at universe-factory.net>
Acked-by: Jo-Philipp Wich <jo at mein.io>
> ---
>  uloop.c | 14 ++++++++------
>  uloop.h |  6 +++---
>  2 files changed, 11 insertions(+), 9 deletions(-)
> 
> diff --git a/uloop.c b/uloop.c
> index cd3de85..fa3544d 100644
> --- a/uloop.c
> +++ b/uloop.c
> @@ -57,7 +57,7 @@ static struct list_head timeouts = LIST_HEAD_INIT(timeouts);
>  static struct list_head processes = LIST_HEAD_INIT(processes);
>  
>  static int poll_fd = -1;
> -bool uloop_cancelled = false;
> +int uloop_status = -1;
>  static bool do_sigchld = false;
>  
>  static struct uloop_fd_event cur_fds[ULOOP_MAX_EVENTS];
> @@ -330,7 +330,7 @@ static void uloop_handle_processes(void)
>  
>  static void uloop_handle_sigint(int signo)
>  {
> -	uloop_cancelled = true;
> +	uloop_status = signo;
>  }
>  
>  static void uloop_sigchld(int signo)
> @@ -443,7 +443,7 @@ static void uloop_clear_processes(void)
>  		uloop_process_delete(p);
>  }
>  
> -void uloop_run(void)
> +int uloop_run(void)
>  {
>  	static int recursive_calls = 0;
>  	struct timeval tv;
> @@ -455,8 +455,8 @@ void uloop_run(void)
>  	if (!recursive_calls++)
>  		uloop_setup_signals(true);
>  
> -	uloop_cancelled = false;
> -	while(!uloop_cancelled)
> +	uloop_status = -1;
> +	while (uloop_status < 0)
>  	{
>  		uloop_gettime(&tv);
>  		uloop_process_timeouts(&tv);
> @@ -464,7 +464,7 @@ void uloop_run(void)
>  		if (do_sigchld)
>  			uloop_handle_processes();
>  
> -		if (uloop_cancelled)
> +		if (uloop_status >= 0)
>  			break;
>  
>  		uloop_gettime(&tv);
> @@ -473,6 +473,8 @@ void uloop_run(void)
>  
>  	if (!--recursive_calls)
>  		uloop_setup_signals(false);
> +
> +	return uloop_status;
>  }
>  
>  void uloop_done(void)
> diff --git a/uloop.h b/uloop.h
> index 7564514..4d87d46 100644
> --- a/uloop.h
> +++ b/uloop.h
> @@ -83,7 +83,7 @@ struct uloop_process
>  	pid_t pid;
>  };
>  
> -extern bool uloop_cancelled;
> +extern int uloop_status;
>  extern bool uloop_handle_sigchld;
>  
>  int uloop_fd_add(struct uloop_fd *sock, unsigned int flags);
> @@ -99,11 +99,11 @@ int uloop_process_delete(struct uloop_process *p);
>  
>  static inline void uloop_end(void)
>  {
> -	uloop_cancelled = true;
> +	uloop_status = 0;
>  }
>  
>  int uloop_init(void);
> -void uloop_run(void);
> +int uloop_run(void);
>  void uloop_done(void);
>  
>  #endif
> 



From jo at mein.io  Tue Jun 21 03:36:13 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Tue, 21 Jun 2016 12:36:13 +0200
Subject: [LEDE-DEV] [PATCH libubox 3/3] blobmsg_json: add new functions
 blobmsg_format_json_value*
In-Reply-To: <0d27b4291afc8ba7137f9f03ddd4a17512b5f8f8.1466409587.git.mschiffer@universe-factory.net>
References: <ad8ab0cdf8d6148e7a514dcb90a8492fd272fe37.1466409587.git.mschiffer@universe-factory.net>
 <0d27b4291afc8ba7137f9f03ddd4a17512b5f8f8.1466409587.git.mschiffer@universe-factory.net>
Message-ID: <5f336903-86cc-5e46-1dc6-3a895a15682f@mein.io>

On 06/20/2016 09:59 AM, Matthias Schiffer wrote:
> The current blobmsg_format_json* functions will return invalid JSON when
> the "list" argument is given as false (blobmsg_format_element() will
> output the name of the blob_attr as if the value is printed as part of a
> JSON object).
> 
> To avoid breaking software relying on this behaviour, introduce new
> functions which will never print the blob_attr name and thus always
> produce valid JSON.
> 
> Signed-off-by: Matthias Schiffer <mschiffer at universe-factory.net>
Acked-by: Jo-Philipp Wich <jo at mein.io>
> ---
>  blobmsg_json.c | 61 ++++++++++++++++++++++++++++++++++++++++++++--------------
>  blobmsg_json.h | 14 ++++++++++++++
>  2 files changed, 61 insertions(+), 14 deletions(-)
> 
> diff --git a/blobmsg_json.c b/blobmsg_json.c
> index 33f3969..115d575 100644
> --- a/blobmsg_json.c
> +++ b/blobmsg_json.c
> @@ -210,7 +210,7 @@ static void blobmsg_format_string(struct strbuf *s, const char *str)
>  
>  static void blobmsg_format_json_list(struct strbuf *s, struct blob_attr *attr, int len, bool array);
>  
> -static void blobmsg_format_element(struct strbuf *s, struct blob_attr *attr, bool array, bool head)
> +static void blobmsg_format_element(struct strbuf *s, struct blob_attr *attr, bool without_name, bool head)
>  {
>  	const char *data_str;
>  	char buf[32];
> @@ -220,7 +220,7 @@ static void blobmsg_format_element(struct strbuf *s, struct blob_attr *attr, boo
>  	if (!blobmsg_check_attr(attr, false))
>  		return;
>  
> -	if (!array && blobmsg_name(attr)[0]) {
> +	if (!without_name && blobmsg_name(attr)[0]) {
>  		blobmsg_format_string(s, blobmsg_name(attr));
>  		blobmsg_puts(s, ": ", s->indent ? 2 : 1);
>  	}
> @@ -289,27 +289,30 @@ static void blobmsg_format_json_list(struct strbuf *s, struct blob_attr *attr, i
>  	blobmsg_puts(s, (array ? "]" : "}"), 1);
>  }
>  
> +static void setup_strbuf(struct strbuf *s, struct blob_attr *attr, blobmsg_json_format_t cb, void *priv, int indent) {
> +	s->len = blob_len(attr);
> +	s->buf = malloc(s->len);
> +	s->pos = 0;
> +	s->custom_format = cb;
> +	s->priv = priv;
> +	s->indent = false;
> +
> +	if (indent >= 0) {
> +		s->indent = true;
> +		s->indent_level = indent;
> +	}
> +}
> +
>  char *blobmsg_format_json_with_cb(struct blob_attr *attr, bool list, blobmsg_json_format_t cb, void *priv, int indent)
>  {
>  	struct strbuf s;
>  	bool array;
>  	char *ret;
>  
> -	s.len = blob_len(attr);
> -	s.pos = 0;
> -	s.custom_format = cb;
> -	s.priv = priv;
> -	s.indent = false;
> -
> -	s.buf = malloc(s.len);
> +	setup_strbuf(&s, attr, cb, priv, indent);
>  	if (!s.buf)
>  		return NULL;
>  
> -	if (indent >= 0) {
> -		s.indent = true;
> -		s.indent_level = indent;
> -	}
> -
>  	array = blob_is_extended(attr) &&
>  		blobmsg_type(attr) == BLOBMSG_TYPE_ARRAY;
>  
> @@ -333,3 +336,33 @@ char *blobmsg_format_json_with_cb(struct blob_attr *attr, bool list, blobmsg_jso
>  
>  	return ret;
>  }
> +
> +char *blobmsg_format_json_value_with_cb(struct blob_attr *attr, blobmsg_json_format_t cb, void *priv, int indent)
> +{
> +	struct strbuf s;
> +	char *ret;
> +
> +	setup_strbuf(&s, attr, cb, priv, indent);
> +	if (!s.buf)
> +		return NULL;
> +
> +	blobmsg_format_element(&s, attr, true, false);
> +
> +	if (!s.len) {
> +		free(s.buf);
> +		return NULL;
> +	}
> +
> +	s.buf = realloc(s.buf, s.pos + 1);
> +	s.buf[s.pos] = 0;
> +
> +	ret = realloc(s.buf, s.pos + 1);
> +	if (!ret) {
> +		free(s.buf);
> +		return NULL;
> +	}
> +
> +	ret[s.pos] = 0;
> +
> +	return ret;
> +}
> diff --git a/blobmsg_json.h b/blobmsg_json.h
> index cd9ed33..9dfc02d 100644
> --- a/blobmsg_json.h
> +++ b/blobmsg_json.h
> @@ -42,4 +42,18 @@ static inline char *blobmsg_format_json_indent(struct blob_attr *attr, bool list
>  	return blobmsg_format_json_with_cb(attr, list, NULL, NULL, indent);
>  }
>  
> +char *blobmsg_format_json_value_with_cb(struct blob_attr *attr,
> +					blobmsg_json_format_t cb, void *priv,
> +					int indent);
> +
> +static inline char *blobmsg_format_json_value(struct blob_attr *attr)
> +{
> +	return blobmsg_format_json_value_with_cb(attr, NULL, NULL, -1);
> +}
> +
> +static inline char *blobmsg_format_json_value_indent(struct blob_attr *attr, int indent)
> +{
> +	return blobmsg_format_json_value_with_cb(attr, NULL, NULL, indent);
> +}
> +
>  #endif
> 



From mschiffer at universe-factory.net  Tue Jun 21 03:43:26 2016
From: mschiffer at universe-factory.net (Matthias Schiffer)
Date: Tue, 21 Jun 2016 12:43:26 +0200
Subject: [LEDE-DEV] [PATCH libubox 1/3] Fix various memory management
 issues
In-Reply-To: <c923196e-69a2-02d9-6dab-2f661fcbd9ff@mein.io>
References: <ad8ab0cdf8d6148e7a514dcb90a8492fd272fe37.1466409587.git.mschiffer@universe-factory.net>
 <c923196e-69a2-02d9-6dab-2f661fcbd9ff@mein.io>
Message-ID: <36f36fbd-b9fa-9d9a-85b2-49662631d888@universe-factory.net>

On 06/21/2016 12:32 PM, Jo-Philipp Wich wrote:
> Hi,
> 
> first of all, thanks for putting work into that - I like the changes in
> general. Have a few comments inline below.
> 
> ~ Jo
> 
>> Consistently handle allocation failures. Some functions are changed to
>> return bool instead of void to allow returning an error.
>>
>> Also fix a buffer size miscalculation in lua/uloop.
>>
>> Signed-off-by: Matthias Schiffer <mschiffer at universe-factory.net>
>> ---
[...]
>> @@ -316,8 +323,13 @@ char *blobmsg_format_json_with_cb(struct blob_attr *attr, bool list, blobmsg_jso
>>  		return NULL;
>>  	}
>>  
>> -	s.buf = realloc(s.buf, s.pos + 1);
>> -	s.buf[s.pos] = 0;
>> +	ret = realloc(s.buf, s.pos + 1);
>> +	if (!ret) {
>> +		free(s.buf);
>> +		return NULL;
>> +	}
>>  
>> -	return s.buf;
>> +	ret[s.pos] = 0;
> 
> Did you forget to assign "ret" to "s.buf" here?
This one is correct as is, s is a local variable, so assigning it at the
end doesn't make sense.

> 
>> +
>> +	return ret;
>>  }
[...]

Thanks for having a look, I'll fix up the rest.

Matthias



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20160621/849c1311/attachment.sig>

From hannu.nyman at iki.fi  Tue Jun 21 03:44:44 2016
From: hannu.nyman at iki.fi (Hannu Nyman)
Date: Tue, 21 Jun 2016 13:44:44 +0300
Subject: [LEDE-DEV] ar71xx - please help test
In-Reply-To: <bfd64b04-7942-19a8-0eda-911840448cb7@phrozen.org>
References: <bfd64b04-7942-19a8-0eda-911840448cb7@phrozen.org>
Message-ID: <f04a3bfc-4194-8cbd-540f-8e01cd94ec87@iki.fi>

On 21.6.2016 11:23, John Crispin wrote:
> it would be nice if people could help test the following patch from my
> staging tree
>
> https://git.lede-project.org/?p=lede/blogic/staging.git;a=commit;h=75773d43cd44ee70e293343fad11db654c35a4ed

My WNDR3700/3800 firmware gets compiled ok with the patch. The same packages 
get selected and the router boots normally.

Hannu

Ps. when applying the patch, git complains about "trailing whitespace" errors...

...$ git apply p.patch
p.patch:2768: trailing whitespace.
   DEVICE_TITLE := NETGEAR WNDR3800
p.patch:2821: trailing whitespace.
   DEVICE_TITLE := PowerCloud CR3000 (No-Cloud)
p.patch:3110: trailing whitespace.
     DEVICE_PACKAGES :=
...
warning: 31 lines add whitespace errors.



From stevecgelliott at gmail.com  Mon Jun 20 18:07:26 2016
From: stevecgelliott at gmail.com (Steve Elliott)
Date: Tue, 21 Jun 2016 11:07:26 +1000
Subject: [LEDE-DEV] subscribe
Message-ID: <1466471246.4598.0.camel@Gmail.com>




From jo at mein.io  Tue Jun 21 04:45:19 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Tue, 21 Jun 2016 13:45:19 +0200
Subject: [LEDE-DEV] [PATCH] ath10k-ct: Update to latest 10.4.3 CT
 firmware for 9980 chipsets.
In-Reply-To: <1466471578-30311-1-git-send-email-greearb@candelatech.com>
References: <1466471578-30311-1-git-send-email-greearb@candelatech.com>
Message-ID: <9dff25e3-4ead-1063-1846-39a96b674d67@mein.io>

Hi Ben,

merged into source.git - thanks!

~ Jo


From jo at mein.io  Tue Jun 21 04:51:30 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Tue, 21 Jun 2016 13:51:30 +0200
Subject: [LEDE-DEV] [PATCH] lantiq: fix type in new image generation
In-Reply-To: <1466440552.7057.14.camel@merveille.lan>
References: <1466440552.7057.14.camel@merveille.lan>
Message-ID: <370c1df1-32d0-92cd-7718-77e8302f6d90@mein.io>

Hi Ben,

pushed to source.git with small typo fix in subject.

Thanks!

~ Jo


From adron at yapic.net  Tue Jun 21 07:04:36 2016
From: adron at yapic.net (=?UTF-8?B?0KHQtdGA0LPQtdC10LIg0KHQtdGA0LPQtdC5?=)
Date: Tue, 21 Jun 2016 17:04:36 +0300
Subject: [LEDE-DEV] [PATCH] build: Adds the ability to disable personal
 initramfs build for target device
In-Reply-To: <f2d9b8b4-d6d4-513b-54a8-9682393ecae1@nbd.name>
References: <1466103891-30447-1-git-send-email-adron@yapic.net>
 <f2d9b8b4-d6d4-513b-54a8-9682393ecae1@nbd.name>
Message-ID: <57694974.8030708@yapic.net>

16.06.2016 22:15, Felix Fietkau ?????:
> On 2016-06-16 21:04, adron at yapic.net wrote:
>> From: Sergey Sergeev <adron at yapic.net>
>>
>>   If KERNEL_INITRAMFS := in the target/linux/*/image/Makefile->Device/%NAME% section is set to ''
>>   then personal initramfs file for this target device will not be created.
>>   This var is similar to the Device/Build/kernel KERNEL_INSTALL :=
>>
>> Signed-off-by: Sergey Sergeev <adron at yapic.net>
> What devices do you need to disable initramfs for, and why?
>
> - Felix
>
Hello. What about my patch? Maybe there is another correct way to 
disable build initratfs duplicate files?


From mschiffer at universe-factory.net  Tue Jun 21 08:10:27 2016
From: mschiffer at universe-factory.net (Matthias Schiffer)
Date: Tue, 21 Jun 2016 17:10:27 +0200
Subject: [LEDE-DEV] [PATCH libubox 1/3] Fix various memory management
 issues
In-Reply-To: <c923196e-69a2-02d9-6dab-2f661fcbd9ff@mein.io>
References: <ad8ab0cdf8d6148e7a514dcb90a8492fd272fe37.1466409587.git.mschiffer@universe-factory.net>
 <c923196e-69a2-02d9-6dab-2f661fcbd9ff@mein.io>
Message-ID: <39666494-b04e-1979-17b4-99aa94b372ff@universe-factory.net>

On 06/21/2016 12:32 PM, Jo-Philipp Wich wrote:
> Hi,
> 
> first of all, thanks for putting work into that - I like the changes in
> general. Have a few comments inline below.
> 
> ~ Jo
> 
[...]
>> diff --git a/lua/uloop.c b/lua/uloop.c
>> index 782b5a5..db89e72 100644
>> --- a/lua/uloop.c
>> +++ b/lua/uloop.c
>> @@ -325,9 +325,12 @@ static int ul_process(lua_State *L)
>>  		int argn = lua_objlen(L, -3);
>>  		int envn = lua_objlen(L, -2);
>>  		char** argp = malloc(sizeof(char*) * (argn + 2));
>> -		char** envp = malloc(sizeof(char*) * envn + 1);
>> +		char** envp = malloc(sizeof(char*) * (envn + 1));
>>  		int i = 1;
>>  
>> +		if (!argp || !envp)
>> +			exit(-1);
> 
> A "return luaL_error(L, "Out of memory");" might be slightly more
> appropriate here.

This one is actually in the forked process. I'll change it from exit() to
_exit() to avoid affecting resources used by the parent process (and also
adjust the exit() a few lines below). I don't think it would be appropriate
to raise a Lua error in the child process.

Matthias

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20160621/b0386604/attachment-0001.sig>

From mschiffer at universe-factory.net  Tue Jun 21 08:19:12 2016
From: mschiffer at universe-factory.net (Matthias Schiffer)
Date: Tue, 21 Jun 2016 17:19:12 +0200
Subject: [LEDE-DEV] [PATCH libubox v2 3/3] blobmsg_json: add new functions
	blobmsg_format_json_value*
In-Reply-To: <cc8bcc58421ebdbf8e65cef24e8eeb0dd4b1e510.1466522197.git.mschiffer@universe-factory.net>
References: <cc8bcc58421ebdbf8e65cef24e8eeb0dd4b1e510.1466522197.git.mschiffer@universe-factory.net>
Message-ID: <fbb2189048a98cc34efaad03f91709935739cee2.1466522197.git.mschiffer@universe-factory.net>

The current blobmsg_format_json* functions will return invalid JSON when
the "list" argument is given as false (blobmsg_format_element() will
output the name of the blob_attr as if the value is printed as part of a
JSON object).

To avoid breaking software relying on this behaviour, introduce new
functions which will never print the blob_attr name and thus always
produce valid JSON.

Signed-off-by: Matthias Schiffer <mschiffer at universe-factory.net>
---
v2: no changes

 blobmsg_json.c | 61 ++++++++++++++++++++++++++++++++++++++++++++--------------
 blobmsg_json.h | 14 ++++++++++++++
 2 files changed, 61 insertions(+), 14 deletions(-)

diff --git a/blobmsg_json.c b/blobmsg_json.c
index 2e318b2..78747d1 100644
--- a/blobmsg_json.c
+++ b/blobmsg_json.c
@@ -214,7 +214,7 @@ static void blobmsg_format_string(struct strbuf *s, const char *str)
 
 static void blobmsg_format_json_list(struct strbuf *s, struct blob_attr *attr, int len, bool array);
 
-static void blobmsg_format_element(struct strbuf *s, struct blob_attr *attr, bool array, bool head)
+static void blobmsg_format_element(struct strbuf *s, struct blob_attr *attr, bool without_name, bool head)
 {
 	const char *data_str;
 	char buf[32];
@@ -224,7 +224,7 @@ static void blobmsg_format_element(struct strbuf *s, struct blob_attr *attr, boo
 	if (!blobmsg_check_attr(attr, false))
 		return;
 
-	if (!array && blobmsg_name(attr)[0]) {
+	if (!without_name && blobmsg_name(attr)[0]) {
 		blobmsg_format_string(s, blobmsg_name(attr));
 		blobmsg_puts(s, ": ", s->indent ? 2 : 1);
 	}
@@ -293,27 +293,30 @@ static void blobmsg_format_json_list(struct strbuf *s, struct blob_attr *attr, i
 	blobmsg_puts(s, (array ? "]" : "}"), 1);
 }
 
+static void setup_strbuf(struct strbuf *s, struct blob_attr *attr, blobmsg_json_format_t cb, void *priv, int indent) {
+	s->len = blob_len(attr);
+	s->buf = malloc(s->len);
+	s->pos = 0;
+	s->custom_format = cb;
+	s->priv = priv;
+	s->indent = false;
+
+	if (indent >= 0) {
+		s->indent = true;
+		s->indent_level = indent;
+	}
+}
+
 char *blobmsg_format_json_with_cb(struct blob_attr *attr, bool list, blobmsg_json_format_t cb, void *priv, int indent)
 {
 	struct strbuf s;
 	bool array;
 	char *ret;
 
-	s.len = blob_len(attr);
-	s.pos = 0;
-	s.custom_format = cb;
-	s.priv = priv;
-	s.indent = false;
-
-	s.buf = malloc(s.len);
+	setup_strbuf(&s, attr, cb, priv, indent);
 	if (!s.buf)
 		return NULL;
 
-	if (indent >= 0) {
-		s.indent = true;
-		s.indent_level = indent;
-	}
-
 	array = blob_is_extended(attr) &&
 		blobmsg_type(attr) == BLOBMSG_TYPE_ARRAY;
 
@@ -337,3 +340,33 @@ char *blobmsg_format_json_with_cb(struct blob_attr *attr, bool list, blobmsg_jso
 
 	return ret;
 }
+
+char *blobmsg_format_json_value_with_cb(struct blob_attr *attr, blobmsg_json_format_t cb, void *priv, int indent)
+{
+	struct strbuf s;
+	char *ret;
+
+	setup_strbuf(&s, attr, cb, priv, indent);
+	if (!s.buf)
+		return NULL;
+
+	blobmsg_format_element(&s, attr, true, false);
+
+	if (!s.len) {
+		free(s.buf);
+		return NULL;
+	}
+
+	s.buf = realloc(s.buf, s.pos + 1);
+	s.buf[s.pos] = 0;
+
+	ret = realloc(s.buf, s.pos + 1);
+	if (!ret) {
+		free(s.buf);
+		return NULL;
+	}
+
+	ret[s.pos] = 0;
+
+	return ret;
+}
diff --git a/blobmsg_json.h b/blobmsg_json.h
index cd9ed33..9dfc02d 100644
--- a/blobmsg_json.h
+++ b/blobmsg_json.h
@@ -42,4 +42,18 @@ static inline char *blobmsg_format_json_indent(struct blob_attr *attr, bool list
 	return blobmsg_format_json_with_cb(attr, list, NULL, NULL, indent);
 }
 
+char *blobmsg_format_json_value_with_cb(struct blob_attr *attr,
+					blobmsg_json_format_t cb, void *priv,
+					int indent);
+
+static inline char *blobmsg_format_json_value(struct blob_attr *attr)
+{
+	return blobmsg_format_json_value_with_cb(attr, NULL, NULL, -1);
+}
+
+static inline char *blobmsg_format_json_value_indent(struct blob_attr *attr, int indent)
+{
+	return blobmsg_format_json_value_with_cb(attr, NULL, NULL, indent);
+}
+
 #endif
-- 
2.9.0



From mschiffer at universe-factory.net  Tue Jun 21 08:19:11 2016
From: mschiffer at universe-factory.net (Matthias Schiffer)
Date: Tue, 21 Jun 2016 17:19:11 +0200
Subject: [LEDE-DEV] [PATCH libubox v2 2/3] loop: make uloop_run() return the
	cancelling signal
In-Reply-To: <cc8bcc58421ebdbf8e65cef24e8eeb0dd4b1e510.1466522197.git.mschiffer@universe-factory.net>
References: <cc8bcc58421ebdbf8e65cef24e8eeb0dd4b1e510.1466522197.git.mschiffer@universe-factory.net>
Message-ID: <cbeb823de9ed12bd6e453eb15ffdd27796ab8436.1466522197.git.mschiffer@universe-factory.net>

When a process quits in response to a signal it handles, it should to so
be re-sending the signal to itself. This especially important for SIGINT,
as is explained in [1].

uloop currently hides the reason for quitting uloop_run(). Fix this by
returning the signal that caused the loop to quit (or 0 when uloop_end()
was used), so a program using loop an comply with [1].

[1] https://www.cons.org/cracauer/sigint.html

Signed-off-by: Matthias Schiffer <mschiffer at universe-factory.net>
---
v2: keep uloop_cancelled in addition to uloop_status to make libubus happy

 uloop.c | 9 +++++++--
 uloop.h | 2 +-
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/uloop.c b/uloop.c
index cd3de85..89c49a3 100644
--- a/uloop.c
+++ b/uloop.c
@@ -58,6 +58,7 @@ static struct list_head processes = LIST_HEAD_INIT(processes);
 
 static int poll_fd = -1;
 bool uloop_cancelled = false;
+static int uloop_status = 0;
 static bool do_sigchld = false;
 
 static struct uloop_fd_event cur_fds[ULOOP_MAX_EVENTS];
@@ -330,6 +331,7 @@ static void uloop_handle_processes(void)
 
 static void uloop_handle_sigint(int signo)
 {
+	uloop_status = signo;
 	uloop_cancelled = true;
 }
 
@@ -443,7 +445,7 @@ static void uloop_clear_processes(void)
 		uloop_process_delete(p);
 }
 
-void uloop_run(void)
+int uloop_run(void)
 {
 	static int recursive_calls = 0;
 	struct timeval tv;
@@ -455,8 +457,9 @@ void uloop_run(void)
 	if (!recursive_calls++)
 		uloop_setup_signals(true);
 
+	uloop_status = 0;
 	uloop_cancelled = false;
-	while(!uloop_cancelled)
+	while (!uloop_cancelled)
 	{
 		uloop_gettime(&tv);
 		uloop_process_timeouts(&tv);
@@ -473,6 +476,8 @@ void uloop_run(void)
 
 	if (!--recursive_calls)
 		uloop_setup_signals(false);
+
+	return uloop_status;
 }
 
 void uloop_done(void)
diff --git a/uloop.h b/uloop.h
index 7564514..2f1eb4c 100644
--- a/uloop.h
+++ b/uloop.h
@@ -103,7 +103,7 @@ static inline void uloop_end(void)
 }
 
 int uloop_init(void);
-void uloop_run(void);
+int uloop_run(void);
 void uloop_done(void);
 
 #endif
-- 
2.9.0



From mschiffer at universe-factory.net  Tue Jun 21 08:19:10 2016
From: mschiffer at universe-factory.net (Matthias Schiffer)
Date: Tue, 21 Jun 2016 17:19:10 +0200
Subject: [LEDE-DEV] [PATCH libubox v2 1/3] Fix various memory management
	issues
Message-ID: <cc8bcc58421ebdbf8e65cef24e8eeb0dd4b1e510.1466522197.git.mschiffer@universe-factory.net>

Consistently handle allocation failures. Some functions are changed to
return bool or int instead of void to allow returning an error.

Also fix a buffer size miscalculation in lua/uloop and use _exit() instead
of exit() on errors after forking.

Signed-off-by: Matthias Schiffer <mschiffer at universe-factory.net>
---
v2:
- make blobmsg_*printf functions return int
- use _exit in forked process in lua/uloop
- avoid using "new" as identifier


 blobmsg.c      | 22 ++++++++++++++++------
 blobmsg.h      |  4 ++--
 blobmsg_json.c | 30 +++++++++++++++++++++++-------
 jshn.c         |  4 ++++
 json_script.c  | 17 +++++++++++++++--
 kvlist.c       | 11 ++++++++---
 kvlist.h       |  2 +-
 lua/uloop.c    |  7 +++++--
 ustream.c      |  7 +++++++
 utils.c        |  2 ++
 10 files changed, 83 insertions(+), 23 deletions(-)

diff --git a/blobmsg.c b/blobmsg.c
index 80b984a..1e93376 100644
--- a/blobmsg.c
+++ b/blobmsg.c
@@ -227,29 +227,38 @@ blobmsg_open_nested(struct blob_buf *buf, const char *name, bool array)
 	return (void *)offset;
 }
 
-void
+int
 blobmsg_vprintf(struct blob_buf *buf, const char *name, const char *format, va_list arg)
 {
 	va_list arg2;
 	char cbuf;
-	int len;
+	char *sbuf;
+	int len, ret;
 
 	va_copy(arg2, arg);
 	len = vsnprintf(&cbuf, sizeof(cbuf), format, arg2);
 	va_end(arg2);
 
-	vsprintf(blobmsg_alloc_string_buffer(buf, name, len + 1), format, arg);
+	sbuf = blobmsg_alloc_string_buffer(buf, name, len + 1);
+	if (!sbuf)
+		return -1;
+	ret = vsprintf(sbuf, format, arg);
 	blobmsg_add_string_buffer(buf);
+
+	return ret;
 }
 
-void
+int
 blobmsg_printf(struct blob_buf *buf, const char *name, const char *format, ...)
 {
 	va_list ap;
+	int ret;
 
 	va_start(ap, format);
-	blobmsg_vprintf(buf, name, format, ap);
+	ret = blobmsg_vprintf(buf, name, format, ap);
 	va_end(ap);
+
+	return ret;
 }
 
 void *
@@ -278,7 +287,8 @@ blobmsg_realloc_string_buffer(struct blob_buf *buf, unsigned int maxlen)
 	if (required <= 0)
 		goto out;
 
-	blob_buf_grow(buf, required);
+	if (!blob_buf_grow(buf, required))
+		return NULL;
 	attr = blob_next(buf->head);
 
 out:
diff --git a/blobmsg.h b/blobmsg.h
index e58f95d..84997a6 100644
--- a/blobmsg.h
+++ b/blobmsg.h
@@ -224,8 +224,8 @@ void *blobmsg_alloc_string_buffer(struct blob_buf *buf, const char *name, unsign
 void *blobmsg_realloc_string_buffer(struct blob_buf *buf, unsigned int maxlen);
 void blobmsg_add_string_buffer(struct blob_buf *buf);
 
-void blobmsg_vprintf(struct blob_buf *buf, const char *name, const char *format, va_list arg);
-void blobmsg_printf(struct blob_buf *buf, const char *name, const char *format, ...)
+int blobmsg_vprintf(struct blob_buf *buf, const char *name, const char *format, va_list arg);
+int blobmsg_printf(struct blob_buf *buf, const char *name, const char *format, ...)
      __attribute__((format(printf, 3, 4)));
 
 
diff --git a/blobmsg_json.c b/blobmsg_json.c
index 5713948..2e318b2 100644
--- a/blobmsg_json.c
+++ b/blobmsg_json.c
@@ -119,15 +119,22 @@ struct strbuf {
 
 static bool blobmsg_puts(struct strbuf *s, const char *c, int len)
 {
+	size_t new_len;
+	char *new_buf;
+
 	if (len <= 0)
 		return true;
 
 	if (s->pos + len >= s->len) {
-		s->len += 16 + len;
-		s->buf = realloc(s->buf, s->len);
-		if (!s->buf)
+		new_len = s->len + 16 + len;
+		new_buf = realloc(s->buf, new_len);
+		if (!new_buf)
 			return false;
+
+		s->len = new_len;
+		s->buf = new_buf;
 	}
+
 	memcpy(s->buf + s->pos, c, len);
 	s->pos += len;
 	return true;
@@ -290,14 +297,18 @@ char *blobmsg_format_json_with_cb(struct blob_attr *attr, bool list, blobmsg_jso
 {
 	struct strbuf s;
 	bool array;
+	char *ret;
 
 	s.len = blob_len(attr);
-	s.buf = malloc(s.len);
 	s.pos = 0;
 	s.custom_format = cb;
 	s.priv = priv;
 	s.indent = false;
 
+	s.buf = malloc(s.len);
+	if (!s.buf)
+		return NULL;
+
 	if (indent >= 0) {
 		s.indent = true;
 		s.indent_level = indent;
@@ -316,8 +327,13 @@ char *blobmsg_format_json_with_cb(struct blob_attr *attr, bool list, blobmsg_jso
 		return NULL;
 	}
 
-	s.buf = realloc(s.buf, s.pos + 1);
-	s.buf[s.pos] = 0;
+	ret = realloc(s.buf, s.pos + 1);
+	if (!ret) {
+		free(s.buf);
+		return NULL;
+	}
+
+	ret[s.pos] = 0;
 
-	return s.buf;
+	return ret;
 }
diff --git a/jshn.c b/jshn.c
index e2d9022..4989099 100644
--- a/jshn.c
+++ b/jshn.c
@@ -338,6 +338,10 @@ int main(int argc, char **argv)
 	for (i = 0; environ[i]; i++);
 
 	vars = calloc(i, sizeof(*vars));
+	if (!vars) {
+		fprintf(stderr, "%m\n");
+		return -1;
+	}
 	for (i = 0; environ[i]; i++) {
 		char *c;
 
diff --git a/json_script.c b/json_script.c
index b5d414d..463aac8 100644
--- a/json_script.c
+++ b/json_script.c
@@ -45,6 +45,9 @@ json_script_file_from_blobmsg(const char *name, void *data, int len)
 		name_len = strlen(name) + 1;
 
 	f = calloc_a(sizeof(*f) + len, &new_name, name_len);
+	if (!f)
+		return NULL;
+
 	memcpy(f->data, data, len);
 	if (name)
 		f->avl.key = strcpy(new_name, name);
@@ -426,12 +429,15 @@ static int eval_string(struct json_call *call, struct blob_buf *buf, const char
 	char c = '%';
 
 	dest = blobmsg_alloc_string_buffer(buf, name, 1);
+	if (!dest)
+		return -1;
+
 	next = alloca(strlen(pattern) + 1);
 	strcpy(next, pattern);
 
 	for (str = next; str; str = next) {
 		const char *cur;
-		char *end;
+		char *end, *new_buf;
 		int cur_len = 0;
 		bool cur_var = var;
 
@@ -464,7 +470,14 @@ static int eval_string(struct json_call *call, struct blob_buf *buf, const char
 			cur_len = end - str;
 		}
 
-		dest = blobmsg_realloc_string_buffer(buf, len + cur_len + 1);
+		new_buf = blobmsg_realloc_string_buffer(buf, len + cur_len + 1);
+		if (!new_buf) {
+			/* Make eval_string return -1 */
+			var = true;
+			break;
+		}
+
+		dest = new_buf;
 		memcpy(dest + len, cur, cur_len);
 		len += cur_len;
 	}
diff --git a/kvlist.c b/kvlist.c
index e0a8acb..a7b6ea0 100644
--- a/kvlist.c
+++ b/kvlist.c
@@ -71,20 +71,25 @@ bool kvlist_delete(struct kvlist *kv, const char *name)
 	return !!node;
 }
 
-void kvlist_set(struct kvlist *kv, const char *name, const void *data)
+bool kvlist_set(struct kvlist *kv, const char *name, const void *data)
 {
 	struct kvlist_node *node;
 	char *name_buf;
 	int len = kv->get_len(kv, data);
 
-	kvlist_delete(kv, name);
-
 	node = calloc_a(sizeof(struct kvlist_node) + len,
 		&name_buf, strlen(name) + 1);
+	if (!node)
+		return false;
+
+	kvlist_delete(kv, name);
+
 	memcpy(node->data, data, len);
 
 	node->avl.key = strcpy(name_buf, name);
 	avl_insert(&kv->avl, &node->avl);
+
+	return true;
 }
 
 void kvlist_free(struct kvlist *kv)
diff --git a/kvlist.h b/kvlist.h
index 0d35b46..d59ff9e 100644
--- a/kvlist.h
+++ b/kvlist.h
@@ -45,7 +45,7 @@ struct kvlist_node {
 void kvlist_init(struct kvlist *kv, int (*get_len)(struct kvlist *kv, const void *data));
 void kvlist_free(struct kvlist *kv);
 void *kvlist_get(struct kvlist *kv, const char *name);
-void kvlist_set(struct kvlist *kv, const char *name, const void *data);
+bool kvlist_set(struct kvlist *kv, const char *name, const void *data);
 bool kvlist_delete(struct kvlist *kv, const char *name);
 
 int kvlist_strlen(struct kvlist *kv, const void *data);
diff --git a/lua/uloop.c b/lua/uloop.c
index 782b5a5..c5dd12f 100644
--- a/lua/uloop.c
+++ b/lua/uloop.c
@@ -325,9 +325,12 @@ static int ul_process(lua_State *L)
 		int argn = lua_objlen(L, -3);
 		int envn = lua_objlen(L, -2);
 		char** argp = malloc(sizeof(char*) * (argn + 2));
-		char** envp = malloc(sizeof(char*) * envn + 1);
+		char** envp = malloc(sizeof(char*) * (envn + 1));
 		int i = 1;
 
+		if (!argp || !envp)
+			_exit(-1);
+
 		argp[0] = (char*) lua_tostring(L, -4);
 		for (i = 1; i <= argn; i++) {
 			lua_rawgeti(L, -3, i);
@@ -344,7 +347,7 @@ static int ul_process(lua_State *L)
 		envp[i - 1] = NULL;
 
 		execve(*argp, argp, envp);
-		exit(-1);
+		_exit(-1);
 	}
 
 	lua_getglobal(L, "__uloop_cb");
diff --git a/ustream.c b/ustream.c
index e7ee9f0..d36ce08 100644
--- a/ustream.c
+++ b/ustream.c
@@ -65,6 +65,9 @@ static int ustream_alloc_default(struct ustream *s, struct ustream_buf_list *l)
 		return -1;
 
 	buf = malloc(sizeof(*buf) + l->buffer_len + s->string_data);
+	if (!buf)
+		return -1;
+
 	ustream_init_buf(buf, l->buffer_len);
 	ustream_add_buf(l, buf);
 
@@ -490,6 +493,8 @@ int ustream_vprintf(struct ustream *s, const char *format, va_list arg)
 			return ustream_write_buffered(s, buf, maxlen, wr);
 		} else {
 			buf = malloc(maxlen + 1);
+			if (!buf)
+				return 0;
 			wr = vsnprintf(buf, maxlen + 1, format, arg);
 			wr = ustream_write(s, buf, wr, false);
 			free(buf);
@@ -517,6 +522,8 @@ int ustream_vprintf(struct ustream *s, const char *format, va_list arg)
 		return wr;
 
 	buf = malloc(maxlen + 1);
+	if (!buf)
+		return wr;
 	maxlen = vsnprintf(buf, maxlen + 1, format, arg);
 	wr = ustream_write_buffered(s, buf + wr, maxlen - wr, wr);
 	free(buf);
diff --git a/utils.c b/utils.c
index 8fd19f4..91dd71e 100644
--- a/utils.c
+++ b/utils.c
@@ -43,6 +43,8 @@ void *__calloc_a(size_t len, ...)
 	va_end(ap1);
 
 	ptr = calloc(1, alloc_len);
+	if (!ptr)
+		return NULL;
 	alloc_len = 0;
 	foreach_arg(ap, cur_addr, cur_len, &ret, len) {
 		*cur_addr = &ptr[alloc_len];
-- 
2.9.0



From ianchi74 at outlook.com  Tue Jun 21 11:55:28 2016
From: ianchi74 at outlook.com (Adrian Panella)
Date: Tue, 21 Jun 2016 13:55:28 -0500
Subject: [LEDE-DEV] [PATCH] ath10k-ct: Update to latest 10.4.3 CT
	firmware	for 9980 chipsets.
In-Reply-To: <1466471578-30311-1-git-send-email-greearb@candelatech.com>
References: <1466471578-30311-1-git-send-email-greearb@candelatech.com>
Message-ID: <BLU405-EAS10157385BD0817D18E44F9ADB2B0@phx.gbl>

Hi Ben,
                                      
>-----Original Message-----
>From: Ben Greear <greearb at candelatech.com>
>
>This works around regressions added in the 4.7 kernel.

Tried it but still have the recurrent stack trace warning we had after the
last compat-wireless update. 
This was the most "visible" regression we were experiencing we the updated
ath10k drivers. Which other problems are you addressing?

I'm not exactly sure, but it seems that the trace is now a little less
frequent.

This is an extract of the console log (from Linksys EA8500 router):


[   11.427882] ath10k_pci 0000:01:00.0: firmware ver
10.4.3-ct-fW-007-41d8756 api 5 features peer-flow-ctrl crc32 5451981c

.....

[  936.407284] ------------[ cut here ]------------

[  936.407406] WARNING: CPU: 0 PID: 0 at
compat-wireless-2016-05-12/net/mac80211/rx.c:4068
ieee80211_rx_napi+0x8c/0x8a4 [mac80211]()

[  936.410974] Modules linked in: pppoe ppp_async iptable_nat pppox
ppp_generic nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT
ipt_MASQUERADE xt_time xt_tcpudp xt_tcpmss xt_statisth
[  936.557402] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W
4.4.13 #2

[  936.557754] Hardware name: Qualcomm (Flattened Device Tree)

[  936.564889] [<c021fea4>] (unwind_backtrace) from [<c021cb0c>]
(show_stack+0x10/0x14)

[  936.570270] [<c021cb0c>] (show_stack) from [<c03a1de0>]
(dump_stack+0x88/0x9c)

[  936.578252] [<c03a1de0>] (dump_stack) from [<c0227a4c>]
(warn_slowpath_common+0x94/0xb0)

[  936.585282] [<c0227a4c>] (warn_slowpath_common) from [<c0227b04>]
(warn_slowpath_null+0x1c/0x24)

[  936.593565] [<c0227b04>] (warn_slowpath_null) from [<bf333a44>]
(ieee80211_rx_napi+0x8c/0x8a4 [mac80211])

[  936.602400] [<bf333a44>] (ieee80211_rx_napi [mac80211]) from [<bf3a2aa0>]
(ath10k_htt_t2h_msg_handler+0x930/0x98c [ath10k_core])

[  936.611811] [<bf3a2aa0>] (ath10k_htt_t2h_msg_handler [ath10k_core]) from
[<bf3a34b8>] (ath10k_htt_txrx_compl_task+0x9bc/0x115c [ath10k_core])

[  936.623422] [<bf3a34b8>] (ath10k_htt_txrx_compl_task [ath10k_core]) from
[<c022b0ec>] (tasklet_action+0xb8/0x144)

[  936.635978] [<c022b0ec>] (tasklet_action) from [<c022b2c0>]
(__do_softirq+0xe0/0x21c)

[  936.646216] [<c022b2c0>] (__do_softirq) from [<c022b68c>]
(irq_exit+0x98/0xec)

[  936.654033] [<c022b68c>] (irq_exit) from [<c02653fc>]
(__handle_domain_irq+0xbc/0xe4)

[  936.661149] [<c02653fc>] (__handle_domain_irq) from [<c0209410>]
(gic_handle_irq+0x54/0x94)

[  936.669048] [<c0209410>] (gic_handle_irq) from [<c020a594>]
(__irq_svc+0x54/0x90)

[  936.677200] Exception stack(0xc0775f50 to 0xc0775f98)

[  936.684840] 5f40:                                     00000001 00000000
00000000 c020b4a0

[  936.689884] 5f60: c0774000 c0776480 c0682740 00000000 00000000 c07702e4
c0775fa8 c0776488

[  936.698041] 5f80: c0776140 c0775fa0 c0219d54 c0219d58 60000013 ffffffff

[  936.706195] [<c020a594>] (__irq_svc) from [<c0219d58>]
(arch_cpu_idle+0x34/0x50)

[  936.712623] [<c0219d58>] (arch_cpu_idle) from [<c025c95c>]
(cpu_startup_entry+0x178/0x24c)

[  936.720266] [<c025c95c>] (cpu_startup_entry) from [<c0743d2c>]
(start_kernel+0x434/0x440)

[  936.728400] ---[ end trace d771ca9672150ac3 ]---                   



From greearb at candelatech.com  Tue Jun 21 11:57:13 2016
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 21 Jun 2016 11:57:13 -0700
Subject: [LEDE-DEV] [PATCH] ath10k-ct: Update to latest 10.4.3 CT
 firmware for 9980 chipsets.
In-Reply-To: <BLU405-EAS10157385BD0817D18E44F9ADB2B0@phx.gbl>
References: <1466471578-30311-1-git-send-email-greearb@candelatech.com>
 <BLU405-EAS10157385BD0817D18E44F9ADB2B0@phx.gbl>
Message-ID: <57698E09.7020203@candelatech.com>

On 06/21/2016 11:55 AM, Adrian Panella wrote:
> Hi Ben,
>
>> -----Original Message-----
>> From: Ben Greear <greearb at candelatech.com>
>>
>> This works around regressions added in the 4.7 kernel.
>
> Tried it but still have the recurrent stack trace warning we had after the
> last compat-wireless update.
> This was the most "visible" regression we were experiencing we the updated
> ath10k drivers. Which other problems are you addressing?
>
> I'm not exactly sure, but it seems that the trace is now a little less
> frequent.

I think your splat is a kernel/driver issue, not firmware related.  Working on
a patch to enable my driver now...

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From hauke at hauke-m.de  Tue Jun 21 13:05:44 2016
From: hauke at hauke-m.de (Hauke Mehrtens)
Date: Tue, 21 Jun 2016 22:05:44 +0200
Subject: [LEDE-DEV] [PATCH] squashfs4: use upstream xz compression header
	format
Message-ID: <1466539544-706-1-git-send-email-hauke@hauke-m.de>

In the upstream kernel and the upstream squashfs4 tools the xz
compression header looks the following:
struct disk_comp_opts {
        __le32 dictionary_size;
        __le32 flags;
};

We added some other members and also moved some existing members. Place
the members which are already in upstream header at the same position
as in that kernel and add our own at the end. The kernel should not
have a problem when there are some additional members and just ignore
them.

Signed-off-by: Hauke Mehrtens <hauke at hauke-m.de>
---
 .../520-squashfs_update_xz_comp_opts.patch         | 25 ----------------------
 .../520-squashfs_update_xz_comp_opts.patch         | 25 ----------------------
 .../520-squashfs_update_xz_comp_opts.patch         | 25 ----------------------
 .../patches/160-expose_lzma_xz_options.patch       |  2 +-
 4 files changed, 1 insertion(+), 76 deletions(-)
 delete mode 100644 target/linux/generic/patches-3.18/520-squashfs_update_xz_comp_opts.patch
 delete mode 100644 target/linux/generic/patches-4.1/520-squashfs_update_xz_comp_opts.patch
 delete mode 100644 target/linux/generic/patches-4.4/520-squashfs_update_xz_comp_opts.patch

diff --git a/target/linux/generic/patches-3.18/520-squashfs_update_xz_comp_opts.patch b/target/linux/generic/patches-3.18/520-squashfs_update_xz_comp_opts.patch
deleted file mode 100644
index ad11b30..0000000
--- a/target/linux/generic/patches-3.18/520-squashfs_update_xz_comp_opts.patch
+++ /dev/null
@@ -1,25 +0,0 @@
-From f31b7c0efa255dd17a5f584022a319387f09b0d8 Mon Sep 17 00:00:00 2001
-From: Jonas Gorski <jonas.gorski at gmail.com>
-Date: Tue, 12 Apr 2011 19:55:41 +0200
-Subject: [PATCH] squashfs: update xz compressor options struct.
-
-Update the xz compressor options struct to match the squashfs userspace
-one.
----
- fs/squashfs/xz_wrapper.c |    4 +++-
- 1 files changed, 3 insertions(+), 1 deletions(-)
-
---- a/fs/squashfs/xz_wrapper.c
-+++ b/fs/squashfs/xz_wrapper.c
-@@ -40,8 +40,10 @@ struct squashfs_xz {
- };
- 
- struct disk_comp_opts {
--	__le32 dictionary_size;
- 	__le32 flags;
-+	__le16 bit_opts;
-+	__le16 fb;
-+	__le32 dictionary_size;
- };
- 
- struct comp_opts {
diff --git a/target/linux/generic/patches-4.1/520-squashfs_update_xz_comp_opts.patch b/target/linux/generic/patches-4.1/520-squashfs_update_xz_comp_opts.patch
deleted file mode 100644
index ad11b30..0000000
--- a/target/linux/generic/patches-4.1/520-squashfs_update_xz_comp_opts.patch
+++ /dev/null
@@ -1,25 +0,0 @@
-From f31b7c0efa255dd17a5f584022a319387f09b0d8 Mon Sep 17 00:00:00 2001
-From: Jonas Gorski <jonas.gorski at gmail.com>
-Date: Tue, 12 Apr 2011 19:55:41 +0200
-Subject: [PATCH] squashfs: update xz compressor options struct.
-
-Update the xz compressor options struct to match the squashfs userspace
-one.
----
- fs/squashfs/xz_wrapper.c |    4 +++-
- 1 files changed, 3 insertions(+), 1 deletions(-)
-
---- a/fs/squashfs/xz_wrapper.c
-+++ b/fs/squashfs/xz_wrapper.c
-@@ -40,8 +40,10 @@ struct squashfs_xz {
- };
- 
- struct disk_comp_opts {
--	__le32 dictionary_size;
- 	__le32 flags;
-+	__le16 bit_opts;
-+	__le16 fb;
-+	__le32 dictionary_size;
- };
- 
- struct comp_opts {
diff --git a/target/linux/generic/patches-4.4/520-squashfs_update_xz_comp_opts.patch b/target/linux/generic/patches-4.4/520-squashfs_update_xz_comp_opts.patch
deleted file mode 100644
index ad11b30..0000000
--- a/target/linux/generic/patches-4.4/520-squashfs_update_xz_comp_opts.patch
+++ /dev/null
@@ -1,25 +0,0 @@
-From f31b7c0efa255dd17a5f584022a319387f09b0d8 Mon Sep 17 00:00:00 2001
-From: Jonas Gorski <jonas.gorski at gmail.com>
-Date: Tue, 12 Apr 2011 19:55:41 +0200
-Subject: [PATCH] squashfs: update xz compressor options struct.
-
-Update the xz compressor options struct to match the squashfs userspace
-one.
----
- fs/squashfs/xz_wrapper.c |    4 +++-
- 1 files changed, 3 insertions(+), 1 deletions(-)
-
---- a/fs/squashfs/xz_wrapper.c
-+++ b/fs/squashfs/xz_wrapper.c
-@@ -40,8 +40,10 @@ struct squashfs_xz {
- };
- 
- struct disk_comp_opts {
--	__le32 dictionary_size;
- 	__le32 flags;
-+	__le16 bit_opts;
-+	__le16 fb;
-+	__le32 dictionary_size;
- };
- 
- struct comp_opts {
diff --git a/tools/squashfs4/patches/160-expose_lzma_xz_options.patch b/tools/squashfs4/patches/160-expose_lzma_xz_options.patch
index 2fbd954..9e1c1fb 100644
--- a/tools/squashfs4/patches/160-expose_lzma_xz_options.patch
+++ b/tools/squashfs4/patches/160-expose_lzma_xz_options.patch
@@ -40,6 +40,7 @@
 +
 +
 +struct lzma_opts {
++	uint32_t dict_size;
 +	uint32_t flags;
 +#define LZMA_OPT_FLT_MASK	0xffff
 +#define LZMA_OPT_PRE_OFF	16
@@ -53,7 +54,6 @@
 +#define LZMA_OPT_PB_OFF		6
 +#define LZMA_OPT_PB_MASK	(0x7 << LZMA_OPT_PB_OFF)
 +	uint16_t fb;
-+	uint32_t dict_size;
 +};
 +
 +#if __BYTE_ORDER == __BIG_ENDIAN
-- 
2.8.1



From hauke at hauke-m.de  Tue Jun 21 13:07:04 2016
From: hauke at hauke-m.de (Hauke Mehrtens)
Date: Tue, 21 Jun 2016 22:07:04 +0200
Subject: [LEDE-DEV] [PATCH] kernel: fix missing break in ubi auto-mounting
	patch
Message-ID: <1466539624-769-1-git-send-email-hauke@hauke-m.de>

Signed-off-by: Hauke Mehrtens <hauke at hauke-m.de>
---
 .../492-try-auto-mounting-ubi0-rootfs-in-init-do_mounts.c.patch      | 3 ++-
 .../492-try-auto-mounting-ubi0-rootfs-in-init-do_mounts.c.patch      | 3 ++-
 .../492-try-auto-mounting-ubi0-rootfs-in-init-do_mounts.c.patch      | 5 +++--
 3 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/target/linux/generic/patches-3.18/492-try-auto-mounting-ubi0-rootfs-in-init-do_mounts.c.patch b/target/linux/generic/patches-3.18/492-try-auto-mounting-ubi0-rootfs-in-init-do_mounts.c.patch
index e4f31fd..3f2b439 100644
--- a/target/linux/generic/patches-3.18/492-try-auto-mounting-ubi0-rootfs-in-init-do_mounts.c.patch
+++ b/target/linux/generic/patches-3.18/492-try-auto-mounting-ubi0-rootfs-in-init-do_mounts.c.patch
@@ -11,7 +11,7 @@ Signed-off-by: Daniel Golle <daniel at makrotopia.org>
 
 --- a/init/do_mounts.c
 +++ b/init/do_mounts.c
-@@ -433,7 +433,27 @@ retry:
+@@ -433,7 +433,28 @@ retry:
  out:
  	put_page(page);
  }
@@ -29,6 +29,7 @@ Signed-off-by: Daniel Golle <daniel at makrotopia.org>
 +			case -EACCES:
 +				flags |= MS_RDONLY;
 +				tried++;
++				break;
 +			default:
 +				return err;
 +		}
diff --git a/target/linux/generic/patches-4.1/492-try-auto-mounting-ubi0-rootfs-in-init-do_mounts.c.patch b/target/linux/generic/patches-4.1/492-try-auto-mounting-ubi0-rootfs-in-init-do_mounts.c.patch
index 005de3f..f6c71a2 100644
--- a/target/linux/generic/patches-4.1/492-try-auto-mounting-ubi0-rootfs-in-init-do_mounts.c.patch
+++ b/target/linux/generic/patches-4.1/492-try-auto-mounting-ubi0-rootfs-in-init-do_mounts.c.patch
@@ -11,7 +11,7 @@ Signed-off-by: Daniel Golle <daniel at makrotopia.org>
 
 --- a/init/do_mounts.c
 +++ b/init/do_mounts.c
-@@ -438,7 +438,27 @@ retry:
+@@ -438,7 +438,28 @@ retry:
  out:
  	put_page(page);
  }
@@ -29,6 +29,7 @@ Signed-off-by: Daniel Golle <daniel at makrotopia.org>
 +			case -EACCES:
 +				flags |= MS_RDONLY;
 +				tried++;
++				break;
 +			default:
 +				return err;
 +		}
diff --git a/target/linux/generic/patches-4.4/492-try-auto-mounting-ubi0-rootfs-in-init-do_mounts.c.patch b/target/linux/generic/patches-4.4/492-try-auto-mounting-ubi0-rootfs-in-init-do_mounts.c.patch
index d21e6d2..ab8b8bb 100644
--- a/target/linux/generic/patches-4.4/492-try-auto-mounting-ubi0-rootfs-in-init-do_mounts.c.patch
+++ b/target/linux/generic/patches-4.4/492-try-auto-mounting-ubi0-rootfs-in-init-do_mounts.c.patch
@@ -11,7 +11,7 @@ Signed-off-by: Daniel Golle <daniel at makrotopia.org>
 
 --- a/init/do_mounts.c
 +++ b/init/do_mounts.c
-@@ -438,7 +438,27 @@ retry:
+@@ -438,7 +438,28 @@ retry:
  out:
  	put_page(page);
  }
@@ -29,6 +29,7 @@ Signed-off-by: Daniel Golle <daniel at makrotopia.org>
 +			case -EACCES:
 +				flags |= MS_RDONLY;
 +				tried++;
++				break;
 +			default:
 +				return err;
 +		}
@@ -40,7 +41,7 @@ Signed-off-by: Daniel Golle <daniel at makrotopia.org>
  #ifdef CONFIG_ROOT_NFS
  
  #define NFSROOT_TIMEOUT_MIN	5
-@@ -532,6 +552,10 @@ void __init mount_root(void)
+@@ -532,6 +553,10 @@ void __init mount_root(void)
  			change_floppy("root floppy");
  	}
  #endif
-- 
2.8.1



From eschultz at prplfoundation.org  Tue Jun 21 13:17:38 2016
From: eschultz at prplfoundation.org (Eric Schultz)
Date: Tue, 21 Jun 2016 15:17:38 -0500
Subject: [LEDE-DEV] TR-069 and OpenWrt Meeting Videos
Message-ID: <5769A0E2.2000709@prplfoundation.org>

I've posted the recordings of the TR-069 and OpenWrt Meetings from June
10 and June 17. Check them out via the links below if you're interested
in the discussion.

* June 10 - https://youtu.be/U2SiveQwKm8
* June 17 - https://youtu.be/Hvqi1EFs_U0

We'll be having another meeting this week on June 24 at 7AM PT as well;
everyone interested is welcome to join. Be on the lookout for the
connection info in the next few days.

Thanks everyone,

Eric


From arjen+lede at de-korte.org  Tue Jun 21 13:19:49 2016
From: arjen+lede at de-korte.org (Arjen de Korte)
Date: Tue, 21 Jun 2016 22:19:49 +0200
Subject: [LEDE-DEV] ar71xx - please help test
In-Reply-To: <bfd64b04-7942-19a8-0eda-911840448cb7@phrozen.org>
Message-ID: <20160621221949.Horde.VzKiOvLi7c3Vj5ykeWgjxYj@mail.de-korte.org>

Citeren John Crispin <john at phrozen.org>:

> Hi,
>
> i have moved all the profiles into the image building code. i have done
> some basic testing and already got a bit of feedback from others.
>
> it would be nice if people could help test the following patch from my
> staging tree
>
> https://git.lede-project.org/?p=lede/blogic/staging.git;a=commit;h=75773d43cd44ee70e293343fad11db654c35a4ed

Patch checked with r762 on a Netgear WNDR-4300. All is well (with the  
already mentioned whitespace issues when applying the patch).

Arjen




From greearb at candelatech.com  Tue Jun 21 13:08:23 2016
From: greearb at candelatech.com (greearb at candelatech.com)
Date: Tue, 21 Jun 2016 13:08:23 -0700
Subject: [LEDE-DEV] [RFC] Support ath10k-ct out-of-tree driver.
Message-ID: <1466539703-21033-1-git-send-email-greearb@candelatech.com>

From: Ben Greear <greearb at candelatech.com>

This lets one use the ath10k-ct driver instead of the built-in
ath10k driver from the upstream kernel (or backports).

Signed-off-by: Ben Greear <greearb at candelatech.com>
---

This has been lightly tested with ath10k-ct firmware on 9880
hardware.

*THIS PATCH BREAKS ath9k*  because I am compiling ath10k against
my own ath.ko, and so load my own ath.ko.  I am not sure the
best way to fix this:  Compile my own ath* modules to replace
upstream, or fix just my ath10k sub-dir to build on it's own
and link against standard ath module....

 package/firmware/ath10k-firmware/Makefile |  2 +-
 package/kernel/ath-ct/Makefile            | 60 +++++++++++++++++++++++++++++++
 2 files changed, 61 insertions(+), 1 deletion(-)
 create mode 100644 package/kernel/ath-ct/Makefile

diff --git a/package/firmware/ath10k-firmware/Makefile b/package/firmware/ath10k-firmware/Makefile
index fcd6167..635aede 100644
--- a/package/firmware/ath10k-firmware/Makefile
+++ b/package/firmware/ath10k-firmware/Makefile
@@ -28,7 +28,7 @@ define Package/ath10k-firmware-default
   CATEGORY:=Kernel modules
   SUBMENU:=$(WMENU)
   URL:=$(PKG_SOURCE_URL)
-  DEPENDS:=kmod-ath10k
+  DEPENDS:=
 endef
 
 define Package/ath10k-firmware-qca988x
diff --git a/package/kernel/ath-ct/Makefile b/package/kernel/ath-ct/Makefile
new file mode 100644
index 0000000..ded41a7
--- /dev/null
+++ b/package/kernel/ath-ct/Makefile
@@ -0,0 +1,60 @@
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=ath-ct
+PKG_VERSION:=2016-06-21
+PKG_RELEASE=1
+
+PKG_LICENSE:=GPLv2
+PKG_LICENSE_FILES:=
+
+PKG_SOURCE_URL:=https://github.com/greearb/ath-ct.git
+PKG_SOURCE_PROTO:=git
+PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
+PKG_SOURCE_VERSION:=7531f0b1798a4af500eb1860f7fd9dcaa727d3fb
+PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.xz
+
+PKG_MAINTAINER:=Ben Greear <greearb at candelatech.com>
+PKG_BUILD_PARALLEL:=1
+
+STAMP_CONFIGURED_DEPENDS := $(STAGING_DIR)/usr/include/mac80211-backport/backport/autoconf.h
+
+include $(INCLUDE_DIR)/kernel.mk
+include $(INCLUDE_DIR)/package.mk
+
+define KernelPackage/ath-ct
+  SUBMENU:=Wireless Drivers
+  TITLE:=ath10k-ct driver optimized for CT ath10k firmware
+  DEPENDS:=+kmod-mac80211 +kmod-ath + at DRIVER_11N_SUPPORT @PCI_SUPPORT
+  FILES:=\
+	$(PKG_BUILD_DIR)/ath.ko \
+	$(PKG_BUILD_DIR)/ath10k/ath10k_pci.ko \
+	$(PKG_BUILD_DIR)/ath10k/ath10k_core.ko
+  AUTOLOAD:=$(call AutoLoad,50,mac80211 ath ath10k_core ath10k_pci)
+endef
+
+NOSTDINC_FLAGS = \
+	-I$(PKG_BUILD_DIR) \
+	-I$(PKG_BUILD_DIR)/ath10k \
+	-I$(STAGING_DIR)/usr/include/mac80211-backport/uapi \
+	-I$(STAGING_DIR)/usr/include/mac80211-backport \
+	-I$(STAGING_DIR)/usr/include/mac80211/uapi \
+	-I$(STAGING_DIR)/usr/include/mac80211 \
+	-include backport/autoconf.h \
+	-include backport/backport.h
+
+ifdef CONFIG_PACKAGE_MAC80211_MESH
+  NOSTDINC_FLAGS += -DCONFIG_MAC80211_MESH
+endif
+
+define Build/Compile
+	+CONFIG_ATH_COMMON=m CONFIG_ATH_DEBUG=m \
+         CONFIG_ATH10K=m CONFIG_ATH10K_DEBUGFS=m CONFIG_MAC80211_DEBUGFS=m CONFIG_ATH10K_PCI=m \
+         $(MAKE) $(PKG_JOBS) -C "$(LINUX_DIR)" \
+		ARCH="$(LINUX_KARCH)" \
+		CROSS_COMPILE="$(TARGET_CROSS)" \
+		SUBDIRS="$(PKG_BUILD_DIR)" \
+		NOSTDINC_FLAGS="$(NOSTDINC_FLAGS)" \
+		modules
+endef
+
+$(eval $(call KernelPackage,ath-ct))
-- 
2.4.3



From chunkeey at googlemail.com  Tue Jun 21 13:22:55 2016
From: chunkeey at googlemail.com (Christian Lamparter)
Date: Tue, 21 Jun 2016 22:22:55 +0200
Subject: [LEDE-DEV] ar71xx - please help test
In-Reply-To: <bfd64b04-7942-19a8-0eda-911840448cb7@phrozen.org>
References: <bfd64b04-7942-19a8-0eda-911840448cb7@phrozen.org>
Message-ID: <1661705.W2DXy00HnN@debian64>

On Tuesday, June 21, 2016 10:23:46 AM John Crispin wrote:
> it would be nice if people could help test the following patch from my
> staging tree
> 
I tested the a patched sysupgrade for:
 - WD's My Net Wi-Fi Range Extender (MYNETREXT)
 - Netgear's WNDR3700 v2 (WNDR3700)
 - TP-Link's Archer C7 v1(ARCHERC7) 

All three updates were successful.


From hauke at hauke-m.de  Tue Jun 21 14:52:55 2016
From: hauke at hauke-m.de (Hauke Mehrtens)
Date: Tue, 21 Jun 2016 23:52:55 +0200
Subject: [LEDE-DEV] [PATCH] packages: prefer http over git for git protocol
Message-ID: <1466545975-21799-1-git-send-email-hauke@hauke-m.de>

In company networks everything except the http and https protocol is
often causes problems, because the network administrators try to block
everything else. To make it easier to use LEDE in company networks use
the https/http protocol for git access when possible.

Signed-off-by: Hauke Mehrtens <hauke at hauke-m.de>
---
 package/boot/uboot-pxa/Makefile           | 2 +-
 package/devel/trace-cmd/Makefile          | 2 +-
 package/firmware/am33x-cm3/Makefile       | 2 +-
 package/firmware/linux-firmware/Makefile  | 2 +-
 package/kernel/acx-mac80211/Makefile      | 2 +-
 package/kernel/kmod-sched-cake/Makefile   | 2 +-
 package/network/services/authsae/Makefile | 2 +-
 package/network/services/hostapd/Makefile | 2 +-
 package/network/services/odhcpd/Makefile  | 2 +-
 9 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/package/boot/uboot-pxa/Makefile b/package/boot/uboot-pxa/Makefile
index 9dae1af..23e84c8 100644
--- a/package/boot/uboot-pxa/Makefile
+++ b/package/boot/uboot-pxa/Makefile
@@ -13,7 +13,7 @@ PKG_VERSION:=2011.08.25
 PKG_RELEASE:=1
 
 PKG_SOURCE_PROTO:=git
-PKG_SOURCE_URL:=git://github.com/ashcharles/verdex-uboot.git
+PKG_SOURCE_URL:=https://github.com/ashcharles/verdex-uboot.git
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
 PKG_SOURCE_VERSION:=ca6bf3ef6ac5f5132a359b43dfa31e07076b74b7
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.gz
diff --git a/package/devel/trace-cmd/Makefile b/package/devel/trace-cmd/Makefile
index 6ed6673..9391092 100644
--- a/package/devel/trace-cmd/Makefile
+++ b/package/devel/trace-cmd/Makefile
@@ -5,7 +5,7 @@ PKG_VERSION:=v2.4.2
 PKG_RELEASE=1
 
 PKG_SOURCE_PROTO:=git
-PKG_SOURCE_URL:=git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git
+PKG_SOURCE_URL:=https://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
 PKG_SOURCE_VERSION:=01f8e669cb035aa911f1ee0e3f94d535cbcca78f
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
diff --git a/package/firmware/am33x-cm3/Makefile b/package/firmware/am33x-cm3/Makefile
index 6f6d050..8bfeb45 100644
--- a/package/firmware/am33x-cm3/Makefile
+++ b/package/firmware/am33x-cm3/Makefile
@@ -14,7 +14,7 @@ PKG_RELEASE:=1
 PKG_SOURCE_PROTO:=git
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
-PKG_SOURCE_URL:=git://arago-project.org/git/projects/am33x-cm3.git
+PKG_SOURCE_URL:=http://arago-project.org/git/projects/am33x-cm3.git
 PKG_SOURCE_VERSION:=32cf44e25b5828b87af6dceebc3a49fed5d858ac
 PKG_MD5SUM:=40a6b7edae5e5cfff99bebde2bf20b97
 
diff --git a/package/firmware/linux-firmware/Makefile b/package/firmware/linux-firmware/Makefile
index e1e1a47..15ee4ae 100644
--- a/package/firmware/linux-firmware/Makefile
+++ b/package/firmware/linux-firmware/Makefile
@@ -16,7 +16,7 @@ PKG_SOURCE_PROTO:=git
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_SOURCE_VERSION)
 PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_SOURCE_SUBDIR)
-PKG_SOURCE_URL:=git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
+PKG_SOURCE_URL:=https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
 PKG_MIRROR_MD5SUM:=ca4d289ad9380471cae376fc7dd3660a
 
 PKG_MAINTAINER:=Felix Fietkau <nbd at nbd.name>
diff --git a/package/kernel/acx-mac80211/Makefile b/package/kernel/acx-mac80211/Makefile
index c5c020d..8fce374 100644
--- a/package/kernel/acx-mac80211/Makefile
+++ b/package/kernel/acx-mac80211/Makefile
@@ -14,7 +14,7 @@ PKG_VERSION:=20140216
 PKG_RELEASE:=1
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
-PKG_SOURCE_URL:=git://git.code.sf.net/p/acx100/acx-mac80211
+PKG_SOURCE_URL:=http://git.code.sf.net/p/acx100/acx-mac80211
 PKG_SOURCE_PROTO:=git
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
 PKG_SOURCE_VERSION:=$(PKG_REV)
diff --git a/package/kernel/kmod-sched-cake/Makefile b/package/kernel/kmod-sched-cake/Makefile
index e5fe79b..b8dd764 100644
--- a/package/kernel/kmod-sched-cake/Makefile
+++ b/package/kernel/kmod-sched-cake/Makefile
@@ -13,7 +13,7 @@ PKG_VERSION:=2016-05-31
 PKG_RELEASE:=1
 
 PKG_SOURCE_PROTO:=git
-PKG_SOURCE_URL:=git://github.com/dtaht/sch_cake
+PKG_SOURCE_URL:=https://github.com/dtaht/sch_cake.git
 PKG_SOURCE_VERSION:=292b57c714f0f9a856c5822b7b3b9fb931873db7
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.gz
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
diff --git a/package/network/services/authsae/Makefile b/package/network/services/authsae/Makefile
index d74cfef..df16054 100644
--- a/package/network/services/authsae/Makefile
+++ b/package/network/services/authsae/Makefile
@@ -12,7 +12,7 @@ PKG_VERSION:=2014-06-09
 PKG_RELEASE=$(PKG_SOURCE_VERSION)
 
 PKG_SOURCE_PROTO:=git
-PKG_SOURCE_URL:=git://github.com/cozybit/authsae.git
+PKG_SOURCE_URL:=https://github.com/cozybit/authsae.git
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
 PKG_SOURCE_VERSION:=8531ab158910a525d4bcbb3ad02c08342f6987f2
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.gz
diff --git a/package/network/services/hostapd/Makefile b/package/network/services/hostapd/Makefile
index 1b4a5d9..88f7627 100644
--- a/package/network/services/hostapd/Makefile
+++ b/package/network/services/hostapd/Makefile
@@ -12,7 +12,7 @@ PKG_RELEASE:=1
 PKG_REV:=31d3692fe5d56c05753ed4a70c7943979e1d29e7
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
-PKG_SOURCE_URL:=git://w1.fi/srv/git/hostap.git
+PKG_SOURCE_URL:=http://w1.fi/hostap.git
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
 PKG_SOURCE_VERSION:=$(PKG_REV)
 PKG_SOURCE_PROTO:=git
diff --git a/package/network/services/odhcpd/Makefile b/package/network/services/odhcpd/Makefile
index 9a2aaff..c2e506c 100644
--- a/package/network/services/odhcpd/Makefile
+++ b/package/network/services/odhcpd/Makefile
@@ -13,7 +13,7 @@ PKG_RELEASE=$(PKG_SOURCE_VERSION)
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
-PKG_SOURCE_URL:=git://github.com/sbyx/odhcpd.git
+PKG_SOURCE_URL:=https://github.com/sbyx/odhcpd.git
 PKG_SOURCE_PROTO:=git
 PKG_SOURCE_VERSION:=01d3f9d64486ac1daa144848944e877e7f0cb762
 
-- 
2.8.1



From lede at kitschensync.net  Tue Jun 21 14:59:04 2016
From: lede at kitschensync.net (Ted Hess)
Date: Tue, 21 Jun 2016 17:59:04 -0400
Subject: [LEDE-DEV] ar71xx - please help test
In-Reply-To: <bfd64b04-7942-19a8-0eda-911840448cb7@phrozen.org>
References: <bfd64b04-7942-19a8-0eda-911840448cb7@phrozen.org>
Message-ID: <1466546344.15903.3.camel@kitschensync.net>

On Tue, 2016-06-21 at 10:23 +0200, John Crispin wrote:
> Hi,
> 
> i have moved all the profiles into the image building code. i have done
> some basic testing and already got a bit of feedback from others.
> 
> it would be nice if people could help test the following patch from my
> staging tree
> 
> https://git.lede-project.org/?p=lede/blogic/staging.git;a=commit;h=75773d43cd4
> 4ee70e293343fad11db654c35a4ed
> 
> 	John
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

Built and tested OK on Ubiquiti RSPRO w/ both 2.4GHz and 5GHz Wireless cards.

/ted



From greearb at candelatech.com  Tue Jun 21 15:00:17 2016
From: greearb at candelatech.com (greearb at candelatech.com)
Date: Tue, 21 Jun 2016 15:00:17 -0700
Subject: [LEDE-DEV] [PATCH] Support Candela-Tech ath10k and ath9k
	out-of-tree driver.
Message-ID: <1466546417-19907-1-git-send-email-greearb@candelatech.com>

From: Ben Greear <greearb at candelatech.com>

This lets one use the ath9k and ath10k driver instead of the built-in
ath10k/ath9k driver from the upstream kernel (or backports).

For ath10k, this should be a drop-in replacement, as well as enabling
better CT firmware support.

For ath9k, this enables some 5Mhz channel and 4.9Ghz support,
but may loose some existing patches that LEDE carries for ath9k.

Signed-off-by: Ben Greear <greearb at candelatech.com>
---
 package/firmware/ath10k-firmware/Makefile |  2 +-
 package/kernel/ath-ct/Makefile            | 74 +++++++++++++++++++++++++++++++
 2 files changed, 75 insertions(+), 1 deletion(-)
 create mode 100644 package/kernel/ath-ct/Makefile

diff --git a/package/firmware/ath10k-firmware/Makefile b/package/firmware/ath10k-firmware/Makefile
index fcd6167..635aede 100644
--- a/package/firmware/ath10k-firmware/Makefile
+++ b/package/firmware/ath10k-firmware/Makefile
@@ -28,7 +28,7 @@ define Package/ath10k-firmware-default
   CATEGORY:=Kernel modules
   SUBMENU:=$(WMENU)
   URL:=$(PKG_SOURCE_URL)
-  DEPENDS:=kmod-ath10k
+  DEPENDS:=
 endef
 
 define Package/ath10k-firmware-qca988x
diff --git a/package/kernel/ath-ct/Makefile b/package/kernel/ath-ct/Makefile
new file mode 100644
index 0000000..4441c14
--- /dev/null
+++ b/package/kernel/ath-ct/Makefile
@@ -0,0 +1,74 @@
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=ath-ct
+PKG_VERSION:=2016-06-21
+PKG_RELEASE=1
+
+PKG_LICENSE:=GPLv2
+PKG_LICENSE_FILES:=
+
+PKG_SOURCE_URL:=https://github.com/greearb/ath-ct.git
+PKG_SOURCE_PROTO:=git
+PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
+PKG_SOURCE_VERSION:=b003b75d885595fbc18f4fd9b3aef9189a63f21e
+PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.xz
+
+PKG_MAINTAINER:=Ben Greear <greearb at candelatech.com>
+PKG_BUILD_PARALLEL:=1
+
+STAMP_CONFIGURED_DEPENDS := $(STAGING_DIR)/usr/include/mac80211-backport/backport/autoconf.h
+
+include $(INCLUDE_DIR)/kernel.mk
+include $(INCLUDE_DIR)/package.mk
+
+define KernelPackage/ath-ct
+  SUBMENU:=Wireless Drivers
+  TITLE:=ath10k-ct driver optimized for CT ath10k firmware
+  DEPENDS:=+kmod-mac80211 +kmod-ath + at DRIVER_11N_SUPPORT @PCI_SUPPORT
+  FILES:=\
+	$(PKG_BUILD_DIR)/ath.ko \
+	$(PKG_BUILD_DIR)/ath9k/ath9k_hw.ko \
+	$(PKG_BUILD_DIR)/ath9k/ath9k_common.ko \
+	$(PKG_BUILD_DIR)/ath9k/ath9k_htc.ko \
+	$(PKG_BUILD_DIR)/ath9k/ath9k_hw.ko \
+	$(PKG_BUILD_DIR)/ath9k/ath9k.ko \
+	$(PKG_BUILD_DIR)/ath10k/ath10k_pci.ko \
+	$(PKG_BUILD_DIR)/ath10k/ath10k_core.ko
+  AUTOLOAD:=$(call AutoLoad,50,mac80211 ath ath10k_core ath10k_pci)
+endef
+
+NOSTDINC_FLAGS = \
+	-I$(PKG_BUILD_DIR) \
+	-I$(STAGING_DIR)/usr/include/mac80211-backport/uapi \
+	-I$(STAGING_DIR)/usr/include/mac80211-backport \
+	-I$(STAGING_DIR)/usr/include/mac80211/uapi \
+	-I$(STAGING_DIR)/usr/include/mac80211 \
+	-include backport/autoconf.h \
+	-include backport/backport.h
+
+ifdef CONFIG_PACKAGE_MAC80211_MESH
+  NOSTDINC_FLAGS += -DCONFIG_MAC80211_MESH
+endif
+
+NOSTDINC_FLAGS += -DCONFIG_ATH10K_DEBUGFS -DCONFIG_MAC80211_DEBUGFS -DCONFIG_ATH10K_DEBUG -DCONFIG_ATH10K_AHB
+NOSTDINC_FLAGS += -DCONFIG_ATH9K_PCI -DCONFIG_ATH9K_DEBUGFS -DCONFIG_ATH9K_DFS_DEBUGFS -DCONFIG_ATH9K_CHANNEL_CONTEXT
+NOSTDINC_FLAGS += -DCONFIG_ATH9K_HTC_DEBUGFS -DCONFIG_ATH_DEBUG -DCONFIG_ATH9K_BTCOEX_SUPPORT
+NOSTDINC_FLAGS += -DCONFIG_ATH9K_RFKILL -DCONFIG_ATH9K_DYNACK -DCONFIG_ATH9K_HWRNG
+NOSTDINC_FLAGS += -DSTANDALONE_CT
+
+define Build/Compile
+	+CONFIG_ATH_COMMON=m CONFIG_ATH_DEBUG=y \
+	 CONFIG_ATH9K=m CONFIG_ATH9K_HW=m CONFIG_ATH9K_COMMON=m CONFIG_ATH9K_PCI=y \
+         CONFIG_ATH9K_HTC=m CONFIG_ATH9K_HTC_DEBUGFS=y CONFIG_ATH9K_RFKILL=y CONFIG_ATH9K_DYNACK=y \
+         CONFIG_ATH9K_DEBUGFS=y CONFIG_ATH9K_DFS_DEBUGFS=y CONFIG_ATH9K_BTCOEX_SUPPORT=y CONFIG_ATH9K_STATION_STATISTICS=m \
+         CONFIG_ATH9K_CHANNEL_CONTEXT=y CONFIG_ATH9K_HWRNG=y \
+         CONFIG_ATH10K=m CONFIG_ATH10K_DEBUGFS=y CONFIG_MAC80211_DEBUGFS=y CONFIG_ATH10K_PCI=m CONFIG_ATH10K_AHB=y \
+         $(MAKE) $(PKG_JOBS) -C "$(LINUX_DIR)" \
+		ARCH="$(LINUX_KARCH)" \
+		CROSS_COMPILE="$(TARGET_CROSS)" \
+		SUBDIRS="$(PKG_BUILD_DIR)" \
+		NOSTDINC_FLAGS="$(NOSTDINC_FLAGS)" \
+		modules
+endef
+
+$(eval $(call KernelPackage,ath-ct))
-- 
2.4.3



From david at lang.hm  Tue Jun 21 15:04:24 2016
From: david at lang.hm (David Lang)
Date: Tue, 21 Jun 2016 15:04:24 -0700 (PDT)
Subject: [LEDE-DEV] [PATCH] Support Candela-Tech ath10k and ath9k
 out-of-tree driver.
In-Reply-To: <1466546417-19907-1-git-send-email-greearb@candelatech.com>
References: <1466546417-19907-1-git-send-email-greearb@candelatech.com>
Message-ID: <alpine.DEB.2.02.1606211502590.10809@nftneq.ynat.uz>

I'll point out that there is a lot of work being done on these drivers right now 
in terms of making significant changes to how they do buffering that in 
increasing network speed as well as reducing latency

search the follwoing lists for [make-wifi-fast] to see the details and 
benchmarks
make-wifi-fast at lists.bufferbloat.net, ath9k-devel at venema.h4ckr.net,linux-wireless at vger.kernel.org

David Lang

  On Tue, 21 Jun 2016, 
greearb at candelatech.com wrote:

> Date: Tue, 21 Jun 2016 15:00:17 -0700
> From: greearb at candelatech.com
> To: lede-dev at lists.infradead.org
> Cc: Ben Greear <greearb at candelatech.com>
> Subject: [LEDE-DEV] [PATCH] Support Candela-Tech ath10k and ath9k	out-of-tree
>     driver.
> 
> From: Ben Greear <greearb at candelatech.com>
>
> This lets one use the ath9k and ath10k driver instead of the built-in
> ath10k/ath9k driver from the upstream kernel (or backports).
>
> For ath10k, this should be a drop-in replacement, as well as enabling
> better CT firmware support.
>
> For ath9k, this enables some 5Mhz channel and 4.9Ghz support,
> but may loose some existing patches that LEDE carries for ath9k.
>
> Signed-off-by: Ben Greear <greearb at candelatech.com>
> ---
> package/firmware/ath10k-firmware/Makefile |  2 +-
> package/kernel/ath-ct/Makefile            | 74 +++++++++++++++++++++++++++++++
> 2 files changed, 75 insertions(+), 1 deletion(-)
> create mode 100644 package/kernel/ath-ct/Makefile
>
> diff --git a/package/firmware/ath10k-firmware/Makefile b/package/firmware/ath10k-firmware/Makefile
> index fcd6167..635aede 100644
> --- a/package/firmware/ath10k-firmware/Makefile
> +++ b/package/firmware/ath10k-firmware/Makefile
> @@ -28,7 +28,7 @@ define Package/ath10k-firmware-default
>   CATEGORY:=Kernel modules
>   SUBMENU:=$(WMENU)
>   URL:=$(PKG_SOURCE_URL)
> -  DEPENDS:=kmod-ath10k
> +  DEPENDS:=
> endef
>
> define Package/ath10k-firmware-qca988x
> diff --git a/package/kernel/ath-ct/Makefile b/package/kernel/ath-ct/Makefile
> new file mode 100644
> index 0000000..4441c14
> --- /dev/null
> +++ b/package/kernel/ath-ct/Makefile
> @@ -0,0 +1,74 @@
> +include $(TOPDIR)/rules.mk
> +
> +PKG_NAME:=ath-ct
> +PKG_VERSION:=2016-06-21
> +PKG_RELEASE=1
> +
> +PKG_LICENSE:=GPLv2
> +PKG_LICENSE_FILES:=
> +
> +PKG_SOURCE_URL:=https://github.com/greearb/ath-ct.git
> +PKG_SOURCE_PROTO:=git
> +PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
> +PKG_SOURCE_VERSION:=b003b75d885595fbc18f4fd9b3aef9189a63f21e
> +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.xz
> +
> +PKG_MAINTAINER:=Ben Greear <greearb at candelatech.com>
> +PKG_BUILD_PARALLEL:=1
> +
> +STAMP_CONFIGURED_DEPENDS := $(STAGING_DIR)/usr/include/mac80211-backport/backport/autoconf.h
> +
> +include $(INCLUDE_DIR)/kernel.mk
> +include $(INCLUDE_DIR)/package.mk
> +
> +define KernelPackage/ath-ct
> +  SUBMENU:=Wireless Drivers
> +  TITLE:=ath10k-ct driver optimized for CT ath10k firmware
> +  DEPENDS:=+kmod-mac80211 +kmod-ath + at DRIVER_11N_SUPPORT @PCI_SUPPORT
> +  FILES:=\
> +	$(PKG_BUILD_DIR)/ath.ko \
> +	$(PKG_BUILD_DIR)/ath9k/ath9k_hw.ko \
> +	$(PKG_BUILD_DIR)/ath9k/ath9k_common.ko \
> +	$(PKG_BUILD_DIR)/ath9k/ath9k_htc.ko \
> +	$(PKG_BUILD_DIR)/ath9k/ath9k_hw.ko \
> +	$(PKG_BUILD_DIR)/ath9k/ath9k.ko \
> +	$(PKG_BUILD_DIR)/ath10k/ath10k_pci.ko \
> +	$(PKG_BUILD_DIR)/ath10k/ath10k_core.ko
> +  AUTOLOAD:=$(call AutoLoad,50,mac80211 ath ath10k_core ath10k_pci)
> +endef
> +
> +NOSTDINC_FLAGS = \
> +	-I$(PKG_BUILD_DIR) \
> +	-I$(STAGING_DIR)/usr/include/mac80211-backport/uapi \
> +	-I$(STAGING_DIR)/usr/include/mac80211-backport \
> +	-I$(STAGING_DIR)/usr/include/mac80211/uapi \
> +	-I$(STAGING_DIR)/usr/include/mac80211 \
> +	-include backport/autoconf.h \
> +	-include backport/backport.h
> +
> +ifdef CONFIG_PACKAGE_MAC80211_MESH
> +  NOSTDINC_FLAGS += -DCONFIG_MAC80211_MESH
> +endif
> +
> +NOSTDINC_FLAGS += -DCONFIG_ATH10K_DEBUGFS -DCONFIG_MAC80211_DEBUGFS -DCONFIG_ATH10K_DEBUG -DCONFIG_ATH10K_AHB
> +NOSTDINC_FLAGS += -DCONFIG_ATH9K_PCI -DCONFIG_ATH9K_DEBUGFS -DCONFIG_ATH9K_DFS_DEBUGFS -DCONFIG_ATH9K_CHANNEL_CONTEXT
> +NOSTDINC_FLAGS += -DCONFIG_ATH9K_HTC_DEBUGFS -DCONFIG_ATH_DEBUG -DCONFIG_ATH9K_BTCOEX_SUPPORT
> +NOSTDINC_FLAGS += -DCONFIG_ATH9K_RFKILL -DCONFIG_ATH9K_DYNACK -DCONFIG_ATH9K_HWRNG
> +NOSTDINC_FLAGS += -DSTANDALONE_CT
> +
> +define Build/Compile
> +	+CONFIG_ATH_COMMON=m CONFIG_ATH_DEBUG=y \
> +	 CONFIG_ATH9K=m CONFIG_ATH9K_HW=m CONFIG_ATH9K_COMMON=m CONFIG_ATH9K_PCI=y \
> +         CONFIG_ATH9K_HTC=m CONFIG_ATH9K_HTC_DEBUGFS=y CONFIG_ATH9K_RFKILL=y CONFIG_ATH9K_DYNACK=y \
> +         CONFIG_ATH9K_DEBUGFS=y CONFIG_ATH9K_DFS_DEBUGFS=y CONFIG_ATH9K_BTCOEX_SUPPORT=y CONFIG_ATH9K_STATION_STATISTICS=m \
> +         CONFIG_ATH9K_CHANNEL_CONTEXT=y CONFIG_ATH9K_HWRNG=y \
> +         CONFIG_ATH10K=m CONFIG_ATH10K_DEBUGFS=y CONFIG_MAC80211_DEBUGFS=y CONFIG_ATH10K_PCI=m CONFIG_ATH10K_AHB=y \
> +         $(MAKE) $(PKG_JOBS) -C "$(LINUX_DIR)" \
> +		ARCH="$(LINUX_KARCH)" \
> +		CROSS_COMPILE="$(TARGET_CROSS)" \
> +		SUBDIRS="$(PKG_BUILD_DIR)" \
> +		NOSTDINC_FLAGS="$(NOSTDINC_FLAGS)" \
> +		modules
> +endef
> +
> +$(eval $(call KernelPackage,ath-ct))
>


From david at lang.hm  Tue Jun 21 15:15:39 2016
From: david at lang.hm (David Lang)
Date: Tue, 21 Jun 2016 15:15:39 -0700 (PDT)
Subject: [LEDE-DEV] [PATCH] Support Candela-Tech ath10k and ath9k
 out-of-tree driver.
In-Reply-To: <5769BBD6.5050907@candelatech.com>
References: <1466546417-19907-1-git-send-email-greearb@candelatech.com>
 <alpine.DEB.2.02.1606211502590.10809@nftneq.ynat.uz>
 <5769BBD6.5050907@candelatech.com>
Message-ID: <alpine.DEB.2.02.1606211514240.10809@nftneq.ynat.uz>

On Tue, 21 Jun 2016, Ben Greear wrote:

> On 06/21/2016 03:04 PM, David Lang wrote:
>> I'll point out that there is a lot of work being done on these drivers 
>> right now in terms of making significant changes to how they do buffering 
>> that in
>> increasing network speed as well as reducing latency
>> 
>> search the follwoing lists for [make-wifi-fast] to see the details and 
>> benchmarks
>> make-wifi-fast at lists.bufferbloat.net, 
>> ath9k-devel at venema.h4ckr.net,linux-wireless at vger.kernel.org
>
> Yes, and I will pull that stuff into my tree as it becomes stable and/or as I 
> have time.
>
> It seems I have little chance to ever get my ath10k patches in the upsteam 
> kernel, so this is the
> best I can think of for now.
>
> It might be best to entirely decouple my ath10k from ath9k so folks can use 
> stock (LEDE) ath9k
> but my ath10k.  Maybe I simply had some typo in my first attempt at this.
>
> I figure Felix will know better how to make this all work, so this patch 
> should probably
> wait for him to comment on and/or fix.

One more thing that I didn't really see in the patch (but I may have skimmed 
over it)

What is the difference/improvement between the stock driver and the Candela-Tech 
driver? (i.e. as someone configuring LEDE, why would I pick your driver?)

David Lang


From greearb at candelatech.com  Tue Jun 21 15:12:38 2016
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 21 Jun 2016 15:12:38 -0700
Subject: [LEDE-DEV] [PATCH] Support Candela-Tech ath10k and ath9k
 out-of-tree driver.
In-Reply-To: <alpine.DEB.2.02.1606211502590.10809@nftneq.ynat.uz>
References: <1466546417-19907-1-git-send-email-greearb@candelatech.com>
 <alpine.DEB.2.02.1606211502590.10809@nftneq.ynat.uz>
Message-ID: <5769BBD6.5050907@candelatech.com>

On 06/21/2016 03:04 PM, David Lang wrote:
> I'll point out that there is a lot of work being done on these drivers right now in terms of making significant changes to how they do buffering that in
> increasing network speed as well as reducing latency
>
> search the follwoing lists for [make-wifi-fast] to see the details and benchmarks
> make-wifi-fast at lists.bufferbloat.net, ath9k-devel at venema.h4ckr.net,linux-wireless at vger.kernel.org

Yes, and I will pull that stuff into my tree as it becomes stable and/or as I have time.

It seems I have little chance to ever get my ath10k patches in the upsteam kernel, so this is the
best I can think of for now.

It might be best to entirely decouple my ath10k from ath9k so folks can use stock (LEDE) ath9k
but my ath10k.  Maybe I simply had some typo in my first attempt at this.

I figure Felix will know better how to make this all work, so this patch should probably
wait for him to comment on and/or fix.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From greearb at candelatech.com  Tue Jun 21 15:45:26 2016
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 21 Jun 2016 15:45:26 -0700
Subject: [LEDE-DEV] apu2 + Candela firmware/driver LEDE tree is available.
Message-ID: <5769C386.3080607@candelatech.com>

In case someone wants to try out my patches by just cloning a tree:

https://github.com/greearb/lede-source-ct

The README has some notes on how to easily build for the 'apu2' platform,
and normal build infrastructure is supported as well.

I am likely to rebase this often as I have time to sync with upstream.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From greearb at candelatech.com  Tue Jun 21 15:51:35 2016
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 21 Jun 2016 15:51:35 -0700
Subject: [LEDE-DEV] apu2 + Candela firmware/driver LEDE tree is
	available.
In-Reply-To: <5769C386.3080607@candelatech.com>
References: <5769C386.3080607@candelatech.com>
Message-ID: <5769C4F7.8050906@candelatech.com>

On 06/21/2016 03:45 PM, Ben Greear wrote:
> In case someone wants to try out my patches by just cloning a tree:
>
> https://github.com/greearb/lede-source-ct
>
> The README has some notes on how to easily build for the 'apu2' platform,
> and normal build infrastructure is supported as well.
>
> I am likely to rebase this often as I have time to sync with upstream.

Oh, and if someone happens to like the buildme.sh logic, I'll be happy to accept
patches for other targets and/or general improvements to the buildme.sh script or other
features only in this particular fork of the lede tree.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From greearb at candelatech.com  Tue Jun 21 15:29:01 2016
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 21 Jun 2016 15:29:01 -0700
Subject: [LEDE-DEV] [PATCH] Support Candela-Tech ath10k and ath9k
 out-of-tree driver.
In-Reply-To: <alpine.DEB.2.02.1606211514240.10809@nftneq.ynat.uz>
References: <1466546417-19907-1-git-send-email-greearb@candelatech.com>
 <alpine.DEB.2.02.1606211502590.10809@nftneq.ynat.uz>
 <5769BBD6.5050907@candelatech.com>
 <alpine.DEB.2.02.1606211514240.10809@nftneq.ynat.uz>
Message-ID: <5769BFAD.9070103@candelatech.com>

On 06/21/2016 03:15 PM, David Lang wrote:
> On Tue, 21 Jun 2016, Ben Greear wrote:
>
>> On 06/21/2016 03:04 PM, David Lang wrote:
>>> I'll point out that there is a lot of work being done on these drivers right now in terms of making significant changes to how they do buffering that in
>>> increasing network speed as well as reducing latency
>>>
>>> search the follwoing lists for [make-wifi-fast] to see the details and benchmarks
>>> make-wifi-fast at lists.bufferbloat.net, ath9k-devel at venema.h4ckr.net,linux-wireless at vger.kernel.org
>>
>> Yes, and I will pull that stuff into my tree as it becomes stable and/or as I have time.
>>
>> It seems I have little chance to ever get my ath10k patches in the upsteam kernel, so this is the
>> best I can think of for now.
>>
>> It might be best to entirely decouple my ath10k from ath9k so folks can use stock (LEDE) ath9k
>> but my ath10k.  Maybe I simply had some typo in my first attempt at this.
>>
>> I figure Felix will know better how to make this all work, so this patch should probably
>> wait for him to comment on and/or fix.
>
> One more thing that I didn't really see in the patch (but I may have skimmed over it)
>
> What is the difference/improvement between the stock driver and the Candela-Tech driver? (i.e. as someone configuring LEDE, why would I pick your driver?)
>
> David Lang
>

The main reason is that it better supports CT ath10k firmware:

http://www.candelatech.com/ath10k-10.1.php
http://www.candelatech.com/ath10k-10.4.php

See the features list down this page a bit.  It is at least mostly up to date.
If you are not using my firmware, then I am not sure my driver will give
you much benefit over stock.

Firmware (10.1) release notes here:

http://www.candelatech.com/downloads/ath10k-fw-beta/release_notes.txt

One of the nice features for me is that I can get much better 'core' dumps out of
my firmware when using this driver, so I expect I can debug firmware crashes
more thoroughly.

For folks on this list, the IBSS support and capturing more frames in monitor
mode might be a key benefit.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From thomas at inet.tu-berlin.de  Wed Jun 22 00:47:22 2016
From: thomas at inet.tu-berlin.de (=?utf-8?Q?Thomas_H=C3=BChn?=)
Date: Wed, 22 Jun 2016 09:47:22 +0200
Subject: [LEDE-DEV] calib table can damage some cpe510's
In-Reply-To: <20160616224955.5176ccf7@lazus.yip>
References: <20160616224955.5176ccf7@lazus.yip>
Message-ID: <B6261A86-7AF7-4AD0-8393-8774455F721B@inet.tu-berlin.de>

HI,

Could you explain a bit your experimental setup and observation that lead you to the conclusion the high power calibration is causing the device a damage ?
I do have 8x CPE510 in our mesh up & running with the high power calibration table with astonishing radio performance and without any problem. So if the version
number could be used to differentiate the effected devices, we might be using it. And while I was looking together with Felix for this calibration table adress on the CPE510 under the original firmware, we might just look at such a different version of the CPE510 as well.
Second question, for the CPE210, is there also a high power calibration table like ?KSEG1ADDR(0x1fff5000)? usable ?

Greetings THomas



> On 17 Jun 2016, at 07:49, Alexander Couzens <lynxis at fe80.eu> wrote:
> 
> Hi,
> 
> it turned out the second calibration table (high power) could
> damage some devices within the rf part. Even it was tested on hardware,
> I guess it depends on the hardware revision *and* the used frequency.
> 
> It means that we have to use the gravelly bumpy way to fix the txgain
> and patching the tx gain table for this particular device.
> 
> The calibration table patch bf27ac019c137e7baf90ca6ef0e40945ae871797
> got reverted.
> 
> Best,
> lynxis
> -- 
> Alexander Couzens
> 
> mail: lynxis at fe80.eu
> jabber: lynxis at fe80.eu
> mobile: +4915123277221
> gpg: 390D CF78 8BF9 AA50 4F8F  F1E2 C29E 9DA6 A0DF 8604
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev



From john at phrozen.org  Wed Jun 22 00:50:20 2016
From: john at phrozen.org (John Crispin)
Date: Wed, 22 Jun 2016 09:50:20 +0200
Subject: [LEDE-DEV] [PATCH v4] base-files: seed /dev/urandom
In-Reply-To: <1466069891-28577-1-git-send-email-champetier.etienne@gmail.com>
References: <1466069891-28577-1-git-send-email-champetier.etienne@gmail.com>
Message-ID: <589dc209-ddff-904a-2899-75eee367b7fb@phrozen.org>



On 16/06/2016 11:38, Etienne CHAMPETIER wrote:
> This commit:
> 1) seed /dev/urandom with a saved seed as early as possible
>    (see /lib/preinit/81_urandom_seed)
> 2) save a new seed if system. at system[0].write_urandom_seed_on_boot == 1
>    or if none exists. We use getrandom() so we are sure /dev/urandom
>    pool is initialized (see /etc/init.d/urandom_seed)
> 
> seed size is 512 bytes (ie /proc/sys/kernel/random/poolsize / 8)
> it's the same size as in ubuntu 14.04 and all systemd systems
> 
> seed file is /etc/urandom.seed (need a writable path)
> 
> seeding /dev/urandom doesn't change entropy estimation, so we still have
> "random: ubus urandom read with 4 bits of entropy available"
> messages in the logs, but we can now ignore them if
> after "urandom-seed: Seeding with ..." message
> 
> for now saving a new seed is disabled by default as Felix and John
> are concerned we might write too much and destroy the flash
> 
> v2: log preinit messages to /dev/kmsg
> v3: use non generic function name for logging, as /lib/preinit/ files
>     are all sourced together in /etc/preinit
> v4: after a lot of discussion on the ML, use a config param
> 
> Signed-off-by: Etienne CHAMPETIER <champetier.etienne at gmail.com>
> ---
>  package/base-files/files/bin/config_generate       |  1 +
>  package/base-files/files/etc/init.d/urandom_seed   | 28 ++++++++++++++++++++++
>  .../base-files/files/lib/preinit/81_urandom_seed   | 19 +++++++++++++++
>  3 files changed, 48 insertions(+)
>  create mode 100755 package/base-files/files/etc/init.d/urandom_seed
>  create mode 100644 package/base-files/files/lib/preinit/81_urandom_seed
> 
> diff --git a/package/base-files/files/bin/config_generate b/package/base-files/files/bin/config_generate
> index 8002bc4..9bccead 100755
> --- a/package/base-files/files/bin/config_generate
> +++ b/package/base-files/files/bin/config_generate
> @@ -230,6 +230,7 @@ generate_static_system() {
>  		set system. at system[-1].timezone='UTC'
>  		set system. at system[-1].ttylogin='0'
>  		set system. at system[-1].log_size='64'
> +		set system. at system[-1].write_urandom_seed_on_boot='0'
>  
>  		delete system.ntp
>  		set system.ntp='timeserver'
> diff --git a/package/base-files/files/etc/init.d/urandom_seed b/package/base-files/files/etc/init.d/urandom_seed
> new file mode 100755
> index 0000000..f950685
> --- /dev/null
> +++ b/package/base-files/files/etc/init.d/urandom_seed
> @@ -0,0 +1,28 @@
> +#!/bin/sh /etc/rc.common
> +
> +START=99
> +
> +EXTRA_COMMANDS="save"
> +
> +SEED=/etc/urandom.seed
> +
> +error_exit() {
> +    logger -t urandom_seed "$1"
> +    exit 1
> +}
> +
> +save() {
> +    touch $SEED.tmp || error_exit "touch failed"
> +    chown root:root $SEED.tmp || error_exit "chown failed"
> +    chmod 600 $SEED.tmp || error_exit "chmod failed"
> +    getrandom 512 > $SEED.tmp || error_exit "getrandom failed"
> +    mv $SEED.tmp $SEED || error_exit "mv failed"
> +}
> +
> +boot() {
> +    [ -f $SEED ] || {
> +        save
> +        exit 0
> +    }
> +    [ "$(uci get system. at system[0].write_urandom_seed_on_boot)" == "1" ] && save
> +}

write_urandom_seed_on_boot was a placeholder for what the option should
be named as i could not think of a good one ;) please try to find a
shorter one

	John



> diff --git a/package/base-files/files/lib/preinit/81_urandom_seed b/package/base-files/files/lib/preinit/81_urandom_seed
> new file mode 100644
> index 0000000..a1457aa
> --- /dev/null
> +++ b/package/base-files/files/lib/preinit/81_urandom_seed
> @@ -0,0 +1,19 @@
> +#!/bin/sh
> +
> +log_urandom_seed() {
> +    echo "urandom-seed: $1" > /dev/kmsg
> +}
> +
> +do_urandom_seed() {
> +    S=/etc/urandom.seed
> +    U=/dev/urandom
> +
> +    [ -c $U ] || { log_urandom_seed "Something is wrong with $U"; return; }
> +    [ -f $S ] || { log_urandom_seed "Seed file not found ($S)"; return; }
> +    [ -O $S -a -G $S -a ! -x $S ] || { log_urandom_seed "Wrong owner / permissions for $S"; return; }
> +
> +    log_urandom_seed "Seeding with $S"
> +    cat $S > $U
> +}
> +
> +boot_hook_add preinit_main do_urandom_seed
> 


From olivier.hardouin at gmail.com  Wed Jun 22 00:51:19 2016
From: olivier.hardouin at gmail.com (olivier.hardouin at gmail.com)
Date: Wed, 22 Jun 2016 09:51:19 +0200
Subject: [LEDE-DEV] [PATCH mountd 2/2] support for disk without partition
	table
In-Reply-To: <1466581879-9862-1-git-send-email-olivier.hardouin@gmail.com>
References: <1466581879-9862-1-git-send-email-olivier.hardouin@gmail.com>
Message-ID: <1466581879-9862-2-git-send-email-olivier.hardouin@gmail.com>

if no partition found, try to mount the block device itself

Signed-off-by: Olivier Hardouin <olivier.hardouin at gmail.com>
---
 mount.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/mount.c b/mount.c
index 0c2862a..7cbb8ff 100644
--- a/mount.c
+++ b/mount.c
@@ -693,13 +693,19 @@ static void mount_enum_drives(void)
 				char tmp[64];
 				snprintf(tmp, 64, "/sys/block/%s/", namelist[n]->d_name);
 				m = scandir(tmp, &namelist2, dir_filter2, dir_sort);
-				while(m--)
+				if(m > 0)
 				{
-					strncpy(&block[blk_cnt][0], namelist2[m]->d_name, MAX_BLOCK);
+					while(m--)
+					{
+						strncpy(&block[blk_cnt][0], namelist2[m]->d_name, MAX_BLOCK);
+						blk_cnt++;
+						free(namelist2[m]);
+					}
+					free(namelist2);
+				} else {
+					strncpy(&block[blk_cnt][0], namelist[n]->d_name, MAX_BLOCK);
 					blk_cnt++;
-					free(namelist2[m]);
 				}
-				free(namelist2);
 			}
 			free(namelist[n]);
 		}
-- 
1.9.1



From olivier.hardouin at gmail.com  Wed Jun 22 00:51:18 2016
From: olivier.hardouin at gmail.com (olivier.hardouin at gmail.com)
Date: Wed, 22 Jun 2016 09:51:18 +0200
Subject: [LEDE-DEV] [PATCH mountd 1/2] hfs+ journal partition support as
	read only
Message-ID: <1466581879-9862-1-git-send-email-olivier.hardouin@gmail.com>

use hfsplus driver to mount hfs+ partition marked as journalled,
read only mounting since partial support from the kernel for write 
access (as stated in Documentatiom/filesystems/hfsplus.txt)
add new index 'LASTFS' to be used in case of support for another
driver

Signed-off-by: Olivier Hardouin <olivier.hardouin at gmail.com>
---
 fs.c         |  4 ++--
 include/fs.h | 25 ++++++++++++++-----------
 mount.c      | 16 +++++++++++-----
 3 files changed, 27 insertions(+), 18 deletions(-)

diff --git a/fs.c b/fs.c
index fee6608..ca77a76 100644
--- a/fs.c
+++ b/fs.c
@@ -153,8 +153,8 @@ static int detect_hfsplus(int fd)
 	{
 		if(!journal)
 			ret = HFSPLUS;
-	//	else
-	//		ret = HFSPLUSJOURNAL;
+		else
+			ret = HFSPLUSJOURNAL;
 	}
 out:
 	free(buffer);
diff --git a/include/fs.h b/include/fs.h
index 1c66db3..b86f383 100644
--- a/include/fs.h
+++ b/include/fs.h
@@ -1,13 +1,16 @@
-#define NONE		-1
-#define MBR			2
-#define EXT2		3
-#define EXT3		4
-#define FAT			5
-#define HFSPLUS		6
-#define EFI			7
-#define NTFS		8
-#define EXTENDED	9
-#define EXFAT		10
-#define EXT4		11
+#define NONE			-1
+#define MBR				2
+#define EXT2			3
+#define EXT3			4
+#define FAT				5
+#define HFSPLUS			6
+#define EFI				7
+#define NTFS			8
+#define EXTENDED		9
+#define EXFAT			10
+#define EXT4			11
+#define HFSPLUSJOURNAL	12
+
+#define LASTFS			HFSPLUSJOURNAL
 
 int detect_fs(char *device);
diff --git a/mount.c b/mount.c
index 219146b..0c2862a 100644
--- a/mount.c
+++ b/mount.c
@@ -60,7 +60,8 @@ char *fs_names[] = {
 	"ntfs",
 	"",
 	"exfat",
-	"ext4"
+	"ext4",
+	"hfsplusjournal"
 };
 
 #define MAX_MOUNTED		32
@@ -100,7 +101,7 @@ static void mount_dump_uci_state(void)
 		ucix_add_option(ctx, mountd, q->serial, "rev", q->rev);
 		snprintf(t, 64, "size%d", atoi(&q->dev[3]));
 		ucix_add_option(ctx, mountd, q->serial, t, q->size);
-		if(q->fs > MBR && q->fs <= EXT4)
+		if(q->fs > MBR && q->fs <= LASTFS)
 		{
 			snprintf(t, 64, "fs%d", atoi(&q->dev[3]));
 			ucix_add_option(ctx, mountd, q->serial, t, fs_names[q->fs]);
@@ -138,7 +139,7 @@ static void mount_add_list(char *name, char *dev, char *serial,
 {
 	struct mount *mount;
 	char tmp[64], tmp2[64];
-	if(fs <= MBR || fs > EXT4)
+	if(fs <= MBR || fs > LASTFS)
 		return;
 	mount  = malloc(sizeof(struct mount));
 	INIT_LIST_HEAD(&mount->list);
@@ -154,7 +155,7 @@ static void mount_add_list(char *name, char *dev, char *serial,
 	mount->mounted = 0;
 	mount->fs = fs;
 	list_add(&mount->list, &mounts);
-	if((!mount->ignore) && (mount->fs > MBR) && (mount->fs <= EXT4))
+	if((!mount->ignore) && (mount->fs > MBR) && (mount->fs <= LASTFS))
 	{
 		log_printf("new mount : %s -> %s (%s)\n", name, dev, fs_names[mount->fs]);
 		snprintf(tmp, 64, "%s%s", uci_path, name);
@@ -260,12 +261,17 @@ int mount_new(char *path, char *dev)
 			options = "rw,defaults,uid=1000,gid=1000";
 			fstype = "hfsplus";
 		}
+		if(mount->fs == HFSPLUSJOURNAL)
+		{
+			options = "ro,defaults,uid=1000,gid=1000";
+			fstype = "hfsplus";
+		}
 		if(mount->fs == NTFS)
 		{
 			options = "force";
 			fstype = "ntfs-3g";
 		}
-		if(mount->fs > MBR && mount->fs <= EXT4)
+		if(mount->fs > MBR && mount->fs <= LASTFS)
 		{
 			struct uci_context *ctx;
 			char *uci_options, *uci_fstype;
-- 
1.9.1



From john at phrozen.org  Wed Jun 22 00:57:12 2016
From: john at phrozen.org (John Crispin)
Date: Wed, 22 Jun 2016 09:57:12 +0200
Subject: [LEDE-DEV] new bugs mailing list
Message-ID: <4e8e45f2-744a-0404-b508-d621f77d6c7c@phrozen.org>

Hi,

the issue tracker now announces bug reports on this list

https://lists.infradead.org/mailman/listinfo/lede-bugs

there will be a lede-commits list shortly

	John


From ardeleanalex at gmail.com  Wed Jun 22 01:10:46 2016
From: ardeleanalex at gmail.com (Alexandru Ardelean)
Date: Wed, 22 Jun 2016 11:10:46 +0300
Subject: [LEDE-DEV] [UBUS] [PATCH] Issue of msgbuf_data_len in
	ubus_context
In-Reply-To: <CANQnsBowyqcGbygwLUfQJGffDg-kZ-uhQR=Qrur1KC6xQb92kA@mail.gmail.com>
References: <CANQnsBpZvnwyon4zuKQ_FQdUC7cWCvp58S+8f-SQHNH1idUTog@mail.gmail.com>
 <CANQnsBowyqcGbygwLUfQJGffDg-kZ-uhQR=Qrur1KC6xQb92kA@mail.gmail.com>
Message-ID: <CA+U=DsqWc0o+iipbWsTv+v_UN5F21Xz-r6xO7C123L4TuOfW5g@mail.gmail.com>

On Sun, Jun 19, 2016 at 7:21 AM, Wang Linetkux <chinawrj at gmail.com> wrote:
> Sorry, forgot to paste the patch in the email for easy reading.
>
> ---
>
>  libubus-io.c | 1 +
>
>  1 file changed, 1 insertion(+)
>
>
>
> diff --git a/libubus-io.c b/libubus-io.c
>
> index 9320bf3..0582ff7 100644
>
> --- a/libubus-io.c
>
> +++ b/libubus-io.c
>
> @@ -259,6 +259,7 @@ static bool alloc_msg_buf(struct ubus_context
> *ctx, int len)
>
>                 return false;
>
>
>
>         ctx->msgbuf.data = ptr;
>
> +       ctx->msgbuf_data_len = len;
>
>         return true;
>
>  }
>
>
>
>
>
>
>
> 2016-06-19 12:16 GMT+08:00 Wang Linetkux <chinawrj at gmail.com>:
>> Hi, Guys
>>   Since I cannot find other places to send this patch, so I send it
>> here, and hope it does not bother you.
>>   "alloc_msg_buf" function in "ubus/libubus-io.c" has the feature that
>> expand or shrink msg buffer when necessary. But I have noticed that
>> "msgbuf_data_len" has been properly set after msg buffer is expanded,
>> and it still stays with its origin value. I have generated one patch
>> for this bug. Feel free to talk with me, just in case I am wrong.
>>
>> ubus repo on lede:
>> https://git.lede-project.org/?p=project/ubus.git;a=summary
>>
>>
>> Rujun
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

@Felix or @John: can you please check this patch ?
Wang has a point here.
"ctx->msgbuf_data_len" is not adjusted after init, and should be, in
case of realloc.

I don't think this causes a leak.
It just makes the buffer size reduction logic useless.
So, if the max ubus msg is 1 MB, then the buffer size will remain 1 MB
until reboot/restart of the process.

@Wang: the way to send patches is via the git send-email command.
so in this case:
    git send-email --to=lede-dev at lists.infraread.org
0001-Fix-the-length-of-msg-buffer-after-realloc.patch

Thanks
Alex


From kevin at darbyshire-bryant.me.uk  Wed Jun 22 01:12:38 2016
From: kevin at darbyshire-bryant.me.uk (Kevin Darbyshire-Bryant)
Date: Wed, 22 Jun 2016 09:12:38 +0100
Subject: [LEDE-DEV] [PATCH v4] base-files: seed /dev/urandom
In-Reply-To: <589dc209-ddff-904a-2899-75eee367b7fb@phrozen.org>
References: <1466069891-28577-1-git-send-email-champetier.etienne@gmail.com>
 <589dc209-ddff-904a-2899-75eee367b7fb@phrozen.org>
Message-ID: <576A4876.4010205@darbyshire-bryant.me.uk>



On 22/06/16 08:50, John Crispin wrote:
>
<snip>
> write_urandom_seed_on_boot was a placeholder for what the option should
> be named as i could not think of a good one ;) please try to find a
> shorter one
>
> 	John
May I offer "preserveurandomseed" or 'saveurandom' as some 'random' 
ideas :-)

Kevin



From dat_le at compex.com.sg  Wed Jun 22 02:31:55 2016
From: dat_le at compex.com.sg (Dat Le)
Date: Wed, 22 Jun 2016 17:31:55 +0800
Subject: [LEDE-DEV] ar71xx - please help test
In-Reply-To: <bfd64b04-7942-19a8-0eda-911840448cb7@phrozen.org>
References: <bfd64b04-7942-19a8-0eda-911840448cb7@phrozen.org>
Message-ID: <b03dd176-e96b-bac6-b6b2-a52725a576d8@compex.com.sg>

Hi,

Compex boards WPJ342 WPJ344 WPJ531 and WPJ588 all are OK

Thanks,
Dat

On 6/21/2016 4:23 PM, John Crispin wrote:
> Hi,
>
> i have moved all the profiles into the image building code. i have done
> some basic testing and already got a bit of feedback from others.
>
> it would be nice if people could help test the following patch from my
> staging tree
>
> https://git.lede-project.org/?p=lede/blogic/staging.git;a=commit;h=75773d43cd44ee70e293343fad11db654c35a4ed
>
> 	John
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev



From jonas.gorski at gmail.com  Wed Jun 22 04:39:04 2016
From: jonas.gorski at gmail.com (Jonas Gorski)
Date: Wed, 22 Jun 2016 13:39:04 +0200
Subject: [LEDE-DEV] new bugs mailing list
In-Reply-To: <4e8e45f2-744a-0404-b508-d621f77d6c7c@phrozen.org>
References: <4e8e45f2-744a-0404-b508-d621f77d6c7c@phrozen.org>
Message-ID: <CAOiHx=k0sHM708GeqdV=mPGYGN5+M=4fQXiCZ7C2n2RNUQtOzQ@mail.gmail.com>

Hi,

On 22 June 2016 at 09:57, John Crispin <john at phrozen.org> wrote:
> Hi,
>
> the issue tracker now announces bug reports on this list
>
> https://lists.infradead.org/mailman/listinfo/lede-bugs

Yay! Thanks a lot.

I wonder if we could change the subject to just "[#<num>] <Title>",
that way gmail and other crappy email clients that ignore
references/in-reply-to headers can group all events from ticket in one
"discussion".

Another bikeshedding would be the currently very verbose text, but
that's a minor issue.

E.g.
"The following task has a new comment added:

FS#9 - Kernel panic with SQM scripts
User who did this - Ansuel (Ansuel)"

Could be easily written as "Ansuel (Ansuel) added a new comment:" (and
the "Task" is already in the subject, so no need repeat that).

No idea if its easy to change though on both.

> there will be a lede-commits list shortly

Yay again!

Regards
Jonas


From john at phrozen.org  Wed Jun 22 04:40:47 2016
From: john at phrozen.org (John Crispin)
Date: Wed, 22 Jun 2016 13:40:47 +0200
Subject: [LEDE-DEV] new bugs mailing list
In-Reply-To: <CAOiHx=k0sHM708GeqdV=mPGYGN5+M=4fQXiCZ7C2n2RNUQtOzQ@mail.gmail.com>
References: <4e8e45f2-744a-0404-b508-d621f77d6c7c@phrozen.org>
 <CAOiHx=k0sHM708GeqdV=mPGYGN5+M=4fQXiCZ7C2n2RNUQtOzQ@mail.gmail.com>
Message-ID: <0a96edac-1675-3be8-f8b0-060a64fc1a0b@phrozen.org>



On 22/06/2016 13:39, Jonas Gorski wrote:
> Hi,
> 
> On 22 June 2016 at 09:57, John Crispin <john at phrozen.org> wrote:
>> Hi,
>>
>> the issue tracker now announces bug reports on this list
>>
>> https://lists.infradead.org/mailman/listinfo/lede-bugs
> 
> Yay! Thanks a lot.
> 
> I wonder if we could change the subject to just "[#<num>] <Title>",
> that way gmail and other crappy email clients that ignore
> references/in-reply-to headers can group all events from ticket in one
> "discussion".
> 
> Another bikeshedding would be the currently very verbose text, but
> that's a minor issue.
> 
> E.g.
> "The following task has a new comment added:
> 
> FS#9 - Kernel panic with SQM scripts
> User who did this - Ansuel (Ansuel)"
> 
> Could be easily written as "Ansuel (Ansuel) added a new comment:" (and
> the "Task" is already in the subject, so no need repeat that).
> 
> No idea if its easy to change though on both.
> 
>> there will be a lede-commits list shortly
> 
> Yay again!
> 
> Regards
> Jonas
> 

Hi Jonas,

makes sense, can you add a feature request for this please ?

	John


From Alexey.Brodkin at synopsys.com  Wed Jun 22 05:47:20 2016
From: Alexey.Brodkin at synopsys.com (Alexey Brodkin)
Date: Wed, 22 Jun 2016 15:47:20 +0300
Subject: [LEDE-DEV] [PATCH] linux: arc: disable kernel unwinding to fix
	modules loading
Message-ID: <1466599640-24633-1-git-send-email-abrodkin@synopsys.com>

With update of binutils for ARC (this is now based on upstream 2.26)
we noticed issues with loadable kernel modules.

Something like that was happening:
--------------------->8-------------------
mbcache: unknown relocation: 49
insmod: can't insert './mbcache.ko': invalid module format
--------------------->8-------------------

More details could be found in that discussion in binutils mailing list:
http://thread.gmane.org/gmane.comp.gnu.binutils/74662

As of now the simplest work-around is to disable in-kernel unwinder
for now. That will at least allow us to use modules again.

Signed-off-by: Alexey Brodkin <abrodkin at synopsys.com>
Cc: Vineet Gupta <vgupta at synopsys.com>
Cc: John Crispin <john at phrozen.org>
---
 target/linux/arc770/config-4.4  | 3 +--
 target/linux/archs38/config-4.4 | 4 +---
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/target/linux/arc770/config-4.4 b/target/linux/arc770/config-4.4
index 87fd7e3..d6905d7 100644
--- a/target/linux/arc770/config-4.4
+++ b/target/linux/arc770/config-4.4
@@ -18,7 +18,7 @@ CONFIG_ARC_CURR_IN_REG=y
 CONFIG_ARC_DBG=y
 # CONFIG_ARC_DBG_TLB_MISS_COUNT is not set
 # CONFIG_ARC_DBG_TLB_PARANOIA is not set
-CONFIG_ARC_DW2_UNWIND=y
+# CONFIG_ARC_DW2_UNWIND is not set
 CONFIG_ARC_EMUL_UNALIGNED=y
 # CONFIG_ARC_FPU_SAVE_RESTORE is not set
 CONFIG_ARC_HAS_DCACHE=y
@@ -78,7 +78,6 @@ CONFIG_HAVE_FUTEX_CMPXCHG=y
 CONFIG_HAVE_IOREMAP_PROT=y
 CONFIG_HAVE_LATENCYTOP_SUPPORT=y
 CONFIG_HAVE_MEMBLOCK=y
-CONFIG_HAVE_MOD_ARCH_SPECIFIC=y
 CONFIG_HAVE_NET_DSA=y
 CONFIG_HAVE_OPROFILE=y
 CONFIG_HAVE_PERF_EVENTS=y
diff --git a/target/linux/archs38/config-4.4 b/target/linux/archs38/config-4.4
index 9ea33c6..c7dc264 100644
--- a/target/linux/archs38/config-4.4
+++ b/target/linux/archs38/config-4.4
@@ -15,7 +15,7 @@ CONFIG_ARC_CURR_IN_REG=y
 CONFIG_ARC_DBG=y
 # CONFIG_ARC_DBG_TLB_MISS_COUNT is not set
 # CONFIG_ARC_DBG_TLB_PARANOIA is not set
-CONFIG_ARC_DW2_UNWIND=y
+# CONFIG_ARC_DW2_UNWIND is not set
 CONFIG_ARC_HAS_COH_CACHES=y
 CONFIG_ARC_HAS_DCACHE=y
 # CONFIG_ARC_HAS_DCCM is not set
@@ -85,7 +85,6 @@ CONFIG_HAVE_FUTEX_CMPXCHG=y
 CONFIG_HAVE_IOREMAP_PROT=y
 CONFIG_HAVE_LATENCYTOP_SUPPORT=y
 CONFIG_HAVE_MEMBLOCK=y
-CONFIG_HAVE_MOD_ARCH_SPECIFIC=y
 CONFIG_HAVE_NET_DSA=y
 CONFIG_HAVE_OPROFILE=y
 CONFIG_HAVE_PERF_EVENTS=y
@@ -175,7 +174,6 @@ CONFIG_SRCU=y
 CONFIG_STACKTRACE=y
 CONFIG_STMMAC_ETH=y
 CONFIG_STMMAC_PLATFORM=y
-# CONFIG_SUNXI_SRAM is not set
 CONFIG_TICK_CPU_ACCOUNTING=y
 CONFIG_UNINLINE_SPIN_UNLOCK=y
 CONFIG_USB_SUPPORT=y
-- 
2.5.5



From sven.eckelmann at open-mesh.com  Wed Jun 22 06:54:42 2016
From: sven.eckelmann at open-mesh.com (Sven Eckelmann)
Date: Wed, 22 Jun 2016 15:54:42 +0200
Subject: [LEDE-DEV] [PATCH] ipq806x: Fix typo in Qualcomm device names
Message-ID: <1466603682-28395-1-git-send-email-sven.eckelmann@open-mesh.com>

Signed-off-by: Sven Eckelmann <sven.eckelmann at open-mesh.com>
---
 target/linux/ipq806x/image/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/target/linux/ipq806x/image/Makefile b/target/linux/ipq806x/image/Makefile
index 455ea1e..36f2332 100644
--- a/target/linux/ipq806x/image/Makefile
+++ b/target/linux/ipq806x/image/Makefile
@@ -106,7 +106,7 @@ define Device/AP148
 	BLOCKSIZE := 128KiB
 	PAGESIZE := 2048
 	BOARD_NAME := ap148
-	DEVICE_TITLE := Qualcom AP148
+	DEVICE_TITLE := Qualcomm AP148
 endef
 
 define Device/AP148-legacy
@@ -116,7 +116,7 @@ define Device/AP148-legacy
 	BLOCKSIZE := 128KiB
 	PAGESIZE := 2048
 	BOARD_NAME := ap148
-	DEVICE_TITLE := Qualcom AP148 (legacy)
+	DEVICE_TITLE := Qualcomm AP148 (legacy)
 endef
 
 define Device/C2600
@@ -146,7 +146,7 @@ define Device/DB149
 	DEVICE_DTS := qcom-ipq8064-db149
 	KERNEL_INSTALL := 1
 	BOARD_NAME := db149
-	DEVICE_TITLE := Qualcom DB149
+	DEVICE_TITLE := Qualcomm DB149
 endef
 
 define Device/EA8500


From i at conorogorman.net  Wed Jun 22 09:01:58 2016
From: i at conorogorman.net (Conor O'Gorman)
Date: Wed, 22 Jun 2016 17:01:58 +0100
Subject: [LEDE-DEV] [PATCH] squashfs4: use upstream xz compression
 header format
In-Reply-To: <1466539544-706-1-git-send-email-hauke@hauke-m.de>
References: <1466539544-706-1-git-send-email-hauke@hauke-m.de>
Message-ID: <576AB676.9060900@conorogorman.net>

On 21/06/16 21:05, Hauke Mehrtens wrote:
> In the upstream kernel and the upstream squashfs4 tools the xz
> compression header looks the following:
> struct disk_comp_opts {
>          __le32 dictionary_size;
>          __le32 flags;
> };
>
> We added some other members and also moved some existing members. Place
> the members which are already in upstream header at the same position
> as in that kernel and add our own at the end. The kernel should not
> have a problem when there are some additional members and just ignore
> them.
>
But no endian match? __le32 -> uint32_t


From dave.taht at gmail.com  Wed Jun 22 10:41:45 2016
From: dave.taht at gmail.com (Dave Taht)
Date: Wed, 22 Jun 2016 10:41:45 -0700
Subject: [LEDE-DEV] portal wifi router
Message-ID: <CAA93jw5QOCk3cKWcz1fnWDTAvx22tijMRPodqaBWTsgRVN0p6g@mail.gmail.com>

eero shipped something debian based (using batman-adv to mesh, I believe)
google onhub shipped some sort of hybrid of chromeos (so far as I know)
https://www.plumewifi.com/ is making all sorts of promises, can't tell
what they are using.

A new one just cropped up - portal - where their kickstarter claims
they are using openwrt. Anyone know anything more about it? Not clear
what chipset they are using but since they are based in taiwan I'd
guess it's mediatek, but it could be qualcomm?

https://www.kickstarter.com/projects/portalwifi/portal-turbocharged-wifi?ref=email

http://getportal.io/ has more "details" and early backers should be
seeing routers soon.

They are all claiming massive improvements in wifi performance mostly
based on whatever 802.11ac based technology they are using, I keep
hoping at least some of the above were also paying attention to bql,
fq_codel, per station queuing, etc.

-- 
Dave T?ht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org


From lynxis at fe80.eu  Wed Jun 22 12:37:52 2016
From: lynxis at fe80.eu (Alexander Couzens)
Date: Wed, 22 Jun 2016 12:37:52 -0700
Subject: [LEDE-DEV] calib table can damage some cpe510's
In-Reply-To: <B6261A86-7AF7-4AD0-8393-8774455F721B@inet.tu-berlin.de>
References: <20160616224955.5176ccf7@lazus.yip>
 <B6261A86-7AF7-4AD0-8393-8774455F721B@inet.tu-berlin.de>
Message-ID: <20160622123752.71e1c2ca@lazus.yip>

On Wed, 22 Jun 2016 09:47:22 +0200
Thomas H?hn <thomas at inet.tu-berlin.de> wrote:

> Could you explain a bit your experimental setup and observation that
> lead you to the conclusion the high power calibration is causing the
> device a damage ? I do have 8x CPE510 in our mesh up & running with
> the high power calibration table with astonishing radio performance
> and without any problem. So if the version number could be used to
> differentiate the effected devices, we might be using it. And while I
> was looking together with Felix for this calibration table adress on
> the CPE510 under the original firmware, we might just look at such a
> different version of the CPE510 as well. 

Hi,

I'm sorry, that I couldn't provide a more detailed report, because I
was in a hurry.

Daniel Golle reported a damaged device when using the high power table
together with a high frequency (channel 160 / ~5.8ghz).
I'm not quite sure this is related, but I want to be safe and reverted
the high calibration table patch quickly.

> Second question, for the
> CPE210, is there also a high power calibration table like
> ?KSEG1ADDR(0x1fff5000)? usable ?
No, it's not usable, because the cpe210 only has 1 calib table.

best,
lynxis
-- 
Alexander Couzens

mail: lynxis at fe80.eu
jabber: lynxis at fe80.eu
mobile: +4915123277221
gpg: 390D CF78 8BF9 AA50 4F8F  F1E2 C29E 9DA6 A0DF 8604
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20160622/8c0fec54/attachment.sig>

From hauke at hauke-m.de  Wed Jun 22 14:53:32 2016
From: hauke at hauke-m.de (Hauke Mehrtens)
Date: Wed, 22 Jun 2016 23:53:32 +0200
Subject: [LEDE-DEV] [PATCH] squashfs4: use upstream xz compression
 header format
In-Reply-To: <576AB676.9060900@conorogorman.net>
References: <1466539544-706-1-git-send-email-hauke@hauke-m.de>
 <576AB676.9060900@conorogorman.net>
Message-ID: <4d72bbac-31fc-a444-cc2c-d5ad6a70618d@hauke-m.de>

On 06/22/2016 06:01 PM, Conor O'Gorman wrote:
> On 21/06/16 21:05, Hauke Mehrtens wrote:
>> In the upstream kernel and the upstream squashfs4 tools the xz
>> compression header looks the following:
>> struct disk_comp_opts {
>>          __le32 dictionary_size;
>>          __le32 flags;
>> };
>>
>> We added some other members and also moved some existing members. Place
>> the members which are already in upstream header at the same position
>> as in that kernel and add our own at the end. The kernel should not
>> have a problem when there are some additional members and just ignore
>> them.
>>
> But no endian match? __le32 -> uint32_t

Hi,

The userspace utile does not use __le32, but the values are converted to
little endian before writing them.

Hauke


From daniel at daniel.thecshore.com  Wed Jun 22 13:50:14 2016
From: daniel at daniel.thecshore.com (Daniel Curran-Dickinson)
Date: Wed, 22 Jun 2016 16:50:14 -0400
Subject: [LEDE-DEV] new bugs mailing list
In-Reply-To: <4e8e45f2-744a-0404-b508-d621f77d6c7c@phrozen.org>
References: <4e8e45f2-744a-0404-b508-d621f77d6c7c@phrozen.org>
Message-ID: <1466628614.6625.2.camel@homehost>

Hi John,

On Wed, 2016-06-22 at 09:57 +0200, John Crispin wrote: 
> Hi,
> 
> the issue tracker now announces bug reports on this list
> 

I missed the announcement of the issue tracker; has it been finalized or
still in testing?  If finalized I should take a look at working on the
automated info gathering I've promised (and actually even if not
finalized get started, based on previous discussions, on the info gather
part, even without the big tracker integration).

Regards,

Daniel



From mohammed.berdai at gmail.com  Wed Jun 22 15:20:17 2016
From: mohammed.berdai at gmail.com (Mohammed Berdai)
Date: Wed, 22 Jun 2016 22:20:17 +0000
Subject: [LEDE-DEV] ar71xx - please help test
In-Reply-To: <b03dd176-e96b-bac6-b6b2-a52725a576d8@compex.com.sg>
References: <bfd64b04-7942-19a8-0eda-911840448cb7@phrozen.org>
 <b03dd176-e96b-bac6-b6b2-a52725a576d8@compex.com.sg>
Message-ID: <3452dec4-1187-9558-6e88-cea9c1aaa0e4@gmail.com>

On 06/22/2016 09:31 AM, Dat Le wrote:

Hi,

TPLink TL-WR841ND v7.x is OK.

	Mohammed

> Hi,
> 
> Compex boards WPJ342 WPJ344 WPJ531 and WPJ588 all are OK
> 
> Thanks,
> Dat
> 
> On 6/21/2016 4:23 PM, John Crispin wrote:
>> Hi,
>>
>> i have moved all the profiles into the image building code. i have done
>> some basic testing and already got a bit of feedback from others.
>>
>> it would be nice if people could help test the following patch from my
>> staging tree
>>
>> https://git.lede-project.org/?p=lede/blogic/staging.git;a=commit;h=75773d43cd44ee70e293343fad11db654c35a4ed
>>
>>     John
>>
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
> 
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev



From bmoffitt at ayrstone.com  Wed Jun 22 14:30:51 2016
From: bmoffitt at ayrstone.com (Bill Moffitt)
Date: Wed, 22 Jun 2016 14:30:51 -0700
Subject: [LEDE-DEV] portal wifi router
In-Reply-To: <CAA93jw5QOCk3cKWcz1fnWDTAvx22tijMRPodqaBWTsgRVN0p6g@mail.gmail.com>
References: <CAA93jw5QOCk3cKWcz1fnWDTAvx22tijMRPodqaBWTsgRVN0p6g@mail.gmail.com>
Message-ID: <a36bcfec-8a1d-0e15-88b6-8b425c85b774@ayrstone.com>

On 6/22/2016 10:41 AM, Dave Taht wrote:
> eero shipped something debian based (using batman-adv to mesh, I believe)
> google onhub shipped some sort of hybrid of chromeos (so far as I know)
> https://www.plumewifi.com/ is making all sorts of promises, can't tell
> what they are using.
>
> A new one just cropped up - portal - where their kickstarter claims
> they are using openwrt. Anyone know anything more about it? Not clear
> what chipset they are using but since they are based in taiwan I'd
> guess it's mediatek, but it could be qualcomm?
>
> https://www.kickstarter.com/projects/portalwifi/portal-turbocharged-wifi?ref=email
>
> http://getportal.io/ has more "details" and early backers should be
> seeing routers soon.
>
> They are all claiming massive improvements in wifi performance mostly
> based on whatever 802.11ac based technology they are using, I keep
> hoping at least some of the above were also paying attention to bql,
> fq_codel, per station queuing, etc.
>
Dave-

Thanks for pointing those out (I'll volunteer that Ayrstone AyrMesh is 
also, of course, based on OpenWRT and Open80211s, for those on U.S. and 
Canadian farms. I don't claim that we're improving on anything but 
getting moderate-bandwidth LAN connectivity over very large rural areas).

I love the idea of meshing WiFi systems adapting their channel settings 
around local interference... so the Plume in my house detects that my 
next door neighbor's Portal is interfering, so it changes its channel. 
However, the Plume in my garage is much closer to the neighbor behind me 
than the Plume in my house, and changes the channel to avoid them. This 
then interferes with the neighbor's Portal, which changes its channel to 
avoid my interference, which then interferes with the neighbor behind 
me, who changes channel to avoid that interference...

And, of course, as you point out, this is a situation ripe for 
bufferbloat (we know that mesh networks are potentially, ah, 
troublesome). On the other hand, you, Jim, and others have been banging 
the drum for 6 years or so, if memory serves. So there's no excuse for 
new products coming out to NOT use bql, etc. If the word has gotten down 
to the least capable wireless networking developers (i.e. me), everyone 
should be up to speed by now.

So, on balance, I'm not too worried about these things increasing 
congestion - in a typical apartment building I'm not sure they'll be 
actually be working long enough to congest anything. ;-)

Humorously,

Bill

P.S. for the mathematically inclined, note the discrepancy between the 3 
distinct channels in the 2.4 GHz. band and the application of the 
4-color theorem to channel selection. Sucks...





From lede at kitschensync.net  Wed Jun 22 16:06:14 2016
From: lede at kitschensync.net (Ted Hess)
Date: Wed, 22 Jun 2016 19:06:14 -0400
Subject: [LEDE-DEV] new bugs mailing list
In-Reply-To: <1466628614.6625.2.camel@homehost>
References: <4e8e45f2-744a-0404-b508-d621f77d6c7c@phrozen.org>
 <1466628614.6625.2.camel@homehost>
Message-ID: <74C01D73E6174E049B60347C929F77A0@fortmeadow.com>

Daniel -

Subject to a few more folk's OKs and an up-coming adm meeting, I think we are going to go forward with Flyspray. There is no other 
proposed systems on deck for testing, so this is it unless someone proposes an alternative for further testing, etc.

If you need any help getting at the Flyspray data directly, I can help you out there. The backend is a MySQL DB and regular sync'd 
backups of it could be available on the mirror site. Otherwise, you can pull your data from the existing "export" feature and/or the 
lede-bugs mailing-list. I am working on implementing Flyspray backup so this would be a good time to discuss.

/ted

-----Original Message----- 
From: Daniel Curran-Dickinson
Sent: Wednesday, June 22, 2016 4:50 PM
To: John Crispin
Cc: LEDE Development List
Subject: Re: [LEDE-DEV] new bugs mailing list

Hi John,

On Wed, 2016-06-22 at 09:57 +0200, John Crispin wrote:
> Hi,
>
> the issue tracker now announces bug reports on this list
>

I missed the announcement of the issue tracker; has it been finalized or
still in testing?  If finalized I should take a look at working on the
automated info gathering I've promised (and actually even if not
finalized get started, based on previous discussions, on the info gather
part, even without the big tracker integration).

Regards,

Daniel


_______________________________________________
Lede-dev mailing list
Lede-dev at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev 



From david at lang.hm  Wed Jun 22 16:39:16 2016
From: david at lang.hm (David Lang)
Date: Wed, 22 Jun 2016 16:39:16 -0700 (PDT)
Subject: [LEDE-DEV] portal wifi router
In-Reply-To: <a36bcfec-8a1d-0e15-88b6-8b425c85b774@ayrstone.com>
References: <CAA93jw5QOCk3cKWcz1fnWDTAvx22tijMRPodqaBWTsgRVN0p6g@mail.gmail.com>
 <a36bcfec-8a1d-0e15-88b6-8b425c85b774@ayrstone.com>
Message-ID: <alpine.DEB.2.02.1606221638260.3588@nftneq.ynat.uz>

On Wed, 22 Jun 2016, Bill Moffitt wrote:

> P.S. for the mathematically inclined, note the discrepancy between the 3 
> distinct channels in the 2.4 GHz. band and the application of the 4-color 
> theorem to channel selection. Sucks...

It gets even worse when you realize that so many people actually have a 3D 
version of the problem, not just the 'simple' 2D version.

David Lang


From chinawrj at gmail.com  Wed Jun 22 20:06:06 2016
From: chinawrj at gmail.com (Rujun Wang)
Date: Thu, 23 Jun 2016 11:06:06 +0800
Subject: [LEDE-DEV] [PATCH] Fix the length of msg buffer after realloc
Message-ID: <20160623030606.6151-1-chinawrj@gmail.com>

Signed-off-by: Rujun Wang <chinawrj at gmail.com>
---
 libubus-io.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libubus-io.c b/libubus-io.c
index 9320bf3..0582ff7 100644
--- a/libubus-io.c
+++ b/libubus-io.c
@@ -259,6 +259,7 @@ static bool alloc_msg_buf(struct ubus_context *ctx, int len)
 		return false;
 
 	ctx->msgbuf.data = ptr;
+	ctx->msgbuf_data_len = len;
 	return true;
 }
 
-- 
1.9.1



From daniel at daniel.thecshore.com  Wed Jun 22 18:57:26 2016
From: daniel at daniel.thecshore.com (Daniel Curran-Dickinson)
Date: Wed, 22 Jun 2016 21:57:26 -0400
Subject: [LEDE-DEV] new bugs mailing list
In-Reply-To: <74C01D73E6174E049B60347C929F77A0@fortmeadow.com>
References: <4e8e45f2-744a-0404-b508-d621f77d6c7c@phrozen.org>
 <1466628614.6625.2.camel@homehost>
 <74C01D73E6174E049B60347C929F77A0@fortmeadow.com>
Message-ID: <1466647046.6625.9.camel@homehost>

Hi Ted,

On Wed, 2016-06-22 at 19:06 -0400, Ted Hess wrote: 
> Daniel -
> 
> Subject to a few more folk's OKs and an up-coming adm meeting, I think we are going to go forward with Flyspray. There is no other 
> proposed systems on deck for testing, so this is it unless someone proposes an alternative for further testing, etc.
> 
> If you need any help getting at the Flyspray data directly, I can help you out there. The backend is a MySQL DB and regular sync'd 
> backups of it could be available on the mirror site. Otherwise, you can pull your data from the existing "export" feature and/or the 
> lede-bugs mailing-list. I am working on implementing Flyspray backup so this would be a good time to discuss.

I'm actually more interested in any REST or similar HTTP API calls I can
use AJAX in a Luci app to automatically populate a ticket for a bug
report generated on-device (which I want to use to include information
from the device subject to user edits/approval; that edit/approval part
will have Luci-side); preferably with the ability to create an on
account for first time users (or least link to the account creation
page), and a chance to review the report in the usual web interface
before submitting.

Regards,

Daniel



From john at phrozen.org  Thu Jun 23 00:24:14 2016
From: john at phrozen.org (John Crispin)
Date: Thu, 23 Jun 2016 09:24:14 +0200
Subject: [LEDE-DEV] [PATCH mountd 2/2] support for disk without
	partition table
In-Reply-To: <1466581879-9862-2-git-send-email-olivier.hardouin@gmail.com>
References: <1466581879-9862-1-git-send-email-olivier.hardouin@gmail.com>
 <1466581879-9862-2-git-send-email-olivier.hardouin@gmail.com>
Message-ID: <c46af673-6171-7347-34e0-d8e51b2bc55d@phrozen.org>



On 22/06/2016 09:51, olivier.hardouin at gmail.com wrote:
> if no partition found, try to mount the block device itself
> 
> Signed-off-by: Olivier Hardouin <olivier.hardouin at gmail.com>

Hi,

looks ok, just wondering what kind of storage you see this on. i have
only seen superfloppy type formating on mmc cards and that is almost a
decade ago.

	John

> ---
>  mount.c | 14 ++++++++++----
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/mount.c b/mount.c
> index 0c2862a..7cbb8ff 100644
> --- a/mount.c
> +++ b/mount.c
> @@ -693,13 +693,19 @@ static void mount_enum_drives(void)
>  				char tmp[64];
>  				snprintf(tmp, 64, "/sys/block/%s/", namelist[n]->d_name);
>  				m = scandir(tmp, &namelist2, dir_filter2, dir_sort);
> -				while(m--)
> +				if(m > 0)
>  				{
> -					strncpy(&block[blk_cnt][0], namelist2[m]->d_name, MAX_BLOCK);
> +					while(m--)
> +					{
> +						strncpy(&block[blk_cnt][0], namelist2[m]->d_name, MAX_BLOCK);
> +						blk_cnt++;
> +						free(namelist2[m]);
> +					}
> +					free(namelist2);
> +				} else {
> +					strncpy(&block[blk_cnt][0], namelist[n]->d_name, MAX_BLOCK);
>  					blk_cnt++;
> -					free(namelist2[m]);
>  				}
> -				free(namelist2);
>  			}
>  			free(namelist[n]);
>  		}
> 


From olivier.hardouin at gmail.com  Thu Jun 23 01:17:27 2016
From: olivier.hardouin at gmail.com (Olivier Hardouin)
Date: Thu, 23 Jun 2016 10:17:27 +0200
Subject: [LEDE-DEV] [PATCH mountd 2/2] support for disk without
	partition table
In-Reply-To: <c46af673-6171-7347-34e0-d8e51b2bc55d@phrozen.org>
References: <1466581879-9862-1-git-send-email-olivier.hardouin@gmail.com>
 <1466581879-9862-2-git-send-email-olivier.hardouin@gmail.com>
 <c46af673-6171-7347-34e0-d8e51b2bc55d@phrozen.org>
Message-ID: <CAE0HSK7P_XLOO_Fhq=JVM2QKDp7-faK4aHRZNWxx3N=ba+O2Ng@mail.gmail.com>

I have a USB flash drive fat32 formatted without any partition table.
I agree this is unusual nowadays (manufacturers usually put a
partition table on their devices), but as it mounts ok on my laptop, I
wanted the same behavior.


On Thu, Jun 23, 2016 at 9:24 AM, John Crispin <john at phrozen.org> wrote:
>
>
> On 22/06/2016 09:51, olivier.hardouin at gmail.com wrote:
>> if no partition found, try to mount the block device itself
>>
>> Signed-off-by: Olivier Hardouin <olivier.hardouin at gmail.com>
>
> Hi,
>
> looks ok, just wondering what kind of storage you see this on. i have
> only seen superfloppy type formating on mmc cards and that is almost a
> decade ago.
>
>         John
>
>> ---
>>  mount.c | 14 ++++++++++----
>>  1 file changed, 10 insertions(+), 4 deletions(-)
>>
>> diff --git a/mount.c b/mount.c
>> index 0c2862a..7cbb8ff 100644
>> --- a/mount.c
>> +++ b/mount.c
>> @@ -693,13 +693,19 @@ static void mount_enum_drives(void)
>>                               char tmp[64];
>>                               snprintf(tmp, 64, "/sys/block/%s/", namelist[n]->d_name);
>>                               m = scandir(tmp, &namelist2, dir_filter2, dir_sort);
>> -                             while(m--)
>> +                             if(m > 0)
>>                               {
>> -                                     strncpy(&block[blk_cnt][0], namelist2[m]->d_name, MAX_BLOCK);
>> +                                     while(m--)
>> +                                     {
>> +                                             strncpy(&block[blk_cnt][0], namelist2[m]->d_name, MAX_BLOCK);
>> +                                             blk_cnt++;
>> +                                             free(namelist2[m]);
>> +                                     }
>> +                                     free(namelist2);
>> +                             } else {
>> +                                     strncpy(&block[blk_cnt][0], namelist[n]->d_name, MAX_BLOCK);
>>                                       blk_cnt++;
>> -                                     free(namelist2[m]);
>>                               }
>> -                             free(namelist2);
>>                       }
>>                       free(namelist[n]);
>>               }
>>


From roger.pueyo at guifi.net  Thu Jun 23 01:58:08 2016
From: roger.pueyo at guifi.net (Roger Pueyo Centelles)
Date: Thu, 23 Jun 2016 10:58:08 +0200
Subject: [LEDE-DEV] [PATCH] ramips: add suport for ZBT APE522II
Message-ID: <1466672288-27104-1-git-send-email-roger.pueyo@guifi.net>

The ZBT APE522II is a dual-radio outdoor CPE based on the MT7620a SoC. It has
64 MB RAM, 8 MB flash, 2 Fast Ethernet ports via internal switch (one with
802.3af 48V PoE support), a 802.11b/g/n SoC 2.4 GHz radio and an 802.11a/n/ac
MT7612E-based 5 GHz radio.

Signed-off-by: Roger Pueyo Centelles <roger.pueyo at guifi.net>
---
 target/linux/ramips/base-files/etc/board.d/01_leds |   5 +
 .../linux/ramips/base-files/etc/board.d/02_network |   1 +
 target/linux/ramips/base-files/lib/ramips.sh       |   3 +
 .../ramips/base-files/lib/upgrade/platform.sh      |   1 +
 target/linux/ramips/dts/ZBT-APE522II.dts           | 143 +++++++++++++++++++++
 target/linux/ramips/image/mt7620.mk                |   8 ++
 6 files changed, 161 insertions(+)
 create mode 100644 target/linux/ramips/dts/ZBT-APE522II.dts

diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds b/target/linux/ramips/base-files/etc/board.d/01_leds
index 3aac1e4..460253c 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -296,6 +296,11 @@ y1s)
 	set_usb_led "$board:blue:usb"
 	set_wifi_led "$board:blue:wifi"
 	;;
+zbt-ape522ii)
+	ucidef_set_led_netdev "wlan2g4" "wlan1-link" "$board:green:wlan2g4" "wlan1"
+	ucidef_set_led_netdev "sys1" "wlan1" "$board:green:sys1" "wlan1" "tx rx"
+	ucidef_set_led_netdev "sys2" "wlan0" "$board:green:sys2" "wlan0" "tx rx"
+	;;
 zbt-wa05)
 	ucidef_set_led_default "power" "power" "$board:blue:power" "1"
 	set_wifi_led "$board:blue:air"
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network b/target/linux/ramips/base-files/etc/board.d/02_network
index be1912a..dbb5fb4 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -224,6 +224,7 @@ ramips_setup_interfaces()
 		ucidef_add_switch "switch0" \
 			"1:lan" "2:lan" "0:wan" "6 at eth0"
 		;;
+	zbt-ape522ii|\
 	zbt-we826|\
 	zbt-wr8305rt)
 		ucidef_add_switch "switch0" \
diff --git a/target/linux/ramips/base-files/lib/ramips.sh b/target/linux/ramips/base-files/lib/ramips.sh
index bd4f33d..10139d7 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -523,6 +523,9 @@ ramips_board_detect() {
 	*"Y1S")
 		name="y1s"
 		;;
+	*"ZBT-APE522II")
+		name="zbt-ape522ii"
+		;;
 	*"ZBT-WA05")
 		name="zbt-wa05"
 		;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 0b3d8c7..e3bea00 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -155,6 +155,7 @@ platform_check_image() {
 	x8|\
 	y1|\
 	y1s|\
+	zbt-ape522ii|\
 	zbt-wa05|\
 	zbt-we826|\
 	zbt-wg2626|\
diff --git a/target/linux/ramips/dts/ZBT-APE522II.dts b/target/linux/ramips/dts/ZBT-APE522II.dts
new file mode 100644
index 0000000..eff27c2
--- /dev/null
+++ b/target/linux/ramips/dts/ZBT-APE522II.dts
@@ -0,0 +1,143 @@
+/dts-v1/;
+
+#include "mt7620a.dtsi"
+
+/ {
+	compatible = "zbtlink,zbt-ape522ii", "ralink,mt7620a-soc";
+	model = "ZBT-APE522II";
+
+	chosen {
+		bootargs = "console=ttyS0,115200";
+	};
+
+	gpio-leds {
+		compatible = "gpio-leds";
+
+		sys1 {
+			label = "zbt-ape522ii:green:sys1";
+			gpios = <&gpio0 11 1>;
+		};
+
+		sys2 {
+			label = "zbt-ape522ii:green:sys2";
+			gpios = <&gpio0 12 1>;
+		};
+
+		sys3 {
+			label = "zbt-ape522ii:green:sys3";
+			gpios = <&gpio0 9 1>;
+		};
+
+		sys4 {
+			label = "zbt-ape522ii:green:sys4";
+			gpios = <&gpio0 14 1>;
+		};
+
+		wlan2g4 {
+			label = "zbt-ape522ii:green:wlan2g4";
+			gpios = <&gpio3 0 1>;
+		};
+	};
+
+	gpio-keys-polled {
+		compatible = "gpio-keys-polled";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		poll-interval = <20>;
+
+		reset {
+			label = "reset";
+			gpios = <&gpio0 2 0>;
+			linux,code = <0x198>;
+		};
+	};
+};
+
+&gpio0 {
+	status = "okay";
+};
+
+&gpio1 {
+	status = "okay";
+};
+
+&gpio2 {
+	status = "okay";
+};
+
+&gpio3 {
+	status = "okay";
+};
+
+&spi0 {
+	status = "okay";
+
+	m25p80 at 0 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+		linux,modalias = "m25p80", "w25q64";
+		spi-max-frequency = <10000000>;
+
+		partition at 0 {
+			label = "u-boot";
+			reg = <0x0 0x30000>;
+		};
+
+		partition at 30000 {
+			label = "u-boot-env";
+			reg = <0x30000 0x10000>;
+			read-only;
+		};
+
+		factory: partition at 40000 {
+			label = "factory";
+			reg = <0x40000 0x10000>;
+			read-only;
+		};
+
+		partition at 50000 {
+			label = "firmware";
+			reg = <0x50000 0xf80000>;
+		};
+	};
+};
+
+&ethernet {
+	pinctrl-names = "default";
+	pinctrl-0 = <&ephy_pins>;
+	mtd-mac-address = <&factory 0x4>;
+	mediatek,portmap = "wllll";
+};
+
+&wmac {
+	ralink,mtd-eeprom = <&factory 0>;
+};
+
+&pcie {
+	status = "okay";
+
+	pcie-bridge {
+		mt76 at 0,0 {
+			reg = <0x0000 0 0 0 0>;
+			device_type = "pci";
+			mediatek,mtd-eeprom = <&factory 0x8000>;
+			mediatek,2ghz = <0>;
+		};
+	};
+};
+
+&pinctrl {
+	state_default: pinctrl0 {
+		gpio {
+			ralink,group = "wled", "i2c", "uartf", "wdt";
+			ralink,function = "gpio";
+		};
+
+		pa {
+			ralink,group = "pa";
+			ralink,function = "pa";
+		};
+	};
+};
diff --git a/target/linux/ramips/image/mt7620.mk b/target/linux/ramips/image/mt7620.mk
index 33f94a4..b1afb82 100644
--- a/target/linux/ramips/image/mt7620.mk
+++ b/target/linux/ramips/image/mt7620.mk
@@ -376,6 +376,14 @@ define Device/youku-yk1
 endef
 TARGET_DEVICES += youku-yk1
 
+define Device/zbt-ape522ii
+  DTS := ZBT-APE522II
+  IMAGE_SIZE := $(ralink_default_fw_size_8M)
+  DEVICE_TITLE := Zbtlink ZBT-APE522II
+  DEVICE_PACKAGES := kmod-mt76
+endef
+TARGET_DEVICES += zbt-ape522ii
+
 define Device/zbt-wa05
   DTS := ZBT-WA05
   IMAGE_SIZE := $(ralink_default_fw_size_8M)
-- 
2.8.1



From jo at mein.io  Thu Jun 23 02:14:08 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Thu, 23 Jun 2016 11:14:08 +0200
Subject: [LEDE-DEV] [PATCH] kernel: fix missing break in ubi
 auto-mounting patch
In-Reply-To: <1466539624-769-1-git-send-email-hauke@hauke-m.de>
References: <1466539624-769-1-git-send-email-hauke@hauke-m.de>
Message-ID: <8f3420ec-25d3-2c80-8d31-8015d188c155@mein.io>

On 06/21/2016 10:07 PM, Hauke Mehrtens wrote:
> Signed-off-by: Hauke Mehrtens <hauke at hauke-m.de>
Reviewed-by: Jo-Philipp Wich <jo at mein.io>
> ---
>  .../492-try-auto-mounting-ubi0-rootfs-in-init-do_mounts.c.patch      | 3 ++-
>  .../492-try-auto-mounting-ubi0-rootfs-in-init-do_mounts.c.patch      | 3 ++-
>  .../492-try-auto-mounting-ubi0-rootfs-in-init-do_mounts.c.patch      | 5 +++--
>  3 files changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/target/linux/generic/patches-3.18/492-try-auto-mounting-ubi0-rootfs-in-init-do_mounts.c.patch b/target/linux/generic/patches-3.18/492-try-auto-mounting-ubi0-rootfs-in-init-do_mounts.c.patch
> index e4f31fd..3f2b439 100644
> --- a/target/linux/generic/patches-3.18/492-try-auto-mounting-ubi0-rootfs-in-init-do_mounts.c.patch
> +++ b/target/linux/generic/patches-3.18/492-try-auto-mounting-ubi0-rootfs-in-init-do_mounts.c.patch
> @@ -11,7 +11,7 @@ Signed-off-by: Daniel Golle <daniel at makrotopia.org>
>  
>  --- a/init/do_mounts.c
>  +++ b/init/do_mounts.c
> -@@ -433,7 +433,27 @@ retry:
> +@@ -433,7 +433,28 @@ retry:
>   out:
>   	put_page(page);
>   }
> @@ -29,6 +29,7 @@ Signed-off-by: Daniel Golle <daniel at makrotopia.org>
>  +			case -EACCES:
>  +				flags |= MS_RDONLY;
>  +				tried++;
> ++				break;
>  +			default:
>  +				return err;
>  +		}
> diff --git a/target/linux/generic/patches-4.1/492-try-auto-mounting-ubi0-rootfs-in-init-do_mounts.c.patch b/target/linux/generic/patches-4.1/492-try-auto-mounting-ubi0-rootfs-in-init-do_mounts.c.patch
> index 005de3f..f6c71a2 100644
> --- a/target/linux/generic/patches-4.1/492-try-auto-mounting-ubi0-rootfs-in-init-do_mounts.c.patch
> +++ b/target/linux/generic/patches-4.1/492-try-auto-mounting-ubi0-rootfs-in-init-do_mounts.c.patch
> @@ -11,7 +11,7 @@ Signed-off-by: Daniel Golle <daniel at makrotopia.org>
>  
>  --- a/init/do_mounts.c
>  +++ b/init/do_mounts.c
> -@@ -438,7 +438,27 @@ retry:
> +@@ -438,7 +438,28 @@ retry:
>   out:
>   	put_page(page);
>   }
> @@ -29,6 +29,7 @@ Signed-off-by: Daniel Golle <daniel at makrotopia.org>
>  +			case -EACCES:
>  +				flags |= MS_RDONLY;
>  +				tried++;
> ++				break;
>  +			default:
>  +				return err;
>  +		}
> diff --git a/target/linux/generic/patches-4.4/492-try-auto-mounting-ubi0-rootfs-in-init-do_mounts.c.patch b/target/linux/generic/patches-4.4/492-try-auto-mounting-ubi0-rootfs-in-init-do_mounts.c.patch
> index d21e6d2..ab8b8bb 100644
> --- a/target/linux/generic/patches-4.4/492-try-auto-mounting-ubi0-rootfs-in-init-do_mounts.c.patch
> +++ b/target/linux/generic/patches-4.4/492-try-auto-mounting-ubi0-rootfs-in-init-do_mounts.c.patch
> @@ -11,7 +11,7 @@ Signed-off-by: Daniel Golle <daniel at makrotopia.org>
>  
>  --- a/init/do_mounts.c
>  +++ b/init/do_mounts.c
> -@@ -438,7 +438,27 @@ retry:
> +@@ -438,7 +438,28 @@ retry:
>   out:
>   	put_page(page);
>   }
> @@ -29,6 +29,7 @@ Signed-off-by: Daniel Golle <daniel at makrotopia.org>
>  +			case -EACCES:
>  +				flags |= MS_RDONLY;
>  +				tried++;
> ++				break;
>  +			default:
>  +				return err;
>  +		}
> @@ -40,7 +41,7 @@ Signed-off-by: Daniel Golle <daniel at makrotopia.org>
>   #ifdef CONFIG_ROOT_NFS
>   
>   #define NFSROOT_TIMEOUT_MIN	5
> -@@ -532,6 +552,10 @@ void __init mount_root(void)
> +@@ -532,6 +553,10 @@ void __init mount_root(void)
>   			change_floppy("root floppy");
>   	}
>   #endif
> 



From i at conorogorman.net  Thu Jun 23 02:25:37 2016
From: i at conorogorman.net (Conor O'Gorman)
Date: Thu, 23 Jun 2016 10:25:37 +0100
Subject: [LEDE-DEV] new bugs mailing list
In-Reply-To: <1466647046.6625.9.camel@homehost>
References: <4e8e45f2-744a-0404-b508-d621f77d6c7c@phrozen.org>
 <1466628614.6625.2.camel@homehost>
 <74C01D73E6174E049B60347C929F77A0@fortmeadow.com>
 <1466647046.6625.9.camel@homehost>
Message-ID: <576BAB11.4060007@conorogorman.net>

On 23/06/16 02:57, Daniel Curran-Dickinson wrote:
> Hi Ted,
>
> On Wed, 2016-06-22 at 19:06 -0400, Ted Hess wrote:
>> Daniel -
>>
>> Subject to a few more folk's OKs and an up-coming adm meeting, I think we are going to go forward with Flyspray. There is no other
>> proposed systems on deck for testing, so this is it unless someone proposes an alternative for further testing, etc.
>>
>> If you need any help getting at the Flyspray data directly, I can help you out there. The backend is a MySQL DB and regular sync'd
>> backups of it could be available on the mirror site. Otherwise, you can pull your data from the existing "export" feature and/or the
>> lede-bugs mailing-list. I am working on implementing Flyspray backup so this would be a good time to discuss.
> I'm actually more interested in any REST or similar HTTP API calls I can
> use AJAX in a Luci app to automatically populate a ticket for a bug
> report generated on-device (which I want to use to include information
> from the device subject to user edits/approval; that edit/approval part
> will have Luci-side); preferably with the ability to create an on
> account for first time users (or least link to the account creation
> page), and a chance to review the report in the usual web interface
> before submitting.
>
>
+1 API


From john at phrozen.org  Thu Jun 23 02:37:28 2016
From: john at phrozen.org (John Crispin)
Date: Thu, 23 Jun 2016 11:37:28 +0200
Subject: [LEDE-DEV] [PATCH mountd 2/2] support for disk without
 partition table
In-Reply-To: <CAE0HSK7P_XLOO_Fhq=JVM2QKDp7-faK4aHRZNWxx3N=ba+O2Ng@mail.gmail.com>
References: <1466581879-9862-1-git-send-email-olivier.hardouin@gmail.com>
 <1466581879-9862-2-git-send-email-olivier.hardouin@gmail.com>
 <c46af673-6171-7347-34e0-d8e51b2bc55d@phrozen.org>
 <CAE0HSK7P_XLOO_Fhq=JVM2QKDp7-faK4aHRZNWxx3N=ba+O2Ng@mail.gmail.com>
Message-ID: <8d43a936-f2b8-406d-6034-2db2d3cf4214@phrozen.org>



On 23/06/2016 10:17, Olivier Hardouin wrote:
> I have a USB flash drive fat32 formatted without any partition table.
> I agree this is unusual nowadays (manufacturers usually put a
> partition table on their devices), but as it mounts ok on my laptop, I
> wanted the same behavior.


Hi,

that is called superfloppy iirc. not seen those in a while. i've pushed
the changes to the mountd repo

	John

> 
> 
> On Thu, Jun 23, 2016 at 9:24 AM, John Crispin <john at phrozen.org> wrote:
>>
>>
>> On 22/06/2016 09:51, olivier.hardouin at gmail.com wrote:
>>> if no partition found, try to mount the block device itself
>>>
>>> Signed-off-by: Olivier Hardouin <olivier.hardouin at gmail.com>
>>
>> Hi,
>>
>> looks ok, just wondering what kind of storage you see this on. i have
>> only seen superfloppy type formating on mmc cards and that is almost a
>> decade ago.
>>
>>         John
>>
>>> ---
>>>  mount.c | 14 ++++++++++----
>>>  1 file changed, 10 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/mount.c b/mount.c
>>> index 0c2862a..7cbb8ff 100644
>>> --- a/mount.c
>>> +++ b/mount.c
>>> @@ -693,13 +693,19 @@ static void mount_enum_drives(void)
>>>                               char tmp[64];
>>>                               snprintf(tmp, 64, "/sys/block/%s/", namelist[n]->d_name);
>>>                               m = scandir(tmp, &namelist2, dir_filter2, dir_sort);
>>> -                             while(m--)
>>> +                             if(m > 0)
>>>                               {
>>> -                                     strncpy(&block[blk_cnt][0], namelist2[m]->d_name, MAX_BLOCK);
>>> +                                     while(m--)
>>> +                                     {
>>> +                                             strncpy(&block[blk_cnt][0], namelist2[m]->d_name, MAX_BLOCK);
>>> +                                             blk_cnt++;
>>> +                                             free(namelist2[m]);
>>> +                                     }
>>> +                                     free(namelist2);
>>> +                             } else {
>>> +                                     strncpy(&block[blk_cnt][0], namelist[n]->d_name, MAX_BLOCK);
>>>                                       blk_cnt++;
>>> -                                     free(namelist2[m]);
>>>                               }
>>> -                             free(namelist2);
>>>                       }
>>>                       free(namelist[n]);
>>>               }
>>>
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 


From champetier.etienne at gmail.com  Thu Jun 23 07:02:52 2016
From: champetier.etienne at gmail.com (Etienne Champetier)
Date: Thu, 23 Jun 2016 16:02:52 +0200
Subject: [LEDE-DEV] [PATCH v4] base-files: seed /dev/urandom
In-Reply-To: <576A4876.4010205@darbyshire-bryant.me.uk>
References: <1466069891-28577-1-git-send-email-champetier.etienne@gmail.com>
 <589dc209-ddff-904a-2899-75eee367b7fb@phrozen.org>
 <576A4876.4010205@darbyshire-bryant.me.uk>
Message-ID: <CAOdf3goGvDHj3prJZL6JkVSFeHsUZT61ahJGmxUGmCBL8Zv0Ug@mail.gmail.com>

Hi all,

2016-06-22 10:12 GMT+02:00 Kevin Darbyshire-Bryant
<kevin at darbyshire-bryant.me.uk>:
>
>
> On 22/06/16 08:50, John Crispin wrote:
>>
>>
> <snip>
>>
>> write_urandom_seed_on_boot was a placeholder for what the option should
>> be named as i could not think of a good one ;) please try to find a
>> shorter one
>>
>>         John
>
> May I offer "preserveurandomseed" or 'saveurandom' as some 'random' ideas
> :-)


is 'saveurandomseed' short enough ? else what about 'urandomseed' ?
(my first version was 'write_new_urandom_seed_on_boot' ;) )


>
> Kevin
>
>


From jo at mein.io  Thu Jun 23 07:08:49 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Thu, 23 Jun 2016 16:08:49 +0200
Subject: [LEDE-DEV] [PATCH v4] base-files: seed /dev/urandom
In-Reply-To: <CAOdf3goGvDHj3prJZL6JkVSFeHsUZT61ahJGmxUGmCBL8Zv0Ug@mail.gmail.com>
References: <1466069891-28577-1-git-send-email-champetier.etienne@gmail.com>
 <589dc209-ddff-904a-2899-75eee367b7fb@phrozen.org>
 <576A4876.4010205@darbyshire-bryant.me.uk>
 <CAOdf3goGvDHj3prJZL6JkVSFeHsUZT61ahJGmxUGmCBL8Zv0Ug@mail.gmail.com>
Message-ID: <370c43de-dd5d-fbc9-4815-35ead861a62c@mein.io>

Hi,

if we plan to attach multiple functions to the option (e.g. persistent
lease file) then it would probably make sense to give it a generic name,
e.g.

 "option persist 0/1"

or

 "option save_state 0/1"

~ Jo


From champetier.etienne at gmail.com  Thu Jun 23 08:00:44 2016
From: champetier.etienne at gmail.com (Etienne Champetier)
Date: Thu, 23 Jun 2016 17:00:44 +0200
Subject: [LEDE-DEV] [PATCH v4] base-files: seed /dev/urandom
In-Reply-To: <370c43de-dd5d-fbc9-4815-35ead861a62c@mein.io>
References: <1466069891-28577-1-git-send-email-champetier.etienne@gmail.com>
 <589dc209-ddff-904a-2899-75eee367b7fb@phrozen.org>
 <576A4876.4010205@darbyshire-bryant.me.uk>
 <CAOdf3goGvDHj3prJZL6JkVSFeHsUZT61ahJGmxUGmCBL8Zv0Ug@mail.gmail.com>
 <370c43de-dd5d-fbc9-4815-35ead861a62c@mein.io>
Message-ID: <CAOdf3goTk3y5y7Ts3ahst+sZN70MAiUq3RHb_Z_So7y2+2T18w@mail.gmail.com>

2016-06-23 16:08 GMT+02:00 Jo-Philipp Wich <jo at mein.io>:
> Hi,
>
> if we plan to attach multiple functions to the option (e.g. persistent
> lease file) then it would probably make sense to give it a generic name,
> e.g.
>
>  "option persist 0/1"
>
> or
>
>  "option save_state 0/1"

why put multiple possibly unrelated functions under one option?
I might want to save urandom seed but not persistant lease file


>
> ~ Jo
>

Etienne


From jo at mein.io  Thu Jun 23 08:05:51 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Thu, 23 Jun 2016 17:05:51 +0200
Subject: [LEDE-DEV] [PATCH v4] base-files: seed /dev/urandom
In-Reply-To: <CAOdf3goTk3y5y7Ts3ahst+sZN70MAiUq3RHb_Z_So7y2+2T18w@mail.gmail.com>
References: <1466069891-28577-1-git-send-email-champetier.etienne@gmail.com>
 <589dc209-ddff-904a-2899-75eee367b7fb@phrozen.org>
 <576A4876.4010205@darbyshire-bryant.me.uk>
 <CAOdf3goGvDHj3prJZL6JkVSFeHsUZT61ahJGmxUGmCBL8Zv0Ug@mail.gmail.com>
 <370c43de-dd5d-fbc9-4815-35ead861a62c@mein.io>
 <CAOdf3goTk3y5y7Ts3ahst+sZN70MAiUq3RHb_Z_So7y2+2T18w@mail.gmail.com>
Message-ID: <d1cff19e-bd8e-e17f-111a-223b0802ed84@mein.io>

Hi.

> why put multiple possibly unrelated functions under one option?

To have a global "write to flash is okay" option instead of needing to
change different options with different semantics in different places.

For example if I want to make the lease file persistent, I would change
the path in the config from /tmp/ to /etc/. But yes, no need to group stuff.

What about following the dnsmasq approach though?
Setting "option randomseed /etc/random.seed" would make it persistent,
the default would be empty or something in /var.

~ Jo


From daniel at gimpelevich.san-francisco.ca.us  Thu Jun 23 08:19:00 2016
From: daniel at gimpelevich.san-francisco.ca.us (Daniel Gimpelevich)
Date: Thu, 23 Jun 2016 08:19:00 -0700
Subject: [LEDE-DEV] [PATCH v4] base-files: seed /dev/urandom
In-Reply-To: <1466069891-28577-1-git-send-email-champetier.etienne@gmail.com>
References: <1466069891-28577-1-git-send-email-champetier.etienne@gmail.com>
Message-ID: <1466695140.5921.29.camel@chimera>

On Thu, 2016-06-16 at 09:38 +0000, Etienne CHAMPETIER wrote:
> +SEED=/etc/urandom.seed
> +
> +error_exit() {
> +    logger -t urandom_seed "$1"
> +    exit 1
> +}
> +
> +save() {
> +    touch $SEED.tmp || error_exit "touch failed"
> +    chown root:root $SEED.tmp || error_exit "chown failed"
> +    chmod 600 $SEED.tmp || error_exit "chmod failed"
> +    getrandom 512 > $SEED.tmp || error_exit "getrandom failed"
> +    mv $SEED.tmp $SEED || error_exit "mv failed"
> +}

The .tmp file should go in /tmp, and maybe SEED would be better off
in /etc/config, so that it gets picked up by sysupgrade?




From champetier.etienne at gmail.com  Thu Jun 23 08:26:32 2016
From: champetier.etienne at gmail.com (Etienne Champetier)
Date: Thu, 23 Jun 2016 17:26:32 +0200
Subject: [LEDE-DEV] [PATCH v4] base-files: seed /dev/urandom
In-Reply-To: <1466695140.5921.29.camel@chimera>
References: <1466069891-28577-1-git-send-email-champetier.etienne@gmail.com>
 <1466695140.5921.29.camel@chimera>
Message-ID: <CAOdf3goZ8AsS7eG6ndzFzVEE7Kr=juWC98mvgv5bnCUw58hwsQ@mail.gmail.com>

Hi Daniel,

2016-06-23 17:19 GMT+02:00 Daniel Gimpelevich
<daniel at gimpelevich.san-francisco.ca.us>:
> On Thu, 2016-06-16 at 09:38 +0000, Etienne CHAMPETIER wrote:
>> +SEED=/etc/urandom.seed
>> +
>> +error_exit() {
>> +    logger -t urandom_seed "$1"
>> +    exit 1
>> +}
>> +
>> +save() {
>> +    touch $SEED.tmp || error_exit "touch failed"
>> +    chown root:root $SEED.tmp || error_exit "chown failed"
>> +    chmod 600 $SEED.tmp || error_exit "chmod failed"
>> +    getrandom 512 > $SEED.tmp || error_exit "getrandom failed"
>> +    mv $SEED.tmp $SEED || error_exit "mv failed"
>> +}
>
> The .tmp file should go in /tmp,

no, else you loose the atomic part of the 'mv' command

> and maybe SEED would be better off
> in /etc/config, so that it gets picked up by sysupgrade?

and no because if you restore the same config on multiple router you
end up with the same seed,
which is exactly what this patch is about (not having the same state)

>
>


From champetier.etienne at gmail.com  Thu Jun 23 08:55:08 2016
From: champetier.etienne at gmail.com (Etienne Champetier)
Date: Thu, 23 Jun 2016 17:55:08 +0200
Subject: [LEDE-DEV] [PATCH v4] base-files: seed /dev/urandom
In-Reply-To: <d1cff19e-bd8e-e17f-111a-223b0802ed84@mein.io>
References: <1466069891-28577-1-git-send-email-champetier.etienne@gmail.com>
 <589dc209-ddff-904a-2899-75eee367b7fb@phrozen.org>
 <576A4876.4010205@darbyshire-bryant.me.uk>
 <CAOdf3goGvDHj3prJZL6JkVSFeHsUZT61ahJGmxUGmCBL8Zv0Ug@mail.gmail.com>
 <370c43de-dd5d-fbc9-4815-35ead861a62c@mein.io>
 <CAOdf3goTk3y5y7Ts3ahst+sZN70MAiUq3RHb_Z_So7y2+2T18w@mail.gmail.com>
 <d1cff19e-bd8e-e17f-111a-223b0802ed84@mein.io>
Message-ID: <CAOdf3gonyk9AjcTeyzjyjzc642pLFZzYd-B7rzkRL2Ld0Z3eng@mail.gmail.com>

2016-06-23 17:05 GMT+02:00 Jo-Philipp Wich <jo at mein.io>:
> Hi.
>
>> why put multiple possibly unrelated functions under one option?
>
> To have a global "write to flash is okay" option instead of needing to
> change different options with different semantics in different places.

if it's disabled by default i don't see the need for a global "write
to flash is okay".
Also do we have that much different options?

>
> For example if I want to make the lease file persistent, I would change
> the path in the config from /tmp/ to /etc/. But yes, no need to group stuff.

if we have a global and a specific config, how do you mix them up (0, 1, undef)?

>
> What about following the dnsmasq approach though?
> Setting "option randomseed /etc/random.seed" would make it persistent,
> the default would be empty or something in /var.

no need to write it if we lose it on reboot ...

>
> ~ Jo
>


From dave.taht at gmail.com  Thu Jun 23 10:25:57 2016
From: dave.taht at gmail.com (Dave Taht)
Date: Thu, 23 Jun 2016 10:25:57 -0700
Subject: [LEDE-DEV] trying to cover costs on my bit of the build cluster
Message-ID: <CAA93jw4wmDxgGkduwAamUu7JnxnEVw4XwwAwQDjAGVp9fMda3w@mail.gmail.com>

I just put up a gofundme link to cover the costs of the 16 cpu google
cloud buildbot machine I donated to lede last month, here:

https://www.gofundme.com/2awkswc

It's looking like $ 500-600 a month (in addition to the 250/mo I
already put into the openwrt builder).

800/mo is WAY more than I can sustain personally past august 1, so I
will be forced to make hard choices then, without some way to cover
these expanded costs.

>From what I can see the new build cluster for lede is *wildly* successful,

( http://phase2.builds.lede-project.org/tgrid )

It is very easy and possibly desirable to continue using bits of the
google compute cloud to continue, or expand this - or there may be
better alternatives... but, regardless, I'll have to shut down or cut
back something by aug 1st without some help here.

-- 
Dave T?ht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org


From mcr at sandelman.ca  Thu Jun 23 11:55:05 2016
From: mcr at sandelman.ca (Michael Richardson)
Date: Thu, 23 Jun 2016 14:55:05 -0400
Subject: [LEDE-DEV] portal wifi router
In-Reply-To: <a36bcfec-8a1d-0e15-88b6-8b425c85b774@ayrstone.com>
References: <CAA93jw5QOCk3cKWcz1fnWDTAvx22tijMRPodqaBWTsgRVN0p6g@mail.gmail.com>
 <a36bcfec-8a1d-0e15-88b6-8b425c85b774@ayrstone.com>
Message-ID: <25597.1466708105@obiwan.sandelman.ca>


Bill Moffitt <bmoffitt at ayrstone.com> wrote:
    > I love the idea of meshing WiFi systems adapting their channel settings
    > around local interference... so the Plume in my house detects that my
    > next door neighbor's Portal is interfering, so it changes its
    > channel. However, the Plume in my garage is much closer to the neighbor
    > behind me than the Plume in my house, and changes the channel to avoid
    > them. This then interferes with the neighbor's Portal, which changes
    > its channel to avoid my interference, which then interferes with the
    > neighbor behind me, who changes channel to avoid that interference...

This is the map colouring problem as you point out:

    > P.S. for the mathematically inclined, note the discrepancy between the
    > 3 distinct channels in the 2.4 GHz. band and the application of the
    > 4-color theorem to channel selection. Sucks...

Am I wrong in thinking that if you can lower your Tx power that you can bleed
less into adjacent channels?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 464 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20160623/4e942083/attachment.sig>

From david at lang.hm  Thu Jun 23 13:15:46 2016
From: david at lang.hm (David Lang)
Date: Thu, 23 Jun 2016 13:15:46 -0700
Subject: [LEDE-DEV] portal wifi router
In-Reply-To: <25597.1466708105@obiwan.sandelman.ca>
References: <CAA93jw5QOCk3cKWcz1fnWDTAvx22tijMRPodqaBWTsgRVN0p6g@mail.gmail.com>
 <a36bcfec-8a1d-0e15-88b6-8b425c85b774@ayrstone.com>
 <25597.1466708105@obiwan.sandelman.ca>
Message-ID: <c3e178fe1dfa40cd5322cb1f84c1ed1c@lang.hm>

 On Thu, 23 Jun 2016 14:55:05 -0400, Michael Richardson wrote:
> Bill Moffitt <bmoffitt at ayrstone.com> wrote:
>     > I love the idea of meshing WiFi systems adapting their channel 
> settings
>     > around local interference... so the Plume in my house detects 
> that my
>     > next door neighbor's Portal is interfering, so it changes its
>     > channel. However, the Plume in my garage is much closer to the 
> neighbor
>     > behind me than the Plume in my house, and changes the channel 
> to avoid
>     > them. This then interferes with the neighbor's Portal, which 
> changes
>     > its channel to avoid my interference, which then interferes 
> with the
>     > neighbor behind me, who changes channel to avoid that 
> interference...
>
> This is the map colouring problem as you point out:
>
>     > P.S. for the mathematically inclined, note the discrepancy 
> between the
>     > 3 distinct channels in the 2.4 GHz. band and the application of 
> the
>     > 4-color theorem to channel selection. Sucks...
>
> Am I wrong in thinking that if you can lower your Tx power that you 
> can bleed
> less into adjacent channels?

 well, lowering TX power reduce your impact on everything, including 
 adjacent channels, but not enough.

 things can be done with good antenna design, but you would need to do 
 the same thing on both ends, and you still have a problem that your 
 transmitter and receiver are so close to each other that it's really 
 hard to isolate them.

 unfocused power drops off at the cube of the distance, so things a few 
 feet apart have a tremendous advantage to the same things within a 
 couple inches of each other (completely ignoring signals propagating 
 over power/ground busses and things like that)

 David Lang


From eschultz at prplfoundation.org  Thu Jun 23 13:44:02 2016
From: eschultz at prplfoundation.org (Eric Schultz)
Date: Thu, 23 Jun 2016 15:44:02 -0500
Subject: [LEDE-DEV] TR-069 and OpenWrt Fuze Meeting - June 24, 7AM PT
Message-ID: <576C4A12.5010701@prplfoundation.org>

As mentioned at last week's meeting, I wanted to announce that we'll
have another discussion on TR-069 and OpenWrt on Fuze on Friday, June 24
at 7AM PT. We'll discuss the in-person meeting and any steps that need
to be taken before it
as well as continue the TR-069 presentations, starting with ADB and then
Technicolor.

I'm looking forward to seeing everyone there!

Thanks,

Eric

--
To join the web meeting click or copy and paste this URL into your browser:

https://fuzemeeting.com/browser/#login
<https://fuzemeeting.com/browser/#login> and enter your name and the
meeting number: 32924366

To join the audio portion of this meeting:

Internet Audio: Simply select the internet audio option after joining.

Toll / Intl #: +12014794595 <tel:%2B12014794595>

Toll free #: +18553463893 <tel:%2B18553463893>

You can find international access numbers at
https://www.fuze.com/extras/symphony <https://www.fuze.com/extras/symphony>

If prompted, enter the meeting number: 32924366, then press #.

For the optimal experience, download Fuze:
www.fuzebox.com/products/download <http://www.fuzebox.com/products/download>

Need help? You can connect to our Customer Support Team or access
self-help tools at www.fuzebox.com/support <http://www.fuzebox.com/support>


From drew at nixcores.com  Thu Jun 23 20:25:47 2016
From: drew at nixcores.com (Drew from NixCore)
Date: Thu, 23 Jun 2016 21:25:47 -0600
Subject: [LEDE-DEV] [PATCH] [ramips] Added NixCore X1 target V5
In-Reply-To: <651aaa54-c389-7edb-8603-56b5d9b226d5@phrozen.org>
References: <5761F4AC.1010805@nixcores.com>
 <651aaa54-c389-7edb-8603-56b5d9b226d5@phrozen.org>
Message-ID: <576CA83B.9020304@nixcores.com>

John,

I am not sure what is causing the line wrap, the emails that I get from 
the list don't have the line wrap but the list shows it.

Any suggestions?

Drew

On 06/16/2016 05:45 AM, John Crispin wrote:
> Hi,
>
> patch does not apply. please go here
>
> --> http://patchwork.ozlabs.org/patch/636150/
>
> click on "download mbox" and you will see that it is line wrapped at 80
> characters.
>
> 	John
>
>
> On 16/06/2016 02:37, Drew from NixCore wrote:
>> Added NixCore X1 ramips target http://nixcores.com.  This builds 8M and
>> 16M images.  V5 updates the patch to work with the latest source.git
>>
>> Signed-off-by: Drew Gaylo <drew at nixcores.com>
>> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
>> b/target/linux/ramips/base-files/etc/board.d/02_network
>> index be1912a..ebcf619 100755
>> --- a/target/linux/ramips/base-files/etc/board.d/02_network
>> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
>> @@ -77,6 +77,7 @@ ramips_setup_interfaces()
>>       mt7628|\
>>       mzk-750dhp|\
>>       mzk-w300nh2|\
>> +    nixcore|\
>>       oy-0001|\
>>       pbr-m1|\
>>       psg1208|\
>> diff --git a/target/linux/ramips/base-files/lib/ramips.sh
>> b/target/linux/ramips/base-files/lib/ramips.sh
>> index bd4f33d..340a628 100755
>> --- a/target/linux/ramips/base-files/lib/ramips.sh
>> +++ b/target/linux/ramips/base-files/lib/ramips.sh
>> @@ -322,6 +322,9 @@ ramips_board_detect() {
>>       *"NCS601W")
>>           name="ncs601w"
>>           ;;
>> +    *"NixcoreX1")
>> +        name="nixcore-x1"
>> +        ;;
>>       *"NW718")
>>           name="nw718"
>>           ;;
>> diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh
>> b/target/linux/ramips/base-files/lib/upgrade/platform.sh
>> index 0b3d8c7..8749c99 100755
>> --- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
>> +++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
>> @@ -95,6 +95,7 @@ platform_check_image() {
>>       mzk-w300nh2|\
>>       mzk-wdpr|\
>>       nbg-419n|\
>> +    nixcore|\
>>       nw718|\
>>       oy-0001|\
>>       pbr-m1|\
>> diff --git a/target/linux/ramips/dts/NIXCOREX1-16M.dts
>> b/target/linux/ramips/dts/NIXCOREX1-16M.dts
>> new file mode 100644
>> index 0000000..2ffcbb2
>> --- /dev/null
>> +++ b/target/linux/ramips/dts/NIXCOREX1-16M.dts
>> @@ -0,0 +1,95 @@
>> +/dts-v1/;
>> +
>> +/include/ "rt5350.dtsi"
>> +
>> +/ {
>> +    compatible = "NixcoreX1", "ralink,rt5350-soc";
>> +    model = "NixcoreX1";
>> +
>> +    chosen{
>> +        bootargs = "console=ttyS1,57600";
>> +    };
>> +};
>> +
>> +&gpio0{
>> +    status = "okay";
>> +};
>> +
>> +&gpio1{
>> +    status = "okay";
>> +};
>> +
>> +&i2c{
>> +    status = "okay";
>> +};
>> +&uart{
>> +    status = "okay";
>> +    /* Mix of uart and gpio */
>> +    reset-names = "gpio uartf";
>> +};
>> +&spi0{
>> +    status = "okay";
>> +
>> +    m25p80 at 0 {
>> +        #address-cells = <1>;
>> +        #size-cells = <1>;
>> +        compatible = "s25fl064k";
>> +        reg = <0>;
>> +        linux,modalias = "m25p80", "s25fl064k";
>> +        spi-max-frequency = <10000000>;
>> +
>> +        partition at 0 {
>> +            label = "uboot";
>> +            reg = <0x0 0x30000>;
>> +            read-only;
>> +        };
>> +
>> +        partition at 30000 {
>> +            label = "uboot-env";
>> +            reg = <0x30000 0x10000>;
>> +            read-only;
>> +        };
>> +
>> +        factory: partition at 40000 {
>> +            label = "factory";
>> +            reg = <0x40000 0x10000>;
>> +            read-only;
>> +        };
>> +
>> +        partition at 50000 {
>> +            label = "firmware";
>> +            reg = <0x50000 0xfb0000>;
>> +        };
>> +    };
>> +};
>> +
>> +&pinctrl {
>> +    state_default: pinctrl0 {
>> +        gpio {
>> +            /* Associate the tjag, uartf and led groups with gpio */
>> +            ralink,group = "jtag", "led", "spi_cs1";
>> +            /* How do we set individual pins? */
>> +            ralink,function = "gpio";
>> +        };
>> +    };
>> +};
>> +
>> +&ethernet {
>> +    mtd-mac-address = <&factory 0x4>;
>> +};
>> +
>> +&esw {
>> +    ralink,portmap = <0x17>;
>> +};
>> +
>> +&wmac {
>> +    ralink,mtd-eeprom = <&factory 0>;
>> +};
>> +
>> +&ehci {
>> +    status = "okay";
>> +};
>> +
>> +&ohci {
>> +    status = "okay";
>> +};
>> diff --git a/target/linux/ramips/dts/NIXCOREX1-8M.dts
>> b/target/linux/ramips/dts/NIXCOREX1-8M.dts
>> new file mode 100644
>> index 0000000..ca557fd
>> --- /dev/null
>> +++ b/target/linux/ramips/dts/NIXCOREX1-8M.dts
>> @@ -0,0 +1,95 @@
>> +/dts-v1/;
>> +
>> +/include/ "rt5350.dtsi"
>> +
>> +/ {
>> +    compatible = "NixcoreX1", "ralink,rt5350-soc";
>> +    model = "NixcoreX1";
>> +
>> +    chosen{
>> +        bootargs = "console=ttyS1,57600";
>> +    };
>> +};
>> +
>> +&gpio0{
>> +    status = "okay";
>> +};
>> +
>> +&gpio1{
>> +    status = "okay";
>> +};
>> +
>> +&i2c{
>> +    status = "okay";
>> +};
>> +&uart{
>> +    status = "okay";
>> +    /* Mix of uart and gpio */
>> +    reset-names = "gpio uartf";
>> +};
>> +&spi0{
>> +    status = "okay";
>> +
>> +    m25p80 at 0 {
>> +        #address-cells = <1>;
>> +        #size-cells = <1>;
>> +        compatible = "s25fl064k";
>> +        reg = <0>;
>> +        linux,modalias = "m25p80", "s25fl064k";
>> +        spi-max-frequency = <10000000>;
>> +
>> +        partition at 0 {
>> +            label = "uboot";
>> +            reg = <0x0 0x30000>;
>> +            read-only;
>> +        };
>> +
>> +        partition at 30000 {
>> +            label = "uboot-env";
>> +            reg = <0x30000 0x10000>;
>> +            read-only;
>> +        };
>> +
>> +        factory: partition at 40000 {
>> +            label = "factory";
>> +            reg = <0x40000 0x10000>;
>> +            read-only;
>> +        };
>> +
>> +        partition at 50000 {
>> +            label = "firmware";
>> +            reg = <0x50000 0x7b0000>;
>> +        };
>> +    };
>> +};
>> +
>> +&pinctrl {
>> +    state_default: pinctrl0 {
>> +        gpio {
>> +            /* Associate the tjag, uartf and led groups with gpio */
>> +            ralink,group = "jtag", "led", "spi_cs1";
>> +            /* How do we set individual pins? */
>> +            ralink,function = "gpio";
>> +        };
>> +    };
>> +};
>> +
>> +&ethernet {
>> +    mtd-mac-address = <&factory 0x4>;
>> +};
>> +
>> +&esw {
>> +    ralink,portmap = <0x17>;
>> +};
>> +
>> +&wmac {
>> +    ralink,mtd-eeprom = <&factory 0>;
>> +};
>> +
>> +&ehci {
>> +    status = "okay";
>> +};
>> +
>> +&ohci {
>> +    status = "okay";
>> +};
>> diff --git a/target/linux/ramips/image/rt305x.mk
>> b/target/linux/ramips/image/rt305x.mk
>> index da7fc46..db12a8e 100644
>> --- a/target/linux/ramips/image/rt305x.mk
>> +++ b/target/linux/ramips/image/rt305x.mk
>> @@ -100,6 +100,21 @@ define BuildFirmware/HLKRM04/initramfs
>>       mkhilinkfw -e -i$(call imgname,$(1),$(2))-uImage.bin -o $(call
>> imgname,$(1),$(2))-factory.bin;
>>   endef
>>
>> +# This is called to build the nixcore image.  Build both 8MB and 16MB
>> +nixcore_8mb_mtd_size=8060928
>> +nixcore_16mb_mtd_size=16449536
>> +define BuildFirmware/NIXCOREX1/squashfs
>> +# Args are XXX, nixcore-mM and NIXCOREX1-xM
>> +    $(call
>> BuildFirmware/CustomFlash/$(1),$(1),$(2)-8M,$(3)-8M,$(nixcore_8mb_mtd_size))
>>
>> +    $(call
>> BuildFirmware/CustomFlash/$(1),$(1),$(2)-16M,$(3)-16M,$(nixcore_16mb_mtd_size))
>>
>> +    # Can do somethings here after the build?
>> +endef
>> +define BuildFirmware/NIXCOREX1/initramfs
>> +# Args are XXXX, nixcore-mM and NIXCOREX1-xM
>> +    $(call BuildFirmware/OF/initramfs,$(1),$(2)-8M,$(3)-8M)
>> +    $(call BuildFirmware/OF/initramfs,$(1),$(2)-16M,$(3)-16M)
>> +endef
>> +
>>   vocore_8mb_mtd_size=8060928
>>   vocore_16mb_mtd_size=16449536
>>   define BuildFirmware/VOCORE/squashfs
>> @@ -257,6 +272,7 @@ Image/Build/Profile/NBG-419N=$(call
>> BuildFirmware/Default4M/$(1),$(1),nbg-419n,N
>>   Image/Build/Profile/MZKW300NH2=$(call
>> BuildFirmware/Edimax/$(1),$(1),mzk-w300nh2,MZK-W300NH2,$(mzkw300nh2_mtd_size),CSYS,RN52,0x50000,0xc0000)
>>
>>   Image/Build/Profile/MZKWDPR=$(call
>> BuildFirmware/Default8M/$(1),$(1),mzk-wdpr,MZK-WDPR)
>>   Image/Build/Profile/NCS601W=$(call
>> BuildFirmware/Default8M/$(1),$(1),ncs601W,NCS601W)
>> +Image/Build/Profile/NIXCOREX1=$(call
>> BuildFirmware/NIXCOREX1/$(1),$(1),nixcorex1,NIXCOREX1)
>>   nw718_mtd_size=3801088
>>   Image/Build/Profile/NW718=$(call
>> BuildFirmware/CustomFlashFactory/$(1),$(1),nw718m,NW718,$(nw718_mtd_size),ARA1B4NCRNW718;1,factory)
>>
>>   Image/Build/Profile/M2M=$(call
>> BuildFirmware/Default8M/$(1),$(1),m2m,M2M,Linux Kernel Image)
>> @@ -353,6 +369,7 @@ define Image/Build/Profile/Default
>>       $(call Image/Build/Profile/MZKWDPR,$(1))
>>       $(call Image/Build/Profile/NBG-419N,$(1))
>>       $(call Image/Build/Profile/NCS601W,$(1))
>> +    $(call Image/Build/Profile/NIXCOREX1,$(1))
>>       $(call Image/Build/Profile/NW718,$(1))
>>       $(call Image/Build/Profile/MINIEMBWIFI,$(1))
>>       $(call Image/Build/Profile/MINIEMBPLUG,$(1))
>> diff --git a/target/linux/ramips/rt305x/profiles/nixcore.mk
>> b/target/linux/ramips/rt305x/profiles/nixcore.mk
>> new file mode 100644
>> index 0000000..22dee9b
>> --- /dev/null
>> +++ b/target/linux/ramips/rt305x/profiles/nixcore.mk
>> @@ -0,0 +1,20 @@
>> +#
>> +# Copyright (C) 2014 OpenWrt.org
>> +#
>> +# This is free software, licensed under the GNU General Public License v2.
>> +# See /LICENSE for more information.
>> +#
>> +
>> +define Profile/NIXCOREX1
>> +    NAME:=NixcoreX1
>> +    PACKAGES:=\
>> +        kmod-usb-core kmod-usb-ohci kmod-usb2 \
>> +        kmod-i2c-core kmod-i2c-ralink \
>> +        kmod-spi-dev
>> +endef
>> +
>> +define Profile/NIXCOREX1/Description
>> +    Package set for Nixcore X1 board
>> +endef
>> +
>> +$(eval $(call Profile,NIXCOREX1))
>>
>>
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev



From john at phrozen.org  Thu Jun 23 21:19:34 2016
From: john at phrozen.org (John Crispin)
Date: Fri, 24 Jun 2016 06:19:34 +0200
Subject: [LEDE-DEV] [PATCH] [ramips] Added NixCore X1 target V5
In-Reply-To: <576CA83B.9020304@nixcores.com>
References: <5761F4AC.1010805@nixcores.com>
 <651aaa54-c389-7edb-8603-56b5d9b226d5@phrozen.org>
 <576CA83B.9020304@nixcores.com>
Message-ID: <69a2bc22-be22-ee3b-3697-d7f845adf273@phrozen.org>


On 24/06/2016 05:25, Drew from NixCore wrote:
> John,
> 
> I am not sure what is causing the line wrap, the emails that I get from
> the list don't have the line wrap but the list shows it.
> 
> Any suggestions?
> 
> Drew

Hi Drew

its your email client with 99.99% certainty. try using "git send-email"
or use github to send us a PR.

	John

> 
> On 06/16/2016 05:45 AM, John Crispin wrote:
>> Hi,
>>
>> patch does not apply. please go here
>>
>> --> http://patchwork.ozlabs.org/patch/636150/
>>
>> click on "download mbox" and you will see that it is line wrapped at 80
>> characters.
>>
>>     John
>>
>>
>> On 16/06/2016 02:37, Drew from NixCore wrote:
>>> Added NixCore X1 ramips target http://nixcores.com.  This builds 8M and
>>> 16M images.  V5 updates the patch to work with the latest source.git
>>>
>>> Signed-off-by: Drew Gaylo <drew at nixcores.com>
>>> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
>>> b/target/linux/ramips/base-files/etc/board.d/02_network
>>> index be1912a..ebcf619 100755
>>> --- a/target/linux/ramips/base-files/etc/board.d/02_network
>>> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
>>> @@ -77,6 +77,7 @@ ramips_setup_interfaces()
>>>       mt7628|\
>>>       mzk-750dhp|\
>>>       mzk-w300nh2|\
>>> +    nixcore|\
>>>       oy-0001|\
>>>       pbr-m1|\
>>>       psg1208|\
>>> diff --git a/target/linux/ramips/base-files/lib/ramips.sh
>>> b/target/linux/ramips/base-files/lib/ramips.sh
>>> index bd4f33d..340a628 100755
>>> --- a/target/linux/ramips/base-files/lib/ramips.sh
>>> +++ b/target/linux/ramips/base-files/lib/ramips.sh
>>> @@ -322,6 +322,9 @@ ramips_board_detect() {
>>>       *"NCS601W")
>>>           name="ncs601w"
>>>           ;;
>>> +    *"NixcoreX1")
>>> +        name="nixcore-x1"
>>> +        ;;
>>>       *"NW718")
>>>           name="nw718"
>>>           ;;
>>> diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh
>>> b/target/linux/ramips/base-files/lib/upgrade/platform.sh
>>> index 0b3d8c7..8749c99 100755
>>> --- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
>>> +++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
>>> @@ -95,6 +95,7 @@ platform_check_image() {
>>>       mzk-w300nh2|\
>>>       mzk-wdpr|\
>>>       nbg-419n|\
>>> +    nixcore|\
>>>       nw718|\
>>>       oy-0001|\
>>>       pbr-m1|\
>>> diff --git a/target/linux/ramips/dts/NIXCOREX1-16M.dts
>>> b/target/linux/ramips/dts/NIXCOREX1-16M.dts
>>> new file mode 100644
>>> index 0000000..2ffcbb2
>>> --- /dev/null
>>> +++ b/target/linux/ramips/dts/NIXCOREX1-16M.dts
>>> @@ -0,0 +1,95 @@
>>> +/dts-v1/;
>>> +
>>> +/include/ "rt5350.dtsi"
>>> +
>>> +/ {
>>> +    compatible = "NixcoreX1", "ralink,rt5350-soc";
>>> +    model = "NixcoreX1";
>>> +
>>> +    chosen{
>>> +        bootargs = "console=ttyS1,57600";
>>> +    };
>>> +};
>>> +
>>> +&gpio0{
>>> +    status = "okay";
>>> +};
>>> +
>>> +&gpio1{
>>> +    status = "okay";
>>> +};
>>> +
>>> +&i2c{
>>> +    status = "okay";
>>> +};
>>> +&uart{
>>> +    status = "okay";
>>> +    /* Mix of uart and gpio */
>>> +    reset-names = "gpio uartf";
>>> +};
>>> +&spi0{
>>> +    status = "okay";
>>> +
>>> +    m25p80 at 0 {
>>> +        #address-cells = <1>;
>>> +        #size-cells = <1>;
>>> +        compatible = "s25fl064k";
>>> +        reg = <0>;
>>> +        linux,modalias = "m25p80", "s25fl064k";
>>> +        spi-max-frequency = <10000000>;
>>> +
>>> +        partition at 0 {
>>> +            label = "uboot";
>>> +            reg = <0x0 0x30000>;
>>> +            read-only;
>>> +        };
>>> +
>>> +        partition at 30000 {
>>> +            label = "uboot-env";
>>> +            reg = <0x30000 0x10000>;
>>> +            read-only;
>>> +        };
>>> +
>>> +        factory: partition at 40000 {
>>> +            label = "factory";
>>> +            reg = <0x40000 0x10000>;
>>> +            read-only;
>>> +        };
>>> +
>>> +        partition at 50000 {
>>> +            label = "firmware";
>>> +            reg = <0x50000 0xfb0000>;
>>> +        };
>>> +    };
>>> +};
>>> +
>>> +&pinctrl {
>>> +    state_default: pinctrl0 {
>>> +        gpio {
>>> +            /* Associate the tjag, uartf and led groups with gpio */
>>> +            ralink,group = "jtag", "led", "spi_cs1";
>>> +            /* How do we set individual pins? */
>>> +            ralink,function = "gpio";
>>> +        };
>>> +    };
>>> +};
>>> +
>>> +&ethernet {
>>> +    mtd-mac-address = <&factory 0x4>;
>>> +};
>>> +
>>> +&esw {
>>> +    ralink,portmap = <0x17>;
>>> +};
>>> +
>>> +&wmac {
>>> +    ralink,mtd-eeprom = <&factory 0>;
>>> +};
>>> +
>>> +&ehci {
>>> +    status = "okay";
>>> +};
>>> +
>>> +&ohci {
>>> +    status = "okay";
>>> +};
>>> diff --git a/target/linux/ramips/dts/NIXCOREX1-8M.dts
>>> b/target/linux/ramips/dts/NIXCOREX1-8M.dts
>>> new file mode 100644
>>> index 0000000..ca557fd
>>> --- /dev/null
>>> +++ b/target/linux/ramips/dts/NIXCOREX1-8M.dts
>>> @@ -0,0 +1,95 @@
>>> +/dts-v1/;
>>> +
>>> +/include/ "rt5350.dtsi"
>>> +
>>> +/ {
>>> +    compatible = "NixcoreX1", "ralink,rt5350-soc";
>>> +    model = "NixcoreX1";
>>> +
>>> +    chosen{
>>> +        bootargs = "console=ttyS1,57600";
>>> +    };
>>> +};
>>> +
>>> +&gpio0{
>>> +    status = "okay";
>>> +};
>>> +
>>> +&gpio1{
>>> +    status = "okay";
>>> +};
>>> +
>>> +&i2c{
>>> +    status = "okay";
>>> +};
>>> +&uart{
>>> +    status = "okay";
>>> +    /* Mix of uart and gpio */
>>> +    reset-names = "gpio uartf";
>>> +};
>>> +&spi0{
>>> +    status = "okay";
>>> +
>>> +    m25p80 at 0 {
>>> +        #address-cells = <1>;
>>> +        #size-cells = <1>;
>>> +        compatible = "s25fl064k";
>>> +        reg = <0>;
>>> +        linux,modalias = "m25p80", "s25fl064k";
>>> +        spi-max-frequency = <10000000>;
>>> +
>>> +        partition at 0 {
>>> +            label = "uboot";
>>> +            reg = <0x0 0x30000>;
>>> +            read-only;
>>> +        };
>>> +
>>> +        partition at 30000 {
>>> +            label = "uboot-env";
>>> +            reg = <0x30000 0x10000>;
>>> +            read-only;
>>> +        };
>>> +
>>> +        factory: partition at 40000 {
>>> +            label = "factory";
>>> +            reg = <0x40000 0x10000>;
>>> +            read-only;
>>> +        };
>>> +
>>> +        partition at 50000 {
>>> +            label = "firmware";
>>> +            reg = <0x50000 0x7b0000>;
>>> +        };
>>> +    };
>>> +};
>>> +
>>> +&pinctrl {
>>> +    state_default: pinctrl0 {
>>> +        gpio {
>>> +            /* Associate the tjag, uartf and led groups with gpio */
>>> +            ralink,group = "jtag", "led", "spi_cs1";
>>> +            /* How do we set individual pins? */
>>> +            ralink,function = "gpio";
>>> +        };
>>> +    };
>>> +};
>>> +
>>> +&ethernet {
>>> +    mtd-mac-address = <&factory 0x4>;
>>> +};
>>> +
>>> +&esw {
>>> +    ralink,portmap = <0x17>;
>>> +};
>>> +
>>> +&wmac {
>>> +    ralink,mtd-eeprom = <&factory 0>;
>>> +};
>>> +
>>> +&ehci {
>>> +    status = "okay";
>>> +};
>>> +
>>> +&ohci {
>>> +    status = "okay";
>>> +};
>>> diff --git a/target/linux/ramips/image/rt305x.mk
>>> b/target/linux/ramips/image/rt305x.mk
>>> index da7fc46..db12a8e 100644
>>> --- a/target/linux/ramips/image/rt305x.mk
>>> +++ b/target/linux/ramips/image/rt305x.mk
>>> @@ -100,6 +100,21 @@ define BuildFirmware/HLKRM04/initramfs
>>>       mkhilinkfw -e -i$(call imgname,$(1),$(2))-uImage.bin -o $(call
>>> imgname,$(1),$(2))-factory.bin;
>>>   endef
>>>
>>> +# This is called to build the nixcore image.  Build both 8MB and 16MB
>>> +nixcore_8mb_mtd_size=8060928
>>> +nixcore_16mb_mtd_size=16449536
>>> +define BuildFirmware/NIXCOREX1/squashfs
>>> +# Args are XXX, nixcore-mM and NIXCOREX1-xM
>>> +    $(call
>>> BuildFirmware/CustomFlash/$(1),$(1),$(2)-8M,$(3)-8M,$(nixcore_8mb_mtd_size))
>>>
>>>
>>> +    $(call
>>> BuildFirmware/CustomFlash/$(1),$(1),$(2)-16M,$(3)-16M,$(nixcore_16mb_mtd_size))
>>>
>>>
>>> +    # Can do somethings here after the build?
>>> +endef
>>> +define BuildFirmware/NIXCOREX1/initramfs
>>> +# Args are XXXX, nixcore-mM and NIXCOREX1-xM
>>> +    $(call BuildFirmware/OF/initramfs,$(1),$(2)-8M,$(3)-8M)
>>> +    $(call BuildFirmware/OF/initramfs,$(1),$(2)-16M,$(3)-16M)
>>> +endef
>>> +
>>>   vocore_8mb_mtd_size=8060928
>>>   vocore_16mb_mtd_size=16449536
>>>   define BuildFirmware/VOCORE/squashfs
>>> @@ -257,6 +272,7 @@ Image/Build/Profile/NBG-419N=$(call
>>> BuildFirmware/Default4M/$(1),$(1),nbg-419n,N
>>>   Image/Build/Profile/MZKW300NH2=$(call
>>> BuildFirmware/Edimax/$(1),$(1),mzk-w300nh2,MZK-W300NH2,$(mzkw300nh2_mtd_size),CSYS,RN52,0x50000,0xc0000)
>>>
>>>
>>>   Image/Build/Profile/MZKWDPR=$(call
>>> BuildFirmware/Default8M/$(1),$(1),mzk-wdpr,MZK-WDPR)
>>>   Image/Build/Profile/NCS601W=$(call
>>> BuildFirmware/Default8M/$(1),$(1),ncs601W,NCS601W)
>>> +Image/Build/Profile/NIXCOREX1=$(call
>>> BuildFirmware/NIXCOREX1/$(1),$(1),nixcorex1,NIXCOREX1)
>>>   nw718_mtd_size=3801088
>>>   Image/Build/Profile/NW718=$(call
>>> BuildFirmware/CustomFlashFactory/$(1),$(1),nw718m,NW718,$(nw718_mtd_size),ARA1B4NCRNW718;1,factory)
>>>
>>>
>>>   Image/Build/Profile/M2M=$(call
>>> BuildFirmware/Default8M/$(1),$(1),m2m,M2M,Linux Kernel Image)
>>> @@ -353,6 +369,7 @@ define Image/Build/Profile/Default
>>>       $(call Image/Build/Profile/MZKWDPR,$(1))
>>>       $(call Image/Build/Profile/NBG-419N,$(1))
>>>       $(call Image/Build/Profile/NCS601W,$(1))
>>> +    $(call Image/Build/Profile/NIXCOREX1,$(1))
>>>       $(call Image/Build/Profile/NW718,$(1))
>>>       $(call Image/Build/Profile/MINIEMBWIFI,$(1))
>>>       $(call Image/Build/Profile/MINIEMBPLUG,$(1))
>>> diff --git a/target/linux/ramips/rt305x/profiles/nixcore.mk
>>> b/target/linux/ramips/rt305x/profiles/nixcore.mk
>>> new file mode 100644
>>> index 0000000..22dee9b
>>> --- /dev/null
>>> +++ b/target/linux/ramips/rt305x/profiles/nixcore.mk
>>> @@ -0,0 +1,20 @@
>>> +#
>>> +# Copyright (C) 2014 OpenWrt.org
>>> +#
>>> +# This is free software, licensed under the GNU General Public
>>> License v2.
>>> +# See /LICENSE for more information.
>>> +#
>>> +
>>> +define Profile/NIXCOREX1
>>> +    NAME:=NixcoreX1
>>> +    PACKAGES:=\
>>> +        kmod-usb-core kmod-usb-ohci kmod-usb2 \
>>> +        kmod-i2c-core kmod-i2c-ralink \
>>> +        kmod-spi-dev
>>> +endef
>>> +
>>> +define Profile/NIXCOREX1/Description
>>> +    Package set for Nixcore X1 board
>>> +endef
>>> +
>>> +$(eval $(call Profile,NIXCOREX1))
>>>
>>>
>>> _______________________________________________
>>> Lede-dev mailing list
>>> Lede-dev at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/lede-dev
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
> 
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


From russell at personaltelco.net  Thu Jun 23 22:54:35 2016
From: russell at personaltelco.net (Russell Senior)
Date: Thu, 23 Jun 2016 22:54:35 -0700
Subject: [LEDE-DEV] portal wifi router
In-Reply-To: <c3e178fe1dfa40cd5322cb1f84c1ed1c@lang.hm> (David Lang's message
 of "Thu, 23 Jun 2016 13:15:46 -0700")
References: <CAA93jw5QOCk3cKWcz1fnWDTAvx22tijMRPodqaBWTsgRVN0p6g@mail.gmail.com>
 <a36bcfec-8a1d-0e15-88b6-8b425c85b774@ayrstone.com>
 <25597.1466708105@obiwan.sandelman.ca>
 <c3e178fe1dfa40cd5322cb1f84c1ed1c@lang.hm>
Message-ID: <87r3bn6sis.fsf@husum.klickitat.com>

>>>>> "David" == David Lang <david at lang.hm> writes:

David> unfocused power drops off at the cube of the distance, [...]

That should be square of the distance.  And that applies to anything
with an antenna.  It all diverges, for practical purposes.  About
6 dB loss for every doubling of the distance.


-- 
Russell Senior, President
russell at personaltelco.net


From jo at mein.io  Fri Jun 24 04:30:50 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Fri, 24 Jun 2016 13:30:50 +0200
Subject: [LEDE-DEV] trying to cover costs on my bit of the build cluster
In-Reply-To: <CAA93jw4wmDxgGkduwAamUu7JnxnEVw4XwwAwQDjAGVp9fMda3w@mail.gmail.com>
References: <CAA93jw4wmDxgGkduwAamUu7JnxnEVw4XwwAwQDjAGVp9fMda3w@mail.gmail.com>
Message-ID: <be851007-3982-4621-5443-d742fdf28191@mein.io>

Hi Dave,

please tell me if funding becomes problematic, we can always take the
builder offline and continue with the remaining resources.

Maybe you could also ask the OpenWrt folks whether all Google builders
are still needed there, given the fact that the builder is recompiling
the same very git revision since two months already.


~ Jo


From ardeleanalex at gmail.com  Fri Jun 24 04:53:21 2016
From: ardeleanalex at gmail.com (Alexandru Ardelean)
Date: Fri, 24 Jun 2016 14:53:21 +0300
Subject: [LEDE-DEV] trying to cover costs on my bit of the build cluster
In-Reply-To: <be851007-3982-4621-5443-d742fdf28191@mein.io>
References: <CAA93jw4wmDxgGkduwAamUu7JnxnEVw4XwwAwQDjAGVp9fMda3w@mail.gmail.com>
 <be851007-3982-4621-5443-d742fdf28191@mein.io>
Message-ID: <CA+U=DsrJYw+rYiPA8NF7nqy7GD2KM-CyDd25P=O1GuTxSsk6fw@mail.gmail.com>

On Fri, Jun 24, 2016 at 2:30 PM, Jo-Philipp Wich <jo at mein.io> wrote:
> Hi Dave,
>
> please tell me if funding becomes problematic, we can always take the
> builder offline and continue with the remaining resources.
>
> Maybe you could also ask the OpenWrt folks whether all Google builders
> are still needed there, given the fact that the builder is recompiling
> the same very git revision since two months already.
>
>
> ~ Jo
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

[ Curious here ]
Would it be an idea to spin-up the builders on a as-needed basis ?
Is that something that's already done ?

No idea how this works on Google, but as an example, on DigitalOcean,
there's an API for bringing up/down VMs/machines.
I was thinking it would be interesting to try out an experiment like
this on Digital Ocean (for my own interests) to see about integrating
a CI/CD env with DigitalOcean.

I will say, I have no idea how often builds/commits occur on
LEDE/OpenWrt, and thus no way to know whether this improves anything
(in terms of cost).
So, whatever I'm saying here may be just noise.

One more interesting topic (and at this point Sci-Fi), something that
would be truly interesting is to somehow scale all the routers in the
world (running LEDE/OpenWrt) to pitch-in CPU cycles for build (if they
want to) by installing a package.
Something like 1/5/10% of the CPU power to be allocated for CI/CD.
I wouldn't debate technical challenges right now.
And this is not entirely new in the world ; grid computing has been
around for a while, but it would be interesting to do on routers.
It could make the project be self-sufficient for CI/CD.


From bittorf at bluebottle.com  Fri Jun 24 05:05:27 2016
From: bittorf at bluebottle.com (Bastian Bittorf)
Date: Fri, 24 Jun 2016 14:05:27 +0200
Subject: [LEDE-DEV] trying to cover costs on my bit of the build cluster
In-Reply-To: <be851007-3982-4621-5443-d742fdf28191@mein.io>
References: <CAA93jw4wmDxgGkduwAamUu7JnxnEVw4XwwAwQDjAGVp9fMda3w@mail.gmail.com>
 <be851007-3982-4621-5443-d742fdf28191@mein.io>
Message-ID: <20160624120527.GO22807@medion.lan>

* Jo-Philipp Wich <jo at mein.io> [24.06.2016 13:55]:
> please tell me if funding becomes problematic, we can always take the
> builder offline and continue with the remaining resources.
> 
> Maybe you could also ask the OpenWrt folks whether all Google builders
> are still needed there, given the fact that the builder is recompiling
> the same very git revision since two months already.

as proposed during battlemesh, our strong box (24 cores, 160gig RAM)
is now in the data-centre and working. Is there some advice for setting
up a build-thingy?

bye, bastian


From alin.nastac at gmail.com  Fri Jun 24 05:41:10 2016
From: alin.nastac at gmail.com (Alin Nastac)
Date: Fri, 24 Jun 2016 14:41:10 +0200
Subject: [LEDE-DEV] [PATCH] libnetfilter_queue: fix checksum computation
Message-ID: <1466772070-21711-1-git-send-email-alin.nastac@gmail.com>

There are 2 issues fixed by this patch:
  - UDP checksum is computed incorrectly, the used pseudo IP header
    contains transport protocol 6 iso 17
  - on big endian arches the UDP/TCP checksum is incorrectly
    computed when payload length is odd

Signed-off-by: Alin Nastac <alin.nastac at gmail.com>
---
 .../patches/100-checksum_computation.patch         | 117 +++++++++++++++++++++
 1 file changed, 117 insertions(+)
 create mode 100644 package/libs/libnetfilter-queue/patches/100-checksum_computation.patch

diff --git a/package/libs/libnetfilter-queue/patches/100-checksum_computation.patch b/package/libs/libnetfilter-queue/patches/100-checksum_computation.patch
new file mode 100644
index 0000000..5d170f3
--- /dev/null
+++ b/package/libs/libnetfilter-queue/patches/100-checksum_computation.patch
@@ -0,0 +1,117 @@
+diff -Nru libnetfilter_queue-1.0.2.orig/src/extra/checksum.c libnetfilter_queue-1.0.2/src/extra/checksum.c
+--- libnetfilter_queue-1.0.2.orig/src/extra/checksum.c	2012-08-06 14:50:10.596973900 +0200
++++ libnetfilter_queue-1.0.2/src/extra/checksum.c	2016-06-23 17:06:50.266905883 +0200
+@@ -11,6 +11,7 @@
+ 
+ #include <stdio.h>
+ #include <stdbool.h>
++#include <endian.h>
+ #include <arpa/inet.h>
+ #include <netinet/ip.h>
+ #include <netinet/ip6.h>
+@@ -26,8 +27,13 @@
+ 		sum += *buf++;
+ 		size -= sizeof(uint16_t);
+ 	}
+-	if (size)
+-		sum += *(uint8_t *)buf;
++	if (size) {
++#if __BYTE_ORDER == __BIG_ENDIAN
++		sum += (uint16_t)*(uint8_t *)buf << 8;
++#else
++		sum += (uint16_t)*(uint8_t *)buf;
++#endif
++	}
+ 
+ 	sum = (sum >> 16) + (sum & 0xffff);
+ 	sum += (sum >>16);
+@@ -35,7 +41,7 @@
+ 	return (uint16_t)(~sum);
+ }
+ 
+-uint16_t checksum_tcpudp_ipv4(struct iphdr *iph)
++uint16_t checksum_tcpudp_ipv4(struct iphdr *iph, uint16_t protocol_id)
+ {
+ 	uint32_t sum = 0;
+ 	uint32_t iph_len = iph->ihl*4;
+@@ -46,13 +52,13 @@
+ 	sum += (iph->saddr) & 0xFFFF;
+ 	sum += (iph->daddr >> 16) & 0xFFFF;
+ 	sum += (iph->daddr) & 0xFFFF;
+-	sum += htons(IPPROTO_TCP);
++	sum += htons(protocol_id);
+ 	sum += htons(len);
+ 
+ 	return checksum(sum, (uint16_t *)payload, len);
+ }
+ 
+-uint16_t checksum_tcpudp_ipv6(struct ip6_hdr *ip6h, void *transport_hdr)
++uint16_t checksum_tcpudp_ipv6(struct ip6_hdr *ip6h, void *transport_hdr, uint16_t protocol_id)
+ {
+ 	uint32_t sum = 0;
+ 	uint32_t hdr_len = (uint32_t *)transport_hdr - (uint32_t *)ip6h;
+@@ -68,7 +74,7 @@
+ 		sum += (ip6h->ip6_dst.s6_addr16[i] >> 16) & 0xFFFF;
+ 		sum += (ip6h->ip6_dst.s6_addr16[i]) & 0xFFFF;
+ 	}
+-	sum += htons(IPPROTO_TCP);
++	sum += htons(protocol_id);
+ 	sum += htons(ip6h->ip6_plen);
+ 
+ 	return checksum(sum, (uint16_t *)payload, len);
+diff -Nru libnetfilter_queue-1.0.2.orig/src/extra/tcp.c libnetfilter_queue-1.0.2/src/extra/tcp.c
+--- libnetfilter_queue-1.0.2.orig/src/extra/tcp.c	2012-08-20 19:36:17.985866277 +0200
++++ libnetfilter_queue-1.0.2/src/extra/tcp.c	2016-06-23 17:04:52.911859011 +0200
+@@ -91,7 +91,7 @@
+ {
+ 	/* checksum field in header needs to be zero for calculation. */
+ 	tcph->check = 0;
+-	tcph->check = checksum_tcpudp_ipv4(iph);
++	tcph->check = checksum_tcpudp_ipv4(iph, IPPROTO_TCP);
+ }
+ EXPORT_SYMBOL(nfq_tcp_compute_checksum_ipv4);
+ 
+@@ -105,7 +105,7 @@
+ {
+ 	/* checksum field in header needs to be zero for calculation. */
+ 	tcph->check = 0;
+-	tcph->check = checksum_tcpudp_ipv6(ip6h, tcph);
++	tcph->check = checksum_tcpudp_ipv6(ip6h, tcph, IPPROTO_TCP);
+ }
+ EXPORT_SYMBOL(nfq_tcp_compute_checksum_ipv6);
+ 
+diff -Nru libnetfilter_queue-1.0.2.orig/src/extra/udp.c libnetfilter_queue-1.0.2/src/extra/udp.c
+--- libnetfilter_queue-1.0.2.orig/src/extra/udp.c	2012-08-20 19:36:17.985866277 +0200
++++ libnetfilter_queue-1.0.2/src/extra/udp.c	2016-06-23 17:04:52.922859297 +0200
+@@ -91,7 +91,7 @@
+ {
+ 	/* checksum field in header needs to be zero for calculation. */
+ 	udph->check = 0;
+-	udph->check = checksum_tcpudp_ipv4(iph);
++	udph->check = checksum_tcpudp_ipv4(iph, IPPROTO_UDP);
+ }
+ EXPORT_SYMBOL(nfq_udp_compute_checksum_ipv4);
+ 
+@@ -110,7 +110,7 @@
+ {
+ 	/* checksum field in header needs to be zero for calculation. */
+ 	udph->check = 0;
+-	udph->check = checksum_tcpudp_ipv6(ip6h, udph);
++	udph->check = checksum_tcpudp_ipv6(ip6h, udph, IPPROTO_UDP);
+ }
+ EXPORT_SYMBOL(nfq_udp_compute_checksum_ipv6);
+ 
+diff -Nru libnetfilter_queue-1.0.2.orig/src/internal.h libnetfilter_queue-1.0.2/src/internal.h
+--- libnetfilter_queue-1.0.2.orig/src/internal.h	2012-08-06 14:50:10.596973900 +0200
++++ libnetfilter_queue-1.0.2/src/internal.h	2016-06-23 17:04:52.930859505 +0200
+@@ -13,8 +13,8 @@
+ struct ip6_hdr;
+ 
+ uint16_t checksum(uint32_t sum, uint16_t *buf, int size);
+-uint16_t checksum_tcpudp_ipv4(struct iphdr *iph);
+-uint16_t checksum_tcpudp_ipv6(struct ip6_hdr *ip6h, void *transport_hdr);
++uint16_t checksum_tcpudp_ipv4(struct iphdr *iph, uint16_t protocol_id);
++uint16_t checksum_tcpudp_ipv6(struct ip6_hdr *ip6h, void *transport_hdr, uint16_t protocol_id);
+ 
+ struct pkt_buff {
+ 	uint8_t *mac_header;
-- 
1.7.12.4



From jo at mein.io  Fri Jun 24 05:44:51 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Fri, 24 Jun 2016 14:44:51 +0200
Subject: [LEDE-DEV] [PATCH] libnetfilter_queue: fix checksum computation
In-Reply-To: <1466772070-21711-1-git-send-email-alin.nastac@gmail.com>
References: <1466772070-21711-1-git-send-email-alin.nastac@gmail.com>
Message-ID: <a176bd73-3c16-0f16-4308-1d6617c72d3d@mein.io>

Hi Alin,

is there some upstream reference we can refer to? Did you submit it
there as well?

Regards,
Jo


From jo at mein.io  Fri Jun 24 06:27:26 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Fri, 24 Jun 2016 15:27:26 +0200
Subject: [LEDE-DEV] trying to cover costs on my bit of the build cluster
In-Reply-To: <20160624120527.GO22807@medion.lan>
References: <CAA93jw4wmDxgGkduwAamUu7JnxnEVw4XwwAwQDjAGVp9fMda3w@mail.gmail.com>
 <be851007-3982-4621-5443-d742fdf28191@mein.io>
 <20160624120527.GO22807@medion.lan>
Message-ID: <6af4d658-ebeb-9768-ef96-9ad0001cb7a4@mein.io>

Hi Bastian,

the usual approach is the following:

- Install "buildbot-slave", on Debian/Ubuntu this is as easy as running
  "apt-get install buildbot-slave"
- Install remaining packages required for build, I attached the package
  list exported from one of our slaves
- Setup a slave and point it to our master (replace "myslave" and
  "mypassword"):
  $ buildbot create-slave --umask=022 /var/lib/buildbot/slaves/myslave \
      builds.lede-project.org:9990 myslave mypassword
  $ chown -R buildbot:nogroup /var/lib/buildbot/slaves/myslave
- Adjust /etc/default/buildslave (mainly set enabled to 1, and adjust
  basedir, leave options and prefixcmd empty)
- Send me the name and the password offlist so I can register the slave

Builds will require between 30 and 40GB of storage. No externally
reachable ports are required, the slave will pull and push the required
files itself.

HTH,
Jo
-------------- next part --------------
acl adduser apt apt-utils base-files base-passwd bash binutils bsdmainutils bsdutils build-essential buildbot buildbot-slave busybox bzip2 ca-certificates console-setup console-setup-linux coreutils cpio cpp cpp-4.9 cron curl dash debconf debconf-i18n debian-archive-keyring debianutils dictionaries-common diffutils discover discover-data dmeventd dmidecode dmsetup dpkg dpkg-dev e2fslibs:amd64 e2fsprogs emacsen-common fail2ban fakeroot file findutils g++ g++-4.9 gawk gcc gcc-4.8-base:amd64 gcc-4.9 gcc-4.9-base:amd64 gettext-base git git-man gnupg gpgv grep groff-base grub-common grub-pc grub-pc-bin grub2-common gzip hostname htop iamerican ibritish ienglish-common ifupdown init init-system-helpers initramfs-tools initscripts insserv installation-report iproute2 iptables iputils-ping isc-dhcp-client isc-dhcp-common ispell javascript-common kbd keyboard-configuration klibc-utils kmod krb5-locales laptop-detect less libacl1:amd64 libalgorithm-c3-perl libalgorithm-diff-perl libalgorithm-diff-xs-perl libalgorithm-merge-perl libapr1:amd64 libaprutil1:amd64 libapt-inst1.5:amd64 libapt-pkg4.12:amd64 libarchive-extract-perl libasan1:amd64 libasprintf0c2:amd64 libatomic1:amd64 libattr1:amd64 libaudit-common libaudit1:amd64 libblkid1:amd64 libboost-iostreams1.55.0:amd64 libbsd0:amd64 libbz2-1.0:amd64 libc-bin libc-dev-bin libc6:amd64 libc6-dev:amd64 libcap2:amd64 libcap2-bin libcgi-fast-perl libcgi-pm-perl libcilkrts5:amd64 libclass-c3-perl libclass-c3-xs-perl libcloog-isl4:amd64 libcomerr2:amd64 libcpan-meta-perl libcryptsetup4:amd64 libcurl3:amd64 libcurl3-gnutls:amd64 libdata-optlist-perl libdata-section-perl libdb5.3:amd64 libdebconfclient0:amd64 libdevmapper-event1.02.1:amd64 libdevmapper1.02.1:amd64 libdiscover2 libdns-export100 libdpkg-perl libedit2:amd64 liberror-perl libestr0 libexpat1:amd64 libfakeroot:amd64 libfcgi-perl libffi6:amd64 libfile-fcntllock-perl libfreetype6:amd64 libfuse2:amd64 libgcc-4.9-dev:amd64 libgcc1:amd64 libgcrypt20:amd64 libgdbm3:amd64 libgmp10:amd64 libgnutls-deb0-28:amd64 libgnutls-openssl27:amd64 libgomp1:amd64 libgpg-error0:amd64 libgpm2:amd64 libgssapi-krb5-2:amd64 libhogweed2:amd64 libicu52:amd64 libidn11:amd64 libirs-export91 libisc-export95 libisccfg-export90 libisl10:amd64 libitm1:amd64 libjs-excanvas libjs-jquery libjs-sphinxdoc libjs-underscore libjson-c2:amd64 libk5crypto3:amd64 libkeyutils1:amd64 libklibc libkmod2:amd64 libkrb5-3:amd64 libkrb5support0:amd64 libldap-2.4-2:amd64 liblocale-gettext-perl liblog-message-perl liblog-message-simple-perl liblogging-stdlog0:amd64 liblognorm1:amd64 liblsan0:amd64 liblua5.2-0:amd64 liblvm2cmd2.02:amd64 liblzma5:amd64 libmagic1:amd64 libmnl0:amd64 libmodule-build-perl libmodule-pluggable-perl libmodule-signature-perl libmount1:amd64 libmpc3:amd64 libmpfr4:amd64 libmro-compat-perl libncurses5:amd64 libncurses5-dev:amd64 libncursesw5:amd64 libnetfilter-acct1:amd64 libnettle4:amd64 libnewt0.52:amd64 libnfnetlink0:amd64 libopts25:amd64 libp11-kit0:amd64 libpackage-constants-perl libpam-modules:amd64 libpam-modules-bin libpam-runtime libpam0g:amd64 libparams-util-perl libparted2:amd64 libpci3:amd64 libpcre3:amd64 libperl5.20 libpipeline1:amd64 libpng12-0:amd64 libpod-latex-perl libpod-readme-perl libpopt0:amd64 libprocps3:amd64 libpsl0:amd64 libpython-stdlib:amd64 libpython2.7:amd64 libpython2.7-minimal:amd64 libpython2.7-stdlib:amd64 libquadmath0:amd64 libreadline5:amd64 libreadline6:amd64 libregexp-common-perl librtmp1:amd64 libruby2.1:amd64 libsasl2-2:amd64 libsasl2-modules:amd64 libsasl2-modules-db:amd64 libselinux1:amd64 libsemanage-common libsemanage1:amd64 libsepol1:amd64 libserf-1-1:amd64 libsigc++-2.0-0c2a:amd64 libsigsegv2:amd64 libslang2:amd64 libsmartcols1:amd64 libsoftware-license-perl libsqlite3-0:amd64 libss2:amd64 libssh2-1:amd64 libssl-dev:amd64 libssl-doc libssl1.0.0:amd64 libstdc++-4.9-dev:amd64 libstdc++6:amd64 libsub-exporter-perl libsub-install-perl libsvn1:amd64 libsystemd0:amd64 libtasn1-6:amd64 libtcl8.6:amd64 libterm-ui-perl libtext-charwidth-perl libtext-iconv-perl libtext-soundex-perl libtext-template-perl libtext-wrapi18n-perl libtimedate-perl libtinfo-dev:amd64 libtinfo5:amd64 libtsan0:amd64 libubsan0:amd64 libudev1:amd64 libusb-0.1-4:amd64 libustr-1.0-1:amd64 libuuid-perl libuuid1:amd64 libwrap0:amd64 libx11-6:amd64 libx11-data libxau6:amd64 libxcb1:amd64 libxdmcp6:amd64 libxext6:amd64 libxmuu1:amd64 libxtables10 libyaml-0-2:amd64 linux-base linux-image-3.16.0-4-amd64 linux-image-amd64 linux-libc-dev:amd64 locales login logrotate lsb-base lsb-release lvm2 make man-db manpages manpages-dev mawk mercurial mercurial-common mime-support mount multiarch-support nano ncurses-base ncurses-bin ncurses-term net-tools netbase netcat-traditional nfacct ntp openssh-client openssh-server openssh-sftp-server openssl os-prober parted passwd patch pciutils perl perl-base perl-modules procps python python-cffi python-characteristic python-chardet python-colorama python-crypto python-cryptography python-dateutil python-decorator python-distlib python-html5lib python-jinja2 python-markupsafe python-migrate python-minimal python-ndg-httpsclient python-openssl python-pam python-pbr python-pip python-pkg-resources python-ply python-pyasn1 python-pyasn1-modules python-pycparser python-pyinotify python-requests python-serial python-service-identity python-setuptools python-six python-sqlalchemy python-sqlalchemy-ext python-support python-tempita python-twisted python-twisted-bin python-twisted-conch python-twisted-core python-twisted-lore python-twisted-mail python-twisted-names python-twisted-news python-twisted-runner python-twisted-web python-twisted-words python-urllib3 python-wheel python-zope.interface python2.7 python2.7-minimal readline-common rename rsync rsyslog screen sed sensible-utils startpar subversion systemd systemd-sysv sysv-rc sysvinit-utils tar task-english tasksel tasksel-data tcpd traceroute tzdata ucf udev unzip util-linux util-linux-locales vim-common vim-nox vim-runtime vim-tiny wamerican wget whiptail whois xauth xkb-data xz-utils zlib1g:amd64 zlib1g-dev:amd64

From drew at nixcores.com  Fri Jun 24 07:39:09 2016
From: drew at nixcores.com (Drew from NixCore)
Date: Fri, 24 Jun 2016 14:33:09 -0006
Subject: [LEDE-DEV] [PATCH] ramips: Add support for the NixCore X1
Message-ID: <1466779149.21604.0@mail.nixcores.com>

The NixCore X1 is a Ralink/MediaTek rt5350 WiFi Module

Patch submission with assistance from LD Pinney, using
simplier email client.

Signed-off-by: L. D. Pinney <ldpinney at gmail.com>
Signed-off-by: Drew Gaylo <drew at nixcore.com>
---

 target/linux/ramips/base-files/etc/board.d/02_network | 1 +
 target/linux/ramips/base-files/lib/ramips.sh | 3 +++
 target/linux/ramips/base-files/lib/upgrade/platform.sh | 1 +
 target/linux/ramips/dts/NIXCOREX1-16M.dts | 93 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 target/linux/ramips/dts/NIXCOREX1-8M.dts | 93 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 target/linux/ramips/image/rt305x.mk | 10 ++++++++
 target/linux/ramips/mt7628/config-4.4 | 7 ++++++
 target/linux/ramips/rt305x/profiles/nixcore.mk | 20 +++++++++++++++
 8 files changed, 228 insertions(+)

diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index dbb5fb4..5063ac8 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -77,6 +77,7 @@ ramips_setup_interfaces()
  mt7628|\
  mzk-750dhp|\
  mzk-w300nh2|\
+	nixcore|\
  oy-0001|\
  pbr-m1|\
  psg1208|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index 10139d7..b6ccd5a 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -322,6 +322,9 @@ ramips_board_detect() {
  *"NCS601W")
   name="ncs601w"
   ;;
+	*"NixcoreX1")
+	 name="nixcore-x1"
+	 ;;
  *"NW718")
   name="nw718"
   ;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index e3bea00..c4d3c01 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -95,6 +95,7 @@ platform_check_image() {
  mzk-w300nh2|\
  mzk-wdpr|\
  nbg-419n|\
+	nixcore|\
  nw718|\
  oy-0001|\
  pbr-m1|\
diff --git a/target/linux/ramips/dts/NIXCOREX1-16M.dts 
b/target/linux/ramips/dts/NIXCOREX1-16M.dts
new file mode 100644
index 0000000..7d2a6a1
--- /dev/null
+++ b/target/linux/ramips/dts/NIXCOREX1-16M.dts
@@ -0,0 +1,93 @@
+/dts-v1/;
+
+#include "rt5350.dtsi"
+
+/ {
+	compatible = "nixcorex1", "ralink,rt5350-soc";
+	model = "NixcoreX1";
+
+	chosen{
+	 bootargs = "console=ttyS1,57600";
+
+	 };
+	};
+
+&gpio0{
+	status = "okay";
+};
+
+&gpio1{
+	status = "okay";
+};
+
+&i2c{
+	status = "okay";
+};
+&uart{
+	status = "okay";
+	reset-names = "gpio uartf";
+};
+&spi0{
+	status = "okay";
+
+	m25p80 at 0 {
+	 #address-cells = <1>;
+	 #size-cells = <1>;
+	 compatible = "jedec,spi-nor";
+	 reg = <0>;
+	 linux,modalias = "m25p80";
+	 spi-max-frequency = <10000000>;
+
+	 partition at 0 {
+	 label = "uboot";
+	 reg = <0x0 0x30000>;
+	 read-only;
+	 };
+
+	 partition at 30000 {
+	 label = "uboot-env";
+	 reg = <0x30000 0x10000>;
+	 read-only;
+	 };
+
+	 factory: partition at 40000 {
+	 label = "factory";
+	 reg = <0x40000 0x10000>;
+	 read-only;
+	 };
+
+	 partition at 50000 {
+	 label = "firmware";
+	 reg = <0x50000 0xfb0000>;
+ };
+ };
+};
+
+&pinctrl {
+ state_default: pinctrl0 {
+ gpio {
+ ralink,group = "jtag", "led", "spi_cs1";
+ ralink,function = "gpio";
+ };
+ };
+};
+
+&ethernet {
+ mtd-mac-address = <&factory 0x4>;
+};
+
+&esw {
+ ralink,portmap = <0x17>;
+};
+
+&wmac {
+ ralink,mtd-eeprom = <&factory 0>;
+};
+
+&ehci {
+ status = "okay";
+};
+
+&ohci {
+ status = "okay";
+};
diff --git a/target/linux/ramips/dts/NIXCOREX1-8M.dts 
b/target/linux/ramips/dts/NIXCOREX1-8M.dts
new file mode 100644
index 0000000..dcfe73b
--- /dev/null
+++ b/target/linux/ramips/dts/NIXCOREX1-8M.dts
@@ -0,0 +1,93 @@
+/dts-v1/;
+
+#include "rt5350.dtsi"
+
+/ {
+	compatible = "nixcorex1", "ralink,rt5350-soc";
+	model = "NixcoreX1";
+
+	chosen{
+	 bootargs = "console=ttyS1,57600";
+
+	 };
+	};
+
+&gpio0{
+	status = "okay";
+};
+
+&gpio1{
+	status = "okay";
+};
+
+&i2c{
+	status = "okay";
+};
+&uart{
+	status = "okay";
+	reset-names = "gpio uartf";
+};
+&spi0{
+	status = "okay";
+
+	m25p80 at 0 {
+	 #address-cells = <1>;
+	 #size-cells = <1>;
+	 compatible = "jedec,spi-nor";
+	 reg = <0>;
+	 linux,modalias = "m25p80";
+	 spi-max-frequency = <10000000>;
+
+	 partition at 0 {
+	 label = "uboot";
+	 reg = <0x0 0x30000>;
+	 read-only;
+	 };
+
+	 partition at 30000 {
+	 label = "uboot-env";
+	 reg = <0x30000 0x10000>;
+	 read-only;
+	 };
+
+	 factory: partition at 40000 {
+	 label = "factory";
+	 reg = <0x40000 0x10000>;
+	 read-only;
+	 };
+
+	 partition at 50000 {
+	 label = "firmware";
+	 reg = <0x50000 0x7b0000>;
+ };
+ };
+};
+
+&pinctrl {
+ state_default: pinctrl0 {
+ gpio {
+ ralink,group = "jtag", "led", "spi_cs1";
+ ralink,function = "gpio";
+ };
+ };
+};
+
+&ethernet {
+ mtd-mac-address = <&factory 0x4>;
+};
+
+&esw {
+ ralink,portmap = <0x17>;
+};
+
+&wmac {
+ ralink,mtd-eeprom = <&factory 0>;
+};
+
+&ehci {
+ status = "okay";
+};
+
+&ohci {
+ status = "okay";
+};
diff --git a/target/linux/ramips/image/rt305x.mk 
b/target/linux/ramips/image/rt305x.mk
index da7fc46..6e7b71c 100644
--- a/target/linux/ramips/image/rt305x.mk
+++ b/target/linux/ramips/image/rt305x.mk
@@ -100,6 +100,16 @@ define BuildFirmware/HLKRM04/initramfs
  mkhilinkfw -e -i$(call imgname,$(1),$(2))-uImage.bin -o $(call 
imgname,$(1),$(2))-factory.bin;
 endef
 
+nixcore_8mb_mtd_size=8060928
+nixcore_16mb_mtd_size=16449536
+define BuildFirmware/NIXCORE/squashfs
+	$(call 
BuildFirmware/CustomFlash/$(1),$(1),$(2)-8M,$(3)-8M,$(nixcore_8mb_mtd_size))
+	$(call 
BuildFirmware/CustomFlash/$(1),$(1),$(2)-16M,$(3)-16M,$(nixcore_16mb_mtd_size))
+endef
+define BuildFirmware/NIXCORE/initramfs
+	$(call BuildFirmware/OF/initramfs,$(1),$(2)-8M,$(3)-8M)
+	$(call BuildFirmware/OF/initramfs,$(1),$(2)-16M,$(3)-16M)
+
 vocore_8mb_mtd_size=8060928
 vocore_16mb_mtd_size=16449536
 define BuildFirmware/VOCORE/squashfs
diff --git a/target/linux/ramips/rt305x/profiles/nixcore.mk 
b/target/linux/ramips/rt305x/profiles/nixcore.mk
new file mode 100644
index 0000000..54e13dc
--- /dev/null
+++ b/target/linux/ramips/rt305x/profiles/nixcore.mk
@@ -0,0 +1,20 @@
+#
+# Copyright (C) 2016 lede-project.org
+#
+# This is free software, licensed under the GNU General Public License 
v2.
+# See /LICENSE for more information.
+#
+
+define Profile/NIXCORE
+ NAME:=NixcoreX1
+ PACKAGES:=\
+ kmod-usb-core kmod-usb-ohci kmod-usb2 \
+ kmod-i2c-core kmod-i2c-ralink \
+ kmod-spi-dev
+endef
+
+define Profile/NIXCORE/Description
+ Package set for Nixcore X1 board
+endef
+
+$(eval $(call Profile,NIXCORE))





From john at phrozen.org  Fri Jun 24 07:51:22 2016
From: john at phrozen.org (John Crispin)
Date: Fri, 24 Jun 2016 16:51:22 +0200
Subject: [LEDE-DEV] [PATCH] ramips: Add support for the NixCore X1
In-Reply-To: <1466779149.21604.0@mail.nixcores.com>
References: <1466779149.21604.0@mail.nixcores.com>
Message-ID: <b3dfa766-eebd-65ed-d741-85d7115cf409@phrozen.org>



On 24/06/2016 16:39, Drew from NixCore wrote:
> The NixCore X1 is a Ralink/MediaTek rt5350 WiFi Module
> 
> Patch submission with assistance from LD Pinney, using
> simplier email client.
> 
> Signed-off-by: L. D. Pinney <ldpinney at gmail.com>
> Signed-off-by: Drew Gaylo <drew at nixcore.com>

Your email client has replaced all tabs with spaces in this version.

	John

> ---
> 
> target/linux/ramips/base-files/etc/board.d/02_network | 1 +
> target/linux/ramips/base-files/lib/ramips.sh | 3 +++
> target/linux/ramips/base-files/lib/upgrade/platform.sh | 1 +
> target/linux/ramips/dts/NIXCOREX1-16M.dts | 93
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> target/linux/ramips/dts/NIXCOREX1-8M.dts | 93
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> target/linux/ramips/image/rt305x.mk | 10 ++++++++
> target/linux/ramips/mt7628/config-4.4 | 7 ++++++
> target/linux/ramips/rt305x/profiles/nixcore.mk | 20 +++++++++++++++
> 8 files changed, 228 insertions(+)
> 
> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
> b/target/linux/ramips/base-files/etc/board.d/02_network
> index dbb5fb4..5063ac8 100755
> --- a/target/linux/ramips/base-files/etc/board.d/02_network
> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
> @@ -77,6 +77,7 @@ ramips_setup_interfaces()
>  mt7628|\
>  mzk-750dhp|\
>  mzk-w300nh2|\
> +    nixcore|\
>  oy-0001|\
>  pbr-m1|\
>  psg1208|\
> diff --git a/target/linux/ramips/base-files/lib/ramips.sh
> b/target/linux/ramips/base-files/lib/ramips.sh
> index 10139d7..b6ccd5a 100755
> --- a/target/linux/ramips/base-files/lib/ramips.sh
> +++ b/target/linux/ramips/base-files/lib/ramips.sh
> @@ -322,6 +322,9 @@ ramips_board_detect() {
>  *"NCS601W")
>   name="ncs601w"
>   ;;
> +    *"NixcoreX1")
> +     name="nixcore-x1"
> +     ;;
>  *"NW718")
>   name="nw718"
>   ;;
> diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh
> b/target/linux/ramips/base-files/lib/upgrade/platform.sh
> index e3bea00..c4d3c01 100755
> --- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
> @@ -95,6 +95,7 @@ platform_check_image() {
>  mzk-w300nh2|\
>  mzk-wdpr|\
>  nbg-419n|\
> +    nixcore|\
>  nw718|\
>  oy-0001|\
>  pbr-m1|\
> diff --git a/target/linux/ramips/dts/NIXCOREX1-16M.dts
> b/target/linux/ramips/dts/NIXCOREX1-16M.dts
> new file mode 100644
> index 0000000..7d2a6a1
> --- /dev/null
> +++ b/target/linux/ramips/dts/NIXCOREX1-16M.dts
> @@ -0,0 +1,93 @@
> +/dts-v1/;
> +
> +#include "rt5350.dtsi"
> +
> +/ {
> +    compatible = "nixcorex1", "ralink,rt5350-soc";
> +    model = "NixcoreX1";
> +
> +    chosen{
> +     bootargs = "console=ttyS1,57600";
> +
> +     };
> +    };
> +
> +&gpio0{
> +    status = "okay";
> +};
> +
> +&gpio1{
> +    status = "okay";
> +};
> +
> +&i2c{
> +    status = "okay";
> +};
> +&uart{
> +    status = "okay";
> +    reset-names = "gpio uartf";
> +};
> +&spi0{
> +    status = "okay";
> +
> +    m25p80 at 0 {
> +     #address-cells = <1>;
> +     #size-cells = <1>;
> +     compatible = "jedec,spi-nor";
> +     reg = <0>;
> +     linux,modalias = "m25p80";
> +     spi-max-frequency = <10000000>;
> +
> +     partition at 0 {
> +     label = "uboot";
> +     reg = <0x0 0x30000>;
> +     read-only;
> +     };
> +
> +     partition at 30000 {
> +     label = "uboot-env";
> +     reg = <0x30000 0x10000>;
> +     read-only;
> +     };
> +
> +     factory: partition at 40000 {
> +     label = "factory";
> +     reg = <0x40000 0x10000>;
> +     read-only;
> +     };
> +
> +     partition at 50000 {
> +     label = "firmware";
> +     reg = <0x50000 0xfb0000>;
> + };
> + };
> +};
> +
> +&pinctrl {
> + state_default: pinctrl0 {
> + gpio {
> + ralink,group = "jtag", "led", "spi_cs1";
> + ralink,function = "gpio";
> + };
> + };
> +};
> +
> +&ethernet {
> + mtd-mac-address = <&factory 0x4>;
> +};
> +
> +&esw {
> + ralink,portmap = <0x17>;
> +};
> +
> +&wmac {
> + ralink,mtd-eeprom = <&factory 0>;
> +};
> +
> +&ehci {
> + status = "okay";
> +};
> +
> +&ohci {
> + status = "okay";
> +};
> diff --git a/target/linux/ramips/dts/NIXCOREX1-8M.dts
> b/target/linux/ramips/dts/NIXCOREX1-8M.dts
> new file mode 100644
> index 0000000..dcfe73b
> --- /dev/null
> +++ b/target/linux/ramips/dts/NIXCOREX1-8M.dts
> @@ -0,0 +1,93 @@
> +/dts-v1/;
> +
> +#include "rt5350.dtsi"
> +
> +/ {
> +    compatible = "nixcorex1", "ralink,rt5350-soc";
> +    model = "NixcoreX1";
> +
> +    chosen{
> +     bootargs = "console=ttyS1,57600";
> +
> +     };
> +    };
> +
> +&gpio0{
> +    status = "okay";
> +};
> +
> +&gpio1{
> +    status = "okay";
> +};
> +
> +&i2c{
> +    status = "okay";
> +};
> +&uart{
> +    status = "okay";
> +    reset-names = "gpio uartf";
> +};
> +&spi0{
> +    status = "okay";
> +
> +    m25p80 at 0 {
> +     #address-cells = <1>;
> +     #size-cells = <1>;
> +     compatible = "jedec,spi-nor";
> +     reg = <0>;
> +     linux,modalias = "m25p80";
> +     spi-max-frequency = <10000000>;
> +
> +     partition at 0 {
> +     label = "uboot";
> +     reg = <0x0 0x30000>;
> +     read-only;
> +     };
> +
> +     partition at 30000 {
> +     label = "uboot-env";
> +     reg = <0x30000 0x10000>;
> +     read-only;
> +     };
> +
> +     factory: partition at 40000 {
> +     label = "factory";
> +     reg = <0x40000 0x10000>;
> +     read-only;
> +     };
> +
> +     partition at 50000 {
> +     label = "firmware";
> +     reg = <0x50000 0x7b0000>;
> + };
> + };
> +};
> +
> +&pinctrl {
> + state_default: pinctrl0 {
> + gpio {
> + ralink,group = "jtag", "led", "spi_cs1";
> + ralink,function = "gpio";
> + };
> + };
> +};
> +
> +&ethernet {
> + mtd-mac-address = <&factory 0x4>;
> +};
> +
> +&esw {
> + ralink,portmap = <0x17>;
> +};
> +
> +&wmac {
> + ralink,mtd-eeprom = <&factory 0>;
> +};
> +
> +&ehci {
> + status = "okay";
> +};
> +
> +&ohci {
> + status = "okay";
> +};
> diff --git a/target/linux/ramips/image/rt305x.mk
> b/target/linux/ramips/image/rt305x.mk
> index da7fc46..6e7b71c 100644
> --- a/target/linux/ramips/image/rt305x.mk
> +++ b/target/linux/ramips/image/rt305x.mk
> @@ -100,6 +100,16 @@ define BuildFirmware/HLKRM04/initramfs
>  mkhilinkfw -e -i$(call imgname,$(1),$(2))-uImage.bin -o $(call
> imgname,$(1),$(2))-factory.bin;
> endef
> 
> +nixcore_8mb_mtd_size=8060928
> +nixcore_16mb_mtd_size=16449536
> +define BuildFirmware/NIXCORE/squashfs
> +    $(call
> BuildFirmware/CustomFlash/$(1),$(1),$(2)-8M,$(3)-8M,$(nixcore_8mb_mtd_size))
> 
> +    $(call
> BuildFirmware/CustomFlash/$(1),$(1),$(2)-16M,$(3)-16M,$(nixcore_16mb_mtd_size))
> 
> +endef
> +define BuildFirmware/NIXCORE/initramfs
> +    $(call BuildFirmware/OF/initramfs,$(1),$(2)-8M,$(3)-8M)
> +    $(call BuildFirmware/OF/initramfs,$(1),$(2)-16M,$(3)-16M)
> +
> vocore_8mb_mtd_size=8060928
> vocore_16mb_mtd_size=16449536
> define BuildFirmware/VOCORE/squashfs
> diff --git a/target/linux/ramips/rt305x/profiles/nixcore.mk
> b/target/linux/ramips/rt305x/profiles/nixcore.mk
> new file mode 100644
> index 0000000..54e13dc
> --- /dev/null
> +++ b/target/linux/ramips/rt305x/profiles/nixcore.mk
> @@ -0,0 +1,20 @@
> +#
> +# Copyright (C) 2016 lede-project.org
> +#
> +# This is free software, licensed under the GNU General Public License v2.
> +# See /LICENSE for more information.
> +#
> +
> +define Profile/NIXCORE
> + NAME:=NixcoreX1
> + PACKAGES:=\
> + kmod-usb-core kmod-usb-ohci kmod-usb2 \
> + kmod-i2c-core kmod-i2c-ralink \
> + kmod-spi-dev
> +endef
> +
> +define Profile/NIXCORE/Description
> + Package set for Nixcore X1 board
> +endef
> +
> +$(eval $(call Profile,NIXCORE))
> 
> 
> 
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


From eschultz at prplfoundation.org  Fri Jun 24 13:02:50 2016
From: eschultz at prplfoundation.org (Eric Schultz)
Date: Fri, 24 Jun 2016 15:02:50 -0500
Subject: [LEDE-DEV] OpenWrt & TR-069 F2F Meeting Agenda
Message-ID: <576D91EA.6020507@prplfoundation.org>

All,

I was hoping the meeting attendees, and the community, could provide
some feedback  about the agenda of the in-person OpenWrt & TR-069
Meeting. I've created an initial agenda but I'm sure I've missed things
or topics we need to discuss. If you'd like to provide feedback
(especially if you're attending) please leave comments on the linked
Google Docs. In particular, we need:

* Suggestions for OPEN meeting slots
* Session leaders for meeting slots marked as OPEN
* Suggestions for improvements to meeting topics, tweaks, etc.

The time slots I've proposed are pretty flexible and a rough estimate.
I'm sure some sessions will go long and some will be shorter. Once we
get there, we may see some need for adjustments as well.

Anyways, the Google Doc is at
https://docs.google.com/document/d/1IhAd3NLes3r3llV3mep6-YAhIzRElell_f97C-2pIPw/edit?usp=sharing

--
Of note to the broader community, I'll be writing up a short summary of
the topics discussed and any conclusions of the participants at the
meeting. I intend to email these lists on Tuesday evening so folks can
have a chance to give feedback. I think the summary will be rather
limited simply due to time but we'll try to manage. The meeting
attendees will review any feedback received the next morning.
Additionally, I'll send a wrap-up summary on Wednesday evening. If there
are any other online documents or notes that are shared during the
event, I'll make sure to post links to them to the lists.

Thanks,

Eric

-- 
Eric Schultz, Community Manager, prpl Foundation
http://www.prplfoundation.org
eschultz at prplfoundation.org <mailto:eschultz at prplfoundation.org>
cell: 920-539-0404
skype: ericschultzwi
@EricPrpl


From david at lang.hm  Fri Jun 24 13:21:52 2016
From: david at lang.hm (David Lang)
Date: Fri, 24 Jun 2016 13:21:52 -0700 (PDT)
Subject: [LEDE-DEV] trying to cover costs on my bit of the build cluster
In-Reply-To: <6af4d658-ebeb-9768-ef96-9ad0001cb7a4@mein.io>
References: <CAA93jw4wmDxgGkduwAamUu7JnxnEVw4XwwAwQDjAGVp9fMda3w@mail.gmail.com>
 <be851007-3982-4621-5443-d742fdf28191@mein.io>
 <20160624120527.GO22807@medion.lan>
 <6af4d658-ebeb-9768-ef96-9ad0001cb7a4@mein.io>
Message-ID: <alpine.DEB.2.02.1606241320180.2687@nftneq.ynat.uz>

On Fri, 24 Jun 2016, Jo-Philipp Wich wrote:

> Hi Bastian,
>
> the usual approach is the following:
>
> - Install "buildbot-slave", on Debian/Ubuntu this is as easy as running
>  "apt-get install buildbot-slave"
> - Install remaining packages required for build, I attached the package
>  list exported from one of our slaves
> - Setup a slave and point it to our master (replace "myslave" and
>  "mypassword"):
>  $ buildbot create-slave --umask=022 /var/lib/buildbot/slaves/myslave \
>      builds.lede-project.org:9990 myslave mypassword
>  $ chown -R buildbot:nogroup /var/lib/buildbot/slaves/myslave
> - Adjust /etc/default/buildslave (mainly set enabled to 1, and adjust
>  basedir, leave options and prefixcmd empty)
> - Send me the name and the password offlist so I can register the slave
>
> Builds will require between 30 and 40GB of storage. No externally
> reachable ports are required, the slave will pull and push the required
> files itself.

How do we set how much work it does? (or is this only good for a dedicated slave 
and you use cgroups or similar to limit a container/vm)

I think a lot of people would be willing to contribute some percentage of a 
system, a smaller group can contribute entire systems.

David Lang


From nbd at nbd.name  Sun Jun 26 03:52:05 2016
From: nbd at nbd.name (Felix Fietkau)
Date: Sun, 26 Jun 2016 12:52:05 +0200
Subject: [LEDE-DEV] [PATCH] Support Candela-Tech ath10k and ath9k
 out-of-tree driver.
In-Reply-To: <1466546417-19907-1-git-send-email-greearb@candelatech.com>
References: <1466546417-19907-1-git-send-email-greearb@candelatech.com>
Message-ID: <10ff529c-6d18-d653-1172-2f24948f0bab@nbd.name>

On 2016-06-22 00:00, greearb at candelatech.com wrote:
> From: Ben Greear <greearb at candelatech.com>
> 
> This lets one use the ath9k and ath10k driver instead of the built-in
> ath10k/ath9k driver from the upstream kernel (or backports).
> 
> For ath10k, this should be a drop-in replacement, as well as enabling
> better CT firmware support.
> 
> For ath9k, this enables some 5Mhz channel and 4.9Ghz support,
> but may loose some existing patches that LEDE carries for ath9k.
> 
> Signed-off-by: Ben Greear <greearb at candelatech.com>
I would really like to have this use kmod-ath from the main mac80211
patches in order to support using ath9k from the main package along with
ath10k-ct.
The packagea at least it needs a split between the ath9k and ath10k parts.

- Felix


From nbd at nbd.name  Sun Jun 26 04:00:52 2016
From: nbd at nbd.name (Felix Fietkau)
Date: Sun, 26 Jun 2016 13:00:52 +0200
Subject: [LEDE-DEV] [PATCH libubox v2 3/3] blobmsg_json: add new
 functions blobmsg_format_json_value*
In-Reply-To: <fbb2189048a98cc34efaad03f91709935739cee2.1466522197.git.mschiffer@universe-factory.net>
References: <cc8bcc58421ebdbf8e65cef24e8eeb0dd4b1e510.1466522197.git.mschiffer@universe-factory.net>
 <fbb2189048a98cc34efaad03f91709935739cee2.1466522197.git.mschiffer@universe-factory.net>
Message-ID: <f563c86f-f887-9411-fc5b-5a6b268fcba1@nbd.name>

On 2016-06-21 17:19, Matthias Schiffer wrote:
> The current blobmsg_format_json* functions will return invalid JSON when
> the "list" argument is given as false (blobmsg_format_element() will
> output the name of the blob_attr as if the value is printed as part of a
> JSON object).
> 
> To avoid breaking software relying on this behaviour, introduce new
> functions which will never print the blob_attr name and thus always
> produce valid JSON.
> 
> Signed-off-by: Matthias Schiffer <mschiffer at universe-factory.net>
> ---
> v2: no changes
> 
>  blobmsg_json.c | 61 ++++++++++++++++++++++++++++++++++++++++++++--------------
>  blobmsg_json.h | 14 ++++++++++++++
>  2 files changed, 61 insertions(+), 14 deletions(-)
> 
> diff --git a/blobmsg_json.c b/blobmsg_json.c
> index 2e318b2..78747d1 100644
> --- a/blobmsg_json.c
> +++ b/blobmsg_json.c
> @@ -293,27 +293,30 @@ static void blobmsg_format_json_list(struct strbuf *s, struct blob_attr *attr, i
>  	blobmsg_puts(s, (array ? "]" : "}"), 1);
>  }
>  
> +static void setup_strbuf(struct strbuf *s, struct blob_attr *attr, blobmsg_json_format_t cb, void *priv, int indent) {
The '{' should go on the next line.

> @@ -337,3 +340,33 @@ char *blobmsg_format_json_with_cb(struct blob_attr *attr, bool list, blobmsg_jso
>  
>  	return ret;
>  }
> +
> +char *blobmsg_format_json_value_with_cb(struct blob_attr *attr, blobmsg_json_format_t cb, void *priv, int indent)
> +{
> +	struct strbuf s;
> +	char *ret;
> +
> +	setup_strbuf(&s, attr, cb, priv, indent);
> +	if (!s.buf)
> +		return NULL;
> +
> +	blobmsg_format_element(&s, attr, true, false);
> +
> +	if (!s.len) {
> +		free(s.buf);
> +		return NULL;
> +	}
> +
> +	s.buf = realloc(s.buf, s.pos + 1);
> +	s.buf[s.pos] = 0;
> +
> +	ret = realloc(s.buf, s.pos + 1);
The double realloc looks bogus to me.

- Felix


From nbd at nbd.name  Sun Jun 26 04:40:09 2016
From: nbd at nbd.name (Felix Fietkau)
Date: Sun, 26 Jun 2016 13:40:09 +0200
Subject: [LEDE-DEV] [PATCH] Support Candela-Tech ath10k and ath9k
 out-of-tree driver.
In-Reply-To: <576FBCF8.7090900@candelatech.com>
References: <1466546417-19907-1-git-send-email-greearb@candelatech.com>
 <10ff529c-6d18-d653-1172-2f24948f0bab@nbd.name>
 <576FBCF8.7090900@candelatech.com>
Message-ID: <1b08c93a-c5e1-da3b-3a34-1c272dcffcc5@nbd.name>

On 2016-06-26 13:31, Ben Greear wrote:
> On 06/26/2016 03:52 AM, Felix Fietkau wrote:
>> On 2016-06-22 00:00, greearb at candelatech.com wrote:
>>> From: Ben Greear <greearb at candelatech.com>
>>>
>>> This lets one use the ath9k and ath10k driver instead of the built-in
>>> ath10k/ath9k driver from the upstream kernel (or backports).
>>>
>>> For ath10k, this should be a drop-in replacement, as well as enabling
>>> better CT firmware support.
>>>
>>> For ath9k, this enables some 5Mhz channel and 4.9Ghz support,
>>> but may loose some existing patches that LEDE carries for ath9k.
>>>
>>> Signed-off-by: Ben Greear <greearb at candelatech.com>
>> I would really like to have this use kmod-ath from the main mac80211
>> patches in order to support using ath9k from the main package along with
>> ath10k-ct.
>> The packagea at least it needs a split between the ath9k and ath10k parts.
> 
> That sounds good to me.  I'm mostly interested in ath10k at this point...probably
> any ath9k changes could just be applied as patches instead of a fully external
> driver.
> 
> I guess I need to change any 'include "../foo.h" to <foo.h> and then somehow fix
> the make command to point to the backports tree?
We could also export any relevant header files from the mac80211 package
and make your package copy them into the tree (and then not build the
ath module).

> Any suggestions on how to better sync with kernel compile options?  Seems ath10k
> has a lot of different CONFIG* options.  I hard-coded some in the make-file, but
> I am guessing that is fragile at best.
We can export backport-include/backport/autoconf.h from the mac80211
package. From C code context you can use all the non-ath10k-specific
options from there, e.g. CONFIG_ATH_DEBUG.
Any other options should probably be defined like in the mac80211
package (though with different config symbol names to prevent conflicts).

> If you have time to help with a bit of whatever is needed to get it properly linking/compiling
> against the proper code, I can work on making the build actually work.
Sure, no problem.

- Felix


From greearb at candelatech.com  Sun Jun 26 04:31:04 2016
From: greearb at candelatech.com (Ben Greear)
Date: Sun, 26 Jun 2016 04:31:04 -0700
Subject: [LEDE-DEV] [PATCH] Support Candela-Tech ath10k and ath9k
 out-of-tree driver.
In-Reply-To: <10ff529c-6d18-d653-1172-2f24948f0bab@nbd.name>
References: <1466546417-19907-1-git-send-email-greearb@candelatech.com>
 <10ff529c-6d18-d653-1172-2f24948f0bab@nbd.name>
Message-ID: <576FBCF8.7090900@candelatech.com>

On 06/26/2016 03:52 AM, Felix Fietkau wrote:
> On 2016-06-22 00:00, greearb at candelatech.com wrote:
>> From: Ben Greear <greearb at candelatech.com>
>>
>> This lets one use the ath9k and ath10k driver instead of the built-in
>> ath10k/ath9k driver from the upstream kernel (or backports).
>>
>> For ath10k, this should be a drop-in replacement, as well as enabling
>> better CT firmware support.
>>
>> For ath9k, this enables some 5Mhz channel and 4.9Ghz support,
>> but may loose some existing patches that LEDE carries for ath9k.
>>
>> Signed-off-by: Ben Greear <greearb at candelatech.com>
> I would really like to have this use kmod-ath from the main mac80211
> patches in order to support using ath9k from the main package along with
> ath10k-ct.
> The packagea at least it needs a split between the ath9k and ath10k parts.

That sounds good to me.  I'm mostly interested in ath10k at this point...probably
any ath9k changes could just be applied as patches instead of a fully external
driver.

I guess I need to change any 'include "../foo.h" to <foo.h> and then somehow fix
the make command to point to the backports tree?

Any suggestions on how to better sync with kernel compile options?  Seems ath10k
has a lot of different CONFIG* options.  I hard-coded some in the make-file, but
I am guessing that is fragile at best.

If you have time to help with a bit of whatever is needed to get it properly linking/compiling
against the proper code, I can work on making the build actually work.

Thanks,
Ben


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



From dgilman at gilslotd.com  Sun Jun 26 15:40:54 2016
From: dgilman at gilslotd.com (David Gilman)
Date: Sun, 26 Jun 2016 17:40:54 -0500
Subject: [LEDE-DEV] Kirkwood Audi U-Boot fw_setenv errors
Message-ID: <20160626224054.GA50866@dar.local>

Claudio, I have a Kirkwood EA3500 (Audi) board and it seems that at some
point the patches for this board have regressed the uboot fw_setenv
utility and semi-bricked my machine.  I've been digging into this issue
and I suspect there was some value missed somewhere but I would like to
hear some feedback from you and am willing to dig around on this box to
help you troubleshoot the issue.

I find it pretty tricky to time the dual firmware resetting feature in
the board's uboot (I think I've gotten it to work for me once...) so I
prefer to set the uboot variables directly to switch what partition I'm
booting from.  When I do so with a `fw_setenv boot_part 1':

Read error on /dev/mtd1: No error information
Error: can't write fw_env to flash

At one point I think this worked, but I'm not sure when it regressed.
The "No error information" is from an errno of 0, so the read worked,
but uboot bailed out anyway.  I ran the utility under strace:

_llseek(4, 0, [0], SEEK_SET)            = 0
read(4, "7b\23\200bootdelay=0\0baudrate=115200\0"..., 131072) = 16384
writev(2, [{"Read error on /dev/mtd1: No erro"..., 46}, {NULL, 0}], 2) = 46
close(4)                                = 0
writev(2, [{"", 0}, {"Error: can't write fw_env to fla"..., 35}], 2) = 35

The read() there returned 16384 (0x4000) although we asked it for 131072
bytes (0x20000).  That is why fw_setenv fails, if you look at the source
code inside uboot it bails out like this when those two aren't equal.
For reference, this is fw_env.c line 734 in uboot:

https://github.com/trini/u-boot/blob/master/tools/env/fw_env.c#L734

The 0x20000 argument comes from CUR_ENVSIZE which is where I lose the
trail on where these magic numbers are coming from.  However, I am
seeing these magic numbers in a patch you authored: "kirkwood: rework
Linksys EA[34]500 DTS".  If you look at the diff there, you'll see those
magic numbers 0x4000 and 0x20000 popping up again.  So I am not sure
what's the way to go forward here but at the moment I can't write to any
flash (to change uboot variables or flash a new root partition) so I am
sort of stuck.

-- 
David Gilman  :DG<
http://gilslotd.com


From leitec at gmail.com  Sun Jun 26 16:07:58 2016
From: leitec at gmail.com (Claudio Leite)
Date: Sun, 26 Jun 2016 19:07:58 -0400
Subject: [LEDE-DEV] Kirkwood Audi U-Boot fw_setenv errors
In-Reply-To: <20160626224054.GA50866@dar.local>
References: <20160626224054.GA50866@dar.local>
Message-ID: <20160626230758.GB6626@pratt.mine.nu>

Hello David,

* David Gilman (dgilman at gilslotd.com) wrote:
> Claudio, I have a Kirkwood EA3500 (Audi) board and it seems that at some
> point the patches for this board have regressed the uboot fw_setenv
> utility and semi-bricked my machine.  I've been digging into this issue
> and I suspect there was some value missed somewhere but I would like to
> hear some feedback from you and am willing to dig around on this box to
> help you troubleshoot the issue.
> 
> I find it pretty tricky to time the dual firmware resetting feature in
> the board's uboot (I think I've gotten it to work for me once...) so I
> prefer to set the uboot variables directly to switch what partition I'm
> booting from.  When I do so with a `fw_setenv boot_part 1':
> 
> Read error on /dev/mtd1: No error information
> Error: can't write fw_env to flash
> 
> At one point I think this worked, but I'm not sure when it regressed.
> The "No error information" is from an errno of 0, so the read worked,
> but uboot bailed out anyway.  I ran the utility under strace:
> 
> _llseek(4, 0, [0], SEEK_SET)            = 0
> read(4, "7b\23\200bootdelay=0\0baudrate=115200\0"..., 131072) = 16384
> writev(2, [{"Read error on /dev/mtd1: No erro"..., 46}, {NULL, 0}], 2) = 46
> close(4)                                = 0
> writev(2, [{"", 0}, {"Error: can't write fw_env to fla"..., 35}], 2) = 35
> 
> The read() there returned 16384 (0x4000) although we asked it for 131072
> bytes (0x20000).  That is why fw_setenv fails, if you look at the source
> code inside uboot it bails out like this when those two aren't equal.

What does your /etc/fw_env.config look like? Did you perhaps restore a
saved config backup at some point which could've contained that file?

It should look like:

/dev/mtd1 0x0 0x4000 0x4000

If I change the last value to 0x20000 (which would've been the correct
size on the previous partition layout) I get the same error:

root at ea3500:/etc# fw_setenv blah test
Read error on /dev/mtd1: No error information
Error: can't write fw_env to flash
root at ea3500:/etc# 

> For reference, this is fw_env.c line 734 in uboot:
> 
> https://github.com/trini/u-boot/blob/master/tools/env/fw_env.c#L734
> 
> The 0x20000 argument comes from CUR_ENVSIZE which is where I lose the
> trail on where these magic numbers are coming from.  However, I am
> seeing these magic numbers in a patch you authored: "kirkwood: rework
> Linksys EA[34]500 DTS".  If you look at the diff there, you'll see those
> magic numbers 0x4000 and 0x20000 popping up again.  So I am not sure
> what's the way to go forward here but at the moment I can't write to any
> flash (to change uboot variables or flash a new root partition) so I am
> sort of stuck.

The change was due to the changed size of the u_env partition after the
re-work. The previous dts had a much larger u_env partition, sized at
0x20000 despite the env taking up just the first 0x4000 bytes.

(0x4000 is also the erasesize for the flash chip)

I resized them to match the factory firmware's idea and to allow access
to the s_env partition, which was previously contained within the
oversized u_env.

-Claudio


From dgilman at gilslotd.com  Sun Jun 26 20:29:55 2016
From: dgilman at gilslotd.com (David Gilman)
Date: Sun, 26 Jun 2016 22:29:55 -0500
Subject: [LEDE-DEV] Kirkwood Audi U-Boot fw_setenv errors
In-Reply-To: <20160626230758.GB6626@pratt.mine.nu>
References: <20160626224054.GA50866@dar.local>
 <20160626230758.GB6626@pratt.mine.nu>
Message-ID: <20160627032955.GA51300@dar.local>

On Sun, Jun 26, 2016 at 07:07:58PM -0400, Claudio Leite wrote:
> 
> What does your /etc/fw_env.config look like? Did you perhaps restore a
> saved config backup at some point which could've contained that file?
> 
> It should look like:
> 
> /dev/mtd1 0x0 0x4000 0x4000

Your intuition was dead on here.  I updated the file and was able to set
firmware variables again.  Thanks for the speedy reply.

-- 
David Gilman  :DG<
http://gilslotd.com


From chunkeey at googlemail.com  Sat Jun 25 12:26:48 2016
From: chunkeey at googlemail.com (Christian Lamparter)
Date: Sat, 25 Jun 2016 21:26:48 +0200
Subject: [LEDE-DEV] [PATCH RFC v3 3/3] ath9k: parse the device
	configuration from an OF node
In-Reply-To: <CAFBinCBtjv4XoUyO6007hs0Aiut-mFxeq9jdEBq9d22dqzTvLw@mail.gmail.com>
References: <20160624123430.4097-1-martin.blumenstingl@googlemail.com>
 <2421107.Vh3zsAgVDf@debian64>
 <CAFBinCBtjv4XoUyO6007hs0Aiut-mFxeq9jdEBq9d22dqzTvLw@mail.gmail.com>
Message-ID: <1973511.3caevZ3pSB@debian64>

On Saturday, June 25, 2016 05:08:29 PM Martin Blumenstingl wrote:
> On Sat, Jun 25, 2016 at 2:01 PM, Christian Lamparter
> <chunkeey at googlemail.com> wrote:
> > On Friday, June 24, 2016 02:34:30 PM Martin Blumenstingl wrote:
> >> This makes it possible to configure ath9k based devices using
> >> devicetree. That makes some out-of-tree "convert devicetree to
> >> ath9k_platform_data glue"-code obsolete.
> >
> > Hm, what about the embedded ath9k pcie chips that need the early
> > pci-fixup routine for the device to work properly [0], [1]? How
> > will this be handled/integrated? I know that the ar71xx and the
> > lantiq platforms use similar pci-fixup routines that need a few
> > bytes from the eeprom/cal data. So lantiq has a few extra properties:
> > "ath,pci-slot", "ath,device-id" and "ath,eep-flash".
> that is exactly the use-case I want to use your owl-loader for (see
> [0], it's a small kernel module which adds the PCI configuration for
> ath9k devices).
Well, we also cooked up a userspace hack for OpenWRT/LEDE which would
work with the existing code (for the case you mentioned below) [2]. 
Furthermore it also works for other devices, as long as the fw is in
/lib/firmware and not in a subdirectory (But this can be fixed in 5
minutes with better bash foo). One thing that needs to be considered
though: That script interferes with procd firmware loading if the
"timing" is right. However usually procd has already finished all
firmware requests by then.

> This makes ath,pci-slot and ath,eep-flash obsolete.
> As far as I'm aware ath,device-id is a bit of a special case (mtd_read
> issues when the caldata is stored at an unaligned position on NOR
> flash). So this might be obsolete as well when using owl-loader.

The problem with the owl-loader is/was that it sticks around
when it has initialized all the cards. Unloading a module by
itself is tough. One way out would be to add it to ath9k's pci.c.
The question is: will such a feature have support from the ath9k
folks?

> > As an example: the AR9280 in the Cisco Z1 AP is initially
> > 0x168c:0xff1f (<-- ath9k doesn't know about that id). The
> > pci-fixup routine will change it to  0x168c:0x002A. Only
> > then ath9k can take it over and will initialize it.
> > Thing is: this is all currently done by platform code for
> > those architectures... And currently, the request_firmware
> > doesn't work for caldata on UBI partitions.
> request_firmware is working on UBI partitions in many cases.
> It's just not working when request_firmware is called too early (and
> this is not UBI specific, other filesystems might be affected as
> well): if it is called before rootfs is mounted (which is the case
> when you call it from a PCI fixup function) then it's not working
> (like you said).
> The "solution" to this is to compile the driver as kernel module (once
> this is loadable everything else should be readable as well).
> Not only ath9k is affected by this "issue", this is simply a
> limitation of request_firmware and/or the linux boot chain.
> 
> A few words regarding your owl-loader:
> First of all I would like to say "thank you"!
> Mathias and I are working on changing the lantiq target in LEDE to use
> owl-loader for all (ath9k) devices.
> All I had to do was to add another OWL PCI ID, implement a fallback
> for the firmware filename when there is no ath9k_platform_data (I'm
> using the same pattern as in PATCH 3/3 in this series). You can find
> the WIP code here: [1]

I've added lede-dev and Luis since this is relevant for them.
Maybe between the sysloadfw.sh and owl-loader, there's another
solution we overlooked so far? I know Luis has been digging
around in the firmware_class and added the sysdata API. But
from what I can tell, this would ?break? LEDE/OpenWRT's
userspace helper, since the sysfs interface in 
/sys/class/firmware which is used by procd to upload the data
is gone with sysdata or am I wrong?
 
Regards,
Christian

> [0] https://patchwork.ozlabs.org/patch/607682/
> [1] https://github.com/xdarklight/source/commits/ath9k-owl-loader-20160624
[2] <https://github.com/riptidewave93/Openwrt-Z1/commit/9a38c60a1206b4010fbfb626fc7b2ec69bbe232a>


From martin.blumenstingl at googlemail.com  Sun Jun 26 16:38:43 2016
From: martin.blumenstingl at googlemail.com (Martin Blumenstingl)
Date: Mon, 27 Jun 2016 01:38:43 +0200
Subject: [LEDE-DEV] [PATCH RFC v3 3/3] ath9k: parse the device
 configuration from an OF node
In-Reply-To: <1973511.3caevZ3pSB@debian64>
References: <20160624123430.4097-1-martin.blumenstingl@googlemail.com>
 <2421107.Vh3zsAgVDf@debian64>
 <CAFBinCBtjv4XoUyO6007hs0Aiut-mFxeq9jdEBq9d22dqzTvLw@mail.gmail.com>
 <1973511.3caevZ3pSB@debian64>
Message-ID: <CAFBinCAh+mdG3Lh6+aS2oAZXxhuapSf34eDfxgUjmCSvWeg-fw@mail.gmail.com>

On Sat, Jun 25, 2016 at 9:26 PM, Christian Lamparter
<chunkeey at googlemail.com> wrote:
> The problem with the owl-loader is/was that it sticks around
> when it has initialized all the cards. Unloading a module by
> itself is tough. One way out would be to add it to ath9k's pci.c.
> The question is: will such a feature have support from the ath9k
> folks?
owl-loader seems very small (<7KiB) and it only allocates a few bytes
dynamically. Even if you move this code to ath9k you will still have
the same problem: as long as ath9k is not unloaded this code will hang
around in memory.
But apart from this - moving it to the kernel might have some benefits
though as it could be shared between ath9k and ath5k (as some ath5k
seem to require a similar "fixup" as well).

> I've added lede-dev and Luis since this is relevant for them.
> Maybe between the sysloadfw.sh and owl-loader, there's another
> solution we overlooked so far? I know Luis has been digging
> around in the firmware_class and added the sysdata API. But
> from what I can tell, this would ?break? LEDE/OpenWRT's
> userspace helper, since the sysfs interface in
> /sys/class/firmware which is used by procd to upload the data
> is gone with sysdata or am I wrong?
good idea to keep lede-dev in the loop, as they will be affected (in
my opinion: positively) by this change.


Regards,
Martin


From mschiffer at universe-factory.net  Sun Jun 26 23:50:29 2016
From: mschiffer at universe-factory.net (Matthias Schiffer)
Date: Mon, 27 Jun 2016 08:50:29 +0200
Subject: [LEDE-DEV] [PATCH libubox v3] blobmsg_json: add new functions
	blobmsg_format_json_value*
Message-ID: <e2baf50085bb8d6b7e8285847c2689541eb1cc44.1467010122.git.mschiffer@universe-factory.net>

The current blobmsg_format_json* functions will return invalid JSON when
the "list" argument is given as false (blobmsg_format_element() will
output the name of the blob_attr as if the value is printed as part of a
JSON object).

To avoid breaking software relying on this behaviour, introduce new
functions which will never print the blob_attr name and thus always
produce valid JSON.

Signed-off-by: Matthias Schiffer <mschiffer at universe-factory.net>
---
v3: fix rebase breakage
v2: no changes


 blobmsg_json.c | 58 ++++++++++++++++++++++++++++++++++++++++++++--------------
 blobmsg_json.h | 14 ++++++++++++++
 2 files changed, 58 insertions(+), 14 deletions(-)

diff --git a/blobmsg_json.c b/blobmsg_json.c
index 2e318b2..7fcf620 100644
--- a/blobmsg_json.c
+++ b/blobmsg_json.c
@@ -214,7 +214,7 @@ static void blobmsg_format_string(struct strbuf *s, const char *str)
 
 static void blobmsg_format_json_list(struct strbuf *s, struct blob_attr *attr, int len, bool array);
 
-static void blobmsg_format_element(struct strbuf *s, struct blob_attr *attr, bool array, bool head)
+static void blobmsg_format_element(struct strbuf *s, struct blob_attr *attr, bool without_name, bool head)
 {
 	const char *data_str;
 	char buf[32];
@@ -224,7 +224,7 @@ static void blobmsg_format_element(struct strbuf *s, struct blob_attr *attr, boo
 	if (!blobmsg_check_attr(attr, false))
 		return;
 
-	if (!array && blobmsg_name(attr)[0]) {
+	if (!without_name && blobmsg_name(attr)[0]) {
 		blobmsg_format_string(s, blobmsg_name(attr));
 		blobmsg_puts(s, ": ", s->indent ? 2 : 1);
 	}
@@ -293,27 +293,30 @@ static void blobmsg_format_json_list(struct strbuf *s, struct blob_attr *attr, i
 	blobmsg_puts(s, (array ? "]" : "}"), 1);
 }
 
+static void setup_strbuf(struct strbuf *s, struct blob_attr *attr, blobmsg_json_format_t cb, void *priv, int indent) {
+	s->len = blob_len(attr);
+	s->buf = malloc(s->len);
+	s->pos = 0;
+	s->custom_format = cb;
+	s->priv = priv;
+	s->indent = false;
+
+	if (indent >= 0) {
+		s->indent = true;
+		s->indent_level = indent;
+	}
+}
+
 char *blobmsg_format_json_with_cb(struct blob_attr *attr, bool list, blobmsg_json_format_t cb, void *priv, int indent)
 {
 	struct strbuf s;
 	bool array;
 	char *ret;
 
-	s.len = blob_len(attr);
-	s.pos = 0;
-	s.custom_format = cb;
-	s.priv = priv;
-	s.indent = false;
-
-	s.buf = malloc(s.len);
+	setup_strbuf(&s, attr, cb, priv, indent);
 	if (!s.buf)
 		return NULL;
 
-	if (indent >= 0) {
-		s.indent = true;
-		s.indent_level = indent;
-	}
-
 	array = blob_is_extended(attr) &&
 		blobmsg_type(attr) == BLOBMSG_TYPE_ARRAY;
 
@@ -337,3 +340,30 @@ char *blobmsg_format_json_with_cb(struct blob_attr *attr, bool list, blobmsg_jso
 
 	return ret;
 }
+
+char *blobmsg_format_json_value_with_cb(struct blob_attr *attr, blobmsg_json_format_t cb, void *priv, int indent)
+{
+	struct strbuf s;
+	char *ret;
+
+	setup_strbuf(&s, attr, cb, priv, indent);
+	if (!s.buf)
+		return NULL;
+
+	blobmsg_format_element(&s, attr, true, false);
+
+	if (!s.len) {
+		free(s.buf);
+		return NULL;
+	}
+
+	ret = realloc(s.buf, s.pos + 1);
+	if (!ret) {
+		free(s.buf);
+		return NULL;
+	}
+
+	ret[s.pos] = 0;
+
+	return ret;
+}
diff --git a/blobmsg_json.h b/blobmsg_json.h
index cd9ed33..9dfc02d 100644
--- a/blobmsg_json.h
+++ b/blobmsg_json.h
@@ -42,4 +42,18 @@ static inline char *blobmsg_format_json_indent(struct blob_attr *attr, bool list
 	return blobmsg_format_json_with_cb(attr, list, NULL, NULL, indent);
 }
 
+char *blobmsg_format_json_value_with_cb(struct blob_attr *attr,
+					blobmsg_json_format_t cb, void *priv,
+					int indent);
+
+static inline char *blobmsg_format_json_value(struct blob_attr *attr)
+{
+	return blobmsg_format_json_value_with_cb(attr, NULL, NULL, -1);
+}
+
+static inline char *blobmsg_format_json_value_indent(struct blob_attr *attr, int indent)
+{
+	return blobmsg_format_json_value_with_cb(attr, NULL, NULL, indent);
+}
+
 #endif
-- 
2.9.0



From Alexey.Brodkin at synopsys.com  Mon Jun 27 02:14:27 2016
From: Alexey.Brodkin at synopsys.com (Alexey Brodkin)
Date: Mon, 27 Jun 2016 09:14:27 +0000
Subject: [LEDE-DEV] Add Synopsys brand to Wiki
Message-ID: <1467018805.3628.36.camel@synopsys.com>

Hello,

I wanted to add information about Synopsys boards (ARC 770D and ARC HS38 based)
in the "Table of Hardware" here?https://wiki.openwrt.org/toh/.

Is there a chance to add new brand "Synopsys" to ToH?

For reference:
?* Support of ARC770-based boards: https://git.lede-project.org/?p=source.git;a=tree;f=target/linux/arc770
?* Support of ARC HS38-based boards: https://git.lede-project.org/?p=source.git;a=tree;f=target/linux/archs38

-Alexey

From alin.nastac at gmail.com  Mon Jun 27 04:04:12 2016
From: alin.nastac at gmail.com (=?UTF-8?B?QWxpbiBOxINzdGFj?=)
Date: Mon, 27 Jun 2016 13:04:12 +0200
Subject: [LEDE-DEV] [PATCH] libnetfilter_queue: fix checksum computation
In-Reply-To: <a176bd73-3c16-0f16-4308-1d6617c72d3d@mein.io>
References: <1466772070-21711-1-git-send-email-alin.nastac@gmail.com>
 <a176bd73-3c16-0f16-4308-1d6617c72d3d@mein.io>
Message-ID: <CAF1oqRDWmnVMouCQSbTDSqoSXR5nBTPZ+TTr8GDcjy3xAA4H3Q@mail.gmail.com>

Hi Jo,

I've submitted this patch upstream, see
https://bugzilla.netfilter.org/show_bug.cgi?id=1075 .

BR,
Alin


On Fri, Jun 24, 2016 at 2:44 PM, Jo-Philipp Wich <jo at mein.io> wrote:
> Hi Alin,
>
> is there some upstream reference we can refer to? Did you submit it
> there as well?
>
> Regards,
> Jo
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


From augustus_meyer at yahoo.de  Mon Jun 27 07:21:16 2016
From: augustus_meyer at yahoo.de (reiner otto)
Date: Mon, 27 Jun 2016 14:21:16 +0000 (UTC)
Subject: [LEDE-DEV] ZBT-826 and other MT7620 SD card RO
In-Reply-To: <1144728151.3602615.1467036179520.JavaMail.yahoo@mail.yahoo.com>
References: <1144728151.3602615.1467036179520.JavaMail.yahoo.ref@mail.yahoo.com>
 <1144728151.3602615.1467036179520.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <421055165.3608383.1467037276244.JavaMail.yahoo@mail.yahoo.com>


Having the problem of SD card to be RO, I got following info from ZBT, to be applied against the build src:
- edit ../drivers/mmc/host/mtk-mmc/board.h:
    modify "#define MSDC_WP_PIN_EN (1<<1)" 
    to
    "#define MSDC_WP_PIN_EN (0<<1)"
- edit ../drivers/mmc/host/mtk-mmc/sd.c:
     modify "#define MSDC_WP_PIN_EN (1<<1)" 
    to
    "#define MSDC_WP_PIN_EN (0<<1)"

and recompile. This worked for me.
As I am not familar with the official patch procedure, one of the developers might take care of this, as it most likely also applies to other MT7620-based boards.    


From john at phrozen.org  Mon Jun 27 07:38:31 2016
From: john at phrozen.org (John Crispin)
Date: Mon, 27 Jun 2016 16:38:31 +0200
Subject: [LEDE-DEV] ZBT-826 and other MT7620 SD card RO
In-Reply-To: <421055165.3608383.1467037276244.JavaMail.yahoo@mail.yahoo.com>
References: <1144728151.3602615.1467036179520.JavaMail.yahoo.ref@mail.yahoo.com>
 <1144728151.3602615.1467036179520.JavaMail.yahoo@mail.yahoo.com>
 <421055165.3608383.1467037276244.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <752853c8-4b58-c951-99d1-81baba2d61aa@phrozen.org>



On 27/06/2016 16:21, reiner otto wrote:
> 
> Having the problem of SD card to be RO, I got following info from ZBT, to be applied against the build src:
> - edit ../drivers/mmc/host/mtk-mmc/board.h:
>     modify "#define MSDC_WP_PIN_EN (1<<1)" 
>     to
>     "#define MSDC_WP_PIN_EN (0<<1)"
> - edit ../drivers/mmc/host/mtk-mmc/sd.c:
>      modify "#define MSDC_WP_PIN_EN (1<<1)" 
>     to
>     "#define MSDC_WP_PIN_EN (0<<1)"
> 
> and recompile. This worked for me.
> As I am not familar with the official patch procedure, one of the developers might take care of this, as it most likely also applies to other MT7620-based boards.    
> 

I'll take care of it the next days, made a note already

	John


From champetier.etienne at gmail.com  Mon Jun 27 08:53:30 2016
From: champetier.etienne at gmail.com (Etienne CHAMPETIER)
Date: Mon, 27 Jun 2016 15:53:30 +0000
Subject: [LEDE-DEV] [PATCH v5] base-files: seed /dev/urandom
Message-ID: <1467042810-52032-1-git-send-email-champetier.etienne@gmail.com>

This commit:
1) seed /dev/urandom with the saved seeds as early as possible
   (see /lib/preinit/81_urandom_seed)
2) save a seed at /etc/urandom.seed if it doesn't exists
3) save a new seed each boot at "system. at system[0].urandom_seed"
   (see /etc/init.d/urandom_seed)

We use getrandom() so we are sure /dev/urandom pool is initialized

Seed size is 512 bytes (ie /proc/sys/kernel/random/poolsize / 8)
it's the same size as in ubuntu 14.04 and all systemd systems

Seeding /dev/urandom doesn't change entropy estimation, so we still have
"random: ubus urandom read with 4 bits of entropy available"
messages in the logs, but we can now ignore them if
after "urandom-seed: Seeding with ..." message

Saving a new seed on each boot is disabled by default to avoid too much
writes without user consent

v2: log preinit messages to /dev/kmsg
v3: use non generic function name for logging, as /lib/preinit/ files
    are all sourced together in /etc/preinit
v4: after a lot of discussion on the ML, use a uci config param
v5: config param is now the path of the seed

Signed-off-by: Etienne CHAMPETIER <champetier.etienne at gmail.com>
---
 package/base-files/files/bin/config_generate       |  1 +
 package/base-files/files/etc/init.d/urandom_seed   | 29 ++++++++++++++++++++++
 .../base-files/files/lib/preinit/81_urandom_seed   | 24 ++++++++++++++++++
 3 files changed, 54 insertions(+)
 create mode 100755 package/base-files/files/etc/init.d/urandom_seed
 create mode 100644 package/base-files/files/lib/preinit/81_urandom_seed

diff --git a/package/base-files/files/bin/config_generate b/package/base-files/files/bin/config_generate
index 8002bc4..c0ba0fb 100755
--- a/package/base-files/files/bin/config_generate
+++ b/package/base-files/files/bin/config_generate
@@ -230,6 +230,7 @@ generate_static_system() {
 		set system. at system[-1].timezone='UTC'
 		set system. at system[-1].ttylogin='0'
 		set system. at system[-1].log_size='64'
+		set system. at system[-1].urandom_seed='0'
 
 		delete system.ntp
 		set system.ntp='timeserver'
diff --git a/package/base-files/files/etc/init.d/urandom_seed b/package/base-files/files/etc/init.d/urandom_seed
new file mode 100755
index 0000000..cb2eb44
--- /dev/null
+++ b/package/base-files/files/etc/init.d/urandom_seed
@@ -0,0 +1,29 @@
+#!/bin/sh /etc/rc.common
+
+START=99
+
+EXTRA_COMMANDS="save"
+
+_log() {
+    logger -t urandom_seed "$1"
+}
+
+_save() {
+    touch $1.tmp || { _log "touch $1 failed"; return; }
+    chown root:root $1.tmp || { _log "chown $1 failed"; return; }
+    chmod 600 $1.tmp || { _log "chmod $1 failed"; return; }
+    getrandom 512 > $1.tmp || { _log "getrandom failed"; return; }
+    mv $1.tmp $1 || { _log "mv $1 failed"; return; }
+}
+
+save() {
+    SEED="$(uci -q get system. at system[0].urandom_seed)"
+    [ "${SEED:0:1}" == "/" ] && _save "$SEED" && _log "Seed saved ($SEED)"
+
+    SEED=/etc/urandom.seed
+    [ ! -f $SEED ] && _save "$SEED" && _log "Seed saved ($SEED)"
+}
+
+boot() {
+    save
+}
diff --git a/package/base-files/files/lib/preinit/81_urandom_seed b/package/base-files/files/lib/preinit/81_urandom_seed
new file mode 100644
index 0000000..10878f3
--- /dev/null
+++ b/package/base-files/files/lib/preinit/81_urandom_seed
@@ -0,0 +1,24 @@
+#!/bin/sh
+
+log_urandom_seed() {
+    echo "urandom-seed: $1" > /dev/kmsg
+}
+
+_do_urandom_seed() {
+    [ -f "$1" ] || { log_urandom_seed "Seed file not found ($1)"; return; }
+    [ -O "$1" -a -G "$1" -a ! -x "$1" ] || { log_urandom_seed "Wrong owner / permissions for $1"; return; }
+
+    log_urandom_seed "Seeding with $1"
+    cat "$1" > /dev/urandom
+}
+
+do_urandom_seed() {
+    [ -c /dev/urandom ] || { log_urandom_seed "Something is wrong with /dev/urandom"; return; }
+
+    _do_urandom_seed "/etc/urandom.seed"
+
+    SEED="$(uci -q get system. at system[0].urandom_seed)"
+    [ "${SEED:0:1}" == "/" -a "$SEED" != "/etc/urandom.seed" ] && _do_urandom_seed "$SEED"
+}
+
+boot_hook_add preinit_main do_urandom_seed
-- 
1.9.1



From jo at mein.io  Tue Jun 28 01:28:08 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Tue, 28 Jun 2016 10:28:08 +0200
Subject: [LEDE-DEV] [PATCH v5] base-files: seed /dev/urandom
In-Reply-To: <1467042810-52032-1-git-send-email-champetier.etienne@gmail.com>
References: <1467042810-52032-1-git-send-email-champetier.etienne@gmail.com>
Message-ID: <fb72489d-ecf3-3985-b873-5773aaf56749@mein.io>

Hi Etienne,

I like this approach, fine with me now.

On 06/27/2016 05:53 PM, Etienne CHAMPETIER wrote:
> This commit:
> 1) seed /dev/urandom with the saved seeds as early as possible
>    (see /lib/preinit/81_urandom_seed)
> 2) save a seed at /etc/urandom.seed if it doesn't exists
> 3) save a new seed each boot at "system. at system[0].urandom_seed"
>    (see /etc/init.d/urandom_seed)
> 
> We use getrandom() so we are sure /dev/urandom pool is initialized
> 
> Seed size is 512 bytes (ie /proc/sys/kernel/random/poolsize / 8)
> it's the same size as in ubuntu 14.04 and all systemd systems
> 
> Seeding /dev/urandom doesn't change entropy estimation, so we still have
> "random: ubus urandom read with 4 bits of entropy available"
> messages in the logs, but we can now ignore them if
> after "urandom-seed: Seeding with ..." message
> 
> Saving a new seed on each boot is disabled by default to avoid too much
> writes without user consent
> 
> v2: log preinit messages to /dev/kmsg
> v3: use non generic function name for logging, as /lib/preinit/ files
>     are all sourced together in /etc/preinit
> v4: after a lot of discussion on the ML, use a uci config param
> v5: config param is now the path of the seed
> 
> Signed-off-by: Etienne CHAMPETIER <champetier.etienne at gmail.com>
Acked-by: Jo-Philipp Wich <jo at mein.io>
> ---
>  package/base-files/files/bin/config_generate       |  1 +
>  package/base-files/files/etc/init.d/urandom_seed   | 29 ++++++++++++++++++++++
>  .../base-files/files/lib/preinit/81_urandom_seed   | 24 ++++++++++++++++++
>  3 files changed, 54 insertions(+)
>  create mode 100755 package/base-files/files/etc/init.d/urandom_seed
>  create mode 100644 package/base-files/files/lib/preinit/81_urandom_seed
> 
> diff --git a/package/base-files/files/bin/config_generate b/package/base-files/files/bin/config_generate
> index 8002bc4..c0ba0fb 100755
> --- a/package/base-files/files/bin/config_generate
> +++ b/package/base-files/files/bin/config_generate
> @@ -230,6 +230,7 @@ generate_static_system() {
>  		set system. at system[-1].timezone='UTC'
>  		set system. at system[-1].ttylogin='0'
>  		set system. at system[-1].log_size='64'
> +		set system. at system[-1].urandom_seed='0'
>  
>  		delete system.ntp
>  		set system.ntp='timeserver'
> diff --git a/package/base-files/files/etc/init.d/urandom_seed b/package/base-files/files/etc/init.d/urandom_seed
> new file mode 100755
> index 0000000..cb2eb44
> --- /dev/null
> +++ b/package/base-files/files/etc/init.d/urandom_seed
> @@ -0,0 +1,29 @@
> +#!/bin/sh /etc/rc.common
> +
> +START=99
> +
> +EXTRA_COMMANDS="save"
> +
> +_log() {
> +    logger -t urandom_seed "$1"
> +}
> +
> +_save() {
> +    touch $1.tmp || { _log "touch $1 failed"; return; }
> +    chown root:root $1.tmp || { _log "chown $1 failed"; return; }
> +    chmod 600 $1.tmp || { _log "chmod $1 failed"; return; }
> +    getrandom 512 > $1.tmp || { _log "getrandom failed"; return; }
> +    mv $1.tmp $1 || { _log "mv $1 failed"; return; }
> +}
> +
> +save() {
> +    SEED="$(uci -q get system. at system[0].urandom_seed)"
> +    [ "${SEED:0:1}" == "/" ] && _save "$SEED" && _log "Seed saved ($SEED)"
> +
> +    SEED=/etc/urandom.seed
> +    [ ! -f $SEED ] && _save "$SEED" && _log "Seed saved ($SEED)"
> +}
> +
> +boot() {
> +    save
> +}
> diff --git a/package/base-files/files/lib/preinit/81_urandom_seed b/package/base-files/files/lib/preinit/81_urandom_seed
> new file mode 100644
> index 0000000..10878f3
> --- /dev/null
> +++ b/package/base-files/files/lib/preinit/81_urandom_seed
> @@ -0,0 +1,24 @@
> +#!/bin/sh
> +
> +log_urandom_seed() {
> +    echo "urandom-seed: $1" > /dev/kmsg
> +}
> +
> +_do_urandom_seed() {
> +    [ -f "$1" ] || { log_urandom_seed "Seed file not found ($1)"; return; }
> +    [ -O "$1" -a -G "$1" -a ! -x "$1" ] || { log_urandom_seed "Wrong owner / permissions for $1"; return; }
> +
> +    log_urandom_seed "Seeding with $1"
> +    cat "$1" > /dev/urandom
> +}
> +
> +do_urandom_seed() {
> +    [ -c /dev/urandom ] || { log_urandom_seed "Something is wrong with /dev/urandom"; return; }
> +
> +    _do_urandom_seed "/etc/urandom.seed"
> +
> +    SEED="$(uci -q get system. at system[0].urandom_seed)"
> +    [ "${SEED:0:1}" == "/" -a "$SEED" != "/etc/urandom.seed" ] && _do_urandom_seed "$SEED"
> +}
> +
> +boot_hook_add preinit_main do_urandom_seed
> 



From john at phrozen.org  Tue Jun 28 01:44:23 2016
From: john at phrozen.org (John Crispin)
Date: Tue, 28 Jun 2016 10:44:23 +0200
Subject: [LEDE-DEV] [PATCH v5] base-files: seed /dev/urandom
In-Reply-To: <fb72489d-ecf3-3985-b873-5773aaf56749@mein.io>
References: <1467042810-52032-1-git-send-email-champetier.etienne@gmail.com>
 <fb72489d-ecf3-3985-b873-5773aaf56749@mein.io>
Message-ID: <cec1c234-509a-d4bf-d3a2-aad5797149c1@phrozen.org>



On 28/06/2016 10:28, Jo-Philipp Wich wrote:
> Hi Etienne,
> 
> I like this approach, fine with me now.
> 

same here, we could not also consider adding a uci-defaults script that
check if rootfs is on a mtd or real lbock device and change the default
during firstboot, but i guess that would be a new patch. i have just
pulled this into my staging tree

	John


> On 06/27/2016 05:53 PM, Etienne CHAMPETIER wrote:
>> This commit:
>> 1) seed /dev/urandom with the saved seeds as early as possible
>>    (see /lib/preinit/81_urandom_seed)
>> 2) save a seed at /etc/urandom.seed if it doesn't exists
>> 3) save a new seed each boot at "system. at system[0].urandom_seed"
>>    (see /etc/init.d/urandom_seed)
>>
>> We use getrandom() so we are sure /dev/urandom pool is initialized
>>
>> Seed size is 512 bytes (ie /proc/sys/kernel/random/poolsize / 8)
>> it's the same size as in ubuntu 14.04 and all systemd systems
>>
>> Seeding /dev/urandom doesn't change entropy estimation, so we still have
>> "random: ubus urandom read with 4 bits of entropy available"
>> messages in the logs, but we can now ignore them if
>> after "urandom-seed: Seeding with ..." message
>>
>> Saving a new seed on each boot is disabled by default to avoid too much
>> writes without user consent
>>
>> v2: log preinit messages to /dev/kmsg
>> v3: use non generic function name for logging, as /lib/preinit/ files
>>     are all sourced together in /etc/preinit
>> v4: after a lot of discussion on the ML, use a uci config param
>> v5: config param is now the path of the seed
>>
>> Signed-off-by: Etienne CHAMPETIER <champetier.etienne at gmail.com>
> Acked-by: Jo-Philipp Wich <jo at mein.io>
>> ---
>>  package/base-files/files/bin/config_generate       |  1 +
>>  package/base-files/files/etc/init.d/urandom_seed   | 29 ++++++++++++++++++++++
>>  .../base-files/files/lib/preinit/81_urandom_seed   | 24 ++++++++++++++++++
>>  3 files changed, 54 insertions(+)
>>  create mode 100755 package/base-files/files/etc/init.d/urandom_seed
>>  create mode 100644 package/base-files/files/lib/preinit/81_urandom_seed
>>
>> diff --git a/package/base-files/files/bin/config_generate b/package/base-files/files/bin/config_generate
>> index 8002bc4..c0ba0fb 100755
>> --- a/package/base-files/files/bin/config_generate
>> +++ b/package/base-files/files/bin/config_generate
>> @@ -230,6 +230,7 @@ generate_static_system() {
>>  		set system. at system[-1].timezone='UTC'
>>  		set system. at system[-1].ttylogin='0'
>>  		set system. at system[-1].log_size='64'
>> +		set system. at system[-1].urandom_seed='0'
>>  
>>  		delete system.ntp
>>  		set system.ntp='timeserver'
>> diff --git a/package/base-files/files/etc/init.d/urandom_seed b/package/base-files/files/etc/init.d/urandom_seed
>> new file mode 100755
>> index 0000000..cb2eb44
>> --- /dev/null
>> +++ b/package/base-files/files/etc/init.d/urandom_seed
>> @@ -0,0 +1,29 @@
>> +#!/bin/sh /etc/rc.common
>> +
>> +START=99
>> +
>> +EXTRA_COMMANDS="save"
>> +
>> +_log() {
>> +    logger -t urandom_seed "$1"
>> +}
>> +
>> +_save() {
>> +    touch $1.tmp || { _log "touch $1 failed"; return; }
>> +    chown root:root $1.tmp || { _log "chown $1 failed"; return; }
>> +    chmod 600 $1.tmp || { _log "chmod $1 failed"; return; }
>> +    getrandom 512 > $1.tmp || { _log "getrandom failed"; return; }
>> +    mv $1.tmp $1 || { _log "mv $1 failed"; return; }
>> +}
>> +
>> +save() {
>> +    SEED="$(uci -q get system. at system[0].urandom_seed)"
>> +    [ "${SEED:0:1}" == "/" ] && _save "$SEED" && _log "Seed saved ($SEED)"
>> +
>> +    SEED=/etc/urandom.seed
>> +    [ ! -f $SEED ] && _save "$SEED" && _log "Seed saved ($SEED)"
>> +}
>> +
>> +boot() {
>> +    save
>> +}
>> diff --git a/package/base-files/files/lib/preinit/81_urandom_seed b/package/base-files/files/lib/preinit/81_urandom_seed
>> new file mode 100644
>> index 0000000..10878f3
>> --- /dev/null
>> +++ b/package/base-files/files/lib/preinit/81_urandom_seed
>> @@ -0,0 +1,24 @@
>> +#!/bin/sh
>> +
>> +log_urandom_seed() {
>> +    echo "urandom-seed: $1" > /dev/kmsg
>> +}
>> +
>> +_do_urandom_seed() {
>> +    [ -f "$1" ] || { log_urandom_seed "Seed file not found ($1)"; return; }
>> +    [ -O "$1" -a -G "$1" -a ! -x "$1" ] || { log_urandom_seed "Wrong owner / permissions for $1"; return; }
>> +
>> +    log_urandom_seed "Seeding with $1"
>> +    cat "$1" > /dev/urandom
>> +}
>> +
>> +do_urandom_seed() {
>> +    [ -c /dev/urandom ] || { log_urandom_seed "Something is wrong with /dev/urandom"; return; }
>> +
>> +    _do_urandom_seed "/etc/urandom.seed"
>> +
>> +    SEED="$(uci -q get system. at system[0].urandom_seed)"
>> +    [ "${SEED:0:1}" == "/" -a "$SEED" != "/etc/urandom.seed" ] && _do_urandom_seed "$SEED"
>> +}
>> +
>> +boot_hook_add preinit_main do_urandom_seed
>>
> 
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 


From arjen+lede at de-korte.org  Tue Jun 28 02:52:35 2016
From: arjen+lede at de-korte.org (Arjen de Korte)
Date: Tue, 28 Jun 2016 11:52:35 +0200
Subject: [LEDE-DEV] [PATCH v5] base-files: seed /dev/urandom
In-Reply-To: <cec1c234-509a-d4bf-d3a2-aad5797149c1@phrozen.org>
References: <1467042810-52032-1-git-send-email-champetier.etienne@gmail.com>
 <fb72489d-ecf3-3985-b873-5773aaf56749@mein.io>
 <cec1c234-509a-d4bf-d3a2-aad5797149c1@phrozen.org>
Message-ID: <20160628115235.Horde.iw9arZN8GJSgL9macxB2CqN@mail.de-korte.org>

Citeren John Crispin <john at phrozen.org>:

> On 28/06/2016 10:28, Jo-Philipp Wich wrote:
>> Hi Etienne,
>>
>> I like this approach, fine with me now.
>>
>
> same here, we could not also consider adding a uci-defaults script that
> check if rootfs is on a mtd or real lbock device and change the default
> during firstboot, but i guess that would be a new patch. i have just
> pulled this into my staging tree

Would it be useful to list /etc/urandom.seed in  
package/base-files/files/lib/upgrade/keep.d/base-files-essential to  
keep on sysupgrade? Or would this break if the file does not exist? In  
that case, it might be useful to make a note to add it to  
/etc/sysupgrade.conf if the contents should be kept on upgrades.

>> On 06/27/2016 05:53 PM, Etienne CHAMPETIER wrote:
>>> This commit:
>>> 1) seed /dev/urandom with the saved seeds as early as possible
>>>    (see /lib/preinit/81_urandom_seed)
>>> 2) save a seed at /etc/urandom.seed if it doesn't exists
>>> 3) save a new seed each boot at "system. at system[0].urandom_seed"
>>>    (see /etc/init.d/urandom_seed)
>>>
>>> We use getrandom() so we are sure /dev/urandom pool is initialized
>>>
>>> Seed size is 512 bytes (ie /proc/sys/kernel/random/poolsize / 8)
>>> it's the same size as in ubuntu 14.04 and all systemd systems
>>>
>>> Seeding /dev/urandom doesn't change entropy estimation, so we still have
>>> "random: ubus urandom read with 4 bits of entropy available"
>>> messages in the logs, but we can now ignore them if
>>> after "urandom-seed: Seeding with ..." message
>>>
>>> Saving a new seed on each boot is disabled by default to avoid too much
>>> writes without user consent
>>>
>>> v2: log preinit messages to /dev/kmsg
>>> v3: use non generic function name for logging, as /lib/preinit/ files
>>>     are all sourced together in /etc/preinit
>>> v4: after a lot of discussion on the ML, use a uci config param
>>> v5: config param is now the path of the seed
>>>
>>> Signed-off-by: Etienne CHAMPETIER <champetier.etienne at gmail.com>
>> Acked-by: Jo-Philipp Wich <jo at mein.io>
>>> ---
>>>  package/base-files/files/bin/config_generate       |  1 +
>>>  package/base-files/files/etc/init.d/urandom_seed   | 29  
>>> ++++++++++++++++++++++
>>>  .../base-files/files/lib/preinit/81_urandom_seed   | 24 ++++++++++++++++++
>>>  3 files changed, 54 insertions(+)
>>>  create mode 100755 package/base-files/files/etc/init.d/urandom_seed
>>>  create mode 100644 package/base-files/files/lib/preinit/81_urandom_seed
>>>
>>> diff --git a/package/base-files/files/bin/config_generate  
>>> b/package/base-files/files/bin/config_generate
>>> index 8002bc4..c0ba0fb 100755
>>> --- a/package/base-files/files/bin/config_generate
>>> +++ b/package/base-files/files/bin/config_generate
>>> @@ -230,6 +230,7 @@ generate_static_system() {
>>>  		set system. at system[-1].timezone='UTC'
>>>  		set system. at system[-1].ttylogin='0'
>>>  		set system. at system[-1].log_size='64'
>>> +		set system. at system[-1].urandom_seed='0'
>>>
>>>  		delete system.ntp
>>>  		set system.ntp='timeserver'
>>> diff --git a/package/base-files/files/etc/init.d/urandom_seed  
>>> b/package/base-files/files/etc/init.d/urandom_seed
>>> new file mode 100755
>>> index 0000000..cb2eb44
>>> --- /dev/null
>>> +++ b/package/base-files/files/etc/init.d/urandom_seed
>>> @@ -0,0 +1,29 @@
>>> +#!/bin/sh /etc/rc.common
>>> +
>>> +START=99
>>> +
>>> +EXTRA_COMMANDS="save"
>>> +
>>> +_log() {
>>> +    logger -t urandom_seed "$1"
>>> +}
>>> +
>>> +_save() {
>>> +    touch $1.tmp || { _log "touch $1 failed"; return; }
>>> +    chown root:root $1.tmp || { _log "chown $1 failed"; return; }
>>> +    chmod 600 $1.tmp || { _log "chmod $1 failed"; return; }
>>> +    getrandom 512 > $1.tmp || { _log "getrandom failed"; return; }
>>> +    mv $1.tmp $1 || { _log "mv $1 failed"; return; }
>>> +}
>>> +
>>> +save() {
>>> +    SEED="$(uci -q get system. at system[0].urandom_seed)"
>>> +    [ "${SEED:0:1}" == "/" ] && _save "$SEED" && _log "Seed saved ($SEED)"
>>> +
>>> +    SEED=/etc/urandom.seed
>>> +    [ ! -f $SEED ] && _save "$SEED" && _log "Seed saved ($SEED)"
>>> +}
>>> +
>>> +boot() {
>>> +    save
>>> +}
>>> diff --git a/package/base-files/files/lib/preinit/81_urandom_seed  
>>> b/package/base-files/files/lib/preinit/81_urandom_seed
>>> new file mode 100644
>>> index 0000000..10878f3
>>> --- /dev/null
>>> +++ b/package/base-files/files/lib/preinit/81_urandom_seed
>>> @@ -0,0 +1,24 @@
>>> +#!/bin/sh
>>> +
>>> +log_urandom_seed() {
>>> +    echo "urandom-seed: $1" > /dev/kmsg
>>> +}
>>> +
>>> +_do_urandom_seed() {
>>> +    [ -f "$1" ] || { log_urandom_seed "Seed file not found ($1)";  
>>> return; }
>>> +    [ -O "$1" -a -G "$1" -a ! -x "$1" ] || { log_urandom_seed  
>>> "Wrong owner / permissions for $1"; return; }
>>> +
>>> +    log_urandom_seed "Seeding with $1"
>>> +    cat "$1" > /dev/urandom
>>> +}
>>> +
>>> +do_urandom_seed() {
>>> +    [ -c /dev/urandom ] || { log_urandom_seed "Something is wrong  
>>> with /dev/urandom"; return; }
>>> +
>>> +    _do_urandom_seed "/etc/urandom.seed"
>>> +
>>> +    SEED="$(uci -q get system. at system[0].urandom_seed)"
>>> +    [ "${SEED:0:1}" == "/" -a "$SEED" != "/etc/urandom.seed" ] &&  
>>> _do_urandom_seed "$SEED"
>>> +}
>>> +
>>> +boot_hook_add preinit_main do_urandom_seed
>>>
>>
>>
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev





From champetier.etienne at gmail.com  Tue Jun 28 03:55:57 2016
From: champetier.etienne at gmail.com (Etienne Champetier)
Date: Tue, 28 Jun 2016 12:55:57 +0200
Subject: [LEDE-DEV] [PATCH v5] base-files: seed /dev/urandom
In-Reply-To: <20160628115235.Horde.iw9arZN8GJSgL9macxB2CqN@mail.de-korte.org>
References: <1467042810-52032-1-git-send-email-champetier.etienne@gmail.com>
 <fb72489d-ecf3-3985-b873-5773aaf56749@mein.io>
 <cec1c234-509a-d4bf-d3a2-aad5797149c1@phrozen.org>
 <20160628115235.Horde.iw9arZN8GJSgL9macxB2CqN@mail.de-korte.org>
Message-ID: <CAOdf3gqjh1ng0qyKhinX04Yco3PWQzpXagGZfhZkUdggv_h-zQ@mail.gmail.com>

Hi Arjen,

2016-06-28 11:52 GMT+02:00 Arjen de Korte <arjen+lede at de-korte.org>:
> Citeren John Crispin <john at phrozen.org>:
>
>> On 28/06/2016 10:28, Jo-Philipp Wich wrote:
>>>
>>> Hi Etienne,
>>>
>>> I like this approach, fine with me now.
>>>
>>
>> same here, we could not also consider adding a uci-defaults script that
>> check if rootfs is on a mtd or real lbock device and change the default
>> during firstboot, but i guess that would be a new patch. i have just
>> pulled this into my staging tree
>
>
> Would it be useful to list /etc/urandom.seed in
> package/base-files/files/lib/upgrade/keep.d/base-files-essential to keep on
> sysupgrade? Or would this break if the file does not exist? In that case, it
> might be useful to make a note to add it to /etc/sysupgrade.conf if the
> contents should be kept on upgrades.
>

We can keep /etc/urandom.seed on upgrade, be we shouldn't include it
in config backup

>
>>> On 06/27/2016 05:53 PM, Etienne CHAMPETIER wrote:
>>>>
>>>> This commit:
>>>> 1) seed /dev/urandom with the saved seeds as early as possible
>>>>    (see /lib/preinit/81_urandom_seed)
>>>> 2) save a seed at /etc/urandom.seed if it doesn't exists
>>>> 3) save a new seed each boot at "system. at system[0].urandom_seed"
>>>>    (see /etc/init.d/urandom_seed)
>>>>
>>>> We use getrandom() so we are sure /dev/urandom pool is initialized
>>>>
>>>> Seed size is 512 bytes (ie /proc/sys/kernel/random/poolsize / 8)
>>>> it's the same size as in ubuntu 14.04 and all systemd systems
>>>>
>>>> Seeding /dev/urandom doesn't change entropy estimation, so we still have
>>>> "random: ubus urandom read with 4 bits of entropy available"
>>>> messages in the logs, but we can now ignore them if
>>>> after "urandom-seed: Seeding with ..." message
>>>>
>>>> Saving a new seed on each boot is disabled by default to avoid too much
>>>> writes without user consent
>>>>
>>>> v2: log preinit messages to /dev/kmsg
>>>> v3: use non generic function name for logging, as /lib/preinit/ files
>>>>     are all sourced together in /etc/preinit
>>>> v4: after a lot of discussion on the ML, use a uci config param
>>>> v5: config param is now the path of the seed
>>>>
>>>> Signed-off-by: Etienne CHAMPETIER <champetier.etienne at gmail.com>
>>>
>>> Acked-by: Jo-Philipp Wich <jo at mein.io>
>>>>
>>>> ---
>>>>  package/base-files/files/bin/config_generate       |  1 +
>>>>  package/base-files/files/etc/init.d/urandom_seed   | 29
>>>> ++++++++++++++++++++++
>>>>  .../base-files/files/lib/preinit/81_urandom_seed   | 24
>>>> ++++++++++++++++++
>>>>  3 files changed, 54 insertions(+)
>>>>  create mode 100755 package/base-files/files/etc/init.d/urandom_seed
>>>>  create mode 100644 package/base-files/files/lib/preinit/81_urandom_seed
>>>>
>>>> diff --git a/package/base-files/files/bin/config_generate
>>>> b/package/base-files/files/bin/config_generate
>>>> index 8002bc4..c0ba0fb 100755
>>>> --- a/package/base-files/files/bin/config_generate
>>>> +++ b/package/base-files/files/bin/config_generate
>>>> @@ -230,6 +230,7 @@ generate_static_system() {
>>>>                 set system. at system[-1].timezone='UTC'
>>>>                 set system. at system[-1].ttylogin='0'
>>>>                 set system. at system[-1].log_size='64'
>>>> +               set system. at system[-1].urandom_seed='0'
>>>>
>>>>                 delete system.ntp
>>>>                 set system.ntp='timeserver'
>>>> diff --git a/package/base-files/files/etc/init.d/urandom_seed
>>>> b/package/base-files/files/etc/init.d/urandom_seed
>>>> new file mode 100755
>>>> index 0000000..cb2eb44
>>>> --- /dev/null
>>>> +++ b/package/base-files/files/etc/init.d/urandom_seed
>>>> @@ -0,0 +1,29 @@
>>>> +#!/bin/sh /etc/rc.common
>>>> +
>>>> +START=99
>>>> +
>>>> +EXTRA_COMMANDS="save"
>>>> +
>>>> +_log() {
>>>> +    logger -t urandom_seed "$1"
>>>> +}
>>>> +
>>>> +_save() {
>>>> +    touch $1.tmp || { _log "touch $1 failed"; return; }
>>>> +    chown root:root $1.tmp || { _log "chown $1 failed"; return; }
>>>> +    chmod 600 $1.tmp || { _log "chmod $1 failed"; return; }
>>>> +    getrandom 512 > $1.tmp || { _log "getrandom failed"; return; }
>>>> +    mv $1.tmp $1 || { _log "mv $1 failed"; return; }
>>>> +}
>>>> +
>>>> +save() {
>>>> +    SEED="$(uci -q get system. at system[0].urandom_seed)"
>>>> +    [ "${SEED:0:1}" == "/" ] && _save "$SEED" && _log "Seed saved
>>>> ($SEED)"
>>>> +
>>>> +    SEED=/etc/urandom.seed
>>>> +    [ ! -f $SEED ] && _save "$SEED" && _log "Seed saved ($SEED)"
>>>> +}
>>>> +
>>>> +boot() {
>>>> +    save
>>>> +}
>>>> diff --git a/package/base-files/files/lib/preinit/81_urandom_seed
>>>> b/package/base-files/files/lib/preinit/81_urandom_seed
>>>> new file mode 100644
>>>> index 0000000..10878f3
>>>> --- /dev/null
>>>> +++ b/package/base-files/files/lib/preinit/81_urandom_seed
>>>> @@ -0,0 +1,24 @@
>>>> +#!/bin/sh
>>>> +
>>>> +log_urandom_seed() {
>>>> +    echo "urandom-seed: $1" > /dev/kmsg
>>>> +}
>>>> +
>>>> +_do_urandom_seed() {
>>>> +    [ -f "$1" ] || { log_urandom_seed "Seed file not found ($1)";
>>>> return; }
>>>> +    [ -O "$1" -a -G "$1" -a ! -x "$1" ] || { log_urandom_seed "Wrong
>>>> owner / permissions for $1"; return; }
>>>> +
>>>> +    log_urandom_seed "Seeding with $1"
>>>> +    cat "$1" > /dev/urandom
>>>> +}
>>>> +
>>>> +do_urandom_seed() {
>>>> +    [ -c /dev/urandom ] || { log_urandom_seed "Something is wrong with
>>>> /dev/urandom"; return; }
>>>> +
>>>> +    _do_urandom_seed "/etc/urandom.seed"
>>>> +
>>>> +    SEED="$(uci -q get system. at system[0].urandom_seed)"
>>>> +    [ "${SEED:0:1}" == "/" -a "$SEED" != "/etc/urandom.seed" ] &&
>>>> _do_urandom_seed "$SEED"
>>>> +}
>>>> +
>>>> +boot_hook_add preinit_main do_urandom_seed
>>>>
>>>
>>>


From john at phrozen.org  Tue Jun 28 23:30:55 2016
From: john at phrozen.org (John Crispin)
Date: Wed, 29 Jun 2016 08:30:55 +0200
Subject: [LEDE-DEV] fstools: ext4 overlay support - rootfs mounted twice
 bug
In-Reply-To: <5768f92a-d15a-37f5-28c7-e7a78d6703ac@gmail.com>
References: <5768f92a-d15a-37f5-28c7-e7a78d6703ac@gmail.com>
Message-ID: <e613fa88-80b9-77c1-d109-ff7ed3b53349@phrozen.org>

Hi,

the patch is an attachement making inline commenting impossible. please
send patches inline

> mount_root: Don't mount ext4 rootfs twice

the patch is incorrect, it breaks the vase where there is an overlay
setup + extroot. after your patch the extroot codepath wont ever run if
there is a rootfs_data partition

	John


From josua.mayer97 at gmail.com  Wed Jun 29 03:11:00 2016
From: josua.mayer97 at gmail.com (Josua Mayer)
Date: Wed, 29 Jun 2016 12:11:00 +0200
Subject: [LEDE-DEV] fstools: ext4 overlay support - rootfs mounted twice
 bug
In-Reply-To: <e613fa88-80b9-77c1-d109-ff7ed3b53349@phrozen.org>
References: <5768f92a-d15a-37f5-28c7-e7a78d6703ac@gmail.com>
 <e613fa88-80b9-77c1-d109-ff7ed3b53349@phrozen.org>
Message-ID: <d5f99997-1156-f7d3-872b-8b1f360f25e8@gmail.com>

Hi John,

thansk for taking a look. I actually sent it this way by intention,
looking to get in touch with someone who had the original bug.

Am 29.06.2016 um 08:30 schrieb John Crispin:
> Hi,
> 
> the patch is an attachement making inline commenting impossible. please
> send patches inline
>From 59a8fa6d7490ba3da76aec710a1beb241ffaa089 Mon Sep 17 00:00:00 2001
From: Josua Mayer <josua.mayer97 at gmail.com>
Date: Thu, 16 Jun 2016 18:35:30 +0200
Subject: [PATCH 2/4] mount_root: Don't mount ext4 rootfs twice

When there is a) no rootfs_data overlay partition,
and b) /dev/root points to an ext4 partition
the partition would be mounted twice, once as / and then as /overlay.
The essence of this change is to return before mounting /overlay,
if /dev/root has been mounted as /.
>
Signed-off-by: Josua Mayer <josua.mayer97 at gmail.com>
---
 mount_root.c | 40 ++++++++++++++++++++++++++++++----------
 1 file changed, 30 insertions(+), 10 deletions(-)

diff --git a/mount_root.c b/mount_root.c
index 608ce5d..13e5772 100644
--- a/mount_root.c
+++ b/mount_root.c
@@ -37,25 +37,45 @@ start(int argc, char *argv[1])
 	if (!getenv("PREINIT") && stat("/tmp/.preinit", &s))
 		return -1;

+	/*
+	 * When the default overlay partition name rootfs_data can not be found,
+	 * fall back to the special /dev/root device.
+	 */
 	if (!data) {
 		root = volume_find("rootfs");
 		volume_init(root);
+
+		// mount /dev/root at /
 		ULOG_NOTE("mounting /dev/root\n");
 		mount("/dev/root", "/", NULL, MS_NOATIME | MS_REMOUNT, 0);
-	}

-	/*
-	 * Before trying to mount and use "rootfs_data" let's check if there is
-	 * extroot configured. Following call will handle reading config from
-	 * the "rootfs_data" on its own.
-	 */
-	extroot_prefix = "";
-	if (!mount_extroot()) {
-		ULOG_NOTE("switched to extroot\n");
+		/*
+		 * Now that / has been mounted, and there is no overlay device,
+		 * see if extroot is configured.
+		 *
+		 * The following call will handle reading configuration from
+		 * rootfs on its own.
+		 */
+		extroot_prefix = "";
+		if (!mount_extroot()) {
+			ULOG_NOTE("switched to extroot\n");
+			/*
+			 * extroot succeeded mounting an overlay partition, return.
+			 */
+			return 0;
+		}
+
+		/*
+		 * Even if extroot was not configured, considering that no overlay
+		 * partition was found, and / was mounted, return now.
+		 */
 		return 0;
 	}

-	/* There isn't extroot, so just try to mount "rootfs_data" */
+	/*
+	 * neither /dev/root nor extroot were used.
+	 * Attempt to mount the overlay partition.
+	 */
 	switch (volume_identify(data)) {
 	case FS_NONE:
 		ULOG_WARN("no usable overlay filesystem found, using tmpfs overlay\n");
-- 
2.6.6
> 
>> mount_root: Don't mount ext4 rootfs twice
> 
> the patch is incorrect, it breaks the vase where there is an overlay
> setup + extroot. after your patch the extroot codepath wont ever run if
> there is a rootfs_data partition
Good point. I had indeed been thinking about this while creating the
patch. I would really be interested if you derived that from reading the
code, or testing. Eitehr way here is what I think how it should work:
If there is rootfs_data, the code wil proceed till down to the switch
statement, and then end up either in a) ramoverlay(), b)
mount_overlay(data) or c) mount_snapshot(data).

a) extroot will not happen.
b) mount_overlay calls mount_extroot
c) I didnt think of that case, and it doesnt mount extroot.

The only change, and I really hope I am not reading my code wrong (if
so, correct me please) is that besides a bunch of comments, is that when
there is no rootfs_data, and /dev/root gets mounted as /, the code
immediately returns before either a), b) or c).
> 
> 	John
> 
br
Josua Mayer


From john at phrozen.org  Wed Jun 29 03:21:58 2016
From: john at phrozen.org (John Crispin)
Date: Wed, 29 Jun 2016 12:21:58 +0200
Subject: [LEDE-DEV] fstools: ext4 overlay support - rootfs mounted twice
 bug
In-Reply-To: <d5f99997-1156-f7d3-872b-8b1f360f25e8@gmail.com>
References: <5768f92a-d15a-37f5-28c7-e7a78d6703ac@gmail.com>
 <e613fa88-80b9-77c1-d109-ff7ed3b53349@phrozen.org>
 <d5f99997-1156-f7d3-872b-8b1f360f25e8@gmail.com>
Message-ID: <1895ef93-3b5c-19fb-725b-ac889c0b045e@phrozen.org>



On 29/06/2016 12:11, Josua Mayer wrote:
> Hi John,
> 
> thansk for taking a look. I actually sent it this way by intention,
> looking to get in touch with someone who had the original bug.
> 
> Am 29.06.2016 um 08:30 schrieb John Crispin:
>> Hi,
>>
>> the patch is an attachement making inline commenting impossible. please
>> send patches inline
> From 59a8fa6d7490ba3da76aec710a1beb241ffaa089 Mon Sep 17 00:00:00 2001
> From: Josua Mayer <josua.mayer97 at gmail.com>
> Date: Thu, 16 Jun 2016 18:35:30 +0200
> Subject: [PATCH 2/4] mount_root: Don't mount ext4 rootfs twice
> 
> When there is a) no rootfs_data overlay partition,
> and b) /dev/root points to an ext4 partition
> the partition would be mounted twice, once as / and then as /overlay.
> The essence of this change is to return before mounting /overlay,
> if /dev/root has been mounted as /.
>>
> Signed-off-by: Josua Mayer <josua.mayer97 at gmail.com>
> ---
>  mount_root.c | 40 ++++++++++++++++++++++++++++++----------
>  1 file changed, 30 insertions(+), 10 deletions(-)
> 
> diff --git a/mount_root.c b/mount_root.c
> index 608ce5d..13e5772 100644
> --- a/mount_root.c
> +++ b/mount_root.c
> @@ -37,25 +37,45 @@ start(int argc, char *argv[1])
>  	if (!getenv("PREINIT") && stat("/tmp/.preinit", &s))
>  		return -1;
> 
> +	/*
> +	 * When the default overlay partition name rootfs_data can not be found,
> +	 * fall back to the special /dev/root device.
> +	 */
>  	if (!data) {
>  		root = volume_find("rootfs");
>  		volume_init(root);
> +
> +		// mount /dev/root at /
>  		ULOG_NOTE("mounting /dev/root\n");
>  		mount("/dev/root", "/", NULL, MS_NOATIME | MS_REMOUNT, 0);
> -	}
> 
> -	/*
> -	 * Before trying to mount and use "rootfs_data" let's check if there is
> -	 * extroot configured. Following call will handle reading config from
> -	 * the "rootfs_data" on its own.
> -	 */
> -	extroot_prefix = "";
> -	if (!mount_extroot()) {
> -		ULOG_NOTE("switched to extroot\n");
> +		/*
> +		 * Now that / has been mounted, and there is no overlay device,
> +		 * see if extroot is configured.
> +		 *
> +		 * The following call will handle reading configuration from
> +		 * rootfs on its own.
> +		 */
> +		extroot_prefix = "";
> +		if (!mount_extroot()) {
> +			ULOG_NOTE("switched to extroot\n");
> +			/*
> +			 * extroot succeeded mounting an overlay partition, return.
> +			 */
> +			return 0;
> +		}
> +
> +		/*
> +		 * Even if extroot was not configured, considering that no overlay
> +		 * partition was found, and / was mounted, return now.
> +		 */
>  		return 0;
>  	}
> 
> -	/* There isn't extroot, so just try to mount "rootfs_data" */
> +	/*
> +	 * neither /dev/root nor extroot were used.
> +	 * Attempt to mount the overlay partition.
> +	 */
>  	switch (volume_identify(data)) {
>  	case FS_NONE:
>  		ULOG_WARN("no usable overlay filesystem found, using tmpfs overlay\n");
> 

derived from looking at the patch. as the patch is not inline i am not
able to actually import it locally so i can only judge it by looking at it.

after applying your patch, mount_extroot() would be hidden behind a
if(!data) {} which means that it will only ever be called if there is no
rootfs_data

	John


From josua.mayer97 at gmail.com  Wed Jun 29 03:34:48 2016
From: josua.mayer97 at gmail.com (Josua Mayer)
Date: Wed, 29 Jun 2016 12:34:48 +0200
Subject: [LEDE-DEV] fstools: ext4 overlay support - rootfs mounted twice
 bug
In-Reply-To: <1895ef93-3b5c-19fb-725b-ac889c0b045e@phrozen.org>
References: <5768f92a-d15a-37f5-28c7-e7a78d6703ac@gmail.com>
 <e613fa88-80b9-77c1-d109-ff7ed3b53349@phrozen.org>
 <d5f99997-1156-f7d3-872b-8b1f360f25e8@gmail.com>
 <1895ef93-3b5c-19fb-725b-ac889c0b045e@phrozen.org>
Message-ID: <b909ff23-7c1b-8833-4111-e8018a620635@gmail.com>



Am 29.06.2016 um 12:21 schrieb John Crispin:
> 
> 
> On 29/06/2016 12:11, Josua Mayer wrote:
>> Hi John,
>>
>> thansk for taking a look. I actually sent it this way by intention,
>> looking to get in touch with someone who had the original bug.
>>
>> Am 29.06.2016 um 08:30 schrieb John Crispin:
>>> Hi,
>>>
>>> the patch is an attachement making inline commenting impossible. please
>>> send patches inline
>> From 59a8fa6d7490ba3da76aec710a1beb241ffaa089 Mon Sep 17 00:00:00 2001
>> From: Josua Mayer <josua.mayer97 at gmail.com>
>> Date: Thu, 16 Jun 2016 18:35:30 +0200
>> Subject: [PATCH 2/4] mount_root: Don't mount ext4 rootfs twice
>>
>> When there is a) no rootfs_data overlay partition,
>> and b) /dev/root points to an ext4 partition
>> the partition would be mounted twice, once as / and then as /overlay.
>> The essence of this change is to return before mounting /overlay,
>> if /dev/root has been mounted as /.
>>>
>> Signed-off-by: Josua Mayer <josua.mayer97 at gmail.com>
>> ---
>>  mount_root.c | 40 ++++++++++++++++++++++++++++++----------
>>  1 file changed, 30 insertions(+), 10 deletions(-)
>>
>> diff --git a/mount_root.c b/mount_root.c
>> index 608ce5d..13e5772 100644
>> --- a/mount_root.c
>> +++ b/mount_root.c
>> @@ -37,25 +37,45 @@ start(int argc, char *argv[1])
>>  	if (!getenv("PREINIT") && stat("/tmp/.preinit", &s))
>>  		return -1;
>>
>> +	/*
>> +	 * When the default overlay partition name rootfs_data can not be found,
>> +	 * fall back to the special /dev/root device.
>> +	 */
>>  	if (!data) {
>>  		root = volume_find("rootfs");
>>  		volume_init(root);
>> +
>> +		// mount /dev/root at /
>>  		ULOG_NOTE("mounting /dev/root\n");
>>  		mount("/dev/root", "/", NULL, MS_NOATIME | MS_REMOUNT, 0);
>> -	}
>>
>> -	/*
>> -	 * Before trying to mount and use "rootfs_data" let's check if there is
>> -	 * extroot configured. Following call will handle reading config from
>> -	 * the "rootfs_data" on its own.
>> -	 */
>> -	extroot_prefix = "";
>> -	if (!mount_extroot()) {
>> -		ULOG_NOTE("switched to extroot\n");
>> +		/*
>> +		 * Now that / has been mounted, and there is no overlay device,
>> +		 * see if extroot is configured.
>> +		 *
>> +		 * The following call will handle reading configuration from
>> +		 * rootfs on its own.
>> +		 */
>> +		extroot_prefix = "";
>> +		if (!mount_extroot()) {
>> +			ULOG_NOTE("switched to extroot\n");
>> +			/*
>> +			 * extroot succeeded mounting an overlay partition, return.
>> +			 */
>> +			return 0;
>> +		}
>> +
>> +		/*
>> +		 * Even if extroot was not configured, considering that no overlay
>> +		 * partition was found, and / was mounted, return now.
>> +		 */
>>  		return 0;
>>  	}
>>
>> -	/* There isn't extroot, so just try to mount "rootfs_data" */
>> +	/*
>> +	 * neither /dev/root nor extroot were used.
>> +	 * Attempt to mount the overlay partition.
>> +	 */
>>  	switch (volume_identify(data)) {
>>  	case FS_NONE:
>>  		ULOG_WARN("no usable overlay filesystem found, using tmpfs overlay\n");
>>
> 
> derived from looking at the patch. as the patch is not inline i am not
> able to actually import it locally so i can only judge it by looking at it.
> 
> after applying your patch, mount_extroot() would be hidden behind a
> if(!data) {} which means that it will only ever be called if there is no
> rootfs_data
That is only partially right. Like I pointed out, it is called inside
mount_overlay().
If there is a way to fix this, I need to understand what should happen:
code path before my patch:
data = volume_find("rootfs_data");
if (!data) {/* mount /dev/root as / */}
mount_extroot()
switch (volume_identify(data))

>From this artificial trace, I extracted these runtime conditions for
extroot:
1. rootfs_data exists but not mounted yet
2. rootfs_data does not exist and /dev/root mounted as /
I then guessed that mount_extroot only makes sense when there is an
overlay partition, or the read-write rootfs mounted in order to have its
configuration available.
So my guess was: if overlay isnt mounted yet but will be later, no point
in executing mount_extroot. Especially considering it will be inherently
called from the call to mount_overlay thats occuring later on.
> 
> 	John
> 


From john at phrozen.org  Wed Jun 29 03:38:22 2016
From: john at phrozen.org (John Crispin)
Date: Wed, 29 Jun 2016 12:38:22 +0200
Subject: [LEDE-DEV] fstools: ext4 overlay support - rootfs mounted twice
 bug
In-Reply-To: <b909ff23-7c1b-8833-4111-e8018a620635@gmail.com>
References: <5768f92a-d15a-37f5-28c7-e7a78d6703ac@gmail.com>
 <e613fa88-80b9-77c1-d109-ff7ed3b53349@phrozen.org>
 <d5f99997-1156-f7d3-872b-8b1f360f25e8@gmail.com>
 <1895ef93-3b5c-19fb-725b-ac889c0b045e@phrozen.org>
 <b909ff23-7c1b-8833-4111-e8018a620635@gmail.com>
Message-ID: <13438932-c196-2747-66ac-1807841b9048@phrozen.org>



On 29/06/2016 12:34, Josua Mayer wrote:
> 
> 
> Am 29.06.2016 um 12:21 schrieb John Crispin:
>>
>>
>> On 29/06/2016 12:11, Josua Mayer wrote:
>>> Hi John,
>>>
>>> thansk for taking a look. I actually sent it this way by intention,
>>> looking to get in touch with someone who had the original bug.
>>>
>>> Am 29.06.2016 um 08:30 schrieb John Crispin:
>>>> Hi,
>>>>
>>>> the patch is an attachement making inline commenting impossible. please
>>>> send patches inline
>>> From 59a8fa6d7490ba3da76aec710a1beb241ffaa089 Mon Sep 17 00:00:00 2001
>>> From: Josua Mayer <josua.mayer97 at gmail.com>
>>> Date: Thu, 16 Jun 2016 18:35:30 +0200
>>> Subject: [PATCH 2/4] mount_root: Don't mount ext4 rootfs twice
>>>
>>> When there is a) no rootfs_data overlay partition,
>>> and b) /dev/root points to an ext4 partition
>>> the partition would be mounted twice, once as / and then as /overlay.
>>> The essence of this change is to return before mounting /overlay,
>>> if /dev/root has been mounted as /.
>>>>
>>> Signed-off-by: Josua Mayer <josua.mayer97 at gmail.com>
>>> ---
>>>  mount_root.c | 40 ++++++++++++++++++++++++++++++----------
>>>  1 file changed, 30 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/mount_root.c b/mount_root.c
>>> index 608ce5d..13e5772 100644
>>> --- a/mount_root.c
>>> +++ b/mount_root.c
>>> @@ -37,25 +37,45 @@ start(int argc, char *argv[1])
>>>  	if (!getenv("PREINIT") && stat("/tmp/.preinit", &s))
>>>  		return -1;
>>>
>>> +	/*
>>> +	 * When the default overlay partition name rootfs_data can not be found,
>>> +	 * fall back to the special /dev/root device.
>>> +	 */
>>>  	if (!data) {
>>>  		root = volume_find("rootfs");
>>>  		volume_init(root);
>>> +
>>> +		// mount /dev/root at /
>>>  		ULOG_NOTE("mounting /dev/root\n");
>>>  		mount("/dev/root", "/", NULL, MS_NOATIME | MS_REMOUNT, 0);
>>> -	}
>>>
>>> -	/*
>>> -	 * Before trying to mount and use "rootfs_data" let's check if there is
>>> -	 * extroot configured. Following call will handle reading config from
>>> -	 * the "rootfs_data" on its own.
>>> -	 */
>>> -	extroot_prefix = "";
>>> -	if (!mount_extroot()) {
>>> -		ULOG_NOTE("switched to extroot\n");
>>> +		/*
>>> +		 * Now that / has been mounted, and there is no overlay device,
>>> +		 * see if extroot is configured.
>>> +		 *
>>> +		 * The following call will handle reading configuration from
>>> +		 * rootfs on its own.
>>> +		 */
>>> +		extroot_prefix = "";
>>> +		if (!mount_extroot()) {
>>> +			ULOG_NOTE("switched to extroot\n");
>>> +			/*
>>> +			 * extroot succeeded mounting an overlay partition, return.
>>> +			 */
>>> +			return 0;
>>> +		}
>>> +
>>> +		/*
>>> +		 * Even if extroot was not configured, considering that no overlay
>>> +		 * partition was found, and / was mounted, return now.
>>> +		 */
>>>  		return 0;
>>>  	}
>>>
>>> -	/* There isn't extroot, so just try to mount "rootfs_data" */
>>> +	/*
>>> +	 * neither /dev/root nor extroot were used.
>>> +	 * Attempt to mount the overlay partition.
>>> +	 */
>>>  	switch (volume_identify(data)) {
>>>  	case FS_NONE:
>>>  		ULOG_WARN("no usable overlay filesystem found, using tmpfs overlay\n");
>>>
>>
>> derived from looking at the patch. as the patch is not inline i am not
>> able to actually import it locally so i can only judge it by looking at it.
>>
>> after applying your patch, mount_extroot() would be hidden behind a
>> if(!data) {} which means that it will only ever be called if there is no
>> rootfs_data
> That is only partially right. Like I pointed out, it is called inside
> mount_overlay().
> If there is a way to fix this, I need to understand what should happen:
> code path before my patch:
> data = volume_find("rootfs_data");
> if (!data) {/* mount /dev/root as / */}
> mount_extroot()
> switch (volume_identify(data))
> 
> From this artificial trace, I extracted these runtime conditions for
> extroot:
> 1. rootfs_data exists but not mounted yet
> 2. rootfs_data does not exist and /dev/root mounted as /
> I then guessed that mount_extroot only makes sense when there is an
> overlay partition, or the read-write rootfs mounted in order to have its
> configuration available.
> So my guess was: if overlay isnt mounted yet but will be later, no point
> in executing mount_extroot. Especially considering it will be inherently
> called from the call to mount_overlay thats occuring later on.
>>
>> 	John
>>
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 

send a proper inline patch so i can test this on device please.

	John


From josua.mayer97 at gmail.com  Wed Jun 29 03:45:40 2016
From: josua.mayer97 at gmail.com (josua.mayer97 at gmail.com)
Date: Wed, 29 Jun 2016 12:45:40 +0200
Subject: [LEDE-DEV] [PATCH 2/2] mount_root: Don't mount ext4 rootfs twice
In-Reply-To: <1467197140-8004-1-git-send-email-josua.mayer97@gmail.com>
References: <1467197140-8004-1-git-send-email-josua.mayer97@gmail.com>
Message-ID: <1467197140-8004-2-git-send-email-josua.mayer97@gmail.com>

From: Josua Mayer <josua.mayer97 at gmail.com>

When there is a) no rootfs_data overlay partition,
and b) /dev/root points to an ext4 partition
the partition would be mounted twice, once as / and then as /overlay.
The essence of this change is to return before mounting /overlay,
if /dev/root has been mounted as /.

Signed-off-by: Josua Mayer <josua.mayer97 at gmail.com>
---
 mount_root.c | 40 ++++++++++++++++++++++++++++++----------
 1 file changed, 30 insertions(+), 10 deletions(-)

diff --git a/mount_root.c b/mount_root.c
index 608ce5d..13e5772 100644
--- a/mount_root.c
+++ b/mount_root.c
@@ -37,25 +37,45 @@ start(int argc, char *argv[1])
 	if (!getenv("PREINIT") && stat("/tmp/.preinit", &s))
 		return -1;
 
+	/*
+	 * When the default overlay partition name rootfs_data can not be found,
+	 * fall back to the special /dev/root device.
+	 */
 	if (!data) {
 		root = volume_find("rootfs");
 		volume_init(root);
+
+		// mount /dev/root at /
 		ULOG_NOTE("mounting /dev/root\n");
 		mount("/dev/root", "/", NULL, MS_NOATIME | MS_REMOUNT, 0);
-	}
 
-	/*
-	 * Before trying to mount and use "rootfs_data" let's check if there is
-	 * extroot configured. Following call will handle reading config from
-	 * the "rootfs_data" on its own.
-	 */
-	extroot_prefix = "";
-	if (!mount_extroot()) {
-		ULOG_NOTE("switched to extroot\n");
+		/*
+		 * Now that / has been mounted, and there is no overlay device,
+		 * see if extroot is configured.
+		 * 
+		 * The following call will handle reading configuration from
+		 * rootfs on its own.
+		 */
+		extroot_prefix = "";
+		if (!mount_extroot()) {
+			ULOG_NOTE("switched to extroot\n");
+			/*
+			 * extroot succeeded mounting an overlay partition, return.
+			 */
+			return 0;
+		}
+
+		/*
+		 * Even if extroot was not configured, considering that no overlay
+		 * partition was found, and / was mounted, return now.
+		 */
 		return 0;
 	}
 
-	/* There isn't extroot, so just try to mount "rootfs_data" */
+	/*
+	 * neither /dev/root nor extroot were used.
+	 * Attempt to mount the overlay partition.
+	 */
 	switch (volume_identify(data)) {
 	case FS_NONE:
 		ULOG_WARN("no usable overlay filesystem found, using tmpfs overlay\n");
-- 
2.6.6



From josua.mayer97 at gmail.com  Wed Jun 29 03:45:39 2016
From: josua.mayer97 at gmail.com (josua.mayer97 at gmail.com)
Date: Wed, 29 Jun 2016 12:45:39 +0200
Subject: [LEDE-DEV] [PATCH 1/2] fstools: support for ext4fs overlay
Message-ID: <1467197140-8004-1-git-send-email-josua.mayer97@gmail.com>

From: Ram Chandra Jangir <rjangi at codeaurora.org>

This change will enables eMMC (ext4 fs) boot support, when we try to boot
from eMMC card then it will read partition names from
/sys/block/mmcblkX/mmcblkXY/uevent
file and will mount the rootfs_data partition as ext4fs overlay.

Signed-off-by: Ram Chandra Jangir <rjangi at codeaurora.org>
---
 CMakeLists.txt          |   1 +
 libfstools/ext4.c       | 193 ++++++++++++++++++++++++++++++++++++++++++++++++
 libfstools/find.c       |   3 +-
 libfstools/libfstools.h |   1 +
 libfstools/overlay.c    |  14 ++++
 libfstools/volume.h     |   1 +
 mount_root.c            |   2 +
 7 files changed, 214 insertions(+), 1 deletion(-)
 create mode 100644 libfstools/ext4.c

diff --git a/CMakeLists.txt b/CMakeLists.txt
index a6002e5..5117e8e 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -11,6 +11,7 @@ ADD_LIBRARY(fstools SHARED
 		libfstools/overlay.c
 		libfstools/volume.c
 		libfstools/mtd.c
+		libfstools/ext4.c
 		libfstools/mount.c
 		libfstools/ubi.c
 		libfstools/find.c)
diff --git a/libfstools/ext4.c b/libfstools/ext4.c
new file mode 100644
index 0000000..f648aa8
--- /dev/null
+++ b/libfstools/ext4.c
@@ -0,0 +1,193 @@
+/*
+ * Copyright (c) 2016, The Linux Foundation. All rights reserved.
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+*/
+
+
+#include <sys/mount.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <fcntl.h>
+#include <asm/byteorder.h>
+#include <unistd.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <mtd/mtd-user.h>
+#include <glob.h>
+
+#include "libfstools.h"
+
+#include "volume.h"
+
+#define ext4_sysfs_path "/sys/block/mmcblk*/mmcblk*/uevent"
+#define MAX_SIZE	128
+
+#define EXT_SB_OFF	0x400
+#define EXT_SB_KBOFF	(EXT_SB_OFF >> 10)
+#define EXT_SB_MAGIC	"\123\357"
+#define EXT_MAG_OFF	0x38
+
+struct ext4_priv {
+	char	*name;
+	char    *devname;
+};
+
+static struct driver ext4_driver;
+
+static int ext4_volume_init(struct volume *v)
+{
+	char buf[MAX_SIZE];
+	struct ext4_priv *p;
+
+	p = (struct ext4_priv*)v->priv;
+	snprintf(buf, sizeof(buf), "/dev/%s",p->devname);
+
+	v->name = strdup(p->name);
+	v->type = EXT4VOLUME;
+	v->blk = strdup(buf);
+	return 0;
+}
+
+static int
+ext4_part_match(char *dev, char *name, char *filename)
+{
+	FILE *fp;
+	char buf[MAX_SIZE];
+	char devname[MAX_SIZE];
+	int i;
+	int ret = -1;
+
+	fp = fopen(filename, "r");
+	if (!fp)
+		return ret;
+
+	while (fgets(buf, sizeof(buf), fp))  {
+		if (strstr(buf, "DEVNAME"))  {
+			strcpy(devname, buf + strlen("DEVNAME="));
+			continue;
+		}
+		/* Match partition name */
+		if (strstr(buf, name))  {
+			ret = 0;
+			break;
+		}
+	}
+
+	fclose(fp);
+
+	/* make sure the string is \0 terminated */
+	devname[sizeof(devname) - 1] = '\0';
+
+	/* remove trailing whitespace */
+	i = strlen(devname) - 1;
+	while (i > 0 && devname[i] <= ' ')
+		devname[i--] = '\0';
+
+	strcpy(dev, devname);
+	return ret;
+}
+
+static int ext4_find_devname(char *dev, char *name)
+{
+	int i;
+	glob_t gl;
+
+	if (glob(ext4_sysfs_path, GLOB_NOESCAPE | GLOB_MARK, NULL, &gl) < 0)
+		return -1;
+
+	for (i = 0; i < gl.gl_pathc; i++) {
+		if (!ext4_part_match(dev, name, gl.gl_pathv[i])) {
+			globfree(&gl);
+			return 0;
+		}
+	}
+
+	globfree(&gl);
+	return -1;
+}
+
+static int check_for_mtd(const char *mtd)
+{
+	FILE *fp;
+	char dev[MAX_SIZE];
+
+	if ((fp = fopen("/proc/mtd", "r"))) {
+		while (fgets(dev, sizeof(dev), fp)) {
+			if (strstr(dev, mtd)) {
+				fclose(fp);
+				return -1;
+			}
+		}
+	}
+	fclose(fp);
+	return 0;
+}
+
+static int ext4_volume_find(struct volume *v, char *name)
+{
+	char buf[MAX_SIZE];
+	struct ext4_priv *p;
+
+	if (find_filesystem("ext4"))
+		return -1;
+
+	if (check_for_mtd(name))
+		return -1;
+
+	if (ext4_find_devname(buf, name))
+		return -1;
+
+        p = calloc(1, sizeof(struct ext4_priv));
+        if (!p)
+                return -1;
+
+        v->priv = p;
+        v->drv = &ext4_driver;
+
+        p->devname = strdup(buf);
+        p->name = strdup(name);
+        return ext4_volume_init(v);
+}
+
+static int ext4_volume_identify(struct volume *v)
+{
+	char magic[32] = { 0 };
+	int off = (EXT_SB_KBOFF * 1024) + EXT_MAG_OFF;
+	int fd;
+
+	fd = open(v->blk, O_RDONLY);
+	if (fd == -1)
+		return -1;
+
+	lseek(fd, off, SEEK_SET);
+	read(fd, magic, sizeof(EXT_SB_MAGIC) - 1);
+	close(fd);
+
+	if (v->type == EXT4VOLUME &&
+	    !memcmp(EXT_SB_MAGIC, magic, sizeof(EXT_SB_MAGIC) - 1)) {
+		return FS_EXT4FS;
+	}
+
+	ULOG_ERR("ext4 is not ready - marker found\n");
+	return FS_DEADCODE;
+}
+
+static struct driver ext4_driver = {
+        .name = "ext4",
+        .find = ext4_volume_find,
+        .init = ext4_volume_init,
+        .identify = ext4_volume_identify,
+};
+
+DRIVER(ext4_driver);
diff --git a/libfstools/find.c b/libfstools/find.c
index 0440052..9fd83c9 100644
--- a/libfstools/find.c
+++ b/libfstools/find.c
@@ -102,7 +102,8 @@ find_mount_point(char *block, int mtd_only)
 
 			if (mtd_only &&
 			    strncmp(t, "jffs2", 5) &&
-			    strncmp(t, "ubifs", 5)) {
+			    strncmp(t, "ubifs", 5) &&
+			    strncmp(t, "ext4", 4)) {
 				fclose(fp);
 				ULOG_ERR("block is mounted with wrong fs\n");
 				return NULL;
diff --git a/libfstools/libfstools.h b/libfstools/libfstools.h
index 31d9f9e..940c504 100644
--- a/libfstools/libfstools.h
+++ b/libfstools/libfstools.h
@@ -26,6 +26,7 @@ enum {
 	FS_JFFS2,
 	FS_DEADCODE,
 	FS_UBIFS,
+	FS_EXT4FS,
 };
 
 enum fs_state {
diff --git a/libfstools/overlay.c b/libfstools/overlay.c
index cdac23e..f8088f9 100644
--- a/libfstools/overlay.c
+++ b/libfstools/overlay.c
@@ -245,6 +245,16 @@ jffs2_switch(struct volume *v)
 			ret = -1;
 		}
 		break;
+
+	case FS_EXT4FS:
+		ret = overlay_mount(v, "ext4");
+		if (ret)
+			break;
+		if (mount_move("/tmp", "", "/overlay") || fopivot("/overlay", "/rom")) {
+			ULOG_ERR("switching to ext4fs failed\n");
+			ret = -1;
+		}
+		break;
 	}
 
 	if (ret)
@@ -270,6 +280,10 @@ static int overlay_mount_fs(struct volume *v)
 	case FS_UBIFS:
 		fstype = "ubifs";
 		break;
+
+	case FS_EXT4FS:
+		fstype = "ext4";
+		break;
 	}
 
 	volume_init(v);
diff --git a/libfstools/volume.h b/libfstools/volume.h
index 9c679f7..b74bd50 100644
--- a/libfstools/volume.h
+++ b/libfstools/volume.h
@@ -47,6 +47,7 @@ enum {
 	NANDFLASH,
 	NORFLASH,
 	UBIVOLUME,
+	EXT4VOLUME,
 };
 
 struct volume {
diff --git a/mount_root.c b/mount_root.c
index 6e06b45..608ce5d 100644
--- a/mount_root.c
+++ b/mount_root.c
@@ -72,6 +72,7 @@ start(int argc, char *argv[1])
 
 	case FS_JFFS2:
 	case FS_UBIFS:
+	case FS_EXT4FS:
 		mount_overlay(data);
 		break;
 
@@ -110,6 +111,7 @@ done(int argc, char *argv[1])
 
 	case FS_JFFS2:
 	case FS_UBIFS:
+	case FS_EXT4FS:
 		fs_state_set("/overlay", FS_STATE_READY);
 		break;
 	}
-- 
2.6.6



From daniel at makrotopia.org  Wed Jun 29 04:04:56 2016
From: daniel at makrotopia.org (Daniel Golle)
Date: Wed, 29 Jun 2016 13:04:56 +0200
Subject: [LEDE-DEV] [Bug CC 15.05.1] ath9k crashes on TL-WR1043NDv1
Message-ID: <20160629110454.GA1148@makrotopia.org>

Hi!

I got an interesting bug on a quite ancient ath9k system which used
to run stable on BB.
Can anyone with more insight of ath9k tell me what's going on?


DISTRIB_RELEASE='Chaos Calmer'
DISTRIB_REVISION='r49378'

system type		: Atheros AR9132 rev 2
machine			: TP-LINK TL-WR1043ND

dmesg:
...
[   12.580000] ath: EEPROM regdomain: 0x0
[   12.580000] ath: EEPROM indicates default country code should be used
[   12.580000] ath: doing EEPROM country->regdmn map search
[   12.580000] ath: country maps to regdmn code: 0x3a
[   12.580000] ath: Country alpha2 being used: US
[   12.580000] ath: Regpair used: 0x3a
[   12.600000] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[   12.610000] ieee80211 phy0: Atheros AR9100 MAC/BB Rev:7 AR2133 RF Rev:a2 mem=0xb80c0000, irq=2
...
[   25.230000] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0-adhoc: link becomes ready
[   25.470000] batman_adv: bat0: Adding interface: wlan0-adhoc_118
[   25.480000] batman_adv: bat0: Interface activated: wlan0-adhoc_118
[   26.970000] br-lan: port 3(wlan0-ap) entered forwarding state
[   27.470000] ip6_tunnel: bmxmain xmit: Local address not yet configured!
[   31.990000] random: nonblocking pool is initialized
[   89.600000] batman_adv: bat0: Changing gw mode from: client to: server
[  671.390000] icmp6_send: no reply to icmp error
[  952.060000] ath: phy0: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42100020 DMADBG_7=0x000084c0
[ 2131.160000] icmp6_send: no reply to icmp error
[ 2291.770000] icmp6_send: no reply to icmp error
[ 2557.400000] icmp6_send: no reply to icmp error
[ 2863.590000] ath: phy0: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42100020 DMADBG_7=0x000084c0
[ 2909.570000] ath: phy0: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42100020 DMADBG_7=0x000084c0
[ 3557.080000] icmp6_send: no reply to icmp error
[ 6453.930000] ath: phy0: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42100020 DMADBG_7=0x000084c0
[ 6502.930000] icmp6_send: no reply to icmp error
[ 7496.600000] icmp6_send: no reply to icmp error
[ 8757.240000] icmp6_send: no reply to icmp error
[10168.610000] icmp6_send: no reply to icmp error
[10173.080000] icmp6_send: no reply to icmp error
[11001.470000] br-lan: received packet on bat0 with own address as source address
[11001.480000] br-lan: received packet on bat0 with own address as source address
[12771.390000] ath: phy0: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42100020 DMADBG_7=0x000084c0
[14479.360000] ath: phy0: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42100020 DMADBG_7=0x000084c0
[14693.990000] ath: phy0: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42100020 DMADBG_7=0x000084c0
[15713.240000] icmp6_send: no reply to icmp error
[15756.350000] ath: phy0: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42100020 DMADBG_7=0x000286c0
[22268.510000] ath: phy0: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42100020 DMADBG_7=0x000286c0
[41164.150000] ath: phy0: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42100020 DMADBG_7=0x000084c0
[43582.350000] ------------[ cut here ]------------
[43582.350000] WARNING: CPU: 0 PID: 0 at /usr/src/openwrt-15.05/build_dir/target-mips_34kc_uClibc-0.9.33.2/linux-ar71xx_generic/compat-wireless-2016-01-10/net/mac80211/rx.c:3617 ieee80211_rx_napi+0x140/0x854 [mac80211]()
[43582.370000] Rate marked as an HT rate but passed status->rate_idx is not an MCS index [0-76]: 77 (0x4d)
[43582.380000] Modules linked in: iptable_nat ath9k nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT ipt_MASQUERADE ebtable_nat ebtable_filter ebtable_broute ath9k_common xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_id xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_NETMAP xt_LOG xt_CT nf_reject_ipv4 nf_nat_masquerade_ipv4 nf_nat_ftp nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack_ftp nf_conntrack macvlan mac80211 iptable_raw iptable_mangle iptable_filter ip_tables ebtables ebt_vlan ebt_stp ebt_redirect ebt_pkttype ebt_mark_m ebt_mark ebt_limit ebt_among ebt_802_3 crc_ccitt ath9k_hw ath batman_adv libcrc32c cfg80211 compat ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables dummy ip6_tunnel tunnel6 tun ipv6 arc4 crypto_blkcipher gpio_button_hotplug crc16 crc32c_generic crypto_hash
[43582.460000] CPU: 0 PID: 0 Comm: swapper Not tainted 3.18.29 #1
[43582.470000] Stack : 00000000 00000000 00000000 00000000 803b4292 00000032 00000000 80e22d00
[43582.470000]    00000001 00000000 80304d78 8035aae3 00000000 803b34d0 8035ae18 00000000
[43582.470000]    00000000 81ff9cd8 803d0000 800a36c4 00000003 8008049c 00000e21 00000000
[43582.470000]    80308370 80355ba4 00000000 00000000 00000000 00000000 00000000 00000000
[43582.470000]    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[43582.470000]    ...
[43582.510000] Call Trace:
[43582.510000] [<80071090>] show_stack+0x50/0x84
[43582.510000] [<800805a4>] warn_slowpath_common+0x84/0xb4
[43582.520000] [<80080600>] warn_slowpath_fmt+0x2c/0x38
[43582.520000] [<80e22d00>] ieee80211_rx_napi+0x140/0x854 [mac80211]
[43582.530000] [<80dc6420>] ath_rx_tasklet+0x9c0/0xa0c [ath9k]
[43582.530000] [<80dc3e68>] ath9k_tasklet+0x1ac/0x230 [ath9k]
[43582.540000] [<80083194>] tasklet_action+0x84/0xcc
[43582.550000] [<80082aa4>] __do_softirq+0xf8/0x230
[43582.550000] [<80082e10>] irq_exit+0x54/0x70
[43582.550000] [<80060830>] ret_from_irq+0x0/0x4
[43582.560000] [<80060a80>] __r4k_wait+0x20/0x40
[43582.560000] [<8009f644>] cpu_startup_entry+0xf0/0x13c
[43582.570000] [<80373b5c>] start_kernel+0x42c/0x444
[43582.570000] 
[43582.570000] ---[ end trace 032e1f77966f4f24 ]---
[43775.730000] ath: phy0: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42100020 DMADBG_7=0x000084c0
[47329.650000] br-lan: received packet on bat0 with own address as source address
[47329.660000] br-lan: received packet on bat0 with own address as source address
[47721.870000] icmp6_send: no reply to icmp error
[48588.260000] ath: phy0: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42100020 DMADBG_7=0x000084c0
[51549.590000] br-lan: received packet on bat0 with own address as source address
[51549.600000] br-lan: received packet on bat0 with own address as source address
[51549.610000] br-lan: received packet on bat0 with own address as source address
[51549.620000] br-lan: received packet on bat0 with own address as source address
[51549.620000] br-lan: received packet on bat0 with own address as source address
[51549.630000] br-lan: received packet on bat0 with own address as source address
[51696.280000] icmp6_send: no reply to icmp error
[57182.090000] br-lan: received packet on bat0 with own address as source address
[57182.100000] br-lan: received packet on bat0 with own address as source address
[59860.980000] br-lan: received packet on bat0 with own address as source address
[59860.980000] br-lan: received packet on bat0 with own address as source address
[60051.210000] ------------[ cut here ]------------
[60051.220000] WARNING: CPU: 0 PID: 1140 at /usr/src/openwrt-15.05/build_dir/target-mips_34kc_uClibc-0.9.33.2/linux-ar71xx_generic/compat-wireless-2016-01-10/include/net/mac80211.h:5372 ieee80211_mps_frame_release+0x8cc/0xd7c [mac80211]()
[60051.240000] Modules linked in: iptable_nat ath9k nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT ipt_MASQUERADE ebtable_nat ebtable_filter ebtable_broute ath9k_common xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_id xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_NETMAP xt_LOG xt_CT nf_reject_ipv4 nf_nat_masquerade_ipv4 nf_nat_ftp nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack_ftp nf_conntrack macvlan mac80211 iptable_raw iptable_mangle iptable_filter ip_tables ebtables ebt_vlan ebt_stp ebt_redirect ebt_pkttype ebt_mark_m ebt_mark ebt_limit ebt_among ebt_802_3 crc_ccitt ath9k_hw ath batman_adv libcrc32c cfg80211 compat ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables dummy ip6_tunnel tunnel6 tun ipv6 arc4 crypto_blkcipher gpio_button_hotplug crc16 crc32c_generic crypto_hash
[60051.320000] CPU: 0 PID: 1140 Comm: hostapd Tainted: G        W      3.18.29 #1
[60051.330000] Stack : 00000000 00000000 00000000 00000000 803b4292 00000042 00000000 80e4b9ac
[60051.330000]    00000001 00000000 80304d78 8035aae3 00000474 803b34d0 819b1f58 00000000
[60051.330000]    00000004 81c90584 00000008 800a36c4 00000003 80080428 000014fc 00000000
[60051.330000]    80308370 80fbb9ec 00000000 00000000 00000000 00000000 00000000 00000000
[60051.330000]    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[60051.330000]    ...
[60051.360000] Call Trace:
[60051.370000] [<80071090>] show_stack+0x50/0x84
[60051.370000] [<800805a4>] warn_slowpath_common+0x84/0xb4
[60051.380000] [<8008065c>] warn_slowpath_null+0x18/0x24
[60051.380000] [<80e4b9ac>] ieee80211_mps_frame_release+0x8cc/0xd7c [mac80211]
[60051.390000] 
[60051.390000] ---[ end trace 032e1f77966f4f25 ]---
[60056.100000] ------------[ cut here ]------------
[60056.100000] WARNING: CPU: 0 PID: 17916 at /usr/src/openwrt-15.05/build_dir/target-mips_34kc_uClibc-0.9.33.2/linux-ar71xx_generic/compat-wireless-2016-01-10/net/mac80211/rate.c:625 ieee80211_get_tx_rates+0x4ac/0x5a8 [mac80211]()
[60056.120000] Modules linked in: iptable_nat ath9k nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT ipt_MASQUERADE ebtable_nat ebtable_filter ebtable_broute ath9k_common xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_id xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_NETMAP xt_LOG xt_CT nf_reject_ipv4 nf_nat_masquerade_ipv4 nf_nat_ftp nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack_ftp nf_conntrack macvlan mac80211 iptable_raw iptable_mangle iptable_filter ip_tables ebtables ebt_vlan ebt_stp ebt_redirect ebt_pkttype ebt_mark_m ebt_mark ebt_limit ebt_among ebt_802_3 crc_ccitt ath9k_hw ath batman_adv libcrc32c cfg80211 compat ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables dummy ip6_tunnel tunnel6 tun ipv6 arc4 crypto_blkcipher gpio_button_hotplug crc16 crc32c_generic crypto_hash
[60056.200000] CPU: 0 PID: 17916 Comm: kworker/u2:1 Tainted: G        W      3.18.29 #1
[60056.210000] Workqueue: phy0 ath_reset_work [ath9k]
[60056.220000] Stack : 00000001 00000000 81fd7800 80304d78 80e56204 80e17384 00000271 00000000
[60056.220000]    00000004 80e60000 00000001 800a36c4 000045fc 800962d4 819b15a8 00000000
[60056.220000]    803159dc 80df3bf4 80df3bf4 800a36c4 00000003 80093cc4 00000271 00000000
[60056.220000]    00000000 801d4dfc 00000000 00000000 00000000 00000000 00000000 00000000
[60056.220000]    70687930 00000000 00000000 00000000 00000000 00000000 80c66c00 80c66d00
[60056.220000]    ...
[60056.250000] Call Trace:
[60056.250000] [<80071090>] show_stack+0x50/0x84
[60056.260000] [<800805a4>] warn_slowpath_common+0x84/0xb4
[60056.260000] [<8008065c>] warn_slowpath_null+0x18/0x24
[60056.270000] [<80e17384>] ieee80211_get_tx_rates+0x4ac/0x5a8 [mac80211]
[60056.280000] [<80dc737c>] ath_stoprecv+0xf10/0x1164 [ath9k]
[60056.280000] [<80dc8948>] ath_txq_schedule+0x190/0x728 [ath9k]
[60056.290000] [<80dc9bbc>] ath_txq_schedule_all+0x44/0x78 [ath9k]
[60056.290000] [<80dc4510>] ath9k_calculate_summary_state+0x468/0x664 [ath9k]
[60056.300000] 
[60056.300000] ---[ end trace 032e1f77966f4f26 ]---
[60162.960000] ------------[ cut here ]------------
[60162.960000] WARNING: CPU: 0 PID: 1140 at /usr/src/openwrt-15.05/build_dir/target-mips_34kc_uClibc-0.9.33.2/linux-ar71xx_generic/compat-wireless-2016-01-10/net/mac80211/rate.c:311 ieee80211_rate_control_unregister+0x1b8/0x494 [mac80211]()
[60162.980000] no supported rates (0x0) in rate_mask 0xfff with flags 0x0
[60162.990000] Modules linked in: iptable_nat ath9k nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT ipt_MASQUERADE ebtable_nat ebtable_filter ebtable_broute ath9k_common xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_id xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_NETMAP xt_LOG xt_CT nf_reject_ipv4 nf_nat_masquerade_ipv4 nf_nat_ftp nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack_ftp nf_conntrack macvlan mac80211 iptable_raw iptable_mangle iptable_filter ip_tables ebtables ebt_vlan ebt_stp ebt_redirect ebt_pkttype ebt_mark_m ebt_mark ebt_limit ebt_among ebt_802_3 crc_ccitt ath9k_hw ath batman_adv libcrc32c cfg80211 compat ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables dummy ip6_tunnel tunnel6 tun ipv6 arc4 crypto_blkcipher gpio_button_hotplug crc16 crc32c_generic crypto_hash
[60163.070000] CPU: 0 PID: 1140 Comm: hostapd Tainted: G        W      3.18.29 #1
[60163.080000] Stack : 00000000 00000000 00000000 00000000 803b4292 00000042 00000000 80e166a0
[60163.080000]    00000001 00000000 80304d78 8035aae3 00000474 803b34d0 819b1f58 00000000
[60163.080000]    00000004 80f3a440 80fbbbd0 800a36c4 00000003 80080428 00000137 00000000
[60163.080000]    80308370 80fbb8ac 00000000 00000000 00000000 00000000 00000000 00000000
[60163.080000]    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[60163.080000]    ...
[60163.120000] Call Trace:
[60163.120000] [<80071090>] show_stack+0x50/0x84
[60163.120000] [<800805a4>] warn_slowpath_common+0x84/0xb4
[60163.130000] [<80080600>] warn_slowpath_fmt+0x2c/0x38
[60163.130000] [<80e166a0>] ieee80211_rate_control_unregister+0x1b8/0x494 [mac80211]
[60163.140000] 
[60163.140000] ---[ end trace 032e1f77966f4f27 ]---
[60852.600000] icmp6_send: no reply to icmp error
[61311.010000] br-lan: received packet on bat0 with own address as source address
[61311.010000] br-lan: received packet on bat0 with own address as source address
[61311.020000] br-lan: received packet on bat0 with own address as source address
[62631.770000] br-lan: received packet on bat0 with own address as source address
[62631.780000] br-lan: received packet on bat0 with own address as source address
[63331.530000] br-lan: received packet on bat0 with own address as source address
[63331.540000] br-lan: received packet on bat0 with own address as source address
[63517.680000] ath: phy0: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42100020 DMADBG_7=0x000084c0
[64251.890000] br-lan: received packet on bat0 with own address as source address
[64251.900000] br-lan: received packet on bat0 with own address as source address
[66138.120000] br-lan: received packet on bat0 with own address as source address
[66138.120000] br-lan: received packet on bat0 with own address as source address
[69016.600000] ------------[ cut here ]------------
[69016.610000] WARNING: CPU: 0 PID: 0 at /usr/src/openwrt-15.05/build_dir/target-mips_34kc_uClibc-0.9.33.2/linux-ar71xx_generic/compat-wireless-2016-01-10/net/mac80211/rx.c:3617 ieee80211_rx_napi+0x140/0x854 [mac80211]()
[69016.630000] Rate marked as an HT rate but passed status->rate_idx is not an MCS index [0-76]: 79 (0x4f)
[69016.640000] Modules linked in: iptable_nat ath9k nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT ipt_MASQUERADE ebtable_nat ebtable_filter ebtable_broute ath9k_common xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_id xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_NETMAP xt_LOG xt_CT nf_reject_ipv4 nf_nat_masquerade_ipv4 nf_nat_ftp nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack_ftp nf_conntrack macvlan mac80211 iptable_raw iptable_mangle iptable_filter ip_tables ebtables ebt_vlan ebt_stp ebt_redirect ebt_pkttype ebt_mark_m ebt_mark ebt_limit ebt_among ebt_802_3 crc_ccitt ath9k_hw ath batman_adv libcrc32c cfg80211 compat ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables dummy ip6_tunnel tunnel6 tun ipv6 arc4 crypto_blkcipher gpio_button_hotplug crc16 crc32c_generic crypto_hash
[69016.720000] CPU: 0 PID: 0 Comm: swapper Tainted: G        W      3.18.29 #1
[69016.730000] Stack : 00000000 00000000 00000000 00000000 803b4292 0000003f 00000000 80e22d00
[69016.730000]    00000001 00000000 80304d78 8035aae3 00000000 803b34d0 8035ae18 00000000
[69016.730000]    000000bd 81ffb6d8 803d0000 800a36c4 00000003 80080428 00000e21 00000000
[69016.730000]    80308370 80355ba4 00000000 00000000 00000000 00000000 00000000 00000000
[69016.730000]    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[69016.730000]    ...
[69016.760000] Call Trace:
[69016.760000] [<80071090>] show_stack+0x50/0x84
[69016.770000] [<800805a4>] warn_slowpath_common+0x84/0xb4
[69016.770000] [<80080600>] warn_slowpath_fmt+0x2c/0x38
[69016.780000] [<80e22d00>] ieee80211_rx_napi+0x140/0x854 [mac80211]
[69016.780000] [<80dc6420>] ath_rx_tasklet+0x9c0/0xa0c [ath9k]
[69016.790000] [<80dc3e68>] ath9k_tasklet+0x1ac/0x230 [ath9k]
[69016.800000] [<80083194>] tasklet_action+0x84/0xcc
[69016.800000] [<80082aa4>] __do_softirq+0xf8/0x230
[69016.810000] [<80082e10>] irq_exit+0x54/0x70
[69016.810000] [<80060830>] ret_from_irq+0x0/0x4
[69016.810000] [<80060a80>] __r4k_wait+0x20/0x40
[69016.820000] [<8009f644>] cpu_startup_entry+0xf0/0x13c
[69016.820000] [<80373b5c>] start_kernel+0x42c/0x444
[69016.830000] 
[69016.830000] ---[ end trace 032e1f77966f4f28 ]---
[69279.660000] br-lan: received packet on bat0 with own address as source address
[69279.670000] br-lan: received packet on bat0 with own address as source address
[70076.380000] ------------[ cut here ]------------
[70076.390000] WARNING: CPU: 0 PID: 0 at /usr/src/openwrt-15.05/build_dir/target-mips_34kc_uClibc-0.9.33.2/linux-ar71xx_generic/compat-wireless-2016-01-10/net/mac80211/rx.c:3617 ieee80211_rx_napi+0x140/0x854 [mac80211]()
[70076.410000] Rate marked as an HT rate but passed status->rate_idx is not an MCS index [0-76]: 79 (0x4f)
[70076.420000] Modules linked in: iptable_nat ath9k nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT ipt_MASQUERADE ebtable_nat ebtable_filter ebtable_broute ath9k_common xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_id xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_NETMAP xt_LOG xt_CT nf_reject_ipv4 nf_nat_masquerade_ipv4 nf_nat_ftp nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack_ftp nf_conntrack macvlan mac80211 iptable_raw iptable_mangle iptable_filter ip_tables ebtables ebt_vlan ebt_stp ebt_redirect ebt_pkttype ebt_mark_m ebt_mark ebt_limit ebt_among ebt_802_3 crc_ccitt ath9k_hw ath batman_adv libcrc32c cfg80211 compat ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables dummy ip6_tunnel tunnel6 tun ipv6 arc4 crypto_blkcipher gpio_button_hotplug crc16 crc32c_generic crypto_hash
[70076.500000] CPU: 0 PID: 0 Comm: swapper Tainted: G        W      3.18.29 #1
[70076.500000] Stack : 00000000 00000000 00000000 00000000 803b4292 0000003f 00000000 80e22d00
[70076.500000]    00000001 00000000 80304d78 8035aae3 00000000 803b34d0 8035ae18 00000000
[70076.500000]    00000000 816359d8 803d0000 800a36c4 00000003 80080428 00000e21 00000000
[70076.500000]    80308370 80355ba4 00000000 00000000 00000000 00000000 00000000 00000000
[70076.500000]    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[70076.500000]    ...
[70076.540000] Call Trace:
[70076.540000] [<80071090>] show_stack+0x50/0x84
[70076.550000] [<800805a4>] warn_slowpath_common+0x84/0xb4
[70076.550000] [<80080600>] warn_slowpath_fmt+0x2c/0x38
[70076.560000] [<80e22d00>] ieee80211_rx_napi+0x140/0x854 [mac80211]
[70076.560000] [<80dc6420>] ath_rx_tasklet+0x9c0/0xa0c [ath9k]
[70076.570000] [<80dc3e68>] ath9k_tasklet+0x1ac/0x230 [ath9k]
[70076.580000] [<80083194>] tasklet_action+0x84/0xcc
[70076.580000] [<80082aa4>] __do_softirq+0xf8/0x230
[70076.580000] [<80082e10>] irq_exit+0x54/0x70
[70076.590000] [<80060830>] ret_from_irq+0x0/0x4
[70076.590000] [<80060a80>] __r4k_wait+0x20/0x40
[70076.600000] [<8009f644>] cpu_startup_entry+0xf0/0x13c
[70076.600000] [<80373b5c>] start_kernel+0x42c/0x444
[70076.610000] 
[70076.610000] ---[ end trace 032e1f77966f4f29 ]---
[71127.680000] ath: phy0: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42100020 DMADBG_7=0x000286c0
[73236.410000] ath: phy0: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x42100020 DMADBG_7=0x000084c0


Cheers


Daniel


From dedeckeh at gmail.com  Wed Jun 29 05:02:18 2016
From: dedeckeh at gmail.com (Hans Dedecker)
Date: Wed, 29 Jun 2016 14:02:18 +0200
Subject: [LEDE-DEV] [PATCH netifd] alias: Set alias link device status to
	disabled when device is removed
Message-ID: <1467201738-2975-1-git-send-email-dedeckeh@gmail.com>

Fixes missing link state event propagation for an aliased device in case a new device is added
as the link state has the last known status of the old device possible resulting into
no link state change detection.

Signed-off-by: Hans Dedecker <dedeckeh at gmail.com>
---
 alias.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/alias.c b/alias.c
index 6b938ca..56420c7 100644
--- a/alias.c
+++ b/alias.c
@@ -61,8 +61,10 @@ static void alias_set_device(struct alias_device *alias, struct device *dev)
 		device_set_ifindex(&alias->dev, dev->ifindex);
 		device_set_ifname(&alias->dev, dev->ifname);
 		device_add_user(&alias->dep, dev);
-	} else
+	} else {
 		device_set_ifname(&alias->dev, "");
+		device_set_link(&alias->dev, false);
+	}
 }
 
 static int
-- 
1.9.1



From jo at mein.io  Wed Jun 29 06:42:10 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Wed, 29 Jun 2016 15:42:10 +0200
Subject: [LEDE-DEV] Add Synopsys brand to Wiki
In-Reply-To: <1467018805.3628.36.camel@synopsys.com>
References: <1467018805.3628.36.camel@synopsys.com>
Message-ID: <46d96e6c-61dc-f28c-8ac9-8db99292c334@mein.io>

Hi Alexey,

please contact Thomas Endt <tmo -at- gmx.de> for assistance on adding
brands to the OpenWrt Wiki ToH.

~ Jo


From jo at mein.io  Wed Jun 29 06:43:02 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Wed, 29 Jun 2016 15:43:02 +0200
Subject: [LEDE-DEV] [PATCH netifd] alias: Set alias link device status
 to disabled when device is removed
In-Reply-To: <1467201738-2975-1-git-send-email-dedeckeh@gmail.com>
References: <1467201738-2975-1-git-send-email-dedeckeh@gmail.com>
Message-ID: <bd272aea-44e4-b373-9a44-ac9121d399f4@mein.io>

Hi Hans,

pushed to netifd.git - thank you!

~ Jo


From john at phrozen.org  Wed Jun 29 07:49:29 2016
From: john at phrozen.org (John Crispin)
Date: Wed, 29 Jun 2016 16:49:29 +0200
Subject: [LEDE-DEV] adding luci to snapshot images
Message-ID: <83d8c156-1a53-e391-fb3e-2460d16ed20e@phrozen.org>

Hi Jo,

can we add luci to snapshot images until the first release is out ?
people are using the images and seem to be confused by there being no luci.

personally i would prefer to not include luci in snapshots to keep them
as minimal as possible but until we have a first release it would make
sense. we can revert that change post release.

	John


From jo at mein.io  Wed Jun 29 07:54:25 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Wed, 29 Jun 2016 16:54:25 +0200
Subject: [LEDE-DEV] adding luci to snapshot images
In-Reply-To: <83d8c156-1a53-e391-fb3e-2460d16ed20e@phrozen.org>
References: <83d8c156-1a53-e391-fb3e-2460d16ed20e@phrozen.org>
Message-ID: <351faca4-edfa-c301-876f-afa9a06ba675@mein.io>

Hi,

it would certainly help to bridge the gap until the #1 release and it
would give more testing exposure to the ui...

My observation on the matter is this:
People who do *not* want to have the ui included are either building
from source or using the IB anyway and those users *requiring* a ui tend
to be unable to spin their own builds (no Linux os at hand, too hard, ...)

So personally I'd lean toward adding LuCI to the snapshots but would
await further feedback on it.

~ Jo


From ianchi74 at outlook.com  Wed Jun 29 08:30:46 2016
From: ianchi74 at outlook.com (Adrian Panella)
Date: Wed, 29 Jun 2016 10:30:46 -0500
Subject: [LEDE-DEV] adding luci to snapshot images
In-Reply-To: <351faca4-edfa-c301-876f-afa9a06ba675@mein.io>
References: <83d8c156-1a53-e391-fb3e-2460d16ed20e@phrozen.org>
 <351faca4-edfa-c301-876f-afa9a06ba675@mein.io>
Message-ID: <BLU405-EAS17D0B85832A0F3392ADB86DB230@phx.gbl>

Totally agree with the observation.
+1 for including LuCI as default.

-----Original Message-----
From: Lede-dev [mailto:lede-dev-bounces at lists.infradead.org] On Behalf Of
Jo-Philipp Wich
Sent: mi?rcoles, 29 de junio de 2016 09:54 a.m.
To: lede-dev at lists.infradead.org
Subject: Re: [LEDE-DEV] adding luci to snapshot images

Hi,

it would certainly help to bridge the gap until the #1 release and it would
give more testing exposure to the ui...

My observation on the matter is this:
People who do *not* want to have the ui included are either building from
source or using the IB anyway and those users *requiring* a ui tend to be
unable to spin their own builds (no Linux os at hand, too hard, ...)

So personally I'd lean toward adding LuCI to the snapshots but would await
further feedback on it.

~ Jo

_______________________________________________
Lede-dev mailing list
Lede-dev at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev


From ldpinney at gmail.com  Wed Jun 29 08:49:54 2016
From: ldpinney at gmail.com (L. D. Pinney)
Date: Wed, 29 Jun 2016 10:49:54 -0500
Subject: [LEDE-DEV] adding luci to snapshot images
In-Reply-To: <BLU405-EAS17D0B85832A0F3392ADB86DB230@phx.gbl>
References: <83d8c156-1a53-e391-fb3e-2460d16ed20e@phrozen.org>
 <351faca4-edfa-c301-876f-afa9a06ba675@mein.io>
 <BLU405-EAS17D0B85832A0F3392ADB86DB230@phx.gbl>
Message-ID: <CAJOqq5Q+2Hk25nUi7JwYp4s4HREY+bz5EdEYmWjkTk29AgTr_A@mail.gmail.com>

While I think adding luci will be convenient for many users.

I feel that the initial release is the paramount issue and that builds
containing luci could be added later.

A nice solution would be to offer downloads built w/wo luci....as well
as adding 'luci' to the filename if built with luci.

On Wed, Jun 29, 2016 at 10:30 AM, Adrian Panella <ianchi74 at outlook.com> wrote:
> Totally agree with the observation.
> +1 for including LuCI as default.
>
> -----Original Message-----
> From: Lede-dev [mailto:lede-dev-bounces at lists.infradead.org] On Behalf Of
> Jo-Philipp Wich
> Sent: mi?rcoles, 29 de junio de 2016 09:54 a.m.
> To: lede-dev at lists.infradead.org
> Subject: Re: [LEDE-DEV] adding luci to snapshot images
>
> Hi,
>
> it would certainly help to bridge the gap until the #1 release and it would
> give more testing exposure to the ui...
>
> My observation on the matter is this:
> People who do *not* want to have the ui included are either building from
> source or using the IB anyway and those users *requiring* a ui tend to be
> unable to spin their own builds (no Linux os at hand, too hard, ...)
>
> So personally I'd lean toward adding LuCI to the snapshots but would await
> further feedback on it.
>
> ~ Jo
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


From yszhou4tech at gmail.com  Wed Jun 29 09:29:31 2016
From: yszhou4tech at gmail.com (Yousong Zhou)
Date: Thu, 30 Jun 2016 00:29:31 +0800
Subject: [LEDE-DEV] [PATCH 0/4] ar71xx: image: a few fixes
Message-ID: <1467217775-14805-1-git-send-email-yszhou4tech@gmail.com>

The patch on HiWiFi HC6361 has been run-tested.

The patch on seama image build has only been compile-tested and inspected
manually.  I'd like to wait for some acks before it get merged.

Yousong Zhou (4):
  ar71xx: hiwifi-hc6361: move packages selection to generic.mk
  ar71xx: image: remove duplicate IMAGES definition
  ar71xx: image: unify indentation with 2 whitespaces
  ar71xx: seama: fix making factory images

 target/linux/ar71xx/image/Makefile          |   1 -
 target/linux/ar71xx/image/generic.mk        | 320 ++++++++++++++++++----------
 target/linux/ar71xx/image/legacy-devices.mk |  26 ---
 target/linux/ar71xx/image/legacy.mk         |  40 ----
 4 files changed, 202 insertions(+), 185 deletions(-)

-- 
2.6.4



From yszhou4tech at gmail.com  Wed Jun 29 09:29:32 2016
From: yszhou4tech at gmail.com (Yousong Zhou)
Date: Thu, 30 Jun 2016 00:29:32 +0800
Subject: [LEDE-DEV] [PATCH 1/4] ar71xx: hiwifi-hc6361: move packages
	selection to generic.mk
In-Reply-To: <1467217775-14805-1-git-send-email-yszhou4tech@gmail.com>
References: <1467217775-14805-1-git-send-email-yszhou4tech@gmail.com>
Message-ID: <1467217775-14805-2-git-send-email-yszhou4tech@gmail.com>

Remove kmod-crypto-deflate and kmod-ledtrig-gpio as the device works the
same by default without them

Signed-off-by: Yousong Zhou <yszhou4tech at gmail.com>
---
 target/linux/ar71xx/image/generic.mk        | 15 +++++++++------
 target/linux/ar71xx/image/legacy-devices.mk |  8 --------
 2 files changed, 9 insertions(+), 14 deletions(-)

diff --git a/target/linux/ar71xx/image/generic.mk b/target/linux/ar71xx/image/generic.mk
index 095c542..6802501 100644
--- a/target/linux/ar71xx/image/generic.mk
+++ b/target/linux/ar71xx/image/generic.mk
@@ -421,11 +421,14 @@ define Build/uImageHiWiFi
 endef
 
 define Device/hiwifi-hc6361
-    BOARDNAME := HiWiFi-HC6361
-    DEVICE_PROFILE := HIWIFI_HC6361
-    IMAGE_SIZE := 16128k
-    KERNEL := kernel-bin | patch-cmdline | lzma | uImageHiWiFi lzma
-    CONSOLE := ttyATH0,115200
-    MTDPARTS := spi0.0:64k(u-boot)ro,64k(bdinfo)ro,16128k(firmware),64k(backup)ro,64k(art)ro
+  DEVICE_TITLE := HiWiFi HC6361
+  DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-storage \
+	kmod-fs-ext4 kmod-nls-iso8859-1 e2fsprogs
+  BOARDNAME := HiWiFi-HC6361
+  DEVICE_PROFILE := HIWIFI_HC6361
+  IMAGE_SIZE := 16128k
+  KERNEL := kernel-bin | patch-cmdline | lzma | uImageHiWiFi lzma
+  CONSOLE := ttyATH0,115200
+  MTDPARTS := spi0.0:64k(u-boot)ro,64k(bdinfo)ro,16128k(firmware),64k(backup)ro,64k(art)ro
 endef
 TARGET_DEVICES += hiwifi-hc6361
diff --git a/target/linux/ar71xx/image/legacy-devices.mk b/target/linux/ar71xx/image/legacy-devices.mk
index 0e51fef..c8e1476 100644
--- a/target/linux/ar71xx/image/legacy-devices.mk
+++ b/target/linux/ar71xx/image/legacy-devices.mk
@@ -401,14 +401,6 @@ define LegacyDevice/EWDORIN
 endef
 LEGACY_DEVICES += EWDORIN
 
-define LegacyDevice/HIWIFI_HC6361
-	DEVICE_TITLE := HiWiFi HC6361
-	DEVICE_PACKAGES :=  kmod-usb-core kmod-usb2 kmod-usb-storage \
-		kmod-crypto-deflate kmod-fs-ext4 kmod-ledtrig-gpio \
-		kmod-nls-iso8859-1 e2fsprogs
-endef
-LEGACY_DEVICES += HIWIFI_HC6361
-
 define LegacyDevice/JA76PF
 	DEVICE_TITLE := jjPlus JA76PF
 	DEVICE_PACKAGES := kmod-usb-core kmod-usb-ohci kmod-usb2 kmod-hwmon-core kmod-i2c-core kmod-hwmon-lm75
-- 
2.6.4



From yszhou4tech at gmail.com  Wed Jun 29 09:29:33 2016
From: yszhou4tech at gmail.com (Yousong Zhou)
Date: Thu, 30 Jun 2016 00:29:33 +0800
Subject: [LEDE-DEV] [PATCH 2/4] ar71xx: image: remove duplicate IMAGES
	definition
In-Reply-To: <1467217775-14805-1-git-send-email-yszhou4tech@gmail.com>
References: <1467217775-14805-1-git-send-email-yszhou4tech@gmail.com>
Message-ID: <1467217775-14805-3-git-send-email-yszhou4tech@gmail.com>

Signed-off-by: Yousong Zhou <yszhou4tech at gmail.com>
---
 target/linux/ar71xx/image/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/target/linux/ar71xx/image/Makefile b/target/linux/ar71xx/image/Makefile
index 2380a62..ced1610 100644
--- a/target/linux/ar71xx/image/Makefile
+++ b/target/linux/ar71xx/image/Makefile
@@ -88,7 +88,6 @@ define Device/Default
   DEVICE_PROFILE = $$(BOARDNAME)
   PROFILES = Default Minimal $$(DEVICE_PROFILE)
   MTDPARTS :=
-  IMAGES := sysupgrade.bin
   BLOCKSIZE := 64k
   FILESYSTEMS = $(filter-out jffs2-%,$(TARGET_FILESYSTEMS)) jffs2-$$(BLOCKSIZE)
   CONSOLE = ttyS0,115200
-- 
2.6.4



From yszhou4tech at gmail.com  Wed Jun 29 09:29:34 2016
From: yszhou4tech at gmail.com (Yousong Zhou)
Date: Thu, 30 Jun 2016 00:29:34 +0800
Subject: [LEDE-DEV] [PATCH 3/4] ar71xx: image: unify indentation with 2
	whitespaces
In-Reply-To: <1467217775-14805-1-git-send-email-yszhou4tech@gmail.com>
References: <1467217775-14805-1-git-send-email-yszhou4tech@gmail.com>
Message-ID: <1467217775-14805-4-git-send-email-yszhou4tech@gmail.com>

Signed-off-by: Yousong Zhou <yszhou4tech at gmail.com>
---
 target/linux/ar71xx/image/generic.mk | 224 +++++++++++++++++------------------
 1 file changed, 112 insertions(+), 112 deletions(-)

diff --git a/target/linux/ar71xx/image/generic.mk b/target/linux/ar71xx/image/generic.mk
index 6802501..3e3dc69 100644
--- a/target/linux/ar71xx/image/generic.mk
+++ b/target/linux/ar71xx/image/generic.mk
@@ -188,176 +188,176 @@ endef
 TARGET_DEVICES += cr5000-nocloud
 
 define Device/antminer-s1
-    $(Device/tplink-8mlzma)
-    DEVICE_TITLE := Antminer-S1
-    DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-crypto-manager kmod-i2c-gpio-custom kmod-usb-hid
-    BOARDNAME := ANTMINER-S1
-    DEVICE_PROFILE := ANTMINERS1
-    TPLINK_HWID := 0x04440101
-    CONSOLE := ttyATH0,115200
+  $(Device/tplink-8mlzma)
+  DEVICE_TITLE := Antminer-S1
+  DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-crypto-manager kmod-i2c-gpio-custom kmod-usb-hid
+  BOARDNAME := ANTMINER-S1
+  DEVICE_PROFILE := ANTMINERS1
+  TPLINK_HWID := 0x04440101
+  CONSOLE := ttyATH0,115200
 endef
 
 define Device/antminer-s3
-    $(Device/tplink-8mlzma)
-    DEVICE_TITLE := Antminer-S3
-    DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-crypto-manager kmod-i2c-gpio-custom kmod-usb-hid
-    BOARDNAME := ANTMINER-S3
-    DEVICE_PROFILE := ANTMINERS3
-    TPLINK_HWID := 0x04440301
-    CONSOLE := ttyATH0,115200
+  $(Device/tplink-8mlzma)
+  DEVICE_TITLE := Antminer-S3
+  DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-crypto-manager kmod-i2c-gpio-custom kmod-usb-hid
+  BOARDNAME := ANTMINER-S3
+  DEVICE_PROFILE := ANTMINERS3
+  TPLINK_HWID := 0x04440301
+  CONSOLE := ttyATH0,115200
 endef
 
 define Device/antrouter-r1
-    $(Device/tplink-8mlzma)
-    DEVICE_TITLE := Antrouter-R1
-    DEVICE_PACKAGES := kmod-usb-core kmod-usb2
-    BOARDNAME := ANTROUTER-R1
-    DEVICE_PROFILE := ANTROUTERR1
-    TPLINK_HWID := 0x44440101
-    CONSOLE := ttyATH0,115200
+  $(Device/tplink-8mlzma)
+  DEVICE_TITLE := Antrouter-R1
+  DEVICE_PACKAGES := kmod-usb-core kmod-usb2
+  BOARDNAME := ANTROUTER-R1
+  DEVICE_PROFILE := ANTROUTERR1
+  TPLINK_HWID := 0x44440101
+  CONSOLE := ttyATH0,115200
 endef
 
 define Device/el-m150
-    $(Device/tplink-8mlzma)
-    DEVICE_TITLE := EasyLink EL-M150
-    DEVICE_PACKAGES := kmod-usb-core kmod-usb2
-    BOARDNAME := EL-M150
-    DEVICE_PROFILE := ELM150
-    TPLINK_HWID := 0x01500101
-    CONSOLE := ttyATH0,115200
+  $(Device/tplink-8mlzma)
+  DEVICE_TITLE := EasyLink EL-M150
+  DEVICE_PACKAGES := kmod-usb-core kmod-usb2
+  BOARDNAME := EL-M150
+  DEVICE_PROFILE := ELM150
+  TPLINK_HWID := 0x01500101
+  CONSOLE := ttyATH0,115200
 endef
 
 define Device/el-mini
-    $(Device/tplink-8mlzma)
-    DEVICE_TITLE := EasyLink EL-MINI
-    DEVICE_PACKAGES := kmod-usb-core kmod-usb2
-    BOARDNAME := EL-MINI
-    DEVICE_PROFILE := ELMINI
-    TPLINK_HWID := 0x01530001
-    CONSOLE := ttyATH0,115200
+  $(Device/tplink-8mlzma)
+  DEVICE_TITLE := EasyLink EL-MINI
+  DEVICE_PACKAGES := kmod-usb-core kmod-usb2
+  BOARDNAME := EL-MINI
+  DEVICE_PROFILE := ELMINI
+  TPLINK_HWID := 0x01530001
+  CONSOLE := ttyATH0,115200
 endef
 TARGET_DEVICES += antminer-s1 antminer-s3 antrouter-r1 el-m150 el-mini
 
 define Device/gl-inet-6408A-v1
-    $(Device/tplink-8mlzma)
-    DEVICE_TITLE := GL.iNet 6408
-    DEVICE_PACKAGES := kmod-usb-core kmod-usb2
-    BOARDNAME := GL-INET
-    DEVICE_PROFILE := GLINET
-    TPLINK_HWID := 0x08000001
-    CONSOLE := ttyATH0,115200
+  $(Device/tplink-8mlzma)
+  DEVICE_TITLE := GL.iNet 6408
+  DEVICE_PACKAGES := kmod-usb-core kmod-usb2
+  BOARDNAME := GL-INET
+  DEVICE_PROFILE := GLINET
+  TPLINK_HWID := 0x08000001
+  CONSOLE := ttyATH0,115200
 endef
 
 define Device/gl-inet-6416A-v1
-    $(Device/tplink-16mlzma)
-    DEVICE_TITLE := GL.iNet 6416
-    DEVICE_PACKAGES := kmod-usb-core kmod-usb2
-    BOARDNAME := GL-INET
-    DEVICE_PROFILE := GLINET
-    TPLINK_HWID := 0x08000001
-    CONSOLE := ttyATH0,115200
+  $(Device/tplink-16mlzma)
+  DEVICE_TITLE := GL.iNet 6416
+  DEVICE_PACKAGES := kmod-usb-core kmod-usb2
+  BOARDNAME := GL-INET
+  DEVICE_PROFILE := GLINET
+  TPLINK_HWID := 0x08000001
+  CONSOLE := ttyATH0,115200
 endef
 TARGET_DEVICES += gl-inet-6408A-v1 gl-inet-6416A-v1
 
 define Device/rnx-n360rt
-    $(Device/tplink-4m)
-    DEVICE_TITLE := Rosewill RNX-N360RT
-    BOARDNAME := TL-WR941ND
-    DEVICE_PROFILE := RNXN360RT
-    TPLINK_HWID := 0x09410002
-    TPLINK_HWREV := 0x00420001
+  $(Device/tplink-4m)
+  DEVICE_TITLE := Rosewill RNX-N360RT
+  BOARDNAME := TL-WR941ND
+  DEVICE_PROFILE := RNXN360RT
+  TPLINK_HWID := 0x09410002
+  TPLINK_HWREV := 0x00420001
 endef
 TARGET_DEVICES += rnx-n360rt
 
 define Device/mc-mac1200r
-    $(Device/tplink-8mlzma)
-    DEVICE_TITLE := MERCURY MAC1200R
-    DEVICE_PACKAGES := kmod-ath10k
-    BOARDNAME := MC-MAC1200R
-    DEVICE_PROFILE := MAC1200R
-    TPLINK_HWID := 0x12000001
+  $(Device/tplink-8mlzma)
+  DEVICE_TITLE := MERCURY MAC1200R
+  DEVICE_PACKAGES := kmod-ath10k
+  BOARDNAME := MC-MAC1200R
+  DEVICE_PROFILE := MAC1200R
+  TPLINK_HWID := 0x12000001
 endef
 TARGET_DEVICES += mc-mac1200r
 
 define Device/minibox-v1
-    $(Device/tplink-16mlzma)
-    DEVICE_TITLE := Gainstrong MiniBox V1.0
-    DEVICE_PACKAGES := kmod-usb-core kmod-usb2  kmod-ledtrig-usbdev
-    BOARDNAME := MINIBOX-V1
-    DEVICE_PROFILE := MINIBOXV1
-    TPLINK_HWID := 0x3C000201
-    CONSOLE := ttyATH0,115200
+  $(Device/tplink-16mlzma)
+  DEVICE_TITLE := Gainstrong MiniBox V1.0
+  DEVICE_PACKAGES := kmod-usb-core kmod-usb2  kmod-ledtrig-usbdev
+  BOARDNAME := MINIBOX-V1
+  DEVICE_PROFILE := MINIBOXV1
+  TPLINK_HWID := 0x3C000201
+  CONSOLE := ttyATH0,115200
 endef
 TARGET_DEVICES += minibox-v1
 
 define Device/omy-g1
-    $(Device/tplink-16mlzma)
-    DEVICE_TITLE := OMYlink OMY-G1
-    DEVICE_PACKAGES := kmod-usb-core kmod-usb2
-    BOARDNAME := OMY-G1
-    DEVICE_PROFILE := OMYG1
-    TPLINK_HWID := 0x06660101
+  $(Device/tplink-16mlzma)
+  DEVICE_TITLE := OMYlink OMY-G1
+  DEVICE_PACKAGES := kmod-usb-core kmod-usb2
+  BOARDNAME := OMY-G1
+  DEVICE_PROFILE := OMYG1
+  TPLINK_HWID := 0x06660101
 endef
 
 define Device/omy-x1
-    $(Device/tplink-8mlzma)
-    DEVICE_TITLE := OMYlink OMY-X1
-    BOARDNAME := OMY-X1
-    DEVICE_PROFILE := OMYX1
-    TPLINK_HWID := 0x06660201
+  $(Device/tplink-8mlzma)
+  DEVICE_TITLE := OMYlink OMY-X1
+  BOARDNAME := OMY-X1
+  DEVICE_PROFILE := OMYX1
+  TPLINK_HWID := 0x06660201
 endef
 TARGET_DEVICES += omy-g1 omy-x1
 
 define Device/onion-omega
-    $(Device/tplink-16mlzma)
-    DEVICE_TITLE := Onion Omega
-    DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-storage kmod-i2c-core kmod-i2c-gpio-custom kmod-spi-bitbang kmod-spi-dev kmod-spi-gpio kmod-spi-gpio-custom kmod-usb-serial
-    BOARDNAME := ONION-OMEGA
-    DEVICE_PROFILE := OMEGA
-    TPLINK_HWID := 0x04700001
-    CONSOLE := ttyATH0,115200
+  $(Device/tplink-16mlzma)
+  DEVICE_TITLE := Onion Omega
+  DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-storage kmod-i2c-core kmod-i2c-gpio-custom kmod-spi-bitbang kmod-spi-dev kmod-spi-gpio kmod-spi-gpio-custom kmod-usb-serial
+  BOARDNAME := ONION-OMEGA
+  DEVICE_PROFILE := OMEGA
+  TPLINK_HWID := 0x04700001
+  CONSOLE := ttyATH0,115200
 endef
 TARGET_DEVICES += onion-omega
 
 define Device/smart-300
-    $(Device/tplink-8mlzma)
-    DEVICE_TITLE := NC-LINK SMART-300
-    BOARDNAME := SMART-300
-    DEVICE_PROFILE := SMART-300
-    TPLINK_HWID := 0x93410001
+  $(Device/tplink-8mlzma)
+  DEVICE_TITLE := NC-LINK SMART-300
+  BOARDNAME := SMART-300
+  DEVICE_PROFILE := SMART-300
+  TPLINK_HWID := 0x93410001
 endef
 TARGET_DEVICES += smart-300
 
 define Device/som9331
-    $(Device/tplink-8mlzma)
-    DEVICE_TITLE := OpenEmbed SOM9331
-    DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-storage kmod-i2c-core kmod-i2c-gpio-custom kmod-spi-bitbang kmod-spi-dev kmod-spi-gpio kmod-spi-gpio-custom kmod-usb-serial
-    BOARDNAME := SOM9331
-    DEVICE_PROFILE := SOM9331
-    TPLINK_HWID := 0x04800054
-    CONSOLE := ttyATH0,115200
+  $(Device/tplink-8mlzma)
+  DEVICE_TITLE := OpenEmbed SOM9331
+  DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-storage kmod-i2c-core kmod-i2c-gpio-custom kmod-spi-bitbang kmod-spi-dev kmod-spi-gpio kmod-spi-gpio-custom kmod-usb-serial
+  BOARDNAME := SOM9331
+  DEVICE_PROFILE := SOM9331
+  TPLINK_HWID := 0x04800054
+  CONSOLE := ttyATH0,115200
 endef
 TARGET_DEVICES += som9331
 
 define Device/tellstick-znet-lite
-    $(Device/tplink-16mlzma)
-    DEVICE_TITLE := TellStick ZNet Lite
-    DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-acm kmod-usb-serial kmod-usb-serial-pl2303
-    BOARDNAME := TELLSTICK-ZNET-LITE
-    DEVICE_PROFILE := TELLSTICKZNETLITE
-    TPLINK_HWID := 0x00726001
-    CONSOLE := ttyATH0,115200
+  $(Device/tplink-16mlzma)
+  DEVICE_TITLE := TellStick ZNet Lite
+  DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-acm kmod-usb-serial kmod-usb-serial-pl2303
+  BOARDNAME := TELLSTICK-ZNET-LITE
+  DEVICE_PROFILE := TELLSTICKZNETLITE
+  TPLINK_HWID := 0x00726001
+  CONSOLE := ttyATH0,115200
 endef
 TARGET_DEVICES += tellstick-znet-lite
 
 define Device/oolite
-    $(Device/tplink-16mlzma)
-    DEVICE_TITLE := Gainstrong OOLITE
-    DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-ledtrig-usbdev
-    BOARDNAME := GS-OOLITE
-    DEVICE_PROFILE := OOLITE
-    TPLINK_HWID := 0x3C000101
-    CONSOLE := ttyATH0,115200
+  $(Device/tplink-16mlzma)
+  DEVICE_TITLE := Gainstrong OOLITE
+  DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-ledtrig-usbdev
+  BOARDNAME := GS-OOLITE
+  DEVICE_PROFILE := OOLITE
+  TPLINK_HWID := 0x3C000101
+  CONSOLE := ttyATH0,115200
 endef
 TARGET_DEVICES += oolite
 
-- 
2.6.4



From yszhou4tech at gmail.com  Wed Jun 29 09:30:37 2016
From: yszhou4tech at gmail.com (Yousong Zhou)
Date: Thu, 30 Jun 2016 00:30:37 +0800
Subject: [LEDE-DEV] [PATCH 4/4] ar71xx: seama: fix making factory images
Message-ID: <1467217837-14916-1-git-send-email-yszhou4tech@gmail.com>

rootfs part needs to be aligned to erase block size which is passed as
the 6th argument to Image/Build/Seama  and is now 65536 since commit
commit 5119ee9 "ar71xx: fix bogus hardcoded kernel image size for Seama
images (fixes #20585)", but $(($(6) - 64)) still assumes that the
argument is a limit on kernel partition size, i.e. 1310720, so the
generated factory image is wrong in that the kernel will fail to find
the rootfs (FlySpray link at [1])

This patch will workaround it with the following steps

1. Calculate the required space for seama header and META data in step 5
2. Pre-padding 64 bytes to lzma-compressed loader
3. Generate correctly padded image-$(2).tmp
4. Strip out the padding
5. Seal it with seama utility

While at it convert seama to new build method

[1] FS#35 - mynet-n750 factory images don't find root partition,
    https://bugs.lede-project.org/index.php?do=details&task_id=35

Reported-by: Steven Haigh <netwiz at crc.id.au>
Signed-off-by: Yousong Zhou <yszhou4tech at gmail.com>
---
 target/linux/ar71xx/image/generic.mk        | 81 +++++++++++++++++++++++++++++
 target/linux/ar71xx/image/legacy-devices.mk | 18 -------
 target/linux/ar71xx/image/legacy.mk         | 40 --------------
 3 files changed, 81 insertions(+), 58 deletions(-)

diff --git a/target/linux/ar71xx/image/generic.mk b/target/linux/ar71xx/image/generic.mk
index 3e3dc69..ce603b5 100644
--- a/target/linux/ar71xx/image/generic.mk
+++ b/target/linux/ar71xx/image/generic.mk
@@ -432,3 +432,84 @@ define Device/hiwifi-hc6361
   MTDPARTS := spi0.0:64k(u-boot)ro,64k(bdinfo)ro,16128k(firmware),64k(backup)ro,64k(art)ro
 endef
 TARGET_DEVICES += hiwifi-hc6361
+
+
+# The pre-filled 64 bytes consist of
+# - 28 bytes seama_header
+# - 36 bytes of META data (4-bytes aligned)
+#
+# And as the 4 bytes jffs2 marker will be erased on first boot, so it needs to
+# be excluded from the calculation of checksum first
+define Build/seama-factory
+	( dd if=/dev/zero bs=64 count=1; cat $(word 1,$^) ) >$@.loader.tmp
+	( dd if=$@.loader.tmp bs=64k conv=sync; dd if=$(word 2,$^) ) >$@.tmp.0
+	tail -c +65 $@.tmp.0 >$@.tmp.1
+	head -c -4 $@.tmp.1 >$@.tmp.2
+	$(STAGING_DIR_HOST)/bin/seama \
+		-i $@.tmp.2 \
+		-m "dev=/dev/mtdblock/1" -m "type=firmware"
+	$(STAGING_DIR_HOST)/bin/seama \
+		-s $@ \
+		-m "signature=$(1)" \
+		-i $@.tmp.2.seama
+	tail -c 4 $@.tmp.1 >>$@
+	rm -f $@.loader.tmp $@.tmp.*
+endef
+
+define Build/seama-sysupgrade
+	$(STAGING_DIR_HOST)/bin/seama \
+		-i $(word 1,$^) \
+		-m "dev=/dev/mtdblock/1" -m "type=firmware"
+	( dd if=$(word 1,$^) bs=64k conv=sync; dd if=$(word 2,$^) ) >$@
+endef
+
+define Build/seama-initramfs
+	$(STAGING_DIR_HOST)/bin/seama \
+		-i $@ \
+		-m "dev=/dev/mtdblock/1" -m "type=firmware"
+	mv $@.seama $@
+endef
+
+define Device/seama
+  CONSOLE := ttyS0,115200
+  KERNEL := kernel-bin | loader-kernel-cmdline | lzma
+  KERNEL_INITRAMFS := kernel-bin | patch-cmdline | lzma | seama-initramfs
+  KERNEL_INITRAMFS_SUFFIX = $$(KERNEL_SUFFIX).seama
+  IMAGES := sysupgrade.bin factory.bin
+  IMAGE/sysupgrade.bin := seama-sysupgrade $$$$(SEAMA_SIGNATURE) | check-size $$$$(IMAGE_SIZE)
+  IMAGE/factory.bin := seama-factory $$$$(SEAMA_SIGNATURE) | check-size $$$$(IMAGE_SIZE)
+  SEAMA_SIGNATURE :=
+  DEVICE_VARS := SEAMA_SIGNATURE
+endef
+
+define Device/mynet-n600
+$(Device/seama)
+  DEVICE_TITLE := Western Digital My Net N600
+  DEVICE_PACKAGES := kmod-usb-core kmod-usb2
+  BOARDNAME = MYNET-N600
+  IMAGE_SIZE = 15808k
+  MTDPARTS = spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,64k(devdata)ro,64k(devconf)ro,15872k(firmware),64k(radiocfg)ro
+  SEAMA_SIGNATURE := wrgnd16_wd_db600
+endef
+
+define Device/mynet-n750
+$(Device/seama)
+  DEVICE_TITLE := Western Digital My Net N750
+  DEVICE_PACKAGES := kmod-usb-core kmod-usb2
+  BOARDNAME = MYNET-N750
+  IMAGE_SIZE = 15808k
+  MTDPARTS = spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,64k(devdata)ro,64k(devconf)ro,15872k(firmware),64k(radiocfg)ro
+  SEAMA_SIGNATURE := wrgnd13_wd_av
+endef
+
+define Device/qihoo-c301
+$(Device/seama)
+  DEVICE_TITLE := Qihoo C301
+  DEVICE_PACKAGES :=  kmod-usb-core kmod-usb2 kmod-ledtrig-usbdev kmod-ath10k
+  BOARDNAME = QIHOO-C301
+  IMAGE_SIZE = 15744k
+  MTDPARTS = mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env),64k(devdata),64k(devconf),15744k(firmware),64k(warm_start),64k(action_image_config),64k(radiocfg)ro;spi0.1:15360k(upgrade2),1024k(privatedata)
+  SEAMA_SIGNATURE := wrgac26_qihoo360_360rg
+endef
+
+TARGET_DEVICES += mynet-n600 mynet-n750 qihoo-c301
diff --git a/target/linux/ar71xx/image/legacy-devices.mk b/target/linux/ar71xx/image/legacy-devices.mk
index c8e1476..07d3df6 100644
--- a/target/linux/ar71xx/image/legacy-devices.mk
+++ b/target/linux/ar71xx/image/legacy-devices.mk
@@ -542,12 +542,6 @@ define LegacyDevice/MZKW300NH
 endef
 LEGACY_DEVICES += MZKW300NH
 
-define LegacyDevice/QIHOO360
-	DEVICE_TITLE := Qihoo 360 C301
-	DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-ledtrig-usbdev kmod-ath10k
-endef
-LEGACY_DEVICES += QIHOO360
-
 define LegacyDevice/RW2458N
 	DEVICE_TITLE := Redwave RW2458N
 	DEVICE_PACKAGES := kmod-usb-core kmod-usb-ohci kmod-ath9k wpad-mini
@@ -608,18 +602,6 @@ define LegacyDevice/DR344
 endef
 LEGACY_DEVICES += DR344
 
-define LegacyDevice/MYNETN600
-	DEVICE_TITLE := WD My Net N600
-	DEVICE_PACKAGES := kmod-usb-core kmod-usb2
-endef
-LEGACY_DEVICES += MYNETN600
-
-define LegacyDevice/MYNETN750
-	DEVICE_TITLE := WD My Net N750
-	DEVICE_PACKAGES := kmod-usb-core kmod-usb2
-endef
-LEGACY_DEVICES += MYNETN750
-
 define LegacyDevice/MYNETREXT
 	DEVICE_TITLE := WD My Net Wi-Fi Range Extender
 	DEVICE_PACKAGES := rssileds
diff --git a/target/linux/ar71xx/image/legacy.mk b/target/linux/ar71xx/image/legacy.mk
index c771f89..18eef4d 100644
--- a/target/linux/ar71xx/image/legacy.mk
+++ b/target/linux/ar71xx/image/legacy.mk
@@ -308,10 +308,8 @@ r6100_mtdlayout=mtdparts=ar934x-nfc:128k(u-boot)ro,256k(caldata),256k(caldata-ba
 tew823dru_mtdlayout=mtdparts=spi0.0:192k(u-boot)ro,64k(nvram)ro,15296k(firmware),192k(lang)ro,512k(my-dlink)ro,64k(mac)ro,64k(art)ro
 wndr4300_mtdlayout=mtdparts=ar934x-nfc:256k(u-boot)ro,256k(u-boot-env)ro,256k(caldata),512k(pot),2048k(language),512k(config),3072k(traffic_meter),2048k(kernel),23552k(ubi),25600k at 0x6c0000(firmware),256k(caldata_backup),-(reserved)
 zcn1523h_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,6208k(rootfs),1472k(kernel),64k(configure)ro,64k(mfg)ro,64k(art)ro,7680k at 0x50000(firmware)
-mynet_n600_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,64k(devdata)ro,64k(devconf)ro,15872k(firmware),64k(radiocfg)ro
 mynet_rext_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,7808k(firmware),64k(nvram)ro,64k(ART)ro
 zyx_nbg6716_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(env)ro,64k(RFdata)ro,-(nbu);ar934x-nfc:2048k(zyxel_rfsd),2048k(romd),1024k(header),2048k(kernel),-(ubi)
-qihoo_c301_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env),64k(devdata),64k(devconf),15744k(firmware),64k(warm_start),64k(action_image_config),64k(radiocfg)ro;spi0.1:15360k(upgrade2),1024k(privatedata)
 yun_mtdlayout_8M=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,6464k(rootfs),1280k(kernel),64k(nvram),64k(art),7744k at 0x50000(firmware)
 yun_mtdlayout_16M=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,14656k(rootfs),1280k(kernel),64k(nvram),64k(art),15936k at 0x50000(firmware)
 wrtnode2q_mtdlayout=mtdparts=spi0.0:192k(u-boot),64k(u-boot-env),64k(art),1472k(kernel),14592k(rootfs),16064k at 0x50000(firmware),16384k at 0x0(fullflash)
@@ -655,39 +653,6 @@ define Image/Build/ALFA
 endef
 
 
-Image/Build/Seama/loader=$(call Image/BuildLoader,$(1),bin,$(2) $(3),0x80060000)
-
-define Image/Build/Seama
-	[ -e "$(KDIR)/loader-$(2).bin" ]
-	$(call CompressLzma,$(KDIR)/loader-$(2).bin,$(KDIR_TMP)/loader-$(2).bin.lzma)
-	-rm -f $(KDIR_TMP)/image-$(2).tmp
-	$(call CatFiles,$(KDIR_TMP)/loader-$(2).bin.lzma,$$(($(6) - 64)),$(KDIR)/root.$(1),$(7),$(KDIR_TMP)/image-$(2).tmp)
-	[ -e "$(KDIR_TMP)/image-$(2).tmp" ] && { \
-		head -c -4 "$(KDIR_TMP)/image-$(2).tmp" > "$(KDIR_TMP)/image-$(2).no-jffs2mark.tmp"; \
-		$(STAGING_DIR_HOST)/bin/seama \
-		-i $(KDIR_TMP)/image-$(2).no-jffs2mark.tmp \
-		-m "dev=/dev/mtdblock/1" -m "type=firmware"; \
-		$(STAGING_DIR_HOST)/bin/seama \
-			-s $(call imgname,$(1),$(2))-factory.bin \
-			-m "signature=$(5)" \
-			-i $(KDIR_TMP)/image-$(2).no-jffs2mark.tmp.seama; \
-		tail -c 4 "$(KDIR_TMP)/image-$(2).tmp" >> $(call imgname,$(1),$(2))-factory.bin; \
-	}
-	cat $(KDIR_TMP)/loader-$(2).bin.lzma > $(KDIR_TMP)/image-$(2)-sysupgrade.tmp
-	$(STAGING_DIR_HOST)/bin/seama \
-		-i $(KDIR_TMP)/image-$(2)-sysupgrade.tmp \
-		-m "dev=/dev/mtdblock/1" -m "type=firmware"
-	$(call CatFiles,$(KDIR_TMP)/image-$(2)-sysupgrade.tmp.seama,$(6),$(KDIR)/root.$(1),$(7),$(call sysupname,$(1),$(2)))
-endef
-
-define Image/Build/Seama/initramfs
-	$(call PatchKernelLzma,$(2),$(3) $(4),,-initramfs)
-	$(STAGING_DIR_HOST)/bin/seama \
-		-i $(KDIR_TMP)/vmlinux-initramfs-$(2).bin.lzma \
-		-m "dev=/dev/mtdblock/1" -m "type=firmware"
-	cat $(KDIR_TMP)/vmlinux-initramfs-$(2).bin.lzma.seama > $(call imgname,initramfs,$(2))-seama.bin
-endef
-
 Image/Build/Senao/buildkernel=$(call MkuImageLzma,$(2),$(3) $(4))
 Image/Build/Senao/initramfs=$(call MkuImageLzma/initramfs,$(2),$(3) $(4))
 
@@ -1097,11 +1062,6 @@ $(eval $(call SingleProfile,PB4X,64k,PB44,pb44,PB44,ttyS0,115200))
 $(eval $(call SingleProfile,Planex,64kraw,MZKW04NU,mzk-w04nu,MZK-W04NU,ttyS0,115200))
 $(eval $(call SingleProfile,Planex,64kraw,MZKW300NH,mzk-w300nh,MZK-W300NH,ttyS0,115200))
 
-$(eval $(call SingleProfile,Seama,64k,MYNETN600,mynet-n600,MYNET-N600,ttyS0,115200,$$(mynet_n600_mtdlayout),wrgnd16_wd_db600,65536,16187392))
-$(eval $(call SingleProfile,Seama,64k,MYNETN750,mynet-n750,MYNET-N750,ttyS0,115200,$$(mynet_n600_mtdlayout),wrgnd13_wd_av,65536,16187392))
-
-$(eval $(call SingleProfile,Seama,64k,QIHOO360,qihoo-c301,QIHOO-C301,ttyS0,115200,$$(qihoo_c301_mtdlayout),wrgac26_qihoo360_360rg,65536,16121856))
-
 $(eval $(call SingleProfile,Senao,squashfs-only,EAP300V2,eap300v2,EAP300V2,ttyS0,115200,$$(eap300v2_mtdlayout)))
 
 $(eval $(call SingleProfile,WHRHPG300N,64kraw,WHRG301N,whr-g301n,WHR-G301N,ttyS0,115200,$$(whrhpg300n_mtdlayout),WHR-G301N))
-- 
2.6.4



From Alexey.Brodkin at synopsys.com  Wed Jun 29 10:18:04 2016
From: Alexey.Brodkin at synopsys.com (Alexey Brodkin)
Date: Wed, 29 Jun 2016 17:18:04 +0000
Subject: [LEDE-DEV] Add Synopsys brand to Wiki
In-Reply-To: <46d96e6c-61dc-f28c-8ac9-8db99292c334@mein.io>
References: <1467018805.3628.36.camel@synopsys.com>
 <46d96e6c-61dc-f28c-8ac9-8db99292c334@mein.io>
Message-ID: <1467220619.26022.37.camel@synopsys.com>

Hi Thomas,

Could you please assist me in adding new brand (Synopsys) to OpenWRT Wiki ToH?

That's my original request sent to Lede dev mailing list:
http://lists.infradead.org/pipermail/lede-dev/2016-June/001551.html

-Alexey

On Wed, 2016-06-29 at 15:42 +0200, Jo-Philipp Wich wrote:
> Hi Alexey,
> 
> please contact Thomas Endt <tmo -at- gmx.de> for assistance on adding
> brands to the OpenWrt Wiki ToH.
> 
> ~ Jo

From kevin at darbyshire-bryant.me.uk  Wed Jun 29 11:41:11 2016
From: kevin at darbyshire-bryant.me.uk (Kevin Darbyshire-Bryant)
Date: Wed, 29 Jun 2016 19:41:11 +0100
Subject: [LEDE-DEV] adding luci to snapshot images
In-Reply-To: <351faca4-edfa-c301-876f-afa9a06ba675@mein.io>
References: <83d8c156-1a53-e391-fb3e-2460d16ed20e@phrozen.org>
 <351faca4-edfa-c301-876f-afa9a06ba675@mein.io>
Message-ID: <57741647.8030003@darbyshire-bryant.me.uk>



On 29/06/16 15:54, Jo-Philipp Wich wrote:
> Hi,
>
> it would certainly help to bridge the gap until the #1 release and it
> would give more testing exposure to the ui...
>
> My observation on the matter is this:
> People who do *not* want to have the ui included are either building
> from source or using the IB anyway and those users *requiring* a ui tend
> to be unable to spin their own builds (no Linux os at hand, too hard, ...)
+1

Personally I think the novice user has enough concern over the flashing 
process let alone then being introduced to the whole command line & opkg 
stuff before they can get to a friendlier GUI.

Kevin



From david at lang.hm  Wed Jun 29 11:43:40 2016
From: david at lang.hm (David Lang)
Date: Wed, 29 Jun 2016 11:43:40 -0700 (PDT)
Subject: [LEDE-DEV] adding luci to snapshot images
In-Reply-To: <BLU405-EAS17D0B85832A0F3392ADB86DB230@phx.gbl>
References: <83d8c156-1a53-e391-fb3e-2460d16ed20e@phrozen.org>
 <351faca4-edfa-c301-876f-afa9a06ba675@mein.io>
 <BLU405-EAS17D0B85832A0F3392ADB86DB230@phx.gbl>
Message-ID: <alpine.DEB.2.02.1606291142020.14948@nftneq.ynat.uz>

I agree. There may be some devices with extremely small flash that can't fit 
luci, but otherwise I think it should be on the default images that people are 
pointed at.

Having a second set of images without luci isn't a bad idea, but if forced to 
choose, I would say they should have luci

David Lang

  On Wed, 29 Jun 2016, Adrian Panella 
wrote:

> Totally agree with the observation.
> +1 for including LuCI as default.
>
> -----Original Message-----
> From: Lede-dev [mailto:lede-dev-bounces at lists.infradead.org] On Behalf Of
> Jo-Philipp Wich
> Sent: mi?rcoles, 29 de junio de 2016 09:54 a.m.
> To: lede-dev at lists.infradead.org
> Subject: Re: [LEDE-DEV] adding luci to snapshot images
>
> Hi,
>
> it would certainly help to bridge the gap until the #1 release and it would
> give more testing exposure to the ui...
>
> My observation on the matter is this:
> People who do *not* want to have the ui included are either building from
> source or using the IB anyway and those users *requiring* a ui tend to be
> unable to spin their own builds (no Linux os at hand, too hard, ...)
>
> So personally I'd lean toward adding LuCI to the snapshots but would await
> further feedback on it.
>
> ~ Jo
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
>

From aczlan+ledev at gmail.com  Wed Jun 29 12:21:16 2016
From: aczlan+ledev at gmail.com (Aaron Z)
Date: Wed, 29 Jun 2016 15:21:16 -0400
Subject: [LEDE-DEV] adding luci to snapshot images
In-Reply-To: <alpine.DEB.2.02.1606291142020.14948@nftneq.ynat.uz>
References: <83d8c156-1a53-e391-fb3e-2460d16ed20e@phrozen.org>
 <351faca4-edfa-c301-876f-afa9a06ba675@mein.io>
 <BLU405-EAS17D0B85832A0F3392ADB86DB230@phx.gbl>
 <alpine.DEB.2.02.1606291142020.14948@nftneq.ynat.uz>
Message-ID: <CAKNoO9o5UtD5nn7bke-DDbmECzY_OdOX1pAXTFBDjQcw9y6MyA@mail.gmail.com>

On Wed, Jun 29, 2016 at 2:43 PM, David Lang <david at lang.hm> wrote:
> I agree. There may be some devices with extremely small flash that can't fit
> luci, but otherwise I think it should be on the default images that people
> are pointed at.
> Having a second set of images without luci isn't a bad idea, but if forced
> to choose, I would say they should have luci
+1, its confusing to your average person if you don't know how to SSH
in and install Luci via opkg.

Aaron Z


From john at phrozen.org  Wed Jun 29 14:02:15 2016
From: john at phrozen.org (John Crispin)
Date: Wed, 29 Jun 2016 23:02:15 +0200
Subject: [LEDE-DEV] server reboot
Message-ID: <b42aa032-312f-e1f8-c2e0-8f92073fbf80@phrozen.org>

hi,

the webserver will see an update to F24 tonight and get more disk space.
there will be several reboots over the next few hours. if all goes well
we will be back to normal operational mode in a few hours.

	John


From hauke at hauke-m.de  Wed Jun 29 14:13:00 2016
From: hauke at hauke-m.de (Hauke Mehrtens)
Date: Wed, 29 Jun 2016 23:13:00 +0200
Subject: [LEDE-DEV] [PATCH 1/2] firmware: extract prism54-firmware into own
	package
Message-ID: <1467234781-27748-1-git-send-email-hauke@hauke-m.de>

From: Hauke Mehrtens <hauke.mehrtens at intel.com>

Instead of downloading the firmware for prism54 devices in the
wireless.mk do it in an extra package Makefile. To ship the complete
source code Intel ships our modified OpenWrt/LEDE + the content of the
dl directory. We do not want to have any files in the dl/ directory
which are not needed to build our images. The prism54 gets downloaded
every time independently of building kmod-net-prism54 or not. When it
is in a own package it only gets downloaded when the firmware package
is selected.

Signed-off-by: Hauke Mehrtens <hauke.mehrtens at intel.com>
---
 package/firmware/prism54-firmware/Makefile | 39 ++++++++++++++++++++++++++++++
 package/kernel/linux/modules/wireless.mk   | 17 +------------
 2 files changed, 40 insertions(+), 16 deletions(-)
 create mode 100644 package/firmware/prism54-firmware/Makefile

diff --git a/package/firmware/prism54-firmware/Makefile b/package/firmware/prism54-firmware/Makefile
new file mode 100644
index 0000000..759e6b0
--- /dev/null
+++ b/package/firmware/prism54-firmware/Makefile
@@ -0,0 +1,39 @@
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=prism54-firmware
+PKG_VERSION:=1.0.4.3
+PKG_RELEASE:=1
+
+# Prism54 FullMAC firmware (jbnore.free.fr seems to be rather slow, so we use daemonizer.de)
+PKG_SOURCE:=$(PKG_VERSION).arm
+PKG_SOURCE_URL:=https://daemonizer.de/prism54/prism54-fw/fw-fullmac/
+PKG_MD5SUM:=8bd4310971772a486b9784c77f8a6df9
+
+include $(INCLUDE_DIR)/package.mk
+
+define Package/prism54-firmware
+  SECTION:=firmware
+  CATEGORY:=Firmware
+  URL:=https://daemonizer.de/prism54/prism54-fw
+  TITLE:=prism54 firmware
+endef
+
+define Build/Prepare
+	mkdir -p $(PKG_BUILD_DIR)
+endef
+
+define Build/Compile
+
+endef
+
+define Package/prism54-firmware/install
+	$(INSTALL_DIR) $(1)/lib/firmware
+	$(INSTALL_DATA) $(DL_DIR)/$(PKG_SOURCE) $(1)/lib/firmware/isl3890
+endef
+
+$(eval $(call BuildPackage,prism54-firmware))
diff --git a/package/kernel/linux/modules/wireless.mk b/package/kernel/linux/modules/wireless.mk
index d7c4425..72e2bf4 100644
--- a/package/kernel/linux/modules/wireless.mk
+++ b/package/kernel/linux/modules/wireless.mk
@@ -10,7 +10,7 @@ WIRELESS_MENU:=Wireless Drivers
 define KernelPackage/net-prism54
   SUBMENU:=$(WIRELESS_MENU)
   TITLE:=Intersil Prism54 support
-  DEPENDS:=@PCI_SUPPORT + at DRIVER_WEXT_SUPPORT
+  DEPENDS:=@PCI_SUPPORT + at DRIVER_WEXT_SUPPORT +prism54-firmware
   KCONFIG:=CONFIG_PRISM54
   FILES:= \
 	$(LINUX_DIR)/drivers/net/wireless/prism54/prism54.ko at lt4.5 \
@@ -22,21 +22,6 @@ define KernelPackage/net-prism54/description
  Kernel modules for Intersil Prism54 support
 endef
 
-# Prism54 FullMAC firmware (jbnore.free.fr seems to be rather slow, so we use daemonizer.de)
-PRISM54_FW:=1.0.4.3.arm
-
-define Download/net-prism54
-  FILE:=$(PRISM54_FW)
-  URL:=http://daemonizer.de/prism54/prism54-fw/fw-fullmac/
-  MD5SUM:=8bd4310971772a486b9784c77f8a6df9
-endef
-
-define KernelPackage/net-prism54/install
-	$(INSTALL_DIR) $(1)/lib/firmware
-	$(INSTALL_DATA) $(DL_DIR)/$(PRISM54_FW) $(1)/lib/firmware/isl3890
-endef
-
-$(eval $(call Download,net-prism54))
 $(eval $(call KernelPackage,net-prism54))
 
 
-- 
2.8.1



From hauke at hauke-m.de  Wed Jun 29 14:13:01 2016
From: hauke at hauke-m.de (Hauke Mehrtens)
Date: Wed, 29 Jun 2016 23:13:01 +0200
Subject: [LEDE-DEV] [PATCH 2/2] prism54-firmware: add also other p54
	firmware to own package
In-Reply-To: <1467234781-27748-1-git-send-email-hauke@hauke-m.de>
References: <1467234781-27748-1-git-send-email-hauke@hauke-m.de>
Message-ID: <1467234781-27748-2-git-send-email-hauke@hauke-m.de>

From: Hauke Mehrtens <hauke.mehrtens at intel.com>

Extract the other p54 firmware files into the prism54-firmware package.

Signed-off-by: Hauke Mehrtens <hauke.mehrtens at intel.com>
---
 package/firmware/prism54-firmware/Makefile | 75 ++++++++++++++++++++++++++++--
 package/kernel/mac80211/Makefile           | 48 ++-----------------
 2 files changed, 75 insertions(+), 48 deletions(-)

diff --git a/package/firmware/prism54-firmware/Makefile b/package/firmware/prism54-firmware/Makefile
index 759e6b0..2f39dc9 100644
--- a/package/firmware/prism54-firmware/Makefile
+++ b/package/firmware/prism54-firmware/Makefile
@@ -9,20 +9,70 @@ PKG_NAME:=prism54-firmware
 PKG_VERSION:=1.0.4.3
 PKG_RELEASE:=1
 
+PRG_URL:=https://daemonizer.de/prism54/prism54-fw/
+
 # Prism54 FullMAC firmware (jbnore.free.fr seems to be rather slow, so we use daemonizer.de)
 PKG_SOURCE:=$(PKG_VERSION).arm
-PKG_SOURCE_URL:=https://daemonizer.de/prism54/prism54-fw/fw-fullmac/
+PKG_SOURCE_URL:=$(PRG_URL)/fw-fullmac/
 PKG_MD5SUM:=8bd4310971772a486b9784c77f8a6df9
 
 include $(INCLUDE_DIR)/package.mk
 
-define Package/prism54-firmware
+
+# Prism54 drivers
+P54USBFW:=2.13.24.0.lm87.arm
+P54PCIFW:=2.13.12.0.arm
+P54SPIFW:=2.13.0.0.a.13.14.arm
+
+define Download/p54-usb-firmware
+  FILE:=$(P54USBFW)
+  URL:=$(PRG_URL)/fw-usb
+  MD5SUM:=8e8ab005a4f8f0123bcdc51bc25b47f6
+endef
+$(eval $(call Download,p54-usb-firmware))
+
+define Download/p54-pci-firmware
+  FILE:=$(P54PCIFW)
+  URL:=$(PRG_URL)/fw-softmac
+  MD5SUM:=ff7536af2092b1c4b21315bd103ef4c4
+endef
+$(eval $(call Download,p54-pci-firmware))
+
+define Download/p54-spi-firmware
+  FILE:=$(P54SPIFW)
+  URL:=$(PRG_URL)/stlc4560
+  MD5SUM:=42661f8ecbadd88012807493f596081d
+endef
+$(eval $(call Download,p54-spi-firmware))
+
+
+define Package/prism54-firmware-default
   SECTION:=firmware
   CATEGORY:=Firmware
-  URL:=https://daemonizer.de/prism54/prism54-fw
+  URL:=https://daemonizer.de/prism54/prism54-fw/
+endef
+
+define Package/prism54-firmware
+$(Package/prism54-firmware-default)
   TITLE:=prism54 firmware
 endef
 
+define Package/p54-usb-firmware
+$(Package/prism54-firmware-default)
+  TITLE:=p54-usb firmware
+endef
+
+define Package/p54-pci-firmware
+$(Package/prism54-firmware-default)
+  TITLE:=p54-pci firmware
+endef
+
+define Package/p54-spi-firmware
+$(Package/prism54-firmware-default)
+  TITLE:=p54-spi firmware
+endef
+
+
 define Build/Prepare
 	mkdir -p $(PKG_BUILD_DIR)
 endef
@@ -36,4 +86,23 @@ define Package/prism54-firmware/install
 	$(INSTALL_DATA) $(DL_DIR)/$(PKG_SOURCE) $(1)/lib/firmware/isl3890
 endef
 
+define Package/p54-usb-firmware/install
+	$(INSTALL_DIR) $(1)/lib/firmware
+	$(INSTALL_DATA) $(DL_DIR)/$(P54USBFW) $(1)/lib/firmware/isl3887usb
+endef
+
+define Package/p54-pci-firmware/install
+	$(INSTALL_DIR) $(1)/lib/firmware
+	$(INSTALL_DATA) $(DL_DIR)/$(P54PCIFW) $(1)/lib/firmware/isl3886pci
+endef
+
+define Package/p54-spi-firmware/install
+	$(INSTALL_DIR) $(1)/lib/firmware
+	$(INSTALL_DATA) $(DL_DIR)/$(P54SPIFW) $(1)/lib/firmware/3826.arm
+endef
+
+
 $(eval $(call BuildPackage,prism54-firmware))
+$(eval $(call BuildPackage,p54-usb-firmware))
+$(eval $(call BuildPackage,p54-pci-firmware))
+$(eval $(call BuildPackage,p54-spi-firmware))
diff --git a/package/kernel/mac80211/Makefile b/package/kernel/mac80211/Makefile
index bee0723..38eb4af 100644
--- a/package/kernel/mac80211/Makefile
+++ b/package/kernel/mac80211/Makefile
@@ -1061,33 +1061,6 @@ define KernelPackage/mwifiex-pcie/description
  Kernel modules for Marvell 802.11n/802.11ac PCIe Wireless cards
 endef
 
-
-# Prism54 drivers
-P54PCIFW:=2.13.12.0.arm
-P54USBFW:=2.13.24.0.lm87.arm
-P54SPIFW:=2.13.0.0.a.13.14.arm
-
-define Download/p54usb
-  FILE:=$(P54USBFW)
-  URL:=http://daemonizer.de/prism54/prism54-fw/fw-usb
-  MD5SUM:=8e8ab005a4f8f0123bcdc51bc25b47f6
-endef
-$(eval $(call Download,p54usb))
-
-define Download/p54pci
-  FILE:=$(P54PCIFW)
-  URL:=http://daemonizer.de/prism54/prism54-fw/fw-softmac
-  MD5SUM:=ff7536af2092b1c4b21315bd103ef4c4
-endef
-$(eval $(call Download,p54pci))
-
-define Download/p54spi
-  FILE:=$(P54SPIFW)
-  URL:=http://daemonizer.de/prism54/prism54-fw/stlc4560
-  MD5SUM:=42661f8ecbadd88012807493f596081d
-endef
-$(eval $(call Download,p54spi))
-
 define KernelPackage/p54/Default
   $(call KernelPackage/mac80211/Default)
   TITLE:=Prism54 Drivers
@@ -1107,7 +1080,7 @@ endef
 define KernelPackage/p54-pci
   $(call KernelPackage/p54/Default)
   TITLE+= (PCI)
-  DEPENDS+= @PCI_SUPPORT +kmod-p54-common
+  DEPENDS+= @PCI_SUPPORT +kmod-p54-common +p54-pci-firmware
   FILES:=$(PKG_BUILD_DIR)/drivers/net/wireless/intersil/p54/p54pci.ko
   AUTOLOAD:=$(call AutoProbe,p54pci)
 endef
@@ -1115,7 +1088,7 @@ endef
 define KernelPackage/p54-usb
   $(call KernelPackage/p54/Default)
   TITLE+= (USB)
-  DEPENDS+= @USB_SUPPORT +kmod-usb-core +kmod-p54-common
+  DEPENDS+= @USB_SUPPORT +kmod-usb-core +kmod-p54-common +p54-usb-firmware
   FILES:=$(PKG_BUILD_DIR)/drivers/net/wireless/intersil/p54/p54usb.ko
   AUTOLOAD:=$(call AutoProbe,p54usb)
 endef
@@ -1123,7 +1096,7 @@ endef
 define KernelPackage/p54-spi
   $(call KernelPackage/p54/Default)
   TITLE+= (SPI)
-  DEPENDS+= @TARGET_omap24xx +kmod-p54-common
+  DEPENDS+= @TARGET_omap24xx +kmod-p54-common +p54-spi-firmware
   FILES:=$(PKG_BUILD_DIR)/drivers/net/wireless/intersil/p54/p54spi.ko
   AUTOLOAD:=$(call AutoProbe,p54spi)
 endef
@@ -1771,21 +1744,6 @@ define KernelPackage/ipw2200/install
 	$(INSTALL_DATA) $(PKG_BUILD_DIR)/$(IPW2200_NAME)-$(IPW2200_VERSION)/ipw2200*.fw $(1)/lib/firmware
 endef
 
-define KernelPackage/p54-pci/install
-	$(INSTALL_DIR) $(1)/lib/firmware
-	$(INSTALL_DATA) $(DL_DIR)/$(P54PCIFW) $(1)/lib/firmware/isl3886pci
-endef
-
-define KernelPackage/p54-usb/install
-	$(INSTALL_DIR) $(1)/lib/firmware
-	$(INSTALL_DATA) $(DL_DIR)/$(P54USBFW) $(1)/lib/firmware/isl3887usb
-endef
-
-define KernelPackage/p54-spi/install
-	$(INSTALL_DIR) $(1)/lib/firmware
-	$(INSTALL_DATA) $(DL_DIR)/$(P54SPIFW) $(1)/lib/firmware/3826.arm
-endef
-
 define KernelPackage/zd1211rw/install
 	$(INSTALL_DIR) $(1)/lib/firmware/zd1211
 	$(INSTALL_DATA) $(PKG_BUILD_DIR)/$(ZD1211FW_NAME)/zd1211* $(1)/lib/firmware/zd1211
-- 
2.8.1



From hauke at hauke-m.de  Wed Jun 29 14:13:58 2016
From: hauke at hauke-m.de (Hauke Mehrtens)
Date: Wed, 29 Jun 2016 23:13:58 +0200
Subject: [LEDE-DEV] [PATCH] libnl-tiny: Generic Netlink multicast groups
	support
Message-ID: <1467234838-27822-1-git-send-email-hauke@hauke-m.de>

From: Hauke Mehrtens <hauke.mehrtens at intel.com>

This adds this commit from normal libnl to libnl-tiny:
https://github.com/tgraf/libnl/commit/2dbc1ca76c5b82c40749e609eb83877418abb006

commit 2dbc1ca76c5b82c40749e609eb83877418abb006
Author: dima <dima.ky at gmail.com>
Date:   Wed Oct 13 17:53:34 2010 +0300

    Generic Netlink multicast groups support

    I have a patch against commit d378220c96c3c8b6f27dca33e7d8ba03318f9c2d
    extending libnl with a facility to receive generic netlink messages sent
    to multicast groups.

    Essentially it add one new function genl_ctrl_resolve_grp which
    prototype looks like this
    int genl_ctrl_resolve_grp(struct nl_sock *sk, const char *family_name,
            const char *grp_name)
    It resolves  the family name and the group name to group id. Then
    the returned id can be used in nl_socket_add_membership to subscribe
    to multicast messages.

    Besides that it adds two more functions

    uint32_t nl_socket_get_peer_groups(struct nl_sock *sk)
    void nl_socket_set_peer_groups(struct nl_sock *sk, uint32_t groups)

    allowing to modify the socket peer groups field. So it's possible to
    multicast messages from the user space using the legacy interface.
    Looks like there is no way (or I was not able to find one?) to modify
    the netlink socket destination group from the user space, when the
    group id is greater then 32.

Signed-off-by: Hauke Mehrtens <hauke.mehrtens at intel.com>
---
 package/libs/libnl-tiny/src/genl_ctrl.c            | 78 ++++++++++++++++++++++
 package/libs/libnl-tiny/src/genl_family.c          | 33 +++++++++
 .../libs/libnl-tiny/src/include/netlink-types.h    |  7 ++
 .../libnl-tiny/src/include/netlink/genl/ctrl.h     |  3 +
 .../libnl-tiny/src/include/netlink/genl/family.h   |  4 ++
 .../libs/libnl-tiny/src/include/netlink/socket.h   | 10 +++
 package/libs/libnl-tiny/src/nl.c                   |  2 +-
 7 files changed, 136 insertions(+), 1 deletion(-)

diff --git a/package/libs/libnl-tiny/src/genl_ctrl.c b/package/libs/libnl-tiny/src/genl_ctrl.c
index 1301642..107a4fa 100644
--- a/package/libs/libnl-tiny/src/genl_ctrl.c
+++ b/package/libs/libnl-tiny/src/genl_ctrl.c
@@ -45,6 +45,7 @@ static struct nla_policy ctrl_policy[CTRL_ATTR_MAX+1] = {
 	[CTRL_ATTR_HDRSIZE]	= { .type = NLA_U32 },
 	[CTRL_ATTR_MAXATTR]	= { .type = NLA_U32 },
 	[CTRL_ATTR_OPS]		= { .type = NLA_NESTED },
+	[CTRL_ATTR_MCAST_GROUPS] = { .type = NLA_NESTED },
 };
 
 static struct nla_policy family_op_policy[CTRL_ATTR_OP_MAX+1] = {
@@ -52,6 +53,11 @@ static struct nla_policy family_op_policy[CTRL_ATTR_OP_MAX+1] = {
 	[CTRL_ATTR_OP_FLAGS]	= { .type = NLA_U32 },
 };
 
+static struct nla_policy family_grp_policy[CTRL_ATTR_MCAST_GRP_MAX+1] = {
+	[CTRL_ATTR_MCAST_GRP_NAME] = { .type = NLA_STRING },
+	[CTRL_ATTR_MCAST_GRP_ID]   = { .type = NLA_U32 },
+};
+
 static int ctrl_msg_parser(struct nl_cache_ops *ops, struct genl_cmd *cmd,
 			   struct genl_info *info, void *arg)
 {
@@ -126,6 +132,40 @@ static int ctrl_msg_parser(struct nl_cache_ops *ops, struct genl_cmd *cmd,
 
 		}
 	}
+	
+	if (info->attrs[CTRL_ATTR_MCAST_GROUPS]) {
+		struct nlattr *nla, *nla_grps;
+		int remaining;
+
+		nla_grps = info->attrs[CTRL_ATTR_MCAST_GROUPS];
+		nla_for_each_nested(nla, nla_grps, remaining) {
+			struct nlattr *tb[CTRL_ATTR_MCAST_GRP_MAX+1];
+			int id;
+			const char * name;
+
+			err = nla_parse_nested(tb, CTRL_ATTR_MCAST_GRP_MAX, nla,
+					       family_grp_policy);
+			if (err < 0)
+				goto errout;
+
+			if (tb[CTRL_ATTR_MCAST_GRP_ID] == NULL) {
+				err = -NLE_MISSING_ATTR;
+				goto errout;
+			}
+			id = nla_get_u32(tb[CTRL_ATTR_MCAST_GRP_ID]);
+
+			if (tb[CTRL_ATTR_MCAST_GRP_NAME] == NULL) {
+				err = -NLE_MISSING_ATTR;
+				goto errout;
+			}
+			name = nla_get_string(tb[CTRL_ATTR_MCAST_GRP_NAME]);
+
+			err = genl_family_add_grp(family, id, name);
+			if (err < 0)
+				goto errout;
+		}
+
+	}
 
 	err = pp->pp_cb((struct nl_object *) family, pp);
 errout:
@@ -242,6 +282,44 @@ errout:
 	return err;
 }
 
+static int genl_ctrl_grp_by_name(const struct genl_family *family,
+				const char *grp_name)
+{
+	struct genl_family_grp *grp;
+
+	nl_list_for_each_entry(grp, &family->gf_mc_grps, list) {
+		if (!strcmp(grp->name, grp_name)) {
+			return grp->id;
+		}
+	}
+
+	return -NLE_OBJ_NOTFOUND;
+}
+
+int genl_ctrl_resolve_grp(struct nl_sock *sk, const char *family_name,
+	const char *grp_name)
+{
+	struct nl_cache *cache;
+	struct genl_family *family;
+	int err;
+
+	if ((err = genl_ctrl_alloc_cache(sk, &cache)) < 0)
+		return err;
+
+	family = genl_ctrl_search_by_name(cache, family_name);
+	if (family == NULL) {
+		err = -NLE_OBJ_NOTFOUND;
+		goto errout;
+	}
+
+	err = genl_ctrl_grp_by_name(family, grp_name);
+	genl_family_put(family);
+errout:
+	nl_cache_free(cache);
+
+	return err;
+}
+
 /** @} */
 
 static struct genl_cmd genl_cmds[] = {
diff --git a/package/libs/libnl-tiny/src/genl_family.c b/package/libs/libnl-tiny/src/genl_family.c
index 88aaad9..aea8799 100644
--- a/package/libs/libnl-tiny/src/genl_family.c
+++ b/package/libs/libnl-tiny/src/genl_family.c
@@ -31,12 +31,14 @@ static void family_constructor(struct nl_object *c)
 	struct genl_family *family = (struct genl_family *) c;
 
 	nl_init_list_head(&family->gf_ops);
+	nl_init_list_head(&family->gf_mc_grps);
 }
 
 static void family_free_data(struct nl_object *c)
 {
 	struct genl_family *family = (struct genl_family *) c;
 	struct genl_family_op *ops, *tmp;
+	struct genl_family_grp *grp, *t_grp;
 
 	if (family == NULL)
 		return;
@@ -45,6 +47,12 @@ static void family_free_data(struct nl_object *c)
 		nl_list_del(&ops->o_list);
 		free(ops);
 	}
+
+	nl_list_for_each_entry_safe(grp, t_grp, &family->gf_mc_grps, list) {
+		nl_list_del(&grp->list);
+		free(grp);
+	}
+
 }
 
 static int family_clone(struct nl_object *_dst, struct nl_object *_src)
@@ -52,6 +60,7 @@ static int family_clone(struct nl_object *_dst, struct nl_object *_src)
 	struct genl_family *dst = nl_object_priv(_dst);
 	struct genl_family *src = nl_object_priv(_src);
 	struct genl_family_op *ops;
+	struct genl_family_grp *grp;
 	int err;
 
 	nl_list_for_each_entry(ops, &src->gf_ops, o_list) {
@@ -59,6 +68,13 @@ static int family_clone(struct nl_object *_dst, struct nl_object *_src)
 		if (err < 0)
 			return err;
 	}
+
+	nl_list_for_each_entry(grp, &src->gf_mc_grps, list) {
+		err = genl_family_add_grp(dst, grp->id, grp->name);
+		if (err < 0)
+			return err;
+	}
+
 	
 	return 0;
 }
@@ -119,6 +135,23 @@ int genl_family_add_op(struct genl_family *family, int id, int flags)
 	return 0;
 }
 
+int genl_family_add_grp(struct genl_family *family, uint32_t id,
+	       		const char *name)
+{
+	struct genl_family_grp *grp;
+
+	grp = calloc(1, sizeof(*grp));
+	if (grp == NULL)
+		return -NLE_NOMEM;
+
+	grp->id = id;
+	strncpy(grp->name, name, GENL_NAMSIZ - 1);
+
+	nl_list_add_tail(&grp->list, &family->gf_mc_grps);
+
+	return 0;
+}
+
 /** @} */
 
 /** @cond SKIP */
diff --git a/package/libs/libnl-tiny/src/include/netlink-types.h b/package/libs/libnl-tiny/src/include/netlink-types.h
index 0d00593..65f7f6c 100644
--- a/package/libs/libnl-tiny/src/include/netlink-types.h
+++ b/package/libs/libnl-tiny/src/include/netlink-types.h
@@ -69,6 +69,13 @@ struct nl_addr
 #define GENL_OP_HAS_DOIT	2
 #define GENL_OP_HAS_DUMPIT	4
 
+struct genl_family_grp {
+	struct genl_family	*family;	/* private */
+	struct nl_list_head	list;		/* private */
+	char			name[GENL_NAMSIZ];
+	u_int32_t		id;
+};
+
 struct genl_family_op
 {
 	uint32_t		o_id;
diff --git a/package/libs/libnl-tiny/src/include/netlink/genl/ctrl.h b/package/libs/libnl-tiny/src/include/netlink/genl/ctrl.h
index 1ae62f4..26a0a99 100644
--- a/package/libs/libnl-tiny/src/include/netlink/genl/ctrl.h
+++ b/package/libs/libnl-tiny/src/include/netlink/genl/ctrl.h
@@ -29,6 +29,9 @@ extern struct genl_family *	genl_ctrl_search_by_name(struct nl_cache *,
 							 const char *);
 extern int			genl_ctrl_resolve(struct nl_sock *,
 						  const char *);
+extern int 			genl_ctrl_resolve_grp(struct nl_sock *sk,
+						      const char *family,
+						      const char *grp);
 
 #ifdef __cplusplus
 }
diff --git a/package/libs/libnl-tiny/src/include/netlink/genl/family.h b/package/libs/libnl-tiny/src/include/netlink/genl/family.h
index 0257cbe..b7cf48f 100644
--- a/package/libs/libnl-tiny/src/include/netlink/genl/family.h
+++ b/package/libs/libnl-tiny/src/include/netlink/genl/family.h
@@ -39,6 +39,7 @@ struct genl_family
 	uint32_t		gf_maxattr;
 
 	struct nl_list_head	gf_ops;
+	struct nl_list_head	gf_mc_grps;
 };
 
 
@@ -47,6 +48,9 @@ extern void			genl_family_put(struct genl_family *);
 
 extern int			genl_family_add_op(struct genl_family *,
 						   int, int);
+extern int 			genl_family_add_grp(struct genl_family *,
+					uint32_t , const char *);
+
 
 /**
  * @name Attributes
diff --git a/package/libs/libnl-tiny/src/include/netlink/socket.h b/package/libs/libnl-tiny/src/include/netlink/socket.h
index 9f7f422..bcb934c 100644
--- a/package/libs/libnl-tiny/src/include/netlink/socket.h
+++ b/package/libs/libnl-tiny/src/include/netlink/socket.h
@@ -166,6 +166,16 @@ static inline void nl_socket_disable_msg_peek(struct nl_sock *sk)
 	sk->s_flags &= ~NL_MSG_PEEK;
 }
 
+static inline uint32_t nl_socket_get_peer_groups(struct nl_sock *sk)
+{
+	return sk->s_peer.nl_groups;
+}
+
+static inline void nl_socket_set_peer_groups(struct nl_sock *sk, uint32_t groups)
+{
+	sk->s_peer.nl_groups = groups;
+}
+
 /**
  * @name Callback Handler
  * @{
diff --git a/package/libs/libnl-tiny/src/nl.c b/package/libs/libnl-tiny/src/nl.c
index ea7d968..2fb866e 100644
--- a/package/libs/libnl-tiny/src/nl.c
+++ b/package/libs/libnl-tiny/src/nl.c
@@ -366,7 +366,7 @@ errout:
  * Receives a netlink message, allocates a buffer in \c *buf and
  * stores the message content. The peer's netlink address is stored
  * in \c *nla. The caller is responsible for freeing the buffer allocated
- * in \c *buf if a positive value is returned.  Interruped system calls
+ * in \c *buf if a positive value is returned.  Interrupted system calls
  * are handled by repeating the read. The input buffer size is determined
  * by peeking before the actual read is done.
  *
-- 
2.8.1



From hauke at hauke-m.de  Wed Jun 29 14:14:36 2016
From: hauke at hauke-m.de (Hauke Mehrtens)
Date: Wed, 29 Jun 2016 23:14:36 +0200
Subject: [LEDE-DEV] [PATCH] e2fsprogs: fix build problem with very old
	libmagic
Message-ID: <1467234876-27902-1-git-send-email-hauke@hauke-m.de>

From: Hauke Mehrtens <hauke.mehrtens at intel.com>

The libmagic shipped with RedHat 5 does not define
MAGIC_NO_CHECK_COMPRESS and MAGIC_NO_CHECK_COMPRESS. e2fsprogs should
check for that otherwise the build will fail.

Signed-off-by: Hauke Mehrtens <hauke.mehrtens at intel.com>
---
 tools/e2fsprogs/patches/010-old-libmagic.patch | 11 +++++++++++
 1 file changed, 11 insertions(+)
 create mode 100644 tools/e2fsprogs/patches/010-old-libmagic.patch

diff --git a/tools/e2fsprogs/patches/010-old-libmagic.patch b/tools/e2fsprogs/patches/010-old-libmagic.patch
new file mode 100644
index 0000000..5ba8a54
--- /dev/null
+++ b/tools/e2fsprogs/patches/010-old-libmagic.patch
@@ -0,0 +1,11 @@
+--- a/lib/support/plausible.c
++++ b/lib/support/plausible.c
+@@ -247,7 +247,7 @@ int check_plausibility(const char *devic
+ 		return 0;
+ 	}
+ 
+-#ifdef HAVE_MAGIC_H
++#if defined(HAVE_MAGIC_H) && defined(MAGIC_NO_CHECK_COMPRESS) && defined(MAGIC_NO_CHECK_COMPRESS)
+ 	if ((flags & CHECK_FS_EXIST) &&
+ 	    !getenv("E2FSPROGS_LIBMAGIC_SUPPRESS") &&
+ 	    magic_library_available()) {
-- 
2.8.1



From martin.blumenstingl at googlemail.com  Wed Jun 29 16:17:54 2016
From: martin.blumenstingl at googlemail.com (Martin Blumenstingl)
Date: Thu, 30 Jun 2016 01:17:54 +0200
Subject: [LEDE-DEV] [PATCH 0/4] kernel: mac80211: extend gpio_chip
	initialization
Message-ID: <20160629231758.8250-1-martin.blumenstingl@googlemail.com>

This re-uses the "number of GPIOs" which are already configured per
ath9k chip/revision during chip initialization in hw.c's
ath9k_hw_fill_cap_info().
It also sets the parent device of the GPIO controller which is not only
good practice, but it will also allow using the ath9k device as GPIO
controller in devicetree (once the patches for this have landed - these
are currently in discussion upstream).

As preparation for this all mac80211 patches are refreshed.


Martin Blumenstingl (3):
  kernel: mac80211: fold the AR9280 GPIO patch into the ath9k GPIO patch
  kernel: mac80211: enable the gpio controller for all ath9k devices
  kernel: mac80211: set the parent of the ath9k gpio_chip

Mathias Kresin (1):
  mac80211: refresh patches

 .../100-remove-cryptoapi-dependencies.patch        | 90 ++++++++++++----------
 .../mac80211/patches/530-ath9k_extra_leds.patch    | 12 +--
 .../patches/541-ath9k_rx_dma_stop_check.patch      |  4 +-
 .../patches/548-ath9k_enable_gpio_chip.patch       | 27 +++----
 .../patches/549-ath9k_enable_gpio_buttons.patch    | 10 +--
 .../patches/550-ath9k_add_ar9280_gpio_chip.patch   | 27 -------
 .../patches/910-01-add-support-for-mt7620.patch    |  6 +-
 7 files changed, 76 insertions(+), 100 deletions(-)
 delete mode 100644 package/kernel/mac80211/patches/550-ath9k_add_ar9280_gpio_chip.patch

-- 
2.9.0



From martin.blumenstingl at googlemail.com  Wed Jun 29 16:17:57 2016
From: martin.blumenstingl at googlemail.com (Martin Blumenstingl)
Date: Thu, 30 Jun 2016 01:17:57 +0200
Subject: [LEDE-DEV] [PATCH 3/4] kernel: mac80211: enable the gpio controller
	for all ath9k devices
In-Reply-To: <20160629231758.8250-1-martin.blumenstingl@googlemail.com>
References: <20160629231758.8250-1-martin.blumenstingl@googlemail.com>
Message-ID: <20160629231758.8250-4-martin.blumenstingl@googlemail.com>

This enables ath9k's built-in GPIO controller for all chip versions
(instead of an explicit whitelist). This also allows us to get rid of
some duplicate code between hw.c and gpio.c because hw.c already
determines the number of GPIOs.

Signed-off-by: Martin Blumenstingl <martin.blumenstingl at googlemail.com>
---
 .../patches/548-ath9k_enable_gpio_chip.patch       | 24 +++++++---------------
 .../patches/549-ath9k_enable_gpio_buttons.patch    | 10 ++++-----
 2 files changed, 12 insertions(+), 22 deletions(-)

diff --git a/package/kernel/mac80211/patches/548-ath9k_enable_gpio_chip.patch b/package/kernel/mac80211/patches/548-ath9k_enable_gpio_chip.patch
index 031be09..f516b8d 100644
--- a/package/kernel/mac80211/patches/548-ath9k_enable_gpio_chip.patch
+++ b/package/kernel/mac80211/patches/548-ath9k_enable_gpio_chip.patch
@@ -45,7 +45,7 @@ Signed-off-by: Felix Fietkau <nbd at nbd.name>
  #ifdef CPTCFG_ATH9K_DEBUGFS
 --- a/drivers/net/wireless/ath/ath9k/gpio.c
 +++ b/drivers/net/wireless/ath/ath9k/gpio.c
-@@ -16,13 +16,140 @@
+@@ -16,13 +16,130 @@
  
  #include "ath9k.h"
  #include <linux/ath9k_platform.h>
@@ -117,17 +117,7 @@ Signed-off-by: Felix Fietkau <nbd at nbd.name>
 +static void ath9k_register_gpio_chip(struct ath_softc *sc)
 +{
 +	struct ath9k_gpio_chip *gc;
-+	u16 ng;
-+
-+	/* supported chips are AR9280, AR9285 and AR9287 */
-+	if (AR_SREV_9287(sc->sc_ah))
-+		ng = AR9287_NUM_GPIO;
-+	else if (AR_SREV_9285(sc->sc_ah))
-+		ng = AR9285_NUM_GPIO;
-+	else if (AR_SREV_9280(sc->sc_ah))
-+		ng = AR9280_NUM_GPIO;
-+	else
-+		return;
++	struct ath_hw *ah = sc->sc_ah;
 +
 +	gc = kzalloc(sizeof(struct ath9k_gpio_chip), GFP_KERNEL);
 +	if (!gc)
@@ -137,7 +127,7 @@ Signed-off-by: Felix Fietkau <nbd at nbd.name>
 +		 wiphy_name(sc->hw->wiphy));
 +	gc->gchip.label = gc->label;
 +	gc->gchip.base = -1;	/* determine base automatically */
-+	gc->gchip.ngpio = ng;
++	gc->gchip.ngpio = ah->caps.num_gpio_pins;
 +	gc->gchip.direction_input = ath9k_gpio_pin_cfg_input;
 +	gc->gchip.direction_output = ath9k_gpio_pin_cfg_output;
 +	gc->gchip.get_direction = ath9k_gpio_pin_get_dir;
@@ -188,7 +178,7 @@ Signed-off-by: Felix Fietkau <nbd at nbd.name>
  static void ath_fill_led_pin(struct ath_softc *sc)
  {
  	struct ath_hw *ah = sc->sc_ah;
-@@ -80,6 +207,12 @@ static int ath_add_led(struct ath_softc
+@@ -80,6 +197,12 @@ static int ath_add_led(struct ath_softc
  	else
  		ath9k_hw_set_gpio(sc->sc_ah, gpio->gpio, gpio->active_low);
  
@@ -201,7 +191,7 @@ Signed-off-by: Felix Fietkau <nbd at nbd.name>
  	return 0;
  }
  
-@@ -136,12 +269,18 @@ void ath_deinit_leds(struct ath_softc *s
+@@ -136,12 +259,18 @@ void ath_deinit_leds(struct ath_softc *s
  
  	while (!list_empty(&sc->leds)) {
  		led = list_first_entry(&sc->leds, struct ath_led, list);
@@ -220,7 +210,7 @@ Signed-off-by: Felix Fietkau <nbd at nbd.name>
  }
  
  void ath_init_leds(struct ath_softc *sc)
-@@ -158,6 +297,8 @@ void ath_init_leds(struct ath_softc *sc)
+@@ -158,6 +287,8 @@ void ath_init_leds(struct ath_softc *sc)
  
  	ath_fill_led_pin(sc);
  
@@ -229,7 +219,7 @@ Signed-off-by: Felix Fietkau <nbd at nbd.name>
  	if (pdata && pdata->led_name)
  		strncpy(led_name, pdata->led_name, sizeof(led_name));
  	else
-@@ -178,6 +319,7 @@ void ath_init_leds(struct ath_softc *sc)
+@@ -178,6 +309,7 @@ void ath_init_leds(struct ath_softc *sc)
  	for (i = 0; i < pdata->num_leds; i++)
  		ath_create_platform_led(sc, &pdata->leds[i]);
  }
diff --git a/package/kernel/mac80211/patches/549-ath9k_enable_gpio_buttons.patch b/package/kernel/mac80211/patches/549-ath9k_enable_gpio_buttons.patch
index 41bebbb..9d887ce 100644
--- a/package/kernel/mac80211/patches/549-ath9k_enable_gpio_buttons.patch
+++ b/package/kernel/mac80211/patches/549-ath9k_enable_gpio_buttons.patch
@@ -29,7 +29,7 @@ Signed-off-by: Felix Fietkau <nbd at nbd.name>
  
  #ifdef CPTCFG_MAC80211_LEDS
  
-@@ -134,6 +136,64 @@ static void ath9k_unregister_gpio_chip(s
+@@ -124,6 +126,64 @@ static void ath9k_unregister_gpio_chip(s
  	sc->gpiochip = NULL;
  }
  
@@ -94,7 +94,7 @@ Signed-off-by: Felix Fietkau <nbd at nbd.name>
  #else /* CONFIG_GPIOLIB */
  
  static inline void ath9k_register_gpio_chip(struct ath_softc *sc)
-@@ -144,6 +204,14 @@ static inline void ath9k_unregister_gpio
+@@ -134,6 +194,14 @@ static inline void ath9k_unregister_gpio
  {
  }
  
@@ -109,7 +109,7 @@ Signed-off-by: Felix Fietkau <nbd at nbd.name>
  #endif /* CONFIG_GPIOLIB */
  
  /********************************/
-@@ -267,6 +335,7 @@ void ath_deinit_leds(struct ath_softc *s
+@@ -257,6 +325,7 @@ void ath_deinit_leds(struct ath_softc *s
  {
  	struct ath_led *led;
  
@@ -117,7 +117,7 @@ Signed-off-by: Felix Fietkau <nbd at nbd.name>
  	while (!list_empty(&sc->leds)) {
  		led = list_first_entry(&sc->leds, struct ath_led, list);
  #ifdef CONFIG_GPIOLIB
-@@ -298,6 +367,7 @@ void ath_init_leds(struct ath_softc *sc)
+@@ -288,6 +357,7 @@ void ath_init_leds(struct ath_softc *sc)
  	ath_fill_led_pin(sc);
  
  	ath9k_register_gpio_chip(sc);
@@ -125,7 +125,7 @@ Signed-off-by: Felix Fietkau <nbd at nbd.name>
  
  	if (pdata && pdata->led_name)
  		strncpy(led_name, pdata->led_name, sizeof(led_name));
-@@ -313,7 +383,7 @@ void ath_init_leds(struct ath_softc *sc)
+@@ -303,7 +373,7 @@ void ath_init_leds(struct ath_softc *sc)
  	ath_create_gpio_led(sc, sc->sc_ah->led_pin, led_name, trigger,
  			   !sc->sc_ah->config.led_active_high);
  
-- 
2.9.0



From martin.blumenstingl at googlemail.com  Wed Jun 29 16:17:58 2016
From: martin.blumenstingl at googlemail.com (Martin Blumenstingl)
Date: Thu, 30 Jun 2016 01:17:58 +0200
Subject: [LEDE-DEV] [PATCH 4/4] kernel: mac80211: set the parent of the
	ath9k gpio_chip
In-Reply-To: <20160629231758.8250-1-martin.blumenstingl@googlemail.com>
References: <20160629231758.8250-1-martin.blumenstingl@googlemail.com>
Message-ID: <20160629231758.8250-5-martin.blumenstingl@googlemail.com>

This allows gpiolib to re-use ath9k's devicetree node as GPIO
controller.
Example:

ath9k: ath9k at 0 {
	#gpio-cells = <2>;
	gpio-controller;
}

Now the ath9k node can be used just like any other GPIO controller:
	gpios = <&ath9k 1 GPIO_ACTIVE_HIGH>;

Signed-off-by: Martin Blumenstingl <martin.blumenstingl at googlemail.com>
---
 .../mac80211/patches/548-ath9k_enable_gpio_chip.patch     | 15 ++++++++++-----
 .../mac80211/patches/549-ath9k_enable_gpio_buttons.patch  | 10 +++++-----
 2 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/package/kernel/mac80211/patches/548-ath9k_enable_gpio_chip.patch b/package/kernel/mac80211/patches/548-ath9k_enable_gpio_chip.patch
index f516b8d..116860d 100644
--- a/package/kernel/mac80211/patches/548-ath9k_enable_gpio_chip.patch
+++ b/package/kernel/mac80211/patches/548-ath9k_enable_gpio_chip.patch
@@ -45,7 +45,7 @@ Signed-off-by: Felix Fietkau <nbd at nbd.name>
  #ifdef CPTCFG_ATH9K_DEBUGFS
 --- a/drivers/net/wireless/ath/ath9k/gpio.c
 +++ b/drivers/net/wireless/ath/ath9k/gpio.c
-@@ -16,13 +16,130 @@
+@@ -16,13 +16,135 @@
  
  #include "ath9k.h"
  #include <linux/ath9k_platform.h>
@@ -125,6 +125,11 @@ Signed-off-by: Felix Fietkau <nbd at nbd.name>
 +
 +	snprintf(gc->label, sizeof(gc->label), "ath9k-%s",
 +		 wiphy_name(sc->hw->wiphy));
++#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,5,0)
++	gc->gchip.parent = sc->dev;
++#else
++	gc->gchip.dev = sc->dev;
++#endif
 +	gc->gchip.label = gc->label;
 +	gc->gchip.base = -1;	/* determine base automatically */
 +	gc->gchip.ngpio = ah->caps.num_gpio_pins;
@@ -178,7 +183,7 @@ Signed-off-by: Felix Fietkau <nbd at nbd.name>
  static void ath_fill_led_pin(struct ath_softc *sc)
  {
  	struct ath_hw *ah = sc->sc_ah;
-@@ -80,6 +197,12 @@ static int ath_add_led(struct ath_softc
+@@ -80,6 +202,12 @@ static int ath_add_led(struct ath_softc
  	else
  		ath9k_hw_set_gpio(sc->sc_ah, gpio->gpio, gpio->active_low);
  
@@ -191,7 +196,7 @@ Signed-off-by: Felix Fietkau <nbd at nbd.name>
  	return 0;
  }
  
-@@ -136,12 +259,18 @@ void ath_deinit_leds(struct ath_softc *s
+@@ -136,12 +264,18 @@ void ath_deinit_leds(struct ath_softc *s
  
  	while (!list_empty(&sc->leds)) {
  		led = list_first_entry(&sc->leds, struct ath_led, list);
@@ -210,7 +215,7 @@ Signed-off-by: Felix Fietkau <nbd at nbd.name>
  }
  
  void ath_init_leds(struct ath_softc *sc)
-@@ -158,6 +287,8 @@ void ath_init_leds(struct ath_softc *sc)
+@@ -158,6 +292,8 @@ void ath_init_leds(struct ath_softc *sc)
  
  	ath_fill_led_pin(sc);
  
@@ -219,7 +224,7 @@ Signed-off-by: Felix Fietkau <nbd at nbd.name>
  	if (pdata && pdata->led_name)
  		strncpy(led_name, pdata->led_name, sizeof(led_name));
  	else
-@@ -178,6 +309,7 @@ void ath_init_leds(struct ath_softc *sc)
+@@ -178,6 +314,7 @@ void ath_init_leds(struct ath_softc *sc)
  	for (i = 0; i < pdata->num_leds; i++)
  		ath_create_platform_led(sc, &pdata->leds[i]);
  }
diff --git a/package/kernel/mac80211/patches/549-ath9k_enable_gpio_buttons.patch b/package/kernel/mac80211/patches/549-ath9k_enable_gpio_buttons.patch
index 9d887ce..d331b15 100644
--- a/package/kernel/mac80211/patches/549-ath9k_enable_gpio_buttons.patch
+++ b/package/kernel/mac80211/patches/549-ath9k_enable_gpio_buttons.patch
@@ -29,7 +29,7 @@ Signed-off-by: Felix Fietkau <nbd at nbd.name>
  
  #ifdef CPTCFG_MAC80211_LEDS
  
-@@ -124,6 +126,64 @@ static void ath9k_unregister_gpio_chip(s
+@@ -129,6 +131,64 @@ static void ath9k_unregister_gpio_chip(s
  	sc->gpiochip = NULL;
  }
  
@@ -94,7 +94,7 @@ Signed-off-by: Felix Fietkau <nbd at nbd.name>
  #else /* CONFIG_GPIOLIB */
  
  static inline void ath9k_register_gpio_chip(struct ath_softc *sc)
-@@ -134,6 +194,14 @@ static inline void ath9k_unregister_gpio
+@@ -139,6 +199,14 @@ static inline void ath9k_unregister_gpio
  {
  }
  
@@ -109,7 +109,7 @@ Signed-off-by: Felix Fietkau <nbd at nbd.name>
  #endif /* CONFIG_GPIOLIB */
  
  /********************************/
-@@ -257,6 +325,7 @@ void ath_deinit_leds(struct ath_softc *s
+@@ -262,6 +330,7 @@ void ath_deinit_leds(struct ath_softc *s
  {
  	struct ath_led *led;
  
@@ -117,7 +117,7 @@ Signed-off-by: Felix Fietkau <nbd at nbd.name>
  	while (!list_empty(&sc->leds)) {
  		led = list_first_entry(&sc->leds, struct ath_led, list);
  #ifdef CONFIG_GPIOLIB
-@@ -288,6 +357,7 @@ void ath_init_leds(struct ath_softc *sc)
+@@ -293,6 +362,7 @@ void ath_init_leds(struct ath_softc *sc)
  	ath_fill_led_pin(sc);
  
  	ath9k_register_gpio_chip(sc);
@@ -125,7 +125,7 @@ Signed-off-by: Felix Fietkau <nbd at nbd.name>
  
  	if (pdata && pdata->led_name)
  		strncpy(led_name, pdata->led_name, sizeof(led_name));
-@@ -303,7 +373,7 @@ void ath_init_leds(struct ath_softc *sc)
+@@ -308,7 +378,7 @@ void ath_init_leds(struct ath_softc *sc)
  	ath_create_gpio_led(sc, sc->sc_ah->led_pin, led_name, trigger,
  			   !sc->sc_ah->config.led_active_high);
  
-- 
2.9.0



From martin.blumenstingl at googlemail.com  Wed Jun 29 16:17:56 2016
From: martin.blumenstingl at googlemail.com (Martin Blumenstingl)
Date: Thu, 30 Jun 2016 01:17:56 +0200
Subject: [LEDE-DEV] [PATCH 2/4] kernel: mac80211: fold the AR9280 GPIO patch
	into the ath9k GPIO patch
In-Reply-To: <20160629231758.8250-1-martin.blumenstingl@googlemail.com>
References: <20160629231758.8250-1-martin.blumenstingl@googlemail.com>
Message-ID: <20160629231758.8250-3-martin.blumenstingl@googlemail.com>

This folds 550-ath9k_add_ar9280_gpio_chip.patch into
548-ath9k_enable_gpio_chip.patch because the former patch only extends
code which is introduced in the latter.

Signed-off-by: Martin Blumenstingl <martin.blumenstingl at googlemail.com>
---
 .../patches/548-ath9k_enable_gpio_chip.patch       | 14 ++++++-----
 .../patches/549-ath9k_enable_gpio_buttons.patch    | 10 ++++----
 .../patches/550-ath9k_add_ar9280_gpio_chip.patch   | 27 ----------------------
 3 files changed, 13 insertions(+), 38 deletions(-)
 delete mode 100644 package/kernel/mac80211/patches/550-ath9k_add_ar9280_gpio_chip.patch

diff --git a/package/kernel/mac80211/patches/548-ath9k_enable_gpio_chip.patch b/package/kernel/mac80211/patches/548-ath9k_enable_gpio_chip.patch
index 1c89e42..031be09 100644
--- a/package/kernel/mac80211/patches/548-ath9k_enable_gpio_chip.patch
+++ b/package/kernel/mac80211/patches/548-ath9k_enable_gpio_chip.patch
@@ -45,7 +45,7 @@ Signed-off-by: Felix Fietkau <nbd at nbd.name>
  #ifdef CPTCFG_ATH9K_DEBUGFS
 --- a/drivers/net/wireless/ath/ath9k/gpio.c
 +++ b/drivers/net/wireless/ath/ath9k/gpio.c
-@@ -16,13 +16,138 @@
+@@ -16,13 +16,140 @@
  
  #include "ath9k.h"
  #include <linux/ath9k_platform.h>
@@ -119,11 +119,13 @@ Signed-off-by: Felix Fietkau <nbd at nbd.name>
 +	struct ath9k_gpio_chip *gc;
 +	u16 ng;
 +
-+	/* for now only AR9285 and AR9287 are recognized */
++	/* supported chips are AR9280, AR9285 and AR9287 */
 +	if (AR_SREV_9287(sc->sc_ah))
 +		ng = AR9287_NUM_GPIO;
 +	else if (AR_SREV_9285(sc->sc_ah))
 +		ng = AR9285_NUM_GPIO;
++	else if (AR_SREV_9280(sc->sc_ah))
++		ng = AR9280_NUM_GPIO;
 +	else
 +		return;
 +
@@ -186,7 +188,7 @@ Signed-off-by: Felix Fietkau <nbd at nbd.name>
  static void ath_fill_led_pin(struct ath_softc *sc)
  {
  	struct ath_hw *ah = sc->sc_ah;
-@@ -80,6 +205,12 @@ static int ath_add_led(struct ath_softc
+@@ -80,6 +207,12 @@ static int ath_add_led(struct ath_softc
  	else
  		ath9k_hw_set_gpio(sc->sc_ah, gpio->gpio, gpio->active_low);
  
@@ -199,7 +201,7 @@ Signed-off-by: Felix Fietkau <nbd at nbd.name>
  	return 0;
  }
  
-@@ -136,12 +267,18 @@ void ath_deinit_leds(struct ath_softc *s
+@@ -136,12 +269,18 @@ void ath_deinit_leds(struct ath_softc *s
  
  	while (!list_empty(&sc->leds)) {
  		led = list_first_entry(&sc->leds, struct ath_led, list);
@@ -218,7 +220,7 @@ Signed-off-by: Felix Fietkau <nbd at nbd.name>
  }
  
  void ath_init_leds(struct ath_softc *sc)
-@@ -158,6 +295,8 @@ void ath_init_leds(struct ath_softc *sc)
+@@ -158,6 +297,8 @@ void ath_init_leds(struct ath_softc *sc)
  
  	ath_fill_led_pin(sc);
  
@@ -227,7 +229,7 @@ Signed-off-by: Felix Fietkau <nbd at nbd.name>
  	if (pdata && pdata->led_name)
  		strncpy(led_name, pdata->led_name, sizeof(led_name));
  	else
-@@ -178,6 +317,7 @@ void ath_init_leds(struct ath_softc *sc)
+@@ -178,6 +319,7 @@ void ath_init_leds(struct ath_softc *sc)
  	for (i = 0; i < pdata->num_leds; i++)
  		ath_create_platform_led(sc, &pdata->leds[i]);
  }
diff --git a/package/kernel/mac80211/patches/549-ath9k_enable_gpio_buttons.patch b/package/kernel/mac80211/patches/549-ath9k_enable_gpio_buttons.patch
index c7973bb..41bebbb 100644
--- a/package/kernel/mac80211/patches/549-ath9k_enable_gpio_buttons.patch
+++ b/package/kernel/mac80211/patches/549-ath9k_enable_gpio_buttons.patch
@@ -29,7 +29,7 @@ Signed-off-by: Felix Fietkau <nbd at nbd.name>
  
  #ifdef CPTCFG_MAC80211_LEDS
  
-@@ -132,6 +134,64 @@ static void ath9k_unregister_gpio_chip(s
+@@ -134,6 +136,64 @@ static void ath9k_unregister_gpio_chip(s
  	sc->gpiochip = NULL;
  }
  
@@ -94,7 +94,7 @@ Signed-off-by: Felix Fietkau <nbd at nbd.name>
  #else /* CONFIG_GPIOLIB */
  
  static inline void ath9k_register_gpio_chip(struct ath_softc *sc)
-@@ -142,6 +202,14 @@ static inline void ath9k_unregister_gpio
+@@ -144,6 +204,14 @@ static inline void ath9k_unregister_gpio
  {
  }
  
@@ -109,7 +109,7 @@ Signed-off-by: Felix Fietkau <nbd at nbd.name>
  #endif /* CONFIG_GPIOLIB */
  
  /********************************/
-@@ -265,6 +333,7 @@ void ath_deinit_leds(struct ath_softc *s
+@@ -267,6 +335,7 @@ void ath_deinit_leds(struct ath_softc *s
  {
  	struct ath_led *led;
  
@@ -117,7 +117,7 @@ Signed-off-by: Felix Fietkau <nbd at nbd.name>
  	while (!list_empty(&sc->leds)) {
  		led = list_first_entry(&sc->leds, struct ath_led, list);
  #ifdef CONFIG_GPIOLIB
-@@ -296,6 +365,7 @@ void ath_init_leds(struct ath_softc *sc)
+@@ -298,6 +367,7 @@ void ath_init_leds(struct ath_softc *sc)
  	ath_fill_led_pin(sc);
  
  	ath9k_register_gpio_chip(sc);
@@ -125,7 +125,7 @@ Signed-off-by: Felix Fietkau <nbd at nbd.name>
  
  	if (pdata && pdata->led_name)
  		strncpy(led_name, pdata->led_name, sizeof(led_name));
-@@ -311,7 +381,7 @@ void ath_init_leds(struct ath_softc *sc)
+@@ -313,7 +383,7 @@ void ath_init_leds(struct ath_softc *sc)
  	ath_create_gpio_led(sc, sc->sc_ah->led_pin, led_name, trigger,
  			   !sc->sc_ah->config.led_active_high);
  
diff --git a/package/kernel/mac80211/patches/550-ath9k_add_ar9280_gpio_chip.patch b/package/kernel/mac80211/patches/550-ath9k_add_ar9280_gpio_chip.patch
deleted file mode 100644
index 22e2c66..0000000
--- a/package/kernel/mac80211/patches/550-ath9k_add_ar9280_gpio_chip.patch
+++ /dev/null
@@ -1,27 +0,0 @@
-From: Michal Cieslakiewicz <michal.cieslakiewicz at wp.pl>
-Date: Thu, 21 Apr 2016 23:00:54 +0200
-Subject: [PATCH] mac80211: ath9k: add GPIO support for AR9280 chip
-
-Enable access to GPIO on Atheros wireless chip AR9280.
-Support for 9280 is added to existing 9285/9287 subsystem
-because these 3 chips differ only in number of GPIO pins.
-
-Signed-off-by: Michal Cieslakiewicz <michal.cieslakiewicz at wp.pl>
----
---- a/drivers/net/wireless/ath/ath9k/gpio.c
-+++ b/drivers/net/wireless/ath/ath9k/gpio.c
-@@ -88,11 +88,13 @@ static void ath9k_register_gpio_chip(str
- 	struct ath9k_gpio_chip *gc;
- 	u16 ng;
- 
--	/* for now only AR9285 and AR9287 are recognized */
-+	/* supported chips are AR9280, AR9285 and AR9287 */
- 	if (AR_SREV_9287(sc->sc_ah))
- 		ng = AR9287_NUM_GPIO;
- 	else if (AR_SREV_9285(sc->sc_ah))
- 		ng = AR9285_NUM_GPIO;
-+	else if (AR_SREV_9280(sc->sc_ah))
-+		ng = AR9280_NUM_GPIO;
- 	else
- 		return;
- 
-- 
2.9.0



From martin.blumenstingl at googlemail.com  Wed Jun 29 16:17:55 2016
From: martin.blumenstingl at googlemail.com (Martin Blumenstingl)
Date: Thu, 30 Jun 2016 01:17:55 +0200
Subject: [LEDE-DEV] [PATCH 1/4] mac80211: refresh patches
In-Reply-To: <20160629231758.8250-1-martin.blumenstingl@googlemail.com>
References: <20160629231758.8250-1-martin.blumenstingl@googlemail.com>
Message-ID: <20160629231758.8250-2-martin.blumenstingl@googlemail.com>

From: Mathias Kresin <dev at kresin.me>

Signed-off-by: Mathias Kresin <dev at kresin.me>
---
 .../100-remove-cryptoapi-dependencies.patch        | 90 ++++++++++++----------
 .../mac80211/patches/530-ath9k_extra_leds.patch    | 12 +--
 .../patches/541-ath9k_rx_dma_stop_check.patch      |  4 +-
 .../patches/910-01-add-support-for-mt7620.patch    |  6 +-
 4 files changed, 59 insertions(+), 53 deletions(-)

diff --git a/package/kernel/mac80211/patches/100-remove-cryptoapi-dependencies.patch b/package/kernel/mac80211/patches/100-remove-cryptoapi-dependencies.patch
index b65b0bd..fbe22e5 100644
--- a/package/kernel/mac80211/patches/100-remove-cryptoapi-dependencies.patch
+++ b/package/kernel/mac80211/patches/100-remove-cryptoapi-dependencies.patch
@@ -34,9 +34,12 @@
  #include "aes_ccm.h"
  
 -void ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
+-			       u8 *data, size_t data_len, u8 *mic,
+-			       size_t mic_len)
 +static void aes_ccm_prepare(struct crypto_cipher *tfm, u8 *b_0, u8 *aad, u8 *s_0,
 +			    u8 *a, u8 *b)
-+{
+ {
+-	struct scatterlist sg[3];
 +	int i;
 +
 +	crypto_cipher_encrypt_one(tfm, b, b_0);
@@ -51,56 +54,55 @@
 +	for (i = 0; i < AES_BLOCK_SIZE; i++)
 +		aad[i] ^= b[i];
 +	crypto_cipher_encrypt_one(tfm, a, aad);
-+
+ 
+-	char aead_req_data[sizeof(struct aead_request) +
+-			   crypto_aead_reqsize(tfm)]
+-		__aligned(__alignof__(struct aead_request));
+-	struct aead_request *aead_req = (void *) aead_req_data;
 +	/* Mask out bits from auth-only-b_0 */
 +	b_0[0] &= 0x07;
-+
+ 
+-	memset(aead_req, 0, sizeof(aead_req_data));
 +	/* S_0 is used to encrypt T (= MIC) */
 +	b_0[14] = 0;
 +	b_0[15] = 0;
 +	crypto_cipher_encrypt_one(tfm, s_0, b_0);
 +}
-+
-+
+ 
+-	sg_init_table(sg, 3);
+-	sg_set_buf(&sg[0], &aad[2], be16_to_cpup((__be16 *)aad));
+-	sg_set_buf(&sg[1], data, data_len);
+-	sg_set_buf(&sg[2], mic, mic_len);
+ 
+-	aead_request_set_tfm(aead_req, tfm);
+-	aead_request_set_crypt(aead_req, sg, sg, data_len, b_0);
+-	aead_request_set_ad(aead_req, sg[0].length);
 +void ieee80211_aes_ccm_encrypt(struct crypto_cipher *tfm, u8 *b_0, u8 *aad,
- 			       u8 *data, size_t data_len, u8 *mic,
- 			       size_t mic_len)
- {
--	struct scatterlist sg[3];
++			       u8 *data, size_t data_len, u8 *mic,
++			       size_t mic_len)
++{
 +	int i, j, last_len, num_blocks;
 +	u8 b[AES_BLOCK_SIZE];
 +	u8 s_0[AES_BLOCK_SIZE];
 +	u8 e[AES_BLOCK_SIZE];
 +	u8 *pos, *cpos;
- 
--	char aead_req_data[sizeof(struct aead_request) +
--			   crypto_aead_reqsize(tfm)]
--		__aligned(__alignof__(struct aead_request));
--	struct aead_request *aead_req = (void *) aead_req_data;
++
 +	num_blocks = DIV_ROUND_UP(data_len, AES_BLOCK_SIZE);
 +	last_len = data_len % AES_BLOCK_SIZE;
 +	aes_ccm_prepare(tfm, b_0, aad, s_0, b, b);
- 
--	memset(aead_req, 0, sizeof(aead_req_data));
++
 +	/* Process payload blocks */
 +	pos = data;
 +	cpos = data;
 +	for (j = 1; j <= num_blocks; j++) {
 +		int blen = (j == num_blocks && last_len) ?
 +			last_len : AES_BLOCK_SIZE;
- 
--	sg_init_table(sg, 3);
--	sg_set_buf(&sg[0], &aad[2], be16_to_cpup((__be16 *)aad));
--	sg_set_buf(&sg[1], data, data_len);
--	sg_set_buf(&sg[2], mic, mic_len);
++
 +		/* Authentication followed by encryption */
 +		for (i = 0; i < blen; i++)
 +			b[i] ^= pos[i];
 +		crypto_cipher_encrypt_one(tfm, b, b);
- 
--	aead_request_set_tfm(aead_req, tfm);
--	aead_request_set_crypt(aead_req, sg, sg, data_len, b_0);
--	aead_request_set_ad(aead_req, sg[0].length);
++
 +		b_0[14] = (j >> 8) & 0xff;
 +		b_0[15] = j & 0xff;
 +		crypto_cipher_encrypt_one(tfm, e, b_0);
@@ -123,30 +125,37 @@
 -			   crypto_aead_reqsize(tfm)]
 -		__aligned(__alignof__(struct aead_request));
 -	struct aead_request *aead_req = (void *) aead_req_data;
+-
+-	if (data_len == 0)
+-		return -EINVAL;
+-
+-	memset(aead_req, 0, sizeof(aead_req_data));
+-
+-	sg_init_table(sg, 3);
+-	sg_set_buf(&sg[0], &aad[2], be16_to_cpup((__be16 *)aad));
+-	sg_set_buf(&sg[1], data, data_len);
+-	sg_set_buf(&sg[2], mic, mic_len);
+-
+-	aead_request_set_tfm(aead_req, tfm);
+-	aead_request_set_crypt(aead_req, sg, sg, data_len + mic_len, b_0);
+-	aead_request_set_ad(aead_req, sg[0].length);
 +	int i, j, last_len, num_blocks;
 +	u8 *pos, *cpos;
 +	u8 a[AES_BLOCK_SIZE];
 +	u8 b[AES_BLOCK_SIZE];
 +	u8 s_0[AES_BLOCK_SIZE];
- 
--	if (data_len == 0)
--		return -EINVAL;
++
 +	num_blocks = DIV_ROUND_UP(data_len, AES_BLOCK_SIZE);
 +	last_len = data_len % AES_BLOCK_SIZE;
 +	aes_ccm_prepare(tfm, b_0, aad, s_0, a, b);
- 
--	memset(aead_req, 0, sizeof(aead_req_data));
++
 +	/* Process payload blocks */
 +	cpos = data;
 +	pos = data;
 +	for (j = 1; j <= num_blocks; j++) {
 +		int blen = (j == num_blocks && last_len) ?
 +			last_len : AES_BLOCK_SIZE;
- 
--	sg_init_table(sg, 3);
--	sg_set_buf(&sg[0], &aad[2], be16_to_cpup((__be16 *)aad));
--	sg_set_buf(&sg[1], data, data_len);
--	sg_set_buf(&sg[2], mic, mic_len);
++
 +		/* Decryption followed by authentication */
 +		b_0[14] = (j >> 8) & 0xff;
 +		b_0[15] = j & 0xff;
@@ -157,10 +166,7 @@
 +		}
 +		crypto_cipher_encrypt_one(tfm, a, a);
 +	}
- 
--	aead_request_set_tfm(aead_req, tfm);
--	aead_request_set_crypt(aead_req, sg, sg, data_len + mic_len, b_0);
--	aead_request_set_ad(aead_req, sg[0].length);
++
 +	for (i = 0; i < mic_len; i++) {
 +		if ((mic[i] ^ s_0[i]) != a[i])
 +			return -1;
@@ -179,12 +185,12 @@
  {
 -	struct crypto_aead *tfm;
 -	int err;
--
++	struct crypto_cipher *tfm;
+ 
 -	tfm = crypto_alloc_aead("ccm(aes)", 0, CRYPTO_ALG_ASYNC);
 -	if (IS_ERR(tfm))
 -		return tfm;
-+	struct crypto_cipher *tfm;
- 
+-
 -	err = crypto_aead_setkey(tfm, key, key_len);
 -	if (err)
 -		goto free_aead;
diff --git a/package/kernel/mac80211/patches/530-ath9k_extra_leds.patch b/package/kernel/mac80211/patches/530-ath9k_extra_leds.patch
index 6001266..0204fa0 100644
--- a/package/kernel/mac80211/patches/530-ath9k_extra_leds.patch
+++ b/package/kernel/mac80211/patches/530-ath9k_extra_leds.patch
@@ -112,8 +112,7 @@
 +		      GFP_KERNEL);
 +	if (!led)
 +		return -ENOMEM;
- 
--	ath9k_hw_set_gpio(sc->sc_ah, sc->sc_ah->led_pin, val);
++
 +	led->gpio = gpio = (struct gpio_led *) (led + 1);
 +	_name = (char *) (led->gpio + 1);
 +
@@ -126,7 +125,8 @@
 +	ret = ath_add_led(sc, led);
 +	if (unlikely(ret < 0))
 +		kfree(led);
-+
+ 
+-	ath9k_hw_set_gpio(sc->sc_ah, sc->sc_ah->led_pin, val);
 +	return ret;
  }
  
@@ -134,11 +134,11 @@
  {
 -	if (!sc->led_registered)
 -		return;
--
--	ath_led_brightness(&sc->led_cdev, LED_OFF);
--	led_classdev_unregister(&sc->led_cdev);
 +	struct ath_led *led;
  
+-	ath_led_brightness(&sc->led_cdev, LED_OFF);
+-	led_classdev_unregister(&sc->led_cdev);
+-
 -	ath9k_hw_gpio_free(sc->sc_ah, sc->sc_ah->led_pin);
 +	while (!list_empty(&sc->leds)) {
 +		led = list_first_entry(&sc->leds, struct ath_led, list);
diff --git a/package/kernel/mac80211/patches/541-ath9k_rx_dma_stop_check.patch b/package/kernel/mac80211/patches/541-ath9k_rx_dma_stop_check.patch
index 3c5e9f5..c2d2781 100644
--- a/package/kernel/mac80211/patches/541-ath9k_rx_dma_stop_check.patch
+++ b/package/kernel/mac80211/patches/541-ath9k_rx_dma_stop_check.patch
@@ -1,6 +1,6 @@
 --- a/drivers/net/wireless/ath/ath9k/mac.c
 +++ b/drivers/net/wireless/ath/ath9k/mac.c
-@@ -695,7 +695,7 @@ bool ath9k_hw_stopdmarecv(struct ath_hw
+@@ -698,7 +698,7 @@ bool ath9k_hw_stopdmarecv(struct ath_hw
  {
  #define AH_RX_STOP_DMA_TIMEOUT 10000   /* usec */
  	struct ath_common *common = ath9k_hw_common(ah);
@@ -9,7 +9,7 @@
  	int i;
  
  	/* Enable access to the DMA observation bus */
-@@ -725,6 +725,16 @@ bool ath9k_hw_stopdmarecv(struct ath_hw
+@@ -728,6 +728,16 @@ bool ath9k_hw_stopdmarecv(struct ath_hw
  	}
  
  	if (i == 0) {
diff --git a/package/kernel/mac80211/patches/910-01-add-support-for-mt7620.patch b/package/kernel/mac80211/patches/910-01-add-support-for-mt7620.patch
index be210f2..b53102b 100644
--- a/package/kernel/mac80211/patches/910-01-add-support-for-mt7620.patch
+++ b/package/kernel/mac80211/patches/910-01-add-support-for-mt7620.patch
@@ -91,8 +91,7 @@
 +			rt2x00_set_field32(&reg, RF_CSR_CFG_REGNUM_MT7620, word);
 +			rt2x00_set_field32(&reg, RF_CSR_CFG_WRITE_MT7620, 1);
 +			rt2x00_set_field32(&reg, RF_CSR_CFG_BUSY_MT7620, 1);
- 
--		rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG, reg);
++
 +			rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG, reg);
 +		}
 +		break;
@@ -104,7 +103,8 @@
 +			rt2x00_set_field32(&reg, RF_CSR_CFG_REGNUM, word);
 +			rt2x00_set_field32(&reg, RF_CSR_CFG_WRITE, 1);
 +			rt2x00_set_field32(&reg, RF_CSR_CFG_BUSY, 1);
-+
+ 
+-		rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG, reg);
 +			rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG, reg);
 +		}
 +		break;
-- 
2.9.0



From yszhou4tech at gmail.com  Wed Jun 29 18:54:17 2016
From: yszhou4tech at gmail.com (Yousong Zhou)
Date: Thu, 30 Jun 2016 09:54:17 +0800
Subject: [LEDE-DEV] [PATCH v2 0/4] ar71xx: image: a few fixes
Message-ID: <1467251661-24376-1-git-send-email-yszhou4tech@gmail.com>

The patch on HiWiFi HC6361 has been run-tested.

The patch on seama image build has only been compile-tested and inspected
manually.  I'd like to wait for some acks before it get merged.

v1 -> v2:

 - Fix making making sysupgrade image: the .seama ext of output file seama
   utility was previously missed out at the final step

Yousong Zhou (4):
  ar71xx: hiwifi-hc6361: move packages selection to generic.mk
  ar71xx: image: remove duplicate IMAGES definition
  ar71xx: image: unify indentation with 2 whitespaces
  ar71xx: seama: fix making factory images

 target/linux/ar71xx/image/Makefile          |   1 -
 target/linux/ar71xx/image/generic.mk        | 320 ++++++++++++++++++----------
 target/linux/ar71xx/image/legacy-devices.mk |  26 ---
 target/linux/ar71xx/image/legacy.mk         |  40 ----
 4 files changed, 202 insertions(+), 185 deletions(-)

-- 
2.6.4



From yszhou4tech at gmail.com  Wed Jun 29 18:54:18 2016
From: yszhou4tech at gmail.com (Yousong Zhou)
Date: Thu, 30 Jun 2016 09:54:18 +0800
Subject: [LEDE-DEV] [PATCH v2 1/4] ar71xx: hiwifi-hc6361: move packages
	selection to generic.mk
In-Reply-To: <1467251661-24376-1-git-send-email-yszhou4tech@gmail.com>
References: <1467251661-24376-1-git-send-email-yszhou4tech@gmail.com>
Message-ID: <1467251661-24376-2-git-send-email-yszhou4tech@gmail.com>

Remove kmod-crypto-deflate and kmod-ledtrig-gpio as the device works the
same by default without them

Signed-off-by: Yousong Zhou <yszhou4tech at gmail.com>
---
 target/linux/ar71xx/image/generic.mk        | 15 +++++++++------
 target/linux/ar71xx/image/legacy-devices.mk |  8 --------
 2 files changed, 9 insertions(+), 14 deletions(-)

diff --git a/target/linux/ar71xx/image/generic.mk b/target/linux/ar71xx/image/generic.mk
index 095c542..6802501 100644
--- a/target/linux/ar71xx/image/generic.mk
+++ b/target/linux/ar71xx/image/generic.mk
@@ -421,11 +421,14 @@ define Build/uImageHiWiFi
 endef
 
 define Device/hiwifi-hc6361
-    BOARDNAME := HiWiFi-HC6361
-    DEVICE_PROFILE := HIWIFI_HC6361
-    IMAGE_SIZE := 16128k
-    KERNEL := kernel-bin | patch-cmdline | lzma | uImageHiWiFi lzma
-    CONSOLE := ttyATH0,115200
-    MTDPARTS := spi0.0:64k(u-boot)ro,64k(bdinfo)ro,16128k(firmware),64k(backup)ro,64k(art)ro
+  DEVICE_TITLE := HiWiFi HC6361
+  DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-storage \
+	kmod-fs-ext4 kmod-nls-iso8859-1 e2fsprogs
+  BOARDNAME := HiWiFi-HC6361
+  DEVICE_PROFILE := HIWIFI_HC6361
+  IMAGE_SIZE := 16128k
+  KERNEL := kernel-bin | patch-cmdline | lzma | uImageHiWiFi lzma
+  CONSOLE := ttyATH0,115200
+  MTDPARTS := spi0.0:64k(u-boot)ro,64k(bdinfo)ro,16128k(firmware),64k(backup)ro,64k(art)ro
 endef
 TARGET_DEVICES += hiwifi-hc6361
diff --git a/target/linux/ar71xx/image/legacy-devices.mk b/target/linux/ar71xx/image/legacy-devices.mk
index 0e51fef..c8e1476 100644
--- a/target/linux/ar71xx/image/legacy-devices.mk
+++ b/target/linux/ar71xx/image/legacy-devices.mk
@@ -401,14 +401,6 @@ define LegacyDevice/EWDORIN
 endef
 LEGACY_DEVICES += EWDORIN
 
-define LegacyDevice/HIWIFI_HC6361
-	DEVICE_TITLE := HiWiFi HC6361
-	DEVICE_PACKAGES :=  kmod-usb-core kmod-usb2 kmod-usb-storage \
-		kmod-crypto-deflate kmod-fs-ext4 kmod-ledtrig-gpio \
-		kmod-nls-iso8859-1 e2fsprogs
-endef
-LEGACY_DEVICES += HIWIFI_HC6361
-
 define LegacyDevice/JA76PF
 	DEVICE_TITLE := jjPlus JA76PF
 	DEVICE_PACKAGES := kmod-usb-core kmod-usb-ohci kmod-usb2 kmod-hwmon-core kmod-i2c-core kmod-hwmon-lm75
-- 
2.6.4



From yszhou4tech at gmail.com  Wed Jun 29 18:54:19 2016
From: yszhou4tech at gmail.com (Yousong Zhou)
Date: Thu, 30 Jun 2016 09:54:19 +0800
Subject: [LEDE-DEV] [PATCH v2 2/4] ar71xx: image: remove duplicate IMAGES
	definition
In-Reply-To: <1467251661-24376-1-git-send-email-yszhou4tech@gmail.com>
References: <1467251661-24376-1-git-send-email-yszhou4tech@gmail.com>
Message-ID: <1467251661-24376-3-git-send-email-yszhou4tech@gmail.com>

Signed-off-by: Yousong Zhou <yszhou4tech at gmail.com>
---
 target/linux/ar71xx/image/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/target/linux/ar71xx/image/Makefile b/target/linux/ar71xx/image/Makefile
index 2380a62..ced1610 100644
--- a/target/linux/ar71xx/image/Makefile
+++ b/target/linux/ar71xx/image/Makefile
@@ -88,7 +88,6 @@ define Device/Default
   DEVICE_PROFILE = $$(BOARDNAME)
   PROFILES = Default Minimal $$(DEVICE_PROFILE)
   MTDPARTS :=
-  IMAGES := sysupgrade.bin
   BLOCKSIZE := 64k
   FILESYSTEMS = $(filter-out jffs2-%,$(TARGET_FILESYSTEMS)) jffs2-$$(BLOCKSIZE)
   CONSOLE = ttyS0,115200
-- 
2.6.4



From yszhou4tech at gmail.com  Wed Jun 29 18:54:20 2016
From: yszhou4tech at gmail.com (Yousong Zhou)
Date: Thu, 30 Jun 2016 09:54:20 +0800
Subject: [LEDE-DEV] [PATCH v2 3/4] ar71xx: image: unify indentation with 2
	whitespaces
In-Reply-To: <1467251661-24376-1-git-send-email-yszhou4tech@gmail.com>
References: <1467251661-24376-1-git-send-email-yszhou4tech@gmail.com>
Message-ID: <1467251661-24376-4-git-send-email-yszhou4tech@gmail.com>

Signed-off-by: Yousong Zhou <yszhou4tech at gmail.com>
---
 target/linux/ar71xx/image/generic.mk | 224 +++++++++++++++++------------------
 1 file changed, 112 insertions(+), 112 deletions(-)

diff --git a/target/linux/ar71xx/image/generic.mk b/target/linux/ar71xx/image/generic.mk
index 6802501..3e3dc69 100644
--- a/target/linux/ar71xx/image/generic.mk
+++ b/target/linux/ar71xx/image/generic.mk
@@ -188,176 +188,176 @@ endef
 TARGET_DEVICES += cr5000-nocloud
 
 define Device/antminer-s1
-    $(Device/tplink-8mlzma)
-    DEVICE_TITLE := Antminer-S1
-    DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-crypto-manager kmod-i2c-gpio-custom kmod-usb-hid
-    BOARDNAME := ANTMINER-S1
-    DEVICE_PROFILE := ANTMINERS1
-    TPLINK_HWID := 0x04440101
-    CONSOLE := ttyATH0,115200
+  $(Device/tplink-8mlzma)
+  DEVICE_TITLE := Antminer-S1
+  DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-crypto-manager kmod-i2c-gpio-custom kmod-usb-hid
+  BOARDNAME := ANTMINER-S1
+  DEVICE_PROFILE := ANTMINERS1
+  TPLINK_HWID := 0x04440101
+  CONSOLE := ttyATH0,115200
 endef
 
 define Device/antminer-s3
-    $(Device/tplink-8mlzma)
-    DEVICE_TITLE := Antminer-S3
-    DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-crypto-manager kmod-i2c-gpio-custom kmod-usb-hid
-    BOARDNAME := ANTMINER-S3
-    DEVICE_PROFILE := ANTMINERS3
-    TPLINK_HWID := 0x04440301
-    CONSOLE := ttyATH0,115200
+  $(Device/tplink-8mlzma)
+  DEVICE_TITLE := Antminer-S3
+  DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-crypto-manager kmod-i2c-gpio-custom kmod-usb-hid
+  BOARDNAME := ANTMINER-S3
+  DEVICE_PROFILE := ANTMINERS3
+  TPLINK_HWID := 0x04440301
+  CONSOLE := ttyATH0,115200
 endef
 
 define Device/antrouter-r1
-    $(Device/tplink-8mlzma)
-    DEVICE_TITLE := Antrouter-R1
-    DEVICE_PACKAGES := kmod-usb-core kmod-usb2
-    BOARDNAME := ANTROUTER-R1
-    DEVICE_PROFILE := ANTROUTERR1
-    TPLINK_HWID := 0x44440101
-    CONSOLE := ttyATH0,115200
+  $(Device/tplink-8mlzma)
+  DEVICE_TITLE := Antrouter-R1
+  DEVICE_PACKAGES := kmod-usb-core kmod-usb2
+  BOARDNAME := ANTROUTER-R1
+  DEVICE_PROFILE := ANTROUTERR1
+  TPLINK_HWID := 0x44440101
+  CONSOLE := ttyATH0,115200
 endef
 
 define Device/el-m150
-    $(Device/tplink-8mlzma)
-    DEVICE_TITLE := EasyLink EL-M150
-    DEVICE_PACKAGES := kmod-usb-core kmod-usb2
-    BOARDNAME := EL-M150
-    DEVICE_PROFILE := ELM150
-    TPLINK_HWID := 0x01500101
-    CONSOLE := ttyATH0,115200
+  $(Device/tplink-8mlzma)
+  DEVICE_TITLE := EasyLink EL-M150
+  DEVICE_PACKAGES := kmod-usb-core kmod-usb2
+  BOARDNAME := EL-M150
+  DEVICE_PROFILE := ELM150
+  TPLINK_HWID := 0x01500101
+  CONSOLE := ttyATH0,115200
 endef
 
 define Device/el-mini
-    $(Device/tplink-8mlzma)
-    DEVICE_TITLE := EasyLink EL-MINI
-    DEVICE_PACKAGES := kmod-usb-core kmod-usb2
-    BOARDNAME := EL-MINI
-    DEVICE_PROFILE := ELMINI
-    TPLINK_HWID := 0x01530001
-    CONSOLE := ttyATH0,115200
+  $(Device/tplink-8mlzma)
+  DEVICE_TITLE := EasyLink EL-MINI
+  DEVICE_PACKAGES := kmod-usb-core kmod-usb2
+  BOARDNAME := EL-MINI
+  DEVICE_PROFILE := ELMINI
+  TPLINK_HWID := 0x01530001
+  CONSOLE := ttyATH0,115200
 endef
 TARGET_DEVICES += antminer-s1 antminer-s3 antrouter-r1 el-m150 el-mini
 
 define Device/gl-inet-6408A-v1
-    $(Device/tplink-8mlzma)
-    DEVICE_TITLE := GL.iNet 6408
-    DEVICE_PACKAGES := kmod-usb-core kmod-usb2
-    BOARDNAME := GL-INET
-    DEVICE_PROFILE := GLINET
-    TPLINK_HWID := 0x08000001
-    CONSOLE := ttyATH0,115200
+  $(Device/tplink-8mlzma)
+  DEVICE_TITLE := GL.iNet 6408
+  DEVICE_PACKAGES := kmod-usb-core kmod-usb2
+  BOARDNAME := GL-INET
+  DEVICE_PROFILE := GLINET
+  TPLINK_HWID := 0x08000001
+  CONSOLE := ttyATH0,115200
 endef
 
 define Device/gl-inet-6416A-v1
-    $(Device/tplink-16mlzma)
-    DEVICE_TITLE := GL.iNet 6416
-    DEVICE_PACKAGES := kmod-usb-core kmod-usb2
-    BOARDNAME := GL-INET
-    DEVICE_PROFILE := GLINET
-    TPLINK_HWID := 0x08000001
-    CONSOLE := ttyATH0,115200
+  $(Device/tplink-16mlzma)
+  DEVICE_TITLE := GL.iNet 6416
+  DEVICE_PACKAGES := kmod-usb-core kmod-usb2
+  BOARDNAME := GL-INET
+  DEVICE_PROFILE := GLINET
+  TPLINK_HWID := 0x08000001
+  CONSOLE := ttyATH0,115200
 endef
 TARGET_DEVICES += gl-inet-6408A-v1 gl-inet-6416A-v1
 
 define Device/rnx-n360rt
-    $(Device/tplink-4m)
-    DEVICE_TITLE := Rosewill RNX-N360RT
-    BOARDNAME := TL-WR941ND
-    DEVICE_PROFILE := RNXN360RT
-    TPLINK_HWID := 0x09410002
-    TPLINK_HWREV := 0x00420001
+  $(Device/tplink-4m)
+  DEVICE_TITLE := Rosewill RNX-N360RT
+  BOARDNAME := TL-WR941ND
+  DEVICE_PROFILE := RNXN360RT
+  TPLINK_HWID := 0x09410002
+  TPLINK_HWREV := 0x00420001
 endef
 TARGET_DEVICES += rnx-n360rt
 
 define Device/mc-mac1200r
-    $(Device/tplink-8mlzma)
-    DEVICE_TITLE := MERCURY MAC1200R
-    DEVICE_PACKAGES := kmod-ath10k
-    BOARDNAME := MC-MAC1200R
-    DEVICE_PROFILE := MAC1200R
-    TPLINK_HWID := 0x12000001
+  $(Device/tplink-8mlzma)
+  DEVICE_TITLE := MERCURY MAC1200R
+  DEVICE_PACKAGES := kmod-ath10k
+  BOARDNAME := MC-MAC1200R
+  DEVICE_PROFILE := MAC1200R
+  TPLINK_HWID := 0x12000001
 endef
 TARGET_DEVICES += mc-mac1200r
 
 define Device/minibox-v1
-    $(Device/tplink-16mlzma)
-    DEVICE_TITLE := Gainstrong MiniBox V1.0
-    DEVICE_PACKAGES := kmod-usb-core kmod-usb2  kmod-ledtrig-usbdev
-    BOARDNAME := MINIBOX-V1
-    DEVICE_PROFILE := MINIBOXV1
-    TPLINK_HWID := 0x3C000201
-    CONSOLE := ttyATH0,115200
+  $(Device/tplink-16mlzma)
+  DEVICE_TITLE := Gainstrong MiniBox V1.0
+  DEVICE_PACKAGES := kmod-usb-core kmod-usb2  kmod-ledtrig-usbdev
+  BOARDNAME := MINIBOX-V1
+  DEVICE_PROFILE := MINIBOXV1
+  TPLINK_HWID := 0x3C000201
+  CONSOLE := ttyATH0,115200
 endef
 TARGET_DEVICES += minibox-v1
 
 define Device/omy-g1
-    $(Device/tplink-16mlzma)
-    DEVICE_TITLE := OMYlink OMY-G1
-    DEVICE_PACKAGES := kmod-usb-core kmod-usb2
-    BOARDNAME := OMY-G1
-    DEVICE_PROFILE := OMYG1
-    TPLINK_HWID := 0x06660101
+  $(Device/tplink-16mlzma)
+  DEVICE_TITLE := OMYlink OMY-G1
+  DEVICE_PACKAGES := kmod-usb-core kmod-usb2
+  BOARDNAME := OMY-G1
+  DEVICE_PROFILE := OMYG1
+  TPLINK_HWID := 0x06660101
 endef
 
 define Device/omy-x1
-    $(Device/tplink-8mlzma)
-    DEVICE_TITLE := OMYlink OMY-X1
-    BOARDNAME := OMY-X1
-    DEVICE_PROFILE := OMYX1
-    TPLINK_HWID := 0x06660201
+  $(Device/tplink-8mlzma)
+  DEVICE_TITLE := OMYlink OMY-X1
+  BOARDNAME := OMY-X1
+  DEVICE_PROFILE := OMYX1
+  TPLINK_HWID := 0x06660201
 endef
 TARGET_DEVICES += omy-g1 omy-x1
 
 define Device/onion-omega
-    $(Device/tplink-16mlzma)
-    DEVICE_TITLE := Onion Omega
-    DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-storage kmod-i2c-core kmod-i2c-gpio-custom kmod-spi-bitbang kmod-spi-dev kmod-spi-gpio kmod-spi-gpio-custom kmod-usb-serial
-    BOARDNAME := ONION-OMEGA
-    DEVICE_PROFILE := OMEGA
-    TPLINK_HWID := 0x04700001
-    CONSOLE := ttyATH0,115200
+  $(Device/tplink-16mlzma)
+  DEVICE_TITLE := Onion Omega
+  DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-storage kmod-i2c-core kmod-i2c-gpio-custom kmod-spi-bitbang kmod-spi-dev kmod-spi-gpio kmod-spi-gpio-custom kmod-usb-serial
+  BOARDNAME := ONION-OMEGA
+  DEVICE_PROFILE := OMEGA
+  TPLINK_HWID := 0x04700001
+  CONSOLE := ttyATH0,115200
 endef
 TARGET_DEVICES += onion-omega
 
 define Device/smart-300
-    $(Device/tplink-8mlzma)
-    DEVICE_TITLE := NC-LINK SMART-300
-    BOARDNAME := SMART-300
-    DEVICE_PROFILE := SMART-300
-    TPLINK_HWID := 0x93410001
+  $(Device/tplink-8mlzma)
+  DEVICE_TITLE := NC-LINK SMART-300
+  BOARDNAME := SMART-300
+  DEVICE_PROFILE := SMART-300
+  TPLINK_HWID := 0x93410001
 endef
 TARGET_DEVICES += smart-300
 
 define Device/som9331
-    $(Device/tplink-8mlzma)
-    DEVICE_TITLE := OpenEmbed SOM9331
-    DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-storage kmod-i2c-core kmod-i2c-gpio-custom kmod-spi-bitbang kmod-spi-dev kmod-spi-gpio kmod-spi-gpio-custom kmod-usb-serial
-    BOARDNAME := SOM9331
-    DEVICE_PROFILE := SOM9331
-    TPLINK_HWID := 0x04800054
-    CONSOLE := ttyATH0,115200
+  $(Device/tplink-8mlzma)
+  DEVICE_TITLE := OpenEmbed SOM9331
+  DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-storage kmod-i2c-core kmod-i2c-gpio-custom kmod-spi-bitbang kmod-spi-dev kmod-spi-gpio kmod-spi-gpio-custom kmod-usb-serial
+  BOARDNAME := SOM9331
+  DEVICE_PROFILE := SOM9331
+  TPLINK_HWID := 0x04800054
+  CONSOLE := ttyATH0,115200
 endef
 TARGET_DEVICES += som9331
 
 define Device/tellstick-znet-lite
-    $(Device/tplink-16mlzma)
-    DEVICE_TITLE := TellStick ZNet Lite
-    DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-acm kmod-usb-serial kmod-usb-serial-pl2303
-    BOARDNAME := TELLSTICK-ZNET-LITE
-    DEVICE_PROFILE := TELLSTICKZNETLITE
-    TPLINK_HWID := 0x00726001
-    CONSOLE := ttyATH0,115200
+  $(Device/tplink-16mlzma)
+  DEVICE_TITLE := TellStick ZNet Lite
+  DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-acm kmod-usb-serial kmod-usb-serial-pl2303
+  BOARDNAME := TELLSTICK-ZNET-LITE
+  DEVICE_PROFILE := TELLSTICKZNETLITE
+  TPLINK_HWID := 0x00726001
+  CONSOLE := ttyATH0,115200
 endef
 TARGET_DEVICES += tellstick-znet-lite
 
 define Device/oolite
-    $(Device/tplink-16mlzma)
-    DEVICE_TITLE := Gainstrong OOLITE
-    DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-ledtrig-usbdev
-    BOARDNAME := GS-OOLITE
-    DEVICE_PROFILE := OOLITE
-    TPLINK_HWID := 0x3C000101
-    CONSOLE := ttyATH0,115200
+  $(Device/tplink-16mlzma)
+  DEVICE_TITLE := Gainstrong OOLITE
+  DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-ledtrig-usbdev
+  BOARDNAME := GS-OOLITE
+  DEVICE_PROFILE := OOLITE
+  TPLINK_HWID := 0x3C000101
+  CONSOLE := ttyATH0,115200
 endef
 TARGET_DEVICES += oolite
 
-- 
2.6.4



From yszhou4tech at gmail.com  Wed Jun 29 18:54:21 2016
From: yszhou4tech at gmail.com (Yousong Zhou)
Date: Thu, 30 Jun 2016 09:54:21 +0800
Subject: [LEDE-DEV] [PATCH v2 4/4] ar71xx: seama: fix making factory images
In-Reply-To: <1467251661-24376-1-git-send-email-yszhou4tech@gmail.com>
References: <1467251661-24376-1-git-send-email-yszhou4tech@gmail.com>
Message-ID: <1467251661-24376-5-git-send-email-yszhou4tech@gmail.com>

rootfs part needs to be aligned to erase block size which is passed as
the 6th argument to Image/Build/Seama  and is now 65536 since commit
commit 5119ee9 "ar71xx: fix bogus hardcoded kernel image size for Seama
images (fixes #20585)", but $(($(6) - 64)) still assumes that the
argument is a limit on kernel partition size, i.e. 1310720, so the
generated factory image is wrong in that the kernel will fail to find
the rootfs (FlySpray link at [1])

This patch will workaround it with the following steps

1. Calculate the required space for seama header and META data in step 5
2. Pre-padding 64 bytes to lzma-compressed loader
3. Generate correctly padded image-$(2).tmp
4. Strip out the padding
5. Seal it with seama utility

While at it convert seama to new build method

[1] FS#35 - mynet-n750 factory images don't find root partition,
    https://bugs.lede-project.org/index.php?do=details&task_id=35

Reported-by: Steven Haigh <netwiz at crc.id.au>
Signed-off-by: Yousong Zhou <yszhou4tech at gmail.com>
---
 target/linux/ar71xx/image/generic.mk        | 81 +++++++++++++++++++++++++++++
 target/linux/ar71xx/image/legacy-devices.mk | 18 -------
 target/linux/ar71xx/image/legacy.mk         | 40 --------------
 3 files changed, 81 insertions(+), 58 deletions(-)

diff --git a/target/linux/ar71xx/image/generic.mk b/target/linux/ar71xx/image/generic.mk
index 3e3dc69..b8e70a4 100644
--- a/target/linux/ar71xx/image/generic.mk
+++ b/target/linux/ar71xx/image/generic.mk
@@ -432,3 +432,84 @@ define Device/hiwifi-hc6361
   MTDPARTS := spi0.0:64k(u-boot)ro,64k(bdinfo)ro,16128k(firmware),64k(backup)ro,64k(art)ro
 endef
 TARGET_DEVICES += hiwifi-hc6361
+
+
+# The pre-filled 64 bytes consist of
+# - 28 bytes seama_header
+# - 36 bytes of META data (4-bytes aligned)
+#
+# And as the 4 bytes jffs2 marker will be erased on first boot, they need to
+# be excluded from the calculation of checksum
+define Build/seama-factory
+	( dd if=/dev/zero bs=64 count=1; cat $(word 1,$^) ) >$@.loader.tmp
+	( dd if=$@.loader.tmp bs=64k conv=sync; dd if=$(word 2,$^) ) >$@.tmp.0
+	tail -c +65 $@.tmp.0 >$@.tmp.1
+	head -c -4 $@.tmp.1 >$@.tmp.2
+	$(STAGING_DIR_HOST)/bin/seama \
+		-i $@.tmp.2 \
+		-m "dev=/dev/mtdblock/1" -m "type=firmware"
+	$(STAGING_DIR_HOST)/bin/seama \
+		-s $@ \
+		-m "signature=$(1)" \
+		-i $@.tmp.2.seama
+	tail -c 4 $@.tmp.1 >>$@
+	rm -f $@.loader.tmp $@.tmp.*
+endef
+
+define Build/seama-sysupgrade
+	$(STAGING_DIR_HOST)/bin/seama \
+		-i $(word 1,$^) \
+		-m "dev=/dev/mtdblock/1" -m "type=firmware"
+	( dd if=$(word 1,$^).seama bs=64k conv=sync; dd if=$(word 2,$^) ) >$@
+endef
+
+define Build/seama-initramfs
+	$(STAGING_DIR_HOST)/bin/seama \
+		-i $@ \
+		-m "dev=/dev/mtdblock/1" -m "type=firmware"
+	mv $@.seama $@
+endef
+
+define Device/seama
+  CONSOLE := ttyS0,115200
+  KERNEL := kernel-bin | loader-kernel-cmdline | lzma
+  KERNEL_INITRAMFS := kernel-bin | patch-cmdline | lzma | seama-initramfs
+  KERNEL_INITRAMFS_SUFFIX = $$(KERNEL_SUFFIX).seama
+  IMAGES := sysupgrade.bin factory.bin
+  IMAGE/sysupgrade.bin := seama-sysupgrade $$$$(SEAMA_SIGNATURE) | check-size $$$$(IMAGE_SIZE)
+  IMAGE/factory.bin := seama-factory $$$$(SEAMA_SIGNATURE) | check-size $$$$(IMAGE_SIZE)
+  SEAMA_SIGNATURE :=
+  DEVICE_VARS := SEAMA_SIGNATURE
+endef
+
+define Device/mynet-n600
+$(Device/seama)
+  DEVICE_TITLE := Western Digital My Net N600
+  DEVICE_PACKAGES := kmod-usb-core kmod-usb2
+  BOARDNAME = MYNET-N600
+  IMAGE_SIZE = 15808k
+  MTDPARTS = spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,64k(devdata)ro,64k(devconf)ro,15872k(firmware),64k(radiocfg)ro
+  SEAMA_SIGNATURE := wrgnd16_wd_db600
+endef
+
+define Device/mynet-n750
+$(Device/seama)
+  DEVICE_TITLE := Western Digital My Net N750
+  DEVICE_PACKAGES := kmod-usb-core kmod-usb2
+  BOARDNAME = MYNET-N750
+  IMAGE_SIZE = 15808k
+  MTDPARTS = spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,64k(devdata)ro,64k(devconf)ro,15872k(firmware),64k(radiocfg)ro
+  SEAMA_SIGNATURE := wrgnd13_wd_av
+endef
+
+define Device/qihoo-c301
+$(Device/seama)
+  DEVICE_TITLE := Qihoo C301
+  DEVICE_PACKAGES :=  kmod-usb-core kmod-usb2 kmod-ledtrig-usbdev kmod-ath10k
+  BOARDNAME = QIHOO-C301
+  IMAGE_SIZE = 15744k
+  MTDPARTS = mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env),64k(devdata),64k(devconf),15744k(firmware),64k(warm_start),64k(action_image_config),64k(radiocfg)ro;spi0.1:15360k(upgrade2),1024k(privatedata)
+  SEAMA_SIGNATURE := wrgac26_qihoo360_360rg
+endef
+
+TARGET_DEVICES += mynet-n600 mynet-n750 qihoo-c301
diff --git a/target/linux/ar71xx/image/legacy-devices.mk b/target/linux/ar71xx/image/legacy-devices.mk
index c8e1476..07d3df6 100644
--- a/target/linux/ar71xx/image/legacy-devices.mk
+++ b/target/linux/ar71xx/image/legacy-devices.mk
@@ -542,12 +542,6 @@ define LegacyDevice/MZKW300NH
 endef
 LEGACY_DEVICES += MZKW300NH
 
-define LegacyDevice/QIHOO360
-	DEVICE_TITLE := Qihoo 360 C301
-	DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-ledtrig-usbdev kmod-ath10k
-endef
-LEGACY_DEVICES += QIHOO360
-
 define LegacyDevice/RW2458N
 	DEVICE_TITLE := Redwave RW2458N
 	DEVICE_PACKAGES := kmod-usb-core kmod-usb-ohci kmod-ath9k wpad-mini
@@ -608,18 +602,6 @@ define LegacyDevice/DR344
 endef
 LEGACY_DEVICES += DR344
 
-define LegacyDevice/MYNETN600
-	DEVICE_TITLE := WD My Net N600
-	DEVICE_PACKAGES := kmod-usb-core kmod-usb2
-endef
-LEGACY_DEVICES += MYNETN600
-
-define LegacyDevice/MYNETN750
-	DEVICE_TITLE := WD My Net N750
-	DEVICE_PACKAGES := kmod-usb-core kmod-usb2
-endef
-LEGACY_DEVICES += MYNETN750
-
 define LegacyDevice/MYNETREXT
 	DEVICE_TITLE := WD My Net Wi-Fi Range Extender
 	DEVICE_PACKAGES := rssileds
diff --git a/target/linux/ar71xx/image/legacy.mk b/target/linux/ar71xx/image/legacy.mk
index c771f89..18eef4d 100644
--- a/target/linux/ar71xx/image/legacy.mk
+++ b/target/linux/ar71xx/image/legacy.mk
@@ -308,10 +308,8 @@ r6100_mtdlayout=mtdparts=ar934x-nfc:128k(u-boot)ro,256k(caldata),256k(caldata-ba
 tew823dru_mtdlayout=mtdparts=spi0.0:192k(u-boot)ro,64k(nvram)ro,15296k(firmware),192k(lang)ro,512k(my-dlink)ro,64k(mac)ro,64k(art)ro
 wndr4300_mtdlayout=mtdparts=ar934x-nfc:256k(u-boot)ro,256k(u-boot-env)ro,256k(caldata),512k(pot),2048k(language),512k(config),3072k(traffic_meter),2048k(kernel),23552k(ubi),25600k at 0x6c0000(firmware),256k(caldata_backup),-(reserved)
 zcn1523h_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,6208k(rootfs),1472k(kernel),64k(configure)ro,64k(mfg)ro,64k(art)ro,7680k at 0x50000(firmware)
-mynet_n600_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,64k(devdata)ro,64k(devconf)ro,15872k(firmware),64k(radiocfg)ro
 mynet_rext_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,7808k(firmware),64k(nvram)ro,64k(ART)ro
 zyx_nbg6716_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(env)ro,64k(RFdata)ro,-(nbu);ar934x-nfc:2048k(zyxel_rfsd),2048k(romd),1024k(header),2048k(kernel),-(ubi)
-qihoo_c301_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env),64k(devdata),64k(devconf),15744k(firmware),64k(warm_start),64k(action_image_config),64k(radiocfg)ro;spi0.1:15360k(upgrade2),1024k(privatedata)
 yun_mtdlayout_8M=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,6464k(rootfs),1280k(kernel),64k(nvram),64k(art),7744k at 0x50000(firmware)
 yun_mtdlayout_16M=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,14656k(rootfs),1280k(kernel),64k(nvram),64k(art),15936k at 0x50000(firmware)
 wrtnode2q_mtdlayout=mtdparts=spi0.0:192k(u-boot),64k(u-boot-env),64k(art),1472k(kernel),14592k(rootfs),16064k at 0x50000(firmware),16384k at 0x0(fullflash)
@@ -655,39 +653,6 @@ define Image/Build/ALFA
 endef
 
 
-Image/Build/Seama/loader=$(call Image/BuildLoader,$(1),bin,$(2) $(3),0x80060000)
-
-define Image/Build/Seama
-	[ -e "$(KDIR)/loader-$(2).bin" ]
-	$(call CompressLzma,$(KDIR)/loader-$(2).bin,$(KDIR_TMP)/loader-$(2).bin.lzma)
-	-rm -f $(KDIR_TMP)/image-$(2).tmp
-	$(call CatFiles,$(KDIR_TMP)/loader-$(2).bin.lzma,$$(($(6) - 64)),$(KDIR)/root.$(1),$(7),$(KDIR_TMP)/image-$(2).tmp)
-	[ -e "$(KDIR_TMP)/image-$(2).tmp" ] && { \
-		head -c -4 "$(KDIR_TMP)/image-$(2).tmp" > "$(KDIR_TMP)/image-$(2).no-jffs2mark.tmp"; \
-		$(STAGING_DIR_HOST)/bin/seama \
-		-i $(KDIR_TMP)/image-$(2).no-jffs2mark.tmp \
-		-m "dev=/dev/mtdblock/1" -m "type=firmware"; \
-		$(STAGING_DIR_HOST)/bin/seama \
-			-s $(call imgname,$(1),$(2))-factory.bin \
-			-m "signature=$(5)" \
-			-i $(KDIR_TMP)/image-$(2).no-jffs2mark.tmp.seama; \
-		tail -c 4 "$(KDIR_TMP)/image-$(2).tmp" >> $(call imgname,$(1),$(2))-factory.bin; \
-	}
-	cat $(KDIR_TMP)/loader-$(2).bin.lzma > $(KDIR_TMP)/image-$(2)-sysupgrade.tmp
-	$(STAGING_DIR_HOST)/bin/seama \
-		-i $(KDIR_TMP)/image-$(2)-sysupgrade.tmp \
-		-m "dev=/dev/mtdblock/1" -m "type=firmware"
-	$(call CatFiles,$(KDIR_TMP)/image-$(2)-sysupgrade.tmp.seama,$(6),$(KDIR)/root.$(1),$(7),$(call sysupname,$(1),$(2)))
-endef
-
-define Image/Build/Seama/initramfs
-	$(call PatchKernelLzma,$(2),$(3) $(4),,-initramfs)
-	$(STAGING_DIR_HOST)/bin/seama \
-		-i $(KDIR_TMP)/vmlinux-initramfs-$(2).bin.lzma \
-		-m "dev=/dev/mtdblock/1" -m "type=firmware"
-	cat $(KDIR_TMP)/vmlinux-initramfs-$(2).bin.lzma.seama > $(call imgname,initramfs,$(2))-seama.bin
-endef
-
 Image/Build/Senao/buildkernel=$(call MkuImageLzma,$(2),$(3) $(4))
 Image/Build/Senao/initramfs=$(call MkuImageLzma/initramfs,$(2),$(3) $(4))
 
@@ -1097,11 +1062,6 @@ $(eval $(call SingleProfile,PB4X,64k,PB44,pb44,PB44,ttyS0,115200))
 $(eval $(call SingleProfile,Planex,64kraw,MZKW04NU,mzk-w04nu,MZK-W04NU,ttyS0,115200))
 $(eval $(call SingleProfile,Planex,64kraw,MZKW300NH,mzk-w300nh,MZK-W300NH,ttyS0,115200))
 
-$(eval $(call SingleProfile,Seama,64k,MYNETN600,mynet-n600,MYNET-N600,ttyS0,115200,$$(mynet_n600_mtdlayout),wrgnd16_wd_db600,65536,16187392))
-$(eval $(call SingleProfile,Seama,64k,MYNETN750,mynet-n750,MYNET-N750,ttyS0,115200,$$(mynet_n600_mtdlayout),wrgnd13_wd_av,65536,16187392))
-
-$(eval $(call SingleProfile,Seama,64k,QIHOO360,qihoo-c301,QIHOO-C301,ttyS0,115200,$$(qihoo_c301_mtdlayout),wrgac26_qihoo360_360rg,65536,16121856))
-
 $(eval $(call SingleProfile,Senao,squashfs-only,EAP300V2,eap300v2,EAP300V2,ttyS0,115200,$$(eap300v2_mtdlayout)))
 
 $(eval $(call SingleProfile,WHRHPG300N,64kraw,WHRG301N,whr-g301n,WHR-G301N,ttyS0,115200,$$(whrhpg300n_mtdlayout),WHR-G301N))
-- 
2.6.4



From ldpinney at gmail.com  Wed Jun 29 19:20:41 2016
From: ldpinney at gmail.com (L. D. Pinney)
Date: Wed, 29 Jun 2016 21:20:41 -0500
Subject: [LEDE-DEV] [PATCH] ramips: Add support for the NixCore X1 Module
Message-ID: <1467253241-11126-1-git-send-email-ldpinney@gmail.com>

The NixCore X1 is a Ralink/MediaTek rt5350 WiFi Module.

http://nixcores.com/

Signed-off-by: L. D. Pinney <ldpinney at gmail.com>
Acked-by: Drew Gaylo <drew at nixcores.com>

---
 target/linux/ramips/base-files/etc/board.d/02_network  |  1 +
 target/linux/ramips/base-files/lib/ramips.sh           |  3 +++
 target/linux/ramips/base-files/lib/upgrade/platform.sh |  1 +
 target/linux/ramips/dts/NIXCORE-16M.dts                | 87 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 target/linux/ramips/dts/NIXCORE-8M.dts                 | 87 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 target/linux/ramips/image/rt305x.mk                    | 13 +++++++++++
 target/linux/ramips/rt305x/profiles/nixcore.mk         | 20 ++++++++++++++++
 7 files changed, 212 insertions(+)

diff --git a/target/linux/ramips/base-files/etc/board.d/02_network b/target/linux/ramips/base-files/etc/board.d/02_network
index dbb5fb4..5063ac8 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -77,6 +77,7 @@ ramips_setup_interfaces()
 	mt7628|\
 	mzk-750dhp|\
 	mzk-w300nh2|\
+	nixcore|\
 	oy-0001|\
 	pbr-m1|\
 	psg1208|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh b/target/linux/ramips/base-files/lib/ramips.sh
index 10139d7..b6ccd5a 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -322,6 +322,9 @@ ramips_board_detect() {
 	*"NCS601W")
 		name="ncs601w"
 		;;
+	*"NixcoreX1")
+		name="nixcore-x1"
+		;;
 	*"NW718")
 		name="nw718"
 		;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index e3bea00..c4d3c01 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -95,6 +95,7 @@ platform_check_image() {
 	mzk-w300nh2|\
 	mzk-wdpr|\
 	nbg-419n|\
+	nixcore|\
 	nw718|\
 	oy-0001|\
 	pbr-m1|\
diff --git a/target/linux/ramips/dts/NIXCORE-16M.dts b/target/linux/ramips/dts/NIXCORE-16M.dts
new file mode 100644
index 0000000..0ee8864
--- /dev/null
+++ b/target/linux/ramips/dts/NIXCORE-16M.dts
@@ -0,0 +1,87 @@
+/dts-v1/;
+
+/include/ "rt5350.dtsi"
+
+/ {
+	compatible = "NixcoreX1", "ralink,rt5350-soc";
+	model = "NixcoreX1";
+
+		chosen {
+				bootargs = "console=ttyS1,57600";
+		};
+
+	palmbus at 10000000 {
+		spi at b00 {
+			status = "okay";
+
+			m25p80 at 0 {
+				#address-cells = <1>;
+				#size-cells = <1>;
+				compatible = "jedec,spi-nor";
+				reg = <0 0>;
+				linux,modalias = "m25p80";
+				spi-max-frequency = <10000000>;
+
+				partition at 0 {
+					label = "u-boot";
+					reg = <0x0 0x30000>;
+					read-only;
+				};
+
+				partition at 30000 {
+					label = "u-boot-env";
+					reg = <0x30000 0x10000>;
+					read-only;
+				};
+
+				factory: partition at 40000 {
+					label = "factory";
+					reg = <0x40000 0x10000>;
+					read-only;
+				};
+
+				partition at 50000 {
+					label = "firmware";
+					reg = <0x50000 0xfb0000>;
+				};
+			};
+		};
+
+		gpio0: gpio at 600 {
+			status = "okay";
+		};
+
+		gpio1: gpio at 660 {
+			status = "okay";
+		};
+	};
+
+	pinctrl {
+		state_default: pinctrl0 {
+			gpio {
+				ralink,group = "i2c", "jtag", "led", "uartf";
+				ralink,function = "gpio";
+			};
+		};
+	};
+
+	ethernet at 10100000 {
+		mtd-mac-address = <&factory 0x4>;
+	};
+
+	esw at 10110000 {
+		mediatek,portmap = <0x2f>;
+	};
+
+	wmac at 10180000 {
+		ralink,mtd-eeprom = <&factory 0>;
+	};
+
+	ehci at 101c0000 {
+		status = "okay";
+	};
+
+	ohci at 101c1000 {
+		status = "okay";
+	};
+};
diff --git a/target/linux/ramips/dts/NIXCORE-8M.dts b/target/linux/ramips/dts/NIXCORE-8M.dts
new file mode 100644
index 0000000..a80d7fb
--- /dev/null
+++ b/target/linux/ramips/dts/NIXCORE-8M.dts
@@ -0,0 +1,87 @@
+/dts-v1/;
+
+/include/ "rt5350.dtsi"
+
+/ {
+	compatible = "NixcoreX1", "ralink,rt5350-soc";
+	model = "NixcoreX1";
+
+		chosen {
+				bootargs = "console=ttyS1,57600";
+	};
+
+	palmbus at 10000000 {
+		spi at b00 {
+			status = "okay";
+
+			m25p80 at 0 {
+				#address-cells = <1>;
+				#size-cells = <1>;
+				compatible = "jedec,spi-nor";
+				reg = <0 0>;
+				linux,modalias = "m25p80";
+				spi-max-frequency = <10000000>;
+
+				partition at 0 {
+					label = "u-boot";
+					reg = <0x0 0x30000>;
+					read-only;
+				};
+
+				partition at 30000 {
+					label = "u-boot-env";
+					reg = <0x30000 0x10000>;
+					read-only;
+				};
+
+				factory: partition at 40000 {
+					label = "factory";
+					reg = <0x40000 0x10000>;
+					read-only;
+				};
+
+				partition at 50000 {
+					label = "firmware";
+					reg = <0x50000 0x7b0000>;
+				};
+			};
+		};
+
+		gpio0: gpio at 600 {
+			status = "okay";
+		};
+
+		gpio1: gpio at 660 {
+			status = "okay";
+		};
+	};
+
+	pinctrl {
+		state_default: pinctrl0 {
+			gpio {
+				ralink,group = "i2c", "jtag", "led", "uartf";
+				ralink,function = "gpio";
+			};
+		};
+	};
+
+	ethernet at 10100000 {
+		mtd-mac-address = <&factory 0x4>;
+	};
+
+	esw at 10110000 {
+		mediatek,portmap = <0x2f>;
+	};
+
+	wmac at 10180000 {
+		ralink,mtd-eeprom = <&factory 0>;
+	};
+
+	ehci at 101c0000 {
+		status = "okay";
+	};
+
+	ohci at 101c1000 {
+		status = "okay";
+	};
+};
diff --git a/target/linux/ramips/image/rt305x.mk b/target/linux/ramips/image/rt305x.mk
index da7fc46..6861ef3 100644
--- a/target/linux/ramips/image/rt305x.mk
+++ b/target/linux/ramips/image/rt305x.mk
@@ -100,6 +100,17 @@ define BuildFirmware/HLKRM04/initramfs
 	mkhilinkfw -e -i$(call imgname,$(1),$(2))-uImage.bin -o $(call imgname,$(1),$(2))-factory.bin;
 endef
 
+nixcore_8mb_mtd_size=8060928
+nixcore_16mb_mtd_size=16449536
+define BuildFirmware/NIXCORE/squashfs
+	$(call BuildFirmware/CustomFlash/$(1),$(1),$(2)-8M,$(3)-8M,$(nixcore_8mb_mtd_size))
+	$(call BuildFirmware/CustomFlash/$(1),$(1),$(2)-16M,$(3)-16M,$(nixcore_16mb_mtd_size))
+endef
+define BuildFirmware/NIXCORE/initramfs
+	$(call BuildFirmware/OF/initramfs,$(1),$(2)-8M,$(3)-8M)
+	$(call BuildFirmware/OF/initramfs,$(1),$(2)-16M,$(3)-16M)
+endef
+
 vocore_8mb_mtd_size=8060928
 vocore_16mb_mtd_size=16449536
 define BuildFirmware/VOCORE/squashfs
@@ -258,6 +269,7 @@ Image/Build/Profile/MZKW300NH2=$(call BuildFirmware/Edimax/$(1),$(1),mzk-w300nh2
 Image/Build/Profile/MZKWDPR=$(call BuildFirmware/Default8M/$(1),$(1),mzk-wdpr,MZK-WDPR)
 Image/Build/Profile/NCS601W=$(call BuildFirmware/Default8M/$(1),$(1),ncs601W,NCS601W)
 nw718_mtd_size=3801088
+Image/Build/Profile/NIXCORE=$(call BuildFirmware/NIXCORE/$(1),$(1),nixcore,NIXCORE)
 Image/Build/Profile/NW718=$(call BuildFirmware/CustomFlashFactory/$(1),$(1),nw718m,NW718,$(nw718_mtd_size),ARA1B4NCRNW718;1,factory)
 Image/Build/Profile/M2M=$(call BuildFirmware/Default8M/$(1),$(1),m2m,M2M,Linux Kernel Image)
 Image/Build/Profile/MINIEMBPLUG=$(call BuildFirmware/Default8M/$(1),$(1),miniembplug,MINIEMBPLUG)
@@ -353,6 +365,7 @@ define Image/Build/Profile/Default
 	$(call Image/Build/Profile/MZKWDPR,$(1))
 	$(call Image/Build/Profile/NBG-419N,$(1))
 	$(call Image/Build/Profile/NCS601W,$(1))
+	$(call Image/Build/Profile/NIXCORE,$(1))
 	$(call Image/Build/Profile/NW718,$(1))
 	$(call Image/Build/Profile/MINIEMBWIFI,$(1))
 	$(call Image/Build/Profile/MINIEMBPLUG,$(1))
diff --git a/target/linux/ramips/rt305x/profiles/nixcore.mk b/target/linux/ramips/rt305x/profiles/nixcore.mk
new file mode 100644
index 0000000..475053c
--- /dev/null
+++ b/target/linux/ramips/rt305x/profiles/nixcore.mk
@@ -0,0 +1,20 @@
+#
+# Copyright (C) 2016 lede-project.org
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+
+define Profile/NIXCORE
+    NAME:=NixcoreX1
+    PACKAGES:=\
+        kmod-usb-core kmod-usb-ohci kmod-usb2 \
+        kmod-i2c-core kmod-i2c-ralink \
+        kmod-spi-dev
+endef
+
+define Profile/NIXCORE/Description
+    Package set for Nixcore X1 board
+endef
+
+$(eval $(call Profile,NIXCORE))


From zajec5 at gmail.com  Wed Jun 29 22:26:35 2016
From: zajec5 at gmail.com (=?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?=)
Date: Thu, 30 Jun 2016 07:26:35 +0200
Subject: [LEDE-DEV] adding luci to snapshot images
In-Reply-To: <351faca4-edfa-c301-876f-afa9a06ba675@mein.io>
References: <83d8c156-1a53-e391-fb3e-2460d16ed20e@phrozen.org>
 <351faca4-edfa-c301-876f-afa9a06ba675@mein.io>
Message-ID: <CACna6rxy5CmW+iC00Jq+zLfp9qnDihajXk1JZA7jaQPD1_Vksw@mail.gmail.com>

On 29 June 2016 at 16:54, Jo-Philipp Wich <jo at mein.io> wrote:
> My observation on the matter is this:
> People who do *not* want to have the ui included are either building
> from source or using the IB anyway and those users *requiring* a ui tend
> to be unable to spin their own builds (no Linux os at hand, too hard, ...)

A great summary. I agree and like John's idea.


From john at phrozen.org  Wed Jun 29 22:42:52 2016
From: john at phrozen.org (John Crispin)
Date: Thu, 30 Jun 2016 07:42:52 +0200
Subject: [LEDE-DEV] [PATCH] ramips: Add support for the NixCore X1 Module
In-Reply-To: <1467253241-11126-1-git-send-email-ldpinney@gmail.com>
References: <1467253241-11126-1-git-send-email-ldpinney@gmail.com>
Message-ID: <f3d78e5f-7675-6a6f-eb5b-14add23353cc@phrozen.org>



On 30/06/2016 04:20, L. D. Pinney wrote:
> The NixCore X1 is a Ralink/MediaTek rt5350 WiFi Module.
> 
> http://nixcores.com/
> 
> Signed-off-by: L. D. Pinney <ldpinney at gmail.com>
> Acked-by: Drew Gaylo <drew at nixcores.com>
> 

this is a different patch to drew's version 5. please incorporate all
the feedback we already gave to drew.

	John

> ---
>  target/linux/ramips/base-files/etc/board.d/02_network  |  1 +
>  target/linux/ramips/base-files/lib/ramips.sh           |  3 +++
>  target/linux/ramips/base-files/lib/upgrade/platform.sh |  1 +
>  target/linux/ramips/dts/NIXCORE-16M.dts                | 87 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  target/linux/ramips/dts/NIXCORE-8M.dts                 | 87 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  target/linux/ramips/image/rt305x.mk                    | 13 +++++++++++
>  target/linux/ramips/rt305x/profiles/nixcore.mk         | 20 ++++++++++++++++
>  7 files changed, 212 insertions(+)
> 
> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network b/target/linux/ramips/base-files/etc/board.d/02_network
> index dbb5fb4..5063ac8 100755
> --- a/target/linux/ramips/base-files/etc/board.d/02_network
> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
> @@ -77,6 +77,7 @@ ramips_setup_interfaces()
>  	mt7628|\
>  	mzk-750dhp|\
>  	mzk-w300nh2|\
> +	nixcore|\
>  	oy-0001|\
>  	pbr-m1|\
>  	psg1208|\
> diff --git a/target/linux/ramips/base-files/lib/ramips.sh b/target/linux/ramips/base-files/lib/ramips.sh
> index 10139d7..b6ccd5a 100755
> --- a/target/linux/ramips/base-files/lib/ramips.sh
> +++ b/target/linux/ramips/base-files/lib/ramips.sh
> @@ -322,6 +322,9 @@ ramips_board_detect() {
>  	*"NCS601W")
>  		name="ncs601w"
>  		;;
> +	*"NixcoreX1")
> +		name="nixcore-x1"
> +		;;
>  	*"NW718")
>  		name="nw718"
>  		;;
> diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh b/target/linux/ramips/base-files/lib/upgrade/platform.sh
> index e3bea00..c4d3c01 100755
> --- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
> @@ -95,6 +95,7 @@ platform_check_image() {
>  	mzk-w300nh2|\
>  	mzk-wdpr|\
>  	nbg-419n|\
> +	nixcore|\
>  	nw718|\
>  	oy-0001|\
>  	pbr-m1|\
> diff --git a/target/linux/ramips/dts/NIXCORE-16M.dts b/target/linux/ramips/dts/NIXCORE-16M.dts
> new file mode 100644
> index 0000000..0ee8864
> --- /dev/null
> +++ b/target/linux/ramips/dts/NIXCORE-16M.dts
> @@ -0,0 +1,87 @@
> +/dts-v1/;
> +
> +/include/ "rt5350.dtsi"
> +
> +/ {
> +	compatible = "NixcoreX1", "ralink,rt5350-soc";
> +	model = "NixcoreX1";
> +
> +		chosen {
> +				bootargs = "console=ttyS1,57600";
> +		};
> +
> +	palmbus at 10000000 {
> +		spi at b00 {
> +			status = "okay";
> +
> +			m25p80 at 0 {
> +				#address-cells = <1>;
> +				#size-cells = <1>;
> +				compatible = "jedec,spi-nor";
> +				reg = <0 0>;
> +				linux,modalias = "m25p80";
> +				spi-max-frequency = <10000000>;
> +
> +				partition at 0 {
> +					label = "u-boot";
> +					reg = <0x0 0x30000>;
> +					read-only;
> +				};
> +
> +				partition at 30000 {
> +					label = "u-boot-env";
> +					reg = <0x30000 0x10000>;
> +					read-only;
> +				};
> +
> +				factory: partition at 40000 {
> +					label = "factory";
> +					reg = <0x40000 0x10000>;
> +					read-only;
> +				};
> +
> +				partition at 50000 {
> +					label = "firmware";
> +					reg = <0x50000 0xfb0000>;
> +				};
> +			};
> +		};
> +
> +		gpio0: gpio at 600 {
> +			status = "okay";
> +		};
> +
> +		gpio1: gpio at 660 {
> +			status = "okay";
> +		};
> +	};
> +
> +	pinctrl {
> +		state_default: pinctrl0 {
> +			gpio {
> +				ralink,group = "i2c", "jtag", "led", "uartf";
> +				ralink,function = "gpio";
> +			};
> +		};
> +	};
> +
> +	ethernet at 10100000 {
> +		mtd-mac-address = <&factory 0x4>;
> +	};
> +
> +	esw at 10110000 {
> +		mediatek,portmap = <0x2f>;
> +	};
> +
> +	wmac at 10180000 {
> +		ralink,mtd-eeprom = <&factory 0>;
> +	};
> +
> +	ehci at 101c0000 {
> +		status = "okay";
> +	};
> +
> +	ohci at 101c1000 {
> +		status = "okay";
> +	};
> +};
> diff --git a/target/linux/ramips/dts/NIXCORE-8M.dts b/target/linux/ramips/dts/NIXCORE-8M.dts
> new file mode 100644
> index 0000000..a80d7fb
> --- /dev/null
> +++ b/target/linux/ramips/dts/NIXCORE-8M.dts
> @@ -0,0 +1,87 @@
> +/dts-v1/;
> +
> +/include/ "rt5350.dtsi"
> +
> +/ {
> +	compatible = "NixcoreX1", "ralink,rt5350-soc";
> +	model = "NixcoreX1";
> +
> +		chosen {
> +				bootargs = "console=ttyS1,57600";
> +	};
> +
> +	palmbus at 10000000 {
> +		spi at b00 {
> +			status = "okay";
> +
> +			m25p80 at 0 {
> +				#address-cells = <1>;
> +				#size-cells = <1>;
> +				compatible = "jedec,spi-nor";
> +				reg = <0 0>;
> +				linux,modalias = "m25p80";
> +				spi-max-frequency = <10000000>;
> +
> +				partition at 0 {
> +					label = "u-boot";
> +					reg = <0x0 0x30000>;
> +					read-only;
> +				};
> +
> +				partition at 30000 {
> +					label = "u-boot-env";
> +					reg = <0x30000 0x10000>;
> +					read-only;
> +				};
> +
> +				factory: partition at 40000 {
> +					label = "factory";
> +					reg = <0x40000 0x10000>;
> +					read-only;
> +				};
> +
> +				partition at 50000 {
> +					label = "firmware";
> +					reg = <0x50000 0x7b0000>;
> +				};
> +			};
> +		};
> +
> +		gpio0: gpio at 600 {
> +			status = "okay";
> +		};
> +
> +		gpio1: gpio at 660 {
> +			status = "okay";
> +		};
> +	};
> +
> +	pinctrl {
> +		state_default: pinctrl0 {
> +			gpio {
> +				ralink,group = "i2c", "jtag", "led", "uartf";
> +				ralink,function = "gpio";
> +			};
> +		};
> +	};
> +
> +	ethernet at 10100000 {
> +		mtd-mac-address = <&factory 0x4>;
> +	};
> +
> +	esw at 10110000 {
> +		mediatek,portmap = <0x2f>;
> +	};
> +
> +	wmac at 10180000 {
> +		ralink,mtd-eeprom = <&factory 0>;
> +	};
> +
> +	ehci at 101c0000 {
> +		status = "okay";
> +	};
> +
> +	ohci at 101c1000 {
> +		status = "okay";
> +	};
> +};
> diff --git a/target/linux/ramips/image/rt305x.mk b/target/linux/ramips/image/rt305x.mk
> index da7fc46..6861ef3 100644
> --- a/target/linux/ramips/image/rt305x.mk
> +++ b/target/linux/ramips/image/rt305x.mk
> @@ -100,6 +100,17 @@ define BuildFirmware/HLKRM04/initramfs
>  	mkhilinkfw -e -i$(call imgname,$(1),$(2))-uImage.bin -o $(call imgname,$(1),$(2))-factory.bin;
>  endef
>  
> +nixcore_8mb_mtd_size=8060928
> +nixcore_16mb_mtd_size=16449536
> +define BuildFirmware/NIXCORE/squashfs
> +	$(call BuildFirmware/CustomFlash/$(1),$(1),$(2)-8M,$(3)-8M,$(nixcore_8mb_mtd_size))
> +	$(call BuildFirmware/CustomFlash/$(1),$(1),$(2)-16M,$(3)-16M,$(nixcore_16mb_mtd_size))
> +endef
> +define BuildFirmware/NIXCORE/initramfs
> +	$(call BuildFirmware/OF/initramfs,$(1),$(2)-8M,$(3)-8M)
> +	$(call BuildFirmware/OF/initramfs,$(1),$(2)-16M,$(3)-16M)
> +endef
> +
>  vocore_8mb_mtd_size=8060928
>  vocore_16mb_mtd_size=16449536
>  define BuildFirmware/VOCORE/squashfs
> @@ -258,6 +269,7 @@ Image/Build/Profile/MZKW300NH2=$(call BuildFirmware/Edimax/$(1),$(1),mzk-w300nh2
>  Image/Build/Profile/MZKWDPR=$(call BuildFirmware/Default8M/$(1),$(1),mzk-wdpr,MZK-WDPR)
>  Image/Build/Profile/NCS601W=$(call BuildFirmware/Default8M/$(1),$(1),ncs601W,NCS601W)
>  nw718_mtd_size=3801088
> +Image/Build/Profile/NIXCORE=$(call BuildFirmware/NIXCORE/$(1),$(1),nixcore,NIXCORE)
>  Image/Build/Profile/NW718=$(call BuildFirmware/CustomFlashFactory/$(1),$(1),nw718m,NW718,$(nw718_mtd_size),ARA1B4NCRNW718;1,factory)
>  Image/Build/Profile/M2M=$(call BuildFirmware/Default8M/$(1),$(1),m2m,M2M,Linux Kernel Image)
>  Image/Build/Profile/MINIEMBPLUG=$(call BuildFirmware/Default8M/$(1),$(1),miniembplug,MINIEMBPLUG)
> @@ -353,6 +365,7 @@ define Image/Build/Profile/Default
>  	$(call Image/Build/Profile/MZKWDPR,$(1))
>  	$(call Image/Build/Profile/NBG-419N,$(1))
>  	$(call Image/Build/Profile/NCS601W,$(1))
> +	$(call Image/Build/Profile/NIXCORE,$(1))
>  	$(call Image/Build/Profile/NW718,$(1))
>  	$(call Image/Build/Profile/MINIEMBWIFI,$(1))
>  	$(call Image/Build/Profile/MINIEMBPLUG,$(1))
> diff --git a/target/linux/ramips/rt305x/profiles/nixcore.mk b/target/linux/ramips/rt305x/profiles/nixcore.mk
> new file mode 100644
> index 0000000..475053c
> --- /dev/null
> +++ b/target/linux/ramips/rt305x/profiles/nixcore.mk
> @@ -0,0 +1,20 @@
> +#
> +# Copyright (C) 2016 lede-project.org
> +#
> +# This is free software, licensed under the GNU General Public License v2.
> +# See /LICENSE for more information.
> +#
> +
> +define Profile/NIXCORE
> +    NAME:=NixcoreX1
> +    PACKAGES:=\
> +        kmod-usb-core kmod-usb-ohci kmod-usb2 \
> +        kmod-i2c-core kmod-i2c-ralink \
> +        kmod-spi-dev
> +endef
> +
> +define Profile/NIXCORE/Description
> +    Package set for Nixcore X1 board
> +endef
> +
> +$(eval $(call Profile,NIXCORE))
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 


From john at phrozen.org  Wed Jun 29 22:44:56 2016
From: john at phrozen.org (John Crispin)
Date: Thu, 30 Jun 2016 07:44:56 +0200
Subject: [LEDE-DEV] [PATCH] e2fsprogs: fix build problem with very old
 libmagic
In-Reply-To: <1467234876-27902-1-git-send-email-hauke@hauke-m.de>
References: <1467234876-27902-1-git-send-email-hauke@hauke-m.de>
Message-ID: <884e4ff4-956d-3eff-8bbd-fec99c6a6a5d@phrozen.org>



On 29/06/2016 23:14, Hauke Mehrtens wrote:
> From: Hauke Mehrtens <hauke.mehrtens at intel.com>
> 
> The libmagic shipped with RedHat 5 does not define
> MAGIC_NO_CHECK_COMPRESS and MAGIC_NO_CHECK_COMPRESS. e2fsprogs should
> check for that otherwise the build will fail.
> 

can you send this upstream aswell please ?

	John

> Signed-off-by: Hauke Mehrtens <hauke.mehrtens at intel.com>
> ---
>  tools/e2fsprogs/patches/010-old-libmagic.patch | 11 +++++++++++
>  1 file changed, 11 insertions(+)
>  create mode 100644 tools/e2fsprogs/patches/010-old-libmagic.patch
> 
> diff --git a/tools/e2fsprogs/patches/010-old-libmagic.patch b/tools/e2fsprogs/patches/010-old-libmagic.patch
> new file mode 100644
> index 0000000..5ba8a54
> --- /dev/null
> +++ b/tools/e2fsprogs/patches/010-old-libmagic.patch
> @@ -0,0 +1,11 @@
> +--- a/lib/support/plausible.c
> ++++ b/lib/support/plausible.c
> +@@ -247,7 +247,7 @@ int check_plausibility(const char *devic
> + 		return 0;
> + 	}
> + 
> +-#ifdef HAVE_MAGIC_H
> ++#if defined(HAVE_MAGIC_H) && defined(MAGIC_NO_CHECK_COMPRESS) && defined(MAGIC_NO_CHECK_COMPRESS)
> + 	if ((flags & CHECK_FS_EXIST) &&
> + 	    !getenv("E2FSPROGS_LIBMAGIC_SUPPRESS") &&
> + 	    magic_library_available()) {
> 


From dirkneukirchen at web.de  Wed Jun 29 23:15:40 2016
From: dirkneukirchen at web.de (Dirk Neukirchen)
Date: Thu, 30 Jun 2016 08:15:40 +0200
Subject: [LEDE-DEV] [PATCH] e2fsprogs: fix build problem with very old
 libmagic
In-Reply-To: <1467234876-27902-1-git-send-email-hauke@hauke-m.de>
References: <1467234876-27902-1-git-send-email-hauke@hauke-m.de>
Message-ID: <c54ecc61-ea9e-efec-76c4-8c13164f5119@web.de>

On 29.06.2016 23:14, Hauke Mehrtens wrote:
> From: Hauke Mehrtens <hauke.mehrtens at intel.com>
> 
> The libmagic shipped with RedHat 5 does not define

As a reference - RHEL4: Mar/2017, RHEL5:Nov/2020 
src: https://access.redhat.com/support/policy/updates/errata

I have recommended/tested build OS on my todo list 


> MAGIC_NO_CHECK_COMPRESS and MAGIC_NO_CHECK_COMPRESS.

c/p error ?

e2fsprogs should
> check for that otherwise the build will fail.
> 
> Signed-off-by: Hauke Mehrtens <hauke.mehrtens at intel.com>
> ---
>  tools/e2fsprogs/patches/010-old-libmagic.patch | 11 +++++++++++
>  1 file changed, 11 insertions(+)
>  create mode 100644 tools/e2fsprogs/patches/010-old-libmagic.patch
> 
> diff --git a/tools/e2fsprogs/patches/010-old-libmagic.patch b/tools/e2fsprogs/patches/010-old-libmagic.patch
> new file mode 100644
> index 0000000..5ba8a54
> --- /dev/null
> +++ b/tools/e2fsprogs/patches/010-old-libmagic.patch
> @@ -0,0 +1,11 @@
> +--- a/lib/support/plausible.c
> ++++ b/lib/support/plausible.c
> +@@ -247,7 +247,7 @@ int check_plausibility(const char *devic
> + 		return 0;
> + 	}
> + 
> +-#ifdef HAVE_MAGIC_H
> ++#if defined(HAVE_MAGIC_H) && defined(MAGIC_NO_CHECK_COMPRESS) && defined(MAGIC_NO_CHECK_COMPRESS)

c/p error ?

> + 	if ((flags & CHECK_FS_EXIST) &&
> + 	    !getenv("E2FSPROGS_LIBMAGIC_SUPPRESS") &&
> + 	    magic_library_available()) {
> 



From john at phrozen.org  Thu Jun 30 00:21:58 2016
From: john at phrozen.org (John Crispin)
Date: Thu, 30 Jun 2016 09:21:58 +0200
Subject: [LEDE-DEV] fstools testing help
Message-ID: <86b938e4-3209-7123-9f4f-a7890d7312e0@phrozen.org>

Hi,

i have just merged to fstools patches into my staging tree that address
a double mount issue and add back ext4 support. the ext4 patch
previously broke rPi and other ext4 targets, but i thini with josua's
patch applied it should work. i have done some basic testing already my
end but would like further etst coverage to make sure there are no
hidden regressions

things that should be tested are

* does ext4 mount work on eMMC
* does rootfs mount work on rPi
* does extroot still work with flat mounts
* does extroot still work with flat overlay mounts

i have only tested the last one so far.

	John


From noltari at gmail.com  Thu Jun 30 00:23:18 2016
From: noltari at gmail.com (=?UTF-8?Q?=c3=81lvaro_Fern=c3=a1ndez_Rojas?=)
Date: Thu, 30 Jun 2016 09:23:18 +0200
Subject: [LEDE-DEV] fstools testing help
In-Reply-To: <86b938e4-3209-7123-9f4f-a7890d7312e0@phrozen.org>
References: <86b938e4-3209-7123-9f4f-a7890d7312e0@phrozen.org>
Message-ID: <5774C8E6.80504@gmail.com>

I will try to test it on RPi tonight.

Regards,
?lvaro.

El 30/6/16 a las 9:21, John Crispin escribi?:
> Hi,
> 
> i have just merged to fstools patches into my staging tree that address
> a double mount issue and add back ext4 support. the ext4 patch
> previously broke rPi and other ext4 targets, but i thini with josua's
> patch applied it should work. i have done some basic testing already my
> end but would like further etst coverage to make sure there are no
> hidden regressions
> 
> things that should be tested are
> 
> * does ext4 mount work on eMMC
> * does rootfs mount work on rPi
> * does extroot still work with flat mounts
> * does extroot still work with flat overlay mounts
> 
> i have only tested the last one so far.
> 
> 	John
> 


From Alexey.Brodkin at synopsys.com  Thu Jun 30 00:37:36 2016
From: Alexey.Brodkin at synopsys.com (Alexey Brodkin)
Date: Thu, 30 Jun 2016 07:37:36 +0000
Subject: [LEDE-DEV] Add Synopsys brand to Wiki
In-Reply-To: <000a01d1d238$07ad6260$17082720$@de>
References: +ADw-1467018805.3628.36.camel+AEA-synopsys.com+AD4-
 +ADw-46d96e6c-61dc-f28c-8ac9-8db99292c334+AEA-mein.io+AD4-
 +ADw-1467220619.26022.37.camel+AEA-synopsys.com+AD4-
 <000a01d1d238$07ad6260$17082720$@de>
Message-ID: <1467272189.26022.67.camel@synopsys.com>

Hi Thomas,

Thanks for that.

Now looks like "target" has to be added as well.

I'll need 2 targets:
?1) arc770
?2) archs38

Thanks in advance,
Alexey

On Wed, 2016-06-29 at 20:57 +0200, Thomas Endt wrote:
> Done.
> 
> Regards, Thomas
> 
> > 
> > -----Urspr?ngliche Nachricht-----
> > Von: Alexey Brodkin [mailto:Alexey.Brodkin at synopsys.com]
> > Gesendet: Mittwoch, 29. Juni 2016 19:18
> > An: tmo at gmx.de
> > Cc: lede-dev at lists.infradead.org; jo at mein.io
> > Betreff: Re: Add Synopsys brand to Wiki
> > 
> > Hi Thomas,
> > 
> > Could you please assist me in adding new brand (Synopsys) to OpenWRT
> > Wiki ToH?
> > 
> > That's my original request sent to Lede dev mailing list:
> > http://lists.infradead.org/pipermail/lede-dev/2016-June/001551.html
> > 
> > -Alexey
> > 
> > On Wed, 2016-06-29 at 15:42 +0200, Jo-Philipp Wich wrote:
> > > 
> > > Hi Alexey,
> > > 
> > > please contact Thomas Endt <tmo -at- gmx.de> for assistance on adding
> > > brands to the OpenWrt Wiki ToH.
> > > 
> > > ~ Jo=

From john at phrozen.org  Thu Jun 30 02:16:39 2016
From: john at phrozen.org (John Crispin)
Date: Thu, 30 Jun 2016 11:16:39 +0200
Subject: [LEDE-DEV] adding luci to snapshot images
In-Reply-To: <351faca4-edfa-c301-876f-afa9a06ba675@mein.io>
References: <83d8c156-1a53-e391-fb3e-2460d16ed20e@phrozen.org>
 <351faca4-edfa-c301-876f-afa9a06ba675@mein.io>
Message-ID: <08e6af78-d91c-c617-3ddc-8d76d26c6cdc@phrozen.org>



On 29/06/2016 16:54, Jo-Philipp Wich wrote:
> Hi,
> 
> it would certainly help to bridge the gap until the #1 release and it
> would give more testing exposure to the ui...
> 
> My observation on the matter is this:
> People who do *not* want to have the ui included are either building
> from source or using the IB anyway and those users *requiring* a ui tend
> to be unable to spin their own builds (no Linux os at hand, too hard, ...)
> 
> So personally I'd lean toward adding LuCI to the snapshots but would
> await further feedback on it.
> 
> ~ Jo
> 

Hi Jo,

if you add this then please make it depend on !SMALL_FLASH

	John


From john at klam.ca  Thu Jun 30 04:57:52 2016
From: john at klam.ca (John Allen)
Date: Thu, 30 Jun 2016 07:57:52 -0400
Subject: [LEDE-DEV] Adding luci to build
Message-ID: <155a12c2200.2784.14d9188d684ea7b6d1324cf92af46b48@klam.ca>

I am a user and do not have the resources to build my own and while I don't 
mind running opkg to install luci etc., it would nice to have it preinstalled
+1 for luci.
+1 for material theme.

_______________________
Sent from my Galaxy S3





From eduardo.abinader at riverbed.com  Thu Jun 30 07:18:12 2016
From: eduardo.abinader at riverbed.com (Eduardo Abinader)
Date: Thu, 30 Jun 2016 16:18:12 +0200
Subject: [LEDE-DEV] [PATCH] netifd: remove wireless device when device fails
	to setup
Message-ID: <57752A24.7020905@riverbed.com>

Ensure wireless device struct is removed, when it fails to be set up,
due to a invalid configuration, hence enabling the wireless dev
to be set up again, when a new valid configuration is set.

Signed-off-by: Eduardo Abinader <eduardo.abinader at riverbed.com>
---
 wireless.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/wireless.c b/wireless.c
index 34dd328..bc31d4a 100644
--- a/wireless.c
+++ b/wireless.c
@@ -336,6 +336,10 @@ wireless_device_mark_down(struct wireless_device *wdev)
 
 	wireless_process_kill_all(wdev, SIGTERM, true);
 
+	if (wdev->state == IFS_SETUP && !wdev->autostart) {
+		wdev->config_state = IFC_REMOVE;
+	}
+
 	wdev->cancel = false;
 	wdev->state = IFS_DOWN;
 	wireless_device_free_state(wdev);
-- 
2.5.0


From eduardo.abinader at riverbed.com  Thu Jun 30 07:26:00 2016
From: eduardo.abinader at riverbed.com (Eduardo Abinader)
Date: Thu, 30 Jun 2016 16:26:00 +0200
Subject: [LEDE-DEV] [PATCH] netifd: remove wireless device when device fails
	to setup
Message-ID: <57752BF8.9090405@riverbed.com>

Ensure wireless device struct is removed, when it fails to be set up,
due to a invalid configuration, hence enabling the wireless dev
to be set up again, when a new valid configuration is set.

Signed-off-by: Eduardo Abinader <eduardo.abinader at riverbed.com>
---
 wireless.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/wireless.c b/wireless.c
index 34dd328..bc31d4a 100644
--- a/wireless.c
+++ b/wireless.c
@@ -336,6 +336,10 @@ wireless_device_mark_down(struct wireless_device *wdev)
 
 	wireless_process_kill_all(wdev, SIGTERM, true);
 
+	if (wdev->state == IFS_SETUP && !wdev->autostart) {
+		wdev->config_state = IFC_REMOVE;
+	}
+
 	wdev->cancel = false;
 	wdev->state = IFS_DOWN;
 	wireless_device_free_state(wdev);
-- 
2.5.0


From dennisschneck at web.de  Thu Jun 30 07:34:18 2016
From: dennisschneck at web.de (Dennis Schneck)
Date: Thu, 30 Jun 2016 16:34:18 +0200
Subject: [LEDE-DEV] Need /dev/mtd4 from TPLink TL-WR941ND v6
Message-ID: <trinity-3da4d021-849f-4ac4-8862-b9dfbc74a8de-1467297258100@3capp-webde-bs04>



Hello,
anybody how has a TPLink TL-WR941ND Ver. 6.0.
Can you please export with dd the Partition: /dev/mtd4 an offer me a Download ?
Thanks
Dennis
?


From jo at mein.io  Thu Jun 30 08:03:45 2016
From: jo at mein.io (Jo-Philipp Wich)
Date: Thu, 30 Jun 2016 17:03:45 +0200
Subject: [LEDE-DEV] [PATCH libubox v3] blobmsg_json: add new functions
 blobmsg_format_json_value*
In-Reply-To: <e2baf50085bb8d6b7e8285847c2689541eb1cc44.1467010122.git.mschiffer@universe-factory.net>
References: <e2baf50085bb8d6b7e8285847c2689541eb1cc44.1467010122.git.mschiffer@universe-factory.net>
Message-ID: <9c625092-1e69-cbef-e837-fa301a4dc8ad@mein.io>

On 06/27/2016 08:50 AM, Matthias Schiffer wrote:
> The current blobmsg_format_json* functions will return invalid JSON when
> the "list" argument is given as false (blobmsg_format_element() will
> output the name of the blob_attr as if the value is printed as part of a
> JSON object).
> 
> To avoid breaking software relying on this behaviour, introduce new
> functions which will never print the blob_attr name and thus always
> produce valid JSON.
> 
> Signed-off-by: Matthias Schiffer <mschiffer at universe-factory.net>

Acked-by: Jo-Philipp Wich <jo at mein.io>


From daniel at dd-wrt.com  Thu Jun 30 08:05:35 2016
From: daniel at dd-wrt.com (Daniel Danzberger)
Date: Thu, 30 Jun 2016 17:05:35 +0200
Subject: [LEDE-DEV] [PATCH] Bridge: Fix ipv6 mc snooping if bridge has no
	ipv6 address
Message-ID: <1467299135-1061-1-git-send-email-daniel@dd-wrt.com>

This patch is a backport for current LEDE 4.4 Kernels.
It is already upstream, for linux-next and stable.
The initial commit message is below:

The bridge is falsly dropping ipv6 mulitcast packets if there is:
 1. No ipv6 address assigned on the brigde.
 2. No external mld querier present.
 3. The internal querier enabled.

When the bridge fails to build mld queries, because it has no
ipv6 address, it slilently returns, but keeps the local querier enabled.
This specific case causes confusing packet loss.

Ipv6 multicast snooping can only work if:
 a) An external querier is present
 OR
 b) The bridge has an ipv6 address an is capable of sending own queries

Otherwise it has to forward/flood the ipv6 multicast traffic,
because snooping cannot work.

This patch fixes the issue by adding a flag to the bridge struct that
indicates that there is currently no ipv6 address assinged to the bridge
and returns a false state for the local querier in
__br_multicast_querier_exists().

Special thanks to Linus L?ssing.

Signed-off-by: Daniel Danzberger <daniel at dd-wrt.com>
---
 ...mc_snooping_if_bridge_has_no_ipv6_address.patch | 76 ++++++++++++++++++++++
 1 file changed, 76 insertions(+)
 create mode 100644 target/linux/generic/patches-4.4/646-bridge_fix_ipv6_mc_snooping_if_bridge_has_no_ipv6_address.patch

diff --git a/target/linux/generic/patches-4.4/646-bridge_fix_ipv6_mc_snooping_if_bridge_has_no_ipv6_address.patch b/target/linux/generic/patches-4.4/646-bridge_fix_ipv6_mc_snooping_if_bridge_has_no_ipv6_address.patch
new file mode 100644
index 0000000..e0bdbae
--- /dev/null
+++ b/target/linux/generic/patches-4.4/646-bridge_fix_ipv6_mc_snooping_if_bridge_has_no_ipv6_address.patch
@@ -0,0 +1,76 @@
+diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
+index c8c2a8a..d063a10 100644
+--- a/net/bridge/br_multicast.c
++++ b/net/bridge/br_multicast.c
+@@ -465,8 +465,11 @@ static struct sk_buff *br_ip6_multicast_alloc_query(struct net_bridge *br,
+ 	if (ipv6_dev_get_saddr(dev_net(br->dev), br->dev, &ip6h->daddr, 0,
+ 			       &ip6h->saddr)) {
+ 		kfree_skb(skb);
++		br->has_ipv6_addr = 0;
+ 		return NULL;
+ 	}
++
++	br->has_ipv6_addr = 1;
+ 	ipv6_eth_mc_map(&ip6h->daddr, eth->h_dest);
+ 
+ 	hopopt = (u8 *)(ip6h + 1);
+@@ -1768,6 +1771,7 @@ void br_multicast_init(struct net_bridge *br)
+ 	br->ip6_other_query.delay_time = 0;
+ 	br->ip6_querier.port = NULL;
+ #endif
++	br->has_ipv6_addr = 1;
+ 
+ 	spin_lock_init(&br->multicast_lock);
+ 	setup_timer(&br->multicast_router_timer,
+diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
+index e24abfd..3dd7e2c 100644
+--- a/net/bridge/br_private.h
++++ b/net/bridge/br_private.h
+@@ -303,6 +303,7 @@ struct net_bridge
+ 	u8				multicast_disabled:1;
+ 	u8				multicast_querier:1;
+ 	u8				multicast_query_use_ifaddr:1;
++	u8				has_ipv6_addr:1;
+ 
+ 	u32				hash_elasticity;
+ 	u32				hash_max;
+@@ -577,10 +578,22 @@ static inline bool br_multicast_is_router(struct net_bridge *br)
+ 
+ static inline bool
+ __br_multicast_querier_exists(struct net_bridge *br,
+-			      struct bridge_mcast_other_query *querier)
++				struct bridge_mcast_other_query *querier,
++				const bool is_ipv6)
+ {
++	bool own_querier_enabled;
++
++	if (br->multicast_querier) {
++		if (is_ipv6 && !br->has_ipv6_addr)
++			own_querier_enabled = false;
++		else
++			own_querier_enabled = true;
++	} else {
++		own_querier_enabled = false;
++	}
++
+ 	return time_is_before_jiffies(querier->delay_time) &&
+-	       (br->multicast_querier || timer_pending(&querier->timer));
++	       (own_querier_enabled || timer_pending(&querier->timer));
+ }
+ 
+ static inline bool br_multicast_querier_exists(struct net_bridge *br,
+@@ -588,10 +601,12 @@ static inline bool br_multicast_querier_exists(struct net_bridge *br,
+ {
+ 	switch (eth->h_proto) {
+ 	case (htons(ETH_P_IP)):
+-		return __br_multicast_querier_exists(br, &br->ip4_other_query);
++		return __br_multicast_querier_exists(br,
++			&br->ip4_other_query, false);
+ #if IS_ENABLED(CONFIG_IPV6)
+ 	case (htons(ETH_P_IPV6)):
+-		return __br_multicast_querier_exists(br, &br->ip6_other_query);
++		return __br_multicast_querier_exists(br,
++			&br->ip6_other_query, true);
+ #endif
+ 	default:
+ 		return false;
-- 
2.8.1



From dennisschneck at web.de  Thu Jun 30 08:54:56 2016
From: dennisschneck at web.de (Dennis Schneck)
Date: Thu, 30 Jun 2016 17:54:56 +0200
Subject: [LEDE-DEV] Need /dev/mtd4 from TPLink TL-WR941ND v6
Message-ID: <trinity-6171ef85-f450-4889-b907-a84f02036240-1467302096051@3capp-webde-bs04>

Hello,
has anybody a TPLink TL-WR941ND Ver. 6.0.
Can you please export with dd the Partition: /dev/mtd4 an offer me a Download ?
Thanks
Dennis


From hauke at hauke-m.de  Thu Jun 30 11:47:02 2016
From: hauke at hauke-m.de (Hauke Mehrtens)
Date: Thu, 30 Jun 2016 20:47:02 +0200
Subject: [LEDE-DEV] [PATCH] e2fsprogs: fix build problem with very old
 libmagic
In-Reply-To: <c54ecc61-ea9e-efec-76c4-8c13164f5119@web.de>
References: <1467234876-27902-1-git-send-email-hauke@hauke-m.de>
 <c54ecc61-ea9e-efec-76c4-8c13164f5119@web.de>
Message-ID: <370426e7-0f4c-2836-fd85-f67588325ba6@hauke-m.de>

On 06/30/2016 08:15 AM, Dirk Neukirchen wrote:
> On 29.06.2016 23:14, Hauke Mehrtens wrote:
>> From: Hauke Mehrtens <hauke.mehrtens at intel.com>
>>
>> The libmagic shipped with RedHat 5 does not define
> 
> As a reference - RHEL4: Mar/2017, RHEL5:Nov/2020 
> src: https://access.redhat.com/support/policy/updates/errata

Yes it is very old and we are planing a migration to something more
recent, it is already anoint.

> I have recommended/tested build OS on my todo list 

You can not test all this in advance.

>> MAGIC_NO_CHECK_COMPRESS and MAGIC_NO_CHECK_COMPRESS.
> 
> c/p error ?

Yes, I will fix it.

> e2fsprogs should
>> check for that otherwise the build will fail.
>>
>> Signed-off-by: Hauke Mehrtens <hauke.mehrtens at intel.com>
>> ---
>>  tools/e2fsprogs/patches/010-old-libmagic.patch | 11 +++++++++++
>>  1 file changed, 11 insertions(+)
>>  create mode 100644 tools/e2fsprogs/patches/010-old-libmagic.patch
>>
>> diff --git a/tools/e2fsprogs/patches/010-old-libmagic.patch b/tools/e2fsprogs/patches/010-old-libmagic.patch
>> new file mode 100644
>> index 0000000..5ba8a54
>> --- /dev/null
>> +++ b/tools/e2fsprogs/patches/010-old-libmagic.patch
>> @@ -0,0 +1,11 @@
>> +--- a/lib/support/plausible.c
>> ++++ b/lib/support/plausible.c
>> +@@ -247,7 +247,7 @@ int check_plausibility(const char *devic
>> + 		return 0;
>> + 	}
>> + 
>> +-#ifdef HAVE_MAGIC_H
>> ++#if defined(HAVE_MAGIC_H) && defined(MAGIC_NO_CHECK_COMPRESS) && defined(MAGIC_NO_CHECK_COMPRESS)
> 
> c/p error ?

Yes, I will fix it.

>> + 	if ((flags & CHECK_FS_EXIST) &&
>> + 	    !getenv("E2FSPROGS_LIBMAGIC_SUPPRESS") &&
>> + 	    magic_library_available()) {
>>
> 



From chunkeey at googlemail.com  Thu Jun 30 11:53:32 2016
From: chunkeey at googlemail.com (Christian Lamparter)
Date: Thu, 30 Jun 2016 20:53:32 +0200
Subject: [LEDE-DEV] [PATCH 2/2] prism54-firmware: add also other p54
	firmware to own package
In-Reply-To: <1467234781-27748-2-git-send-email-hauke@hauke-m.de>
References: <1467234781-27748-1-git-send-email-hauke@hauke-m.de>
 <1467234781-27748-2-git-send-email-hauke@hauke-m.de>
Message-ID: <5648141.N8Y6LZsnWQ@debian64>

On Wednesday, June 29, 2016 11:13:01 PM Hauke Mehrtens wrote:
> From: Hauke Mehrtens <hauke.mehrtens at intel.com>
> 
> Extract the other p54 firmware files into the prism54-firmware package.
> 
> Signed-off-by: Hauke Mehrtens <hauke.mehrtens at intel.com>
Hey, that's really nice of you.

Would it be possible to set PKG_VERSION to like 1.0 and add a variable
for PRISM54FW:=1.0.4.3.arm and set the PKG_SOURCE:=$(PRISM54FW) instead?

Regards,
Christian

> ---
>  package/firmware/prism54-firmware/Makefile | 75 ++++++++++++++++++++++++++++--
>  package/kernel/mac80211/Makefile           | 48 ++-----------------
>  2 files changed, 75 insertions(+), 48 deletions(-)
> 
> diff --git a/package/firmware/prism54-firmware/Makefile b/package/firmware/prism54-firmware/Makefile
> index 759e6b0..2f39dc9 100644
> --- a/package/firmware/prism54-firmware/Makefile
> +++ b/package/firmware/prism54-firmware/Makefile
> @@ -9,20 +9,70 @@ PKG_NAME:=prism54-firmware
>  PKG_VERSION:=1.0.4.3
>  PKG_RELEASE:=1
>  
> +PRG_URL:=https://daemonizer.de/prism54/prism54-fw/
> +
>  # Prism54 FullMAC firmware (jbnore.free.fr seems to be rather slow, so we use daemonizer.de)
>  PKG_SOURCE:=$(PKG_VERSION).arm
> -PKG_SOURCE_URL:=https://daemonizer.de/prism54/prism54-fw/fw-fullmac/
> +PKG_SOURCE_URL:=$(PRG_URL)/fw-fullmac/
>  PKG_MD5SUM:=8bd4310971772a486b9784c77f8a6df9
>  
>  include $(INCLUDE_DIR)/package.mk
>  
> -define Package/prism54-firmware
> +
> +# Prism54 drivers
> +P54USBFW:=2.13.24.0.lm87.arm
> +P54PCIFW:=2.13.12.0.arm
> +P54SPIFW:=2.13.0.0.a.13.14.arm
> +
> +define Download/p54-usb-firmware
> +  FILE:=$(P54USBFW)
> +  URL:=$(PRG_URL)/fw-usb
> +  MD5SUM:=8e8ab005a4f8f0123bcdc51bc25b47f6
> +endef
> +$(eval $(call Download,p54-usb-firmware))
> +
> +define Download/p54-pci-firmware
> +  FILE:=$(P54PCIFW)
> +  URL:=$(PRG_URL)/fw-softmac
> +  MD5SUM:=ff7536af2092b1c4b21315bd103ef4c4
> +endef
> +$(eval $(call Download,p54-pci-firmware))
> +
> +define Download/p54-spi-firmware
> +  FILE:=$(P54SPIFW)
> +  URL:=$(PRG_URL)/stlc4560
> +  MD5SUM:=42661f8ecbadd88012807493f596081d
> +endef
> +$(eval $(call Download,p54-spi-firmware))
> +
> +
> +define Package/prism54-firmware-default
>    SECTION:=firmware
>    CATEGORY:=Firmware
> -  URL:=https://daemonizer.de/prism54/prism54-fw
> +  URL:=https://daemonizer.de/prism54/prism54-fw/
> +endef
> +
> +define Package/prism54-firmware
> +$(Package/prism54-firmware-default)
>    TITLE:=prism54 firmware
>  endef
>  
> +define Package/p54-usb-firmware
> +$(Package/prism54-firmware-default)
> +  TITLE:=p54-usb firmware
> +endef
> +
> +define Package/p54-pci-firmware
> +$(Package/prism54-firmware-default)
> +  TITLE:=p54-pci firmware
> +endef
> +
> +define Package/p54-spi-firmware
> +$(Package/prism54-firmware-default)
> +  TITLE:=p54-spi firmware
> +endef
> +
> +
>  define Build/Prepare
>  	mkdir -p $(PKG_BUILD_DIR)
>  endef
> @@ -36,4 +86,23 @@ define Package/prism54-firmware/install
>  	$(INSTALL_DATA) $(DL_DIR)/$(PKG_SOURCE) $(1)/lib/firmware/isl3890
>  endef
>  
> +define Package/p54-usb-firmware/install
> +	$(INSTALL_DIR) $(1)/lib/firmware
> +	$(INSTALL_DATA) $(DL_DIR)/$(P54USBFW) $(1)/lib/firmware/isl3887usb
> +endef
> +
> +define Package/p54-pci-firmware/install
> +	$(INSTALL_DIR) $(1)/lib/firmware
> +	$(INSTALL_DATA) $(DL_DIR)/$(P54PCIFW) $(1)/lib/firmware/isl3886pci
> +endef
> +
> +define Package/p54-spi-firmware/install
> +	$(INSTALL_DIR) $(1)/lib/firmware
> +	$(INSTALL_DATA) $(DL_DIR)/$(P54SPIFW) $(1)/lib/firmware/3826.arm
> +endef
> +
> +
>  $(eval $(call BuildPackage,prism54-firmware))
> +$(eval $(call BuildPackage,p54-usb-firmware))
> +$(eval $(call BuildPackage,p54-pci-firmware))
> +$(eval $(call BuildPackage,p54-spi-firmware))
> diff --git a/package/kernel/mac80211/Makefile b/package/kernel/mac80211/Makefile
> index bee0723..38eb4af 100644
> --- a/package/kernel/mac80211/Makefile
> +++ b/package/kernel/mac80211/Makefile
> @@ -1061,33 +1061,6 @@ define KernelPackage/mwifiex-pcie/description
>   Kernel modules for Marvell 802.11n/802.11ac PCIe Wireless cards
>  endef
>  
> -
> -# Prism54 drivers
> -P54PCIFW:=2.13.12.0.arm
> -P54USBFW:=2.13.24.0.lm87.arm
> -P54SPIFW:=2.13.0.0.a.13.14.arm
> -
> -define Download/p54usb
> -  FILE:=$(P54USBFW)
> -  URL:=http://daemonizer.de/prism54/prism54-fw/fw-usb
> -  MD5SUM:=8e8ab005a4f8f0123bcdc51bc25b47f6
> -endef
> -$(eval $(call Download,p54usb))
> -
> -define Download/p54pci
> -  FILE:=$(P54PCIFW)
> -  URL:=http://daemonizer.de/prism54/prism54-fw/fw-softmac
> -  MD5SUM:=ff7536af2092b1c4b21315bd103ef4c4
> -endef
> -$(eval $(call Download,p54pci))
> -
> -define Download/p54spi
> -  FILE:=$(P54SPIFW)
> -  URL:=http://daemonizer.de/prism54/prism54-fw/stlc4560
> -  MD5SUM:=42661f8ecbadd88012807493f596081d
> -endef
> -$(eval $(call Download,p54spi))
> -
>  define KernelPackage/p54/Default
>    $(call KernelPackage/mac80211/Default)
>    TITLE:=Prism54 Drivers
> @@ -1107,7 +1080,7 @@ endef
>  define KernelPackage/p54-pci
>    $(call KernelPackage/p54/Default)
>    TITLE+= (PCI)
> -  DEPENDS+= @PCI_SUPPORT +kmod-p54-common
> +  DEPENDS+= @PCI_SUPPORT +kmod-p54-common +p54-pci-firmware
>    FILES:=$(PKG_BUILD_DIR)/drivers/net/wireless/intersil/p54/p54pci.ko
>    AUTOLOAD:=$(call AutoProbe,p54pci)
>  endef
> @@ -1115,7 +1088,7 @@ endef
>  define KernelPackage/p54-usb
>    $(call KernelPackage/p54/Default)
>    TITLE+= (USB)
> -  DEPENDS+= @USB_SUPPORT +kmod-usb-core +kmod-p54-common
> +  DEPENDS+= @USB_SUPPORT +kmod-usb-core +kmod-p54-common +p54-usb-firmware
>    FILES:=$(PKG_BUILD_DIR)/drivers/net/wireless/intersil/p54/p54usb.ko
>    AUTOLOAD:=$(call AutoProbe,p54usb)
>  endef
> @@ -1123,7 +1096,7 @@ endef
>  define KernelPackage/p54-spi
>    $(call KernelPackage/p54/Default)
>    TITLE+= (SPI)
> -  DEPENDS+= @TARGET_omap24xx +kmod-p54-common
> +  DEPENDS+= @TARGET_omap24xx +kmod-p54-common +p54-spi-firmware
>    FILES:=$(PKG_BUILD_DIR)/drivers/net/wireless/intersil/p54/p54spi.ko
>    AUTOLOAD:=$(call AutoProbe,p54spi)
>  endef
> @@ -1771,21 +1744,6 @@ define KernelPackage/ipw2200/install
>  	$(INSTALL_DATA) $(PKG_BUILD_DIR)/$(IPW2200_NAME)-$(IPW2200_VERSION)/ipw2200*.fw $(1)/lib/firmware
>  endef
>  
> -define KernelPackage/p54-pci/install
> -	$(INSTALL_DIR) $(1)/lib/firmware
> -	$(INSTALL_DATA) $(DL_DIR)/$(P54PCIFW) $(1)/lib/firmware/isl3886pci
> -endef
> -
> -define KernelPackage/p54-usb/install
> -	$(INSTALL_DIR) $(1)/lib/firmware
> -	$(INSTALL_DATA) $(DL_DIR)/$(P54USBFW) $(1)/lib/firmware/isl3887usb
> -endef
> -
> -define KernelPackage/p54-spi/install
> -	$(INSTALL_DIR) $(1)/lib/firmware
> -	$(INSTALL_DATA) $(DL_DIR)/$(P54SPIFW) $(1)/lib/firmware/3826.arm
> -endef
> -
>  define KernelPackage/zd1211rw/install
>  	$(INSTALL_DIR) $(1)/lib/firmware/zd1211
>  	$(INSTALL_DATA) $(PKG_BUILD_DIR)/$(ZD1211FW_NAME)/zd1211* $(1)/lib/firmware/zd1211
> 



From john at phrozen.org  Thu Jun 30 12:07:43 2016
From: john at phrozen.org (John Crispin)
Date: Thu, 30 Jun 2016 21:07:43 +0200
Subject: [LEDE-DEV] [PATCH 2/2] prism54-firmware: add also other p54
 firmware to own package
In-Reply-To: <5648141.N8Y6LZsnWQ@debian64>
References: <1467234781-27748-1-git-send-email-hauke@hauke-m.de>
 <1467234781-27748-2-git-send-email-hauke@hauke-m.de>
 <5648141.N8Y6LZsnWQ@debian64>
Message-ID: <5f9a57f3-a4ae-f291-3ee4-d5d47ae067df@phrozen.org>

i have already added this to my staging tree, feel free to send a ptch
that i can fold into haukes patch

	John

On 30/06/2016 20:53, Christian Lamparter wrote:
> On Wednesday, June 29, 2016 11:13:01 PM Hauke Mehrtens wrote:
>> From: Hauke Mehrtens <hauke.mehrtens at intel.com>
>>
>> Extract the other p54 firmware files into the prism54-firmware package.
>>
>> Signed-off-by: Hauke Mehrtens <hauke.mehrtens at intel.com>
> Hey, that's really nice of you.
> 
> Would it be possible to set PKG_VERSION to like 1.0 and add a variable
> for PRISM54FW:=1.0.4.3.arm and set the PKG_SOURCE:=$(PRISM54FW) instead?
> 
> Regards,
> Christian
> 
>> ---
>>  package/firmware/prism54-firmware/Makefile | 75 ++++++++++++++++++++++++++++--
>>  package/kernel/mac80211/Makefile           | 48 ++-----------------
>>  2 files changed, 75 insertions(+), 48 deletions(-)
>>
>> diff --git a/package/firmware/prism54-firmware/Makefile b/package/firmware/prism54-firmware/Makefile
>> index 759e6b0..2f39dc9 100644
>> --- a/package/firmware/prism54-firmware/Makefile
>> +++ b/package/firmware/prism54-firmware/Makefile
>> @@ -9,20 +9,70 @@ PKG_NAME:=prism54-firmware
>>  PKG_VERSION:=1.0.4.3
>>  PKG_RELEASE:=1
>>  
>> +PRG_URL:=https://daemonizer.de/prism54/prism54-fw/
>> +
>>  # Prism54 FullMAC firmware (jbnore.free.fr seems to be rather slow, so we use daemonizer.de)
>>  PKG_SOURCE:=$(PKG_VERSION).arm
>> -PKG_SOURCE_URL:=https://daemonizer.de/prism54/prism54-fw/fw-fullmac/
>> +PKG_SOURCE_URL:=$(PRG_URL)/fw-fullmac/
>>  PKG_MD5SUM:=8bd4310971772a486b9784c77f8a6df9
>>  
>>  include $(INCLUDE_DIR)/package.mk
>>  
>> -define Package/prism54-firmware
>> +
>> +# Prism54 drivers
>> +P54USBFW:=2.13.24.0.lm87.arm
>> +P54PCIFW:=2.13.12.0.arm
>> +P54SPIFW:=2.13.0.0.a.13.14.arm
>> +
>> +define Download/p54-usb-firmware
>> +  FILE:=$(P54USBFW)
>> +  URL:=$(PRG_URL)/fw-usb
>> +  MD5SUM:=8e8ab005a4f8f0123bcdc51bc25b47f6
>> +endef
>> +$(eval $(call Download,p54-usb-firmware))
>> +
>> +define Download/p54-pci-firmware
>> +  FILE:=$(P54PCIFW)
>> +  URL:=$(PRG_URL)/fw-softmac
>> +  MD5SUM:=ff7536af2092b1c4b21315bd103ef4c4
>> +endef
>> +$(eval $(call Download,p54-pci-firmware))
>> +
>> +define Download/p54-spi-firmware
>> +  FILE:=$(P54SPIFW)
>> +  URL:=$(PRG_URL)/stlc4560
>> +  MD5SUM:=42661f8ecbadd88012807493f596081d
>> +endef
>> +$(eval $(call Download,p54-spi-firmware))
>> +
>> +
>> +define Package/prism54-firmware-default
>>    SECTION:=firmware
>>    CATEGORY:=Firmware
>> -  URL:=https://daemonizer.de/prism54/prism54-fw
>> +  URL:=https://daemonizer.de/prism54/prism54-fw/
>> +endef
>> +
>> +define Package/prism54-firmware
>> +$(Package/prism54-firmware-default)
>>    TITLE:=prism54 firmware
>>  endef
>>  
>> +define Package/p54-usb-firmware
>> +$(Package/prism54-firmware-default)
>> +  TITLE:=p54-usb firmware
>> +endef
>> +
>> +define Package/p54-pci-firmware
>> +$(Package/prism54-firmware-default)
>> +  TITLE:=p54-pci firmware
>> +endef
>> +
>> +define Package/p54-spi-firmware
>> +$(Package/prism54-firmware-default)
>> +  TITLE:=p54-spi firmware
>> +endef
>> +
>> +
>>  define Build/Prepare
>>  	mkdir -p $(PKG_BUILD_DIR)
>>  endef
>> @@ -36,4 +86,23 @@ define Package/prism54-firmware/install
>>  	$(INSTALL_DATA) $(DL_DIR)/$(PKG_SOURCE) $(1)/lib/firmware/isl3890
>>  endef
>>  
>> +define Package/p54-usb-firmware/install
>> +	$(INSTALL_DIR) $(1)/lib/firmware
>> +	$(INSTALL_DATA) $(DL_DIR)/$(P54USBFW) $(1)/lib/firmware/isl3887usb
>> +endef
>> +
>> +define Package/p54-pci-firmware/install
>> +	$(INSTALL_DIR) $(1)/lib/firmware
>> +	$(INSTALL_DATA) $(DL_DIR)/$(P54PCIFW) $(1)/lib/firmware/isl3886pci
>> +endef
>> +
>> +define Package/p54-spi-firmware/install
>> +	$(INSTALL_DIR) $(1)/lib/firmware
>> +	$(INSTALL_DATA) $(DL_DIR)/$(P54SPIFW) $(1)/lib/firmware/3826.arm
>> +endef
>> +
>> +
>>  $(eval $(call BuildPackage,prism54-firmware))
>> +$(eval $(call BuildPackage,p54-usb-firmware))
>> +$(eval $(call BuildPackage,p54-pci-firmware))
>> +$(eval $(call BuildPackage,p54-spi-firmware))
>> diff --git a/package/kernel/mac80211/Makefile b/package/kernel/mac80211/Makefile
>> index bee0723..38eb4af 100644
>> --- a/package/kernel/mac80211/Makefile
>> +++ b/package/kernel/mac80211/Makefile
>> @@ -1061,33 +1061,6 @@ define KernelPackage/mwifiex-pcie/description
>>   Kernel modules for Marvell 802.11n/802.11ac PCIe Wireless cards
>>  endef
>>  
>> -
>> -# Prism54 drivers
>> -P54PCIFW:=2.13.12.0.arm
>> -P54USBFW:=2.13.24.0.lm87.arm
>> -P54SPIFW:=2.13.0.0.a.13.14.arm
>> -
>> -define Download/p54usb
>> -  FILE:=$(P54USBFW)
>> -  URL:=http://daemonizer.de/prism54/prism54-fw/fw-usb
>> -  MD5SUM:=8e8ab005a4f8f0123bcdc51bc25b47f6
>> -endef
>> -$(eval $(call Download,p54usb))
>> -
>> -define Download/p54pci
>> -  FILE:=$(P54PCIFW)
>> -  URL:=http://daemonizer.de/prism54/prism54-fw/fw-softmac
>> -  MD5SUM:=ff7536af2092b1c4b21315bd103ef4c4
>> -endef
>> -$(eval $(call Download,p54pci))
>> -
>> -define Download/p54spi
>> -  FILE:=$(P54SPIFW)
>> -  URL:=http://daemonizer.de/prism54/prism54-fw/stlc4560
>> -  MD5SUM:=42661f8ecbadd88012807493f596081d
>> -endef
>> -$(eval $(call Download,p54spi))
>> -
>>  define KernelPackage/p54/Default
>>    $(call KernelPackage/mac80211/Default)
>>    TITLE:=Prism54 Drivers
>> @@ -1107,7 +1080,7 @@ endef
>>  define KernelPackage/p54-pci
>>    $(call KernelPackage/p54/Default)
>>    TITLE+= (PCI)
>> -  DEPENDS+= @PCI_SUPPORT +kmod-p54-common
>> +  DEPENDS+= @PCI_SUPPORT +kmod-p54-common +p54-pci-firmware
>>    FILES:=$(PKG_BUILD_DIR)/drivers/net/wireless/intersil/p54/p54pci.ko
>>    AUTOLOAD:=$(call AutoProbe,p54pci)
>>  endef
>> @@ -1115,7 +1088,7 @@ endef
>>  define KernelPackage/p54-usb
>>    $(call KernelPackage/p54/Default)
>>    TITLE+= (USB)
>> -  DEPENDS+= @USB_SUPPORT +kmod-usb-core +kmod-p54-common
>> +  DEPENDS+= @USB_SUPPORT +kmod-usb-core +kmod-p54-common +p54-usb-firmware
>>    FILES:=$(PKG_BUILD_DIR)/drivers/net/wireless/intersil/p54/p54usb.ko
>>    AUTOLOAD:=$(call AutoProbe,p54usb)
>>  endef
>> @@ -1123,7 +1096,7 @@ endef
>>  define KernelPackage/p54-spi
>>    $(call KernelPackage/p54/Default)
>>    TITLE+= (SPI)
>> -  DEPENDS+= @TARGET_omap24xx +kmod-p54-common
>> +  DEPENDS+= @TARGET_omap24xx +kmod-p54-common +p54-spi-firmware
>>    FILES:=$(PKG_BUILD_DIR)/drivers/net/wireless/intersil/p54/p54spi.ko
>>    AUTOLOAD:=$(call AutoProbe,p54spi)
>>  endef
>> @@ -1771,21 +1744,6 @@ define KernelPackage/ipw2200/install
>>  	$(INSTALL_DATA) $(PKG_BUILD_DIR)/$(IPW2200_NAME)-$(IPW2200_VERSION)/ipw2200*.fw $(1)/lib/firmware
>>  endef
>>  
>> -define KernelPackage/p54-pci/install
>> -	$(INSTALL_DIR) $(1)/lib/firmware
>> -	$(INSTALL_DATA) $(DL_DIR)/$(P54PCIFW) $(1)/lib/firmware/isl3886pci
>> -endef
>> -
>> -define KernelPackage/p54-usb/install
>> -	$(INSTALL_DIR) $(1)/lib/firmware
>> -	$(INSTALL_DATA) $(DL_DIR)/$(P54USBFW) $(1)/lib/firmware/isl3887usb
>> -endef
>> -
>> -define KernelPackage/p54-spi/install
>> -	$(INSTALL_DIR) $(1)/lib/firmware
>> -	$(INSTALL_DATA) $(DL_DIR)/$(P54SPIFW) $(1)/lib/firmware/3826.arm
>> -endef
>> -
>>  define KernelPackage/zd1211rw/install
>>  	$(INSTALL_DIR) $(1)/lib/firmware/zd1211
>>  	$(INSTALL_DATA) $(PKG_BUILD_DIR)/$(ZD1211FW_NAME)/zd1211* $(1)/lib/firmware/zd1211
>>
> 
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 


From john at phrozen.org  Thu Jun 30 12:33:53 2016
From: john at phrozen.org (John Crispin)
Date: Thu, 30 Jun 2016 21:33:53 +0200
Subject: [LEDE-DEV] [PATCH] Bridge: Fix ipv6 mc snooping if bridge has
 no ipv6 address
In-Reply-To: <1467299135-1061-1-git-send-email-daniel@dd-wrt.com>
References: <1467299135-1061-1-git-send-email-daniel@dd-wrt.com>
Message-ID: <73de8da8-aa3e-2e0a-46f0-5ae1c5b29aa5@phrozen.org>


On 30/06/2016 17:05, Daniel Danzberger wrote:
> This patch is a backport for current LEDE 4.4 Kernels.
> It is already upstream, for linux-next and stable.
> The initial commit message is below:
> 
> The bridge is falsly dropping ipv6 mulitcast packets if there is:
>  1. No ipv6 address assigned on the brigde.
>  2. No external mld querier present.
>  3. The internal querier enabled.
> 
> When the bridge fails to build mld queries, because it has no
> ipv6 address, it slilently returns, but keeps the local querier enabled.
> This specific case causes confusing packet loss.
> 
> Ipv6 multicast snooping can only work if:
>  a) An external querier is present
>  OR
>  b) The bridge has an ipv6 address an is capable of sending own queries
> 
> Otherwise it has to forward/flood the ipv6 multicast traffic,
> because snooping cannot work.
> 
> This patch fixes the issue by adding a flag to the bridge struct that
> indicates that there is currently no ipv6 address assinged to the bridge
> and returns a false state for the local querier in
> __br_multicast_querier_exists().
> 
> Special thanks to Linus L?ssing.
> 
> Signed-off-by: Daniel Danzberger <daniel at dd-wrt.com>


Hi Daniel,

can you please use the full annotated upstream patch ? it would be best
if 646-bridge_fix_ipv6_mc_snooping_if_bridge_has_no_ipv6_address.patch
contained the original description and SoB line
	John


> ---
>  ...mc_snooping_if_bridge_has_no_ipv6_address.patch | 76 ++++++++++++++++++++++
>  1 file changed, 76 insertions(+)
>  create mode 100644 target/linux/generic/patches-4.4/646-bridge_fix_ipv6_mc_snooping_if_bridge_has_no_ipv6_address.patch
> 
> diff --git a/target/linux/generic/patches-4.4/646-bridge_fix_ipv6_mc_snooping_if_bridge_has_no_ipv6_address.patch b/target/linux/generic/patches-4.4/646-bridge_fix_ipv6_mc_snooping_if_bridge_has_no_ipv6_address.patch
> new file mode 100644
> index 0000000..e0bdbae
> --- /dev/null
> +++ b/target/linux/generic/patches-4.4/646-bridge_fix_ipv6_mc_snooping_if_bridge_has_no_ipv6_address.patch
> @@ -0,0 +1,76 @@
> +diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
> +index c8c2a8a..d063a10 100644
> +--- a/net/bridge/br_multicast.c
> ++++ b/net/bridge/br_multicast.c
> +@@ -465,8 +465,11 @@ static struct sk_buff *br_ip6_multicast_alloc_query(struct net_bridge *br,
> + 	if (ipv6_dev_get_saddr(dev_net(br->dev), br->dev, &ip6h->daddr, 0,
> + 			       &ip6h->saddr)) {
> + 		kfree_skb(skb);
> ++		br->has_ipv6_addr = 0;
> + 		return NULL;
> + 	}
> ++
> ++	br->has_ipv6_addr = 1;
> + 	ipv6_eth_mc_map(&ip6h->daddr, eth->h_dest);
> + 
> + 	hopopt = (u8 *)(ip6h + 1);
> +@@ -1768,6 +1771,7 @@ void br_multicast_init(struct net_bridge *br)
> + 	br->ip6_other_query.delay_time = 0;
> + 	br->ip6_querier.port = NULL;
> + #endif
> ++	br->has_ipv6_addr = 1;
> + 
> + 	spin_lock_init(&br->multicast_lock);
> + 	setup_timer(&br->multicast_router_timer,
> +diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
> +index e24abfd..3dd7e2c 100644
> +--- a/net/bridge/br_private.h
> ++++ b/net/bridge/br_private.h
> +@@ -303,6 +303,7 @@ struct net_bridge
> + 	u8				multicast_disabled:1;
> + 	u8				multicast_querier:1;
> + 	u8				multicast_query_use_ifaddr:1;
> ++	u8				has_ipv6_addr:1;
> + 
> + 	u32				hash_elasticity;
> + 	u32				hash_max;
> +@@ -577,10 +578,22 @@ static inline bool br_multicast_is_router(struct net_bridge *br)
> + 
> + static inline bool
> + __br_multicast_querier_exists(struct net_bridge *br,
> +-			      struct bridge_mcast_other_query *querier)
> ++				struct bridge_mcast_other_query *querier,
> ++				const bool is_ipv6)
> + {
> ++	bool own_querier_enabled;
> ++
> ++	if (br->multicast_querier) {
> ++		if (is_ipv6 && !br->has_ipv6_addr)
> ++			own_querier_enabled = false;
> ++		else
> ++			own_querier_enabled = true;
> ++	} else {
> ++		own_querier_enabled = false;
> ++	}
> ++
> + 	return time_is_before_jiffies(querier->delay_time) &&
> +-	       (br->multicast_querier || timer_pending(&querier->timer));
> ++	       (own_querier_enabled || timer_pending(&querier->timer));
> + }
> + 
> + static inline bool br_multicast_querier_exists(struct net_bridge *br,
> +@@ -588,10 +601,12 @@ static inline bool br_multicast_querier_exists(struct net_bridge *br,
> + {
> + 	switch (eth->h_proto) {
> + 	case (htons(ETH_P_IP)):
> +-		return __br_multicast_querier_exists(br, &br->ip4_other_query);
> ++		return __br_multicast_querier_exists(br,
> ++			&br->ip4_other_query, false);
> + #if IS_ENABLED(CONFIG_IPV6)
> + 	case (htons(ETH_P_IPV6)):
> +-		return __br_multicast_querier_exists(br, &br->ip6_other_query);
> ++		return __br_multicast_querier_exists(br,
> ++			&br->ip6_other_query, true);
> + #endif
> + 	default:
> + 		return false;
> 


From hauke at hauke-m.de  Thu Jun 30 13:16:42 2016
From: hauke at hauke-m.de (Hauke Mehrtens)
Date: Thu, 30 Jun 2016 22:16:42 +0200
Subject: [LEDE-DEV] [PATCH 2/2] prism54-firmware: add also other p54
 firmware to own package
In-Reply-To: <5f9a57f3-a4ae-f291-3ee4-d5d47ae067df@phrozen.org>
References: <1467234781-27748-1-git-send-email-hauke@hauke-m.de>
 <1467234781-27748-2-git-send-email-hauke@hauke-m.de>
 <5648141.N8Y6LZsnWQ@debian64>
 <5f9a57f3-a4ae-f291-3ee4-d5d47ae067df@phrozen.org>
Message-ID: <b9792319-8b9a-cce4-72cd-cb083fce0401@hauke-m.de>

On 06/30/2016 09:07 PM, John Crispin wrote:
> i have already added this to my staging tree, feel free to send a ptch
> that i can fold into haukes patch
> 
> 	John

I already pushed this, but send a patch to improve this please.

Hauke
> 
> On 30/06/2016 20:53, Christian Lamparter wrote:
>> On Wednesday, June 29, 2016 11:13:01 PM Hauke Mehrtens wrote:
>>> From: Hauke Mehrtens <hauke.mehrtens at intel.com>
>>>
>>> Extract the other p54 firmware files into the prism54-firmware package.
>>>
>>> Signed-off-by: Hauke Mehrtens <hauke.mehrtens at intel.com>
>> Hey, that's really nice of you.
>>
>> Would it be possible to set PKG_VERSION to like 1.0 and add a variable
>> for PRISM54FW:=1.0.4.3.arm and set the PKG_SOURCE:=$(PRISM54FW) instead?
>>
>> Regards,
>> Christian
>>
>>> ---
>>>  package/firmware/prism54-firmware/Makefile | 75 ++++++++++++++++++++++++++++--
>>>  package/kernel/mac80211/Makefile           | 48 ++-----------------
>>>  2 files changed, 75 insertions(+), 48 deletions(-)
>>>
>>> diff --git a/package/firmware/prism54-firmware/Makefile b/package/firmware/prism54-firmware/Makefile
>>> index 759e6b0..2f39dc9 100644
>>> --- a/package/firmware/prism54-firmware/Makefile
>>> +++ b/package/firmware/prism54-firmware/Makefile
>>> @@ -9,20 +9,70 @@ PKG_NAME:=prism54-firmware
>>>  PKG_VERSION:=1.0.4.3
>>>  PKG_RELEASE:=1
>>>  
>>> +PRG_URL:=https://daemonizer.de/prism54/prism54-fw/
>>> +
>>>  # Prism54 FullMAC firmware (jbnore.free.fr seems to be rather slow, so we use daemonizer.de)
>>>  PKG_SOURCE:=$(PKG_VERSION).arm
>>> -PKG_SOURCE_URL:=https://daemonizer.de/prism54/prism54-fw/fw-fullmac/
>>> +PKG_SOURCE_URL:=$(PRG_URL)/fw-fullmac/
>>>  PKG_MD5SUM:=8bd4310971772a486b9784c77f8a6df9
>>>  
>>>  include $(INCLUDE_DIR)/package.mk
>>>  
>>> -define Package/prism54-firmware
>>> +
>>> +# Prism54 drivers
>>> +P54USBFW:=2.13.24.0.lm87.arm
>>> +P54PCIFW:=2.13.12.0.arm
>>> +P54SPIFW:=2.13.0.0.a.13.14.arm
>>> +
>>> +define Download/p54-usb-firmware
>>> +  FILE:=$(P54USBFW)
>>> +  URL:=$(PRG_URL)/fw-usb
>>> +  MD5SUM:=8e8ab005a4f8f0123bcdc51bc25b47f6
>>> +endef
>>> +$(eval $(call Download,p54-usb-firmware))
>>> +
>>> +define Download/p54-pci-firmware
>>> +  FILE:=$(P54PCIFW)
>>> +  URL:=$(PRG_URL)/fw-softmac
>>> +  MD5SUM:=ff7536af2092b1c4b21315bd103ef4c4
>>> +endef
>>> +$(eval $(call Download,p54-pci-firmware))
>>> +
>>> +define Download/p54-spi-firmware
>>> +  FILE:=$(P54SPIFW)
>>> +  URL:=$(PRG_URL)/stlc4560
>>> +  MD5SUM:=42661f8ecbadd88012807493f596081d
>>> +endef
>>> +$(eval $(call Download,p54-spi-firmware))
>>> +
>>> +
>>> +define Package/prism54-firmware-default
>>>    SECTION:=firmware
>>>    CATEGORY:=Firmware
>>> -  URL:=https://daemonizer.de/prism54/prism54-fw
>>> +  URL:=https://daemonizer.de/prism54/prism54-fw/
>>> +endef
>>> +
>>> +define Package/prism54-firmware
>>> +$(Package/prism54-firmware-default)
>>>    TITLE:=prism54 firmware
>>>  endef
>>>  
>>> +define Package/p54-usb-firmware
>>> +$(Package/prism54-firmware-default)
>>> +  TITLE:=p54-usb firmware
>>> +endef
>>> +
>>> +define Package/p54-pci-firmware
>>> +$(Package/prism54-firmware-default)
>>> +  TITLE:=p54-pci firmware
>>> +endef
>>> +
>>> +define Package/p54-spi-firmware
>>> +$(Package/prism54-firmware-default)
>>> +  TITLE:=p54-spi firmware
>>> +endef
>>> +
>>> +
>>>  define Build/Prepare
>>>  	mkdir -p $(PKG_BUILD_DIR)
>>>  endef
>>> @@ -36,4 +86,23 @@ define Package/prism54-firmware/install
>>>  	$(INSTALL_DATA) $(DL_DIR)/$(PKG_SOURCE) $(1)/lib/firmware/isl3890
>>>  endef
>>>  
>>> +define Package/p54-usb-firmware/install
>>> +	$(INSTALL_DIR) $(1)/lib/firmware
>>> +	$(INSTALL_DATA) $(DL_DIR)/$(P54USBFW) $(1)/lib/firmware/isl3887usb
>>> +endef
>>> +
>>> +define Package/p54-pci-firmware/install
>>> +	$(INSTALL_DIR) $(1)/lib/firmware
>>> +	$(INSTALL_DATA) $(DL_DIR)/$(P54PCIFW) $(1)/lib/firmware/isl3886pci
>>> +endef
>>> +
>>> +define Package/p54-spi-firmware/install
>>> +	$(INSTALL_DIR) $(1)/lib/firmware
>>> +	$(INSTALL_DATA) $(DL_DIR)/$(P54SPIFW) $(1)/lib/firmware/3826.arm
>>> +endef
>>> +
>>> +
>>>  $(eval $(call BuildPackage,prism54-firmware))
>>> +$(eval $(call BuildPackage,p54-usb-firmware))
>>> +$(eval $(call BuildPackage,p54-pci-firmware))
>>> +$(eval $(call BuildPackage,p54-spi-firmware))
>>> diff --git a/package/kernel/mac80211/Makefile b/package/kernel/mac80211/Makefile
>>> index bee0723..38eb4af 100644
>>> --- a/package/kernel/mac80211/Makefile
>>> +++ b/package/kernel/mac80211/Makefile
>>> @@ -1061,33 +1061,6 @@ define KernelPackage/mwifiex-pcie/description
>>>   Kernel modules for Marvell 802.11n/802.11ac PCIe Wireless cards
>>>  endef
>>>  
>>> -
>>> -# Prism54 drivers
>>> -P54PCIFW:=2.13.12.0.arm
>>> -P54USBFW:=2.13.24.0.lm87.arm
>>> -P54SPIFW:=2.13.0.0.a.13.14.arm
>>> -
>>> -define Download/p54usb
>>> -  FILE:=$(P54USBFW)
>>> -  URL:=http://daemonizer.de/prism54/prism54-fw/fw-usb
>>> -  MD5SUM:=8e8ab005a4f8f0123bcdc51bc25b47f6
>>> -endef
>>> -$(eval $(call Download,p54usb))
>>> -
>>> -define Download/p54pci
>>> -  FILE:=$(P54PCIFW)
>>> -  URL:=http://daemonizer.de/prism54/prism54-fw/fw-softmac
>>> -  MD5SUM:=ff7536af2092b1c4b21315bd103ef4c4
>>> -endef
>>> -$(eval $(call Download,p54pci))
>>> -
>>> -define Download/p54spi
>>> -  FILE:=$(P54SPIFW)
>>> -  URL:=http://daemonizer.de/prism54/prism54-fw/stlc4560
>>> -  MD5SUM:=42661f8ecbadd88012807493f596081d
>>> -endef
>>> -$(eval $(call Download,p54spi))
>>> -
>>>  define KernelPackage/p54/Default
>>>    $(call KernelPackage/mac80211/Default)
>>>    TITLE:=Prism54 Drivers
>>> @@ -1107,7 +1080,7 @@ endef
>>>  define KernelPackage/p54-pci
>>>    $(call KernelPackage/p54/Default)
>>>    TITLE+= (PCI)
>>> -  DEPENDS+= @PCI_SUPPORT +kmod-p54-common
>>> +  DEPENDS+= @PCI_SUPPORT +kmod-p54-common +p54-pci-firmware
>>>    FILES:=$(PKG_BUILD_DIR)/drivers/net/wireless/intersil/p54/p54pci.ko
>>>    AUTOLOAD:=$(call AutoProbe,p54pci)
>>>  endef
>>> @@ -1115,7 +1088,7 @@ endef
>>>  define KernelPackage/p54-usb
>>>    $(call KernelPackage/p54/Default)
>>>    TITLE+= (USB)
>>> -  DEPENDS+= @USB_SUPPORT +kmod-usb-core +kmod-p54-common
>>> +  DEPENDS+= @USB_SUPPORT +kmod-usb-core +kmod-p54-common +p54-usb-firmware
>>>    FILES:=$(PKG_BUILD_DIR)/drivers/net/wireless/intersil/p54/p54usb.ko
>>>    AUTOLOAD:=$(call AutoProbe,p54usb)
>>>  endef
>>> @@ -1123,7 +1096,7 @@ endef
>>>  define KernelPackage/p54-spi
>>>    $(call KernelPackage/p54/Default)
>>>    TITLE+= (SPI)
>>> -  DEPENDS+= @TARGET_omap24xx +kmod-p54-common
>>> +  DEPENDS+= @TARGET_omap24xx +kmod-p54-common +p54-spi-firmware
>>>    FILES:=$(PKG_BUILD_DIR)/drivers/net/wireless/intersil/p54/p54spi.ko
>>>    AUTOLOAD:=$(call AutoProbe,p54spi)
>>>  endef
>>> @@ -1771,21 +1744,6 @@ define KernelPackage/ipw2200/install
>>>  	$(INSTALL_DATA) $(PKG_BUILD_DIR)/$(IPW2200_NAME)-$(IPW2200_VERSION)/ipw2200*.fw $(1)/lib/firmware
>>>  endef
>>>  
>>> -define KernelPackage/p54-pci/install
>>> -	$(INSTALL_DIR) $(1)/lib/firmware
>>> -	$(INSTALL_DATA) $(DL_DIR)/$(P54PCIFW) $(1)/lib/firmware/isl3886pci
>>> -endef
>>> -
>>> -define KernelPackage/p54-usb/install
>>> -	$(INSTALL_DIR) $(1)/lib/firmware
>>> -	$(INSTALL_DATA) $(DL_DIR)/$(P54USBFW) $(1)/lib/firmware/isl3887usb
>>> -endef
>>> -
>>> -define KernelPackage/p54-spi/install
>>> -	$(INSTALL_DIR) $(1)/lib/firmware
>>> -	$(INSTALL_DATA) $(DL_DIR)/$(P54SPIFW) $(1)/lib/firmware/3826.arm
>>> -endef
>>> -
>>>  define KernelPackage/zd1211rw/install
>>>  	$(INSTALL_DIR) $(1)/lib/firmware/zd1211
>>>  	$(INSTALL_DATA) $(PKG_BUILD_DIR)/$(ZD1211FW_NAME)/zd1211* $(1)/lib/firmware/zd1211
>>>
>>
>>
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 



From daniel at dd-wrt.com  Thu Jun 30 14:49:52 2016
From: daniel at dd-wrt.com (Daniel Danzberger)
Date: Thu, 30 Jun 2016 23:49:52 +0200
Subject: [LEDE-DEV] [PATCH v2] Bridge: Fix ipv6 mc snooping if bridge has no
	ipv6 address
Message-ID: <1467323392-21279-1-git-send-email-daniel@dd-wrt.com>

This patch is a backport for current LEDE 4.4 Kernels.
It is already upstream, for linux-next and stable.
The initial commit message is below:

The bridge is falsly dropping ipv6 mulitcast packets if there is:
 1. No ipv6 address assigned on the brigde.
 2. No external mld querier present.
 3. The internal querier enabled.

When the bridge fails to build mld queries, because it has no
ipv6 address, it slilently returns, but keeps the local querier enabled.
This specific case causes confusing packet loss.

Ipv6 multicast snooping can only work if:
 a) An external querier is present
 OR
 b) The bridge has an ipv6 address an is capable of sending own queries

Otherwise it has to forward/flood the ipv6 multicast traffic,
because snooping cannot work.

This patch fixes the issue by adding a flag to the bridge struct that
indicates that there is currently no ipv6 address assinged to the bridge
and returns a false state for the local querier in
__br_multicast_querier_exists().

Special thanks to Linus L?ssing.

Signed-off-by: Daniel Danzberger <daniel at dd-wrt.com>
---

diff --git a/target/linux/generic/patches-4.4/646-bridge_fix_ipv6_mc_snooping_if_bridge_has_no_ipv6_address.patch b/target/linux/generic/patches-4.4/646-bridge_fix_ipv6_mc_snooping_if_bridge_has_no_ipv6_address.patch
new file mode 100644
index 0000000..4388cda
--- /dev/null
+++ b/target/linux/generic/patches-4.4/646-bridge_fix_ipv6_mc_snooping_if_bridge_has_no_ipv6_address.patch
@@ -0,0 +1,113 @@
+From: daniel <daniel at dd-wrt.com>
+Date: Fri, 24 Jun 2016 12:35:18 +0200
+Subject: [PATCH] Bridge: Fix ipv6 mc snooping if bridge has no ipv6 address
+
+The bridge is falsly dropping ipv6 mulitcast packets if there is:
+ 1. No ipv6 address assigned on the brigde.
+ 2. No external mld querier present.
+ 3. The internal querier enabled.
+
+When the bridge fails to build mld queries, because it has no
+ipv6 address, it slilently returns, but keeps the local querier enabled.
+This specific case causes confusing packet loss.
+
+Ipv6 multicast snooping can only work if:
+ a) An external querier is present
+ OR
+ b) The bridge has an ipv6 address an is capable of sending own queries
+
+Otherwise it has to forward/flood the ipv6 multicast traffic,
+because snooping cannot work.
+
+This patch fixes the issue by adding a flag to the bridge struct that
+indicates that there is currently no ipv6 address assinged to the bridge
+and returns a false state for the local querier in
+__br_multicast_querier_exists().
+
+Special thanks to Linus L?ssing.
+
+Fixes: d1d81d4c3dd8 ("bridge: check return value of ipv6_dev_get_saddr()")
+Signed-off-by: Daniel Danzberger <daniel at dd-wrt.com>
+Acked-by: Linus L?ssing <linus.luessing at c0d3.blue>
+Signed-off-by: David S. Miller <davem at davemloft.net>
+---
+ net/bridge/br_multicast.c |  4 ++++
+ net/bridge/br_private.h   | 23 +++++++++++++++++++----
+ 2 files changed, 23 insertions(+), 4 deletions(-)
+
+diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
+index c8c2a8a..d063a10 100644
+--- a/net/bridge/br_multicast.c
++++ b/net/bridge/br_multicast.c
+@@ -465,8 +465,11 @@ static struct sk_buff *br_ip6_multicast_alloc_query(struct net_bridge *br,
+ 	if (ipv6_dev_get_saddr(dev_net(br->dev), br->dev, &ip6h->daddr, 0,
+ 			       &ip6h->saddr)) {
+ 		kfree_skb(skb);
++		br->has_ipv6_addr = 0;
+ 		return NULL;
+ 	}
++
++	br->has_ipv6_addr = 1;
+ 	ipv6_eth_mc_map(&ip6h->daddr, eth->h_dest);
+ 
+ 	hopopt = (u8 *)(ip6h + 1);
+@@ -1768,6 +1771,7 @@ void br_multicast_init(struct net_bridge *br)
+ 	br->ip6_other_query.delay_time = 0;
+ 	br->ip6_querier.port = NULL;
+ #endif
++	br->has_ipv6_addr = 1;
+ 
+ 	spin_lock_init(&br->multicast_lock);
+ 	setup_timer(&br->multicast_router_timer,
+diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
+index e24abfd..3dd7e2c 100644
+--- a/net/bridge/br_private.h
++++ b/net/bridge/br_private.h
+@@ -303,6 +303,7 @@ struct net_bridge
+ 	u8				multicast_disabled:1;
+ 	u8				multicast_querier:1;
+ 	u8				multicast_query_use_ifaddr:1;
++	u8				has_ipv6_addr:1;
+ 
+ 	u32				hash_elasticity;
+ 	u32				hash_max;
+@@ -577,10 +578,22 @@ static inline bool br_multicast_is_router(struct net_bridge *br)
+ 
+ static inline bool
+ __br_multicast_querier_exists(struct net_bridge *br,
+-			      struct bridge_mcast_other_query *querier)
++				struct bridge_mcast_other_query *querier,
++				const bool is_ipv6)
+ {
++	bool own_querier_enabled;
++
++	if (br->multicast_querier) {
++		if (is_ipv6 && !br->has_ipv6_addr)
++			own_querier_enabled = false;
++		else
++			own_querier_enabled = true;
++	} else {
++		own_querier_enabled = false;
++	}
++
+ 	return time_is_before_jiffies(querier->delay_time) &&
+-	       (br->multicast_querier || timer_pending(&querier->timer));
++	       (own_querier_enabled || timer_pending(&querier->timer));
+ }
+ 
+ static inline bool br_multicast_querier_exists(struct net_bridge *br,
+@@ -588,10 +601,12 @@ static inline bool br_multicast_querier_exists(struct net_bridge *br,
+ {
+ 	switch (eth->h_proto) {
+ 	case (htons(ETH_P_IP)):
+-		return __br_multicast_querier_exists(br, &br->ip4_other_query);
++		return __br_multicast_querier_exists(br,
++			&br->ip4_other_query, false);
+ #if IS_ENABLED(CONFIG_IPV6)
+ 	case (htons(ETH_P_IPV6)):
+-		return __br_multicast_querier_exists(br, &br->ip6_other_query);
++		return __br_multicast_querier_exists(br,
++			&br->ip6_other_query, true);
+ #endif
+ 	default:
+ 		return false;
-- 
2.8.1



From nbd at nbd.name  Thu Jun 30 15:14:22 2016
From: nbd at nbd.name (Felix Fietkau)
Date: Fri, 1 Jul 2016 00:14:22 +0200
Subject: [LEDE-DEV] [PATCH] netifd: remove wireless device when device
 fails to setup
In-Reply-To: <57752A24.7020905@riverbed.com>
References: <57752A24.7020905@riverbed.com>
Message-ID: <8e7f2f39-8f08-6c71-3082-97039ac76211@nbd.name>

On 2016-06-30 16:18, Eduardo Abinader wrote:
> Ensure wireless device struct is removed, when it fails to be set up,
> due to a invalid configuration, hence enabling the wireless dev
> to be set up again, when a new valid configuration is set.
> 
> Signed-off-by: Eduardo Abinader <eduardo.abinader at riverbed.com>
> ---
>  wireless.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/wireless.c b/wireless.c
> index 34dd328..bc31d4a 100644
> --- a/wireless.c
> +++ b/wireless.c
> @@ -336,6 +336,10 @@ wireless_device_mark_down(struct wireless_device *wdev)
>  
>  	wireless_process_kill_all(wdev, SIGTERM, true);
>  
> +	if (wdev->state == IFS_SETUP && !wdev->autostart) {
> +		wdev->config_state = IFC_REMOVE;
> +	}
This doesn't make sense to me. Could you please provide a test case that
reproduces the problem you're trying to fix?

- Felix



From chunkeey at googlemail.com  Thu Jun 30 15:17:54 2016
From: chunkeey at googlemail.com (Christian Lamparter)
Date: Fri,  1 Jul 2016 00:17:54 +0200
Subject: [LEDE-DEV] [PATCH] prism54-firmware: change prism54/p54-firmware
	package versioning
Message-ID: <1467325074-30265-1-git-send-email-chunkeey@gmail.com>

There are multiple prism54/p54 firmware versions for different
drivers and devices. Therefore, assigning the package version
of all the different firmware packages on the old prism54
firmware could break if any of the p54 firmwares are updated
and we need to roll out new packages.

Signed-off-by: Christian Lamparter <chunkeey at gmail.com>
---
John and Hauke: How about this? I'm not an expert on LEDE packages.
I'm not sure if both PKG_RELEASE and PKG_VERSION needed an update
or not (I just want it so that the previous packages will be
updated with the new ones). I know that for example "base-files"
only needs PKG_RELEASE, so I'm not sure if PKG_VERSION is
actually needed or not.

So yes: Please fix this (or tell me what to do and more
importantly: tell me what (PKG_VERSION or PKG_RELEASE)
takes precedence over the other and why so?.

Regards,
Christian
---
 package/firmware/prism54-firmware/Makefile | 22 +++++++++++++---------
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/package/firmware/prism54-firmware/Makefile b/package/firmware/prism54-firmware/Makefile
index 32bd289..0aaad62 100644
--- a/package/firmware/prism54-firmware/Makefile
+++ b/package/firmware/prism54-firmware/Makefile
@@ -6,24 +6,28 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=prism54-firmware
-PKG_VERSION:=1.0.4.3
-PKG_RELEASE:=1
-
-PRG_URL:=https://daemonizer.de/prism54/prism54-fw/
+PKG_VERSION:=2.0.0.0
+PKG_RELEASE:=2
 
 # Prism54 FullMAC firmware (jbnore.free.fr seems to be rather slow, so we use daemonizer.de)
-PKG_SOURCE:=$(PKG_VERSION).arm
-PKG_SOURCE_URL:=$(PRG_URL)/fw-fullmac/
-PKG_MD5SUM:=8bd4310971772a486b9784c77f8a6df9
+PRG_URL:=https://daemonizer.de/prism54/prism54-fw/
 
 include $(INCLUDE_DIR)/package.mk
 
 
-# Prism54 drivers
+# PRISM54/P54 firmwares
+PRISM54FW:=1.0.4.3.arm
 P54USBFW:=2.13.24.0.lm87.arm
 P54PCIFW:=2.13.12.0.arm
 P54SPIFW:=2.13.0.0.a.13.14.arm
 
+define Download/prism54-firmware
+  FILE:=$(PRISM54FW)
+  URL:=$(PRG_URL)/fw-fullmac
+  MD5SUM:=8bd4310971772a486b9784c77f8a6df9
+endef
+$(eval $(call Download,prism54-firmware))
+
 define Download/p54-usb-firmware
   FILE:=$(P54USBFW)
   URL:=$(PRG_URL)/fw-usb
@@ -83,7 +87,7 @@ endef
 
 define Package/prism54-firmware/install
 	$(INSTALL_DIR) $(1)/lib/firmware
-	$(INSTALL_DATA) $(DL_DIR)/$(PKG_SOURCE) $(1)/lib/firmware/isl3890
+	$(INSTALL_DATA) $(DL_DIR)/$(PRISM54FW) $(1)/lib/firmware/isl3890
 endef
 
 define Package/p54-usb-firmware/install
-- 
2.8.1



From john at phrozen.org  Thu Jun 30 22:38:15 2016
From: john at phrozen.org (John Crispin)
Date: Fri, 1 Jul 2016 07:38:15 +0200
Subject: [LEDE-DEV] [ubox] remove unnecessary size struct between
	messages
In-Reply-To: <1465294276-15925-1-git-send-email-danutbug@gmail.com>
References: <1465294276-15925-1-git-send-email-danutbug@gmail.com>
Message-ID: <9bc32fca-d19c-e015-f21f-87327ed0b62e@phrozen.org>



On 07/06/2016 12:11, Dan Bugnar wrote:
> From: Dan Bugnar <dnbugnar at ocedo.com>
> 
> The next message needs to be written after the data of current message.
> This was adding "sizeof(struct log_head)" bytes between messages.
> 
> Signed-off-by: Dan Bugnar <danutbug at gmail.com>

coming back to these patches, i fail to see why you remove the padding.
this will guarantee that struct log_head pointers are always 4 byte
aligned, thus preventing unaligned accesses from happening. imho the
code should nt be changed, it is there for a reason.

	John

> ---
>  log/syslog.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/log/syslog.c b/log/syslog.c
> index e8b6774..2042e93 100644
> --- a/log/syslog.c
> +++ b/log/syslog.c
> @@ -51,7 +51,7 @@ static regex_t pat_tstamp;
>  static struct log_head*
>  log_next(struct log_head *h, int size)
>  {
> -	struct log_head *n = (struct log_head *) &h->data[PAD(sizeof(struct log_head) + size)];
> +	struct log_head *n = (struct log_head *) &h->data[size];
>  
>  	return (n >= log_end) ? (log) : (n);
>  }
> 


From juvanham.tc at gmail.com  Thu Jun 30 23:45:22 2016
From: juvanham.tc at gmail.com (Jurgen Van Ham)
Date: Fri, 1 Jul 2016 08:45:22 +0200
Subject: [LEDE-DEV] Procd instance pidfiles remain after daemon dies
	unexpectedly
Message-ID: <CALxZQ2Oo_c+ZLBaWuzZTFBHO4f-iWwn77pKLDuum-1WRx4ziGA@mail.gmail.com>

Dear all,

Procd supports instance_writepid and instance_removepid in the file instance.c.
The removepid is called when stopping a daemon or restarting it.
However, when a daemon
dies and it is not configured to respawn the pidfile is not removed.


When other daemon watch the pidfile because they rely on the daemon
they cannot rely to stop when the pidfile disappears.  This other
daemon cannot just continue after procd would respawn the died daemon.
Before restarting the procd managed daemon, the depending daemons need
to stop.

Would a fix in the function instance_exit be the right solution to
remove the pid after dying without a configured respawn?
Is there a reason to keep a pidfile after a daemon terminates without
any procd request.

regards,


From augustus_meyer at yahoo.de  Thu Jun 30 04:49:49 2016
From: augustus_meyer at yahoo.de (reiner otto)
Date: Thu, 30 Jun 2016 11:49:49 +0000 (UTC)
Subject: [LEDE-DEV] sysupgrade weakness
References: <1796646707.6886347.1467287389175.JavaMail.yahoo.ref@mail.yahoo.com>
Message-ID: <1796646707.6886347.1467287389175.JavaMail.yahoo@mail.yahoo.com>

sysupgrade is "weak", when having to kill user processes before flashing. Having spent several hours, to figure out, why only a reboot was done, I recognized, that sysupgrade "promises" to kill my private running processes, but does not succeed in doing so. Manual "kill -9 ..." before running sysupgrade fixed the issue.
At least, it might be a good idea for sysupgrade to give a warning, in case killing the processes does not succeed, to have a clue.


