date:20161019

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

2016-10-19 Thread Chris Blake

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.

Regards,
Chris Blake

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?

___
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

2016-10-19 Thread Rafał Miłecki

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?

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

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

2016-10-19 Thread Chris Blake

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, and disables the "reset" feature if
no /overlay is mounted on the device.

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="$( 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
--
2.7.4

___
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

2016-10-19 Thread Chris Blake

Bastian,

I will get that revised and push out a v2 of this patch. Thanks.

On Wed, Oct 19, 2016 at 3:04 PM, Bastian Bittorf  wrote:
> * Chris Blake  [19.10.2016 21:57]:
>> + OVERLAY="$(cat /proc/mounts | grep ' /overlay ' 2>/dev/null)"
>
> please change to:
> OVERLAY="$( grep ' /overlay ' /proc/mounts )"
>
> bye, bastian

___
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

2016-10-19 Thread Chris Blake

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

Re: [LEDE-DEV] [PATCH 1/1] package/utils: Add beep package

2016-10-19 Thread Rafał Miłecki

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.

___
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

2016-10-19 Thread Rafał Miłecki

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

[LEDE-DEV] regulatory domain information

2016-10-19 Thread Charles

Hello,

on a TP-Link WDR3600 v1 (dual-band wifi, ath9k, wireless settings are
attached below, most notably wireless.radioX.country=DE), the output
of command 'iw reg get' is

with OpenWrt 15.05.1:

country DE: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 20), (N/A)
(5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
(5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
(5470 - 5725 @ 160), (N/A, 27), (0 ms), DFS
(57000 - 66000 @ 2160), (N/A, 40), (N/A)

and with current LEDE:

global
country DE: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 20), (N/A)
(5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5725 @ 160), (N/A, 27), (0 ms), DFS
(5725 - 5875 @ 80), (N/A, 14), (N/A)
(57000 - 66000 @ 2160), (N/A, 40), (N/A)

phy#1
country US: DFS-FCC
(2402 - 2472 @ 40), (N/A, 30), (N/A)
(5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5735 - 5835 @ 80), (N/A, 30), (N/A)
(57240 - 63720 @ 2160), (N/A, 40), (N/A)

phy#0
country US: DFS-FCC
(2402 - 2472 @ 40), (N/A, 30), (N/A)
(5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5735 - 5835 @ 80), (N/A, 30), (N/A)
(57240 - 63720 @ 2160), (N/A, 40), (N/A)

global
country DE: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 20), (N/A)
(5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5725 @ 160), (N/A, 27), (0 ms), DFS
(5725 - 5875 @ 80), (N/A, 14), (N/A)
(57000 - 66000 @ 2160), (N/A, 40), (N/A)

Questions:

1. Why does LEDE show four regulatory domain blocks while OpenWrt shows
   only one?

2. What does the "country US: DFS-FCC" blocks tell me when radio is set
   to an ETSI region country (DE) according to uci?

3. What does AUTO-BW mean?

tnx, Charles


$uci export wireless

config wifi-device 'radio0'
option type 'mac80211'
option channel '11'
option hwmode '11g'
option path 'platform/ar934x_wmac'
option htmode 'HT20'
option country 'DE'

config wifi-iface
option device 'radio0'
option network 'lan'
option mode 'ap'
option ssid 'OpenWrt'
option encryption 'none'

config wifi-device 'radio1'
option type 'mac80211'
option hwmode '11a'
option path 'pci:00/:00:00.0'
option htmode 'HT20'
option country 'DE'
option channel '36'

config wifi-iface
option device 'radio1'
option network 'lan'
option mode 'ap'
option ssid 'OpenWrt'
option encryption 'none'




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

Re: [LEDE-DEV] [PATCHv2] ipq806x: add support for ZyXEL NBG6817

2016-10-19 Thread Felix Fietkau

Hi André,

