[LEDE-DEV] [PATCH] scripts/getver.sh: treat all commits as local if can't find upstream

[Rafał Miłecki]

From: Rafał Miłecki 

If something goes wrong and script can't find upstream revision it will
return something like:
r2220
which looks like a valid upstream revision 2220. We cant' distinguish it
from e.g. 2200 upstream commits and 20 local ones.

The new format still provides revision number but also points clearly
that is may be not the upstream one:
r0+2220

Signed-off-by: Rafał Miłecki 
---
 scripts/getver.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/getver.sh b/scripts/getver.sh
index 9b84602..2fd6adb 100755
--- a/scripts/getver.sh
+++ b/scripts/getver.sh
@@ -33,7 +33,7 @@ try_git() {
UPSTREAM_BASE="$(git merge-base $GET_REV $ORIGIN)"
UPSTREAM_REV="$(git rev-list --count 
${REBOOT}..$UPSTREAM_BASE)"
else
-   UPSTREAM_REV=$REV
+   UPSTREAM_REV=0
fi
 
if [ "$REV" -gt "$UPSTREAM_REV" ]; then
-- 
2.10.1


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

[LEDE-DEV] [PATCH] scripts/getver.sh: use --count for git rev-list to count commits

[Rafał Miłecki]

From: Rafał Miłecki 

It should be faster than printing them and piping to the wc.

Signed-off-by: Rafał Miłecki 
---
 scripts/getver.sh | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/scripts/getver.sh b/scripts/getver.sh
index e718485..9b84602 100755
--- a/scripts/getver.sh
+++ b/scripts/getver.sh
@@ -20,18 +20,18 @@ try_git() {
case "$GET_REV" in
r*)
GET_REV="$(echo $GET_REV | tr -d 'r')"
-   BASE_REV="$(git rev-list ${REBOOT}..HEAD | wc -l | awk '{print 
$1}')"
+   BASE_REV="$(git rev-list --count ${REBOOT}..HEAD)"
REV="$(git rev-parse HEAD~$((BASE_REV - GET_REV)))"
;;
*)
BRANCH="$(git rev-parse --abbrev-ref HEAD)"
ORIGIN="$(git rev-parse --verify --symbolic-full-name 
${BRANCH}@{u} 2>/dev/null)"
[ -n "$ORIGIN" ] || ORIGIN="$(git rev-parse --verify 
--symbolic-full-name master@{u} 2>/dev/null)"
-   REV="$(git rev-list ${REBOOT}..$GET_REV | wc -l | awk '{print 
$1}')"
+   REV="$(git rev-list --count ${REBOOT}..$GET_REV)"
 
if [ -n "$ORIGIN" ]; then
UPSTREAM_BASE="$(git merge-base $GET_REV $ORIGIN)"
-   UPSTREAM_REV="$(git rev-list ${REBOOT}..$UPSTREAM_BASE 
| wc -l | awk '{print $1}')"
+   UPSTREAM_REV="$(git rev-list --count 
${REBOOT}..$UPSTREAM_BASE)"
else
UPSTREAM_REV=$REV
fi
-- 
2.10.1


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

Re: [LEDE-DEV] [PATCH] mt7621: add support for WeVO W2914NS v2

[perillamint]

Hi, Mathias Kresin.

It seems its Ethernet LEDs are directly hooked into switch chip. It
flashes without defining them in DTB. I dunno about where WLAN LEDs are
hooked. I failed to drive them with sysfs gpio driver.

I tried LED blinker script in

https://wiki.openwrt.org/doc/hardware/port.gpio

and it only blinked USB LED. So, I added that LED only.

Is there any way to discover how to turn on that two WiFi LEDs?


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

Re: [LEDE-DEV] FCC killing open platforms and inovations [Was: Re: [PATCH] ar71xx: Add usable, inactive LEDs on OpenMesh devices]

[Simon Wunderlich]

Hi David,

On Tuesday, November 15, 2016 4:49:40 PM CET David Lang wrote:
> > Well, we are. We can't change the fact that the devices need to be locked
> > to be sold in the US. But if you google a little, you will find a lot of
> > patches for various Open Source projects signed by @open-mesh.com mail
> > addresses (LEDE, Linux, hostapd, etc) ... Feel free to compare that with
> > other WiFi vendors. I don't think we are doing that bad. :)
> 
> except that they don't need to be locked down to be sold in the US.
> 
> The FCC posted a proposed rule that would require such a lockdown, but then
> have repeatedly made public statements that they do not intend to prevent
> different firmware from being loaded on the devices and the proposed rule
> that would have required lockdowns have basically been stopped.
> 
> However, multiple vendors are imposing restriction and claiming that the FCC
> is requiring them, even after the FCC says that it's not.

You are right, the FCC doesn't explicitly requires to prevent third-party 
firmware loading anymore. However, they still require to explain how a vendor 
makes sure that US RF limits are not violated [1]. Since a third-party firmware 
can be anything including a firmware with a patched ath9k where DFS is disabled 
etc, we (as Open-Mesh) can't really prevent that those RF limits are violated. 
Thus we can not give a convincing explanation there, and the situation stays 
the same.

If you have any constructive idea, I would love to propose it internally.

Thanks,
 Simon

[1] From https://apps.fcc.gov/kdb/GetAttachment.html?id=zXtrctoj6zH7oNEOO6De6g
%3D%3D=594280%20D02%20U-NII%20Device%20Security
%20v01r03_number=39498

"Describe, if the device permits third-party software or firmware installation, 
what mechanisms are provided by the manufacturer to permit integration of
such functions while ensuring that the RF parameters of the device cannot be 
operated outside its authorization for operation in the U.S .  In the 
description include what controls and/or agreements are in place with 
providers of third-party functionality to ensure  the devices’ underlying RF 
parameters are unchanged and how the manufacturer verifies the functionality. "

signature.asc
Description: This is a digitally signed message part.
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] kernel: enable pcrypt

[Jason A. Donenfeld]

On Wed, Nov 16, 2016 at 8:35 PM, Felix Fietkau  wrote:
> It's in my staging tree and will make it to the main repo soon.

Good to hear. Thanks.

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

Re: [LEDE-DEV] [PATCH] kernel: enable pcrypt

[Jason A. Donenfeld]

Hi Felix,

Patchwork was changed to "accepted" --
http://patchwork.ozlabs.org/patch/694517/ -- but this hasn't shown up
in the actual LEDE repo. What's up?

Jason

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

Re: [LEDE-DEV] [PATCH] kernel: enable pcrypt

[Felix Fietkau]

On 2016-11-16 20:35, Jason A. Donenfeld wrote:
> Hi Felix,
> 
> Patchwork was changed to "accepted" --
> http://patchwork.ozlabs.org/patch/694517/ -- but this hasn't shown up
> in the actual LEDE repo. What's up?
It's in my staging tree and will make it to the main repo soon.

- Felix


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

Re: [LEDE-DEV] [wiki] Permalinks to page sections

[Thomas Endt]

> If someone stumbles upon the solution for this problem, please let me
> know.

Since I havn't found any open issue that could cause this, I opened a
ticket:
https://github.com/LotarProject/dokuwiki-template-bootstrap3/issues/268

Thomas


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

Re: [LEDE-DEV] [PATCH] mt7621: add support for WeVO W2914NS v2

[Mathias Kresin]

Hi,

find my comments inline.

