[LEDE-DEV] [LEDE-DEV, netifd] proto-shell: add helpers for generic options in proto handlers

2016-10-25 Thread Marcin Jurkowski 
Adding helpers for virtual interfaces generic options in ncm, qmi, mbim
and directip protocols as suggested by Felix in
https://lists.openwrt.org/pipermail/openwrt-devel/2016-February/039794.html

Signed-off-by: Marcin Jurkowski 
---
 scripts/netifd-proto.sh | 13 +
 1 file changed, 13 insertions(+)

diff --git a/scripts/netifd-proto.sh b/scripts/netifd-proto.sh
index 64b3cab..cc7031a 100644
--- a/scripts/netifd-proto.sh
+++ b/scripts/netifd-proto.sh
@@ -1,4 +1,5 @@
 NETIFD_MAIN_DIR="${NETIFD_MAIN_DIR:-/lib/netifd}"
+PROTO_DEFAULT_OPTIONS="defaultroute peerdns metric"
 
 . /usr/share/libubox/jshn.sh
 . $NETIFD_MAIN_DIR/utils.sh
@@ -15,6 +16,18 @@ proto_config_add_boolean() {
config_add_boolean "$@"
 }
 
+proto_config_add_defaults() {
+   proto_config_add_boolean "defaultroute"
+   proto_config_add_boolean "peerdns"
+   proto_config_add_int "metric"
+}
+
+proto_add_dynamic_defaults() {
+   [ -n "$defaultroute" ] && json_add_boolean defaultroute "$defaultroute"
+   [ -n "$peerdns" ] && json_add_boolean peerdns "$peerdns"
+   [ -n "$metric" ] && json_add_int metric "$metric"
+}
+
 _proto_do_teardown() {
json_load "$data"
eval "proto_$1_teardown \"$interface\" \"$ifname\""
-- 
2.7.3


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

[LEDE-DEV] [PATCH] ath10k-ct: Add QCA9888/9886 support, fix compat issue.

2016-10-25 Thread greearb 
From: Ben Greear 

This should fix problems with latest backports, and also adds
driver support for QCA9888 chipset.

Signed-off-by: Ben Greear 
---
 package/kernel/ath10k-ct/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/kernel/ath10k-ct/Makefile 
b/package/kernel/ath10k-ct/Makefile
index 6ca9db1..3df9496 100644
--- a/package/kernel/ath10k-ct/Makefile
+++ b/package/kernel/ath10k-ct/Makefile
@@ -1,7 +1,7 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=ath10k-ct
-PKG_VERSION:=2016-10-17
+PKG_VERSION:=2016-10-25
 PKG_RELEASE=1
 
 PKG_LICENSE:=GPLv2
@@ -10,7 +10,7 @@ PKG_LICENSE_FILES:=
 PKG_SOURCE_URL:=https://github.com/greearb/ath10k-ct.git
 PKG_SOURCE_PROTO:=git
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
-PKG_SOURCE_VERSION:=f2fb96a03d6a2c0cdcd6482e2653a4468956e1f4
+PKG_SOURCE_VERSION:=5b7a620fdc9de03aaa76145bccb2d83e8cb1b767
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.xz
 
 PKG_MAINTAINER:=Ben Greear 
-- 
2.4.11


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

[LEDE-DEV] Arcadyan vrv9510kwac23

2016-10-25 Thread Juan Rios 
Hello again,
I have been working on adding support for this router with the
help of SCApi and we got it to the point that Ethernet ports works,
leds and buttons works and wifi card 0xa8d6 43222 works.

The wifi card don't have sprom and I had to write a patch to add
fallback sprom support for this card.

The sprom is not located in flash or at least I could not find it. I
used the logs from original firmware and information from broadcom
architecture to make it and put the interesting values and it works.

To supply sprom buffer I need the mac address of the interface. I want
to use the Ethernet mac address + 2. The Ethernet mac address is
stored in mtd at certain offset.

Where should be the registration of the sprom fallback function?.
Right now I did it in the b43_pci_ssb_bridge_init function from the
drivers/ssb/pci_b43_bridge.c file.

Also It is needed a way to specify the mtd partition where the mac
address is stored, the offset and the increment needed to the mac
address. Where and how should this be put?

Right now there is only three lantiq routers with broadcom wifi card
that I know of and may be in the same situation.

Regards
Juan Rios

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

Re: [LEDE-DEV] [RFC v2 3/3] config: ext4: increase x86 rootfs size to 2GB to support online resize2fs

2016-10-25 Thread Alberto Bursi 


On 10/25/2016 01:02 PM, Jo-Philipp Wich wrote:
>
> For x86 targets, increase the default rootfs size to 2048MB which allows
> online resizing the filesystem to up to 2TB which is the current theoretical
> maximum for LEDE, due to missing GPT support on the root block device.
>

FYI: in the packages feed there is "gptfdisk" now (was added like a 
month ago), the name is self-explanatory.

Won't really matter for this usecase.

-Alberto

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

Re: [LEDE-DEV] LEDE Forum - Startup mode

2016-10-25 Thread Vincenzo Romano 
Just my humble opinion.
That piece of software looks great.
Isn't there any other free (as in beer) alternative?
--
Vincenzo Romano - NotOrAnd.IT
Information Technologies
--
NON QVIETIS MARIBVS NAVTA PERITVS


2016-10-25 17:03 GMT+02:00 Ted Hess :
> Hi all -
>
> First off, thanks for all the feedback, suggestions and volunteers. For
> starters, and perhaps to become permanent, we have set up a copy of Discourse
> (http://discourse.org) for testing and evaluation. It is a very popular 
> package
> for new organizations and it has a pretty active community and support.
>
> Discourse puts a high demand on the user's client software capabilities and 
> may
> present some problems to users of screen readers. We would like to ask those
> using screen readers to take a look at our site and give us your opinions with
> respect the accessibility of our forum.
>
> Before we can "go live" for everyone all accounts need to be admin approved.
> This will be a quick and very liberal process. Admins currently are: Rich 
> Brown
> (richb-hanover), Thomas Endt (tmomas), myself, jow & blogic. If we get enough
> interest and no one has good reasons not to proceed, and we have success 
> setting
> up the forum categories and site description (Welcome, ToS, FAQ, etc), we can 
> go
> live and allow open general self-registration. We will not be allowing 
> anonymous
> posting.
>
> For those not wishing to use the forum site directly, once you have registered
> you will be able reply to topics via e-mail. Additionally, we may enable the
> ability to post new topics via e-mail to users with advanced trust levels to
> certain categories.
>
> During this initial startup period, we reserve the right to:
>  * Take the site off-line for maintenance and reconfiguration.
>  * Remove unwanted posts and uploaded content.
>  * Revoke privileges and/or remove unwanted accounts.
>
> So, visit the site, sign-up and post us a note. We will try to respond to all
> requests. Try things out, send me or another admin any requests for site
> configuration changes - or better yet, post a topic for those discussions.
>
> And yes, Github logins are possible once you are registered.
>
> /ted
>
> Site location: https://forum.lede-project.org
> Email: fo...@lede-project.org
>
>
> ___
> lede-adm mailing list
> lede-...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-adm

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

[LEDE-DEV] Fwd: TP-Link Archer C7 boot loop

2016-10-25 Thread Jon 
 Hello all,  am having a similar problem with a boot loop.  After an 
attempted flash of a LEDE build,  my router is in a 5-6 second loop.


Am 20.08.2016 um 23:35 schrieb Jochen Demmer:


> yesterday I bricked an Archer C7 v2 by installing some homebrew 
(buildroot) lede firmware. > It got stuck in a boot loop and it's also 
not reachable on 192.168.1.1 on any time during > boot whatsoever. No 
failsafe mode. Archer C7 v2 can be un-brick with TFTP and U-Boot of 
the router. If you try it with the serial console, you need a program 
which hits 'tpl' for you. > I don't know how to debug this. Could 
someone give me a hint? Is maybe something wrong > within lede for 
Archer C7 ? Did you connect a UART adapter to the router? My Lede 
build for Archer C7 v2 works perfectly. I did never use the 
pre-compiled images and I'm using sysupgrade images only. Regards, Hartmut
 I've progressed thru successful serial terminal configuration, and am 
observing the loop,  as well as the TFTP firmware loads attemps.
I seem to be failing a check of product ID and version.  Then, the 
router attempts to boot the firmware with the same failure that I see in 
the regular boot loop:



#Example of firmware TFTP load,  and subsequent problem leading to reboot

dup 1 speed 1000
Using eth1 device
TFTP from server 192.168.0.66; our IP address is 192.168.0.86
Filename 'ArcherC7v2_tp_recovery.bin'.
Load address: 0x8006
Loading: T 
#

 ###

editing out hashtags

#
#
 ###
done
Bytes transferred = 16252928 (f8 hex)
original_product_id = 
 original_product_ver = 
 recovery_product_id = c702
 recovery_product_ver = 01
 auto update firmware: product id verify fail!
Autobooting in 1 seconds
## Booting image at 9f02 ...
   Uncompressing Kernel Image ... Stream with EOS marker is not 
supportedLZMA ERROR1 - must RESET board to recover


U-Boot 1.1.4 (Oct 14 2015 - 13:34:14)


The last part starting at the "Autobooting in 1 seconds",  is the end of 
the boot loop,  where it complains,  then U-Boot starts again. The 
regular loop is much longer,  culminating in the image boot and the same 
error.


My problem is,  I can't seem to catch it with tpl,   to stop it and get 
to console.   Have seen another method of erasing and writing from the 
console, but either I need to type faster,  or something's wrong with my 
console config.  Are there any other ways to stop a boot and go to console?


Thanks...

Jon

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

[LEDE-DEV] LEDE Forum - Startup mode

2016-10-25 Thread Ted Hess 
Hi all -

First off, thanks for all the feedback, suggestions and volunteers. For
starters, and perhaps to become permanent, we have set up a copy of Discourse
(http://discourse.org) for testing and evaluation. It is a very popular package
for new organizations and it has a pretty active community and support. 

Discourse puts a high demand on the user's client software capabilities and may
present some problems to users of screen readers. We would like to ask those
using screen readers to take a look at our site and give us your opinions with
respect the accessibility of our forum.

Before we can "go live" for everyone all accounts need to be admin approved.
This will be a quick and very liberal process. Admins currently are: Rich Brown
(richb-hanover), Thomas Endt (tmomas), myself, jow & blogic. If we get enough
interest and no one has good reasons not to proceed, and we have success setting
up the forum categories and site description (Welcome, ToS, FAQ, etc), we can go
live and allow open general self-registration. We will not be allowing anonymous
posting.

For those not wishing to use the forum site directly, once you have registered
you will be able reply to topics via e-mail. Additionally, we may enable the
ability to post new topics via e-mail to users with advanced trust levels to
certain categories.

During this initial startup period, we reserve the right to:
 * Take the site off-line for maintenance and reconfiguration.
 * Remove unwanted posts and uploaded content.
 * Revoke privileges and/or remove unwanted accounts.

So, visit the site, sign-up and post us a note. We will try to respond to all
requests. Try things out, send me or another admin any requests for site
configuration changes - or better yet, post a topic for those discussions.

And yes, Github logins are possible once you are registered.

/ted

Site location: https://forum.lede-project.org
Email: fo...@lede-project.org


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

Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH] blobmsg_json: handle conversion of large integers from JSON

2016-10-25 Thread Florian Larysch 
Hi,

> IIUC, your change makes the type of fields vary upon their values.
> I'm wondering how you suggest applications parse the resulting blob messages?

you're right, this doesn't make sense. In my case, the only consumer was
using blobmsg_format_json(), which handles element types dynamically.

This patch would break users of blobmsg_parse() in some cases, please
disregard it.

> This has been somewhat discussed in the past (see
> https://lists.openwrt.org/pipermail/openwrt-devel/2016-June/041700.html).

While I agree with you that all options would cause a ABI break in the
strict sense that the raw blob might change in an incompatible way, this
could be handled in libubox without causing an ABI break there (for
example by capping values like libjson-c does). In that light, options 3
and 4 are largely equivalent.

Options 1 and 2 would be a bit wasteful, IMO. 

Florian

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

[LEDE-DEV] [RFC v2] Adjusting ext4 filesystem defaults

2016-10-25 Thread Jo-Philipp Wich 
This patch series tunes the ext4 default parameters in order to support
online resize and to make resulting filesystem images more flexible.

The changes should also fix the issue reported at
http://lists.infradead.org/pipermail/lede-dev/2016-September/002518.html
at least for x86 systems.


Changes since v1:

 - Drop TARGET_EXT4_MAXINODE config entirely as there is really no
   known good use-case for it
 - Instead of reducing the block size, bump the default rootfs size
   for x86 to 2GB in order to support online resize up to 2TB


Jo-Philipp Wich (3):
  include: image.mk: make ext4 reserved blocks percentage optional
  config: ext4: drop option to set maximum number of inodes
  config: ext4: increase x86 rootfs size to 2GB to support online
resize2fs

 config/Config-images.in | 10 ++
 include/image.mk|  3 +--
 2 files changed, 3 insertions(+), 10 deletions(-)

-- 
2.9.3


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

[LEDE-DEV] [RFC v2 3/3] config: ext4: increase x86 rootfs size to 2GB to support online resize2fs

2016-10-25 Thread Jo-Philipp Wich 
The current default rootfs size of 256MB in conjunction with 4K blocks
produces an ext4 filesystem which lacks the appropriate amount of backup GDT
entries to support online-resizing.

For x86 targets, increase the default rootfs size to 2048MB which allows
online resizing the filesystem to up to 2TB which is the current theoretical
maximum for LEDE, due to missing GPT support on the root block device.

Note that the filesystem artefact will not occupy 2GB on the build system as
the make_ext4fs utility uses sparse files to generate the filesystem images,
so the actual disk usage is much lower. Furthermore the filesystem images
are gzip compressed, shrinking them to only a few megabytes on the download
server.

Signed-off-by: Jo-Philipp Wich 
---
 config/Config-images.in | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/config/Config-images.in b/config/Config-images.in
index 1a6951d..1866bb1 100644
--- a/config/Config-images.in
+++ b/config/Config-images.in
@@ -253,7 +253,8 @@ menu "Target Images"
config TARGET_ROOTFS_PARTSIZE
int "Root filesystem partition size (in MB)"
depends on GRUB_IMAGES || TARGET_ROOTFS_EXT4FS || TARGET_rb532 
|| TARGET_mvebu
-   default 256
+   default 2048 if TARGET_x86
+   default 256 if ! TARGET_x86
help
  Select the root filesystem partition size.
 
-- 
2.9.3


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

[LEDE-DEV] [RFC v2 2/3] config: ext4: drop option to set maximum number of inodes

2016-10-25 Thread Jo-Philipp Wich 
There is very little practical use to limit the number of available inodes on
an ext4 filesystem and the make_ext4fs utility is able to calculate useful
defaults by itself.

Drop the option to make resulting ext4 filesystems more flexible by default.

Signed-off-by: Jo-Philipp Wich 
---
 config/Config-images.in | 7 ---
 include/image.mk| 1 -
 2 files changed, 8 deletions(-)

diff --git a/config/Config-images.in b/config/Config-images.in
index 05b817b..1a6951d 100644
--- a/config/Config-images.in
+++ b/config/Config-images.in
@@ -73,13 +73,6 @@ menu "Target Images"
help
  Build an ext4 root filesystem.
 
-   config TARGET_EXT4_MAXINODE
-   int "Maximum number of inodes in root filesystem"
-   depends on TARGET_ROOTFS_EXT4FS
-   default 6000
-   help
- Select the maximum number of inodes in the root 
filesystem.
-
config TARGET_EXT4_RESERVED_PCT
int "Percentage of reserved blocks in root filesystem"
depends on TARGET_ROOTFS_EXT4FS
diff --git a/include/image.mk b/include/image.mk
index 59dd66f..8b183ab 100644
--- a/include/image.mk
+++ b/include/image.mk
@@ -244,7 +244,6 @@ E2SIZE=$(shell echo 
$$(($(CONFIG_TARGET_ROOTFS_PARTSIZE)*1024*1024)))
 define Image/mkfs/ext4
$(STAGING_DIR_HOST)/bin/make_ext4fs \
-l $(E2SIZE) -b $(CONFIG_TARGET_EXT4_BLOCKSIZE) \
-   -i $(CONFIG_TARGET_EXT4_MAXINODE) \
$(if $(CONFIG_TARGET_EXT4_RESERVED_PCT),-m 
$(CONFIG_TARGET_EXT4_RESERVED_PCT)) \
$(if $(CONFIG_TARGET_EXT4_JOURNAL),,-J) \
$(if $(SOURCE_DATE_EPOCH),-T $(SOURCE_DATE_EPOCH)) \
-- 
2.9.3


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

[LEDE-DEV] [RFCv2 2/3] include: properly update .install stamp files

2016-10-25 Thread Jo-Philipp Wich 
Right now the $(PKG_INSTALL_STAMP) files are only written if a package is
selected as <*> but never deleted or emptied if the corresponding package
is getting deselected.

For ordinary packages this usually is no problem as the package/install
recipe performs its own check for enabled packages when assembling the
list of install stamp files to consider, but this logic might fail under
certain circumstances for packages providing multiple build variants.

In case of a multi-variant package, the buildroot first checks if any
of the variants is enabled, then resolves all variants of the common
source package and finally processes the corresponding .install stamp
files of all variants, relying on the assumption that only the selected
.install stamp file exists.

When an initially selected variant is getting deselected or changed from
<*> to  and another variant is marked as <*> instead, the .install
stamp file of the deselected variant remains unchanged and a second
.install stamp file for the newly selected variant is getting created,
causing the package/install recipe to pick up two .install stamps with
conflicting variants, leading to opkg file clashes.

This issue happens for example if package "ip" is set to  and package
"ip-full" to <*> -  the install command will eventually fail with:

 * check_conflicts_for: The following packages conflict with ip:
 * check_conflicts_for: ip-full *
 * opkg_install_cmd: Cannot install package ip.

In order to fix the problem, always update the .install stamp files,
even for deselected packages but only write the package base name into
stamp files whose corresponding package is marked as builtin.

Signed-off-by: Jo-Philipp Wich 
---
 include/package-ipkg.mk | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/include/package-ipkg.mk b/include/package-ipkg.mk
index 2591f5e..5b080f5 100644
--- a/include/package-ipkg.mk
+++ b/include/package-ipkg.mk
@@ -103,21 +103,23 @@ ifeq ($(DUMP),)
 ifneq ($(ABI_VERSION),)
 compile: $(PKG_INFO_DIR)/$(1).version
 endif
-
-ifeq ($(CONFIG_PACKAGE_$(1)),y)
-  .PHONY: $(PKG_INSTALL_STAMP).$(1)
-  compile: $(PKG_INSTALL_STAMP).$(1)
-  $(PKG_INSTALL_STAMP).$(1):
-   if [ -f $(PKG_INSTALL_STAMP).clean ]; then \
-   rm -f \
-   $(PKG_INSTALL_STAMP) \
-   $(PKG_INSTALL_STAMP).clean; \
-   fi; \
-   echo "$(1)" >> $(PKG_INSTALL_STAMP)
-endif
   else
 $(if $(CONFIG_PACKAGE_$(1)),$$(info WARNING: skipping $(1) -- package 
not selected))
   endif
+
+  .PHONY: $(PKG_INSTALL_STAMP).$(1)
+  compile: $(PKG_INSTALL_STAMP).$(1)
+  $(PKG_INSTALL_STAMP).$(1):
+   if [ -f $(PKG_INSTALL_STAMP).clean ]; then \
+   rm -f \
+   $(PKG_INSTALL_STAMP) \
+   $(PKG_INSTALL_STAMP).clean; \
+   fi
+  ifeq ($(CONFIG_PACKAGE_$(1)),y)
+   echo "$(1)" >> $(PKG_INSTALL_STAMP)
+  else
+   echo "" >> $(PKG_INSTALL_STAMP)
+  endif
 endif
 endif
 
-- 
2.9.3


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

[LEDE-DEV] [RFCv2 3/3] iproute2: rename ip to ip-tiny and let both ip-tiny and ip-full provide "ip"

2016-10-25 Thread Jo-Philipp Wich 
Rename the "ip" package declaration to "ip-tiny" and let both "ip-tiny" and
"ip-full" provide the virtual "ip" package. This allows users to freely choose
the "ip" command variant while other packages can continue to depend on "ip"
without needing to enforce a specific variant.

Note that this commit does not add busybox as "ip" provider due to
the following reasons:

 - The builtin Busybox ip applet cannot be added or removed at runtime
 - Both "ip-tiny" and "ip-full" are able to install without file clashes even
   if the busybox applet is enabled
 - The system is preferring full "ip-tiny" and "ip-full" at runtime, even
   if Busybox ip is still present.

Signed-off-by: Jo-Philipp Wich 
---
 package/network/utils/iproute2/Makefile | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/package/network/utils/iproute2/Makefile 
b/package/network/utils/iproute2/Makefile
index 9575ff1..ab38d0e 100644
--- a/package/network/utils/iproute2/Makefile
+++ b/package/network/utils/iproute2/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=iproute2
 PKG_VERSION:=4.4.0
-PKG_RELEASE:=4
+PKG_RELEASE:=5
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 PKG_SOURCE_URL:=@KERNEL/linux/utils/net/iproute2
@@ -30,14 +30,15 @@ define Package/iproute2/Default
   MAINTAINER:=Russell Senior 
   DEPENDS:= +libnl-tiny
   VARIANT:=$(1)
+  PROVIDES:=$(3)
 endef
 
-define Package/ip
-$(call Package/iproute2/Default,tiny,Minimal)
+define Package/ip-tiny
+$(call Package/iproute2/Default,tiny,Minimal,ip)
   CONFLICTS:=ip-full
 endef
 
-Package/ip-full=$(call Package/iproute2/Default,full,Full)
+Package/ip-full:=$(call Package/iproute2/Default,full,Full,ip)
 
 define Package/tc
 $(call Package/iproute2/Default)
@@ -101,7 +102,7 @@ define Build/InstallDev
$(CP) $(PKG_BUILD_DIR)/lib/libnetlink.a $(1)/usr/lib/
 endef
 
-define Package/ip/install
+define Package/ip-tiny/install
$(INSTALL_DIR) $(1)/usr/bin
$(INSTALL_BIN) $(PKG_BUILD_DIR)/ip/ip $(1)/usr/bin/
 endef
@@ -138,7 +139,7 @@ define Package/nstat/install
$(INSTALL_BIN) $(PKG_BUILD_DIR)/misc/nstat $(1)/usr/sbin/
 endef
 
-$(eval $(call BuildPackage,ip))
+$(eval $(call BuildPackage,ip-tiny))
 $(eval $(call BuildPackage,ip-full))
 $(eval $(call BuildPackage,tc))
 $(eval $(call BuildPackage,genl))
-- 
2.9.3


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

[LEDE-DEV] [RFCv2 0/3] Fix and improve PROVIDES handling

2016-10-25 Thread Jo-Philipp Wich 
Various packages in the feeds and within the base repository provide multiple
build variants with slightly varying feature sets and in some cases packages
rely on functionality that can be supported by entirely different packages,
like using either openssl-util or px5g to generate an RSA certificate.

The current situation is that packages that rely on features provided by multi-
build-variant packages are forcibly depending on specific candidates which
makes it impossible for users to install other variants due to file clashes
reported by opkg.

One exemplary common use case is OpenVPN which can be configured to support
and use iproute2, in which case it will forcibly depend on "ip" which is the
stripped down variant of iproute2. Due to this hard dependency it is impossible
for users to choose "ip-full" because "opkg install" will fail with file
clashes since commit 021b96d7c5c668fbcb5375c65cee90832bb2854f.

This patch series attempts to fix the already existing but slightly defunct
PROVIDES support in the buildroot in order to be able to properly satisfy
depends with any build variant in the future.

Topics that require further testing and refinement are:

 1) Investigate handling of DEFAULT_VARIANT wrt. <*> vs.  selections,
similar to the fixes in patch 2 and 3

 2) Ensure that DEFAULT_VARIANT is properly respected by mconf_depends()
of scripts/package-metadata.pl - right now the (alphabetically?) first
build variant is considered to be the preferred candidate

 3) Test proper OPKG runtime behaviour when installing packages depending
