[LEDE-DEV] Getting 'too many bounces' notification

[Daniel Dickinson]

Hi all,

Ended up having some problems again and when I got back to my email I
noticed that I was getting a lot of 'too many bounces' notifications
even though I have whitelisted the mailing lists for LEDE.  Any ideas?

Also, I noticed in the git log there were issues with older kernel
versions.  I had forgotten about the need to check kernel modules
against older kernels.  My apologies, I will attempt to keep that in
mind in future (my mind has been rather occupied with other things for
last while).

Regards,

Daniel

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

[LEDE-DEV] Firewall UCI has non-working 'utc_time 0'

[Daniel Dickinson]

Hi all,

The firewall package advertises utc_time uci option for firewall rules
and redirects, however, based in the iptables-extensions manpage, only
UTC time is supported by the time extension.

This matches my experience with attempting to use local timezone with
firewall rules based on time (does not work; always treats time as UTC;
iptables -nvx -L always shows UTC in the time regardless of utc_time as
well) for both standard openwrt method of setting timezone and with
appropriate zoneinfo package.

Regards,

Daniel

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

Re: [LEDE-DEV] regulatory domain information

[Charles]

on 2016-10-19 Charles wrote:

> Questions:

A similar observation: With OpenWrt 15.05.1, after booting, dmesg
output contains driver messages related to regulatory domain
changes and final (I hope) settings:

> [   10.85] cfg80211: Calling CRDA to update world regulatory domain
> [   10.88] cfg80211: World regulatory domain updated:
> [   10.88] cfg80211:  DFS Master region: unset
> [   10.89] cfg80211:   (start_freq - end_freq @ bandwidth), 
> (max_antenna_gain, max_eirp), (dfs_cac_time)
> [   10.90] cfg80211:   (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 
> 2000 mBm), (N/A)
> [   10.91] cfg80211:   (2457000 KHz - 2482000 KHz @ 2 KHz, 92000 KHz 
> AUTO), (N/A, 2000 mBm), (N/A)
> [   10.92] cfg80211:   (2474000 KHz - 2494000 KHz @ 2 KHz), (N/A, 
> 2000 mBm), (N/A)
> [   10.92] cfg80211:   (517 KHz - 525 KHz @ 8 KHz, 16 KHz 
> AUTO), (N/A, 2000 mBm), (N/A)
> [   10.93] cfg80211:   (525 KHz - 533 KHz @ 8 KHz, 16 KHz 
> AUTO), (N/A, 2000 mBm), (0 s)
> [   10.94] cfg80211:   (549 KHz - 573 KHz @ 16 KHz), (N/A, 
> 2000 mBm), (0 s)
> [   10.95] cfg80211:   (5735000 KHz - 5835000 KHz @ 8 KHz), (N/A, 
> 2000 mBm), (N/A)
> [   10.96] cfg80211:   (5724 KHz - 6372 KHz @ 216 KHz), (N/A, 
> 0 mBm), (N/A)
> ...
> [   11.14] cfg80211: Calling CRDA for country: US
> [   11.14] cfg80211: Regulatory domain changed to country: US
> [   11.15] cfg80211:  DFS Master region: FCC
> [   11.15] cfg80211:   (start_freq - end_freq @ bandwidth), 
> (max_antenna_gain, max_eirp), (dfs_cac_time)
> [   11.16] cfg80211:   (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 
> 3000 mBm), (N/A)
> [   11.17] cfg80211:   (517 KHz - 525 KHz @ 8 KHz, 16 KHz 
> AUTO), (N/A, 2300 mBm), (N/A)
> [   11.18] cfg80211:   (525 KHz - 533 KHz @ 8 KHz, 16 KHz 
> AUTO), (N/A, 2300 mBm), (0 s)
> [   11.19] cfg80211:   (549 KHz - 573 KHz @ 16 KHz), (N/A, 
> 2300 mBm), (0 s)
> [   11.20] cfg80211:   (5735000 KHz - 5835000 KHz @ 8 KHz), (N/A, 
> 3000 mBm), (N/A)
> [   11.21] cfg80211:   (5724 KHz - 6372 KHz @ 216 KHz), (N/A, 
> 4000 mBm), (N/A)
> ...
> [   19.92] cfg80211: Calling CRDA for country: DE
> [   19.94] cfg80211: Regulatory domain changed to country: DE
> [   19.95] cfg80211:  DFS Master region: ETSI
> [   19.95] cfg80211:   (start_freq - end_freq @ bandwidth), 
> (max_antenna_gain, max_eirp), (dfs_cac_time)
> [   19.96] cfg80211:   (240 KHz - 2483000 KHz @ 4 KHz), (N/A, 
> 2000 mBm), (N/A)
> [   19.97] cfg80211:   (515 KHz - 525 KHz @ 8 KHz, 20 KHz 
> AUTO), (N/A, 2000 mBm), (N/A)
> [   19.98] cfg80211:   (525 KHz - 535 KHz @ 8 KHz, 20 KHz 
> AUTO), (N/A, 2000 mBm), (0 s)
> [   19.99] cfg80211:   (547 KHz - 5725000 KHz @ 16 KHz), (N/A, 
> 2700 mBm), (0 s)
> [   20.00] cfg80211:   (5700 KHz - 6600 KHz @ 216 KHz), (N/A, 
> 4000 mBm), (N/A)

