date:20160311

Re: [OpenWrt-Devel] [PATCH v3] brcmfmac: Add Raspberry Pi 3 support

2016-03-11 Thread Rafał Miłecki

On 11 March 2016 at 20:19, Álvaro Fernández Rojas  wrote:
> - Enable SDIO support on brcmfmac.
> - Disable power managment for brcm2708 target.
>
> Signed-off-by: Álvaro Fernández Rojas 
> ---
>  v3: fix ifdef mistake
>  v2: use a proper patch prefix

Reviewed-by: Rafał Miłecki 

Thanks Álvaro!
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2] ramips: Add support for Xiaomi MiWiFi Nano

2016-03-11 Thread Noble Pepper

Xiaomi MiWiFi Nano is based on Mediatek MT7628 with 64MB ram 16MB flash

Signed-off-by: Noble Pepper 

v2 includes changes suggested by L. D. Pinney-
Eliminate en25q64 (4MB) flash chip
Remove miwifi-nano from images built when Default Profile is chosen
Alphabetization
---
 package/boot/uboot-envtools/files/ramips   |  3 +-
 .../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/MIWIFI-NANO.dts| 70 ++
 target/linux/ramips/image/Makefile |  4 ++
 target/linux/ramips/mt7628/profiles/miwifinano.mk  | 18 ++
 7 files changed, 99 insertions(+), 1 deletion(-)
 create mode 100644 target/linux/ramips/dts/MIWIFI-NANO.dts
 create mode 100644 target/linux/ramips/mt7628/profiles/miwifinano.mk

diff --git a/package/boot/uboot-envtools/files/ramips 
b/package/boot/uboot-envtools/files/ramips
index 53cf9d3..a759bcc 100644
--- a/package/boot/uboot-envtools/files/ramips
+++ b/package/boot/uboot-envtools/files/ramips
@@ -23,7 +23,8 @@ linkits7688 | \
 linkits7688d | \
 wsr-600 | \
 wsr-1166 | \