2016-11-16 12:47 GMT+01:00 perillamint :
> From: "Yong-hyu, Ban" 
>
> Signed-off-by: Yong-hyu, Ban 
> ---
>  .../linux/ramips/base-files/etc/board.d/02_network |   1 +
>  target/linux/ramips/base-files/lib/ramips.sh   |   3 +
>  .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
>  target/linux/ramips/dts/W2914NSV2.dts  | 126 
> +
>  target/linux/ramips/image/mt7621.mk|   8 ++
>  5 files changed, 139 insertions(+)
>  create mode 100644 target/linux/ramips/dts/W2914NSV2.dts
>
> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
> b/target/linux/ramips/base-files/etc/board.d/02_network
> index e2a2f94..52289a4 100755
> --- a/target/linux/ramips/base-files/etc/board.d/02_network
> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
> @@ -86,6 +86,7 @@ ramips_setup_interfaces()
> sap-g3200u3|\
> sk-wb8|\
> vr500|\
> +   w2914nsv2|\
> wf-2881|\
> witi|\
> wl-wn575a3|\
> diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
> b/target/linux/ramips/base-files/lib/ramips.sh
> index 2560eb7..dbfb650 100755
> --- a/target/linux/ramips/base-files/lib/ramips.sh
> +++ b/target/linux/ramips/base-files/lib/ramips.sh
> @@ -583,6 +583,9 @@ ramips_board_detect() {
> *"YK1")
> name="youku-yk1"
> ;;
> +   *"W2914NS v2")

Please keep alphabetical order.

> +   name="w2914nsv2"
> +   ;;
> *)
> name="generic"
> ;;
> diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
> b/target/linux/ramips/base-files/lib/upgrade/platform.sh
> index 7f161f5..169e0ff 100755
> --- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
> @@ -131,6 +131,7 @@ platform_check_image() {
> vocore|\
> vr500|\
> w150m|\
> +   w2914nsv2|\
> w306r-v20|\
> w502u|\
> wf-2881|\
> diff --git a/target/linux/ramips/dts/W2914NSV2.dts 
> b/target/linux/ramips/dts/W2914NSV2.dts
> new file mode 100644
> index 000..fd50e4e
> --- /dev/null
> +++ b/target/linux/ramips/dts/W2914NSV2.dts
> @@ -0,0 +1,126 @@
> +/dts-v1/;
> +
> +#include "mt7621.dtsi"
> +
> +#include 

Please include  here as well and put it in
front of the input/input.h include to keep alphabetical order. Use the
constants GPIO_ACTIVE_LOW and GPIO_ACTIVE_HIGH afterwards instead of 1
and 0 for the gpio parameters.

Check the recent board additions to ramips for examples.

> +
> +/ {
> +   compatible = "mediatek,mt7621-eval-board", "mediatek,mt7621-soc";

Drop this line. Your board isn't the mediatek,mt7621-eval-board and
the mediatek compatible string is inherit from mt7621.dtsi

> +   model = "WeVO W2914NS v2";
> +
> +   memory@0 {
> +   device_type = "memory";
> +   reg = <0x0 0x800>;
> +   };
> +
> +   chosen {
> +   bootargs = "console=ttyS0,57600";
> +   };
> +
> +   gpio-keys-polled {
> +   compatible = "gpio-keys-polled";
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   poll-interval = <20>;
> +
> +   reset {
> +   label = "reset";
> +   gpios = < 29 1>;
> +   linux,code = ;
> +   };
> +
> +   wps {
> +   label = "wps";
> +   gpios = < 18 1>;
> +   linux,code = ;
> +   };
> +   };
> +
> +   gpio-leds {
> +   compatible = "gpio-leds";
> +
> +   usb {
> +   label = "w2914nsv2:green:usb";
> +   gpios = < 27 1>;
> +   };
> +   };

Any reason why you included only the usb led? According to the
pictures I found, it looks like this board does have a WAN, WLAN
2.4GHz, WLAN 5GHz, USB, Power and multiple LAN leds.

The usb led isn't used for indicating a connected usb device (see
target/linux/ramips/base-files/etc/board.d/01_leds). Any specific
reason why?

If you decide to add the power led, please use this led in
target/linux/ramips/base-files/etc/diag.sh. If added, it will be used
for boot status indication.

> +};
> +
> +

Remove the double line break.

> + {
> +   status = "okay";
> +};
> +
> + {
> +   status = "okay";
> +};
> +
> + {
> +   status = "okay";
> +
> +   m25p80@0 {
> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +   compatible = "mx25l12805d";

Does this really work?

>From 
>http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt?v=4.8:

- May include a device-specific string consisting of the manufacturer
_and_ name of the chip.
- Must also 

Re: [LEDE-DEV] [wiki] Permalinks to page sections

[Thomas Endt]

> There is a small usability issue with the wiki: there is no easy way to
> get a permalink to a page section (i.e. a link that includes an
> anchor).
> 
> First, it would be nice to have a small clickable permalink just beside
> a section title.

Done.


> Also, there is a bug in the table of contents of a page.  The table of
> contents provides correct links to sections, but after clicking on the
> link, the URL (with the anchor to the section) is not updated in the
> address bar of the browser.

That's a problem of the fantastic bootstrap3 template and does not happen
with the monobook template. Currently, I can not do anything against this.
:(
If someone stumbles upon the solution for this problem, please let me know.


Regards,

Thomas


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

[LEDE-DEV] ar71xx: Fix switch config on Mikrotik RB450/G

[João Chaínho]

This patch fixes switch initial config on Mikrotik RB450/G
Signed-off-by: João Chaínho 
---
diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network 
b/target/linux/ar71xx/base-files/etc/board.d/02_network
index df87c96..daf9495 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -343,13 +343,13 @@ ar71xx_setup_interfaces()
rb-450)
ucidef_set_interfaces_lan_wan "eth1" "eth0"
ucidef_add_switch "switch0" \
-   "0:lan" "1:lan" "2:lan" "3:lan" "5@eth1"
+   "0:lan:4" "1:lan:3" "2:lan:2" "3:lan:1" "5@eth1"
;;
rb-450g|\
routerstation-pro)
ucidef_set_interfaces_lan_wan "eth1" "eth0"
ucidef_add_switch "switch0" \
-   "0@eth1" "2:lan:3" "3:lan:2" "4:lan:1"
+   "0@eth1" "1:lan:1" "2:lan:4" "3:lan:3" "4:lan:2"
;;
rb-493g)
ucidef_set_interfaces_lan_wan "eth0 eth1.1" "eth1.2"

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

Re: [LEDE-DEV] [PATCH] ar71xx: fix drivers/mtd/nand/ar934x_nfc.c

[John Crispin]

On 16/11/2016 16:35, Rafał Miłecki wrote:
> On 16 November 2016 at 12:41,   wrote:
>>> patch fails to apply to current HEAD. could you check/resend it please
>>
>> Just checked again on a new git clone - everything is fine here.
> 
> I can confirm it applies cleanly
> $ curl https://patchwork.ozlabs.org/patch/695452/mbox/ | git am
> Applying: ar71xx: fix drivers/mtd/nand/ar934x_nfc.c
> 

weird, will retry, maybe i did a copypasta error

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

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

[bittorf wireless )) Bastian Bittorf]