One can easily see region changing from 'unset' over 'FCC' to 'ETSI'.

With current LEDE, however, these messages are completely missing,
making it harder to trust radio obeying regulatory rules.  I mean, what
is the rationale for this change (as well as that subject of the other
mail)?

tnx, Charles



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

Re: [LEDE-DEV] [PATCH] base-files: sysfixtime: Allow system time in local timezones

[Daniel Dickinson]

On Wed, 19 Oct 2016 22:05:43 +0200
Petr Štetiar  wrote:

> Felix Fietkau  [2016-10-19 21:44:06]:
> 
> > I'd like to know why you need to use local time for the RTC, I think
> > that's rather uncommon.  
> 
> You mean system time in local time, right? RTC should be in UTC and
> in current sysftime isn't. Basically sysfixtime should be using
> hwclock with -u parameter from the same beginning as the kernel
> doesn't expect time in RTC to be in other timezone.
> 
> Believe it or not, I've some users which are used to have system time
> on their desktop Linux machines in local timezone and they expect the
> same from the Linux on embedded devices. It's hard, I know :-)

Have you ever looked at UCI config for /etc/config/system?  There is
the option to set the system timezone there.  No need to hack hwclock.

Regards,

Daniel

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

[LEDE-DEV] Archer C7(v2) - Question

[Jens DPunkt]

Hi,

im new on lede and im a user, no dev. Hope its ok to ask.
I got an archer c5 flashed to a C7 (works perfect since month with openwrt).

I stumbled over messages - and i dont no if this is also on openwrt.
Looks like there are not a problem (wifi works)


root@Archer-Lede:/# dmesg | grep ath10
[9.291627] ath10k_pci :01:00.0: pci irq legacy oper_irq_mode 1
irq_mode 0 reset_mode 0
[9.514635] ath10k_pci :01:00.0: Direct firmware load for
ath10k/pre-cal-pci-:01:00.0.bin failed with error -2
[9.525521] ath10k_pci :01:00.0: Falling back to user helper
[9.617803] firmware ath10k!pre-cal-pci-:01:00.0.bin:
firmware_loading_store: map pages failed
[9.981761] ath10k_pci :01:00.0: qca988x hw2.0 target
0x4100016c chip_id 0x043202ff sub :
[9.991164] ath10k_pci :01:00.0: kconfig debug 0 debugfs 1
tracing 0 dfs 1 testmode 1
[   10.004239] ath10k_pci :01:00.0: firmware ver 10.2.4.70.54 api
5 features no-p2p,raw-mode,mfp crc32 9d340dd9
[   10.014664] ath10k_pci :01:00.0: Direct firmware load for
ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
[   10.025265] ath10k_pci :01:00.0: Falling back to user helper
[   10.104231] firmware ath10k!QCA988X!hw2.0!board-2.bin:
firmware_loading_store: map pages failed
[   10.119436] ath10k_pci :01:00.0: board_file api 1 bmi_id N/A
crc32 bebc7c08
[   11.250688] ath10k_pci :01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2
cal file max-sta 128 raw 0 hwcrypto 1
[  328.294935] ath10k_pci :01:00.0: DFS region 0x0 not supported,
will trigger radar for every pulse
root@Archer-Lede:/#

Regards

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

Re: [LEDE-DEV] Ubnt power beam board - back to defaults after reboot

[Matthias Schiffer]

On 10/20/2016 10:20 AM, Jiri Pirko wrote:
> Thu, Oct 20, 2016 at 09:48:48AM CEST, garet...@orcon.net.nz wrote:
>> Hi Jiri
>> This is a common problem on XM devices due to new uboot on AirOS >= 5.6.x,
>> although I haven't got any XW devices to test but its possibly the same?
>> Try downgrading back to AirOS v5.5.11 or less or apply the following patches
>> which I can confirm fix the problem on my XM devices.
>>
>> https://raw.githubusercontent.com/freifunk-gluon/gluon/1f400189cfbae697b5018
>> 0bccf876784a3c03423/patches/openwrt/0026-kernel-backport-spi-nor-driver-from
>> -4.4.9.patch
>> https://raw.githubusercontent.com/freifunk-gluon/gluon/1f400189cfbae697b5018
>> 0bccf876784a3c03423/patches/openwrt/0027-kernel-mtd-spi-nor-wait-until-statu
>> s-register-writes-are-ready.patch
>> https://raw.githubusercontent.com/freifunk-gluon/gluon/1f400189cfbae697b5018
>> 0bccf876784a3c03423/patches/openwrt/0028-kernel-mtd-spi-nor-unlock-Winbond-f
>> lashs.patch
> 
> Ok, will try, thanks. But why these patches are not merged to openwrt master?
> 
> Also, it be would be nice to mention this on the wiki.
> 