On 2016-10-19 20:58, Andre Valentin wrote:
> Hi Felix!
> 
> Am 19.10.2016 um 12:40 schrieb Felix Fietkau:
>> On 2016-10-18 09:49, André Valentin wrote:
>>> Hi John,
>>>
>>> thanks for your comments. Please take a look:
>>>
>>> Am 18.10.2016 um 08:22 schrieb John Crispin:
>>>
> +++ b/target/linux/ipq806x/base-files/lib/preinit/04_set_mtd_ipq806x.sh
> @@ -0,0 +1,21 @@
> +#
> +# Copyright (C) 2009 OpenWrt.org
> +#
> +
> +. /lib/ipq806x.sh
> +. /lib/functions/system.sh
> +
> +preinit_assign_mtd2block() {
> + case $(ipq806x_board_name) in
> + nbg6817)
> + echo "/dev/mmcblk0p2,64KiB,romd" > 
> /sys/module/block2mtd/parameters/block2mtd
> + echo "/dev/mmcblk0p3,64KiB,header" > 
> /sys/module/block2mtd/parameters/block2mtd
> + echo "/dev/mmcblk0p4,64KiB,kernel" > 
> /sys/module/block2mtd/parameters/block2mtd
> + echo "/dev/mmcblk0p6,64KiB,header_1" > 
> /sys/module/block2mtd/parameters/block2mtd
> + echo "/dev/mmcblk0p7,64KiB,kernel_1" > 
> /sys/module/block2mtd/parameters/block2mtd
> + echo "/dev/mmcblk0p8,64KiB,rootfs_1" > 
> /sys/module/block2mtd/parameters/block2mtd
> + ;;
> + esac
> +}
> +

 can this not go into the commandline inside the devicetree ?
>>> I tried, but block2mtd accepts only one mapping in the command line.
>>>
>>> I will rework the patch the next days and send an update.
>> Why do we need block2mtd at all for this target?
> 
> The system uses an internal mmc for storage of root fs and other data. I saw 
> that the rb532 platform also uses block2mtd for this.
> With ubi on top of it, everything including sysupgrade worked nearly out of 
> the box. That's why I preferred to use existing parts.
> If you have another idea, please tell. For me it's my first mmc based 
> platform.
MMC is just a block device like any other. Please take a look at octeon,
mvebu or x86 as examples of how to do it without block2mtd.

Thanks,

- Felix


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

Re: [LEDE-DEV] [PATCHv2] ipq806x: add support for ZyXEL NBG6817

2016-10-19 Thread Andre Valentin

Hi Mathis,

thanks for your comments. I will change it according to your request!

André




smime.p7s
Description: S/MIME Cryptographic 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

2016-10-19 Thread Alexandru Ardelean

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.

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.

>
>
> 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?
>
> BTW, this is about SNMP agentx support for lldpd.
>
>
> Cheers,
> Zefir
>
>
> ___
> 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 1/1] package/utils: Add beep package

2016-10-19 Thread Chris Blake

This adds the "beep" binary as a package to LEDE. Note that busybox does
have a beep option that can be built in, but it is disabled by default
on all LEDE targets. This package gives users the option to manually
install beep at a later time, or include it as a default for a device
profile.

This was based on the older PR at https://lists.openwrt.org/pipermail
/openwrt-devel/2009-November/005226.html

Signed-off-by: Chris Blake 
---
 package/utils/beep/Makefile | 50 +
 1 file changed, 50 insertions(+)
 create mode 100644 package/utils/beep/Makefile

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.
+#
+
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=beep
+PKG_REV:=0d790fa45777896749a885c3b93b2c1476d59f20
+PKG_VERSION:=1.3
+PKG_RELEASE:=1
+
+PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
+PKG_SOURCE_URL:=https://github.com/johnath/beep.git
+PKG_SOURCE_PROTO:=git
+PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
+PKG_SOURCE_VERSION:=$(PKG_REV)
+
+PKG_LICENSE:=GPL
+PKG_LICENSE_FILES:=
+
+include $(INCLUDE_DIR)/package.mk
+
+define Package/beep
+  SECTION:=sound
+  CATEGORY:=Sound
+  DEPENDS:=+kmod-pcspkr
+  TITLE:=Play beep sounds through a PC speaker
+  URL:=http://johnath.com/beep/README
+endef
+
+define Package/beep/description
+   This program plays beeps through the PC speaker
+endef
+
+CONFIGURE_ARGS += \
+   --enable-static \
+   --enable-shared
+
+MAKE_FLAGS += \
+   CFLAGS="$(TARGET_CFLAGS)"
+
+define Package/beep/install
+   $(INSTALL_DIR) $(1)/usr/bin
+   $(INSTALL_BIN) $(PKG_BUILD_DIR)/beep $(1)/usr/bin
+endef
+
+$(eval $(call BuildPackage,beep))
--
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