* Koen Vandeputte  [16.11.2016 17:45]:
> 3)
> - When a kernel update patch is posted, it requires at least 2
> additional "tested-by"'s on different targets before it can be
> considered for merging. (Covering 5 .. 6 targets in total

thanks for these insights.
i think the 2 testers if a senseful thing.

i can at least test
ar71xx ath25 au1000 brcm47xx kirkwood mpc85xx omap ppc40x ramips rb532 sunxi 
uml x86 xburst
on real hardware and because of autoupdate it's not too hard.

bye, bastian

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

[LEDE-DEV] ar71xx: enable serial console on mikrotik devices

[João Chaínho]

This patch enables the serial console on some Mikrotik devices (RB450, RB450G, 
RB493G, RB750UP).
Signed-off-by: João Chaínho 
diff --git 
a/target/linux/ar71xx/patches-4.4/701-MIPS-ath79-add-routerboard-detection.patch
 
b/target/linux/ar71xx/patches-4.4/701-MIPS-ath79-add-routerboard-detection.patch
index 8dee006..77bf38c 100644
--- 
a/target/linux/ar71xx/patches-4.4/701-MIPS-ath79-add-routerboard-detection.patch
+++ 
b/target/linux/ar71xx/patches-4.4/701-MIPS-ath79-add-routerboard-detection.patch
@@ -1,11 +1,14 @@
 --- a/arch/mips/ath79/prom.c
 +++ b/arch/mips/ath79/prom.c
-@@ -136,6 +136,13 @@ void __init prom_init(void)
+@@ -136,6 +136,16 @@ void __init prom_init(void)
initrd_end = initrd_start + fw_getenvl("initrd_size");
}
  #endif
 +
 +  if (strstr(arcs_cmdline, "board=750Gr3") ||
++  strstr(arcs_cmdline, "board=750i") ||
++  strstr(arcs_cmdline, "board=450") ||
++  strstr(arcs_cmdline, "board=493") ||
 +  strstr(arcs_cmdline, "board=951G") ||
 +  strstr(arcs_cmdline, "board=2011L") ||
 +  strstr(arcs_cmdline, "board=711Gr100") ||

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

[LEDE-DEV] [PATCH v2 2/2] apm821xx: Add support for the Cisco Meraki MX60/MX60W

[Chris Blake]

This patch adds support for the Cisco Meraki MX60/MX60W Security
Appliance. Flashing information can be found at
https://github.com/riptidewave93/LEDE-MX60

Specs are as follows:
AppliedMicro APM82181 SoC at 800MHz
1GiB NAND - Samsung K9K8G08U0D
512MB DDR RAM - 4x Nanya NT5TU128M8GE-AC
Atheros AR8327-BL1A Gigabit Ethernet Switch
1x USB 2.0 Port

More info can be found at https://wiki.openwrt.org/toh/meraki/mx60

Cc: Christian Lamparter 

Signed-off-by: Chris Blake 
---
 .../linux/apm821xx/base-files/etc/board.d/01_leds  |   8 +
 .../apm821xx/base-files/etc/board.d/02_network |   3 +-
 target/linux/apm821xx/base-files/etc/diag.sh   |  15 +-
 target/linux/apm821xx/base-files/lib/apm821xx.sh   |   4 +
 .../lib/preinit/05_set_iface_mac_apm821xx  |   3 +-
 .../apm821xx/base-files/lib/upgrade/merakinand.sh  |   9 +-
 .../apm821xx/base-files/lib/upgrade/platform.sh|   6 +-
 target/linux/apm821xx/config-4.4   |   1 +
 target/linux/apm821xx/dts/MX60.dts | 186 +
 target/linux/apm821xx/image/Makefile   |  32 
 .../203-add-meraki-mx60-buckminster-support.patch  |  32 
 11 files changed, 283 insertions(+), 16 deletions(-)
 create mode 100644 target/linux/apm821xx/dts/MX60.dts
 create mode 100644 
target/linux/apm821xx/patches-4.4/203-add-meraki-mx60-buckminster-support.patch

diff --git a/target/linux/apm821xx/base-files/etc/board.d/01_leds 
b/target/linux/apm821xx/base-files/etc/board.d/01_leds
index 38cfbdc..ad9bef9c 100755
--- a/target/linux/apm821xx/base-files/etc/board.d/01_leds
+++ b/target/linux/apm821xx/base-files/etc/board.d/01_leds
@@ -16,6 +16,14 @@ mr24)
ucidef_set_led_wlan "wlan4" "WLAN4" "mr24:green:wifi4" "phy0tpt"
;;
 
+mx60)
+   ucidef_set_led_switch "wan" "WAN" "mx60:green:wan" "switch0" "0x20"
+   ucidef_set_led_switch "lan1" "LAN1" "mx60:green:lan1" "switch0" "0x10"
+   ucidef_set_led_switch "lan2" "LAN2" "mx60:green:lan2" "switch0" "0x08"
+   ucidef_set_led_switch "lan3" "LAN3" "mx60:green:lan3" "switch0" "0x04"
+   ucidef_set_led_switch "lan4" "LAN4" "mx60:green:lan4" "switch0" "0x02"
+   ;;
+
 mbl)
ucidef_set_led_ide "sata" "SATA" "mbl:blue:power"
;;
diff --git a/target/linux/apm821xx/base-files/etc/board.d/02_network 
b/target/linux/apm821xx/base-files/etc/board.d/02_network
index 3a25709..90a8c1a 100755
--- a/target/linux/apm821xx/base-files/etc/board.d/02_network
+++ b/target/linux/apm821xx/base-files/etc/board.d/02_network
@@ -9,11 +9,12 @@ board_config_update
 board=$(apm821xx_board_name)
 
 case "$board" in
-mbl | \
+mbl|\
 mr24)
ucidef_set_interface_lan "eth0"
;;
 
+mx60|\
 wndr4700)
ucidef_add_switch "switch0" \
"0@eth0" "4:lan" "3:lan" "2:lan" "1:lan" "5:wan"
diff --git a/target/linux/apm821xx/base-files/etc/diag.sh 
b/target/linux/apm821xx/base-files/etc/diag.sh
index 3ddd21d..3e480f1 100755
--- a/target/linux/apm821xx/base-files/etc/diag.sh
+++ b/target/linux/apm821xx/base-files/etc/diag.sh
@@ -4,17 +4,14 @@
 . /lib/apm821xx.sh
 
 get_status_led() {
-   case $(apm821xx_board_name) in
-   mbl)
-   status_led="mbl:green:power"
-   ;;
-
-   mr24)
-   status_led="mr24:green:power"
-   ;;
+   local board=$(apm821xx_board_name)
 
+   case $board in
+   mbl|\
+   mr24|\
+   mx60|\
wndr4700)
-   status_led="wndr4700:green:power"
+   status_led="$board:green:power"
;;
 
*)
diff --git a/target/linux/apm821xx/base-files/lib/apm821xx.sh 
b/target/linux/apm821xx/base-files/lib/apm821xx.sh
index 78fe452..98f6ee9 100755
--- a/target/linux/apm821xx/base-files/lib/apm821xx.sh
+++ b/target/linux/apm821xx/base-files/lib/apm821xx.sh
@@ -14,6 +14,10 @@ apm821xx_board_detect() {
name="mr24"
;;
 
+   *"Meraki MX60/MX60W Security Appliance")
+   name="mx60"
+   ;;
+
*"MyBook Live"*)
name="mbl"
;;
diff --git 
a/target/linux/apm821xx/base-files/lib/preinit/05_set_iface_mac_apm821xx 
b/target/linux/apm821xx/base-files/lib/preinit/05_set_iface_mac_apm821xx
index 5dc7175..750af04 100644
--- a/target/linux/apm821xx/base-files/lib/preinit/05_set_iface_mac_apm821xx
+++ b/target/linux/apm821xx/base-files/lib/preinit/05_set_iface_mac_apm821xx
@@ -4,7 +4,8 @@
 
 preinit_set_mac_address() {
case $(apm821xx_board_name) in
-   mr24)
+   mr24|\
+   mx60)
mac_lan=$(mtd_get_mac_binary_ubi board-config 102)
[ -n "$mac_lan" ] && ifconfig eth0 hw ether "$mac_lan"
;;
diff --git a/target/linux/apm821xx/base-files/lib/upgrade/merakinand.sh 
b/target/linux/apm821xx/base-files/lib/upgrade/merakinand.sh
index 5861d97..f025082 100755
--- 

Re: [LEDE-DEV] [PATCH] ar71xx: fix drivers/mtd/nand/ar934x_nfc.c

[Rafał Miłecki]

On 16 November 2016 at 12:41,   wrote:
>> patch fails to apply to current HEAD. could you check/resend it please
>
> Just checked again on a new git clone - everything is fine here.

I can confirm it applies cleanly
$ curl https://patchwork.ozlabs.org/patch/695452/mbox/ | git am
Applying: ar71xx: fix drivers/mtd/nand/ar934x_nfc.c

