[LEDE-DEV] ar71xx: add tp-link 841nd-v9-vn board - 8mbit flash isp oem variant

[Luke McKee]

https://github.com/openwrt/openwrt/pull/29
https://github.com/openwrt/openwrt/pull/29/commits/84c616f66390230a2938f8db691e8093f1669ec2

Please see the commit message or the forum. This has been run-tested
on the new hardware which is basically the same as a v9 board just
with the larger flash size
https://forum.openwrt.org/viewtopic.php?id=65786
Users can install factory.bin's via tp-link firmware, or use
sysupgrade - both tested successfully. As you can see from the factory
rom extracted via uboot, it really does have different HWID's used by
tp-link to distinguish the OEM order for larger flash size. They add a
1 at the end of the HWID to denote that.

If a user bricks a tp-link 841nd v9 , the factory bootloader has a
tftp recovery method as demonstrated. In any case -v9-vn firmware will
not install on -v9 firwmare and visa versa. There isn't much need for
pico''s patched u-boot I think, except for the frills of a web-browser
to upgrade the flash and loosing your Ethernet mac address.

https://www.youtube.com/watch?v=0k1sxwX5pMk

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

[LEDE-DEV] [PATCH] ramips: Cleanup etc/board.d/02_network

[p . wassi]

From: Paul Wassi 

Clean-up duplicate cases and fix alphabetical ordering in 
base-files/etc/board.d/02_network
Signed-off-by: Paul Wassi 
---
linux/ramips/base-files/etc/board.d/02_network |   15 +--
1 file changed, 5 insertions(+), 10 deletions(-)

diff -rupN a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -92,9 +92,12 @@ ramips_setup_interfaces()
wsr-600|\
wt1520|\
y1|\
+   youku-yk1|\
+   zbt-ape522ii|\
+   zbt-we826|\
zbt-wg2626|\
zbt-wg3526|\
-   youku-yk1)
+   zbt-wr8305rt)
ucidef_add_switch "switch0" \
"0:lan" "1:lan" "2:lan" "3:lan" "4:wan" "6@eth0"
;;
@@ -172,6 +175,7 @@ ramips_setup_interfaces()
mzk-ex750np|\
na930|\
wli-tx4-ag300n|\
+   wmr-300|\
wrh-300cr)
ucidef_set_interface_lan "eth0"
;;
@@ -194,9 +198,6 @@ ramips_setup_interfaces()
wl-330n)
ucidef_set_interface_lan "eth0.1"
;;
-   wmr-300)
-   ucidef_set_interface_lan "eth0"
-   ;;
mzk-dp150n|\
vocore)
ucidef_add_switch "switch0" \
@@ -228,12 +229,6 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"1:lan" "2:lan" "0:wan" "6@eth0"
;;
-   zbt-ape522ii|\
-   zbt-we826|\
-   zbt-wr8305rt)
-   ucidef_add_switch "switch0" \
-   "0:lan" "1:lan" "2:lan" "3:lan" "4:wan" "6@eth0"
-   ;;
*)
RT3X5X=`cat /proc/cpuinfo | egrep "(RT3.5|RT5350)"`
if [ -n "${RT3X5X}" ]; then

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

Re: [LEDE-DEV] [PATCH] ramips: Cleanup etc/board.d/02_network

[Jo-Philipp Wich]

Hi Paul,

thank you for your patch!

I merged it into my staging tree with a fixed mail address in the
Signoff line and an additional new line wrap in the commit message to
keep lines shorter than 80 chars.

~ Jo

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

[LEDE-DEV] [PATCH netifd 2/3] interface: Only teardown interfaces having no proto task when l3_dev link lost

[Hans Dedecker]

Commit c6858766 adds teardown support when l3_dev link is lost especially for 
shell protocols
that have no proto task. However shell protocols which have a proto task 
running like ppp will
also be teared down which is not always the expected action.
As an example the PPP daemon can be put into persist state trying to 
re-establish the link via
a hold off mechanism which is not possible when the daemon is terminated by the 
proto shell
teardown.
Therefore restrict the teardown action for shell protocols having no proto task.

Signed-off-by: Hans Dedecker 
---
 interface.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/interface.c b/interface.c
index 7b18cef..8d9dc9c 100644
--- a/interface.c
+++ b/interface.c
@@ -408,7 +408,8 @@ interface_l3_dev_cb(struct device_user *dep, enum 
device_event ev)
 
switch (ev) {
case DEV_EVENT_LINK_DOWN:
-   interface_proto_event(iface->proto, PROTO_CMD_TEARDOWN, false);
+   if (iface->proto->handler->flags & PROTO_FLAG_NO_TASK)
+   interface_proto_event(iface->proto, PROTO_CMD_TEARDOWN, 
false);
break;
default:
break;
-- 
1.9.1


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

[LEDE-DEV] [PATCH netifd 3/3] proto: Display proto flags when dumping the protocol handlers in ubus

[Hans Dedecker]

Signed-off-by: Hans Dedecker 
---
 proto.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/proto.c b/proto.c
index 45eeb4b..4cbf3f4 100644
--- a/proto.c
+++ b/proto.c
@@ -567,7 +567,13 @@ proto_dump_handlers(struct blob_buf *b)
blobmsg_add_string(b, 
p->config_params->params[i].name, uci_get_validate_string(p->config_params, i));
blobmsg_close_table(b, v);
}
+   blobmsg_add_u8(b, "immediate", !!(p->flags & 
PROTO_FLAG_IMMEDIATE));
blobmsg_add_u8(b, "no_device", !!(p->flags & PROTO_FLAG_NODEV));
+   blobmsg_add_u8(b, "init_available", !!(p->flags & 
PROTO_FLAG_INIT_AVAILABLE));
+   blobmsg_add_u8(b, "renew_available", !!(p->flags & 
PROTO_FLAG_RENEW_AVAILABLE));
+   blobmsg_add_u8(b, "force_link_default", !!(p->flags & 
PROTO_FLAG_FORCE_LINK_DEFAULT));
+   blobmsg_add_u8(b, "last_error", !!(p->flags & 
PROTO_FLAG_LASTERROR));
+   blobmsg_add_u8(b, "no_task", !!(p->flags & PROTO_FLAG_NO_TASK));
blobmsg_close_table(b, c);
}
 }
-- 
1.9.1


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

[LEDE-DEV] [PATCH netifd 1/3] proto-shell: Model config parameter "no-proto-task" as a proto flag

[Hans Dedecker]

Export the config parameter "no-proto-task" as a proto flag so it can be checked
by other netifd modules

Signed-off-by: Hans Dedecker 
---
 proto-shell.c | 6 +++---
 proto.h   | 1 +
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/proto-shell.c b/proto-shell.c
index 25dec00..1922024 100644
--- a/proto-shell.c
+++ b/proto-shell.c
@@ -44,7 +44,6 @@ struct proto_shell_handler {
char *config_buf;
char *script_name;
bool init_available;
-   bool no_proto_task;
 
struct uci_blob_param_list config;
 };