-br6425)
+br6425 | \
+miwifi-nano)
ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x1000" "0x1"
;;
 esac
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 dc9b5b2..4b65d36 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -68,6 +68,7 @@ ramips_setup_interfaces()
firewrt|\
hlk-rm04|\
miwifi-mini|\
+   miwifi-nano|\
mt7621|\
mt7628|\
mzk-750dhp|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index 815765a..6abda92 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -250,6 +250,9 @@ ramips_board_detect() {
*"MiWiFi Mini")
name="miwifi-mini"
;;
+   *"MiWiFi-Nano")
+   name="miwifi-nano"
+   ;;
*"MLW221")
name="mlw221"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index b1d2347..c329dce 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -78,6 +78,7 @@ platform_check_image() {
miniembplug|\
miniembwifi|\
miwifi-mini|\
+   miwifi-nano|\
mlw221|\
mlwg2|\
mofi3500-3gn|\
diff --git a/target/linux/ramips/dts/MIWIFI-NANO.dts 
b/target/linux/ramips/dts/MIWIFI-NANO.dts
new file mode 100644
index 000..9f1d027
--- /dev/null
+++ b/target/linux/ramips/dts/MIWIFI-NANO.dts
@@ -0,0 +1,70 @@
+/dts-v1/;
+
+/include/ "mt7628an.dtsi"
+
+/ {
+   compatible = "xiaomi,MiWifi Nano", "mediatek,mt7628an-soc";
+   model = "MiWiFi-Nano";
+
+   chosen {
+   bootargs = "console=ttyS0,115200";
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x400>;
+   };
+
+   pinctrl {
+   state_default: pinctrl0 {
+   gpio {
+   ralink,group = "i2c", "jtag";
+   ralink,function = "gpio";
+   };
+   };
+   };
+
+
+   wmac@1030 {
+   status = "okay";
+   };
+
+   palmbus@1000 {
+   spi@b00 {
+   status = "okay";
+
+   m25p80@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "jedec,spi-nor";
+   reg = <0 0>;
+   linux,modalias = "m25p80";
+   spi-max-frequency = <1000>;
+   m25p,chunked-io = <32>;
+
+   partition@0 {
+   label = "u-boot";
+   reg = <0x0 0x3>;
+   read-only;
+   };
+
+   partition@3 {
+   label = "u-boot-env";
+   reg = <0x3 0x1>;
+   read-only;
+   };
+
+   factory: partition@4 {
+   label = "factory";
+   reg = <0x4 0x1>;
+   read-only;
+   };
+
+

[OpenWrt-Devel] netfilter.mk: how do I identify which kernel is being built?

2016-03-11 Thread Mauro Mozzarelli

I would like to modify dynamically the modules being built depending on the 
kernel
version. I thought I could build KCONFIG using ifeq. But I cannot find anything
that I can use to determine which kernel is being built.

So far I tried:

ifeq ($(call kernel_patchver_gt,4.0.0),1)   # does not work
ifeq ($(strip $(call CompareKernelPatchVer,$(KERNEL_PATCHVER),eq,4.1.16)),1) # 
does not
work
ifeq ($(strip $(call CompareKernelPatchVer,$(KERNEL_PATCHVER),eq,3.18.27)),1) # 
does not
work either

I tried also looking into some variable:

KERNEL_PATCHVER=""  # always empty
LINUX_VERSION=   # useless

Any suggestion?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v3] brcmfmac: Add Raspberry Pi 3 support

2016-03-11 Thread Álvaro Fernández Rojas

- Enable SDIO support on brcmfmac.
- Disable power managment for brcm2708 target.

Signed-off-by: Álvaro Fernández Rojas 
---
 v3: fix ifdef mistake
 v2: use a proper patch prefix

 package/kernel/mac80211/Makefile   |  1 +
 .../863-brcmfmac-Disable-power-management.patch| 27 ++
 .../brcm2708/bcm2710/profiles/RaspberryPi3.mk  |  1 +
 3 files changed, 29 insertions(+)
 create mode 100644 
package/kernel/mac80211/patches/863-brcmfmac-Disable-power-management.patch

diff --git a/package/kernel/mac80211/Makefile b/package/kernel/mac80211/Makefile
index e65cf2a..13a07ae 100644
--- a/package/kernel/mac80211/Makefile
+++ b/package/kernel/mac80211/Makefile
@@ -673,6 +673,7 @@ define KernelPackage/brcmfmac/config
 
config BRCMFMAC_SDIO
bool "Enable SDIO bus interface support"
+   default y if TARGET_brcm2708
default n
help
  Enable support for cards attached to an SDIO bus.
diff --git 
a/package/kernel/mac80211/patches/863-brcmfmac-Disable-power-management.patch 
b/package/kernel/mac80211/patches/863-brcmfmac-Disable-power-management.patch
new file mode 100644
index 000..1615202
--- /dev/null
+++ 
b/package/kernel/mac80211/patches/863-brcmfmac-Disable-power-management.patch
@@ -0,0 +1,27 @@
+From 66ae1b1750720a33e29792a177b1e696f4f005fb Mon Sep 17 00:00:00 2001
+From: Phil Elwell 
+Date: Wed, 9 Mar 2016 17:25:59 +
+Subject: [PATCH] brcmfmac: Disable power management
+
+Disable wireless power saving in the brcmfmac WLAN driver. This is a
+temporary measure until the connectivity loss resulting from power
+saving is resolved.
+
+Signed-off-by: Phil Elwell 
+---
+ drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
 b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+@@ -2651,6 +2651,10 @@ brcmf_cfg80211_set_power_mgmt(struct wip
+* preference in cfg struct to apply this to
+* FW later while initializing the dongle
+*/
++#if defined(CONFIG_BCM2708) || defined(CONFIG_BCM2709)
++  pr_info("power management disabled\n");
++  enabled = false;
++#endif
+   cfg->pwr_save = enabled;
+   if (!check_vif_up(ifp->vif)) {
+ 
diff --git a/target/linux/brcm2708/bcm2710/profiles/RaspberryPi3.mk 
b/target/linux/brcm2708/bcm2710/profiles/RaspberryPi3.mk
index 251a8b5..a20e225 100644
--- a/target/linux/brcm2708/bcm2710/profiles/RaspberryPi3.mk
+++ b/target/linux/brcm2708/bcm2710/profiles/RaspberryPi3.mk
@@ -7,6 +7,7 @@
 
 define Profile/RaspberryPi_3
   NAME:=Raspberry Pi 3 Model B
+  PACKAGES:=kmod-brcmfmac wpad-mini
 endef
 define Profile/RaspberryPi_3/Description
   Raspberry Pi 3 Model B
-- 
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v3] ipvs: Linux IP Virtual Server kernel modules (netfilter.mk patch)

2016-03-11 Thread Mauro Mozzarelli

I am trying to find the syntax by reverse engineering the mk files I find, but 
I cannot
find enough options. So I need some help.

So far I have seen full linux versions like LINUX_4_1 or LINUX_4_4.

What if the rule applies to all linux 4.* or linux 3.*?
Can I use LINUX_4 or LINUX_4_X (guessing as in here
https://wiki.openwrt.org/doc/devel/packages)

What does @! mean before LINUX_4_4 ?

Is it advisable to create two different packages, one for kernel 3 and one for 
kernel 4
or is there a more clever way to manipulate KCONFIG and IPVS_MODULE variables 
depending
on the kernel version?

Thank you

On Fri, March 11, 2016 17:20, Martin Blumenstingl wrote:
>> The ftp module is in kernel 3, but not in kernel 4 for which the patch was 
>> built.
>> Is there a way to include modules conditionally dependent on the kernel 
>> version?
> sure, you can either exclude .ko files from the package/AUTOLOAD (see
> [0]) or make a whole package depend on specific kernel versions (see
> [1]).
>
>
> [0] 
> https://dev.openwrt.org/browser/trunk/package/kernel/linux/modules/crypto.mk#L111
> [1] 
> https://dev.openwrt.org/browser/trunk/package/kernel/linux/modules/crypto.mk#L30
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v3] ipvs: Linux IP Virtual Server kernel modules (netfilter.mk patch)

2016-03-11 Thread Martin Blumenstingl

> The ftp module is in kernel 3, but not in kernel 4 for which the patch was 
> built.
> Is there a way to include modules conditionally dependent on the kernel 
> version?
sure, you can either exclude .ko files from the package/AUTOLOAD (see
[0]) or make a whole package depend on specific kernel versions (see
[1]).


[0] 
https://dev.openwrt.org/browser/trunk/package/kernel/linux/modules/crypto.mk#L111
[1] 
https://dev.openwrt.org/browser/trunk/package/kernel/linux/modules/crypto.mk#L30
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v3] ipvs: Linux IP Virtual Server kernel modules (netfilter.mk patch)

2016-03-11 Thread Mauro Mozzarelli

Ooops!

The ftp module is in kernel 3, but not in kernel 4 for which the patch was 
built.
Is there a way to include modules conditionally dependent on the kernel version?

On Fri, March 11, 2016 12:45, Jo-Philipp Wich wrote:
> Hi,
>
> seems that change fails all builds now due to undeclared symbols:
>
>   *
>   * IPVS application helper
>   *
>   FTP protocol helper (IP_VS_FTP) [N/m/?] (NEW) aborted!
>
>
> Please fix.
>
> ~ Jow
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ARMv4 (not v4t) marked obsolete in gcc-6

2016-03-11 Thread Hans Ulli Kroll

HI

On Fri, 11 Mar 2016, Roman Yeryomin wrote:

> On 2016-03-11 08:48, John Crispin wrote:
> > On 11/03/2016 06:44, Hans Ulli Kroll wrote:
> > > Hi
> > > > 
> > > > * Gemini: officially supported in OpenWRT today, with the latest
> > > > compiler. This one
> > > >   will likely cause the most issues for actual users. It would be
> > > > helpful to get
> > > >   some numbers about users or downloads here, to see whether it can be
> > > > dropped
> > > >   in a future OpenWRT release or if it might be possible to leave this
> > > > on
> > > >   gcc-6.x when the other platforms move on to gcc-7+
> > > 
> > > I don't have any numbers from the OPenWRT people.
> > > For the NAS BOXes itself, I get one/two support questions a month on the
> > > german based forum.
> > > I think most people know about the SATA bug, which makes the platform
> > > unreliable for some SATA drives.
> > > y
> > > Hans Ulli
> > 
> > Hi,
> > 
> > We have several active users. Roman has done a great job to constantly
> > maintain and update the target. We have been including gemini in our
> > releases for years thanks to Romans effort. It would be a shame to to
> > see support being dropped, even if there are few yet active users.
> >
> 
> Thanks, John.
> I'm actively using it as a backup box and know at least several other people.
> Although it's quite old I can't stop using it, it serves well for me and I
> don't see any reason to throw it out.
> I've heard of SATA problems but never seen them myself.

The SATA bug occurs first on Samsung devices. 
I bought a HDD to test this by my self and check if it's possible to fix. 
There are some 'hidden' registers to tweak to PATA controller, the 
names can be found in the PATA header from the original sources.
No avail !
So I asked Paulius sometime ago about this and the PATA/SATA mux, he has 
also no clue for fixing this.

> As to the numbers I think that people like me (or others trying out OpenWrt)
> usually don't go to the forums, so number of questions there doesn't tell much
> (but even there latest messages are from last month, so not dead at all).
> Maybe number of downloads from downloads.openwrt.org can tell more but I would
> guess that actual users would rather compile it themselves.

The support thread on the german board is very long, so most of the 
questions are answered there. The experienced don't need this, so the 
numbers *are* wrong.

And I'm using two of the NAS boxes for backup and another for kernel work

> So I vote for not killing it at least until it's supported by kernel.
> 

ACK !!

Hans Ulli
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2] fstools: support for ext4fs overlay

2016-03-11 Thread Ram Chandra Jangir

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 
---

change in v2:
fixed space indentation
removed mkfs.ext4 code of lines
Added volume type enum EXT4VOLUME
---

 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 000..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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#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_OFF0x38
+
+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, ) < 0)
+   return -1;
+
+   for (i = 0; i < gl.gl_pathc; i++) {
+   if (!ext4_part_match(dev, name, gl.gl_pathv[i])) {
+   globfree();
+   return 0;
+   }
+   }
+
+   globfree();
+   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