-- 
Rafał

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

[LEDE-DEV] [PATCH 0/2] Add support for the Cisco Meraki MX60 & MX60W

[Chris Blake]

These patches add support for the Cisco Meraki MX60 & MX60W Security Appliance.

Cc: Christian Lamparter 

Chris Blake (2):
  firmware-utils: Add support for the Cisco Meraki MX60/MX60W
  apm821xx: Add support for the Cisco Meraki MX60/MX60W

 .../linux/apm821xx/base-files/etc/board.d/01_leds  |   8 +
 .../apm821xx/base-files/etc/board.d/02_network |   3 +-
 target/linux/apm821xx/base-files/etc/diag.sh   |  15 +-
 target/linux/apm821xx/base-files/lib/apm821xx.sh   |   4 +
 .../lib/preinit/05_set_iface_mac_apm821xx  |   3 +-
 .../apm821xx/base-files/lib/upgrade/merakinand.sh  |   9 +-
 .../apm821xx/base-files/lib/upgrade/platform.sh|   6 +-
 target/linux/apm821xx/config-4.4   |   3 +
 target/linux/apm821xx/dts/MX60.dts | 186 +
 target/linux/apm821xx/image/Makefile   |  32 
 .../203-add-meraki-mx60-buckminster-support.patch  |  32 
 tools/firmware-utils/src/mkmerakifw.c  |  69 ++--
 12 files changed, 343 insertions(+), 27 deletions(-)
 create mode 100644 target/linux/apm821xx/dts/MX60.dts
 create mode 100644 
target/linux/apm821xx/patches-4.4/203-add-meraki-mx60-buckminster-support.patch

--
2.7.4

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

[LEDE-DEV] [PATCH 1/2] firmware-utils: Add support for the Cisco Meraki MX60/MX60W

[Chris Blake]

This patch adds header support for the Cisco Meraki MX60/MX60W, which
are a part of the apm821xx target. Some structure changes were needed
due to the fact this device uses U-Boot (unlike other devices in
mkmerakifw.c) which uses a different header structure to define the load
offsets for the image.

A thanks to Christian for helping implement this properly.

Cc: Christian Lamparter 

Signed-off-by: Chris Blake 
---
 tools/firmware-utils/src/mkmerakifw.c | 69 +--
 1 file changed, 58 insertions(+), 11 deletions(-)

diff --git a/tools/firmware-utils/src/mkmerakifw.c 
b/tools/firmware-utils/src/mkmerakifw.c
index 61b81c6..6394cba 100644
--- a/tools/firmware-utils/src/mkmerakifw.c
+++ b/tools/firmware-utils/src/mkmerakifw.c
@@ -32,13 +32,27 @@
 #define HDR_OFF_IMAGELEN   8
 #define HDR_OFF_CHECKSUM   12
 #define HDR_OFF_MAGIC2 32
-#define HDR_OFF_FILLER 36
+#define HDR_OFF_MAGIC3 36
 #define HDR_OFF_STATICHASH 40
+#define HDR_OFF_KERNEL_OFFSET  40
+#define HDR_OFF_RAMDISK_OFFSET 44
+#define HDR_OFF_FDT_OFFSET 48
+#define HDR_OFF_UNKNOWN_OFFSET 52

 struct board_info {
-   uint32_t magic;
+   uint32_t magic1;
+   uint32_t magic2;
+   uint32_t magic3;
uint32_t imagelen;
-   unsigned char statichash[20];
+   union {
+   unsigned char statichash[20];
+   struct {
+   uint32_t kernel_offset;
+   uint32_t ramdisk_offset;
+   uint32_t fdt_offset;
+   uint32_t unknown_offset;
+   } mx60;
+   };
char *id;
char *description;
 };
@@ -55,7 +69,8 @@ static const struct board_info boards[] = {
{
.id = "mr18",
.description= "Meraki MR18 Access Point",
-   .magic  = 0x8e73ed8a,
+   .magic1 = 0x8e73ed8a,
+   .magic2 = 0x8e73ed8a,
.imagelen   = 0x0080,
.statichash = {0xda, 0x39, 0xa3, 0xee, 0x5e,
   0x6b, 0x4b, 0x0d, 0x32, 0x55,
@@ -64,14 +79,34 @@ static const struct board_info boards[] = {
}, {
.id = "mr24",
.description= "Meraki MR24 Access Point",
-   .magic  = 0x8e73ed8a,
+   .magic1 = 0x8e73ed8a,
+   .magic2 = 0x8e73ed8a,
.imagelen   = 0x0080,
.statichash = {0xff, 0xff, 0xff, 0xff, 0xff,
   0xff, 0xff, 0xff, 0xff, 0xff,
   0xff, 0xff, 0xff, 0xff, 0xff,
   0xff, 0xff, 0xff, 0xff, 0xff},
}, {
-
+   .id = "mx60",
+   .description= "Meraki MX60/MX60W Security Appliance",
+   .magic1 = 0x8e73ed8a,
+   .magic2 = 0xa1f0beef, /* Enables use of load addr in 
statichash */
+   .magic3 = 0x00060001, /* This goes along with magic2 */
+   .imagelen   = 0x3fd0,
+   /* The static hash below does the following:
+* 1st Row: Kernel Offset
+* 2nd Row: Ramdisk Offset
+* 3rd Row: FDT Offset
+* 4th Row: ? Unused/Unknown ?
+* 5th Row: ? Unused/Unknown ?
+*/
+   .mx60   = {
+   .kernel_offset  = 0x1,
+   .ramdisk_offset = 0x3FFC00,
+   .fdt_offset = 0x0400,
+   .unknown_offset = 0x0400,
+   },
+   }, {
/* terminating entry */
}
 };
@@ -237,10 +272,10 @@ int main(int argc, char *argv[])
kernel = buf + HDR_LENGTH;
fread(kernel, klen, 1, in);

-   /* Write magic values and filler */
-   writel(buf, HDR_OFF_MAGIC1, board->magic);
-   writel(buf, HDR_OFF_MAGIC2, board->magic);
-   writel(buf, HDR_OFF_FILLER, 0);
+   /* Write magic values */
+   writel(buf, HDR_OFF_MAGIC1, board->magic1);
+   writel(buf, HDR_OFF_MAGIC2, board->magic2);
+   writel(buf, HDR_OFF_MAGIC3, board->magic3);

/* Write header and image length */
writel(buf, HDR_OFF_HDRLEN, HDR_LENGTH);
@@ -248,7 +283,19 @@ int main(int argc, char *argv[])

/* Write checksum and static hash */
sha1_csum(kernel, klen, buf + HDR_OFF_CHECKSUM);
-   memcpy(buf + HDR_OFF_STATICHASH, board->statichash, 20);
+
+   switch (board->magic2) {
+   case 0xa1f0beef:
+   writel(buf, HDR_OFF_KERNEL_OFFSET, board->mx60.kernel_offset);
+   writel(buf, HDR_OFF_RAMDISK_OFFSET, board->mx60.ramdisk_offset);
+   writel(buf, HDR_OFF_FDT_OFFSET, board->mx60.fdt_offset),
+   writel(buf, 

[LEDE-DEV] [PATCH 2/2] apm821xx: Add support for the Cisco Meraki MX60/MX60W

[Chris Blake]

This patch adds support for the Cisco Meraki MX60/MX60W Security
Appliance. Flashing information can be found at
https://github.com/riptidewave93/LEDE-MX60

Specs are as follows:
AppliedMicro APM82181 SoC at 800MHz
1GiB NAND - Samsung K9K8G08U0D
512MB DDR RAM - 4x Nanya NT5TU128M8GE-AC
Atheros AR8327-BL1A Gigabit Ethernet Switch
1x USB 2.0 Port

More info can be found at https://wiki.openwrt.org/toh/meraki/mx60

Cc: Christian Lamparter 

Signed-off-by: Chris Blake 
---
 .../linux/apm821xx/base-files/etc/board.d/01_leds  |   8 +
 .../apm821xx/base-files/etc/board.d/02_network |   3 +-
 target/linux/apm821xx/base-files/etc/diag.sh   |  15 +-
 target/linux/apm821xx/base-files/lib/apm821xx.sh   |   4 +
 .../lib/preinit/05_set_iface_mac_apm821xx  |   3 +-
 .../apm821xx/base-files/lib/upgrade/merakinand.sh  |   9 +-
 .../apm821xx/base-files/lib/upgrade/platform.sh|   6 +-
 target/linux/apm821xx/config-4.4   |   3 +
 target/linux/apm821xx/dts/MX60.dts | 186 +
 target/linux/apm821xx/image/Makefile   |  32 
 .../203-add-meraki-mx60-buckminster-support.patch  |  32 
 11 files changed, 285 insertions(+), 16 deletions(-)
 create mode 100644 target/linux/apm821xx/dts/MX60.dts
 create mode 100644 
target/linux/apm821xx/patches-4.4/203-add-meraki-mx60-buckminster-support.patch

diff --git a/target/linux/apm821xx/base-files/etc/board.d/01_leds 
b/target/linux/apm821xx/base-files/etc/board.d/01_leds
index 38cfbdc..ad9bef9c 100755
--- a/target/linux/apm821xx/base-files/etc/board.d/01_leds
+++ b/target/linux/apm821xx/base-files/etc/board.d/01_leds
@@ -16,6 +16,14 @@ mr24)
ucidef_set_led_wlan "wlan4" "WLAN4" "mr24:green:wifi4" "phy0tpt"
;;

+mx60)
+   ucidef_set_led_switch "wan" "WAN" "mx60:green:wan" "switch0" "0x20"
+   ucidef_set_led_switch "lan1" "LAN1" "mx60:green:lan1" "switch0" "0x10"
+   ucidef_set_led_switch "lan2" "LAN2" "mx60:green:lan2" "switch0" "0x08"
+   ucidef_set_led_switch "lan3" "LAN3" "mx60:green:lan3" "switch0" "0x04"
+   ucidef_set_led_switch "lan4" "LAN4" "mx60:green:lan4" "switch0" "0x02"
+   ;;
+
 mbl)
ucidef_set_led_ide "sata" "SATA" "mbl:blue:power"
;;
diff --git a/target/linux/apm821xx/base-files/etc/board.d/02_network 
b/target/linux/apm821xx/base-files/etc/board.d/02_network
index 3a25709..90a8c1a 100755
--- a/target/linux/apm821xx/base-files/etc/board.d/02_network
+++ b/target/linux/apm821xx/base-files/etc/board.d/02_network
@@ -9,11 +9,12 @@ board_config_update
 board=$(apm821xx_board_name)

 case "$board" in
-mbl | \
+mbl|\
 mr24)