2016-10-19 Thread Piotr Dymacz

Hello Gareth,

I will be back in ~2 weeks, there is no need to wait for me. You can
push your changes and I will update/rebase my patches later and
combine your code into one, common mach-*.c file.

Greetings from Japan!
Piotr

2016-10-19 18:56 GMT+09:00 Gareth Parker :
> Hi Piotr
> Thanks for your input, I have fixed up all the issues in my patch and was
> about to re-submit it, however having seen your email below what would be
> the best approach from here?
>
> I can submit my patch as is if you want?  Then you can move all comfast
> devices into one mach file later?
>
> I also have a cf-e355ac which I'm going to be submitting a patch for, plus
> my company is also going to be importing more comfast gear soon (outdoor
> high power ap's) and hence will be adding support for this also.
>
> Cheers,
>
> Gareth
>
> -Original Message-
> From: Lede-dev [mailto:lede-dev-boun...@lists.infradead.org] On Behalf Of
> Piotr Dymacz
> Sent: Wednesday, 19 October 2016 4:32 p.m.
> To: Gareth Parker
> Cc: LEDE Development List; gar...@zappie.net.nz
> Subject: Re: [LEDE-DEV] [PATCH] Add support for Comfast E380AC v1 and v2
>
> Hello Gareth,
>
> Please, take a look how I made support for other Comfast devices (QCA953x
> based) [1].
>
> I will rebase, update and send PR when I'm back from my holidays.
> Maybe we could keep everything in one mach-*.c file as there are some common
> parts, ex. timer for external watchdog.
>
> [1]
> https://github.com/pepe2k/lede-project-source/commit/9bb9b210ad483611304a2f6
> bcba418866b550e17
>
> Cheers,
> Piotr
>
> 2016-10-17 19:14 GMT+09:00 Gareth Parker :
>> 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.
>>
>> The factory firmware is built on openwrt and will accept a sysupgrade
> file, this patch produces two sysupgrade files for both versions.
>>
>> Signed-off-by: Gareth Parker 
>> ---
>>  target/linux/ar71xx/base-files/etc/diag.sh |4 +
>>  .../etc/hotplug.d/firmware/11-ath10k-caldata   |5 +
>>  target/linux/ar71xx/base-files/lib/ar71xx.sh   |6 +
>>  .../ar71xx/base-files/lib/upgrade/platform.sh  |   12 ++
>>  target/linux/ar71xx/config-4.4 |1 +
>>  .../ar71xx/files/arch/mips/ath79/Kconfig.openwrt   |   10 +
>>  target/linux/ar71xx/files/arch/mips/ath79/Makefile |1 +
>>  .../ar71xx/files/arch/mips/ath79/mach-cf-e380ac.c  |  197
> 
>>  .../linux/ar71xx/files/arch/mips/ath79/machtypes.h |2 +
>>  target/linux/ar71xx/image/generic.mk   |   18 ++
>>  10 files changed, 256 insertions(+)
>>  create mode 100644
>> target/linux/ar71xx/files/arch/mips/ath79/mach-cf-e380ac.c
>>
>> 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"
>> ;;
>> diff --git
>> a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-cald
>> ata
>> b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-cald
>> ata
>> index 0e93feb..7598a83 100644
>> ---
>> a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-cald
>> ata
>> +++ b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-
>> +++ caldata
>> @@ -47,6 +47,11 @@ board=$(ar71xx_board_name)  case "$FIRMWARE" in
>>  "ath10k/cal-pci-:00:00.0.bin")
>> case $board in
>> +   cf-e380ac-v1 | \
>> +   cf-e380ac-v2)
>> +   ath10kcal_extract "art" 20480 2116
>> +   ath10kcal_patch_mac $(macaddr_add $(cat
> /sys/class/net/eth0/address) +3)
>> +   ;;
>> dlan-pro-1200-ac)
>> ath10kcal_extract "art" 20480 2116
>> ;;
>> diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
>> b/target/linux/ar71xx/base-files/lib/ar71xx.sh
>> index dae6fb2..fb017f5 100755
>> --- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
>> +++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
>> @@ -488,6 +488,12 @@ ar71xx_board_detect() {
>> *"COMFAST CF-E316N v2")
>> name="cf-e316n-v2"
>> ;;
>> +   *"COMFAST CF-E380AC-V1")
>> +   name="cf-e380ac-v1"
>> +   ;;
>> +   *"COMFAST CF-E380AC-V2")
>> +   name="cf-e380ac-v2"
>> +   ;;
>>