[OpenWrt-Devel] [PATCH] ramips: Add support for Xiaomi MiWiFi Nano

2016-03-11 Thread Noble Pepper

Xiaomi MiWiFi Nano is based on Mediatek MT7628 with 64MB ram 16 MB flash

Signed-off-by: Noble Pepper 
---
 package/boot/uboot-envtools/files/ramips   |  3 +-
 .../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/MIWIFI-NANO.dts| 70 ++
 target/linux/ramips/image/Makefile |  5 ++
 target/linux/ramips/mt7628/profiles/miwifinano.mk  | 18 ++
 7 files changed, 100 insertions(+), 1 deletion(-)
 create mode 100644 target/linux/ramips/dts/MIWIFI-NANO.dts
 create mode 100644 target/linux/ramips/mt7628/profiles/miwifinano.mk

diff --git a/package/boot/uboot-envtools/files/ramips 
b/package/boot/uboot-envtools/files/ramips
index 53cf9d3..a759bcc 100644
--- a/package/boot/uboot-envtools/files/ramips
+++ b/package/boot/uboot-envtools/files/ramips
@@ -23,7 +23,8 @@ linkits7688 | \
 linkits7688d | \
 wsr-600 | \
 wsr-1166 | \
-br6425)
+br6425 | \
+miwifi-nano)
ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x1000" "0x1"
;;
 esac
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 dc9b5b2..4b65d36 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -68,6 +68,7 @@ ramips_setup_interfaces()
firewrt|\
hlk-rm04|\
miwifi-mini|\
+   miwifi-nano|\
mt7621|\
mt7628|\
mzk-750dhp|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index 815765a..6abda92 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -250,6 +250,9 @@ ramips_board_detect() {
*"MiWiFi Mini")
name="miwifi-mini"
;;
+   *"MiWiFi-Nano")
+   name="miwifi-nano"
+   ;;
*"MLW221")
name="mlw221"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index b1d2347..c329dce 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -78,6 +78,7 @@ platform_check_image() {
miniembplug|\
miniembwifi|\
miwifi-mini|\
+   miwifi-nano|\
mlw221|\
mlwg2|\
mofi3500-3gn|\
diff --git a/target/linux/ramips/dts/MIWIFI-NANO.dts 
b/target/linux/ramips/dts/MIWIFI-NANO.dts
new file mode 100644
index 000..0938ec8
--- /dev/null
+++ b/target/linux/ramips/dts/MIWIFI-NANO.dts
@@ -0,0 +1,70 @@
+/dts-v1/;
+
+/include/ "mt7628an.dtsi"
+
+/ {
+   compatible = "xiaomi,MiWifi Nano", "mediatek,mt7628an-soc";
+   model = "MiWiFi-Nano";
+
+   chosen {
+   bootargs = "console=ttyS0,115200";
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x400>;
+   };
+
+   pinctrl {
+   state_default: pinctrl0 {
+   gpio {
+   ralink,group = "i2c", "jtag";
+   ralink,function = "gpio";
+   };
+   };
+   };
+
+
+   wmac@1030 {
+   status = "okay";
+   };
+
+   palmbus@1000 {
+   spi@b00 {
+   status = "okay";
+
+   m25p80@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "jedec,spi-nor";
+   reg = <0 0>;
+   linux,modalias = "m25p80", "en25q64";
+   spi-max-frequency = <1000>;
+   m25p,chunked-io = <32>;
+
+   partition@0 {
+   label = "u-boot";
+   reg = <0x0 0x3>;
+   read-only;
+   };
+
+   partition@3 {
+   label = "u-boot-env";
+   reg = <0x3 0x1>;
+   read-only;
+   };
+
+   factory: partition@4 {
+   label = "factory";
+   reg = <0x4 0x1>;
+   read-only;
+   };
+
+   partition@5 {
+   label = "firmware";
+   reg = <0x5

Re: [OpenWrt-Devel] Which image for the Nanostation Loco M2, WAS:Cannot flash UBNT Loco M2

2016-03-11 Thread Matthias Schiffer

On 03/11/2016 05:15 PM, Aaron Z wrote:
>  )On Fri, Mar 11, 2016 at 9:28 AM, Matthias Schiffer
>  wrote:
>> PS. Completely unrelated to this issue: I noticed in your log that you used
>> the wrong image ("nanostation" instead of "bullet") for your Loco. This
>> isn't really an issue, as the nanostation and bullet images only differ by
>> the number of ethernet ports they define, but you'll have a dead "eth1"
>> device. The image "nanostation" should used for the NanoStation (as it is
>> the only device with two ethernet ports), and "bullet" for everything from
>> the AirMax XM series except NanoStation and Rocket (Bullet, Loco,
>> PicoStation, ...)
> So, which should be used for the Nanostation Loco M2 (
> http://www.amazon.com/Ubiquiti-NanoStation-locoM2-2-4GHz-Outdoor/dp/B004EGI3CI/
> ) which has one Ethernet port?
> The one I have is an older (non-XW) device. For CC, I see:
> openwrt-15.05-ar71xx-generic-ubnt-bullet-m-squashfs-sysupgrade.bin and
> openwrt-15.05-ar71xx-generic-ubnt-nano-m-squashfs-sysupgrade.bin
> I had used the nano build, but it has a non-functional eth1 port.
> 
> Aaron Z

As I wrote, "bullet" is the correct image for all XM devices with one
ethernet port and no USB.

Matthias




signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Which image for the Nanostation Loco M2, WAS:Cannot flash UBNT Loco M2

2016-03-11 Thread Aaron Z

 )On Fri, Mar 11, 2016 at 9:28 AM, Matthias Schiffer
 wrote:
> PS. Completely unrelated to this issue: I noticed in your log that you used
> the wrong image ("nanostation" instead of "bullet") for your Loco. This
> isn't really an issue, as the nanostation and bullet images only differ by
> the number of ethernet ports they define, but you'll have a dead "eth1"
> device. The image "nanostation" should used for the NanoStation (as it is
> the only device with two ethernet ports), and "bullet" for everything from
> the AirMax XM series except NanoStation and Rocket (Bullet, Loco,
> PicoStation, ...)
So, which should be used for the Nanostation Loco M2 (
http://www.amazon.com/Ubiquiti-NanoStation-locoM2-2-4GHz-Outdoor/dp/B004EGI3CI/
) which has one Ethernet port?
The one I have is an older (non-XW) device. For CC, I see:
openwrt-15.05-ar71xx-generic-ubnt-bullet-m-squashfs-sysupgrade.bin and
openwrt-15.05-ar71xx-generic-ubnt-nano-m-squashfs-sysupgrade.bin
I had used the nano build, but it has a non-functional eth1 port.

Aaron Z
A human being should be able to change a diaper, plan an invasion,
butcher a hog, conn a ship, design a building, write a sonnet, balance
accounts, build a wall, set a bone, comfort the dying, take orders,
give orders, cooperate, act alone, solve equations, analyze a new
problem, pitch manure, program a computer, cook a tasty meal, fight
efficiently, die gallantly. Specialization is for insects.
— Robert Heinlein, Time Enough for Love
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v3] ipvs: Linux IP Virtual Server kernel modules (netfilter.mk patch)

2016-03-11 Thread John Crispin



On 11/03/2016 15:24, John Crispin wrote:
> 
> 
> On 11/03/2016 13:45, Jo-Philipp Wich wrote:
>> Hi,
>>
>> seems that change fails all builds now due to undeclared symbols:
>>
>>   *
>>   * IPVS application helper
>>   *
>>   FTP protocol helper (IP_VS_FTP) [N/m/?] (NEW) aborted!
>>
>>
>> Please fix.
>>
>> ~ Jow
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>
> 
> 
> grmlnarf, cant be bothered with the endless discussions. i'll fix it
> now, patch coming up.
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 

ok, it was already removed, please resend a working version that was
tested with CONFIG_ALL enabled.

John
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Cannot flash UBNT Loco M2

2016-03-11 Thread Matthias Schiffer

On 03/11/2016 02:46 PM, Joseph Marlin wrote:
> We certainly haven't. I've tried applying these patches - 
> http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/39001
> 
> to no avail. I still get hit by a "Error code 2 - Firmware Check Failed". 
> 
> I'm really suspecting this comes down to an intentional check by Ubiquiti to 
> prevent us from flashing, as described on this list and in this comment on 
> the ticket - https://dev.openwrt.org/ticket/20982#comment:16
> 
> I have not yet had a chance to change the image header and CRC to look like a 
> Ubiquiti image, nor do I know how to offhand, but I hope to give it a shot 
> soon.

Hi,
there is a lot of misinformation about this issue going around, in
particular, the wiki is plain wrong (I'll fix that some time soon.)

Here's what's going on:

* OpenWrt had wrong partition sizes in its UBNT AirMax firmware for a long time
* Old AirOS and the corresponding U-boot version had a bug that made U-boot
ignore the partition sizes defined in the firmware image. This made OpenWrt
work with the old U-boot despite its broken partition sizes
* The new AirOS has been fixed in this regard (but contains a new bug).
This also means that the broken OpenWrt images don't work anymore and can
cause even more breakage
* The new U-boot/AirOS did *not* change the flash layout. Both AirOS 5.5.x
and 5.6.x use the same flash layout, the changed flash layout reported in
the wiki is caused by broken OpenWrt images!
* The OpenWrt trunk since r48829 and the CC branch since r48849 are fixed,
meaning they define the correct partition sizes
* The "Newly-erased block contained word ..." messages are a consequence of
a missing patch in CC that has been backported as r48849 (the new U-boot
doesn't remove flash protection, so the flash is just read-only from
OpenWrt; TFTP recovery is the only way to upgrade in this state)
* AFAIR "Error code 2 - Firmware Check Failed" is the consequence of a bug
in the new U-boot: after flashing an image with broken (smaller) partition
sizes, the recovery doesn't accept images with the original partition sizes
anymore

Getting out of this state is not easy: you have a U-boot on your device
that doesn't accept correct images, and an OpenWrt version that doesn't
allow writing to the flash.

Through a serial console, you can try fixing the settings in U-boot; when I
tried this the last time, I wasn't able to do so, but maybe I did something
wrong. The U-boot console has a few interesting settings (I forgot the
exact commands, but the "help" command should tell you everything you need
to know):

* You can reset the MTD layout to the defaults. This makes the recovery
accept correct images again. Unfortunately, in my experiments, this setting
was not permanent even when I saves the environment after resetting the
layout. In the hindsight, I remember there being a setting to disable flash
protection, maybe that would made have the environment saving effective.

In the end, I fixed this by creating a patched OpenWrt image that allowed
me to write to the uboot and uboot-env partitions; this allowed me to write
back backups I had made of the uboot and uboot-env before I broke the flash
layout by flashing OpenWrt. Obviously, this does not work if you don't have
backups...

* If you don't plan to ever go back to AirOS again, it might be okay to
just ignore the broken MTD layout in the U-boot settings. Get into the
U-boot console, reset the MTD layout, start recovery, and flash an OpenWrt
version after trunk r48829 or CC r48849.

I hope this helps. I'd be interested if you find a way to parmanently reset
the MTD layout from the U-boot console; unfortunately, I don't have a test
device available at the moment.

Regards,
Matthias

PS. Completely unrelated to this issue: I noticed in your log that you used
the wrong image ("nanostation" instead of "bullet") for your Loco. This
isn't really an issue, as the nanostation and bullet images only differ by
the number of ethernet ports they define, but you'll have a dead "eth1"
device. The image "nanostation" should used for the NanoStation (as it is
the only device with two ethernet ports), and "bullet" for everything from
the AirMax XM series except NanoStation and Rocket (Bullet, Loco,
PicoStation, ...)

> 
> - Original Message -
> From: "Outback Dingo" 
> To: "Joseph Marlin" 
> Cc: "Bill Moffitt" , openwrt-devel@lists.openwrt.org
> Sent: Friday, March 11, 2016 6:22:39 AM
> Subject: Re: [OpenWrt-Devel] Cannot flash UBNT Loco M2
> 
> so, have we gotten past the ubiquiti bootloader downgrade issues yet ?
> 
> On Fri, Feb 12, 2016 at 11:09 PM, Joseph Marlin 
> wrote:
> 
>> Yes, we've been fighting this bug unsuccessfully for quite a while. It's
>> the result of a new version of uboot changing the partition sizes.
>>
>> Here's the ticket: https://dev.openwrt.org/ticket/20982
>>
>>
>>
>> - Original Message -
>>

Re: [OpenWrt-Devel] [PATCH v3] ipvs: Linux IP Virtual Server kernel modules (netfilter.mk patch)

2016-03-11 Thread John Crispin

On 11/03/2016 13:45, Jo-Philipp Wich wrote:
> Hi,
> 
> seems that change fails all builds now due to undeclared symbols:
> 
>   *
>   * IPVS application helper
>   *
>   FTP protocol helper (IP_VS_FTP) [N/m/?] (NEW) aborted!
> 
> 
> Please fix.
> 
> ~ Jow
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 

grmlnarf, cant be bothered with the endless discussions. i'll fix it
now, patch coming up.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Cannot flash UBNT Loco M2

2016-03-11 Thread Joseph Marlin

We certainly haven't. I've tried applying these patches - 
http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/39001

to no avail. I still get hit by a "Error code 2 - Firmware Check Failed". 

I'm really suspecting this comes down to an intentional check by Ubiquiti to 
prevent us from flashing, as described on this list and in this comment on the 
ticket - https://dev.openwrt.org/ticket/20982#comment:16

I have not yet had a chance to change the image header and CRC to look like a 
Ubiquiti image, nor do I know how to offhand, but I hope to give it a shot soon.

- Original Message -
From: "Outback Dingo" 
To: "Joseph Marlin" 
Cc: "Bill Moffitt" , openwrt-devel@lists.openwrt.org
Sent: Friday, March 11, 2016 6:22:39 AM
Subject: Re: [OpenWrt-Devel] Cannot flash UBNT Loco M2

so, have we gotten past the ubiquiti bootloader downgrade issues yet ?

On Fri, Feb 12, 2016 at 11:09 PM, Joseph Marlin 
wrote:

> Yes, we've been fighting this bug unsuccessfully for quite a while. It's
> the result of a new version of uboot changing the partition sizes.
>
> Here's the ticket: https://dev.openwrt.org/ticket/20982
>
>
>
> - Original Message -
> From: "Outback Dingo" 
> To: "Bill Moffitt" 
> Cc: openwrt-devel@lists.openwrt.org
> Sent: Friday, February 12, 2016 5:00:38 PM
> Subject: Re: [OpenWrt-Devel] Cannot flash UBNT Loco M2
>
>
>
> On Fri, Feb 12, 2016 at 10:54 PM, Bill Moffitt < bmoff...@ayrstone.com >
> wrote:
>
>
> I got a new batch of LocoM2 units, and they won't flash using the
> "recovery" (tftp) method - it says,
>
> received ERROR

Re: [OpenWrt-Devel] [PATCH v3] ipvs: Linux IP Virtual Server kernel modules (netfilter.mk patch)

2016-03-11 Thread Jo-Philipp Wich

Hi,

seems that change fails all builds now due to undeclared symbols:

  *
  * IPVS application helper
  *
  FTP protocol helper (IP_VS_FTP) [N/m/?] (NEW) aborted!


Please fix.

~ Jow
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Cannot flash UBNT Loco M2

2016-03-11 Thread Outback Dingo

so, have we gotten past the ubiquiti bootloader downgrade issues yet ?

On Fri, Feb 12, 2016 at 11:09 PM, Joseph Marlin 
wrote:

> Yes, we've been fighting this bug unsuccessfully for quite a while. It's
> the result of a new version of uboot changing the partition sizes.
>
> Here's the ticket: https://dev.openwrt.org/ticket/20982
>
>
>
> - Original Message -
> From: "Outback Dingo" 
> To: "Bill Moffitt" 
> Cc: openwrt-devel@lists.openwrt.org
> Sent: Friday, February 12, 2016 5:00:38 PM
> Subject: Re: [OpenWrt-Devel] Cannot flash UBNT Loco M2
>
>
>
> On Fri, Feb 12, 2016 at 10:54 PM, Bill Moffitt < bmoff...@ayrstone.com >
> wrote:
>
>
> I got a new batch of LocoM2 units, and they won't flash using the
> "recovery" (tftp) method - it says,
>
> received ERROR

Re: [OpenWrt-Devel] Question regarding call python script

2016-03-11 Thread Bastian Bittorf

* Paul Fertser  [11.03.2016 11:15]:
> As a sidenote, POSIX shell doesn't support associative arrays (which
> were mentioned in this thread), so it's probably worth clarifying
> whether it's ok to require bash >= 4 for OpenWrt build scripts or not.

yes, POSIX is "missing" some goodies of a full bash but:

"Stick to portable constructs where possible, and
 you will make somebody's life easier in the future.
 Maybe your own."

For all things you can use a workaround.
So, if you need an array e.g.

foo[7]=bar

for e.g. easy iterating over it? use e.g. this approach:

array_put()
{
local message="$1"
local dim1="$2"
local dim2="$3"

eval ${ARRAYNAME:-default}_${dim1}_${dim2}='$message'
}

array_get()
{
local dim1="$1"
local dim2="$2"
local var

eval var="\"\${${ARRAYNAME:-default}_${dim1}_${dim2}:-unset}\""
echo "$var"
}

array_set "test" 7
array_get 7

or for 2-dimensional arrays:
array_set "2dim" 3 14
array_get 3 14

you can simplify this by removing dim2 and ARRAYNAME if this is too much.

bye, bastian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Question regarding call python script

2016-03-11 Thread Paul Fertser

On Fri, Mar 11, 2016 at 08:37:31PM +1000, Jason Wu wrote:
> >>As a sidenote, POSIX shell doesn't support associative arrays (which
> >>were mentioned in this thread), so it's probably worth clarifying
> >>whether it's ok to require bash >= 4 for OpenWrt build scripts or not.
> >>
> >
> >what exactly do you need them for and can you solve it in a different
> >way ? ideally we run on as many distros as possible.
> 
> I can use indexed array instead of associative array.

Citing a SO answer: "POSIX shells have one array: the positional
parameters ($1, $2, etc., collectively refered to as "$@")".

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Question regarding call python script

2016-03-11 Thread Jason Wu




On 11/03/2016 8:12 PM, John Crispin wrote:



On 11/03/2016 11:11, Paul Fertser wrote:

Hey folks,

Bastian Bittorf  writes:

* John Crispin  [11.03.2016 06:27]:

depends on what you want to do. i dont really see anything that cannot
be handled using shell. what exactly do you want to write in python ?


also in general i think it's a good idea to have
less dependency than more. personally 8-) i want to
see perl and awk abandoned...