ucidef_set_interface_lan "eth0"
;;

+mx60|\
 wndr4700)
ucidef_add_switch "switch0" \
"0@eth0" "4:lan" "3:lan" "2:lan" "1:lan" "5:wan"
diff --git a/target/linux/apm821xx/base-files/etc/diag.sh 
b/target/linux/apm821xx/base-files/etc/diag.sh
index 3ddd21d..3e480f1 100755
--- a/target/linux/apm821xx/base-files/etc/diag.sh
+++ b/target/linux/apm821xx/base-files/etc/diag.sh
@@ -4,17 +4,14 @@
 . /lib/apm821xx.sh

 get_status_led() {
-   case $(apm821xx_board_name) in
-   mbl)
-   status_led="mbl:green:power"
-   ;;
-
-   mr24)
-   status_led="mr24:green:power"
-   ;;
+   local board=$(apm821xx_board_name)

+   case $board in
+   mbl|\
+   mr24|\
+   mx60|\
wndr4700)
-   status_led="wndr4700:green:power"
+   status_led="$board:green:power"
;;

*)
diff --git a/target/linux/apm821xx/base-files/lib/apm821xx.sh 
b/target/linux/apm821xx/base-files/lib/apm821xx.sh
index 78fe452..98f6ee9 100755
--- a/target/linux/apm821xx/base-files/lib/apm821xx.sh
+++ b/target/linux/apm821xx/base-files/lib/apm821xx.sh
@@ -14,6 +14,10 @@ apm821xx_board_detect() {
name="mr24"
;;

+   *"Meraki MX60/MX60W Security Appliance")
+   name="mx60"
+   ;;
+
*"MyBook Live"*)
name="mbl"
;;
diff --git 
a/target/linux/apm821xx/base-files/lib/preinit/05_set_iface_mac_apm821xx 
b/target/linux/apm821xx/base-files/lib/preinit/05_set_iface_mac_apm821xx
index 5dc7175..750af04 100644
--- a/target/linux/apm821xx/base-files/lib/preinit/05_set_iface_mac_apm821xx
+++ b/target/linux/apm821xx/base-files/lib/preinit/05_set_iface_mac_apm821xx
@@ -4,7 +4,8 @@

 preinit_set_mac_address() {
case $(apm821xx_board_name) in
-   mr24)
+   mr24|\
+   mx60)
mac_lan=$(mtd_get_mac_binary_ubi board-config 102)
[ -n "$mac_lan" ] && ifconfig eth0 hw ether "$mac_lan"
;;
diff --git a/target/linux/apm821xx/base-files/lib/upgrade/merakinand.sh 
b/target/linux/apm821xx/base-files/lib/upgrade/merakinand.sh
index 5861d97..f025082 100755
--- 

[LEDE-DEV] [PATCH] mt7621: add support for WeVO W2914NS v2

[perillamint]

From: "Yong-hyu, Ban" 

Signed-off-by: Yong-hyu, Ban 
---
 .../linux/ramips/base-files/etc/board.d/02_network |   1 +
 target/linux/ramips/base-files/lib/ramips.sh   |   3 +
 .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
 target/linux/ramips/dts/W2914NSV2.dts  | 126 +
 target/linux/ramips/image/mt7621.mk|   8 ++
 5 files changed, 139 insertions(+)
 create mode 100644 target/linux/ramips/dts/W2914NSV2.dts

diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index e2a2f94..52289a4 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -86,6 +86,7 @@ ramips_setup_interfaces()
sap-g3200u3|\
sk-wb8|\
vr500|\
+   w2914nsv2|\
wf-2881|\
witi|\
wl-wn575a3|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index 2560eb7..dbfb650 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -583,6 +583,9 @@ ramips_board_detect() {
*"YK1")
name="youku-yk1"
;;
+   *"W2914NS v2")
+   name="w2914nsv2"
+   ;;
*)
name="generic"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 7f161f5..169e0ff 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -131,6 +131,7 @@ platform_check_image() {
vocore|\
vr500|\
w150m|\
+   w2914nsv2|\
w306r-v20|\
w502u|\
wf-2881|\
diff --git a/target/linux/ramips/dts/W2914NSV2.dts 
b/target/linux/ramips/dts/W2914NSV2.dts
new file mode 100644
index 000..fd50e4e
--- /dev/null
+++ b/target/linux/ramips/dts/W2914NSV2.dts
@@ -0,0 +1,126 @@
+/dts-v1/;
+
+#include "mt7621.dtsi"
+
+#include 
+
+/ {
+   compatible = "mediatek,mt7621-eval-board", "mediatek,mt7621-soc";
+   model = "WeVO W2914NS v2";
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x800>;
+   };
+
+   chosen {
+   bootargs = "console=ttyS0,57600";
+   };
+
+   gpio-keys-polled {
+   compatible = "gpio-keys-polled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   poll-interval = <20>;
+
+   reset {
+   label = "reset";
+   gpios = < 29 1>;
+   linux,code = ;
+   };
+
+   wps {
+   label = "wps";
+   gpios = < 18 1>;
+   linux,code = ;
+   };
+   };
+
+   gpio-leds {
+   compatible = "gpio-leds";
+
+   usb {
+   label = "w2914nsv2:green:usb";
+   gpios = < 27 1>;
+   };
+   };
+};
+
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+
+   m25p80@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "mx25l12805d";
+   reg = <0>;
+   linux,modalias = "m25p80", "w25q128";
+   spi-max-frequency = <1000>;
+
+   partition@0 {
+   label = "u-boot";
+   reg = <0x0 0x3>;
+   read-only;
+   };
+
+   partition@3 {
+   label = "u-boot-env";
+   reg = <0x3 0x1>;
+   read-only;
+   };
+
+   factory: partition@4 {
+   label = "factory";
+   reg = <0x4 0x1>;
+   };
+
+   partition@5 {
+   label = "firmware";
+   reg = <0x5 0xfb>;
+   };
+   };
+};
+
+ {
+   status = "okay";
+
+   pcie0 {
+   mt76x2e@0,0 {
+   reg = <0x 0 0 0 0>;
+   device_type = "pci";
+   mediatek,mtd-eeprom = < 0x>;
+   mediatek,5ghz = <0>;
+   };
+   };
+
+   pcie1 {
+   mt7603e@1,0 {
+   reg = <0x 0 0 0 0>;
+   device_type = "pci";
+   mediatek,mtd-eeprom = < 0x8000>;
+   mediatek,2ghz = <0>;
+   };
+   };
+};
+
+ {
+   mtd-mac-address = < 0xe000>;
+};
+
+ {
+   state_default: pinctrl0 {
+   gpio {
+   ralink,group = 

Re: [LEDE-DEV] [PATCH] ar71xx: fix drivers/mtd/nand/ar934x_nfc.c

[p . wassi]

> patch fails to apply to current HEAD. could you check/resend it please

Just checked again on a new git clone - everything is fine here.

Regards,
P. Wassi

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

Re: [LEDE-DEV] [PATCH] ar71xx: fix drivers/mtd/nand/ar934x_nfc.c

[John Crispin]

Hi,

patch fails to apply to current HEAD. could you check/resend it please

John

On 16/11/2016 07:25, p.wa...@gmx.at wrote:
> From: Paul Wassi 
> 
> Fix the incorrect usage of ar934x_nfc_write_page and 
> ar934x_nfc_write_page_raw.
> Add *page* in the argument list and remove the local variable.
> 
> Signed-off-by: Paul Wassi 
> ---
> In the buildlogs of ar71xx-nand [1] you can see a warning
>> drivers/mtd/nand/ar934x_nfc.c: In function 'ar934x_nfc_setup_hwecc':
>> drivers/mtd/nand/ar934x_nfc.c:1328:23: warning: assignment from incompatible 
>> pointer type [-Wincompatible-pointer-types]
>>   nand->ecc.write_page = ar934x_nfc_write_page;
>>^
>> drivers/mtd/nand/ar934x_nfc.c:1329:27: warning: assignment from incompatible 
>> pointer type [-Wincompatible-pointer-types]
>>   nand->ecc.write_page_raw = ar934x_nfc_write_page_raw;
>>^
> This is due to a change in interfaces which was done by kernel upstream in 
> 2015-10-13
> as can be seen in [2]. The function pointers seem to have been used 
> incorrectly since then.
> 
> [1]:
> http://phase1.builds.lede-project.org/builders/ar71xx%2Fnand/builds/322/steps/images/logs/stdio
> 
> [2]:
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/patch/include/linux/mtd/nand.h?id=45aaeff947190e4b57b2d0db4d74ab5eea450825
> 
>  target/linux/ar71xx/files/drivers/mtd/nand/ar934x_nfc.c |   10 ++
>  1 file changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/target/linux/ar71xx/files/drivers/mtd/nand/ar934x_nfc.c 
> b/target/linux/ar71xx/files/drivers/mtd/nand/ar934x_nfc.c
> --- a/target/linux/ar71xx/files/drivers/mtd/nand/ar934x_nfc.c
> +++ b/target/linux/ar71xx/files/drivers/mtd/nand/ar934x_nfc.c
> @@ -983,14 +983,11 @@ ar934x_nfc_read_page(struct mtd_info *mtd, struct 
> nand_chip *chip,
>  
>  static int
>  ar934x_nfc_write_page_raw(struct mtd_info *mtd, struct nand_chip *chip,
> -   const u8 *buf, int oob_required)
> +   const u8 *buf, int oob_required, int page)
>  {
>   struct ar934x_nfc *nfc = mtd_to_ar934x_nfc(mtd);
> - int page;
>   int len;
>  
> - page = nfc->seqin_page_addr;
> -
>   nfc_dbg(nfc, "write_page_raw: page:%d oob:%d\n", page, oob_required);
>  
>   memcpy(nfc->buf, buf, mtd->writesize);
> @@ -1006,14 +1003,11 @@ ar934x_nfc_write_page_raw(struct mtd_info *mtd, 
> struct nand_chip *chip,
>  
>  static int
>  ar934x_nfc_write_page(struct mtd_info *mtd, struct nand_chip *chip,
> -   const u8 *buf, int oob_required)
> +   const u8 *buf, int oob_required, int page)
>  {
>   struct ar934x_nfc *nfc = mtd_to_ar934x_nfc(mtd);
> - int page;
>   int err;
>  
> - page = nfc->seqin_page_addr;
> -
>   nfc_dbg(nfc, "write_page: page:%d oob:%d\n", page, oob_required);
>  
>   /* write OOB first */
> 
> ___
> 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] kernel: update kernel 4.4 to version 4.4.31

[Koen Vandeputte]

I started the script to do this for 4.4.31, and I already have more
changes than you, so NAK. While I appreciate the effort, I would like to
ask you to not send these kind of patches anymore until you are sure you
completely understand what you are doing.

Ok, noted.

I just started playing with the script and it really is a nice little thing!
As I really want to master this specific part, I'll keep on practicing 
with it for some time and eventually, on some future update, would 
submit a patch for you to review.


Thanks for your time invested in this so far,

Koen

Thanks,
Stijn




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

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

[Stijn Tintel]

On 16-11-16 07:43, p.wa...@gmx.at wrote:
> From: Paul Wassi 
>
> Refresh patches for all targets that support kernel 4.4.
> compile/run-tested on kirkwood, ar71xx, brcm47xx.
>
> Signed-off-by: Paul Wassi 
> ---
> This patch is meant to be applied upon 4.4.31!
> Apply https://patchwork.ozlabs.org/patch/694032/ first.
Running the script to update to 4.4.32 on top of the patch above, and
already have more changed files, so NAK here as well.
As you used the script, I suspect it is because you are not using the
same quilt configuration:
https://wiki.openwrt.org/doc/devel/patches#prepare_quilt_configuration

Stijn

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

Re: [LEDE-DEV] Package data on the wiki

[Alberto Bursi]

On 11/16/2016 08:01 AM, Baptiste Jonglez wrote:
> Hi,
>
> I discovered that tons of packages now have their own page in the wiki,
> which is nice.  It looks automated, what is the source of the data?
>
> Here are a few observations:
>
> - I'm not sure the list of architectures is very relevant, and it clutters
>   the page a lot.  See for instance 
> https://wiki.lede-project.org/pkgdata/htop-snapshot
>
> - Regarding https://wiki.lede-project.org/pkgdata/wireguard-tools-snapshot
>   the link to the "Source code" is wrong, it points to utils/openocd instead
>   of net/wireguard.  Also, a lot of metadata have not been imported, like
>   version or dependencies.
>
> - There is no page for the kmod-wireguard package, which is built
>   alongside wireguard-tools.  In fact, there seems to be no kmod-*
>   packages at all.
>
> Baptiste
>
>

The project is a work-in-progress to have a Table of packages (which 
does not mean just a huge table), you can find the discussion with more 
details in the forum thread here.

https://forum.lede-project.org/t/lede-table-of-packages-good-or-bad/123/86 
(btw, the script source shown in the forum thread is an old revision, I 
basically rewrote it to allow decent performance)

and the WIP Table of Packages here 
https://wiki.lede-project.org/packages/start

The data is imported by a script that is reading the same package lists 
used by opkg in a live LEDE system, then integrated with data scraped 
from the Makefiles it downloads from github (mostly categories and 
submenus, this wasn't working when I uploaded package data in the wiki, 
but now it works fine for most packages).
The plan is to eventually move the script on the wiki server itself and 
run this automatically to keep the package data updated weekly or something.

The package data you find on the wiki at the moment is a dummy, loaded 
with a immature and buggy script just to test the wiki's ability to show 
such data in a meaningful/performing way (and see if it was a good idea 
or not).

I know that the information is wrong/missing/incorrect in many cases, 
that's the reason we didn't add any link to these pages in the main wiki 
yet.

-Alberto

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

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

[p . wassi]

> On 16-11-16 09:54, Koen Vandeputte wrote:
> - From each seperate build, copy all pathes from 
> target/linux/"target"/patches-4.4 to the unused git source clone 
> ("target" being cns3xxx or imx6)

Ah, ok. So that's why the things for apm821xx and brcm2708 were not refreshed.
I thought a patch refreshing was meant to refresh *all* platforms and not just
those who are fully tested. I mean refreshing only tested platforms will
possibly break targets which are not refreshed.

The scripted approach is the one I use here. It just prepares the kernel with
files and generic patches and upon that starts the same procedure for every 
platform
on a clean kernel directory.


> I've done this before, https://git.lede-project.org/8072264b. It took a
> long time, but it's doable.
Just for reference, the link is https://git.lede-project.org/8072264

> I started the script to do this for 4.4.31, and I already have more
> changes than you, so NAK. While I appreciate the effort, I would like to
> ask you to not send these kind of patches anymore until you are sure you
> completely understand what you are doing.
While I feel adressed here, I'm not sure what is meant here?
You started the script on .31 for .32 or on .30 for .31?

> and I already have more changes than you, so NAK.
More changes than those listed in the diffstat you quoted in your mail
directly above this comment, or more changes than I've sent in for .32?
If it's for .32 please directly NAK on the other topic.

Best regards,
P. Wassi

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

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

[Stijn Tintel]

On 16-11-16 09:54, Koen Vandeputte wrote:
> Hi Paul,
>
> First of all, thank you for reviewing and testing the patch.
>
>
> Let me share in detail how I prepare the kernel update patch:
>
> - Pull the latest git state 3 times
> - On two of them, I apply my custom .config and feeds for the hardware
> targets I use (1 for cns3xxx, 1 for imx6)
> - On each of the 2 targets: Adapt the kernel-version.mk file to
> include the new kernel
> - Do a full build (tools, toolchain, packages, ...)
> - Run the following command: |"make target/linux/refresh V=s"|
> --> which is instructed here:
> https://wiki.openwrt.org/doc/devel/patches#refreshing_patches
> - From one of the build, copy all pathes from
> "target/linux/generic/patches-4.4" to the unused git source clone
> - From each seperate build, copy all pathes from
> target/linux/"target"/patches-4.4 to the unused git source clone
> ("target" being cns3xxx or imx6)
> - Read all changes in git
> - Commit + clearly specifiy it has been compiled/tested only on my 2
> targets.
>
> (If anyone thinks this is not the correct approach, please provide
> feedback by all means!)
>
>
> To be honest .. I share your opinion that it sometimes feels ..
> dangerous.
> - Will it build on other targets except my 2?
> - As some patches appear to lack refreshes, is something wrong with
> the refresh system? (I followed the previous discussion with the jump
> to kernel .30 extensively)
>
You should use the script, and trust the refresh mechanism over yourself.
>
>
> Personal thoughts regarding possible solutions:
>
> 1)
> - Having a separate staging tree which is a copy of the main Source
> tree, but only used for updating/testing kernel updates.
> This way different people using different targets could easily test a
> kernel update on their targets and reply if it's working or not. (and
> supply refresh-patches for target-specific kernel patches)
> If all major targets are refreshed, tested & confirmed, it should be
> safer to merge it to main.
>
> 2)
> - An alternate approach would be to create a script which auto-builds
> & refresh every possible target.

We already have this script, it was mentioned in a previous thread about
the subject.
> --> Huge workload for 1 person
> --> Would still leave some targets untested (unless someone has all
> the time + hardware? :) )
I've done this before, https://git.lede-project.org/8072264b. It took a
long time, but it's doable.
>
> 3)
> - When a kernel update patch is posted, it requires at least 2
> additional "tested-by"'s on different targets before it can be
> considered for merging. (Covering 5 .. 6 targets in total)
>
>
> Any other ideas? anyone?
>
>
>
> Thanks again,
>
> Koen
>
>
>
> On 2016-11-16 08:00, p.wa...@gmx.at wrote:
>> As I've just sent in 4.4.32, I came across other changes from which
>> I think they should have already been done in 4.4.31:
>> /apm821xx/patches-4.4/801-usb-xhci-add-firmware-loader-for-uPD720201-and-uPD72.patch
>>
>> /apm821xx/patches-4.4/802-usb-xhci-force-msi-renesas-xhci.patch
>>
>> Changes to xhci-pci.c were made upstream during release of 4.4.31
>> [1], which introduce
>> two lines offset. Of course I know, that missing this refreshing
>> doesn't break anything.
>> However, it's not clear for me why some patches are refreshed, while
>> others are not. This
>> looks so indeterministic to me. Or am I still producing false positives?
>>
>> Best regards,
>> P. Wassi
>>
>> [1]:
>> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/diff/?id=v4.4.31=v4.4.30=2
>>
>>
>>> + Refresh patches
>>> compile/run-tested on cns3xxx & imx6.
>>>
>>> Signed-off-by: Koen Vandeputte 
>>> ---
>>>   include/kernel-version.mk  |  4 ++--
>>>   ...-override-creds-with-the-ones-from-the-superblock.patch |  6
>>> +++---
>>>   .../patches-4.4/052-01-ubifs-Implement-O_TMPFILE.patch |  2 +-
>>>   .../052-02-ubifs-Implement-RENAME_WHITEOUT.patch   | 14
>>> +++---
>>>   .../052-03-ubifs-Implement-RENAME_EXCHANGE.patch   |  6
>>> +++---
>>>   ...ac-stop-clearing-DMA-receive-control-register-rig.patch |  9
>>> ++---
>>>   .../linux/generic/patches-4.4/201-extra_optimization.patch |  4 ++--
>>>   7 files changed, 20 insertions(+), 25 deletions(-)
>
I started the script to do this for 4.4.31, and I already have more
changes than you, so NAK. While I appreciate the effort, I would like to
ask you to not send these kind of patches anymore until you are sure you
completely understand what you are doing.