Hi,
when I backported those changes, OpenWrt was still on 3.18 or 4.1 for
ar71xx; I had planned to submit these after switching to 4.4, so we could
avoid the huge spi-nor backport, but later forgot about it...

I had also submitted some of our patches upstream, but some discussion
prevented them from being included so far ([1], [2]), and I was too busy to
write an improved version.

Regards,
Matthias


[1] https://patchwork.kernel.org/patch/9118911/
[2] https://patchwork.kernel.org/patch/9118901/



signature.asc
Description: OpenPGP digital signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] uqmi: re-enable autoconnect which was dropped without explanation

[Felix Fietkau]

On 2016-10-19 23:49, Petr Štetiar wrote:
> Hi Felix,
> 
> it seems like that this autoconnect feature is causing some regressions and a
> headaches to few people :-) I'm talking about this commit in particular:
> 
>   Author: Felix Fietkau 
>   Date:   Thu Sep 22 20:07:45 2016 +0200
> 
>   uqmi: re-enable autoconnect which was dropped without explanation
>   
>   Fixes a regression in commit 8f24ee638275:
>   "uqmi: Add proper IPv6 support"
> 
> I'm using Quectel EC20 miniPCIe modem mainly in Slovakia and Czech Republic.
> Till now, without autoconnect enabled it was working fine in both networks, 
> but
> now after this change has been pulled into my device I'm no more able to
> initiate the connection in Slovakia:
> 
> netifd: wan (1681): Waiting for network registration
> netifd: wan (1681): Starting network internet
> netifd: wan (1681): Unable to connect IPv4
> netifd: wan (1681): Unable to connect
> 
> To get it working again, I've to just remove autoconnect from start-network
> command:
> 
>   --- a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
>   +++ b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
>   @@ -112,8 +112,7 @@ proto_qmi_setup() {
>   ${auth:+--auth-type $auth} \
>   ${username:+--username $username} \
>   ${password:+--password $password} \
>   -   --ip-family ipv4 \
>   -   --autoconnect`
>   +   --ip-family ipv4`
> 
> To me it seems like this autoconnect option is being propagated throught the
> network and the network operator could refuse connection with this option. I
> don't have any other logical explanation.
> 
> How to fix it for both use cases, with and without autoconnect feature?
> Introduce qmi_autoconnect config option?
I think we probably need to introduce such an option as a temporary
measure.

The problem with not using autoconnect is that once the link is gone for
a while, the link will be torn down and not re-established anymore. To
deal with that properly, we need some code to monitor the link and try
to re-establish the connection when it's gone.

- Felix


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

Re: [LEDE-DEV] [PATCH] base-files: ensure reset only works if an overlay exists

[Karl Palsson]

It used to only do the sync+reboot for button presses less than 1
second. jffs2reset and reboot for button presses longer than 5
seconds, and _nothing_ for presses between 1 and 5 seconds.
(Potentially leaving room for someone else to add some other
hook, but realistically just useless)

I noticed it, but thought it was probably simpler this way, but
Rafal's right, if you're changing that behaviour as well, it
should at least be documented as deliberate in the commit note.

Sincerely,
Karl Palsson

Chris Blake  wrote:
> Rafal,
> 
> I am not sure I see the issue you are mentioning. The patch's
> goal is to disable the "reset" feature for devices that do not
> have an overlay, and instead just reboot the device. This patch
> does that, and was tested on an ar71xx and x86_64 ext4
> platform.
> 
> Regards,
> Chris Blake
> 
> On Wed, Oct 19, 2016 at 4:33 PM, Rafał Miłecki
>  wrote:
> > On 19 October 2016 at 16:54, Chris Blake  wrote:
> >> Currently the reset script will try to run jffs2reset on boards that are
> >> running a rw ext4 or other rootfs, which will then cause jffs2reset to
> >> fail and the board to never reboot. This change ensures that jffs2reset
> >> is only ran if an overlay is mounted.
> >>
> >> Signed-off-by: Chris Blake 
> >> ---
> >>  package/base-files/files/etc/rc.button/reset | 11 ++-
> >>  1 file changed, 6 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/package/base-files/files/etc/rc.button/reset 
> >> b/package/base-files/files/etc/rc.button/reset
> >> index c6dc7cf..fab9a6c 100755
> >> --- a/package/base-files/files/etc/rc.button/reset
> >> +++ b/package/base-files/files/etc/rc.button/reset
> >> @@ -11,15 +11,16 @@ timeout)
> >> set_state failsafe
> >>  ;;
> >>  released)
> >> -   if [ "$SEEN" -lt 1 ]
> >> +   OVERLAY="$(cat /proc/mounts | grep ' /overlay ' 2>/dev/null)"
> >> +   if [ "$SEEN" -gt 5 -a -n "$OVERLAY" ]
> >> +   then
> >> +   echo "FACTORY RESET" > /dev/console
> >> +   jffs2reset -y && reboot &
> >> +   elif [ "$SEEN" ]
> >> then
> >> echo "REBOOT" > /dev/console
> >> sync
> >> reboot
> >> -   elif [ "$SEEN" -gt 5 ]
> >> -   then
> >> -   echo "FACTORY RESET" > /dev/console
> >> -   jffs2reset -y && reboot &
> >> fi
> >>  ;;
> >>  esac
> >
> > It seems to me you just changed behavior for pressing button for time
> > between 1 and 5 seconds. Your commit message doesn't state you wanted
> > to do that and I don't think we should.
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] package contribution guidelines