@@ -306,7 +305,7 @@ proto_shell_task_finish(struct proto_shell_state *state,
if (state->renew_pending)
proto_shell_handler(&state->proto,
PROTO_CMD_RENEW, false);
-   else if (!state->handler->no_proto_task &&
+   else if (!(state->handler->proto.flags & 
PROTO_FLAG_NO_TASK) &&
 !state->proto_task.uloop.pending &&
 state->sm == S_SETUP)
proto_shell_handler(&state->proto,
@@ -892,7 +891,8 @@ proto_shell_add_handler(const char *script, const char 
*name, json_object *obj)
handler->proto.flags |= PROTO_FLAG_NODEV;
 
tmp = json_get_field(obj, "no-proto-task", json_type_boolean);
-   handler->no_proto_task = tmp && json_object_get_boolean(tmp);
+   if (tmp && json_object_get_boolean(tmp))
+   handler->proto.flags |= PROTO_FLAG_NO_TASK;
 
tmp = json_get_field(obj, "available", json_type_boolean);
if (tmp && json_object_get_boolean(tmp))
diff --git a/proto.h b/proto.h
index 87dec4e..4c4d824 100644
--- a/proto.h
+++ b/proto.h
@@ -38,6 +38,7 @@ enum {
PROTO_FLAG_RENEW_AVAILABLE = (1 << 3),
PROTO_FLAG_FORCE_LINK_DEFAULT = (1 << 4),
PROTO_FLAG_LASTERROR = (1 << 5),
+   PROTO_FLAG_NO_TASK = (1 << 6),
 };
 
 struct interface_proto_state {
-- 
1.9.1


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

Re: [LEDE-DEV] [PATCH v2 1/8] apm821xx: add support for the apm821xx device target

[Felix Fietkau]

On 2016-07-13 21:23, Christian Lamparter wrote:
> From: Chris Blake 
> 
> This adds a new target for PowerPC APM82181 and APM82161
> (464-based) boards, as well as adds support for the booke-wdt
> watchdog package.
> 
> Signed-off-by: Chris Blake 
> ---
>  include/target.mk  |   1 +
>  package/kernel/linux/modules/other.mk  |   2 +-
>  target/linux/apm821xx/Makefile |  28 ++
>  .../linux/apm821xx/base-files/etc/board.d/01_leds  |  17 +
>  .../apm821xx/base-files/etc/board.d/02_network |  19 +
>  target/linux/apm821xx/base-files/etc/diag.sh   |  33 ++
>  target/linux/apm821xx/base-files/etc/inittab   |   4 +
>  target/linux/apm821xx/base-files/lib/apm821xx.sh   |  36 ++
>  .../lib/preinit/03_preinit_do_apm821xx.sh  |   9 +
>  .../lib/preinit/05_set_preinit_iface_apm821xx  |   9 +
>  .../apm821xx/base-files/lib/upgrade/platform.sh|  58 +++
>  target/linux/apm821xx/config-4.4   | 327 +
>  target/linux/apm821xx/image/Makefile   |  22 +
>  ...to4xx-integrate-ppc4xx-rng-into-crypto4xx.patch | 507 
> +
>  .../300-fix-atheros-nics-on-apm82181.patch |  51 +++
>  .../701-powerpc_ibm_apm82181_phyclk_fix.patch  |  56 +++
>  16 files changed, 1178 insertions(+), 1 deletion(-)
>  create mode 100644 target/linux/apm821xx/Makefile
>  create mode 100755 target/linux/apm821xx/base-files/etc/board.d/01_leds
>  create mode 100755 target/linux/apm821xx/base-files/etc/board.d/02_network
>  create mode 100755 target/linux/apm821xx/base-files/etc/diag.sh
>  create mode 100644 target/linux/apm821xx/base-files/etc/inittab
>  create mode 100755 target/linux/apm821xx/base-files/lib/apm821xx.sh
>  create mode 100644 
> target/linux/apm821xx/base-files/lib/preinit/03_preinit_do_apm821xx.sh
>  create mode 100644 
> target/linux/apm821xx/base-files/lib/preinit/05_set_preinit_iface_apm821xx
>  create mode 100755 target/linux/apm821xx/base-files/lib/upgrade/platform.sh
>  create mode 100644 target/linux/apm821xx/config-4.4
>  create mode 100644 target/linux/apm821xx/image/Makefile
>  create mode 100644 
> target/linux/apm821xx/patches-4.4/001-crypto4xx-integrate-ppc4xx-rng-into-crypto4xx.patch
>  create mode 100644 
> target/linux/apm821xx/patches-4.4/300-fix-atheros-nics-on-apm82181.patch
>  create mode 100644 
> target/linux/apm821xx/patches-4.4/701-powerpc_ibm_apm82181_phyclk_fix.patch
> 
> diff --git a/include/target.mk b/include/target.mk
> index b5153ff..7fb298a 100644
> --- a/include/target.mk
> +++ b/include/target.mk
> @@ -208,6 +208,7 @@ ifeq ($(DUMP),1)
>  CPU_CFLAGS_8540:=-mcpu=8540
>  CPU_CFLAGS_405:=-mcpu=405
>  CPU_CFLAGS_440:=-mcpu=440
> +CPU_CFLAGS_464fp:=-mcpu=464fp
>endif
>ifeq ($(ARCH),sparc)
>  CPU_TYPE = sparc
> diff --git a/package/kernel/linux/modules/other.mk 
> b/package/kernel/linux/modules/other.mk
> index a1fce48..ee1ee06 100644
> --- a/package/kernel/linux/modules/other.mk
> +++ b/package/kernel/linux/modules/other.mk
> @@ -517,7 +517,7 @@ $(eval $(call KernelPackage,wdt-orion))
>  define KernelPackage/booke-wdt
>SUBMENU:=$(OTHER_MENU)
>TITLE:=PowerPC Book-E Watchdog Timer
> -  DEPENDS:=@(TARGET_mpc85xx||TARGET_ppc40x||TARGET_ppc44x)
> +  DEPENDS:=@(TARGET_apm821xx||TARGET_mpc85xx||TARGET_ppc40x||TARGET_ppc44x)
>KCONFIG:=CONFIG_BOOKE_WDT
>FILES:=$(LINUX_DIR)/drivers/$(WATCHDOG_DIR)/booke_wdt.ko
>AUTOLOAD:=$(call AutoLoad,50,booke_wdt,1)
Is there any reason to keep this as module? Unless there's a good reason
to do it this way, I would like to make this built-in in the kernel
config on all relevant targets and get rid of the kmod package.

- Felix

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

Re: [LEDE-DEV] [RFC 2/8] toolchain/binutils: add 2.26.1

[Felix Fietkau]

Pushed to my staging tree with some changes (see below)

On 2016-07-13 15:57, Syrone Wong wrote:
> Signed-off-by: Syrone Wong 
> ---
>  toolchain/binutils/Config.in   |  6 
>  toolchain/binutils/Config.version  |  5 +++
>  toolchain/binutils/Makefile|  4 +++
>  .../patches/2.26.1/300-001_ld_makefile_patch.patch | 22 +
>  .../2.26.1/300-012_check_ldrunpath_length.patch| 20 
>  .../2.26.1/400-mips_no_dynamic_linking_sym.patch   | 18 +++
>  ...Change-default-emulation-for-mips64-linux.patch | 37 
> ++
>  7 files changed, 112 insertions(+)
>  create mode 100644 
> toolchain/binutils/patches/2.26.1/300-001_ld_makefile_patch.patch
>  create mode 100644 
> toolchain/binutils/patches/2.26.1/300-012_check_ldrunpath_length.patch
>  create mode 100644 
> toolchain/binutils/patches/2.26.1/400-mips_no_dynamic_linking_sym.patch
>  create mode 100644 
> toolchain/binutils/patches/2.26.1/500-Change-default-emulation-for-mips64-linux.patch
> 
> diff --git a/toolchain/binutils/Config.in b/toolchain/binutils/Config.in
> index 2960c94..16c8005 100644
> --- a/toolchain/binutils/Config.in
> +++ b/toolchain/binutils/Config.in
> @@ -3,6 +3,7 @@
>  choice
>   prompt "Binutils Version" if TOOLCHAINOPTS
>   default BINUTILS_USE_VERSION_2_25_1 if !arc
> + default BINUTILS_USE_VERSION_2_26_1 if !arc
I removed this line

>   default BINUTILS_USE_VERSION_2_26_ARC if arc
>   help
> Select the version of binutils you wish to use.
> diff --git a/toolchain/binutils/Config.version 
> b/toolchain/binutils/Config.version
> index fc7a1f3..2951c0b 100644
> --- a/toolchain/binutils/Config.version
> +++ b/toolchain/binutils/Config.version
> @@ -5,6 +5,10 @@ config BINUTILS_VERSION_2_25_1
>   default y if (!TOOLCHAINOPTS && !arc)
>   bool
>  
> +config BINUTILS_VERSION_2_26_1
> + default y if (!TOOLCHAINOPTS && !arc)
And this one. binutils 2.26.1 should not be enabled by default for
anything just yet, and the default lines there actually had duplicates,
since you didn't remove the 2.25.1 ones.

- Felix

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

Re: [LEDE-DEV] [RFC 4/8] toolchain/gdb: add 7.11.1

[Felix Fietkau]

On 2016-07-13 15:57, Syrone Wong wrote:
> Signed-off-by: Syrone Wong 
> ---
>  toolchain/gdb/Makefile |  4 +--
>  .../gdb/patches/7.11.1/100-no_extern_inline.patch  | 32 
> ++
>  .../gdb/patches/7.11.1/110-no_testsuite.patch  | 21 ++
>  .../7.11.1/120-fix-compile-flag-mismatch.patch | 11 
>  4 files changed, 66 insertions(+), 2 deletions(-)
>  create mode 100644 toolchain/gdb/patches/7.11.1/100-no_extern_inline.patch
>  create mode 100644 toolchain/gdb/patches/7.11.1/110-no_testsuite.patch
>  create mode 100644 
> toolchain/gdb/patches/7.11.1/120-fix-compile-flag-mismatch.patch
I reorganized the patch layout in my staging tree and added a gdb update
patch that does not involve making yet another copy of the patches.

- Felix

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

Re: [LEDE-DEV] [RFC 5/8] toolchain/gcc: add 6.1.0

[Felix Fietkau]

Pushed to my staging tree with some changes. I removed GCC_VERSION_5 and
removed your addition of GCC_VERSION_6 as well.

On 2016-07-13 15:57, Syrone Wong wrote:
> -fno-plt and musl-libc patches already get upstream, then dropped
> in GCC 6. Other patches are almost identical compared to GCC 5.3.
> 
> Compile and run tested on ar71xx/Qihoo C301 and
> mvebu/Linksys WRT1900ac v1
> 
> Signed-off-by: Syrone Wong 
> ---
>  toolchain/gcc/Config.in|   6 +
>  toolchain/gcc/Config.version   |   7 +-
>  toolchain/gcc/common.mk|   4 +
>  .../6.1.0/001-revert_register_mode_search.patch|  65 ++
>  .../gcc/patches/6.1.0/002-case_insensitive.patch   |  14 ++
>  .../gcc/patches/6.1.0/010-documentation.patch  |  23 +++
>  toolchain/gcc/patches/6.1.0/100-uclibc-conf.patch  |  33 +++
>  toolchain/gcc/patches/6.1.0/230-musl_libssp.patch  |  13 ++
>  .../patches/6.1.0/800-arm_v5te_no_ldrd_strd.patch  |  11 +
>  .../patches/6.1.0/810-arm-softfloat-libgcc.patch   |  25 +++
>  toolchain/gcc/patches/6.1.0/820-libgcc_pic.patch   |  36 
>  .../gcc/patches/6.1.0/830-arm_unbreak_armv4t.patch |  13 ++
>  .../6.1.0/840-armv4_pass_fix-v4bx_to_ld.patch  |  19 ++
>  .../gcc/patches/6.1.0/850-use_shared_libgcc.patch  |  47 +
>  .../gcc/patches/6.1.0/851-libgcc_no_compat.patch   |  12 ++
>  .../gcc/patches/6.1.0/870-ppc_no_crtsavres.patch   |  11 +
>  .../gcc/patches/6.1.0/880-no_java_section.patch|  11 +
>  .../gcc/patches/6.1.0/900-bad-mips16-crt.patch |   9 +
>  toolchain/gcc/patches/6.1.0/910-mbsd_multi.patch   | 222 
> +
>  .../patches/6.1.0/920-specs_nonfatal_getenv.patch  |  70 +++
>  .../patches/6.1.0/930-fix-mips-noexecstack.patch   | 111 +++
>  .../patches/6.1.0/940-no-clobber-stamp-bits.patch  |  11 +
>  .../6.1.0/950-cpp_file_path_translation.patch  | 182 +
>  23 files changed, 954 insertions(+), 1 deletion(-)
>  create mode 100644 
> toolchain/gcc/patches/6.1.0/001-revert_register_mode_search.patch
>  create mode 100644 toolchain/gcc/patches/6.1.0/002-case_insensitive.patch
>  create mode 100644 toolchain/gcc/patches/6.1.0/010-documentation.patch
>  create mode 100644 toolchain/gcc/patches/6.1.0/100-uclibc-conf.patch
>  create mode 100644 toolchain/gcc/patches/6.1.0/230-musl_libssp.patch
>  create mode 100644 
> toolchain/gcc/patches/6.1.0/800-arm_v5te_no_ldrd_strd.patch
>  create mode 100644 toolchain/gcc/patches/6.1.0/810-arm-softfloat-libgcc.patch
>  create mode 100644 toolchain/gcc/patches/6.1.0/820-libgcc_pic.patch
>  create mode 100644 toolchain/gcc/patches/6.1.0/830-arm_unbreak_armv4t.patch
>  create mode 100644 
> toolchain/gcc/patches/6.1.0/840-armv4_pass_fix-v4bx_to_ld.patch
>  create mode 100644 toolchain/gcc/patches/6.1.0/850-use_shared_libgcc.patch
>  create mode 100644 toolchain/gcc/patches/6.1.0/851-libgcc_no_compat.patch
>  create mode 100644 toolchain/gcc/patches/6.1.0/870-ppc_no_crtsavres.patch
>  create mode 100644 toolchain/gcc/patches/6.1.0/880-no_java_section.patch
>  create mode 100644 toolchain/gcc/patches/6.1.0/900-bad-mips16-crt.patch
>  create mode 100644 toolchain/gcc/patches/6.1.0/910-mbsd_multi.patch
>  create mode 100644 
> toolchain/gcc/patches/6.1.0/920-specs_nonfatal_getenv.patch
>  create mode 100644 toolchain/gcc/patches/6.1.0/930-fix-mips-noexecstack.patch
>  create mode 100644 
> toolchain/gcc/patches/6.1.0/940-no-clobber-stamp-bits.patch
>  create mode 100644 
> toolchain/gcc/patches/6.1.0/950-cpp_file_path_translation.patch
> 
> diff --git a/toolchain/gcc/Config.in b/toolchain/gcc/Config.in
> index def296f..13cbe7a8 100644
> --- a/toolchain/gcc/Config.in
> +++ b/toolchain/gcc/Config.in
> @@ -4,6 +4,7 @@ choice
>   prompt "GCC compiler Version" if TOOLCHAINOPTS
>   default GCC_USE_VERSION_4_8_ARC if arc
>   default GCC_USE_VERSION_5
> + default GCC_USE_VERSION_6
>   help
> Select the version of gcc you wish to use.
>  
Removed this.

> @@ -17,6 +18,11 @@ choice
>   bool "gcc 5.x"
>   depends on !arc
>  
> + config GCC_USE_VERSION_6
> + select GCC_VERSION_6
And this line

> + bool "gcc 6.x"
> + depends on !arc
> +
>  endchoice
>  
>  config GCC_USE_GRAPHITE
> diff --git a/toolchain/gcc/Config.version b/toolchain/gcc/Config.version
> index f9e8c47..6a95862 100644
> --- a/toolchain/gcc/Config.version
> +++ b/toolchain/gcc/Config.version
> @@ -6,7 +6,8 @@ config GCC_VERSION
>   string
>   default "4.8-linaro"if GCC_VERSION_4_8_LINARO
>   default "arc-2016.03"   if GCC_VERSION_4_8_ARC
> - default "5.3.0"
> + default "5.3.0" if GCC_VERSION_5
> + default "6.1.0" if GCC_VERSION_6
>  
>  config GCC_VERSION_4_8
>   bool
Cleaned up the defaults here.

> @@ -15,3 +16,7 @@ config GCC_VERSION_4_8
>  config GCC_VERSION_5
>   default y if (!TOOLCHAINOPTS && !arc)
>   bool
> +
> +config GCC_VERSION_6
> + 

Re: [LEDE-DEV] [RFC 7/8] config: add gcc 6 info to build rule

[Felix Fietkau]

On 2016-07-13 15:57, Syrone Wong wrote:
> Signed-off-by: Syrone Wong 
> ---
>  config/Config-build.in | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/config/Config-build.in b/config/Config-build.in
> index 23cf83b..7a70862 100644
> --- a/config/Config-build.in
> +++ b/config/Config-build.in
> @@ -236,7 +236,7 @@ menu "Global build settings"
>   config PKG_CC_STACKPROTECTOR_STRONG
>   bool "Strong"
>   select SSP_SUPPORT if !USE_MUSL
> - depends on GCC_VERSION_5
> + depends on (GCC_VERSION_5 || GCC_VERSION_6)
>   depends on KERNEL_CC_STACKPROTECTOR_STRONG
>   endchoice
>  
> @@ -251,7 +251,7 @@ menu "Global build settings"
>   config KERNEL_CC_STACKPROTECTOR_REGULAR
>   bool "Regular"
>   config KERNEL_CC_STACKPROTECTOR_STRONG
> - depends on GCC_VERSION_5
> + depends on (GCC_VERSION_5 || GCC_VERSION_6)
Replaced the dependencies with !GCC_VERSION_4_8 instead.

- Felix


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

Re: [LEDE-DEV] [RFC 8/8] toolchain: choose new toolchain only if

[Felix Fietkau]

On 2016-07-13 15:57, Syrone Wong wrote:
> developer mode has been enabled,
> GCC 5.3 binutils 2.25.1 otherwise.
> 
> Signed-off-by: Syrone Wong 
Unnecessary with the proper defaults fixes. Also, developer mode
shouldn't automagically change the defaults to different gcc/binutils
versions, it should only allow you to make these changes yourself.

- Felix


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

Re: [LEDE-DEV] [RFC 6/8] uclibc++: fix gcc 6 build

[Felix Fietkau]

On 2016-07-13 15:57, Syrone Wong wrote:
> C++14 added sized deallocation, while uclibc++ deleted all files
> (extracted from libsupc++.a via "ar x") named "del_op*.o"
> in abi/libsupc, so I wrote two wrapper files and let them call
> free(ptr) and ignored the size parameter.
> 
> GCC upstream URL: 
> https://github.com/gcc-mirror/gcc/commit/d1856d2c87b844afb0e31f7aa9502745b3446189
> 
> Signed-off-by: Syrone Wong 
> ---
> 
> According to https://gcc.gnu.org/gcc-6/changes.html,
> default C++ mode changed to -std=gnu++14 instead of -std=gnu++98, I added the 
> previous
> mode to presist compiler behaviour.
> 
> I think the program in OpenWrt/LEDE codebase linked to libuClibc++ will not 
> use C++14 features.
> This is the best workaround I can come up with.
I dropped the conditional patching, dealt with g++-uc via defaults
change and simplified the patch.

- Felix


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

Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH netifd 2/3] interface: Only teardown interfaces having no proto task when l3_dev link lost

[Hans Dedecker]

On Thu, Jul 14, 2016 at 12:01 PM, Yousong Zhou  wrote:
> On 14 July 2016 at 16:14, Hans Dedecker  wrote:
>> Commit c6858766 adds teardown support when l3_dev link is lost especially 
>> for shell protocols
>> that have no proto task. However shell protocols which have a proto task 
>> running like ppp will
>> also be teared down which is not always the expected action.
>> As an example the PPP daemon can be put into persist state trying to 
>> re-establish the link via
>> a hold off mechanism which is not possible when the daemon is terminated by 
>> the proto shell
>> teardown.
>> Therefore restrict the teardown action for shell protocols having no proto 
>> task.
>>
>
> How about adding an extra flag like managed-link, persistent-link,
> on-demand-link?  It looks to me doing teardown at link-down is more
> common a case.
Initially I was thinking about adding another flag like you propose
but then I was doubting if the change in behavior for shell protocols
having a proto task task was on purpose or not. In case of PPP and
link failure you don't want an immediate restart by netifd in some
cases (see https://github.com/lede-project/source/pull/200) as PPP
daemon can take care of the link re-negotiation based on a holdoff
timeout.
Additionally if the wan link loses connectivity a link down
notification will be received on the main device which will teardown
the protocol. Anyway I'm open for suggestions which way to go forward.

Hans
>
> Regards,
> yousong
>
>
>> Signed-off-by: Hans Dedecker 
>> ---
>>  interface.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/interface.c b/interface.c
>> index 7b18cef..8d9dc9c 100644
>> --- a/interface.c
>> +++ b/interface.c
>> @@ -408,7 +408,8 @@ interface_l3_dev_cb(struct device_user *dep, enum 
>> device_event ev)
>>
>> switch (ev) {
>> case DEV_EVENT_LINK_DOWN:
>> -   interface_proto_event(iface->proto, PROTO_CMD_TEARDOWN, 
>> false);
>> +   if (iface->proto->handler->flags & PROTO_FLAG_NO_TASK)
>> +   interface_proto_event(iface->proto, 
>> PROTO_CMD_TEARDOWN, false);
>> break;
>> default:
>> break;
>> --
>> 1.9.1
>> ___
>> openwrt-devel mailing list
>> openwrt-de...@lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

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

Re: [LEDE-DEV] [RFC 5/8] toolchain/gcc: add 6.1.0

[Syrone Wong]

Hi Felix,

Thanks for your effort on this. I forgot to refresh the patch offset,
can you help me do it? Although the offset doesn't affect patch
application.
Best Regards,
Syrone Wong


On Thu, Jul 14, 2016 at 6:55 PM, Felix Fietkau  wrote:
> Pushed to my staging tree with some changes. I removed GCC_VERSION_5 and
> removed your addition of GCC_VERSION_6 as well.
>
> On 2016-07-13 15:57, Syrone Wong wrote:
>> -fno-plt and musl-libc patches already get upstream, then dropped
>> in GCC 6. Other patches are almost identical compared to GCC 5.3.
>>
>> Compile and run tested on ar71xx/Qihoo C301 and
>> mvebu/Linksys WRT1900ac v1
>>
>> Signed-off-by: Syrone Wong 
>> ---
>>  toolchain/gcc/Config.in|   6 +
>>  toolchain/gcc/Config.version   |   7 +-
>>  toolchain/gcc/common.mk|   4 +
>>  .../6.1.0/001-revert_register_mode_search.patch|  65 ++
>>  .../gcc/patches/6.1.0/002-case_insensitive.patch   |  14 ++
>>  .../gcc/patches/6.1.0/010-documentation.patch  |  23 +++
>>  toolchain/gcc/patches/6.1.0/100-uclibc-conf.patch  |  33 +++
>>  toolchain/gcc/patches/6.1.0/230-musl_libssp.patch  |  13 ++
>>  .../patches/6.1.0/800-arm_v5te_no_ldrd_strd.patch  |  11 +
>>  .../patches/6.1.0/810-arm-softfloat-libgcc.patch   |  25 +++
>>  toolchain/gcc/patches/6.1.0/820-libgcc_pic.patch   |  36 
>>  .../gcc/patches/6.1.0/830-arm_unbreak_armv4t.patch |  13 ++
>>  .../6.1.0/840-armv4_pass_fix-v4bx_to_ld.patch  |  19 ++
>>  .../gcc/patches/6.1.0/850-use_shared_libgcc.patch  |  47 +
>>  .../gcc/patches/6.1.0/851-libgcc_no_compat.patch   |  12 ++
>>  .../gcc/patches/6.1.0/870-ppc_no_crtsavres.patch   |  11 +
>>  .../gcc/patches/6.1.0/880-no_java_section.patch|  11 +
>>  .../gcc/patches/6.1.0/900-bad-mips16-crt.patch |   9 +
>>  toolchain/gcc/patches/6.1.0/910-mbsd_multi.patch   | 222 
>> +
>>  .../patches/6.1.0/920-specs_nonfatal_getenv.patch  |  70 +++
>>  .../patches/6.1.0/930-fix-mips-noexecstack.patch   | 111 +++
>>  .../patches/6.1.0/940-no-clobber-stamp-bits.patch  |  11 +
>>  .../6.1.0/950-cpp_file_path_translation.patch  | 182 +
>>  23 files changed, 954 insertions(+), 1 deletion(-)
>>  create mode 100644 
>> toolchain/gcc/patches/6.1.0/001-revert_register_mode_search.patch
>>  create mode 100644 toolchain/gcc/patches/6.1.0/002-case_insensitive.patch
>>  create mode 100644 toolchain/gcc/patches/6.1.0/010-documentation.patch
>>  create mode 100644 toolchain/gcc/patches/6.1.0/100-uclibc-conf.patch
>>  create mode 100644 toolchain/gcc/patches/6.1.0/230-musl_libssp.patch
>>  create mode 100644 
>> toolchain/gcc/patches/6.1.0/800-arm_v5te_no_ldrd_strd.patch
>>  create mode 100644 
>> toolchain/gcc/patches/6.1.0/810-arm-softfloat-libgcc.patch
>>  create mode 100644 toolchain/gcc/patches/6.1.0/820-libgcc_pic.patch
>>  create mode 100644 toolchain/gcc/patches/6.1.0/830-arm_unbreak_armv4t.patch
>>  create mode 100644 
>> toolchain/gcc/patches/6.1.0/840-armv4_pass_fix-v4bx_to_ld.patch
>>  create mode 100644 toolchain/gcc/patches/6.1.0/850-use_shared_libgcc.patch
>>  create mode 100644 toolchain/gcc/patches/6.1.0/851-libgcc_no_compat.patch
>>  create mode 100644 toolchain/gcc/patches/6.1.0/870-ppc_no_crtsavres.patch
>>  create mode 100644 toolchain/gcc/patches/6.1.0/880-no_java_section.patch
>>  create mode 100644 toolchain/gcc/patches/6.1.0/900-bad-mips16-crt.patch
>>  create mode 100644 toolchain/gcc/patches/6.1.0/910-mbsd_multi.patch
>>  create mode 100644 
>> toolchain/gcc/patches/6.1.0/920-specs_nonfatal_getenv.patch
>>  create mode 100644 
>> toolchain/gcc/patches/6.1.0/930-fix-mips-noexecstack.patch
>>  create mode 100644 
>> toolchain/gcc/patches/6.1.0/940-no-clobber-stamp-bits.patch
>>  create mode 100644 
>> toolchain/gcc/patches/6.1.0/950-cpp_file_path_translation.patch
>>
>> diff --git a/toolchain/gcc/Config.in b/toolchain/gcc/Config.in
>> index def296f..13cbe7a8 100644
>> --- a/toolchain/gcc/Config.in
>> +++ b/toolchain/gcc/Config.in
>> @@ -4,6 +4,7 @@ choice
>>   prompt "GCC compiler Version" if TOOLCHAINOPTS
>>   default GCC_USE_VERSION_4_8_ARC if arc
>>   default GCC_USE_VERSION_5
>> + default GCC_USE_VERSION_6
>>   help
>> Select the version of gcc you wish to use.
>>
> Removed this.
>
>> @@ -17,6 +18,11 @@ choice
>>   bool "gcc 5.x"
>>   depends on !arc
>>
>> + config GCC_USE_VERSION_6
>> + select GCC_VERSION_6
> And this line
>
>> + bool "gcc 6.x"
>> + depends on !arc
>> +
>>  endchoice
>>
>>  config GCC_USE_GRAPHITE
>> diff --git a/toolchain/gcc/Config.version b/toolchain/gcc/Config.version
>> index f9e8c47..6a95862 100644
>> --- a/toolchain/gcc/Config.version
>> +++ b/toolchain/gcc/Config.version
>> @@ -6,7 +6,8 @@ config GCC_VERSION
>>   string
>>   default "4.8-linaro"if GCC_VERSION_4_8_LINARO
>>   default "arc-2016.03"   if GCC_VERSION_4_8_ARC
>> - 

[LEDE-DEV] sysupgrade on lantiq xrx200 form openwrt to lede

[Florian Eckert]

Hello LEDE-Team

I am using a openwrt 15.05 on an lantiq xrx200 device.
Upgrade works always as expectet for 15.05.
I am using the squashfs tar file.

I wantet to test lede and i have seen that the image generation has
completly changed there is no tar file anymore only bin.
If i use this to make a sysupgrade command i always get the output

Could not open mtd device: firmware
Can't open device for writing!
Upgrade completed
Rebooting system...

In openwrt i always could untar the tar file. To see the structur CONTROL ...
In lede this does not work anymore.

What to i make wrong? Could you explain your changes?

Regards Flo

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

Re: [LEDE-DEV] sysupgrade on lantiq xrx200 form openwrt to lede

[Syrone Wong]

Hi,

You may want to flash back to factory and flash to LEDE via
*-factory.bin. Make sure to set all configurations by hand.
Best Regards,
Syrone Wong


On Thu, Jul 14, 2016 at 8:48 PM, Florian Eckert
 wrote:
> Hello LEDE-Team
>
> I am using a openwrt 15.05 on an lantiq xrx200 device.
> Upgrade works always as expectet for 15.05.
> I am using the squashfs tar file.
>
> I wantet to test lede and i have seen that the image generation has
> completly changed there is no tar file anymore only bin.
> If i use this to make a sysupgrade command i always get the output
>
> Could not open mtd device: firmware
> Can't open device for writing!
> Upgrade completed
> Rebooting system...
>
> In openwrt i always could untar the tar file. To see the structur CONTROL ...
> In lede this does not work anymore.
>
> What to i make wrong? Could you explain your changes?
>
> Regards Flo
>
> ___
> 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] [RFC 5/8] toolchain/gcc: add 6.1.0

[Felix Fietkau]

On 2016-07-14 14:43, Syrone Wong wrote:
> Hi Felix,
> 
> Thanks for your effort on this. I forgot to refresh the patch offset,
> can you help me do it? Although the offset doesn't affect patch
> application.
> Best Regards,
> Syrone Wong
Pushed an updated version with refreshed patches to my staging tree.

- Felix


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

Re: [LEDE-DEV] [RFC 5/8] toolchain/gcc: add 6.1.0

[Syrone Wong]

Good job.
Best Regards,
Syrone Wong


On Thu, Jul 14, 2016 at 9:17 PM, Felix Fietkau  wrote:
> On 2016-07-14 14:43, Syrone Wong wrote:
>> Hi Felix,
>>
>> Thanks for your effort on this. I forgot to refresh the patch offset,
>> can you help me do it? Although the offset doesn't affect patch
>> application.
>> Best Regards,
>> Syrone Wong
> Pushed an updated version with refreshed patches to my staging tree.
>
> - Felix
>

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

Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH netifd 2/3] interface: Only teardown interfaces having no proto task when l3_dev link lost

[Felix Fietkau]

On 2016-07-14 13:28, Hans Dedecker wrote:
> On Thu, Jul 14, 2016 at 12:01 PM, Yousong Zhou  wrote:
>> On 14 July 2016 at 16:14, Hans Dedecker  wrote:
>>> Commit c6858766 adds teardown support when l3_dev link is lost especially 
>>> for shell protocols
>>> that have no proto task. However shell protocols which have a proto task 
>>> running like ppp will
>>> also be teared down which is not always the expected action.
>>> As an example the PPP daemon can be put into persist state trying to 
>>> re-establish the link via
>>> a hold off mechanism which is not possible when the daemon is terminated by 
>>> the proto shell
>>> teardown.
>>> Therefore restrict the teardown action for shell protocols having no proto 
>>> task.
>>>
>>
>> How about adding an extra flag like managed-link, persistent-link,
>> on-demand-link?  It looks to me doing teardown at link-down is more
>> common a case.
> Initially I was thinking about adding another flag like you propose
> but then I was doubting if the change in behavior for shell protocols
> having a proto task task was on purpose or not. In case of PPP and
> link failure you don't want an immediate restart by netifd in some
> cases (see https://github.com/lede-project/source/pull/200) as PPP
> daemon can take care of the link re-negotiation based on a holdoff
> timeout.
> Additionally if the wan link loses connectivity a link down
> notification will be received on the main device which will teardown
> the protocol. Anyway I'm open for suggestions which way to go forward.
Yousong,

please provide some more details on where your commit c6858766 is
actually needed/useful. In all the use cases I can think of, handling
setup/teardown based on the l2 dev should be enough.

- Felix

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

Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH netifd 2/3] interface: Only teardown interfaces having no proto task when l3_dev link lost

[Yousong Zhou]

On 14/07/2016, Felix Fietkau  wrote:
> On 2016-07-14 13:28, Hans Dedecker wrote:
>> On Thu, Jul 14, 2016 at 12:01 PM, Yousong Zhou 
>> wrote:
>>> On 14 July 2016 at 16:14, Hans Dedecker  wrote:
 Commit c6858766 adds teardown support when l3_dev link is lost
 especially for shell protocols
 that have no proto task. However shell protocols which have a proto task
 running like ppp will
 also be teared down which is not always the expected action.
 As an example the PPP daemon can be put into persist state trying to
 re-establish the link via
 a hold off mechanism which is not possible when the daemon is terminated
 by the proto shell
 teardown.
 Therefore restrict the teardown action for shell protocols having no
 proto task.

>>>
>>> How about adding an extra flag like managed-link, persistent-link,
>>> on-demand-link?  It looks to me doing teardown at link-down is more
>>> common a case.
>> Initially I was thinking about adding another flag like you propose
>> but then I was doubting if the change in behavior for shell protocols
>> having a proto task task was on purpose or not. In case of PPP and
>> link failure you don't want an immediate restart by netifd in some
>> cases (see https://github.com/lede-project/source/pull/200) as PPP
>> daemon can take care of the link re-negotiation based on a holdoff
>> timeout.
>> Additionally if the wan link loses connectivity a link down
>> notification will be received on the main device which will teardown
>> the protocol. Anyway I'm open for suggestions which way to go forward.
> Yousong,
>
> please provide some more details on where your commit c6858766 is
> actually needed/useful. In all the use cases I can think of, handling
> setup/teardown based on the l2 dev should be enough.
>
> - Felix
>

The issue them was that when l2tp-xxx went down, netifd has no proto
task state to be notified of, and main_dev state seemed unchanged.  If
I remeber and understand the code correcly other pppd shell protos do
teardown because of proto task event, not any device link state, and I
thought it's reasonable and  should not hurt to do an explicit
teardown on link down.

-- 
yousong

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

Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH netifd 2/3] interface: Only teardown interfaces having no proto task when l3_dev link lost

[Felix Fietkau]

On 2016-07-14 16:53, Yousong Zhou wrote:
> On 14/07/2016, Felix Fietkau  wrote:
>> On 2016-07-14 13:28, Hans Dedecker wrote:
>>> On Thu, Jul 14, 2016 at 12:01 PM, Yousong Zhou 
>>> wrote:
 On 14 July 2016 at 16:14, Hans Dedecker  wrote:
> Commit c6858766 adds teardown support when l3_dev link is lost
> especially for shell protocols
> that have no proto task. However shell protocols which have a proto task
> running like ppp will
> also be teared down which is not always the expected action.
> As an example the PPP daemon can be put into persist state trying to
> re-establish the link via
> a hold off mechanism which is not possible when the daemon is terminated
> by the proto shell
> teardown.
> Therefore restrict the teardown action for shell protocols having no
> proto task.
>

 How about adding an extra flag like managed-link, persistent-link,
 on-demand-link?  It looks to me doing teardown at link-down is more
 common a case.
>>> Initially I was thinking about adding another flag like you propose
>>> but then I was doubting if the change in behavior for shell protocols
>>> having a proto task task was on purpose or not. In case of PPP and
>>> link failure you don't want an immediate restart by netifd in some
>>> cases (see https://github.com/lede-project/source/pull/200) as PPP
>>> daemon can take care of the link re-negotiation based on a holdoff
>>> timeout.
>>> Additionally if the wan link loses connectivity a link down
>>> notification will be received on the main device which will teardown
>>> the protocol. Anyway I'm open for suggestions which way to go forward.
>> Yousong,
>>
>> please provide some more details on where your commit c6858766 is
>> actually needed/useful. In all the use cases I can think of, handling
>> setup/teardown based on the l2 dev should be enough.
>>
>> - Felix
>>
> 
> The issue them was that when l2tp-xxx went down, netifd has no proto
> task state to be notified of, and main_dev state seemed unchanged.  If
> I remeber and understand the code correcly other pppd shell protos do
> teardown because of proto task event, not any device link state, and I
> thought it's reasonable and  should not hurt to do an explicit
> teardown on link down.
It seems to me that we should do less magic here and make the behavior
opt-in via an explicit flag that needs to be enabled by the proto handler.

- Felix

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

Re: [LEDE-DEV] [PATCH v2 1/8] apm821xx: add support for the apm821xx device target

[Christian Lamparter]

On Thursday, July 14, 2016 12:25:58 PM CEST Felix Fietkau wrote:
> On 2016-07-13 21:23, Christian Lamparter wrote:
> > From: Chris Blake 
> > 
> > This adds a new target for PowerPC APM82181 and APM82161
> > (464-based) boards, as well as adds support for the booke-wdt
> > watchdog package.
> > 
> > Signed-off-by: Chris Blake 
> > ---
> > [...]
> > diff --git a/package/kernel/linux/modules/other.mk 
> > b/package/kernel/linux/modules/other.mk
> > index a1fce48..ee1ee06 100644
> > --- a/package/kernel/linux/modules/other.mk
> > +++ b/package/kernel/linux/modules/other.mk
> > @@ -517,7 +517,7 @@ $(eval $(call KernelPackage,wdt-orion))
> >  define KernelPackage/booke-wdt
> >SUBMENU:=$(OTHER_MENU)
> >TITLE:=PowerPC Book-E Watchdog Timer
> > -  DEPENDS:=@(TARGET_mpc85xx||TARGET_ppc40x||TARGET_ppc44x)
> > +  DEPENDS:=@(TARGET_apm821xx||TARGET_mpc85xx||TARGET_ppc40x||TARGET_ppc44x)
> >KCONFIG:=CONFIG_BOOKE_WDT
> >FILES:=$(LINUX_DIR)/drivers/$(WATCHDOG_DIR)/booke_wdt.ko
> >AUTOLOAD:=$(call AutoLoad,50,booke_wdt,1)
> Is there any reason to keep this as module? Unless there's a good reason
> to do it this way, I would like to make this built-in in the kernel
> config on all relevant targets and get rid of the kmod package.
Probably not [0]. I've made a patch which removes the module and
enables the watchdog in the kernel configs for the affected boards.

Regards,
Christian

[0] One issue I can think of: limited "kernel image" space in the
mtd partition. The only apm821xx board which could develop a problem
would be the WNDR4700. Netgear's uboot has fixed the kernel partition
to 2M and the lzma -9 compressed kernel image with 4.4.15 is 1.5M.
The MR24 has proper ubi support in the bootloader, so the kernel can
be as big as needed. For the WD MyBook Live Series this isn't a issue
either since the kernel is loaded from the HDD (boot partition, still
there is plenty of space there).
---
>From a7aaadfe488d806efe1f3aa58f45fe8c2afa3423 Mon Sep 17 00:00:00 2001
From: Christian Lamparter 
Date: Thu, 14 Jul 2016 16:22:51 +0200
Subject: [PATCH] ppc4xx: remove booke-wdt watchdog package

This patch gets rid of the booke watchdog kmod package.
Instead the affected boards will enable it in their
kernel configs.

Signed-off-by: Christian Lamparter 
---
 package/kernel/linux/modules/other.mk | 16 
 target/linux/apm821xx/Makefile|  2 +-
 target/linux/apm821xx/config-4.4  |  1 +
 target/linux/mpc85xx/Makefile |  3 +--
 target/linux/mpc85xx/config-4.4   |  1 +
 target/linux/ppc40x/config-3.18   |  1 +
 target/linux/ppc44x/config-3.18   |  1 +
 7 files changed, 6 insertions(+), 19 deletions(-)

diff --git a/package/kernel/linux/modules/other.mk 
b/package/kernel/linux/modules/other.mk
index ee1ee06..3f7a3ee 100644
--- a/package/kernel/linux/modules/other.mk
+++ b/package/kernel/linux/modules/other.mk
@@ -514,22 +514,6 @@ endef
 $(eval $(call KernelPackage,wdt-orion))
 
 
-define KernelPackage/booke-wdt
-  SUBMENU:=$(OTHER_MENU)
-  TITLE:=PowerPC Book-E Watchdog Timer
-  DEPENDS:=@(TARGET_apm821xx||TARGET_mpc85xx||TARGET_ppc40x||TARGET_ppc44x)
-  KCONFIG:=CONFIG_BOOKE_WDT
-  FILES:=$(LINUX_DIR)/drivers/$(WATCHDOG_DIR)/booke_wdt.ko
-  AUTOLOAD:=$(call AutoLoad,50,booke_wdt,1)
-endef
-
-define KernelPackage/booke-wdt/description
- Kernel module for PowerPC Book-E Watchdog Timer
-endef
-
-$(eval $(call KernelPackage,booke-wdt))
-
-
 define KernelPackage/rtc-ds1307
   SUBMENU:=$(OTHER_MENU)
   TITLE:=Dallas/Maxim DS1307 (and compatible) RTC support
diff --git a/target/linux/apm821xx/Makefile b/target/linux/apm821xx/Makefile
index f8246c4..d52829e 100644
--- a/target/linux/apm821xx/Makefile
+++ b/target/linux/apm821xx/Makefile
@@ -20,7 +20,7 @@ include $(INCLUDE_DIR)/target.mk
 KERNELNAME:=uImage
 
 DEFAULT_PACKAGES += \
-   kmod-leds-gpio kmod-booke-wdt kmod-i2c-core kmod-gpio-button-hotplug
+   kmod-leds-gpio kmod-i2c-core kmod-gpio-button-hotplug
 
 define Target/Description
Build images for AppliedMicro APM821xx based boards.
diff --git a/target/linux/apm821xx/config-4.4 b/target/linux/apm821xx/config-4.4
index 858952c..1515dda 100644
--- a/target/linux/apm821xx/config-4.4
+++ b/target/linux/apm821xx/config-4.4
@@ -36,6 +36,7 @@ CONFIG_AUDIT_ARCH=y
 CONFIG_BCH=y
 # CONFIG_BLUESTONE is not set
 CONFIG_BOOKE=y
+CONFIG_BOOKE_WDT=y
 CONFIG_BOUNCE=y
 # CONFIG_CANYONLANDS is not set
 # CONFIG_IKAREM is not set
diff --git a/target/linux/mpc85xx/Makefile b/target/linux/mpc85xx/Makefile
index a32be90..efd48d7 100644
--- a/target/linux/mpc85xx/Makefile
+++ b/target/linux/mpc85xx/Makefile
@@ -25,8 +25,7 @@ endif
 
 DEFAULT_PACKAGES += \
kmod-input-core kmod-input-gpio-keys kmod-button-hotplug \
-   kmod-leds-gpio kmod-booke-wdt \
-   swconfig kmod-ath9k wpad-mini
+   kmod-leds-gpio swconfig kmod-ath9k wpad-mini
 
 define Target/Description
Build images for the Freescale MPC85xx based boards.
diff --git a/target/linux/mpc85xx/config-4.4 b/t

Re: [LEDE-DEV] [PATCH v2 0/8] apm821xx: apm821xx platform

[Chris Blake]

I can confirm that these patches work to make functional images for
the Meraki MR24, as expected.

Regards,
Chris Blake

On Wed, Jul 13, 2016 at 2:23 PM, Christian Lamparter
 wrote:
> This series was initially posted to OpenWRT List back in March,
> April 2016 for inclusion [0]. The APM821XX target will add support for:
>  - Cisco Meraki MR24
>  - Western Digital MyBook Live and MyBook Live Duo
>  - Netgear Centria N900 WNDR4700 / WNDR4720
>
> The SATA backports were split into separate patches as they became too
> big for the mailing list (also, it's a backport, so people might want
> to skip it). The driver for the tc654 will be submitted to upstream.
>
> Information and pre-compiled images can be found in the project's
> wiki [1].
>
> [0] 
> [1] 
> [2] 
>
> BTW: LG N1T3 and the Monoprice 4-Bay NAS have an APM82181 too.
> If someone has them and is interested, please feel free to
> contact us.
>
> Chris Blake (2):
>   apm821xx: add support for the apm821xx device target
>   apm821xx: add support for the Cisco Meraki MR24
>
> Christian Lamparter (6):
>   apm821xx: dw_dmac: backport fixes and cleanups from 4.7
>   apm821xx: sata_dwc_460ex: backport fixes and cleanups from 4.7
>   apm821xx: add support for the Western Digital MyBook Live Series
>   apm821xx: tc654: add driver for Microchip TC654/TC655 PWM fan
> controllers
>   apm821xx: lm90 add thermal sensor interface support for device tree
>   apm821xx: add support for the Netgear Centria N900 WNDR4700/WNDR4720
>
>  include/target.mk  |1 +
>  package/firmware/uPD72020x-firmware/Makefile   |   45 +
>  package/kernel/linux/modules/other.mk  |2 +-
>  target/linux/apm821xx/Makefile |   29 +
>  .../linux/apm821xx/base-files/etc/board.d/01_leds  |   36 +
>  .../apm821xx/base-files/etc/board.d/02_network |   29 +
>  target/linux/apm821xx/base-files/etc/diag.sh   |   45 +
>  .../etc/hotplug.d/firmware/10-ath9k-eeprom |   89 ++
>  target/linux/apm821xx/base-files/etc/inittab   |4 +
>  target/linux/apm821xx/base-files/lib/apm821xx.sh   |   48 +
>  .../lib/preinit/03_preinit_do_apm821xx.sh  |9 +
>  .../lib/preinit/05_set_iface_mac_apm821xx  |   14 +
>  .../lib/preinit/05_set_preinit_iface_apm821xx  |9 +
>  .../apm821xx/base-files/lib/preinit/79_move_config |   13 +
>  .../apm821xx/base-files/lib/upgrade/merakinand.sh  |   65 +
>  .../apm821xx/base-files/lib/upgrade/platform.sh|   89 ++
>  .../apm821xx/base-files/lib/upgrade/wdbook.sh  |   36 +
>  target/linux/apm821xx/cisco/config-default |   15 +
>  target/linux/apm821xx/cisco/target.mk  |   11 +
>  target/linux/apm821xx/config-4.4   |  331 +
>  target/linux/apm821xx/dts/MR24.dts |  433 ++
>  target/linux/apm821xx/dts/apollo3g-duo.dts |   18 +
>  target/linux/apm821xx/dts/apollo3g.dts |   34 +
>  target/linux/apm821xx/dts/apollo3g.dtsi|  489 +++
>  target/linux/apm821xx/dts/wndr4700.dts |  762 ++
>  .../files/arch/powerpc/platforms/44x/wndr4700.c|   96 ++
>  target/linux/apm821xx/image/Makefile   |  247 
>  target/linux/apm821xx/image/mbl_boot.scr   |6 +
>  target/linux/apm821xx/image/mbl_gen_hdd_img.sh |   27 +
>  .../linux/apm821xx/image/mbl_gen_recovery_tar.sh   |   92 ++
>  target/linux/apm821xx/mbl/config-default   |   44 +
>  target/linux/apm821xx/mbl/target.mk|   11 +
>  target/linux/apm821xx/netgear/config-default   |   45 +
>  target/linux/apm821xx/netgear/target.mk|8 +
>  ...to4xx-integrate-ppc4xx-rng-into-crypto4xx.patch |  507 +++
>  .../002-powerpc_ibm_phy_add_ar8035.patch   |   62 +
>  ...dd-transfer-termination-synchronization-s.patch |  143 ++
>  ...ore-Introduce-new-universal-API-to-reques.patch |  345 +
>  ...dd-transfer-termination-synchronization-s.patch |  293 
>  .../patches-4.4/015-dmaengine-dw-fixed.patch   | 1522 
> 
>  .../linux/apm821xx/patches-4.4/020-sata-dwc.patch  | 1088 ++
>  .../patches-4.4/030-usb-dwc2-endian-fix.patch  |   95 ++
>  .../200-add-meraki-mr24-ikarem-support.patch   |   31 +
>  .../201-add-amcc-apollo3g-support.patch|   30 +
>  .../202-add-netgear-wndr4700-support.patch |   32 +
>  .../300-fix-atheros-nics-on-apm82181.patch |   51 +
>  .../patches-4.4/301-fix-memory-map-wndr4700.patch  |   14 +
>  .../701-powerpc_ibm_apm82181_phyclk_fix.patch  |   56 +
>  .../702-powerpc_ibm_phy_add_dt_parser.patch|  335 +
>  .../800-usb-dwc2-add-wndr4700-otg.patch|   48 +
>  .../801-usb-pci-quirks-add-renesas-fw-loader.patch |  420 ++
>  .../802-usb-xhci-force-

[LEDE-DEV] Mail notifications from Flyspray

[Ted Hess]

Hi all -

As reported - there was a problem with email notification from our bug tracking
system. This problem has been cleared up and notifications are being delivered
once again.

If anyone has tried to register on bugs.lede-project.org and did not receive
their email confirmation, you should be able to request it again by re-
registering. If you have problems with registration please send us an email at
lede-adm or lede-dev lists.

/ted

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

Re: [LEDE-DEV] [PATCH v2 2/8] apm821xx: add support for the Cisco Meraki MR24

[Felix Fietkau]

On 2016-07-13 21:23, Christian Lamparter wrote:
> From: Chris Blake 
> 
> This patch adds support for the Cisco Meraki MR24 Access point
> to the apm821xx target.
> 
> Board:MR24 - Meraki MR24 Cloud Managed Access Point
> CPU:  APM82181 SoC 800 MHz (PLB=200 OPB=100 EBC=100)
> Flash size:   32MiB
> RAM Size: 128MiB
> Wireless: Atheros AR9380 5.0GHz + Atheros AR9380 2.4GHz
> Ethernet ports:   1x Gigabit Atheros AR8035
> 
> WARNING: The serial port needs a TTL/RS-232 v3.3 level converter!
> 
> For flashing instructions, visit:
> 
> 
> Signed-off-by: Chris Blake 
> ---
>  target/linux/apm821xx/Makefile |   1 +
>  .../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   |   4 +
>  target/linux/apm821xx/base-files/lib/apm821xx.sh   |   4 +
>  .../lib/preinit/05_set_iface_mac_apm821xx  |  14 +
>  .../apm821xx/base-files/lib/upgrade/merakinand.sh  |  65 
>  .../apm821xx/base-files/lib/upgrade/platform.sh|   9 +
>  target/linux/apm821xx/cisco/config-default |  15 +
>  target/linux/apm821xx/cisco/target.mk  |  11 +
>  target/linux/apm821xx/config-4.4   |   1 +
>  target/linux/apm821xx/dts/MR24.dts | 433 
> +
>  target/linux/apm821xx/image/Makefile   |  81 +++-
>  .../002-powerpc_ibm_phy_add_ar8035.patch   |  62 +++
>  .../200-add-meraki-mr24-ikarem-support.patch   |  31 ++
>  tools/firmware-utils/src/mkmerakifw.c  |  10 +
>  16 files changed, 742 insertions(+), 10 deletions(-)
>  create mode 100644 
> target/linux/apm821xx/base-files/lib/preinit/05_set_iface_mac_apm821xx
>  create mode 100755 target/linux/apm821xx/base-files/lib/upgrade/merakinand.sh
>  create mode 100644 target/linux/apm821xx/cisco/config-default
>  create mode 100644 target/linux/apm821xx/cisco/target.mk
>  create mode 100644 target/linux/apm821xx/dts/MR24.dts
>  create mode 100644 
> target/linux/apm821xx/patches-4.4/002-powerpc_ibm_phy_add_ar8035.patch
>  create mode 100644 
> target/linux/apm821xx/patches-4.4/200-add-meraki-mr24-ikarem-support.patch
> 
> diff --git a/target/linux/apm821xx/Makefile b/target/linux/apm821xx/Makefile
> index ba3b179..809f2f1 100644
> --- a/target/linux/apm821xx/Makefile
> +++ b/target/linux/apm821xx/Makefile
> @@ -11,6 +11,7 @@ CPU_TYPE:=464fp
>  FEATURES:=fpu dt gpio
>  MAINTAINER:=Chris Blake , \
>   Christian Lamparter 
> +SUBTARGETS:=cisco
>  
>  KERNEL_PATCHVER:=4.4
>  
Having one subtarget per device is overkill. Is there any reason why you
cannot support all devices from the same target without having
subtargets at all?

- Felix

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

Re: [LEDE-DEV] [PATCH v2 8/8] apm821xx: add support for the Netgear Centria N900 WNDR4700/WNDR4720

[Felix Fietkau]

On 2016-07-13 21:23, Christian Lamparter wrote:
> From: Christian Lamparter 
> 
> This patch adds support for Netgear Centria N900 WNDR4700/WNDR4720
> 
> hardware highlights:
> 
> CPU:  AMCC PowerPC APM82181 Rev. E at 1000 MHz (PLB=166, OPB=83, EBC=83 MHz)
>   Security support, Boot ROM Location NAND wo/ECC 2k page (8 bits)
>   32 kB I-Cache 32 kB D-Cache, 256 kB L2-Cache, 32 kB OnChip Memory
> Board:AMCC APM82181 Evaluation Board, PCIE0/SATA1, 1*USB OTG
> DRAM: 256 MB (ECC not enabled, 500 Mb/s, 32-bit, CL3)
> NAND: 128 MiB (SLC, erase size: 128 KiB, page size: 2048, OOB size: 64)
> ETH:  Atheros AR8327N Gigabit Switch (4 x LAN, 1 x WAN)
> USB:  2 x 3.0 (Renesas uPD720202K8-711-BAA-A)
> SATA: 1 x SATA-II 3.5" Hard Drive Bay for HDDs (DesignWare SATA).
> WLAN1:Atheros AR9380 5GHz 802.11an 3:3x3
> WLAN2:Atheros AR9581 2.4GHz 802.11bgn 3:3x3
> SDCARD:   GL827L SD/MMC/MS Flash Card Reader (on internal dwc2 USB 2.0 
> host)
> I2C:  GMT G781 (i2c-0 @ 0x4d - lm90 compatible temperature sensor)
>   TC654(i2c-0 @ 0x1b - Dual PWM fan Speed controller)
> 
> WARNING: The serial port needs a TTL/RS-232 v3.3 level converter!
> 
> INFO: Since this device only has a NAND chip. I opted for going with
> root.squashfs in a UBI volume. There's no squashfs/jffs2 image.
> 
> This target produces three images.
>   a. netgear factory image
>  This image can be used to flash the Netgear WNDR4700 via the
>  firmware recovery mechanism and the web admin site.
> 
>  The bootloader can be instructed to do a firmware recovery via the
>  # fw_recovery
>  command. It will start a tftp server and listen on 192.168.1.1
>  (the ipaddr variable in u-boot) for incoming, binary tftp clients.
>  The firmware recovery mechanism is also started if any of the flash
>  content which contains the kernel, device-tree definitions or the
>  (fake)rootfs fails to verify or load.
> 
>   b. sysupgrade.tar image for sysupgrade
>  An sysupgrade will replace the entire current LEDE installation
>  with a newer version. This does include the kernel and the ubi rootfs
>  partition. The configuration can be carried over automatically as well
>  if desired.
> 
>  simply copy the sysupgrade.tar to a the WNDR4700 running LEDE and run:
> 
>  root@lede:~# sysupgrade sysupgrade.tar
> 
>  and let it reboot.
> 
>  Note: The devicetree flash area is NOT updated. Until the devicetree
>  definition is stable, this can lead to all sorts of hardware
>  detection problems! So make sure, if you experience issues: try
>  the fw_recovery. If you are unsure whenever this affects you:
>  test if you can reproduce your issue with the initramfs method.
>  As it will always have up-to-date device-tree definitions.
> 
>   c. initramfs image for TFTP (for development and testing)
>  To use the initramfs method, follow the following steps:
>1) Move the "lede-apm821xx-netgear-WNDR4700-initramfs-kernel.bin"
> file to to the root directory of your TFTP server.
> 
>2) rename it to wndr4700.bin
> 
>3) On the WNDR4700 - Hit Enter during u-boot and insert:
> # tftp 40 wndr4700.bin; run addtty; bootm 40 -
> 
>  This will boot the LEDE image.
> 
>  Note: The default tftp server is 192.168.1.7, if you want to change it:
>  # setenv serverip 192.168.8.7;
> 
>  Note2: The default address for the WNDR4700 is 192.168.1.1:
>  # setenv ipaddr 192.168.8.8;
> 
>  Note: Connect you tftp server on the last LAN port (not the WAN)
> 
> Signed-off-by: Christian Lamparter 
> ---

> --- /dev/null
> +++ b/package/firmware/uPD72020x-firmware/Makefile
> @@ -0,0 +1,45 @@
> +include $(TOPDIR)/rules.mk
> +
> +PKG_NAME:=uPD72020x-firmware
> +PKG_RELEASE:=1
> +
> +RENESAS_FW:=USB3-201-202-FW-20120615
> +RENESAS_FW_FILE:=$(RENESAS_FW).zip
> +
> +PKG_SOURCE:=$(PKG_NAME)-$(PKG_RELEASE).tar.gz
> +PKG_SOURCE_PROTO:=git
> +PKG_SOURCE_URL:=https://github.com/chunkeey/renesas-fw
> +PKG_SOURCE_VERSION:=f64132a3bca64b47994fce140c69e2b432751162
> +PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_RELEASE)
> +
> +PKG_FLAGS:=nonshared
> +
> +include $(INCLUDE_DIR)/package.mk
> +
> +define Package/uPD72020x-firmware
> +  SECTION:=firmware
> +  CATEGORY:=Firmware
> +  TITLE:=Renesas uPD720201 and uPD720202 firmware
> +endef
> +
> +define Package/uPD72020x-firmware/description
> +  Firmware for the Renesas USB3.0 Host Controllers uPD720201 and uPD720202.
> +endef
What's the license of this firmware? Is it redistributable?