Thanks,
Stijn


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

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

[Koen Vandeputte]

Small correction below


On 2016-11-16 09:54, Koen Vandeputte wrote:

Hi Paul,

First of all, thank you for reviewing and testing the patch.


Let me share in detail how I prepare the kernel update patch:

- Pull the latest git state 3 times
- On two of them, I apply my custom .config and feeds for the hardware 
targets I use (1 for cns3xxx, 1 for imx6)
- On each of the 2 targets: Adapt the kernel-version.mk file to 
include the new kernel

- Do a full build (tools, toolchain, packages, ...)
- Run the following command: |"make target/linux/refresh V=s"|
--> which is instructed here: 
https://wiki.openwrt.org/doc/devel/patches#refreshing_patches

- Clean, rebuild & test on both targets
- From one of the build, copy all pathes from 
"target/linux/generic/patches-4.4" to the unused git source clone
- From each seperate build, copy all pathes from 
target/linux/"target"/patches-4.4 to the unused git source clone 
("target" being cns3xxx or imx6)

- Read all changes in git
- Commit + clearly specifiy it has been compiled/tested only on my 2 
targets.


(If anyone thinks this is not the correct approach, please provide 
feedback by all means!)



To be honest .. I share your opinion that it sometimes feels .. 
dangerous.