[Karl Palsson]

Rafał Miłecki   wrote:
> On 19 October 2016 at 16:59, Chris Blake
>  wrote:
> > diff --git a/package/utils/beep/Makefile b/package/utils/beep/Makefile
> > new file mode 100644
> > index 000..b9bb4d80
> > --- /dev/null
> > +++ b/package/utils/beep/Makefile
> > @@ -0,0 +1,50 @@
> > +#
> > +# Copyright (C) 2016 OpenWrt.org
> > +#
> > +# This is free software, licensed under the GNU General Public License v2.
> > +# See /LICENSE for more information.
> > +#
> 
> We really need to do some final research on this and add some
> documentation probably.
> 
> I don't think you can assign copyrights to OpenWrt without
> having a contract specifying that clearly.

jow drafted some nice updates to the
https://github.com/openwrt/packages/blob/master/CONTRIBUTING.md
file on piratepad when we spoke about this recently. Addresses a
few other things that had come up recently too, wrt git vs
http(s) sources and so on.

Did anyone else ever comment on that jow? Should we submit it as
a change to that file now?

Sincerely,
Karl Palsson

signature.asc
Description: OpenPGP Digital Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] Add support for Comfast E380AC v1 and v2

[Gareth Parker]

Because there are two versions of this device there are two different $board 
values cf-e380ac-v1 and cf-e380ac-v2, however there is one struct for gpio's in 
the corresponding mach file referencing cf-e380ac.  What would be the procedure 
or protocol to follow here in regards to using $board in diag.sh and 02_leds?

Gareth

-Original Message-
From: John Crispin [mailto:j...@phrozen.org] 
Sent: Tuesday, 18 October 2016 7:13 p.m.
To: Rafał Miłecki; Gareth Parker
Cc: LEDE Development List; gar...@zappie.net.nz
Subject: Re: [LEDE-DEV] [PATCH] Add support for Comfast E380AC v1 and v2



On 18/10/2016 07:54, Rafał Miłecki wrote:
> On 17 October 2016 at 12:14, Gareth Parker  wrote:
>> The Comfast E380AC is a single port PoE Dual Band AP.
>>
>> There are two versions which are only identifiable through the web 
>> administration interface, v1 has 128mb ram and a uboot size of 128k, v2 has 
>> 256mb ram and a uboot size of 256k, the remaining hardware and PCB markings 
>> are the same.
> 
> Minor note: mb means milli-bits. You probably meant MiB which means 
> mebi-bytes.
> https://en.wikipedia.org/wiki/Metric_prefix
> https://en.wikipedia.org/wiki/Binary_prefix
> 
> 
>> diff --git a/target/linux/ar71xx/base-files/etc/diag.sh 
>> b/target/linux/ar71xx/base-files/etc/diag.sh
>> index d6e257d..c8e6b48 100644
>> --- a/target/linux/ar71xx/base-files/etc/diag.sh
>> +++ b/target/linux/ar71xx/base-files/etc/diag.sh
>> @@ -82,6 +82,10 @@ get_status_led() {
>> cf-e316n-v2)
>> status_led="$board:blue:wan"
>> ;;
>> +   cf-e380ac-v1|\
>> +   cf-e380ac-v2)
>> +   status_led="cfe380ac:green"
>> +   ;;
>> cpe510)
>> status_led="tp-link:green:link4"
>> ;;
> 
> See comment below.
> 
> 
>> +static struct gpio_led cf_e380ac_leds_gpio[] __initdata = {
>> +   {
>> +   .name   = "cfe380ac:red",
>> +   .gpio   = CF_E380AC_GPIO_LED_RED,
>> +   .active_low = 0,
>> +   },
>> +   {
>> +   .name   = "cfe380ac:green",
>> +   .gpio   = CF_E380AC_GPIO_LED_GREEN,
>> +   .active_low = 0,
>> +   },
>> +   {
>> +   .name   = "cfe380ac:blue",
>> +   .gpio   = CF_E380AC_GPIO_LED_BLUE,
>> +   .active_low = 0,
>> +   },
>> +
>> +};
> 
> What about functions of these LEDs? Take a look at 
> Documentation/leds/leds-class.txt, you should be using 
> "devicename:colour:function".

