[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
Re: [LEDE-DEV] Ubnt power beam board - back to defaults after reboot
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 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] Ubnt power beam board - back to defaults after reboot
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
[LEDE-DEV] [PATCH] kernel: update kernel 4.4 to version 4.4.26
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] [PATCH] Add support for Comfast E380AC v1 and v2
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
Re: [LEDE-DEV] package contribution guidelines
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] base-files: ensure reset only works if an overlay exists
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] uqmi: re-enable autoconnect which was dropped without explanation
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] Ubnt power beam board - back to defaults after reboot
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] Need help with package dependencies
On 10/19/2016 07:12 PM, Alexandru Ardelean wrote: > On Tue, Oct 18, 2016 at 2:09 PM, Zefir Kurtisi > wrote: >> >> Hi, >> >> to those understanding the package dependency logic by heart, I'm trying to >> achieve something I assumed to be common, but fail to get there with the >> help of >> the available documentation. >> >> The short version is this: >> * package A has an optional feature X provided by package B >> * package B is optional (feeds package) >> => feature X should be selectable only if B is installed and selected >> * if feature X is activated, package A depends from package B >> >> I did: >> 1) in Config.in of package A add >> config WITH_FEATURE_X >> bool >> depends on PACKAGE_B >> prompt "Enable feature X" >> default n >> >> 2) in Makefile of package A add >> DEPENDS += +WITH_FEATURE_X:B > Why not just do DEPENDS+=+PACKAGE_B:B ? > This has the semantic that package A depends on B, only if it was > selected by some other package. > This would add an unconditional dependency (A depends from B when B is selected), which is maybe not desirable. I.e. you can have packages snmp and lldpd installed, but lldpd's SNMP agentx support is not mandatory. That's the idea of having WITH_FEATURE_X selectable in menu. > There are other depends like this PACKAGE_x around. > > You could then drop WITH_FEATURE_X config option in A > > If you need to add any other CFLAGS or LDFLAGS in A, you can just do > ifeq ($(CONFIG_PACKAGE_B),y) > CFLAGS+= > LDFLAGS+= > etc > endif > > I hope I understood correctly what you want to do. > Looked through all packages with Config.in menus, but did not find any with such inter-package dependencies. Maybe it is just not supported out of the box. Thanks anyway, I'll report back if I find some workaround. ___ 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 wrote: > 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. Should this actually be fixed by having the button handler just call "firstboot" (and fixing it there if necessary) rather than explicitly within the button handler? Sincerely, Karl P 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 v2] base-files: ensure reset only works if an overlay exists
On 20 October 2016 at 16:12, Karl Palsson wrote: > Rafał Miłecki wrote: >> 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. > > Should this actually be fixed by having the button handler just > call "firstboot" (and fixing it there if necessary) rather than > explicitly within the button handler? Calling "firstboot" helper sounds OK, but we still need to avoid LED blinking if factory reset is not supported. -- Rafał ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Archer C7(v2) - Question
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] [PATCH] base-files: sysfixtime: Allow system time in local timezones
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
Re: [LEDE-DEV] [PATCH] base-files: sysfixtime: Allow system time in local timezones
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 :-) I don't see wanting an embedded system to be like a desktop to be a reasonable justification. It doesn't serve any useful purpose that I can see. Also with there is daylight savings then when daylight savings kicks in you've got to change the clock which is *ugly* and waste of resources on an embedded device. 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
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] Need help with package dependencies
On Tue, 18 Oct 2016 13:09:22 +0200 Zefir Kurtisi wrote: > Hi, > > to those understanding the package dependency logic by heart, I'm > trying to achieve something I assumed to be common, but fail to get > there with the help of the available documentation. > > The short version is this: > * package A has an optional feature X provided by package B > * package B is optional (feeds package) > => feature X should be selectable only if B is installed and > selected > * if feature X is activated, package A depends from package B > > I did: > 1) in Config.in of package A add > config WITH_FEATURE_X > bool > depends on PACKAGE_B > prompt "Enable feature X" > default n > > 2) in Makefile of package A add > DEPENDS += +WITH_FEATURE_X:B > > > With those changes, build fails due to recursive dependencies, because > - symbol PACKAGE_B is selected by WITH_FEATURE_X > - symbol WITH_FEATURE_X depends on PACKAGE_B > > If I leave out the additional line in Makefile of A and in menu select > WITH_FEATURE_X, the build of A fails with missing dependency to > package B. > > If I leave out the 'depends on PACKAGE_B' line in Config.in, I can > select WITH_FEATURE_X without package B even being installed, which > obviously fails building. > > > Is this doable out of the box? What am I missing? Try the following: 1) Replace 'depends on PACKAGE_B' with 'select PACKAGE_B' 2) Replace DEPENDS+= +WITH_FEATURE_X:B with EXTRA_DEPENDS:=$(if $(CONFIG_WITH_FEAURE_X),B) That means that if WITH_FEATURE_X is selected that the package will select (mark for build) rather than just depend on (refuse to build unless package is selected) package B, and the EXTRA_DEPENDS makes sure opkg has the dependency if WITH_FEATURE_X is selected. Another possibility is: DEPENDS+= +@(WITH_FEATURE_X&&PACKAGE_B):B which ends up with a dependency on WITH_FEATURE_X and PACKAGE_B - the disadvantage of this approach is that it means if the user does not select package B but WITH_FEATURE_X is selected then the package will disappear from menuconfig. 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'
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
[LEDE-DEV] Getting 'too many bounces' notification
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