- Felix


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

Re: [LEDE-DEV] [PATCH v2 2/8] apm821xx: add support for the Cisco Meraki MR24

[Christian Lamparter]

On Thursday, July 14, 2016 6:39:34 PM CEST Felix Fietkau wrote:
> On 2016-07-13 21:23, Christian Lamparter wrote:
> > From: Chris Blake 
> > 
> > This patch adds support for the Cisco Meraki MR24 Access point
> > to the apm821xx target.
> > 
> > Board:  MR24 - Meraki MR24 Cloud Managed Access Point
> > CPU:APM82181 SoC 800 MHz (PLB=200 OPB=100 EBC=100)
> > Flash size: 32MiB
> > RAM Size:   128MiB
> > Wireless:   Atheros AR9380 5.0GHz + Atheros AR9380 2.4GHz
> > Ethernet ports: 1x Gigabit Atheros AR8035
> > 
> > WARNING: The serial port needs a TTL/RS-232 v3.3 level converter!
> > 
> > For flashing instructions, visit:
> > 
> > 
> > Signed-off-by: Chris Blake 
> > ---
> >  target/linux/apm821xx/Makefile |   1 +
> >  .../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   |   4 +
> >  target/linux/apm821xx/base-files/lib/apm821xx.sh   |   4 +
> >  .../lib/preinit/05_set_iface_mac_apm821xx  |  14 +
> >  .../apm821xx/base-files/lib/upgrade/merakinand.sh  |  65 
> >  .../apm821xx/base-files/lib/upgrade/platform.sh|   9 +
> >  target/linux/apm821xx/cisco/config-default |  15 +
> >  target/linux/apm821xx/cisco/target.mk  |  11 +
> >  target/linux/apm821xx/config-4.4   |   1 +
> >  target/linux/apm821xx/dts/MR24.dts | 433 
> > +
> >  target/linux/apm821xx/image/Makefile   |  81 +++-
> >  .../002-powerpc_ibm_phy_add_ar8035.patch   |  62 +++
> >  .../200-add-meraki-mr24-ikarem-support.patch   |  31 ++
> >  tools/firmware-utils/src/mkmerakifw.c  |  10 +
> >  16 files changed, 742 insertions(+), 10 deletions(-)
> >  create mode 100644 
> > target/linux/apm821xx/base-files/lib/preinit/05_set_iface_mac_apm821xx
> >  create mode 100755 
> > target/linux/apm821xx/base-files/lib/upgrade/merakinand.sh
> >  create mode 100644 target/linux/apm821xx/cisco/config-default
> >  create mode 100644 target/linux/apm821xx/cisco/target.mk
> >  create mode 100644 target/linux/apm821xx/dts/MR24.dts
> >  create mode 100644 
> > target/linux/apm821xx/patches-4.4/002-powerpc_ibm_phy_add_ar8035.patch
> >  create mode 100644 
> > target/linux/apm821xx/patches-4.4/200-add-meraki-mr24-ikarem-support.patch
> > 
> > diff --git a/target/linux/apm821xx/Makefile b/target/linux/apm821xx/Makefile
> > index ba3b179..809f2f1 100644
> > --- a/target/linux/apm821xx/Makefile
> > +++ b/target/linux/apm821xx/Makefile
> > @@ -11,6 +11,7 @@ CPU_TYPE:=464fp
> >  FEATURES:=fpu dt gpio
> >  MAINTAINER:=Chris Blake , \
> > Christian Lamparter 
> > +SUBTARGETS:=cisco
> >  
> >  KERNEL_PATCHVER:=4.4
> >  
> Having one subtarget per device is overkill. Is there any reason why you
> cannot support all devices from the same target without having
> subtargets at all?
This is mostly because with subtargets, it's possible to have different
kernel configs.