please make sure to use $board instead of the board name when referencing the 
leds.

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


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

[LEDE-DEV] [PATCH] kernel: update kernel 4.4 to version 4.4.26

[Koen Vandeputte]

Refresh patches for all targets that support kernel 4.4.
compile/run-tested on cns3xxx & imx6.

Signed-off-by: Koen Vandeputte 
---
 include/kernel-version.mk | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/kernel-version.mk b/include/kernel-version.mk
index 2452f6d..faf8dde 100644
--- a/include/kernel-version.mk
+++ b/include/kernel-version.mk
@@ -4,11 +4,11 @@ LINUX_RELEASE?=1
 
 LINUX_VERSION-3.18 = .29
 LINUX_VERSION-4.1 = .20
-LINUX_VERSION-4.4 = .25
+LINUX_VERSION-4.4 = .26
 
 LINUX_KERNEL_MD5SUM-3.18.29 = b25737a0bc98e80d12200de93f239c28
 LINUX_KERNEL_MD5SUM-4.1.20 = 075c38a3a23ca5bc80437b13606df00a
-LINUX_KERNEL_MD5SUM-4.4.25 = 14f7ff09d79088d82685463a70d66464
+LINUX_KERNEL_MD5SUM-4.4.26 = 0a3a2a719490d24f85591593913d3004
 
 ifdef KERNEL_PATCHVER
   LINUX_VERSION:=$(KERNEL_PATCHVER)$(strip $(LINUX_VERSION-$(KERNEL_PATCHVER)))
-- 
2.7.4


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

Re: [LEDE-DEV] Ubnt power beam board - back to defaults after reboot

[Jiri Pirko]

Thu, Oct 20, 2016 at 09:48:48AM CEST, garet...@orcon.net.nz wrote:
>Hi Jiri
>This is a common problem on XM devices due to new uboot on AirOS >= 5.6.x,
>although I haven't got any XW devices to test but its possibly the same?
>Try downgrading back to AirOS v5.5.11 or less or apply the following patches
>which I can confirm fix the problem on my XM devices.
>
>https://raw.githubusercontent.com/freifunk-gluon/gluon/1f400189cfbae697b5018
>0bccf876784a3c03423/patches/openwrt/0026-kernel-backport-spi-nor-driver-from
>-4.4.9.patch
>https://raw.githubusercontent.com/freifunk-gluon/gluon/1f400189cfbae697b5018
>0bccf876784a3c03423/patches/openwrt/0027-kernel-mtd-spi-nor-wait-until-statu
>s-register-writes-are-ready.patch
>https://raw.githubusercontent.com/freifunk-gluon/gluon/1f400189cfbae697b5018
>0bccf876784a3c03423/patches/openwrt/0028-kernel-mtd-spi-nor-unlock-Winbond-f
>lashs.patch

Ok, will try, thanks. But why these patches are not merged to openwrt master?

Also, it be would be nice to mention this on the wiki.


>
>Cheers,
>
>Gareth
>
>-Original Message-
>From: Lede-dev [mailto:lede-dev-boun...@lists.infradead.org] On Behalf Of
>Jiri Pirko
>Sent: Thursday, 20 October 2016 8:29 p.m.
>To: openwrt-de...@lists.openwrt.org; lede-dev@lists.infradead.org
>Subject: [LEDE-DEV] Ubnt power beam board - back to defaults after reboot
>
>Hi.
>
>Trying Ubiquity power beam M5. According to the instructions on openwrt
>wiki, I'm using loco m5 firmware. All looks fine, only configuration is lost
>after every reboot.
>
>Tried:
>openwrt-15.05.1-ar71xx-generic-ubnt-loco-m-xw-squashfs-sysupgrade.bin
>openwrt-15.05-ar71xx-generic-ubnt-loco-m-xw-squashfs-sysupgrade.bin
>openwrt-ar71xx-generic-ubnt-loco-m-xw-squashfs-sysupgrade.bin
>lede-ar71xx-generic-ubnt-loco-m-xw-squashfs-sysupgrade.bin
>
>All with the same result.
>
>I remember I had some similar problem in past on a different board, and I
>believe that there was and issue on definition of nand size. Not really
>sure.
>
>Any ideas?
>
>Jiri
>
>___
>Lede-dev mailing list
>Lede-dev@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/lede-dev
>

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