Re: [LEDE-DEV] [PATCHv2] ipq806x: add support for ZyXEL NBG6817

2016-10-19 Thread Felix Fietkau

On 2016-10-18 09:49, André Valentin wrote:
> Hi John,
> 
> thanks for your comments. Please take a look:
> 
> Am 18.10.2016 um 08:22 schrieb John Crispin:
> 
>>> +++ b/target/linux/ipq806x/base-files/lib/preinit/04_set_mtd_ipq806x.sh
>>> @@ -0,0 +1,21 @@
>>> +#
>>> +# Copyright (C) 2009 OpenWrt.org
>>> +#
>>> +
>>> +. /lib/ipq806x.sh
>>> +. /lib/functions/system.sh
>>> +
>>> +preinit_assign_mtd2block() {
>>> +   case $(ipq806x_board_name) in
>>> +   nbg6817)
>>> +   echo "/dev/mmcblk0p2,64KiB,romd" > 
>>> /sys/module/block2mtd/parameters/block2mtd
>>> +   echo "/dev/mmcblk0p3,64KiB,header" > 
>>> /sys/module/block2mtd/parameters/block2mtd
>>> +   echo "/dev/mmcblk0p4,64KiB,kernel" > 
>>> /sys/module/block2mtd/parameters/block2mtd
>>> +   echo "/dev/mmcblk0p6,64KiB,header_1" > 
>>> /sys/module/block2mtd/parameters/block2mtd
>>> +   echo "/dev/mmcblk0p7,64KiB,kernel_1" > 
>>> /sys/module/block2mtd/parameters/block2mtd
>>> +   echo "/dev/mmcblk0p8,64KiB,rootfs_1" > 
>>> /sys/module/block2mtd/parameters/block2mtd
>>> +   ;;
>>> +   esac
>>> +}
>>> +
>> 
>> can this not go into the commandline inside the devicetree ?
> I tried, but block2mtd accepts only one mapping in the command line.
> 
> I will rework the patch the next days and send an update.
Why do we need block2mtd at all for this target?

- Felix

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

Re: [LEDE-DEV] Reproducible builds & feeds

2016-10-19 Thread Jonas Gorski

Hi,

On 15 October 2016 at 17:32, Rafał Miłecki  wrote:
> Hi,
>
> After Holger & Alexander talk at OpenWrt Summit I started thinking
> about handling feeds in LEDE. Right now we simply point to external
> repositories within feeds.conf(.default):
> src-git packages https://git.lede-project.org/feed/packages.git
> src-git luci https://git.lede-project.org/project/luci.git
> src-git routing https://git.lede-project.org/feed/routing.git
> src-git telephony https://git.lede-project.org/feed/telephony.git
>
> I see few problems with this solution:
>
> 1) No info on used feeds revisions
> Problem: When you get an image you can't say which revisions of feeds
> were used to build it.
> Possible solution: Include some extra file with info about each feed
> and used revision

Not sure yet how much this is actually helps/makes sense. Usually
images do not contain packages from feeds, just from base packages,
and the packages in the feeds might have been updated since
downloading the image. The info might be better stored along side the
actual feeds, not in the image. Note that you also don't get a .config
in your image, so if e.g. kernel options were changed you won't be
able to reproduce it either (unless you correctly guess the options).