- Will it build on other targets except my 2?
- As some patches appear to lack refreshes, is something wrong with 
the refresh system? (I followed the previous discussion with the jump 
to kernel .30 extensively)




Personal thoughts regarding possible solutions:

1)
- Having a separate staging tree which is a copy of the main Source 
tree, but only used for updating/testing kernel updates.
This way different people using different targets could easily test a 
kernel update on their targets and reply if it's working or not. (and 
supply refresh-patches for target-specific kernel patches)
If all major targets are refreshed, tested & confirmed, it should be 
safer to merge it to main.


2)
- An alternate approach would be to create a script which auto-builds 
& refresh every possible target.

--> Huge workload for 1 person
--> Would still leave some targets untested (unless someone has all 
the time + hardware? :) )


3)
- When a kernel update patch is posted, it requires at least 2 
additional "tested-by"'s on different targets before it can be 
considered for merging. (Covering 5 .. 6 targets in total)



Any other ideas? anyone?



Thanks again,

Koen



On 2016-11-16 08:00, p.wa...@gmx.at wrote:

As I've just sent in 4.4.32, I came across other changes from which
I think they should have already been done in 4.4.31:
/apm821xx/patches-4.4/801-usb-xhci-add-firmware-loader-for-uPD720201-and-uPD72.patch 


/apm821xx/patches-4.4/802-usb-xhci-force-msi-renesas-xhci.patch

Changes to xhci-pci.c were made upstream during release of 4.4.31 
[1], which introduce
two lines offset. Of course I know, that missing this refreshing 
doesn't break anything.
However, it's not clear for me why some patches are refreshed, while 
others are not. This

looks so indeterministic to me. Or am I still producing false positives?

Best regards,
P. Wassi

[1]:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/diff/?id=v4.4.31=v4.4.30=2 




+ Refresh patches
compile/run-tested on cns3xxx & imx6.

Signed-off-by: Koen Vandeputte 
---
  include/kernel-version.mk |  4 ++--
  ...-override-creds-with-the-ones-from-the-superblock.patch |  6 
+++---

  .../patches-4.4/052-01-ubifs-Implement-O_TMPFILE.patch |  2 +-
  .../052-02-ubifs-Implement-RENAME_WHITEOUT.patch   | 14 
+++---

  .../052-03-ubifs-Implement-RENAME_EXCHANGE.patch |  6 +++---
  ...ac-stop-clearing-DMA-receive-control-register-rig.patch |  9 
++---

  .../linux/generic/patches-4.4/201-extra_optimization.patch |  4 ++--
  7 files changed, 20 insertions(+), 25 deletions(-)




--
Koen Vandeputte - Software Developer
koen.vandepu...@ncentric.com | +32499736158


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

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

[Koen Vandeputte]

Hi Paul,

First of all, thank you for reviewing and testing the patch.


Let me share in detail how I prepare the kernel update patch:

- Pull the latest git state 3 times
- On two of them, I apply my custom .config and feeds for the hardware 
targets I use (1 for cns3xxx, 1 for imx6)
- On each of the 2 targets: Adapt the kernel-version.mk file to include 
the new kernel

- Do a full build (tools, toolchain, packages, ...)
- Run the following command: |"make target/linux/refresh V=s"|
--> which is instructed here: 
https://wiki.openwrt.org/doc/devel/patches#refreshing_patches
- From one of the build, copy all pathes from 
"target/linux/generic/patches-4.4" to the unused git source clone
- From each seperate build, copy all pathes from 
target/linux/"target"/patches-4.4 to the unused git source clone 
("target" being cns3xxx or imx6)

- Read all changes in git
- Commit + clearly specifiy it has been compiled/tested only on my 2 
targets.


(If anyone thinks this is not the correct approach, please provide 
feedback by all means!)



To be honest .. I share your opinion that it sometimes feels .. dangerous.
- Will it build on other targets except my 2?
- As some patches appear to lack refreshes, is something wrong with the 
refresh system? (I followed the previous discussion with the jump to 
kernel .30 extensively)




Personal thoughts regarding possible solutions:

1)
- Having a separate staging tree which is a copy of the main Source 
tree, but only used for updating/testing kernel updates.
This way different people using different targets could easily test a 
kernel update on their targets and reply if it's working or not. (and 
supply refresh-patches for target-specific kernel patches)
If all major targets are refreshed, tested & confirmed, it should be 
safer to merge it to main.


2)
- An alternate approach would be to create a script which auto-builds & 
refresh every possible target.

--> Huge workload for 1 person
--> Would still leave some targets untested (unless someone has all the 
time + hardware? :) )


3)
- When a kernel update patch is posted, it requires at least 2 
additional "tested-by"'s on different targets before it can be 
considered for merging. (Covering 5 .. 6 targets in total)



Any other ideas? anyone?



Thanks again,

Koen



On 2016-11-16 08:00, p.wa...@gmx.at wrote:

As I've just sent in 4.4.32, I came across other changes from which
I think they should have already been done in 4.4.31:
/apm821xx/patches-4.4/801-usb-xhci-add-firmware-loader-for-uPD720201-and-uPD72.patch
/apm821xx/patches-4.4/802-usb-xhci-force-msi-renesas-xhci.patch

Changes to xhci-pci.c were made upstream during release of 4.4.31 [1], which 
introduce
two lines offset. Of course I know, that missing this refreshing doesn't break 
anything.
However, it's not clear for me why some patches are refreshed, while others are 
not. This
looks so indeterministic to me. Or am I still producing false positives?

Best regards,
P. Wassi

[1]:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/diff/?id=v4.4.31=v4.4.30=2


+ Refresh patches
compile/run-tested on cns3xxx & imx6.

Signed-off-by: Koen Vandeputte 
---
  include/kernel-version.mk  |  4 ++--
  ...-override-creds-with-the-ones-from-the-superblock.patch |  6 +++---
  .../patches-4.4/052-01-ubifs-Implement-O_TMPFILE.patch |  2 +-
  .../052-02-ubifs-Implement-RENAME_WHITEOUT.patch   | 14 +++---
  .../052-03-ubifs-Implement-RENAME_EXCHANGE.patch   |  6 +++---
  ...ac-stop-clearing-DMA-receive-control-register-rig.patch |  9 ++---
  .../linux/generic/patches-4.4/201-extra_optimization.patch |  4 ++--
  7 files changed, 20 insertions(+), 25 deletions(-)


--
Koen Vandeputte - Software Developer
koen.vandepu...@ncentric.com | +32499736158


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

[LEDE-DEV] [wiki] Permalinks to page sections

[Baptiste Jonglez]

Hi,

There is a small usability issue with the wiki: there is no easy way to
get a permalink to a page section (i.e. a link that includes an anchor).

First, it would be nice to have a small clickable permalink just beside a
section title.

Also, there is a bug in the table of contents of a page.  The table of
contents provides correct links to sections, but after clicking on the
link, the URL (with the anchor to the section) is not updated in the
address bar of the browser.

For instance:

1) https://wiki.lede-project.org/docs/user-guide/tunneling_interface_protocols
   has a table of contents, with links to sections, for instance
   
https://wiki.lede-project.org/docs/user-guide/tunneling_interface_protocols#protocol_wireguard_wireguard_vpn

2) When clicking on the link to a section, the page scrolls down to the
   section, this is good.

3) However, the URL in the address bar of the browser is still
   https://wiki.lede-project.org/docs/user-guide/tunneling_interface_protocols
   (there is no anchor at the end)

Thanks,
Baptiste


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