As a sidenote, POSIX shell doesn't support associative arrays (which
were mentioned in this thread), so it's probably worth clarifying
whether it's ok to require bash >= 4 for OpenWrt build scripts or not.



what exactly do you need them for and can you solve it in a different
way ? ideally we run on as many distros as possible.


I can use indexed array instead of associative array.

thanks,

Jason
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] procd warning about respawn

2016-03-11 Thread Helmut Schaa

On Fri, Mar 11, 2016 at 10:58 AM, John Crispin  wrote:
>
>
> On 11/03/2016 10:57, John Crispin wrote:
>>
>>
>> On 11/03/2016 10:54, Helmut Schaa wrote:
>>> On Tue, Mar 8, 2016 at 9:39 PM, John Crispin  wrote:


 On 08/03/2016 21:33, Ted Hess wrote:
> [ Sorry if duplicate -- first attempt was returned as spam!? ]
>
> John C. -- rather than continue this on a closed Github PR...
>
> Since changeset (https://dev.openwrt.org/changeset/48915),
> procd_close_instance issues a
> WARNING about respawn not defined if 'procd_set_param respawn' is not in
> ones startup script.
>
> Is respawn now a required parameter or is this an extraneous buglet?
>
> Example:
>
>#/etc/init.d/squeezelite start
>WARNING: Variable 'respawn' does not exist or is not an array/object
>#
>

 looks like a bug, will have a closer look tomorrow.
>>>
>>> Seems to be my fault. Looking into this as well now ...
>>> Helmut
>>
>> fixed the warning last night. please verify that the code is correct though.

Thanks John, fix looks good to me.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Question regarding call python script

2016-03-11 Thread John Crispin



On 11/03/2016 11:11, Paul Fertser wrote:
> Hey folks,
> 
> Bastian Bittorf  writes:
>> * John Crispin  [11.03.2016 06:27]:
>>> depends on what you want to do. i dont really see anything that cannot
>>> be handled using shell. what exactly do you want to write in python ?
>>
>> also in general i think it's a good idea to have
>> less dependency than more. personally 8-) i want to
>> see perl and awk abandoned...
> 
> As a sidenote, POSIX shell doesn't support associative arrays (which
> were mentioned in this thread), so it's probably worth clarifying
> whether it's ok to require bash >= 4 for OpenWrt build scripts or not.
> 