on virtual PROVIDES, e.g. "opkg install ip-full; opkg remove ip" should
not remove the iproute2-enabled OpenVPN

This series only touches iproute2 for now to demonstrate the viability of the
approach so any testing should be done with a fresh .config and only those two
packages.

Once PROVIDES support is properly fixed, other multi-variant package users
should be converted to provides as well.


Changes since v1:

 - Instead of splitting -m and -y variant lists, fix the root cause of
   improperly updated install stamp files

 - Instead of letting "ip" and "ip-full" provide "ip-command", rename "ip" to
   "ip-tiny" and let both build variants provide "ip" instead, this way no "ip"
   users need to be changed


Jo-Philipp Wich (3):
  scripts/package-metadata.pl: fix handling of virtual (PROVIDES)
depends
  include: properly update .install stamp files
  iproute2: rename ip to ip-tiny and let both ip-tiny and ip-full
provide "ip"

 include/package-ipkg.mk | 26 ++
 package/network/utils/iproute2/Makefile | 13 +++--
 scripts/package-metadata.pl |  4 ++--
 3 files changed, 23 insertions(+), 20 deletions(-)

-- 
2.9.3


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

[LEDE-DEV] [PATCH netifd 1/2] bridge: Don't use device name as bridge member name

2016-10-25 Thread Hans Dedecker 
The bridge name is a copy of the device name; but the device name can
change which is the case when an aliased interface is used as bridge member.
This will result into unwanted side effects like bridge reload triggering
a topology change effect after doing network reload; therefore use the
configured ifname as fixed bridge member name.
Also don't display bridge member devices which are hidden

