Re: [LEDE-DEV] Dependency issues on custom packages and USE_MUSL visibility
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
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
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
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
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 += asus-wl-320gp + + define Device/asus-
Re: [LEDE-DEV] [PATCH v2] base-files: ensure reset only works if an overlay exists
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
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
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
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
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] base-files: ensure reset only works if an overlay exists
19.10.2016 16:54, 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. 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 Since you are not really interested in the matches, you can use the exit code as indicator for found/not found: if [ "$SEEN" -gt 5 ] && grep -q ' /overlay ' /proc/mounts then Not sure if it should be done this way since it might be hard to read. Mathias ___ 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
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
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
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] [PATCH] base-files: ensure reset only works if an overlay exists
* 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: sysfixtime: Allow system time in local timezones
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 :-) -- ynezz ___ 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 2016-10-19 21:38, Petr Štetiar wrote: > Felix Fietkau [2016-10-18 23:25:40]: > >> On 2016-10-18 23:11, Petr Štetiar wrote: >> > Currently we're forced to have system time in the UTC timezone as >> > hardware clock, mainly because kernel expects in rtc_hctosys(), that RTC >> > time is held in UTC timezone. >> > >> > With this patch one can now have local system time for example in CEST >> > timezone and RTC time still in UTC with boolean config option `rtc_utc`. >> > >> Why? > > Would this be a better commit message? > > I'm using devices which have battery backed RTC. Sometime I need to use local > timezone for system time as for example CEST(UTC+2) timezone. I'd like to know why you need to use local time for the RTC, I think that's rather uncommon. - 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
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] [PATCH] base-files: sysfixtime: Allow system time in local timezones
Felix Fietkau [2016-10-18 23:25:40]: > On 2016-10-18 23:11, Petr Štetiar wrote: > > Currently we're forced to have system time in the UTC timezone as > > hardware clock, mainly because kernel expects in rtc_hctosys(), that RTC > > time is held in UTC timezone. > > > > With this patch one can now have local system time for example in CEST > > timezone and RTC time still in UTC with boolean config option `rtc_utc`. > > > Why? Would this be a better commit message? I'm using devices which have battery backed RTC. Sometime I need to use local timezone for system time as for example CEST(UTC+2) timezone. The problem is, that as soon as I enable CEST timezone for system time, the battery backed RTC clock gets screwed with every graceful reboot as the sysfixtime script writes system time to RTC in system's CEST timezone instead in UTC. Linux kernel on next reboot expects time from RTC to be in UTC, but the time is there already in CEST resulting in screwed clock. -- ynezz ___ 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
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.
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] [PATCHv2] ipq806x: add support for ZyXEL NBG6817
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
[LEDE-DEV] [PATCH 1/3] ar71xx: Move MR12 & MR16 from legacy to generic
This moves the Meraki MR12 and Meraki MR16 to the new generic target. Tested and verified working on both devices. Note that kernel/rootfs images are still generated. This is because they are used for the inital flashing process due to the fun pace at which UBoot erases/writes to SPI. Signed-off-by: Chris Blake --- target/linux/ar71xx/image/generic.mk| 26 ++ target/linux/ar71xx/image/legacy-devices.mk | 12 target/linux/ar71xx/image/legacy.mk | 2 -- 3 files changed, 26 insertions(+), 14 deletions(-) diff --git a/target/linux/ar71xx/image/generic.mk b/target/linux/ar71xx/image/generic.mk index 192f1a7..04fed88 100644 --- a/target/linux/ar71xx/image/generic.mk +++ b/target/linux/ar71xx/image/generic.mk @@ -97,6 +97,32 @@ define Device/gl-mifi endef TARGET_DEVICES += gl-mifi +define Device/mr12 + DEVICE_TITLE := Meraki MR12 + DEVICE_PACKAGES := kmod-spi-gpio + BOARDNAME = MR12 + IMAGE_SIZE = 15744k + MTDPARTS = spi0.0:256k(u-boot)ro,256k(u-boot-env)ro,13440k(rootfs),2304k(kernel),128k(art)ro,15744k@0x8(firmware) + IMAGE/kernel.bin = append-kernel + IMAGE/rootfs.bin = append-rootfs | pad-rootfs + IMAGE/sysupgrade.bin = append-rootfs | pad-rootfs | pad-to 13440k | append-kernel | check-size (IMAGE_SIZE) + IMAGES := kernel.bin rootfs.bin sysupgrade.bin +endef +TARGET_DEVICES += mr12 + +define Device/mr16 + DEVICE_TITLE := Meraki MR16 + DEVICE_PACKAGES := kmod-spi-gpio + BOARDNAME = MR16 + IMAGE_SIZE = 15744k + MTDPARTS = spi0.0:256k(u-boot)ro,256k(u-boot-env)ro,13440k(rootfs),2304k(kernel),128k(art)ro,15744k@0x8(firmware) + IMAGE/kernel.bin = append-kernel + IMAGE/rootfs.bin = append-rootfs | pad-rootfs + IMAGE/sysupgrade.bin = append-rootfs | pad-rootfs | pad-to 13440k | append-kernel | check-size (IMAGE_SIZE) + IMAGES := kernel.bin rootfs.bin sysupgrade.bin +endef +TARGET_DEVICES += mr16 + define Device/dr531 DEVICE_TITLE := Wallys DR531 DEVICE_PACKAGES := kmod-usb-core kmod-usb2 diff --git a/target/linux/ar71xx/image/legacy-devices.mk b/target/linux/ar71xx/image/legacy-devices.mk index 2af7598..8522f9e 100644 --- a/target/linux/ar71xx/image/legacy-devices.mk +++ b/target/linux/ar71xx/image/legacy-devices.mk @@ -185,18 +185,6 @@ define LegacyDevice/HORNETUBx2 endef LEGACY_DEVICES += HORNETUBx2 -define LegacyDevice/MR12 - DEVICE_TITLE := Meraki MR12 - DEVICE_PACKAGES := kmod-spi-gpio -endef -LEGACY_DEVICES += MR12 - -define LegacyDevice/MR16 - DEVICE_TITLE := Meraki MR16 - DEVICE_PACKAGES := kmod-spi-gpio -endef -LEGACY_DEVICES += MR16 - define LegacyDevice/PB92 DEVICE_TITLE := Atheros PB92 reference board DEVICE_PACKAGES := kmod-usb-core kmod-usb2 diff --git a/target/linux/ar71xx/image/legacy.mk b/target/linux/ar71xx/image/legacy.mk index 14de229..5aff130 100644 --- a/target/linux/ar71xx/image/legacy.mk +++ b/target/linux/ar71xx/image/legacy.mk @@ -271,8 +271,6 @@ ew-dorin_mtdlayout_16M=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env),16000k(fir f9k1115v2_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env),14464k(rootfs),1408k(kernel),64k(nvram)ro,64k(envram)ro,64k(art)ro,15872k@0x5(firmware) dlrtdev_mtdlayout=mtdparts=spi0.0:256k(uboot)ro,64k(config)ro,6208k(firmware),64k(caldata)ro,640k(certs),960k(unknown)ro,64k@0x7f(caldata_copy) dlrtdev_mtdlayout_fat=mtdparts=spi0.0:256k(uboot)ro,64k(config)ro,7168k(firmware),640k(certs),64k(caldata)ro,64k@0x66(caldata_orig),6208k@0x5(firmware_orig) -mr12_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,256k(u-boot-env)ro,13440k(rootfs),2304k(kernel),128k(art)ro,15744k@0x8(firmware) -mr16_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,256k(u-boot-env)ro,13440k(rootfs),2304k(kernel),128k(art)ro,15744k@0x8(firmware) pb92_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,2752k(rootfs),896k(kernel),64k(nvram),64k(art)ro,3648k@0x5(firmware) planex_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,7744k(firmware),128k(art)ro ubntxm_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,7552k(firmware),256k(cfg)ro,64k(EEPROM)ro -- 2.7.4 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 3/3] ar71xx: Remove switch config for the MR12/MR16
These boards do not have a switch, so they should have never been added to this file in the first place. Signed-off-by: Chris Blake --- .../ar71xx/base-files/etc/uci-defaults/03_network-switchX-migration | 2 -- 1 file changed, 2 deletions(-) diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/03_network-switchX-migration b/target/linux/ar71xx/base-files/etc/uci-defaults/03_network-switchX-migration index ee8f63b..c6b91b7 100644 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/03_network-switchX-migration +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/03_network-switchX-migration @@ -61,8 +61,6 @@ dir-615-c1|\ dir-615-e1|\ dir-615-e4|\ ja76pf|\ -mr-12|\ -mr-16|\ rb-750|\ rb-751|\ tew-632brp|\ -- 2.7.4 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 2/3] ar71xx: add mac partition to the MR12/MR16
On the stock Meraki Firmare for the MR12/MR16, a chunk of SPI space
after u-boot-env is used to store the boards Mac address. Sadly as this
was removed on any device already on OpenWRT/LEDE, moving forward a new,
64k partition named "mac" will be used to store the mac address for the
device (which is the minimum size). This allows users to properly set
the correct MAC, without editing the ART partition (which holds the same
MAC for all devices).
The reason the space is taken from kernel instead of rootfs is currently
kernels are only 1.3MB, so that way we can leave the current rootfs
space alone for users who fully utilize the available storage space.
Once this partition is added to a device, you can set your MAC doing the
following:
mtd erase mac
echo -n -e '\x00\x18\x0a\x33\x44\x55' > /dev/mtd5
sync && reboot
Where 00:18:0a:33:44:55 is your MAC address.
This was tested, and confirmed working on both the MR12 and MR16.
Signed-off-by: Chris Blake
---
.../linux/ar71xx/files/arch/mips/ath79/mach-mr12.c | 14 +++---
.../linux/ar71xx/files/arch/mips/ath79/mach-mr16.c | 22 +++---
target/linux/ar71xx/image/generic.mk | 4 ++--
3 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-mr12.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-mr12.c
index 12c9a1c..dc880c5 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-mr12.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-mr12.c
@@ -42,8 +42,7 @@
#define MR12_WAN_PHYMASKBIT(4)
-#define MR12_WMAC0_MAC_OFFSET 0x120c
-#define MR12_CALDATA0_OFFSET0x1000
+#define MR12_CALDATA0_OFFSET0x21000
static struct gpio_led MR12_leds_gpio[] __initdata = {
{
@@ -90,8 +89,9 @@ static struct gpio_keys_button MR12_gpio_keys[] __initdata = {
static void __init MR12_setup(void)
{
- u8 *mac = (u8 *) KSEG1ADDR(0xbfff);
-
+ u8 *mac = (u8 *) KSEG1ADDR(0xbffd);
+ u8 WLAN0_MAC[ETH_ALEN];
+
ath79_register_mdio(0,0x0);
ath79_init_mac(ath79_eth0_data.mac_addr, mac, 0);
@@ -107,9 +107,9 @@ static void __init MR12_setup(void)
ARRAY_SIZE(MR12_gpio_keys),
MR12_gpio_keys);
- ap91_pci_init(mac + MR12_CALDATA0_OFFSET,
- mac + MR12_WMAC0_MAC_OFFSET);
+ ath79_init_mac(WLAN0_MAC, mac, 1);
+ ap91_pci_init(mac + MR12_CALDATA0_OFFSET, WLAN0_MAC);
}
-MIPS_MACHINE(ATH79_MACH_MR12, "MR12", "Meraki MR12", MR12_setup);
\ No newline at end of file
+MIPS_MACHINE(ATH79_MACH_MR12, "MR12", "Meraki MR12", MR12_setup);
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-mr16.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-mr16.c
index 9f08e3d..2897ee5 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-mr16.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-mr16.c
@@ -42,10 +42,8 @@
#define MR16_WAN_PHYMASKBIT(0)
-#define MR16_WMAC0_MAC_OFFSET 0x120c
-#define MR16_WMAC1_MAC_OFFSET 0x520c
-#define MR16_CALDATA0_OFFSET 0x1000
-#define MR16_CALDATA1_OFFSET 0x5000
+#define MR16_CALDATA0_OFFSET 0x21000
+#define MR16_CALDATA1_OFFSET 0x25000
static struct gpio_led MR16_leds_gpio[] __initdata = {
{
@@ -92,8 +90,10 @@ static struct gpio_keys_button MR16_gpio_keys[] __initdata =
{
static void __init MR16_setup(void)
{
- u8 *mac = (u8 *) KSEG1ADDR(0xbfff);
-
+ u8 *mac = (u8 *) KSEG1ADDR(0xbffd);
+ u8 WLAN0_MAC[ETH_ALEN];
+ u8 WLAN1_MAC[ETH_ALEN];
+
ath79_register_mdio(0,0x0);
ath79_init_mac(ath79_eth0_data.mac_addr, mac, 0);
@@ -109,10 +109,10 @@ static void __init MR16_setup(void)
ARRAY_SIZE(MR16_gpio_keys),
MR16_gpio_keys);
- ap94_pci_init(mac + MR16_CALDATA0_OFFSET,
- mac + MR16_WMAC0_MAC_OFFSET,
- mac + MR16_CALDATA1_OFFSET,
- mac + MR16_WMAC1_MAC_OFFSET);
+ ath79_init_mac(WLAN0_MAC, mac, 1);
+ ath79_init_mac(WLAN1_MAC, mac, 2);
+ ap94_pci_init(mac + MR16_CALDATA0_OFFSET, WLAN0_MAC,
+ mac + MR16_CALDATA1_OFFSET, WLAN1_MAC);
}
-MIPS_MACHINE(ATH79_MACH_MR16, "MR16", "Meraki MR16", MR16_setup);
\ No newline at end of file
+MIPS_MACHINE(ATH79_MACH_MR16, "MR16", "Meraki MR16", MR16_setup);
diff --git a/target/linux/ar71xx/image/generic.mk
b/target/linux/ar71xx/image/generic.mk
index 04fed88..ee910af 100644
--- a/target/linux/ar71xx/image/generic.mk
+++ b/target/linux/ar71xx/image/generic.mk
@@ -102,7 +102,7 @@ define Device/mr12
DEVICE_PACKAGES := kmod-spi-gpio
BOARDNAME = MR12
IMAGE_SIZE = 15744k
- MTDPARTS =
spi0.0:256k(u-boot)ro,256k(u-boot-env)ro,13440k(rootfs),2304k(kernel),128k(art)ro,15744k@0x8(firmware)
+ MTDPARTS =
spi0.0:256k(u-boot)ro,2
Re: [LEDE-DEV] Need help with package dependencies
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
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
[LEDE-DEV] [PATCH] base-files: ensure reset only works if an overlay exists
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 -- 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
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"
>> + ;;
>> *"CPE210/220")
>> name="cpe210"
>> tpl
[LEDE-DEV] [PATCH] base-files: add ucidef_set_led_usbport for full usbport support
From: Rafał Miłecki
This helper allows using usbport trigger directly. It requires usbport
compatible syntax and supports specifying multiple USB ports, e.g.:
ucidef_set_led_usbport "usb" "USB" "devicename:colour:function" "usb1-port1"
"usb2-port1"
This adds a proper object to the board.json, e.g.
"usb": {
"name": "USB",
"type": "usbport",
"sysfs": "devicename:colour:function",
"ports": [
"usb1-port1",
"usb2-port1"
]
}
and supports translating it into uci section.
Signed-off-by: Rafał Miłecki
---
package/base-files/files/bin/config_generate | 9
package/base-files/files/etc/init.d/led| 1 +
.../base-files/files/lib/functions/uci-defaults.sh | 24 ++
3 files changed, 34 insertions(+)
diff --git a/package/base-files/files/bin/config_generate
b/package/base-files/files/bin/config_generate
index 80e5c9f..13ddb07 100755
--- a/package/base-files/files/bin/config_generate
+++ b/package/base-files/files/bin/config_generate
@@ -335,6 +335,15 @@ generate_led() {
EOF
;;
+ usbport)
+ local ports port
+ json_get_values ports ports
+ uci set system.$cfg.trigger='usbport'
+ for port in $ports; do
+ uci add_list system.$cfg.port=$port
+ done
+ ;;
+
rssi)
local iface minq maxq offset factor
json_get_vars iface minq maxq offset factor
diff --git a/package/base-files/files/etc/init.d/led
b/package/base-files/files/etc/init.d/led
index 9a793e9..7c2a185 100755
--- a/package/base-files/files/etc/init.d/led
+++ b/package/base-files/files/etc/init.d/led
@@ -19,6 +19,7 @@ load_led() {
config_get name $1 name "$sysfs"
config_get trigger $1 trigger "none"
config_get dev $1 dev
+ config_get ports $1 port
config_get mode $1 mode "link"
config_get_bool default $1 default "nil"
config_get delayon $1 delayon
diff --git a/package/base-files/files/lib/functions/uci-defaults.sh
b/package/base-files/files/lib/functions/uci-defaults.sh
index a88308b..e39b0a5 100755
--- a/package/base-files/files/lib/functions/uci-defaults.sh
+++ b/package/base-files/files/lib/functions/uci-defaults.sh
@@ -390,6 +390,30 @@ ucidef_set_led_usbdev() {
json_select ..
}
+ucidef_set_led_usbport() {
+ local obj="$1"
+ local name="$2"
+ local sysfs="$3"
+ shift
+ shift
+ shift
+
+ json_select_object led
+
+ json_select_object "$obj"
+ json_add_string name "$name"
+ json_add_string type usbport
+ json_add_string sysfs "$sysfs"
+ json_select_array ports
+ for port in "$@"; do
+ json_add_string port "$port"
+ done
+ json_select ..
+ json_select ..
+
+ json_select ..
+}
+
ucidef_set_led_wlan() {
local cfg="led_$1"
local name="$2"
--
2.9.3
___
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
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
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
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
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
[LEDE-DEV] [PATCH] blobmsg_json: handle conversion of large integers from JSON
Currently, libubox uses json_object_get_int when converting a JSON
document into a blobmsg. However, json-c stores integers as int64_t
values and may clamp the value when asked to return it as an int32_t.
Always use json_object_get_int64 and use a u32/u64 blobmsg value
depending on the magnitude of the returned value.
Signed-off-by: Florian Larysch
---
blobmsg_json.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/blobmsg_json.c b/blobmsg_json.c
index 8a6ed8f..1ae4954 100644
--- a/blobmsg_json.c
+++ b/blobmsg_json.c
@@ -47,6 +47,7 @@ static bool blobmsg_add_array(struct blob_buf *b, struct
array_list *a)
bool blobmsg_add_json_element(struct blob_buf *b, const char *name,
json_object *obj)
{
bool ret = true;
+ int64_t n;
void *c;
switch (json_object_get_type(obj)) {
@@ -67,7 +68,13 @@ bool blobmsg_add_json_element(struct blob_buf *b, const char
*name, json_object
blobmsg_add_u8(b, name, json_object_get_boolean(obj));
break;
case json_type_int:
- blobmsg_add_u32(b, name, json_object_get_int(obj));
+ n = json_object_get_int64(obj);
+
+ if (n >= INT32_MIN && n <= INT32_MAX)
+ blobmsg_add_u32(b, name, n);
+ else
+ blobmsg_add_u64(b, name, n);
+
break;
case json_type_null:
blobmsg_add_field(b, BLOBMSG_TYPE_UNSPEC, name, NULL, 0);
--
2.10.0
___
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
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"
> + ;;
> *"CPE210/220")
> name="cpe210"
> tplink_pharos_board_detect diff --git
> a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> index 559f97d..2463587 100755
> --- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> @@ -495,6 +495,16 @@ platform_check_image() {
> alfa_check_image "$1" && return 0
>
Re: [LEDE-DEV] [PATCHv2] ipq806x: add support for ZyXEL NBG6817
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 = &uart4;
+ mdio-gpio0 = &mdio0;
+ sdcc1 = &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 = <&mdio0_pins &rgmii2_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 = <&spi_pins>;
+ pinctrl-name