what exactly do you need them for and can you solve it in a different
way ? ideally we run on as many distros as possible.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Question regarding call python script

2016-03-11 Thread Paul Fertser

Hey folks,

Bastian Bittorf  writes:
> * John Crispin  [11.03.2016 06:27]:
>> depends on what you want to do. i dont really see anything that cannot
>> be handled using shell. what exactly do you want to write in python ?
>
> also in general i think it's a good idea to have
> less dependency than more. personally 8-) i want to
> see perl and awk abandoned...

As a sidenote, POSIX shell doesn't support associative arrays (which
were mentioned in this thread), so it's probably worth clarifying
whether it's ok to require bash >= 4 for OpenWrt build scripts or not.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] procd warning about respawn

2016-03-11 Thread John Crispin



On 11/03/2016 10:57, John Crispin wrote:
> 
> 
> On 11/03/2016 10:54, Helmut Schaa wrote:
>> On Tue, Mar 8, 2016 at 9:39 PM, John Crispin  wrote:
>>>
>>>
>>> On 08/03/2016 21:33, Ted Hess wrote:
 [ Sorry if duplicate -- first attempt was returned as spam!? ]

 John C. -- rather than continue this on a closed Github PR...

 Since changeset (https://dev.openwrt.org/changeset/48915),
 procd_close_instance issues a
 WARNING about respawn not defined if 'procd_set_param respawn' is not in
 ones startup script.

 Is respawn now a required parameter or is this an extraneous buglet?

 Example:

#/etc/init.d/squeezelite start
WARNING: Variable 'respawn' does not exist or is not an array/object
#

>>>
>>> looks like a bug, will have a closer look tomorrow.
>>
>> Seems to be my fault. Looking into this as well now ...
>> Helmut
> 
> fixed the warning last night. please verify that the code is correct though.
> 
>   John

https://dev.openwrt.org/changeset/48996
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] procd warning about respawn