Signed-off-by: Hans Dedecker 
---
 bridge.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/bridge.c b/bridge.c
index 8e6c9a6..30fd58d 100644
--- a/bridge.c
+++ b/bridge.c
@@ -394,24 +394,25 @@ bridge_set_state(struct device *dev, bool up)
 }
 
 static struct bridge_member *
-bridge_create_member(struct bridge_state *bst, struct device *dev, bool 
hotplug)
+bridge_create_member(struct bridge_state *bst, const char *name,
+struct device *dev, bool hotplug)
 {
struct bridge_member *bm;
 
-   bm = calloc(1, sizeof(*bm) + strlen(dev->ifname) + 1);
+   bm = calloc(1, sizeof(*bm) + strlen(name) + 1);
if (!bm)
return NULL;
 
bm->bst = bst;
bm->dev.cb = bridge_member_cb;
bm->dev.hotplug = hotplug;
-   strcpy(bm->name, dev->ifname);
+   strcpy(bm->name, name);
bm->dev.dev = dev;
vlist_add(>members, >node, bm->name);
// Need to look up the bridge member again as the above
// created pointer will be freed in case the bridge member
// already existed
-   bm = vlist_find(>members, dev->ifname, bm, node);
+   bm = vlist_find(>members, name, bm, node);
if (hotplug && bm)
bm->node.version = -1;
 
@@ -455,7 +456,7 @@ bridge_add_member(struct bridge_state *bst, const char 
*name)
if (!dev)
return;
 
-   bridge_create_member(bst, dev, false);
+   bridge_create_member(bst, name, dev, false);
 }
 
 static int