> 2) No pointing specific revision
> Problem: We always use the latest revision of each feed. It's easy to
> hit some problem/regression introduced in a feed without an easy way
> of tracking it down. You have to guess which was the latest working
> revision.
> Possible solution: Always point specific revision in
> feeds.conf.default, e.g. src-git packages
> https://git.lede-project.org/feed/packages.git^commithash .
> Unfortunately this will require us to update this file over and over.

Yeah, I don't think this is a healthy way of doing it, unless we have
a bot that does that every X hours or so. And that leads to a lot of
noise in the commit log. At most it might makes sense for release
(-candidate) branches, where we want to be careful which feeds
revisions we do want to build.

> 3) The way of specifying revisions
> Problem: This is only possible with manually creating a proper
> feeds.conf. I'm wondering if this would make sense to make is somehow
> more script friendly? Alexander, Holger: what do you think about this?
> Possible solution: Implement solution suggested in problem 2 or maybe
> add support for some env variable(s) pointing revision(s)?

For making this easier I added the ability for scripts/feeds to give
you the current feeds with their revisions a while ago in the expected
format, e.g.

# ./scripts/feeds list -s -f
src-git packages https://git.lede-project.org/feed/packages.git^144812d
src-git luci https://git.lede-project.org/project/luci.git^6be6904
src-git routing https://git.lede-project.org/feed/routing.git^fe8fa0b
src-git telephony https://git.lede-project.org/feed/telephony.git^1f0fb25

Adding this to along side the config. we ... used to provide
should make it much easier to reproduce a build (then I guess as a
feeds. or so in phase2).

> I think the problem that really needs solving is the first one. The
> rest we can probably just discuss (hint: waiting for your opinions).
> Right now it's not possible/easy to rebuild image I got downloaded.
> Even if I'm ready to create my own feeds.conf I don't know what
> revisions to put there. Also please note this is only an introduction
> to have binary reproducible builds.

Maybe we could add a step in the build that at the end that will
compile all build info, i.e. revision of the repo, revisions of the
feeds, minimized config, and put it along side the images / packages.

Regards
Jonas

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

Re: [LEDE-DEV] [PATCH V2 3/3] kernel: drop usbdev LED trigger

2016-10-19 Thread Rafał Miłecki

On 13 October 2016 at 09:44, Rafał Miłecki  wrote:
> From: Rafał Miłecki 
>
> It was LEDE's trigger that was replaced by upstream usbport one.
>
> Signed-off-by: Rafał Miłecki 

Pushed with removal of ledtrig-usbdev from package/kernel/linux/modules/leds.mk.

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

Re: [LEDE-DEV] [PATCH V2 2/3] switch to the new usbport LED trigger

2016-10-19 Thread Rafał Miłecki

On 13 October 2016 at 09:44, Rafał Miłecki  wrote:
> From: Rafał Miłecki 
>
> This makes init.d script handle existing UCI entries using the new
> trigger. It also switches all targets to use its package.
>
> Signed-off-by: Rafał Miłecki 

Pushed with code moved out of switch for cleaner code sharing with
usbport trigger. Also added comments to make it clear what sed
commands are for.

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

Re: [LEDE-DEV] [PATCHv2] ipq806x: add support for ZyXEL NBG6817

2016-10-19 Thread Mathias Kresin


17.10.2016 21:22, André Valentin:

CPU: 1.8GHz ARM, RAM: 512MB
Storage: 4MiB Serial Flash, 3.9GiB MMC
NIC: 2x1GBit/s, 5 external and 2 internal Port Switch
WiFi: Dualband, ATH10k 2.4GHz, 5GHz MU-MIMO

Changes:
-remove kernel compression changes
-give spi-nor.c patch a correct name

Signed-off-by: André Valentin 
---


...