2016-03-11 Thread John Crispin



On 11/03/2016 10:54, Helmut Schaa wrote:
> On Tue, Mar 8, 2016 at 9:39 PM, John Crispin  wrote:
>>
>>
>> On 08/03/2016 21:33, Ted Hess wrote:
>>> [ Sorry if duplicate -- first attempt was returned as spam!? ]
>>>
>>> John C. -- rather than continue this on a closed Github PR...
>>>
>>> Since changeset (https://dev.openwrt.org/changeset/48915),
>>> procd_close_instance issues a
>>> WARNING about respawn not defined if 'procd_set_param respawn' is not in
>>> ones startup script.
>>>
>>> Is respawn now a required parameter or is this an extraneous buglet?
>>>
>>> Example:
>>>
>>>#/etc/init.d/squeezelite start
>>>WARNING: Variable 'respawn' does not exist or is not an array/object
>>>#
>>>
>>
>> looks like a bug, will have a closer look tomorrow.
> 
> Seems to be my fault. Looking into this as well now ...
> Helmut

fixed the warning last night. please verify that the code is correct though.

John

> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] procd warning about respawn

2016-03-11 Thread Helmut Schaa

On Tue, Mar 8, 2016 at 9:39 PM, John Crispin  wrote:
>
>
> On 08/03/2016 21:33, Ted Hess wrote:
>> [ Sorry if duplicate -- first attempt was returned as spam!? ]
>>
>> John C. -- rather than continue this on a closed Github PR...
>>
>> Since changeset (https://dev.openwrt.org/changeset/48915),
>> procd_close_instance issues a
>> WARNING about respawn not defined if 'procd_set_param respawn' is not in
>> ones startup script.
>>
>> Is respawn now a required parameter or is this an extraneous buglet?
>>
>> Example:
>>
>>#/etc/init.d/squeezelite start
>>WARNING: Variable 'respawn' does not exist or is not an array/object
>>#
>>
>
> looks like a bug, will have a closer look tomorrow.

Seems to be my fault. Looking into this as well now ...
Helmut
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v3] brcmfmac: Add Raspberry Pi 3 support