Re: [LEDE-DEV] Dependency issues on custom packages and USE_MUSL visibility

[Yousong Zhou]

On 10 October 2016 at 04:03, Carlos Ferreira  wrote:
> Hello!
> I'm having some issues regarding the implementation of new package
> options, due to their peculiar dependencies.
>
> I'm trying to implement a configuration option, which should exist
> only if the package libbz2 is selected. I understand that to do this,
> I should have something like this:
>
> config new-option-with-libbz2-dependency
> depends on PACKAGE_libbz2
> bool "Optional support for libbz2."
> default n
>
> Now, the thing is, the building system is not building libbz2 before
> the package, as a result of being a dependency, it is only hiding the
> option until libbz2 is selected in the menuconfig.
> Also, if I add:
> select PACKAGE_libz2
> it will only select the package but not build it as a dependency.
>
> How can I force the compilation of libbz2 before the package is
> compiled, when my new option is selected?

Try using +new-option-with-libbz2-dependency:libbz2 . See
https://wiki.openwrt.org/doc/devel/packages#dependency_types and
package makefile of dnsmasq for details

>
>
> Also, I would like to know how can I use the USE_MUSL symbol to add
> values to the TARGET_LDFLAGS variable. The following example seems not
> to work:
>
> TARGET_LDFLAGS += \
> $(if $(@USE_MUSL), -pthread -lrt,) \
>
>
> What am I doing wrong?

Check `CONFIG_USE_MUSL` in Makefile.  It's not the same as the those
in `DEPENDS` and mconf, though related.

yousong

>
> --
>
> Carlos Miguel Ferreira
> Researcher at Telecommunications Institute
> Aveiro - Portugal
> Work E-mail - c...@av.it.pt
> Skype & GTalk -> carlosmf...@gmail.com
> LinkedIn -> http://www.linkedin.com/in/carlosmferreira
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

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

Re: [LEDE-DEV] [PATCH v2] base-files: ensure reset only works if an overlay exists

[Rafał Miłecki]

On 20 October 2016 at 08:11, Chris Blake  wrote:
> I agree that would work in terms of functionality, but the issue with
> that logic is if you hold the button over 5 seconds, the system LED
> will start flashing (as expected) but then no action is taken on the
> board. The reason for my logic change was just to ensure the board
> would reboot in that case.

That would just as confusing for the user. If jffs2reset is
unsupported on a device, make sure we also don't start blinking.

It will be more clear that way: user keeps RESET pressed for 5+
seconds, LED doesn't start blinking, device doesn't reboot. It somehow
indicated factory reset wasn't started.

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

Re: [LEDE-DEV] [PATCH v2] base-files: ensure reset only works if an overlay exists

[Chris Blake]

Hey Rafal,

I agree that would work in terms of functionality, but the issue with
that logic is if you hold the button over 5 seconds, the system LED
will start flashing (as expected) but then no action is taken on the
board. The reason for my logic change was just to ensure the board
would reboot in that case.

Regards,
Chris Blake

On Thu, Oct 20, 2016 at 1:05 AM, Rafał Miłecki  wrote:
> On 20 October 2016 at 07:37, Chris Blake  wrote:
>> On Thu, Oct 20, 2016 at 12:29 AM, Rafał Miłecki  wrote:
>>> On 20 October 2016 at 05:23, Chris Blake  wrote:
 diff --git a/package/base-files/files/etc/rc.button/reset 
 b/package/base-files/files/etc/rc.button/reset
 index c6dc7cf..fab9a6c 100755
 --- a/package/base-files/files/etc/rc.button/reset
 +++ b/package/base-files/files/etc/rc.button/reset
 @@ -11,15 +11,16 @@ timeout)
 set_state failsafe
  ;;
  released)
 -   if [ "$SEEN" -lt 1 ]
 +   OVERLAY="$( grep ' /overlay ' /proc/mounts )"
 +   if [ "$SEEN" -gt 5 -a -n "$OVERLAY" ]
 +   then
 +   echo "FACTORY RESET" > /dev/console
 +   jffs2reset -y && reboot &
 +   elif [ "$SEEN" ]
 then
 echo "REBOOT" > /dev/console
 sync
 reboot
 -   elif [ "$SEEN" -gt 5 ]
 -   then
 -   echo "FACTORY RESET" > /dev/console
 -   jffs2reset -y && reboot &
 fi
  ;;
  esac
>>>
>>> Before:
>>> if $SEEN < 1 => reboot
>>> if $SEEN > 5 => factory
>>>
>>> After
>>> if $SEEN > 5 => factory
>>> else => reboot
>>>
>>> Can you see that changed behavior now?
>>
>> Rafal,
>>
>> Indeed I do. If you have a better idea for implementation I am all
>> ears on feedback to resolve this bug.
>
> Don't rework this script so much, just add:
> OVERLAY="$( grep ' /overlay ' /proc/mounts )"
> as you did and replace:
> elif [ "$SEEN" -gt 5 ]
> with:
> elif [ "$SEEN" -gt 5 -a -n "$OVERLAY" ]

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