MyBook Live is somewhat unique compared to the MR24 or the WNDR4700. It has to
do without any flash (the 512Kb flash on the MBL only contains the u-boot). 
The target's boot and rootfs has to be located on the SATA drive, so the MBL
needs to have the ext2/4 built-in to boot. (WD's u-boot requires the bootfs 
to be ext2. We could do without it, if we didn't care about sysupgrade).

The problem with having a shared target for MR24 and WNDR4700 is that the they
have different hard-coded addresses (CONFIG_PPC_EARLY_DEBUG_44x_PHYSLOW) for 
the early console. Other than that, there is AFICT no reason.

So, what's the plan? Have a NAS and ROUTER subtarget? And forget about the early
console?

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

Re: [LEDE-DEV] [PATCH v2 2/8] apm821xx: add support for the Cisco Meraki MR24

[Felix Fietkau]

On 2016-07-14 21:39, Christian Lamparter wrote:
> This is mostly because with subtargets, it's possible to have different
> kernel configs.
> 
> MyBook Live is somewhat unique compared to the MR24 or the WNDR4700. It has to
> do without any flash (the 512Kb flash on the MBL only contains the u-boot). 
> The target's boot and rootfs has to be located on the SATA drive, so the MBL
> needs to have the ext2/4 built-in to boot. (WD's u-boot requires the bootfs 
> to be ext2. We could do without it, if we didn't care about sysupgrade).
> 
> The problem with having a shared target for MR24 and WNDR4700 is that the they
> have different hard-coded addresses (CONFIG_PPC_EARLY_DEBUG_44x_PHYSLOW) for 
> the early console. Other than that, there is AFICT no reason.
> 
> So, what's the plan? Have a NAS and ROUTER subtarget? And forget about the 
> early
> console?
I don't think early console is worth having subtargets for. And
regarding router vs nas: how much flash does the router have? Can it
handle the extra stuff that NAS devices need in their kernel config?

Having unnecessary extra subtargets wastes resources on snapshot builds
and releases, so I want as few of them as possible.

- Felix

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

Re: [LEDE-DEV] [PATCH v2 8/8] apm821xx: add support for the Netgear Centria N900 WNDR4700/WNDR4720

[Christian Lamparter]

On Thursday, July 14, 2016 6:44:17 PM CEST Felix Fietkau wrote:
> On 2016-07-13 21:23, Christian Lamparter wrote:
> > From: Christian Lamparter 
> > 
> > This patch adds support for Netgear Centria N900 WNDR4700/WNDR4720
> > 
> > hardware highlights:
> > 
> > CPU:AMCC PowerPC APM82181 Rev. E at 1000 MHz (PLB=166, OPB=83, 
> > EBC=83 MHz)
> > Security support, Boot ROM Location NAND wo/ECC 2k page (8 bits)
> > 32 kB I-Cache 32 kB D-Cache, 256 kB L2-Cache, 32 kB OnChip Memory
> > Board:  AMCC APM82181 Evaluation Board, PCIE0/SATA1, 1*USB OTG
> > DRAM:   256 MB (ECC not enabled, 500 Mb/s, 32-bit, CL3)
> > NAND:   128 MiB (SLC, erase size: 128 KiB, page size: 2048, OOB size: 
> > 64)
> > ETH:Atheros AR8327N Gigabit Switch (4 x LAN, 1 x WAN)
> > USB:2 x 3.0 (Renesas uPD720202K8-711-BAA-A)
[...]
> > --- /dev/null
> > +++ b/package/firmware/uPD72020x-firmware/Makefile
> > @@ -0,0 +1,45 @@
> > +include $(TOPDIR)/rules.mk
> > +
> > +PKG_NAME:=uPD72020x-firmware
> > +PKG_RELEASE:=1
> > +
> > +RENESAS_FW:=USB3-201-202-FW-20120615
> > +RENESAS_FW_FILE:=$(RENESAS_FW).zip
> > +
> > +PKG_SOURCE:=$(PKG_NAME)-$(PKG_RELEASE).tar.gz
> > +PKG_SOURCE_PROTO:=git
> > +PKG_SOURCE_URL:=https://github.com/chunkeey/renesas-fw
> > +PKG_SOURCE_VERSION:=f64132a3bca64b47994fce140c69e2b432751162
> > +PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_RELEASE)
> > +
> > +PKG_FLAGS:=nonshared
> > +
> > +include $(INCLUDE_DIR)/package.mk
> > +
> > +define Package/uPD72020x-firmware
> > +  SECTION:=firmware
> > +  CATEGORY:=Firmware
> > +  TITLE:=Renesas uPD720201 and uPD720202 firmware
> > +endef
> > +
> > +define Package/uPD72020x-firmware/description
> > +  Firmware for the Renesas USB3.0 Host Controllers uPD720201 and uPD720202.
> > +endef
> What's the license of this firmware? Is it redistributable?
You could say: At the moment, it shares the same license as
package/firmware/b43legacy-firmware.

I've contacted Renesas a while ago, I'm still waiting for a reply. It's
not that unlikely that it could show up in linux-firmware.git with the
same licence as the rcar-platform, but this hasn't happen yet.

The downloaded firmware.zip from renesas itself doesn't have a licence
file. There is a license floating around on the PP2U's directory together
with the release notes however: 


"[...] With respect to this Software GNU General Public License（“GPL”）shall 
apply.
YOU may, therefore, copy, modify and re-distribute the Software in accordance
with the GPL.
Please see here to obtain the conditions of GPL.
http://www.fsf.org/licensing/licenses/gpl.html

[...]"

But this could very well be for something else entirely. 
As they made various serial rom flashers for this and a
modified kernel driver for the early adopters.

I've also looked in Netgears's GPL Sources for the WNDR4700. 
The archive Netgear provides includes the crucial K2013080.mem file
(located: WNDR4700-V1.0.0.52_gpl_src/target/linux/wndr4700/renesas).
But without any matching licence file.

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

Re: [LEDE-DEV] [PATCH v2 2/8] apm821xx: add support for the Cisco Meraki MR24

[Christian Lamparter]

On Thursday, July 14, 2016 10:02:36 PM CEST Felix Fietkau wrote:
> On 2016-07-14 21:39, Christian Lamparter wrote:
> > This is mostly because with subtargets, it's possible to have different
> > kernel configs.
> > 
> > MyBook Live is somewhat unique compared to the MR24 or the WNDR4700. It has 
> > to
> > do without any flash (the 512Kb flash on the MBL only contains the u-boot). 
> > The target's boot and rootfs has to be located on the SATA drive, so the MBL
> > needs to have the ext2/4 built-in to boot. (WD's u-boot requires the bootfs 
> > to be ext2. We could do without it, if we didn't care about sysupgrade).
> > 
> > The problem with having a shared target for MR24 and WNDR4700 is that the 
> > they
> > have different hard-coded addresses (CONFIG_PPC_EARLY_DEBUG_44x_PHYSLOW) 
> > for 
> > the early console. Other than that, there is AFICT no reason.
> > 
> > So, what's the plan? Have a NAS and ROUTER subtarget? And forget about the 
> > early
> > console?
> I don't think early console is worth having subtargets for. 
Having individual kernel-configs for targets would solve this.

> And regarding router vs nas: how much flash does the router have? Can it
> handle the extra stuff that NAS devices need in their kernel config?
The WNDR4700's kernel's uimage can be max 2M. Currently a lzma'd uimage
is at 1.5M. ext4 built-in will add another 150k. dm and md 

> Having unnecessary extra subtargets wastes resources on snapshot builds
> and releases, so I want as few of them as possible.
I've looked into a shared subtarget. One problem that came up was with the
"ext4" [0], "ramdisk" [1], squashfs, nand features in the FEATURES list.

[0] MR24 will now select the CONFIG_TARGET_ROOTFS_EXT4FS option by
default and generate a useless ext4 rootfs. (Default 48M)

Note: The WNDR4700 will also generate a ext4 image. However, since it
  has the option for a HDD, a rootfs on the HDD is do-able with 
  some additional work (e.g.:  cmdline).

[1] MyBook Live will now generate useless ramdisk and squashfs images.

What should I do about those?

Regards,
Christian

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

Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH netifd 2/3] interface: Only teardown interfaces having no proto task when l3_dev link lost

[Hans Dedecker]

On Thu, Jul 14, 2016 at 4:56 PM, Felix Fietkau  wrote:
> On 2016-07-14 16:53, Yousong Zhou wrote:
>> On 14/07/2016, Felix Fietkau  wrote:
>>> On 2016-07-14 13:28, Hans Dedecker wrote:
 On Thu, Jul 14, 2016 at 12:01 PM, Yousong Zhou 
 wrote:
> On 14 July 2016 at 16:14, Hans Dedecker  wrote:
>> Commit c6858766 adds teardown support when l3_dev link is lost
>> especially for shell protocols
>> that have no proto task. However shell protocols which have a proto task
>> running like ppp will
>> also be teared down which is not always the expected action.
>> As an example the PPP daemon can be put into persist state trying to
>> re-establish the link via
>> a hold off mechanism which is not possible when the daemon is terminated
>> by the proto shell
>> teardown.
>> Therefore restrict the teardown action for shell protocols having no
>> proto task.
>>
>
> How about adding an extra flag like managed-link, persistent-link,
> on-demand-link?  It looks to me doing teardown at link-down is more
> common a case.
 Initially I was thinking about adding another flag like you propose
 but then I was doubting if the change in behavior for shell protocols
 having a proto task task was on purpose or not. In case of PPP and
 link failure you don't want an immediate restart by netifd in some
 cases (see https://github.com/lede-project/source/pull/200) as PPP
 daemon can take care of the link re-negotiation based on a holdoff
 timeout.
 Additionally if the wan link loses connectivity a link down
 notification will be received on the main device which will teardown
 the protocol. Anyway I'm open for suggestions which way to go forward.
>>> Yousong,
>>>
>>> please provide some more details on where your commit c6858766 is
>>> actually needed/useful. In all the use cases I can think of, handling
>>> setup/teardown based on the l2 dev should be enough.
>>>
>>> - Felix
>>>
>>
>> The issue them was that when l2tp-xxx went down, netifd has no proto
>> task state to be notified of, and main_dev state seemed unchanged.  If
>> I remeber and understand the code correcly other pppd shell protos do
>> teardown because of proto task event, not any device link state, and I
>> thought it's reasonable and  should not hurt to do an explicit
>> teardown on link down.
> It seems to me that we should do less magic here and make the behavior
> opt-in via an explicit flag that needs to be enabled by the proto handler.
>
> - Felix
Felix,

Currently the xl2tp protocol script registers itself as having
no_proto_task which is used in proto_shell_task_finish to send a
teardown when the shell is in setup state an having a proto task.
I re-used the no_proto_task flag to send a teardown in case l3 dev
link loss is detected.
Do I understand it correctly you favour adding an explicit flag (to be
set by the protocol script in this case l2tp) and thus decouple the
teardown from the no_proto_task flag ?

Hans

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

Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH netifd 2/3] interface: Only teardown interfaces having no proto task when l3_dev link lost

[Felix Fietkau]

On 2016-07-14 23:10, Hans Dedecker wrote:
> Felix,
> 
> Currently the xl2tp protocol script registers itself as having
> no_proto_task which is used in proto_shell_task_finish to send a
> teardown when the shell is in setup state an having a proto task.
> I re-used the no_proto_task flag to send a teardown in case l3 dev
> link loss is detected.
> Do I understand it correctly you favour adding an explicit flag (to be
> set by the protocol script in this case l2tp) and thus decouple the
> teardown from the no_proto_task flag ?
Yes, that's exactly what I meant. What's your opinion on that?

- Felix

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

Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH netifd 2/3] interface: Only teardown interfaces having no proto task when l3_dev link lost

[Hans Dedecker]

On Thu, Jul 14, 2016 at 11:20 PM, Felix Fietkau  wrote:
> On 2016-07-14 23:10, Hans Dedecker wrote:
>> Felix,
>>
>> Currently the xl2tp protocol script registers itself as having
>> no_proto_task which is used in proto_shell_task_finish to send a
>> teardown when the shell is in setup state an having a proto task.
>> I re-used the no_proto_task flag to send a teardown in case l3 dev
>> link loss is detected.
>> Do I understand it correctly you favour adding an explicit flag (to be
>> set by the protocol script in this case l2tp) and thus decouple the
>> teardown from the no_proto_task flag ?
> Yes, that's exactly what I meant. What's your opinion on that?
Agree with the idea as currently the no_proto_task flag is overloaded;
additionally it will allow the protocol handlers to register for a
teardown on l3 dev link loss decoupled from the no_proto task flag. I
will cook a patch after my holidays

Hans
>
> - Felix

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