diff --git 
a/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8065-nbg6817.dts 
b/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8065-nbg6817.dts
new file mode 100644
index 000..2e1302d
--- /dev/null
+++ b/target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8065-nbg6817.dts
@@ -0,0 +1,338 @@
+#include "qcom-ipq8065-v1.0.dtsi"
+
+#include 
+
+/ {
+   model = "ZyXEL NBG6817";
+   compatible = "zyxel,nbg6817", "qcom,ipq8065";
+
+   memory@0 {
+   reg = <0x4200 0x1e00>;
+   device_type = "memory";
+   };
+
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   rsvd@4120 {
+   reg = <0x4120 0x30>;
+   no-map;
+   };
+   };
+
+   aliases {
+   serial0 = 
+   mdio-gpio0 = 
+   sdcc1 = 
+   };
+
+   chosen {
+   bootargs = "rootfstype=squashfs noinitrd 
block2mtd.block2mtd=/dev/mmcblk0p5,65536,ubi,5 ubi.mtd=ubi";
+   linux,stdout-path = "serial0:115200n8";
+   };
+
+   soc {
+   pinmux@80 {
+   pinctrl-0 = <_pins _pins>;
+   pinctrl-names = "default";
+
+   i2c4_pins: i2c4_pinmux {
+   mux {
+   pins = "gpio12", "gpio13";
+   function = "gsbi4";
+   drive-strength = <12>;
+   bias-disable;
+   };
+   };
+
+   mdio0_pins: mdio0_pins {
+   mux {
+   pins = "gpio0", "gpio1";
+   function = "gpio";
+   drive-strength = <8>;
+   bias-disable;
+   };
+
+   clk {
+   pins = "gpio1";
+   input-disable;
+   };
+   };
+
+   rgmii2_pins: rgmii2_pins {
+   mux {
+   pins = "gpio27", "gpio28", "gpio29", "gpio30", 
"gpio31", "gpio32",
+  "gpio51", "gpio52", "gpio59", "gpio60", 
"gpio61", "gpio62" ;
+   function = "rgmii2";
+   drive-strength = <8>;
+   bias-disable;
+   };
+
+   tx {
+   pins = "gpio27", "gpio28", "gpio29", "gpio30", 
"gpio31", "gpio32" ;
+   input-disable;
+   };
+   };
+
+   spi_pins: spi_pins {
+   mux {
+   pins = "gpio18", "gpio19", "gpio21";
+   function = "gsbi5";
+   drive-strength = <10>;
+   bias-none;
+   };
+
+   cs {
+   pins = "gpio20";
+   drive-strength = <12>;
+   };
+   };
+   };
+
+   gsbi@1630 {
+   qcom,mode = ;
+   status = "ok";
+   serial@1634 {
+   status = "ok";
+   };
+   /*
+* The i2c device on gsbi4 should not be enabled.
+* On ipq806x designs gsbi4 i2c is meant for exclusive
+* RPM usage. Turning this on in kernel manifests as
+* i2c failure for the RPM.
+*/
+   };
+
+   gsbi5: gsbi@1a20 {
+   qcom,mode = ;
+   status = "ok";
+
+   spi4: spi@1a28 {
+   status = "ok";
+   spi-max-frequency = <5000>;
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";

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

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

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

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

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

Re: [LEDE-DEV] [PATCH 1/1] package/utils: Add beep package

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

[LEDE-DEV] regulatory domain information

Re: [LEDE-DEV] [PATCHv2] ipq806x: add support for ZyXEL NBG6817

Re: [LEDE-DEV] [PATCHv2] ipq806x: add support for ZyXEL NBG6817

Re: [LEDE-DEV] Need help with package dependencies

[LEDE-DEV] [PATCH 1/1] package/utils: Add beep package

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

Re: [LEDE-DEV] [PATCHv2] ipq806x: add support for ZyXEL NBG6817

Re: [LEDE-DEV] Reproducible builds & feeds

Re: [LEDE-DEV] [PATCH V2 3/3] kernel: drop usbdev LED trigger

Re: [LEDE-DEV] [PATCH V2 2/3] switch to the new usbport LED trigger

Re: [LEDE-DEV] [PATCHv2] ipq806x: add support for ZyXEL NBG6817

18 matches

Site Navigation

Mail list logo

Footer information