Re: [LEDE-DEV] [PATCH v2] base-files: ensure reset only works if an overlay exists

[Rafał Miłecki]

On 20 October 2016 at 07:37, Chris Blake  wrote:
> On Thu, Oct 20, 2016 at 12:29 AM, Rafał Miłecki  wrote:
>> On 20 October 2016 at 05:23, Chris Blake  wrote:
>>> diff --git a/package/base-files/files/etc/rc.button/reset 
>>> b/package/base-files/files/etc/rc.button/reset
>>> index c6dc7cf..fab9a6c 100755
>>> --- a/package/base-files/files/etc/rc.button/reset
>>> +++ b/package/base-files/files/etc/rc.button/reset
>>> @@ -11,15 +11,16 @@ timeout)
>>> set_state failsafe
>>>  ;;
>>>  released)
>>> -   if [ "$SEEN" -lt 1 ]
>>> +   OVERLAY="$( grep ' /overlay ' /proc/mounts )"
>>> +   if [ "$SEEN" -gt 5 -a -n "$OVERLAY" ]
>>> +   then
>>> +   echo "FACTORY RESET" > /dev/console
>>> +   jffs2reset -y && reboot &
>>> +   elif [ "$SEEN" ]
>>> then
>>> echo "REBOOT" > /dev/console
>>> sync
>>> reboot
>>> -   elif [ "$SEEN" -gt 5 ]
>>> -   then
>>> -   echo "FACTORY RESET" > /dev/console
>>> -   jffs2reset -y && reboot &
>>> fi
>>>  ;;
>>>  esac
>>
>> Before:
>> if $SEEN < 1 => reboot
>> if $SEEN > 5 => factory
>>
>> After
>> if $SEEN > 5 => factory
>> else => reboot
>>
>> Can you see that changed behavior now?
>
> Rafal,
>
> Indeed I do. If you have a better idea for implementation I am all
> ears on feedback to resolve this bug.

Don't rework this script so much, just add:
OVERLAY="$( grep ' /overlay ' /proc/mounts )"
as you did and replace:
elif [ "$SEEN" -gt 5 ]
with:
elif [ "$SEEN" -gt 5 -a -n "$OVERLAY" ]

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

[LEDE-DEV] [PATCH] brcm47xx: open code Makefile entries for all devices

[Rafał Miłecki]

From: Rafał Miłecki 

If we want to use some of new features like per device rootfs we will
need this to specify them there.

Signed-off-by: Rafał Miłecki 
---
 target/linux/brcm47xx/image/Makefile | 642 ---
 1 file changed, 527 insertions(+), 115 deletions(-)

diff --git a/target/linux/brcm47xx/image/Makefile 
b/target/linux/brcm47xx/image/Makefile
index b9cdbf4..9076605 100644
--- a/target/linux/brcm47xx/image/Makefile
+++ b/target/linux/brcm47xx/image/Makefile
@@ -77,7 +77,7 @@ define Build/trx-without-loader
 endef
 
 define Build/asus-trx
-   $(STAGING_DIR_HOST)/bin/asustrx -p "$(PRODUCTID)" -i $@ -o $@.new
+   $(STAGING_DIR_HOST)/bin/asustrx -p $(PRODUCTID) -i $@ -o $@.new
mv $@.new $@
 endef
 
@@ -159,69 +159,69 @@ define Device/asus
IMAGE/trx := trx-with-loader | asus-trx
 endef
 
-define AsusDevice
-  define Device/asus-$(1)
-   $$(Device/asus)
-   PRODUCTID := $(2)
-  endef
-  TARGET_DEVICES += asus-$(1)
-endef
-
 define Device/linksys
IMAGES := bin
IMAGE/bin := trx-with-loader | linksys-bin
 endef
 
-define LinksysDevice
-  define Device/linksys-$(1)
-   $$(Device/linksys)
-   DEVICE_ID := $(2)
-   VERSION := $(3)
-  endef
-  TARGET_DEVICES += linksys-$(1)
-endef
-
 define Device/motorola
IMAGES := bin
IMAGE/bin := trx-with-loader | motorola-bin
 endef
 
-define MotorolaDevice
-  define Device/motorola-$(1)
-   $$(Device/motorola)
-   MOTOROLA_DEVICE := $(2)
-  endef
-  TARGET_DEVICES += motorola-$(1)
-endef
-
 define Device/netgear
IMAGES := chk
IMAGE/chk := trx-with-loader | netgear-chk
 endef
 