@@ -463,7 +464,7 @@ bridge_hotplug_add(struct device *dev, struct device 
*member)
 {
struct bridge_state *bst = container_of(dev, struct bridge_state, dev);
 
-   bridge_create_member(bst, member, true);
+   bridge_create_member(bst, member->ifname, member, true);
 
return 0;
 }
@@ -523,8 +524,12 @@ bridge_dump_info(struct device *dev, struct blob_buf *b)
system_if_dump_info(dev, b);
list = blobmsg_open_array(b, "bridge-members");
 
-   vlist_for_each_element(>members, bm, node)
+   vlist_for_each_element(>members, bm, node) {
+   if (bm->dev.dev->hidden)
+   continue;
+
blobmsg_add_string(b, NULL, bm->dev.dev->ifname);
+   }
 
blobmsg_close_array(b, list);
 }
-- 
1.9.1


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

Re: [LEDE-DEV] [RFC] brcm47xx: bump kernel to 4.4

2016-10-25 Thread p . wassi 
> Anyway I finally debugged this local vs. buildbot difference to the
> CONFIG_KERNEL_KALLSYMS. Images from buildbot have this symbol enabled
> which slightly increases kernel size. Enough to stop it from booting
> on WRT300N v1.

There must be something more...
What I had on WRT54GL:
http://lists.infradead.org/pipermail/lede-dev/2016-June/001162.html