[OpenWrt-Devel] [PATCH v2] ramips: Add support for Xiaomi MiWiFi Nano

[OpenWrt-Devel] netfilter.mk: how do I identify which kernel is being built?

[OpenWrt-Devel] [PATCH v3] brcmfmac: Add Raspberry Pi 3 support

Re: [OpenWrt-Devel] [PATCH v3] ipvs: Linux IP Virtual Server kernel modules (netfilter.mk patch)

Re: [OpenWrt-Devel] [PATCH v3] ipvs: Linux IP Virtual Server kernel modules (netfilter.mk patch)

Re: [OpenWrt-Devel] [PATCH v3] ipvs: Linux IP Virtual Server kernel modules (netfilter.mk patch)

Re: [OpenWrt-Devel] ARMv4 (not v4t) marked obsolete in gcc-6

[OpenWrt-Devel] [PATCH v2] fstools: support for ext4fs overlay

[OpenWrt-Devel] [PATCH] ramips: Add support for Xiaomi MiWiFi Nano

Re: [OpenWrt-Devel] Which image for the Nanostation Loco M2, WAS:Cannot flash UBNT Loco M2

[OpenWrt-Devel] Which image for the Nanostation Loco M2, WAS:Cannot flash UBNT Loco M2

Re: [OpenWrt-Devel] [PATCH v3] ipvs: Linux IP Virtual Server kernel modules (netfilter.mk patch)

Re: [OpenWrt-Devel] Cannot flash UBNT Loco M2

Re: [OpenWrt-Devel] [PATCH v3] ipvs: Linux IP Virtual Server kernel modules (netfilter.mk patch)

Re: [OpenWrt-Devel] Cannot flash UBNT Loco M2

Re: [OpenWrt-Devel] [PATCH v3] ipvs: Linux IP Virtual Server kernel modules (netfilter.mk patch)

Re: [OpenWrt-Devel] Cannot flash UBNT Loco M2

Re: [OpenWrt-Devel] Question regarding call python script

Re: [OpenWrt-Devel] Question regarding call python script

Re: [OpenWrt-Devel] Question regarding call python script

Re: [OpenWrt-Devel] procd warning about respawn

Re: [OpenWrt-Devel] Question regarding call python script

Re: [OpenWrt-Devel] Question regarding call python script

Re: [OpenWrt-Devel] procd warning about respawn

Re: [OpenWrt-Devel] procd warning about respawn

Re: [OpenWrt-Devel] procd warning about respawn

27 matches

Site Navigation

Mail list logo

Footer information