-define NetgearDevice
-  define Device/netgear-$(1)
-   $$(Device/netgear)
-   NETGEAR_BOARD_ID := $(2)
-   NETGEAR_REGION := $(3)
-  endef
-  TARGET_DEVICES += netgear-$(1)
-endef
-
 #
 # Subtarget generic
 #
 
 ifeq ($(SUBTARGET),generic)
   # BCM4705 with tg3
-  $(eval $(call LinksysDevice,wrt300n-v1.1,EWC2,1.51.2))
-  $(eval $(call LinksysDevice,wrt310n-v1,310N,1.0.10))
-  $(eval $(call LinksysDevice,wrt350n-v1,EWCG,1.04.1))
-  $(eval $(call LinksysDevice,wrt610n-v1,610N,1.0.1))
+  define Device/linksys-wrt300n-v1.1
+   $(Device/linksys)
+   DEVICE_ID := EWC2
+   VERSION := 1.51.2
+  endef
+  TARGET_DEVICES += linksys-wrt300n-v1.1
+
+  define Device/linksys-wrt310n-v1
+   $(Device/linksys)
+   DEVICE_ID := 310N
+   VERSION := 1.0.10
+  endef
+  TARGET_DEVICES += linksys-wrt310n-v1
+
+  define Device/linksys-wrt350n-v1
+   $(Device/linksys)
+   DEVICE_ID := EWCG
+   VERSION := 1.04.1
+  endef
+  TARGET_DEVICES += linksys-wrt350n-v1
+
+  define Device/linksys-wrt610n-v1
+   $(Device/linksys)
+   DEVICE_ID := 610N
+   VERSION := 1.0.1
+  endef
+  TARGET_DEVICES += linksys-wrt610n-v1
 
   # BCMA SoC with SSB WiFi
-  $(eval $(call LinksysDevice,wrt610n-v2,610N,2.0.0))
-  $(eval $(call LinksysDevice,e3000-v1,61XN,1.0.3))
+  define Device/linksys-wrt610n-v2
+   $(Device/linksys)
+   DEVICE_ID := 610N
+   VERSION := 2.0.0
+  endef
+  TARGET_DEVICES += linksys-wrt610n-v2
+
+  define Device/linksys-e3000-v1
+   $(Device/linksys)
+   DEVICE_ID := 61XN
+   VERSION := 1.0.3
+  endef
+  TARGET_DEVICES += linksys-e3000-v1
 
   TARGET_DEVICES += standard
 endif
@@ -293,28 +293,147 @@ ifeq ($(SUBTARGET),legacy)
netgear-wgt634u \
usrobotics-usr5461
 
-  $(eval $(call AsusDevice,wl-300g,WL300g  ))
-  $(eval $(call AsusDevice,wl-320gp,WL320gP ))
-  $(eval $(call AsusDevice,wl-330ge,WL-330gE))
-  $(eval $(call AsusDevice,wl-500gp-v1,WL500gp ))
-  $(eval $(call AsusDevice,wl-500gp-v2,WL500gpv2   ))
-  $(eval $(call AsusDevice,wl-500w,WL500W  ))
-  $(eval $(call AsusDevice,wl-520gu,WL520gu ))
-  $(eval $(call AsusDevice,wl-550ge,WL550gE ))
-  $(eval $(call AsusDevice,wl-hdd25,WLHDD   ))
-  $(eval $(call LinksysDevice,wrt54g3g,W54F,2.20.1))
-  $(eval $(call LinksysDevice,wrt54g3g-em,W3GN,2.20.1))
-  $(eval $(call LinksysDevice,wrt54g,W54G,4.71.1))
-  $(eval $(call LinksysDevice,wrt54gs-v4,W54s,1.09.1))
-  $(eval $(call LinksysDevice,wrt150n,N150,1.51.3))
-  $(eval $(call LinksysDevice,wrt160n-v1,N150,1.50.1))
-  $(eval $(call LinksysDevice,wrt300n-v1,EWCB,1.03.6))
-  $(eval $(call MotorolaDevice,wa840g,2))
-  $(eval $(call MotorolaDevice,we800g,3))
-  $(eval $(call MotorolaDevice,wr850g,1))
-  $(eval $(call NetgearDevice,wgr614-v8,U12H072T00_NETGEAR,2))
-  $(eval $(call NetgearDevice,wndr3300-v1,U12H093T00_NETGEAR,2))
-  $(eval $(call NetgearDevice,wnr834b-v2,U12H081T00_NETGEAR,2))
+  define Device/asus-wl-300g
+   $(Device/asus)
+   PRODUCTID := "WL300g  "
+  endef
+  TARGET_DEVICES += asus-wl-300g
+
+  define Device/asus-wl-320gp
+   $(Device/asus)
+   PRODUCTID := "WL320gP "
+  endef
+  TARGET_DEVICES +=