Buildbot's images did _not_ boot (assuming they have KALLSYMS as you stated 
above).
However, my local images did boot fine (with KALLSYMS enabled).
So although I had KALLSYMS increasing the kernel size, a local image
booted, while buildbots image did not (both using the same config as jow already
showed me here: 
http://lists.infradead.org/pipermail/lede-dev/2016-June/001153.html )

Anyway, I'm just compiling a new set of images and will report back.

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

Re: [LEDE-DEV] [RFC] brcm47xx: bump kernel to 4.4

2016-10-25 Thread Rafał Miłecki 
On 25 October 2016 at 10:00, Jo-Philipp Wich  wrote:
> did you ever test local builds with all additional kmods (including all
> kmods from feeds) enabled as  ? I guess this will bump the kernel
> size somewhat due to additional subsystems which are getting enabled.

No, I never expected extra kmod packages to affect kernel size.

Anyway I finally debugged this local vs. buildbot difference to the
CONFIG_KERNEL_KALLSYMS. Images from buildbot have this symbol enabled
which slightly increases kernel size. Enough to stop it from booting
on WRT300N v1.

The reason it took me so much time to realize it's related to
CONFIG_KERNEL_KALLSYMS is bug in LEDE building system I just spotted:
[LEDE-DEV] make -j 4: race between Image/Prepare and device images?
http://lists.infradead.org/pipermail/lede-dev/2016-October/003632.html

-- 
Rafał

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

Re: [LEDE-DEV] [RFC] brcm47xx: bump kernel to 4.4

2016-10-25 Thread Rafał Miłecki 
On 25 October 2016 at 09:55, Hannu Nyman  wrote:
> On 25.10.2016 9:13, p.wa...@gmx.at wrote:
>>>
>>> It seems I'm experiencing the same crazy problem. Local builds work
>>> for me (as explained in commit message), but image from buildbot
>>> doesn't boot. This is some totally crazy thing :|
>>
>> I opt for staying at 4.4 and not reverting, since the issue already
>> occured
>> on kernel 4.1 for the WRT54GL (and probably other devices as well?).
>> So it's _not_ a 4.1 -> 4.4 issue! The last kernel, that booted fine
>> on my devices (with buildbot images) was OpenWRT 15.05.1 - 3.18.23
>> As you've experienced yourself: local images also work fine. With 4.1 and
>> 4.4.
>
>
> This freezing after "> Starting program at 0x80001000" reminds me of an old
> issue on ar71xx/WNDR3700:
>
> This might be something related to uncompressing the image by the
> bootloader. Kernel & firmware size growth may be exposing some
> compression/uncompression problem that gets semi-arbitrarily triggered now
> (when the images sizes have grown due to kernel size growth?). It is
> possible that the old bootloader fails to decompress the image but has no
> proper verbose error message about that.

For Linksys WRT300N v1 we use lzma-loader compressed using gzip. It
didn't change between 4.1 and 4.4.

So CFE decompression doesn't matter as it deals with the same loader.
If there is some decompression bug it may be inside lzma-loader.

-- 
Rafał

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

Re: [LEDE-DEV] [RFC] brcm47xx: bump kernel to 4.4

2016-10-25 Thread Rafał Miłecki 
On 25 October 2016 at 08:13,   wrote:
>> It seems I'm experiencing the same crazy problem. Local builds work
>> for me (as explained in commit message), but image from buildbot
>> doesn't boot. This is some totally crazy thing :|
>
> I opt for staying at 4.4 and not reverting, since the issue already occured
> on kernel 4.1 for the WRT54GL (and probably other devices as well?).
> So it's _not_ a 4.1 -> 4.4 issue! The last kernel, that booted fine
> on my devices (with buildbot images) was OpenWRT 15.05.1 - 3.18.23
> As you've experienced yourself: local images also work fine. With 4.1 and 4.4.

I agree, it doesn't make much sense to revert.

Can you test if (uns)setting CONFIG_KERNEL_KALLSYMS makes a difference
for your local builds? Please remember to compile without -j N as it
isn't reliable, see:
[LEDE-DEV] make -j 4: race between Image/Prepare and device images?
http://lists.infradead.org/pipermail/lede-dev/2016-October/003632.html

-- 
Rafał

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

[LEDE-DEV] make -j 4: race between Image/Prepare and device images?

2016-10-25 Thread Rafał Miłecki 

Hi,

I just discovered why I was getting some crazy results during my various kernel
tests. It seems that LEDE doesn't rebuild images as expected with make -j N.

I think that some/all images may be generated before Image/Prepare step.


// I did initial build with CONFIG_KERNEL_KALLSYMS=y
$ ls -l build_dir/target-*/linux-*/vmlinux.lzma
-rw-r--r-- 1 zajec users 1229437 Oct 25 10:10 
build_dir/target-mipsel_mips32_musl-1.1.15/linux-brcm47xx_legacy/vmlinux.lzma
$ ls -l bin/targets/brcm47xx/legacy/*standard*trx 
bin/targets/brcm47xx/legacy/*wrt300n*trx
-rw-r--r-- 1 zajec users 3608576 Oct 25 10:11 
bin/targets/brcm47xx/legacy/lede-brcm47xx-legacy-linksys-wrt300n-v1-squashfs.trx
-rw-r--r-- 1 zajec users 4132864 Oct 25 10:11 
bin/targets/brcm47xx/legacy/lede-brcm47xx-legacy-standard-noloader-gz-squashfs.trx
-rw-r--r-- 1 zajec users 3608576 Oct 25 10:11 
bin/targets/brcm47xx/legacy/lede-brcm47xx-legacy-standard-squashfs.trx


// I disabled CONFIG_KERNEL_KALLSYMS and decided to rebuild
$ make -j 4
 make[1] world
 make[2] package/cleanup
 make[2] target/compile
 make[3] -C target/linux compile
 make[2] package/compile
 make[3] -C package/kernel/gpio-button-hotplug compile
 make[3] -C package/libs/toolchain compile
 make[3] -C package/system/usign host-compile
 make[3] -C package/libs/libjson-c compile
 make[3] -C package/libs/libnl-tiny compile
 make[3] -C package/utils/lua compile
 make[3] -C package/libs/lzo compile
 make[3] -C package/libs/zlib compile
 make[3] -C package/utils/util-linux compile
 make[3] -C package/system/lede-keyring compile
 make[3] -C package/firmware/b43legacy-firmware compile
 make[3] -C package/firmware/linux-firmware compile
 make[3] -C package/firmware/prism54-firmware compile
 make[3] -C package/network/utils/iw compile
 make[3] -C package/libs/mbedtls compile
 make[3] -C package/libs/polarssl compile
 make[3] -C package/network/ipv6/odhcp6c compile
 make[3] -C package/network/services/dnsmasq compile
 make[3] -C package/network/services/dropbear compile
 make[3] -C package/libs/libpcap compile
 make[3] -C package/network/utils/linux-atm compile
 make[3] -C package/network/utils/resolveip compile
 make[3] -C package/utils/busybox compile
 make[3] -C package/utils/nvram compile
 make[3] -C package/utils/otrx compile
 make[3] -C package/libs/libubox compile
 make[3] -C package/utils/mtd-utils compile
 make[3] -C package/kernel/linux compile
 make[3] -C package/system/ubus compile
 make[3] -C package/system/uci compile
 make[3] -C package/utils/jsonfilter compile
 make[3] -C package/system/usign compile
 make[3] -C package/libs/ustream-ssl compile
 make[3] -C package/network/config/swconfig compile
 make[3] -C package/network/services/odhcpd compile
 make[3] -C package/network/utils/iwinfo compile
 make[3] -C package/system/mtd compile
 make[3] -C package/network/config/netifd compile
 make[3] -C package/system/ubox compile
 make[3] -C package/network/services/hostapd compile
 make[3] -C package/libs/uclient compile
 make[3] -C package/system/fstools compile
 make[3] -C package/system/procd compile
 make[3] -C package/system/opkg compile
 make[3] -C package/base-files compile
 make[3] -C package/kernel/mac80211 compile
 make[3] -C package/network/utils/iptables compile
 make[3] -C package/network/services/ppp compile
 make[3] -C package/network/config/firewall compile
 make[2] package/install
 make[3] -C package/system/opkg host-install
 make[3] package/preconfig
 make[2] target/install
 make[3] -C target/linux install
 make[6] -C target/linux/brcm47xx/image/lzma-loader clean install
 make[2] package/index
 make[2] checksum


// vmlinux.lzma is now smaller as expected, but TRX images remained big!
$ ls -l build_dir/target-*/linux-*/vmlinux.lzma
-rw-r--r-- 1 zajec users 1140021 Oct 25 10:17 
build_dir/target-mipsel_mips32_musl-1.1.15/linux-brcm47xx_legacy/vmlinux.lzma
$ ls -l bin/targets/brcm47xx/legacy/*standard*trx 
bin/targets/brcm47xx/legacy/*wrt300n*trx
-rw-r--r-- 1 zajec users 3608576 Oct 25 10:17 
bin/targets/brcm47xx/legacy/lede-brcm47xx-legacy-linksys-wrt300n-v1-squashfs.trx
-rw-r--r-- 1 zajec users 4132864 Oct 25 10:17 
bin/targets/brcm47xx/legacy/lede-brcm47xx-legacy-standard-noloader-gz-squashfs.trx
-rw-r--r-- 1 zajec users 3608576 Oct 25 10:17 
bin/targets/brcm47xx/legacy/lede-brcm47xx-legacy-standard-squashfs.trx


// Another try
$ make -j 4
 make[1] world
 make[2] package/cleanup
 make[2] target/compile
 make[3] -C target/linux compile
 make[2] package/compile
 make[3] -C package/system/usign host-compile
 make[3] -C package/kernel/gpio-button-hotplug compile
 make[3] -C package/libs/toolchain compile
 make[3] -C package/utils/lua compile
 make[3] -C package/libs/lzo compile
 make[3] -C package/libs/libnl-tiny compile
 make[3] -C package/libs/libjson-c compile
 make[3] -C package/libs/zlib compile
 make[3] -C package/utils/util-linux compile
 make[3] -C package/system/lede-keyring compile
 make[3] -C package/firmware/b43legacy-firmware compile
 make[3] -C

Re: [LEDE-DEV] [RFC] brcm47xx: bump kernel to 4.4

2016-10-25 Thread Jo-Philipp Wich 
Hi Rafal,

did you ever test local builds with all additional kmods (including all
kmods from feeds) enabled as  ? I guess this will bump the kernel
size somewhat due to additional subsystems which are getting enabled.

~ Jo

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

[LEDE-DEV] [PATCH] package/boot/uboot-kirkwood: fix default bootcmd for Seagate Dockstar

2016-10-25 Thread p . wassi 
From: Paul Wassi 

Fix the default value for the 'bootcmd' environment variable.
Therefore make the default bootcmd work for buildbot's images.

Signed-off-by: Paul Wassi 
---
The images generated for Dockstar (and probably other devices as well)
have an _uncompressed_ uImage. The bootcmd is 'bootz' at the moment (for 
zImage),
the device will fail to boot. Subsitute 'bootz' with 'bootm' and it will load 
fine.
This patch is meant to be applied to my previous patch for 2016.09.01 !

 boot/uboot-kirkwood/patches/110-dockstar.patch |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff -rupN a/package/boot/uboot-kirkwood/patches/110-dockstar.patch 
b/package/boot/uboot-kirkwood/patches/110-dockstar.patch
--- a/package/boot/uboot-kirkwood/patches/110-dockstar.patch
+++ b/package/boot/uboot-kirkwood/patches/110-dockstar.patch
@@ -28,7 +28,7 @@
 -  "bootm 0x80 0x110"
 +  "ubi part ubi; " \
 +  "ubi read 0x80 kernel; " \
-+  "bootz 0x80"
++  "bootm 0x80"
  
 -#define CONFIG_MTDPARTS   
"mtdparts=orion_nand:1m(uboot),-(root)\0"
 +#define CONFIG_MTDPARTS \

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

Re: [LEDE-DEV] [RFC] brcm47xx: bump kernel to 4.4

2016-10-25 Thread Hannu Nyman 

On 25.10.2016 9:13, p.wa...@gmx.at wrote:

It seems I'm experiencing the same crazy problem. Local builds work
for me (as explained in commit message), but image from buildbot
doesn't boot. This is some totally crazy thing :|

I opt for staying at 4.4 and not reverting, since the issue already occured
on kernel 4.1 for the WRT54GL (and probably other devices as well?).
So it's _not_ a 4.1 -> 4.4 issue! The last kernel, that booted fine
on my devices (with buildbot images) was OpenWRT 15.05.1 - 3.18.23
As you've experienced yourself: local images also work fine. With 4.1 and 4.4.


This freezing after "> Starting program at 0x80001000" reminds me of an old 
issue on ar71xx/WNDR3700:


This might be something related to uncompressing the image by the bootloader. 
Kernel & firmware size growth may be exposing some compression/uncompression 
problem that gets semi-arbitrarily triggered now (when the images sizes have 
grown due to kernel size growth?). It is possible that the old bootloader 
fails to decompress the image but has no proper verbose error message about that.


There was something rather similar four years ago with ar71xx-based 
WNDR3700/WNDR3800 series. There the problem was fixed by decreasing the 
compression dictionary size used for WNDR3700/3800 devices. I debugged that 
after receiving a hint from Rafal (who had had a bit similar problems with 
WNDR4500). Rafal's last message of a long thread:

https://lists.openwrt.org/pipermail/openwrt-devel/2012-June/015846.html

For reference, the ar71xx WNDR3700 debugging:
https://forum.openwrt.org/viewtopic.php?id=40565
https://lists.openwrt.org/pipermail/openwrt-devel/2012-November/thread.html#17445
https://dev.openwrt.org/ticket/12454#comment:12


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

[LEDE-DEV] [PATCH] package/boot/uboot-kirkwood: bump to upstream 2016.09.01

2016-10-25 Thread p . wassi 
From: Paul Wassi 

Bump U-Boot for Kirkwood to upstream 2016.09.01. Local patches
cleaned up and reworked. Rename OpenWrt/LEDE occurrences.

Signed-off-by: Paul Wassi 
---
This patch bumps uboot-kirkwood to 2016.09.01, some of the local patches
can be dropped then (since already integrated upstream). Other patches
are reworked, a few occurrences of OpenWrt have been renamed to LEDE.
Patch for gcc5 quirks not needed anymore - it compiled fine on gcc 5.4.
Bootloader tested on Seagate Dockstar:
https://pwassi.privatedns.org/lede/dockstar/#log_uboot

 boot/uboot-kirkwood/Makefile   
 |   12 -
 
boot/uboot-kirkwood/patches/0001-cosmetic-kirkwood-style-fixes-in-kwbimage.cfg-files.patch
  |   96 
 
boot/uboot-kirkwood/patches/0001-kirkwood-ib62x0-add-CONFIG_SYS_GENERIC_BOARD-define.patch
  |   27 ++
 
boot/uboot-kirkwood/patches/0002-kirkwood-define-empty-CONFIG_MVGBE_PORTS-by-default.patch
  |   32 --
 
boot/uboot-kirkwood/patches/0002-kirkwood-dockstar-add-CONFIG_SYS_GENERIC_BOARD-defin.patch
 |   23 +
 
boot/uboot-kirkwood/patches/0003-ARM-kirkwood-fix-cpu-info-for-6282-device-id.patch
 |   45 ---
 
boot/uboot-kirkwood/patches/0003-kirkwood-goflexhome-add-CONFIG_SYS_GENERIC_BOARD-def.patch
 |   23 +
 
boot/uboot-kirkwood/patches/0004-kirkwood-ib62x0-add-CONFIG_SYS_GENERIC_BOARD-define.patch
  |   27 --
 
boot/uboot-kirkwood/patches/0004-kirkwood-iconnect-add-CONFIG_SYS_GENERIC_BOARD-defin.patch
 |   23 +
 
boot/uboot-kirkwood/patches/0005-kirkwood-dockstar-add-CONFIG_SYS_GENERIC_BOARD-defin.patch
 |   23 -
 
boot/uboot-kirkwood/patches/0005-kirkwood-pogo_e02-add-CONFIG_SYS_GENERIC_BOARD-defin.patch
 |   23 +
 
boot/uboot-kirkwood/patches/0006-kirkwood-goflexhome-add-CONFIG_SYS_GENERIC_BOARD-def.patch
 |   23 -
 
boot/uboot-kirkwood/patches/0006-kirkwood-sheevaplug-add-CONFIG_SYS_GENERIC_BOARD-def.patch
 |   23 +
 
boot/uboot-kirkwood/patches/0007-kirkwood-iconnect-add-CONFIG_SYS_GENERIC_BOARD-defin.patch
 |   23 -
 
boot/uboot-kirkwood/patches/0008-kirkwood-pogo_e02-add-CONFIG_SYS_GENERIC_BOARD-defin.patch
 |   23 -
 
boot/uboot-kirkwood/patches/0009-kirkwood-sheevaplug-add-CONFIG_SYS_GENERIC_BOARD-def.patch
 |   23 -
 boot/uboot-kirkwood/patches/110-dockstar.patch 
 |   95 +--
 boot/uboot-kirkwood/patches/120-iconnect.patch 
 |   12 -
 boot/uboot-kirkwood/patches/130-ib62x0.patch   
 |4 
 boot/uboot-kirkwood/patches/140-pogoplug_e02.patch 
 |2 
 boot/uboot-kirkwood/patches/150-goflexhome.patch   
 |   12 -
 boot/uboot-kirkwood/patches/200-lede-config.patch  
 |  107 
 boot/uboot-kirkwood/patches/200-openwrt-config.patch   
 |  119 --
 boot/uboot-kirkwood/patches/400-gcc-5-compiler.patch   
 |   87 ---
 24 files changed, 287 insertions(+), 620 deletions(-)
system/mtd/src/mtd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff -rupN a/package/boot/uboot-kirkwood/Makefile 
b/package/boot/uboot-kirkwood/Makefile
--- a/package/boot/uboot-kirkwood/Makefile
+++ b/package/boot/uboot-kirkwood/Makefile
@@ -8,7 +8,7 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=u-boot
-PKG_VERSION:=2014.10
+PKG_VERSION:=2016.09.01
 PKG_RELEASE:=1
 
 
PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)-$(BUILD_VARIANT)/$(PKG_NAME)-$(PKG_VERSION)
@@ -16,7 +16,7 @@ PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).t
 PKG_SOURCE_URL:=\
http://mirror2.openwrt.org/sources \
ftp://ftp.denx.de/pub/u-boot
-PKG_MD5SUM:=3ddcaee2f05b7c464778112ec83664b5
+PKG_MD5SUM:=61c628f8034477c946e173ed174efeb4
 PKG_TARGETS:=bin
 
 PKG_LICENSE:=GPL-2.0 GPL-2.0+
@@ -112,18 +112,18 @@ define Build/Compile
CROSS_COMPILE=$(TARGET_CROSS)
mkimage -A $(ARCH) -O linux -T kernel -C none \
-a 0x60 -e 0x60 \
-   -n 'OpenWrt Das U-Boot uImage' \
+   -n 'LEDE Das U-Boot uImage' \
-d $(PKG_BUILD_DIR)/u-boot.bin $(PKG_BUILD_DIR)/u-boot.img
 endef
 
 define Package/uboot/install/default
$(INSTALL_DIR) $(BIN_DIR)/uboot-$(BOARD)-$(1)
$(CP) $(PKG_BUILD_DIR)/u-boot.bin \
-   $(BIN_DIR)/uboot-$(BOARD)-$(1)/openwrt-$(BOARD)-$(1)-u-boot.bin
+   $(BIN_DIR)/uboot-$(BOARD)-$(1)/lede-$(BOARD)-$(1)-u-boot.bin
$(CP) $(PKG_BUILD_DIR)/u-boot.kwb \
-   $(BIN_DIR)/uboot-$(BOARD)-$(1)/openwrt-$(BOARD)-$(1)-u-boot.kwb
+   $(BIN_DIR)/uboot-$(BOARD)-$(1)/lede-$(BOARD)-$(1)-u-boot.kwb
$(CP) $(PKG_BUILD_DIR)/u-boot.img \
-   $(BIN_DIR)/uboot-$(BOARD)-$(1)/openwrt-$(BOARD)-$(1)-u-boot.img
+   $(BIN_DIR)/uboot-$(BOARD)-$(1)/lede-$(BOARD)-$(1)-u-boot.img

Re: [LEDE-DEV] Actual community change and additional developers compared to OpenWrt

2016-10-25 Thread David Lang 

On Mon, 24 Oct 2016, Jo-Philipp Wich wrote:


I would be interested in a more contributor oriented insight at this
point. For example it took me a while to realize that being on Github
suddenly means that people edit C code via the web interface without any
means to syntax / compile / run test their changes or to sign off their
commits.


One thing that has helped us over in the rsyslog project was that we spent a 
signficant chunk of time setting up Travis (tied into github) and have that 
doing compile/testsuite runs for PRs that are submitted.


It took quite a while to get done (very little other work for a couple release 
cycles, about 3 months) but the results have been well worth it.


It would be even harder to setup for LEDE as it is bigger and has more different 
compile options to test, but I think this would be a very worthwhile thing to 
do. It's also something that could be setup by someone outside of the core group 
(working with their own fork of the project until they get things functioning)


David Lang

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

Re: [LEDE-DEV] [PATCH v4 2/5] linux/mtd: add id for mx25u3235f needed by ZyXEL NBG6817

2016-10-25 Thread André Valentin 
Hi,

Am 25.10.2016 um 08:58 schrieb Arjen de Korte:> Citeren André Valentin 
:
>
>> Signed-off-by: André Valentin 
>> ---
>>  .../patches-4.4/477-mtd-add-spi-nor-add-mx25u3235f.patch   | 10 
>> ++
>>  1 file changed, 10 insertions(+)
>>  create mode 100644 
>> target/linux/generic/patches-4.4/477-mtd-add-spi-nor-add-mx25u3235f.patch
>>
>> diff --git 
>> a/target/linux/generic/patches-4.4/477-mtd-add-spi-nor-add-mx25u3235f.patch 
>> b/target/linux/generic/patches-4.4/477-mtd-add-spi-nor-add-mx25u3235f.patch
>> new file mode 100644
>> index 000..45533e1
>> --- /dev/null
>> +++ 
>> b/target/linux/generic/patches-4.4/477-mtd-add-spi-nor-add-mx25u3235f.patch
>> @@ -0,0 +1,10 @@
>> +--- a/drivers/mtd/spi-nor/spi-nor.c2016-10-09 00:34:19.206155838 +0200
>>  b/drivers/mtd/spi-nor/spi-nor.c2016-10-09 00:37:11.048495602 +0200
>> +@@ -721,6 +721,7 @@ static const struct flash_info spi_nor_i
>> + { "mx25l3205d",  INFO(0xc22016, 0, 64 * 1024,  64, SECT_4K) },
>> + { "mx25l3255e",  INFO(0xc29e16, 0, 64 * 1024,  64, SECT_4K) },
>> + { "mx25l6405d",  INFO(0xc22017, 0, 64 * 1024, 128, SECT_4K) },
>> ++{ "mx25u3235f", INFO(0xc22536, 0, 64 * 1024, 64, 0) },
>
> Are you sure the above is correct? According to the datasheet, this device 
> does support both 4K and 64K erase size.

I'm not 100% sure. I got the specs from another patch used in zyxel sources.
Should I change it to SECT_4K?

Kind regards,

André



smime.p7s
Description: S/MIME Cryptographic Signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v4 2/5] linux/mtd: add id for mx25u3235f needed by ZyXEL NBG6817

2016-10-25 Thread Arjen de Korte 

Citeren André Valentin :


Signed-off-by: André Valentin 
---
 .../patches-4.4/477-mtd-add-spi-nor-add-mx25u3235f.patch   | 10  
++

 1 file changed, 10 insertions(+)
 create mode 100644  
target/linux/generic/patches-4.4/477-mtd-add-spi-nor-add-mx25u3235f.patch


diff --git  
a/target/linux/generic/patches-4.4/477-mtd-add-spi-nor-add-mx25u3235f.patch  
b/target/linux/generic/patches-4.4/477-mtd-add-spi-nor-add-mx25u3235f.patch

new file mode 100644
index 000..45533e1
--- /dev/null
+++  
b/target/linux/generic/patches-4.4/477-mtd-add-spi-nor-add-mx25u3235f.patch

@@ -0,0 +1,10 @@
+--- a/drivers/mtd/spi-nor/spi-nor.c2016-10-09 00:34:19.206155838 +0200
 b/drivers/mtd/spi-nor/spi-nor.c2016-10-09 00:37:11.048495602 +0200
+@@ -721,6 +721,7 @@ static const struct flash_info spi_nor_i
+   { "mx25l3205d",  INFO(0xc22016, 0, 64 * 1024,  64, SECT_4K) },
+   { "mx25l3255e",  INFO(0xc29e16, 0, 64 * 1024,  64, SECT_4K) },
+   { "mx25l6405d",  INFO(0xc22017, 0, 64 * 1024, 128, SECT_4K) },
++  { "mx25u3235f",INFO(0xc22536, 0, 64 * 1024, 64, 0) },


Are you sure the above is correct? According to the datasheet, this  
device does support both 4K and 64K erase size.



+   { "mx25u6435f",  INFO(0xc22537, 0, 64 * 1024, 128, SECT_4K) },
+   { "mx25l12805d", INFO(0xc22018, 0, 64 * 1024, 256, 0) },
+   { "mx25l12855e", INFO(0xc22618, 0, 64 * 1024, 256, 0) },





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

[LEDE-DEV] [PATCH v4 3/5] ipq806x/nbg6817: add sysupgrade support

2016-10-25 Thread André Valentin 
Add new way of flashing to mmc devices based on rootfs split with loop devices.

Signed-off-by: André Valentin 
---
 .../ipq806x/base-files/lib/upgrade/platform.sh | 12 +++
 .../linux/ipq806x/base-files/lib/upgrade/zyxel.sh  | 87 ++
 2 files changed, 99 insertions(+)
 create mode 100644 target/linux/ipq806x/base-files/lib/upgrade/zyxel.sh

diff --git a/target/linux/ipq806x/base-files/lib/upgrade/platform.sh 
b/target/linux/ipq806x/base-files/lib/upgrade/platform.sh
index 8768930..53cdc87 100644
--- a/target/linux/ipq806x/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ipq806x/base-files/lib/upgrade/platform.sh
@@ -9,6 +9,7 @@ platform_check_image() {
ap148 |\
d7800 |\
ea8500 |\
+   nbg6817 |\
r7500 |\
r7500v2 |\
r7800)
@@ -34,6 +35,7 @@ platform_pre_upgrade() {
case "$board" in
ap148 |\
d7800 |\
+   nbg6817 |\
r7500 |\
r7500v2 |\
r7800)
@@ -60,6 +62,16 @@ platform_do_upgrade() {
esac
 }
 
+platform_nand_pre_upgrade() {
+   local board=$(ipq806x_board_name)
+
+   case "$board" in
+   nbg6817)
+   zyxel_do_upgrade "$1"
+   ;;
+   esac
+}
+
 blink_led() {
. /etc/diag.sh; set_state upgrade
 }
diff --git a/target/linux/ipq806x/base-files/lib/upgrade/zyxel.sh 
b/target/linux/ipq806x/base-files/lib/upgrade/zyxel.sh
new file mode 100644
index 000..fc48cb1
--- /dev/null
+++ b/target/linux/ipq806x/base-files/lib/upgrade/zyxel.sh
@@ -0,0 +1,87 @@
+#
+# Copyright (C) 2016 lede-project.org
+#
+
+zyxel_get_rootfs() {
+   local rootfsdev
+
+   if read cmdline < /proc/cmdline; then
+   case "$cmdline" in
+   *root=*)
+   rootfsdev="${cmdline##*root=}"
+   rootfsdev="${rootfsdev%% *}"
+   ;;
+   esac
+
+   echo "${rootfsdev}"
+   fi
+}
+
+zyxel_do_flash() {
+   local tar_file=$1
+   local board=$2
+   local kernel=$3
+   local rootfs=$4
+
+   # keep sure its unbound
+   losetup --detach-all || {
+   echo Failed to detach all loop devices. Skip this try.
+   reboot -f
+   }
+
+   echo "flashing kernel to /dev/${kernel}"
+   tar xf $tar_file sysupgrade-$board/kernel -O >/dev/$kernel
+
+   echo "flashing rootfs to ${rootfs}"
+   tar xf $tar_file sysupgrade-$board/root -O >"${rootfs}"
+
+   # a padded rootfs is needed for overlay fs creation
+   local offset=$(tar xf $tar_file sysupgrade-$board/root -O | wc -c)
+   [ $offset -lt 65536 ] && {
+   echo Wrong size for rootfs: $offset
+   sleep 10
+   reboot -f
+   }
+
+   # Mount loop for rootfs_data
+   losetup -o $offset /dev/loop0 "${rootfs}" || {
+   echo "Failed to mount looped rootfs_data."
+   sleep 10
+   reboot -f
+   }
+
+   echo "Format new rootfs_data at position ${offset}."
+   mkfs.ext4 -F -L rootfs_data /dev/loop0
+   mkdir /tmp/new_root
+   mount -t ext4 /dev/loop0 /tmp/new_root && {
+   echo "Saving config to rootfs_data at position ${offset}."
+   cp -v /tmp/sysupgrade.tgz /tmp/new_root/
+   umount /tmp/new_root
+   }
+
+   # Cleanup
+   losetup -d /dev/loop0 >/dev/null 2>&1
+   sync
+   umount -a
+   reboot -f
+}
+
+zyxel_do_upgrade() {
+   local tar_file="$1"
+   local board=$(cat /tmp/sysinfo/board_name)
+   local rootfs="$(zyxel_get_rootfs)"
+   local kernel=
+
+   [ -b "${rootfs}" ] || return 1
+   case "$board" in
+   nbg6817)
+   kernel=mmcblk0p4
+   ;;
+   *)
+   return 1
+   esac
+
+   zyxel_do_flash $tar_file $board $kernel $rootfs
+
+   return 0
+}
-- 
2.1.4


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

[LEDE-DEV] [PATCH v4 0/5] ipq806x: add support for ZyXEL NBG6817

2016-10-25 Thread André Valentin 
Support for NBG6817 comes with several challenges:
-enable mmc support on platform
-use fstools rootfs split on block devices ( creates a loop dev with offset )
-extend sysupgrade support to format the loop fs and save config 

Changes to v3:
-build sysupgrade images padded to overlay block size
-remove offset calculation from sysupgrade script
-remove old code

older Changes:
-update GPIO definitions

Comments are appreciated.

André Valentin (5):
  ipq806x/nbg6817: add support for ZyXEL NBG6817
  linux/mtd: add id for mx25u3235f needed by ZyXEL NBG6817
  ipq806x/nbg6817: add sysupgrade support
  package/basefiles: add mkfs.ext4 and losetup binaries to ramfs list
  package/uboot-envtools: Add support for ZyXEL NBG6817

 package/base-files/files/lib/upgrade/common.sh |   2 +
 package/boot/uboot-envtools/files/ipq  |   3 +
 .../477-mtd-add-spi-nor-add-mx25u3235f.patch   |  10 +
 .../linux/ipq806x/base-files/etc/board.d/01_leds   |   5 +
 .../ipq806x/base-files/etc/board.d/02_network  |   7 +
 .../etc/hotplug.d/firmware/11-ath10k-caldata   |   6 +
 target/linux/ipq806x/base-files/lib/ipq806x.sh |   3 +
 .../ipq806x/base-files/lib/upgrade/platform.sh |  12 +
 .../linux/ipq806x/base-files/lib/upgrade/zyxel.sh  |  87 ++
 target/linux/ipq806x/config-4.4|  18 +-
 .../arch/arm/boot/dts/qcom-ipq8065-nbg6817.dts | 341 +
 target/linux/ipq806x/image/Makefile|  25 +-
 .../linux/ipq806x/patches-4.4/800-devicetree.patch |   3 +-
 13 files changed, 514 insertions(+), 8 deletions(-)
 create mode 100644 
target/linux/generic/patches-4.4/477-mtd-add-spi-nor-add-mx25u3235f.patch
 create mode 100644 target/linux/ipq806x/base-files/lib/upgrade/zyxel.sh
 create mode 100644 
target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8065-nbg6817.dts

-- 
2.1.4


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

[LEDE-DEV] [PATCH v4 4/5] package/basefiles: add mkfs.ext4 and losetup binaries to ramfs list

2016-10-25 Thread André Valentin 
mkfs.ext4 und losetup are needed for sysupgrade support on mmc devices
with automatic rootfs split (loopback device usage).

Signed-off-by: André Valentin 
---
 package/base-files/files/lib/upgrade/common.sh | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/package/base-files/files/lib/upgrade/common.sh 
b/package/base-files/files/lib/upgrade/common.sh
index bed9c18..4d0e6d5 100644
--- a/package/base-files/files/lib/upgrade/common.sh
+++ b/package/base-files/files/lib/upgrade/common.sh
@@ -69,6 +69,8 @@ run_ramfs() { #  [...]
install_bin /usr/sbin/ubirmvol
install_bin /usr/sbin/ubimkvol
install_bin /usr/sbin/partx
+   install_bin /usr/sbin/losetup
+   install_bin /usr/sbin/mkfs.ext4
for file in $RAMFS_COPY_BIN; do
install_bin ${file//:/ }
done
-- 
2.1.4


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

Re: [LEDE-DEV] [PATCH] [PATCH] fstools: added f2fs to block-mount, really correct indentation

2016-10-25 Thread John Crispin 
Hi,

after some recent changes in the fstools repo this patch applies but
causes a compile error. could you please rebase/test/send the patch

there were also a lot of whitespace errors. please use tabs to indent
your c code
John

On 21/10/2016 14:54, Alberto Bursi wrote:
> added the code to recognize and operate the filesystem checker of f2fs
> 
> added f2fs to the filesystem whitelist of block so it can mount it on
> /overlay at boot.
> 
> Signed-off-by: Alberto Bursi 
> ---
>  block.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/block.c b/block.c
> index 9de8343..073ad05 100644
> --- a/block.c
> +++ b/block.c
> @@ -687,6 +687,7 @@ static void check_filesystem(struct probe_info *pr)
>   pid_t pid;
>   struct stat statbuf;
>   const char *e2fsck = "/usr/sbin/e2fsck";
> + const char *f2fsck = "/usr/sbin/fsck.f2fs";
>   const char *dosfsck = "/usr/sbin/dosfsck";
>   const char *ckfs;
>  
> @@ -696,6 +697,8 @@ static void check_filesystem(struct probe_info *pr)
>  
>   if (!strncmp(pr->type, "vfat", 4)) {
>   ckfs = dosfsck;
> + } else if (!strncmp(pr->id->name, "f2fs", 4)) {
> + ckfs = f2fsck;
>   } else if (!strncmp(pr->type, "ext", 3)) {
>   ckfs = e2fsck;
>   } else {
> @@ -710,8 +713,12 @@ static void check_filesystem(struct probe_info *pr)
>  
>   pid = fork();
>   if (!pid) {
> - execl(ckfs, ckfs, "-p", pr->dev, NULL);
> - exit(-1);
> + if(!strncmp(pr->id->name, "f2fs", 4)) {
> + execl(ckfs, ckfs, "-f", pr->dev, NULL);
> + exit(-1);
> + } else
> + execl(ckfs, ckfs, "-p", pr->dev, NULL);
> + exit(-1);
>   } else if (pid > 0) {
>   int status;
>  
> @@ -1154,8 +1161,9 @@ static int mount_extroot(char *cfg)
>   }
>   if (pr) {
>   if (strncmp(pr->type, "ext", 3) &&
> + strncmp(pr->id->name, "f2fs", 4) &&
>   strncmp(pr->type, "ubifs", 5)) {
> - ULOG_ERR("extroot: unsupported filesystem %s, try 
> ext4\n", pr->type);
> + ULOG_ERR("extroot: unsupported filesystem %s, try ext4 
> or f2fs\n", pr->type);
>   return -1;
>   }
>  
> 

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

Re: [LEDE-DEV] [RFC] brcm47xx: bump kernel to 4.4

2016-10-25 Thread p . wassi 
> It seems I'm experiencing the same crazy problem. Local builds work
> for me (as explained in commit message), but image from buildbot
> doesn't boot. This is some totally crazy thing :|

I opt for staying at 4.4 and not reverting, since the issue already occured
on kernel 4.1 for the WRT54GL (and probably other devices as well?).
So it's _not_ a 4.1 -> 4.4 issue! The last kernel, that booted fine
on my devices (with buildbot images) was OpenWRT 15.05.1 - 3.18.23
As you've experienced yourself: local images also work fine. With 4.1 and 4.4.

Best regards,
P. Wassi

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