[OpenWrt-Devel] umdns not compiling with GCC9`

2019-09-24 Thread Rosen Penev 
/home/mangix/devstuff/openwrt/build_dir/target-mips_24kc_musl/umdns-2018-01-02-78974417/dns.c:
In function 'dns_consume_question':
/home/mangix/devstuff/openwrt/build_dir/target-mips_24kc_musl/umdns-2018-01-02-78974417/dns.c:261:2:
error: converting a packed 'struct dns_question' pointer (alignment 1)
to a 'uint16_t' {aka 'short unsigned int'} pointer (alignment 2) may
result in an unaligned pointer value
[-Werror=address-of-packed-member]
  261 |  uint16_t *swap = (uint16_t *) q;
  |  ^~~~
In file included from
/home/mangix/devstuff/openwrt/build_dir/target-mips_24kc_musl/umdns-2018-01-02-78974417/dns.c:37:
/home/mangix/devstuff/openwrt/build_dir/target-mips_24kc_musl/umdns-2018-01-02-78974417/dns.h:67:8:
note: defined here
   67 | struct dns_question {

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] build: fix make kernel_menuconfig

2019-09-24 Thread Eneas Queiroz 
On Tue, Sep 24, 2019 at 7:07 PM Petr Štetiar  wrote:
>
> Eneas Queiroz  [2019-09-24 18:28:44]:
>
> > I've got your patch applied, and it still fails make menuconfig if I
> > start from scratch or after make -C scripts/config clean.  I haven't
> > tried kernel_menuconfig yet--it will have to compile a lot of stuff if
> > I start fresh.
>
> Ok, my bad, I can't read properly, you're talking about `make menuconfig` but
> I've assumed `make kernel_menuconfig` :-)
>
> So as the commit subject[1] says `build: fix make kernel_{menu,n}config ` this
> patch is about fixing only kernel_{menu,n}config targets, no desire to fix
> other broken targets.
>
> > What do you think?
>
> That it should be probably fixed in a similar manner as the other broken
> config targets, perhaps something like this would work?
>
>  diff --git a/include/toplevel.mk b/include/toplevel.mk
>  index 12586e87c09a..2b3b55db9f75 100644
>  --- a/include/toplevel.mk
>  +++ b/include/toplevel.mk
>  @@ -99,6 +99,9 @@ prepare-tmpinfo: FORCE
> $(_SINGLE)$(NO_TRACE_MAKE) menuconfig $(PREP_MK); \
> fi
>
>  +ifneq ($(DISTRO_PKG_CONFIG),)
>  +scripts/config/mconf: export PATH:=$(dir $(DISTRO_PKG_CONFIG)):$(PATH)
>  +endif
>   scripts/config/mconf:
> @$(_SINGLE)$(SUBMAKE) -s -C scripts/config all CC="$(HOSTCC_WRAPPER)"
>
> Anyway, I've already deleted my testing Gentoo Docker image and don't want to
> emerge a new one in foreseeable future, so it would be nice if you could
> simply confirm, that my proposed patch[1] is ok and works, I'll merge it
> tomorrow and then you can add your fix(es) on top of that, what do you think?
>
> 1. 
> https://gitlab.com/ynezz/openwrt/commit/0a20a3c08652af0d21accae6e76e8946cb4c1b84
>
> -- ynezz

I've applied both your patches ([1] plus the one inline), and tested
with all three affected targets, and they're all working now.

Tested-by: Eneas U de Queiroz 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/2] build: add script to sign packages

2019-09-24 Thread Paul Spooren 
This script allows image signing indipendend of the actual build
process, to run on a master server after receiving freshly backed
images. Idea is to avoid storying private keys on third party builders
while still beeing to be able to sign packages.

Run ./scripts/sign_images.sh with the following env vars:

* TOP_DIR where to search for sysupgrade.bin images
* BUILD_KEY place of key-build{,.pub,.ucert}
* REMOVE_OTHER_SIGNATURES removes signatures added by e.g. buildbots

Only sysupgrade.bin files are touched as factory.bin signatures wouldn't
be evaluated on stock from.

Signed-off-by: Paul Spooren 
---
 scripts/sign_images.sh | 27 +++
 1 file changed, 27 insertions(+)
 create mode 100755 scripts/sign_images.sh

diff --git a/scripts/sign_images.sh b/scripts/sign_images.sh
new file mode 100755
index 00..c41b21e091
--- /dev/null
+++ b/scripts/sign_images.sh
@@ -0,0 +1,27 @@
+#!/bin/sh
+
+# directory where search for images
+TOP_DIR="${TOP_DIR:-./bin/targets}"
+# key to sign images
+BUILD_KEY="${BUILD_KEY:-key-build}" # TODO unifiy naming?
+# remove other signatures (added e.g.  by buildbot)
+REMOVE_OTER_SIGNATURES="${REMOVE_OTER_SIGNATURES:-1}"
+
+# find all sysupgrade images in TOP_DIR
+# factory images don't need signatures as non OpenWrt system doen't check them 
anyway
+for image in $(find $TOP_DIR -type f -name "*-sysupgrade.bin"); do
+   # check if image actually support metadata
+   if fwtool -i /dev/null "$image"; then
+   # remove all previous signatures
+   if [ -n "$REMOVE_OTER_SIGNATURES" ]; then
+   while [ "$?" = 0 ]; do
+   fwtool -t -s /dev/null "$image"
+   done
+   fi
+   # run same operation as build root does for signing
+   cp "$BUILD_KEY.ucert" "$image.ucert"
+   usign -S -m "$image" -s "$BUILD_KEY" -x "$image.sig"
+   ucert -A -c "$image.ucert" -x "$image.sig"
+   fwtool -S "$image.ucert" "$image"
+   fi
+done
-- 
2.23.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/2] build: separate signing logic

2019-09-24 Thread Paul Spooren 
This separates the options for signature creation and verification

* SIGNED_PACKAGES create Packages.sig
* SIGNED_IMAGES add ucert signature to created images
* CHECK_SIGNATURE add verification capabilities to images
* INSTALL_LOCAL_KEY add local key-build to /etc/opkg/keys

Right now the buildbot.git contains some hacks to create images that
have signature verification capabilities while not storing private keys
on buildbot slaves. This commit allows to disable these steps for the
buildbots and only perform signing on the master.

Signed-off-by: Paul Spooren 
---
 config/Config-build.in  | 12 ++--
 include/image-commands.mk   | 13 -
 package/base-files/Makefile | 17 +
 3 files changed, 27 insertions(+), 15 deletions(-)

diff --git a/config/Config-build.in b/config/Config-build.in
index 35341833e3..fd2ae5bbdd 100644
--- a/config/Config-build.in
+++ b/config/Config-build.in
@@ -30,13 +30,21 @@ menu "Global build settings"
  - Enabling per-device rootfs support
  ...
 
+   config INSTALL_LOCAL_KEY
+   bool "Install local usign key into image"
+   default n
+
config SIGNED_PACKAGES
bool "Cryptographically signed package lists"
-   default y
+   default n
+
+   config SIGNED_IMAGES
+   bool "Cryptographically signed firmware images"
+   default n
 
config SIGNATURE_CHECK
bool "Enable signature checking in opkg"
-   default SIGNED_PACKAGES
+   default y
 
comment "General build options"
 
diff --git a/include/image-commands.mk b/include/image-commands.mk
index 1d0aed1918..d4d19a40e1 100644
--- a/include/image-commands.mk
+++ b/include/image-commands.mk
@@ -370,11 +370,14 @@ metadata_json = \
 
 define Build/append-metadata
$(if $(SUPPORTED_DEVICES),-echo $(call 
metadata_json,$(SUPPORTED_DEVICES)) | fwtool -I - $@)
-   [ ! -s "$(BUILD_KEY)" -o ! -s "$(BUILD_KEY).ucert" -o ! -s "$@" ] || { \
-   cp "$(BUILD_KEY).ucert" "$@.ucert" ;\
-   usign -S -m "$@" -s "$(BUILD_KEY)" -x "$@.sig" ;\
-   ucert -A -c "$@.ucert" -x "$@.sig" ;\
-   fwtool -S "$@.ucert" "$@" ;\
+   [ -z "$(SIGNED_IMAGES)" \
+   -o ! -s "$(BUILD_KEY)" \
+   -o ! -s "$(BUILD_KEY).ucert" \
+   -o ! -s "$@" ] || { \
+   cp "$(BUILD_KEY).ucert" "$@.ucert" ;\
+   usign -S -m "$@" -s "$(BUILD_KEY)" -x "$@.sig" ;\
+   ucert -A -c "$@.ucert" -x "$@.sig" ;\
+   fwtool -S "$@.ucert" "$@" ;\
}
 endef
 
diff --git a/package/base-files/Makefile b/package/base-files/Makefile
index f105d2cd27..588c958f80 100644
--- a/package/base-files/Makefile
+++ b/package/base-files/Makefile
@@ -37,7 +37,7 @@ endif
 define Package/base-files
   SECTION:=base
   CATEGORY:=Base system
-  DEPENDS:=+netifd +libc +procd +jsonfilter +SIGNED_PACKAGES:usign 
+SIGNED_PACKAGES:openwrt-keyring +NAND_SUPPORT:ubi-utils +fstools +fwtool
+  DEPENDS:=+netifd +libc +procd +jsonfilter +SIGNATURE_CHECK:usign 
+SIGNATURE_CHECK:openwrt-keyring +NAND_SUPPORT:ubi-utils +fstools +fwtool
   TITLE:=Base filesystem for OpenWrt
   URL:=http://openwrt.org/
   VERSION:=$(PKG_RELEASE)-$(REVISION)
@@ -116,12 +116,6 @@ ifdef CONFIG_SIGNED_PACKAGES
$(STAGING_DIR_HOST)/bin/ucert -I -c $(BUILD_KEY).ucert -p 
$(BUILD_KEY).pub -s $(BUILD_KEY)
 
   endef
-
-  define Package/base-files/install-key
-   mkdir -p $(1)/etc/opkg/keys
-   $(CP) $(BUILD_KEY).pub 
$(1)/etc/opkg/keys/`$(STAGING_DIR_HOST)/bin/usign -F -p $(BUILD_KEY).pub`
-
-  endef
 endif
 
 ifeq ($(CONFIG_NAND_SUPPORT),)
@@ -130,9 +124,16 @@ ifeq ($(CONFIG_NAND_SUPPORT),)
   endef
 endif
 
+ifdef CONFIG_INSTALL_LOCAL_KEY
+  define Package/base-files/install-local-key
+   mkdir -p $(1)/etc/opkg/keys
+   $(CP) $(BUILD_KEY).pub 
$(1)/etc/opkg/keys/`$(STAGING_DIR_HOST)/bin/usign \
+   -F -p $(BUILD_KEY).pub`
+endef
+
 define Package/base-files/install
$(CP) ./files/* $(1)/
-   $(Package/base-files/install-key)
+   $(Package/base-files/install-local-key)
$(Package/base-files/nand-support)
if [ -d $(GENERIC_PLATFORM_DIR)/base-files/. ]; then \
$(CP) $(GENERIC_PLATFORM_DIR)/base-files/* $(1)/; \
-- 
2.23.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] build: fix make kernel_menuconfig

2019-09-24 Thread Petr Štetiar 
Eneas Queiroz  [2019-09-24 18:28:44]:

> I've got your patch applied, and it still fails make menuconfig if I
> start from scratch or after make -C scripts/config clean.  I haven't
> tried kernel_menuconfig yet--it will have to compile a lot of stuff if
> I start fresh.

Ok, my bad, I can't read properly, you're talking about `make menuconfig` but
I've assumed `make kernel_menuconfig` :-)

So as the commit subject[1] says `build: fix make kernel_{menu,n}config ` this
patch is about fixing only kernel_{menu,n}config targets, no desire to fix
other broken targets.

> What do you think?

That it should be probably fixed in a similar manner as the other broken
config targets, perhaps something like this would work?

 diff --git a/include/toplevel.mk b/include/toplevel.mk
 index 12586e87c09a..2b3b55db9f75 100644
 --- a/include/toplevel.mk
 +++ b/include/toplevel.mk
 @@ -99,6 +99,9 @@ prepare-tmpinfo: FORCE
$(_SINGLE)$(NO_TRACE_MAKE) menuconfig $(PREP_MK); \
fi
  
 +ifneq ($(DISTRO_PKG_CONFIG),)
 +scripts/config/mconf: export PATH:=$(dir $(DISTRO_PKG_CONFIG)):$(PATH)
 +endif
  scripts/config/mconf:
@$(_SINGLE)$(SUBMAKE) -s -C scripts/config all CC="$(HOSTCC_WRAPPER)"

Anyway, I've already deleted my testing Gentoo Docker image and don't want to
emerge a new one in foreseeable future, so it would be nice if you could
simply confirm, that my proposed patch[1] is ok and works, I'll merge it
tomorrow and then you can add your fix(es) on top of that, what do you think?

1. 
https://gitlab.com/ynezz/openwrt/commit/0a20a3c08652af0d21accae6e76e8946cb4c1b84

-- ynezz

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] build: fix make kernel_menuconfig

2019-09-24 Thread Eneas Queiroz 
Sorry for the double reply, Peter, this did not make it to the list.

On Tue, Sep 24, 2019 at 5:42 PM Petr Štetiar  wrote:
>
> Eneas Queiroz  [2019-09-24 17:06:28]:
>
> Hi,
>
> > The problem is that when scripts/config/lxdialog/check-lxdialog.sh is run,
> > it will still use the staging_dir/host/bin/pkg-config script without
> > STAGING_PREFIX set.
>
> it doesn't work like that here, I've just added following into 
> check-lxdialog.sh:
>
>   echo "$(command -v pkg-config)" > $TOPDIR/meh.log
>
> and meh.log contains /usr/bin/pkg-config after kernel_menuconfig run.
>
> > > +DISTRO_PKG_CONFIG:=$(shell which -a pkg-config | grep -E '\/usr' | head 
> > > -n 1)
> > If we export this, then we can check its existence in
> > tools/pkg-config/files/pkg-config, and decide which pkg-config we want
> > to run.
>
> if I understand it correctly this global exports are not welcome.
>
> > Then, we can use the variable in our pkg-config script to decide what
> > to run, using just pkg-config.real as a fallback if nothing is defined
> > (alternatively, we can fail instead):
>
> similar approach was already suggested[1] by Thomas originally and was 
> considered
> brittle (and I agreed with that), so I've reworked it to current version.
>
> 1. https://patchwork.ozlabs.org/patch/1163120/
>
> -- ynezz

I've got your patch applied, and it still fails make menuconfig if I
start from scratch or after make -C scripts/config clean.  I haven't
tried kernel_menuconfig yet--it will have to compile a lot of stuff if
I start fresh.

I've tried to run it like you did, but my meh.log points to
/home/equeiroz/src/openwrt/staging_dir/host/bin/pkg-config.  How will
it get past $(TOPDIR)/staging_dir/host/bin, if that's the first
thing--at least here--in PATH?

I can certainly agree that globals are not really the best way.  To
avoid that, we can set DISTRO_PKG_CONFIG inside
tools/pkg-config/files/pkg-config, and go from there:
DISTRO_PKG_CONFIG="$(which -a pkg-config | grep -Ev
'staging_dir/host/bin/pkg-config' | head -n 1)"

What do you think?

Cheers,

Eneas

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] build: fix make kernel_menuconfig

2019-09-24 Thread Petr Štetiar 
Eneas Queiroz  [2019-09-24 17:06:28]:

Hi,

> The problem is that when scripts/config/lxdialog/check-lxdialog.sh is run,
> it will still use the staging_dir/host/bin/pkg-config script without
> STAGING_PREFIX set.

it doesn't work like that here, I've just added following into 
check-lxdialog.sh:

  echo "$(command -v pkg-config)" > $TOPDIR/meh.log

and meh.log contains /usr/bin/pkg-config after kernel_menuconfig run.

> > +DISTRO_PKG_CONFIG:=$(shell which -a pkg-config | grep -E '\/usr' | head -n 
> > 1)
> If we export this, then we can check its existence in
> tools/pkg-config/files/pkg-config, and decide which pkg-config we want
> to run.

if I understand it correctly this global exports are not welcome.

> Then, we can use the variable in our pkg-config script to decide what
> to run, using just pkg-config.real as a fallback if nothing is defined
> (alternatively, we can fail instead):

similar approach was already suggested[1] by Thomas originally and was 
considered
brittle (and I agreed with that), so I've reworked it to current version.

1. https://patchwork.ozlabs.org/patch/1163120/

-- ynezz

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] buildbot: store key-build.pub as 0644

2019-09-24 Thread Paul Spooren 
All other keys are stored as 0644, the only reason this key is 0600 is
as the key-build should be hidden from others. Changing the public key
it to 0644 it is in line with all other keys in /etc/opkg/keys.

Signed-off-by: Paul Spooren 
---
 phase1/master.cfg | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/phase1/master.cfg b/phase1/master.cfg
index ee26fe4..f0151f6 100644
--- a/phase1/master.cfg
+++ b/phase1/master.cfg
@@ -763,7 +763,7 @@ for target in targets:
name = "dlkeybuildpub",
s = UsignSec2Pub(usign_key, usign_comment),
slavedest = "key-build.pub",
-   mode = 0600,
+   mode = 0644,
))
 
factory.addStep(StringDownload(
-- 
2.23.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] build: fix make kernel_menuconfig

2019-09-24 Thread Eneas Queiroz 
This is still failing on gentoo.  The problem is that when
scripts/config/lxdialog/check-lxdialog.sh is run, it will still use
the staging_dir/host/bin/pkg-config script without STAGING_PREFIX set.
See my suggestion below.

On Mon, Sep 23, 2019 at 4:39 AM Petr Štetiar  wrote:
>
> On a recent Gentoo Linux installation, invoking `make kernel_menuconfig`
> in the build system fails, whereas `make menuconfig` in the kernel tree
> alone works as expected.
>
> This is happening because STAGING_PREFIX is not defined when kernel's
> menuconfig target calls pkg-config from the toolchain/host and thus
> pkg-config returns an empty value, and the fallback values in the kernel
> config script are applied but those are off and the linking fails.
>
> Solution is to use system's pkg-config for kernel_menuconfig target in
> order to provide proper compiler/linker flags.
>
> Ref: FS#2423
> Cc: Thomas Albers 
> Signed-off-by: Petr Štetiar 
> ---
>
> changes in v2:
>
>  * fixed kernel_nconfig path
>
>  Makefile| 1 +
>  include/toplevel.mk | 8 +++-
>  scripts/config/Makefile | 2 --
>  3 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index ab97eacc9d2b..65ee10a84b8d 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -18,6 +18,7 @@ $(if $(findstring $(space),$(TOPDIR)),$(error ERROR: The 
> path to the OpenWrt dir
>
>  world:
>
> +DISTRO_PKG_CONFIG:=$(shell which -a pkg-config | grep -E '\/usr' | head -n 1)
If we export this, then we can check its existence in
tools/pkg-config/files/pkg-config, and decide which pkg-config we want
to run.
The following is optional, since it already works as is, but I would
suggest not using `/usr` as a filter here; TOPDIR may be in /usr.
Instead, we can filter-out "staging_dir/host/bin", which is what we
are adding to PATH below:

export DISTRO_PKG_CONFIG:=$(shell which -a pkg-config | grep -vE
'/staging_dir/host/bin/pkg-config' | head -n 1)

Then, we can use the variable in our pkg-config script to decide what
to run, using just pkg-config.real as a fallback if nothing is defined
(alternatively, we can fail instead):

--- a/tools/pkg-config/files/pkg-config
+++ b/tools/pkg-config/files/pkg-config
@@ -1,3 +1,9 @@
 #!/bin/sh

-pkg-config.real --define-variable=prefix=${STAGING_PREFIX}
--define-variable=exec_prefix=${STAGING_PREFIX}
--define-variable=bindir=${STAGING_PREFIX}/bin $@
+if [ -n "${STAGING_PREFIX}" ]; then
+   pkg-config.real --define-variable=prefix=${STAGING_PREFIX}
--define-variable=exec_prefix=${STAGING_PREFIX}
--define-variable=bindir=${STAGING_PREFIX}/bin $@
+elif [ -n "${DISTRO_PKG_CONFIG}" ]; then
+   ${DISTRO_PKG_CONFIG} $@
+else
+   pkg-config.real $@
+fi

Regards,

Eneas

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ramips: add support for Asus RT-AC65P

2019-09-24 Thread vargagab 
From: Gabor Varga 

The Asus RT-AC65P router is identical with the RT-AC85P, but better to make 
separate images for it.

On both routers the installation can be done also via SSH:

Note: The user/password for SSH is identical with the one used in the
Web-interface.

1. Complete the initial setup wizard.
2. Activate SSH under "Administration" -> "System".
3. Transfer the OpenWrt factory image via scp:
 > scp openwrt-ramips-mt7621-asus_rt-ac65p-squashfs-factory.bin 
 > admin@192.168.50.1:/tmp
4. Connect via SSH to the router.
 > ssh admin@192.168.50.1
5. Write the OpenWrt image to flash.
 > mtd-write -i
/tmp/openwrt-ramips-mt7621-asus_rt-ac65p-squashfs-factory.bin -d linux
6. Reboot the router
 > reboot

Signed-off-by: Gabor Varga 
---
 .../ramips/base-files/etc/board.d/02_network  |   2 +
 .../ramips/base-files/lib/upgrade/platform.sh |   2 +
 .../linux/ramips/dts/mt7621_asus_rt-ac65p.dts |   9 +
 .../linux/ramips/dts/mt7621_asus_rt-ac85p.dts | 155 +
 .../ramips/dts/mt7621_asus_rt-ac[68]5p.dtsi   | 159 ++
 target/linux/ramips/image/mt7621.mk   |  16 ++
 6 files changed, 189 insertions(+), 154 deletions(-)
 create mode 100644 target/linux/ramips/dts/mt7621_asus_rt-ac65p.dts
 create mode 100644 target/linux/ramips/dts/mt7621_asus_rt-ac[68]5p.dtsi

diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index 63644331e5..f66b5742ec 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -233,6 +233,7 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"0:lan" "1:wan" "6@eth0"
;;
+   asus,rt-ac65p|\
asus,rt-ac85p|\
dlink,dir-860l-b1|\
elecom,wrc-1167ghbk2-s|\
@@ -561,6 +562,7 @@ ramips_setup_macs()
zbtlink,zbt-we3526)
wan_mac=$(mtd_get_mac_binary factory 0xe006)
;;
+   asus,rt-ac65p|\
asus,rt-ac85p)
wan_mac=$(mtd_get_mac_ascii u-boot-env et1macaddr)
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index a62ded4b9d..03e994dfa4 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -18,6 +18,7 @@ platform_do_upgrade() {
mikrotik,rbm33g)
[ -z "$(rootfs_type)" ] && mtd erase firmware
;;
+   asus,rt-ac65p|\
asus,rt-ac85p)
echo "Backing up firmware"
dd if=/dev/mtd4 bs=1024 count=4096  > /tmp/backup_firmware.bin
@@ -27,6 +28,7 @@ platform_do_upgrade() {
esac
 
case "$board" in
+   asus,rt-ac65p|\
asus,rt-ac85p|\
hiwifi,hc5962|\
netgear,r6220|\
diff --git a/target/linux/ramips/dts/mt7621_asus_rt-ac65p.dts 
b/target/linux/ramips/dts/mt7621_asus_rt-ac65p.dts
new file mode 100644
index 00..d952221b48
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_asus_rt-ac65p.dts
@@ -0,0 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7621_asus_rt-ac[68]5p.dtsi"
+
+/ {
+   compatible = "asus,rt-ac65p", "mediatek,mt7621-soc";
+   model = "ASUS RT-AC65P";
+};
diff --git a/target/linux/ramips/dts/mt7621_asus_rt-ac85p.dts 
b/target/linux/ramips/dts/mt7621_asus_rt-ac85p.dts
index 3ddbfcfb7c..b24bbc8d06 100644
--- a/target/linux/ramips/dts/mt7621_asus_rt-ac85p.dts
+++ b/target/linux/ramips/dts/mt7621_asus_rt-ac85p.dts
@@ -1,162 +1,9 @@
 // SPDX-License-Identifier: GPL-2.0-or-later OR MIT
 /dts-v1/;
 
-#include "mt7621.dtsi"
-
-#include 
-#include 
+#include "mt7621_asus_rt-ac[68]5p.dtsi"
 
 / {
compatible = "asus,rt-ac85p", "mediatek,mt7621-soc";
model = "ASUS RT-AC85P";
-
-   aliases {
-   led-boot = _power;
-   led-failsafe = _power;
-   led-running = _power;
-   led-upgrade = _power;
-   };
-
-   chosen {
-   bootargs = "console=ttyS0,57600";
-   };
-
-   palmbus: palmbus@1E00 {
-   i2c@900 {
-   status = "okay";
-   };
-   };
-
-   keys {
-   compatible = "gpio-keys";
-
-   reset {
-   label = "reset";
-   gpios = < 3 GPIO_ACTIVE_LOW>;
-   linux,code = ;
-   };
-
-   wps {
-   label = "wps";
-   gpios = < 6 GPIO_ACTIVE_LOW>;
-   linux,code = ;
-   };
-   };
-
-   leds {
-   compatible = "gpio-leds";
-
-   led_power: power {
-   label = "rt-ac85p:blue:power";
-   gpios = < 4 GPIO_ACTIVE_LOW>;
-   linux,default-trigger = "phy0tpt";
-

Re: [OpenWrt-Devel] [PATCH v2 2/2] ramips: Add support for ZBT WE1026-H

2019-09-24 Thread mail 
Hi,

> I prefer consistency, so my preference would be staying with the initial
> naming scheme used for this "family" of devices.

I'm all about consistency. I just scanned the image definitions in ramips:

define Device/zbtlink_zbt-we1226
  DEVICE_VENDOR := ZBTlink
  DEVICE_MODEL := ZBT-WE1226

define Device/zbtlink_we1026-5g-16m
  DEVICE_VENDOR := Zbtlink
  DEVICE_MODEL := ZBT-WE1026-5G

define Device/zbtlink_zbt-ape522ii
  DEVICE_VENDOR := Zbtlink
  DEVICE_MODEL := ZBT-APE522II

define Device/zbtlink_zbt-cpe102
  DEVICE_VENDOR := Zbtlink
  DEVICE_MODEL := ZBT-CPE102

define Device/zbtlink_zbt-wa05
  DEVICE_VENDOR := Zbtlink
  DEVICE_MODEL := ZBT-WA05

define Device/zbtlink_zbt-we2026
  DEVICE_VENDOR := Zbtlink
  DEVICE_MODEL := ZBT-WE2026

define Device/zbtlink_zbt-we826-16m
  DEVICE_VENDOR := Zbtlink
  DEVICE_MODEL := ZBT-WE826
  DEVICE_VARIANT := 16M

define Device/zbtlink_zbt-we826-32m
  DEVICE_VENDOR := Zbtlink
  DEVICE_MODEL := ZBT-WE826
  DEVICE_VARIANT := 32M

define Device/zbtlink_zbt-we826-e
  DEVICE_VENDOR := Zbtlink
  DEVICE_MODEL := ZBT-WE826-E

define Device/zbtlink_zbt-wr8305rt
  DEVICE_VENDOR := Zbtlink
  DEVICE_MODEL := ZBT-WR8305RT

define Device/zbtlink_zbt-we1326
  DEVICE_VENDOR := ZBT
  DEVICE_MODEL := ZBT-WE1326

define Device/zbtlink_zbt-we3526
  DEVICE_VENDOR := ZBT
  DEVICE_MODEL := ZBT-WE3526

define Device/zbtlink_zbt-wg2626
  DEVICE_VENDOR := ZBT
  DEVICE_MODEL := ZBT-WG2626

define Device/zbtlink_zbt-wg3526-16m
  DEVICE_VENDOR := ZBT
  DEVICE_MODEL := ZBT-WG3526
  DEVICE_VARIANT := 16M

define Device/zbtlink_zbt-wg3526-32m
  DEVICE_VENDOR := ZBT
  DEVICE_MODEL := ZBT-WG3526
  DEVICE_VARIANT := 32M

The only device deviating from the pattern "zbtlink_zbt-something" is 
zbtlink_we1026-5g-16m.

So, IMO the correct solution _in terms of consistency_ would be to rename 
zbtlink_we1026-5g-16m to zbtlink_zbt-we1026-5g-16m and then adjust your device 
support for the -H to that scheme.

Do you agree? If yes, you could either implement all changes within or before 
your patch 1/2. Or I could send a patch for that and you rebase on it.

What do you think?

(I will send a separate patch to unify the device vendor)

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2 2/2] ramips: Add support for ZBT WE1026-H

2019-09-24 Thread Kristian Evensen 
Hi,

On Tue, Sep 24, 2019 at 1:28 PM Adrian Schmutzler
 wrote:
>
> Hi,
>
> first of all:
> Naming scheme for ZBT devices is mixed in ramips. Some include the ZBT in 
> model name, some don't. In your case, this means the following options:
> zbtlink,zbt-we1026-hcorresponding to modelZBT-WE1026-H
> or
> zbtlink,we1026-hcorresponding to modelWE1026-H
>
> I do not know what's correct here (if there is right/wrong for this at all), 
> but just want you to decide about this intentionally. Even if the existing 
> WE1026-5G proves to have the wrong scheme then, I'd use the correct one for 
> the WE1026-H.

I prefer consistency, so my preference would be staying with the
initial naming scheme used for this "family" of devices.

> > diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds 
> > b/target/linux/ramips/base-files/etc/board.d/01_leds
> > index 46202b4117..3e12c2a947 100755
> > --- a/target/linux/ramips/base-files/etc/board.d/01_leds
> > +++ b/target/linux/ramips/base-files/etc/board.d/01_leds
> > @@ -461,6 +461,11 @@ zbtlink,zbt-we826-16m|\
> >  zbtlink,zbt-we826-32m)
> >   set_wifi_led "zbt-we826:green:wifi"
> >   ;;
> > +zbtlink,we1026-h-32m)
>
> If you keep this name (without zbt), then you should sort it appropriately, 
> i.e. "we" before "zbt" ...

True, thanks for spotting that.

> > @@ -721,6 +722,9 @@ ramips_setup_macs()
> >   wan_mac=$(mtd_get_mac_binary factory 0xe006)
> >   label_mac=$(cat /sys/class/ieee80211/phy0/macaddress)
> >   ;;
> > + zbtlink,we1026-h-32m)
> > + wan_mac=$(mtd_get_mac_binary factory 0x2e)
> > + ;;
>
> Depending on how the label MAC address discussion below ends, you might merge 
> this with the node for cudy,wr1000.
>
> >   *)
> >   wan_mac=$(macaddr_add "$(cat /sys/class/net/eth0/address)" 1)
> >   ;;
> > diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_we1026-h-32m.dts 
> > b/target/linux/ramips/dts/mt7620a_zbtlink_we1026-h-
> > 32m.dts
> > new file mode 100644
> > index 00..ca62ccfc84
> > --- /dev/null
> > +++ b/target/linux/ramips/dts/mt7620a_zbtlink_we1026-h-32m.dts
> > @@ -0,0 +1,14 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> > +/dts-v1/;
> > +
> > +#include "mt7620a_zbtlink_we1026-h.dtsi"
> > +
> > +/ {
> > + compatible = "zbtlink,we1026-h-32m", "zbtlink,we1026-h",
> > +  "zbtlink,we1026","ralink,mt7620a-soc";
> > + model = "ZBT WE1026-H (32M)";
> > +};
> > +
> > + {
> > + reg = <0x5 0x1fb>;
> > +};
> > diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_we1026-h.dtsi 
> > b/target/linux/ramips/dts/mt7620a_zbtlink_we1026-h.dtsi
> > new file mode 100644
> > index 00..fed79c2809
> > --- /dev/null
> > +++ b/target/linux/ramips/dts/mt7620a_zbtlink_we1026-h.dtsi
> > @@ -0,0 +1,42 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> > +/dts-v1/;
> > +
> > +#include "mt7620a_zbtlink_we1026.dtsi"
> > +
> > +/ {
> > + compatible = "zbtlink,we1026-h", "zbtlink,we1026",
> > +  "ralink,mt7620a-soc";
> > +
> > + aliases {
> > + led-boot = _power;
> > + led-failsafe = _power;
> > + led-running = _power;
> > + led-upgrade = _power;
> > + label-mac-device = 
>
> This won't work, as wmac uses ralink,mtd-eeprom without mtd-mac-address (so 
> you do not have access to the mac address via /proc/device-tree).

Ok, thanks for letting me know. I got confused because I saw other
devices assigning the same value to label-mac-device. I will remove
label-mac-device from the DTS then, as I do not see the point of
having something around that may or may not be used in the future. The
assignment can rather be added when label-mac-device is properly
supported.

> Current policy is to keep label-mac-device here anyway (for future use), but 
> to include a line like the following in the mac setup section of 02_network 
> to actually have label MAC address set:
> label_mac=$(cat /sys/class/ieee80211/phy0/macaddress)
> You have to evaluate whether phy0 or phy1 is correct for your device.
> If phy0 is, you can just add the device(s) to the cudy,wr1000 case.

Ok, thanks.

> If you have access to the WE1026-5G, too, the cleanest way would be to check 
> label MAC address on it and then add label MAC address for all WE1026-* in 
> 02_network, and move the label_mac_device alias to the parent DTSI where wmac 
> is set up.

I will that a look.

> > +define Device/zbtlink_we1026-h-32m
> > +  MTK_SOC := mt7620a
> > +  DTS := WE1026-H-32M
>
> This line (DTS) can be dropped. DTS name is constructed automatically from 
> node name and mtk_soc ...

Thanks for spotting this.

>
> > +  IMAGE_SIZE := 32448k
> > +  DEVICE_VENDOR := Zbtlink
> > +  DEVICE_MODEL := ZBT-WE1026-H
>
> If you choose that name, then you have to use zbtlink_zbt-we1026-h-32m.
> Otherwise, put "WE1026-H" here.

The DEVICE_MODEL for the other 1026-devices

Re: [OpenWrt-Devel] [PATCH] ipq40xx: remove redundant ucidef_set_interfaces_* in 02_network

2019-09-24 Thread Dmitry Tunin 
Hi David,
> On the other hand there's ipqess and qca8k on the horizon to end the ar40xx 
> mess.
> But i don't think this is a showstopper for this.

That stopped me from doing this fast. ipqess will solve it anyway.
Maybe it is not worth the effort now. I don't see a straightforward
simple solution for now.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ipq40xx: remove redundant ucidef_set_interfaces_* in 02_network

2019-09-24 Thread Dmitry Tunin 
> Are you just talking about asus/zyxel case or should I remove the entire 
> patch (-> mark as deferred)?
I mean all ipq40xx devices with two MACs. I mentioned the two I have.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2 2/2] ramips: Add support for ZBT WE1026-H

2019-09-24 Thread Adrian Schmutzler 
Hi,

first of all:
Naming scheme for ZBT devices is mixed in ramips. Some include the ZBT in model 
name, some don't. In your case, this means the following options:
zbtlink,zbt-we1026-hcorresponding to modelZBT-WE1026-H
or
zbtlink,we1026-hcorresponding to modelWE1026-H

I do not know what's correct here (if there is right/wrong for this at all), 
but just want you to decide about this intentionally. Even if the existing 
WE1026-5G proves to have the wrong scheme then, I'd use the correct one for the 
WE1026-H.

Find some comments below.

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On 
> Behalf Of Kristian Evensen
> Sent: Dienstag, 24. September 2019 12:47
> To: openwrt-devel@lists.openwrt.org; d...@kresin.me; mon...@monkeh.net; 
> musashino.o...@gmail.com; yn...@true.cz
> Cc: Kristian Evensen 
> Subject: [OpenWrt-Devel] [PATCH v2 2/2] ramips: Add support for ZBT WE1026-H
> 
> This commit adds support for the ZBT WE1026-H, an outdoor AP with
> support for adding an internal LTE modem. The detailed specs are:
> 
> * CPU: MT7620A
> * 2x 10/100Mbps Ethernet (LAN port has passive PoE support).
> * 16/32 MB Flash.
> * 128/256 MB RAM.
> * 1x USB 2.0 port.
> * 1x mini-PCIe slot (only USB2.0 bus).
> * 1x SIM slot (standard size).
> * 1x 2.4Ghz WIFI (rt2800).
> * 1x button.
> * 6x LEDS (4 GPIO-controlled).
> * 1x micro-SD reader.
> 
> The following have been tested and working:
> - Ethernet switch
> - Wifi
> - Mini-PCIe slot + SIM slot
> - USB port
> - microSD slot
> - sysupgrade
> - reset button
> 
> Installation and recovery:
> 
> In order to install OpenWRT the first time or ito recover the router,
> you can use the web-based recovery system. Keep the reset button pressed
> during boot and access 192.168.1.1 in your browser when your machine
> obtains an IP address. Upload the firmware to start the recovery
> process.
> 
> Notes:
> 
> * The LED labeled "USB" is used as the power LED. When binding this LED
> to a usbport, the LED is switched on all the time due to the presence of
> an internal hub. Thus, it does not really signal any USB-information.
> 
> * I only have the 32MB version and have only added support for this
> device. However, the files are structured so that adding support for the
> 16MB version should be easy.
> 
> * Only the LAN port is accessible from the outside of the casing and LEDs
> are not visible.
> 
> v1->v2:
> * Rebased on top of master.
> * Read correct WAN address from flash (thanks Adrian Schmutzler).
> 
> Signed-off-by: Kristian Evensen 
> ---
>  .../ramips/base-files/etc/board.d/01_leds |  5 +++
>  .../ramips/base-files/etc/board.d/02_network  |  6 ++-
>  .../dts/mt7620a_zbtlink_we1026-h-32m.dts  | 14 +++
>  .../ramips/dts/mt7620a_zbtlink_we1026-h.dtsi  | 42 +++
>  target/linux/ramips/image/mt7620.mk   | 12 ++
>  5 files changed, 78 insertions(+), 1 deletion(-)
>  create mode 100644 target/linux/ramips/dts/mt7620a_zbtlink_we1026-h-32m.dts
>  create mode 100644 target/linux/ramips/dts/mt7620a_zbtlink_we1026-h.dtsi
> 
> diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds 
> b/target/linux/ramips/base-files/etc/board.d/01_leds
> index 46202b4117..3e12c2a947 100755
> --- a/target/linux/ramips/base-files/etc/board.d/01_leds
> +++ b/target/linux/ramips/base-files/etc/board.d/01_leds
> @@ -461,6 +461,11 @@ zbtlink,zbt-we826-16m|\
>  zbtlink,zbt-we826-32m)
>   set_wifi_led "zbt-we826:green:wifi"
>   ;;
> +zbtlink,we1026-h-32m)

If you keep this name (without zbt), then you should sort it appropriately, 
i.e. "we" before "zbt" ...

> + set_wifi_led "we1026-h:green:wifi"
> + ucidef_set_led_switch "lan" "lan" "we1026-h:green:lan" "switch0" "0x8"
> + ucidef_set_led_switch "wan" "wan" "we1026-h:green:wan" "switch0" "0x10"
> + ;;
>  zbtlink,zbt-we1226)
>   set_wifi_led "$boardname:green:wlan"
>   ucidef_set_led_switch "lan1" "LAN1" "$boardname:green:lan1" "switch0" 
> "0x01"
> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
> b/target/linux/ramips/base-files/etc/board.d/02_network
> index 63644331e5..d94cd5fa98 100755
> --- a/target/linux/ramips/base-files/etc/board.d/02_network
> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
> @@ -272,7 +272,8 @@ ramips_setup_interfaces()
>   ucidef_add_switch "switch0" \
>   "1:lan" "2:lan" "3:lan" "4:lan" "0:wan" "5@eth0"
>   ;;
> - buffalo,wcr-1166ds)
> + buffalo,wcr-1166ds|\
> + zbtlink,we1026-h-32m)
>   ucidef_add_switch "switch0" \
>   "3:lan" "4:wan" "6@eth0"
>   ;;
> @@ -721,6 +722,9 @@ ramips_setup_macs()
>   wan_mac=$(mtd_get_mac_binary factory 0xe006)
>   label_mac=$(cat /sys/class/ieee80211/phy0/macaddress)
>   ;;
> + zbtlink,we1026-h-32m)
> + wan_mac=$(mtd_get_mac_binary factory 0x2e)
> + ;;

Re: [OpenWrt-Devel] [PATCH v2 1/2] ramips: Update ZBT WE1026 DTS-files

2019-09-24 Thread Adrian Schmutzler 
Hi,

don't know whether that's required as I only did the DTS file rename, but you 
can also add my
Acked-by: Adrian Schmutzler 

Some optional nitpicks:

> diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_we1026-5g.dtsi 
> b/target/linux/ramips/dts/mt7620a_zbtlink_we1026-5g.dtsi
> index e7e64e251a..b90179fe1f 100644
> --- a/target/linux/ramips/dts/mt7620a_zbtlink_we1026-5g.dtsi
> +++ b/target/linux/ramips/dts/mt7620a_zbtlink_we1026-5g.dtsi
> @@ -1,47 +1,9 @@
> -/*
> - *  BSD LICENSE
> - *
> - *  Copyright(c) 2017 Kristian Evensen .
> - *  All rights reserved.
> - *
> - *  Redistribution and use in source and binary forms, with or without
> - *  modification, are permitted provided that the following conditions
> - *  are met:
> - *
> - ** Redistributions of source code must retain the above copyright
> - *  notice, this list of conditions and the following disclaimer.
> - ** Redistributions in binary form must reproduce the above copyright
> - *  notice, this list of conditions and the following disclaimer in
> - *  the documentation and/or other materials provided with the
> - *  distribution.
> - ** Neither the name of Broadcom Corporation nor the names of its
> - *  contributors may be used to endorse or promote products derived
> - *  from this software without specific prior written permission.
> - *
> - *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> - *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> - *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> - *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
> - *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> - *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> - *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> - *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
> - *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> - *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> - *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> - */
> -
> -#include "mt7620a.dtsi"
> -
> -#include 
> -#include 
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +#include "mt7620a_zbtlink_we1026.dtsi"

I'd prefer an empty line between license and include here.

> diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_we1026.dtsi 
> b/target/linux/ramips/dts/mt7620a_zbtlink_we1026.dtsi
> new file mode 100644
> index 00..522a354305
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7620a_zbtlink_we1026.dtsi
> @@ -0,0 +1,99 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +#include "mt7620a.dtsi"

Same here.

[...]

> + {
> + ralink,mtd-eeprom = < 0>;

I'd change this to "0x0" for mere optical reasons.

Thanks for tidying up.

Best

Adrian 


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2 0/2] Add support for the ZBT WE1026-H

2019-09-24 Thread Kristian Evensen 
This patch series adds support for the ZBT WE1026-H, an outdoor AP with support
for adding an internal LTE modem. The first patch restructures the DTS files for
the WE0126-5G slightly and adds a WE1026 DTSI-file, containing descriptions of
the components that are shared between the WE0126-5G and the WE1026-H. The
second patch adds support for the WE1026-H.

The main change between v1 and v2 is the addition of acked-bys on the first
patch, triggered by the re-licensing of the DTS'.

Signed-off-by: Kristian Evensen 

Kristian Evensen (2):
  ramips: Update ZBT WE1026 DTS-files
  ramips: Add support for ZBT WE1026-H

 .../ramips/base-files/etc/board.d/01_leds |  5 +
 .../ramips/base-files/etc/board.d/02_network  |  6 +-
 .../dts/mt7620a_zbtlink_we1026-5g-16m.dts | 77 +--
 .../ramips/dts/mt7620a_zbtlink_we1026-5g.dtsi | 90 +
 .../dts/mt7620a_zbtlink_we1026-h-32m.dts  | 14 +++
 .../ramips/dts/mt7620a_zbtlink_we1026-h.dtsi  | 42 
 .../ramips/dts/mt7620a_zbtlink_we1026.dtsi| 99 +++
 target/linux/ramips/image/mt7620.mk   | 12 +++
 8 files changed, 186 insertions(+), 159 deletions(-)
 create mode 100644 target/linux/ramips/dts/mt7620a_zbtlink_we1026-h-32m.dts
 create mode 100644 target/linux/ramips/dts/mt7620a_zbtlink_we1026-h.dtsi
 create mode 100644 target/linux/ramips/dts/mt7620a_zbtlink_we1026.dtsi

-- 
2.20.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2 2/2] ramips: Add support for ZBT WE1026-H

2019-09-24 Thread Kristian Evensen 
This commit adds support for the ZBT WE1026-H, an outdoor AP with
support for adding an internal LTE modem. The detailed specs are:

* CPU: MT7620A
* 2x 10/100Mbps Ethernet (LAN port has passive PoE support).
* 16/32 MB Flash.
* 128/256 MB RAM.
* 1x USB 2.0 port.
* 1x mini-PCIe slot (only USB2.0 bus).
* 1x SIM slot (standard size).
* 1x 2.4Ghz WIFI (rt2800).
* 1x button.
* 6x LEDS (4 GPIO-controlled).
* 1x micro-SD reader.

The following have been tested and working:
- Ethernet switch
- Wifi
- Mini-PCIe slot + SIM slot
- USB port
- microSD slot
- sysupgrade
- reset button

Installation and recovery:

In order to install OpenWRT the first time or ito recover the router,
you can use the web-based recovery system. Keep the reset button pressed
during boot and access 192.168.1.1 in your browser when your machine
obtains an IP address. Upload the firmware to start the recovery
process.

Notes:

* The LED labeled "USB" is used as the power LED. When binding this LED
to a usbport, the LED is switched on all the time due to the presence of
an internal hub. Thus, it does not really signal any USB-information.

* I only have the 32MB version and have only added support for this
device. However, the files are structured so that adding support for the
16MB version should be easy.

* Only the LAN port is accessible from the outside of the casing and LEDs
are not visible.

v1->v2:
* Rebased on top of master.
* Read correct WAN address from flash (thanks Adrian Schmutzler).

Signed-off-by: Kristian Evensen 
---
 .../ramips/base-files/etc/board.d/01_leds |  5 +++
 .../ramips/base-files/etc/board.d/02_network  |  6 ++-
 .../dts/mt7620a_zbtlink_we1026-h-32m.dts  | 14 +++
 .../ramips/dts/mt7620a_zbtlink_we1026-h.dtsi  | 42 +++
 target/linux/ramips/image/mt7620.mk   | 12 ++
 5 files changed, 78 insertions(+), 1 deletion(-)
 create mode 100644 target/linux/ramips/dts/mt7620a_zbtlink_we1026-h-32m.dts
 create mode 100644 target/linux/ramips/dts/mt7620a_zbtlink_we1026-h.dtsi

diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds 
b/target/linux/ramips/base-files/etc/board.d/01_leds
index 46202b4117..3e12c2a947 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -461,6 +461,11 @@ zbtlink,zbt-we826-16m|\
 zbtlink,zbt-we826-32m)
set_wifi_led "zbt-we826:green:wifi"
;;
+zbtlink,we1026-h-32m)
+   set_wifi_led "we1026-h:green:wifi"
+   ucidef_set_led_switch "lan" "lan" "we1026-h:green:lan" "switch0" "0x8"
+   ucidef_set_led_switch "wan" "wan" "we1026-h:green:wan" "switch0" "0x10"
+   ;;
 zbtlink,zbt-we1226)
set_wifi_led "$boardname:green:wlan"
ucidef_set_led_switch "lan1" "LAN1" "$boardname:green:lan1" "switch0" 
"0x01"
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index 63644331e5..d94cd5fa98 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -272,7 +272,8 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"1:lan" "2:lan" "3:lan" "4:lan" "0:wan" "5@eth0"
;;
-   buffalo,wcr-1166ds)
+   buffalo,wcr-1166ds|\
+   zbtlink,we1026-h-32m)
ucidef_add_switch "switch0" \
"3:lan" "4:wan" "6@eth0"
;;
@@ -721,6 +722,9 @@ ramips_setup_macs()
wan_mac=$(mtd_get_mac_binary factory 0xe006)
label_mac=$(cat /sys/class/ieee80211/phy0/macaddress)
;;
+   zbtlink,we1026-h-32m)
+   wan_mac=$(mtd_get_mac_binary factory 0x2e)
+   ;;
*)
wan_mac=$(macaddr_add "$(cat /sys/class/net/eth0/address)" 1)
;;
diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_we1026-h-32m.dts 
b/target/linux/ramips/dts/mt7620a_zbtlink_we1026-h-32m.dts
new file mode 100644
index 00..ca62ccfc84
--- /dev/null
+++ b/target/linux/ramips/dts/mt7620a_zbtlink_we1026-h-32m.dts
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7620a_zbtlink_we1026-h.dtsi"
+
+/ {
+   compatible = "zbtlink,we1026-h-32m", "zbtlink,we1026-h",
+"zbtlink,we1026","ralink,mt7620a-soc";
+   model = "ZBT WE1026-H (32M)";
+};
+
+ {
+   reg = <0x5 0x1fb>;
+};
diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_we1026-h.dtsi 
b/target/linux/ramips/dts/mt7620a_zbtlink_we1026-h.dtsi
new file mode 100644
index 00..fed79c2809
--- /dev/null
+++ b/target/linux/ramips/dts/mt7620a_zbtlink_we1026-h.dtsi
@@ -0,0 +1,42 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7620a_zbtlink_we1026.dtsi"
+
+/ {
+   compatible = "zbtlink,we1026-h", "zbtlink,we1026",
+"ralink,mt7620a-soc";
+
+   aliases {
+

[OpenWrt-Devel] [PATCH v2 1/2] ramips: Update ZBT WE1026 DTS-files

2019-09-24 Thread Kristian Evensen 
This commit makes the following changes to the WE1026 DTS-files:

* The parts that are unique to the -5G-version (LED and 5GHz wifi)
are moved to a separate file, so that WE1026.dtsi can be referenced also
by the DTS for the -H version.
* Changed button from polled to interrupt.
* Use the generic "flash"-name for the spi-nor node.

All changes have been tested on the WE1026-5G-16M and work fine. I.e.,
the device works as before the DTS-changes.

v1->v2:
* Added missing acked-bys.

Signed-off-by: Kristian Evensen 
Acked-by: Mathias Kresin 
Acked-by: Alex Maclean 
Acked-by: INAGAKI Hiroshi 
Acked-by: Petr Štetiar 
---
 .../dts/mt7620a_zbtlink_we1026-5g-16m.dts | 77 +--
 .../ramips/dts/mt7620a_zbtlink_we1026-5g.dtsi | 93 +
 .../ramips/dts/mt7620a_zbtlink_we1026.dtsi| 99 +++
 3 files changed, 108 insertions(+), 161 deletions(-)
 create mode 100644 target/linux/ramips/dts/mt7620a_zbtlink_we1026.dtsi

diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_we1026-5g-16m.dts 
b/target/linux/ramips/dts/mt7620a_zbtlink_we1026-5g-16m.dts
index e2eb5b6329..0bb6812fcf 100644
--- a/target/linux/ramips/dts/mt7620a_zbtlink_we1026-5g-16m.dts
+++ b/target/linux/ramips/dts/mt7620a_zbtlink_we1026-5g-16m.dts
@@ -1,81 +1,14 @@
-/*
- *  BSD LICENSE
- *
- *  Copyright(c) 2017 Kristian Evensen .
- *  All rights reserved.
- *
- *  Redistribution and use in source and binary forms, with or without
- *  modification, are permitted provided that the following conditions
- *  are met:
- *
- ** Redistributions of source code must retain the above copyright
- *  notice, this list of conditions and the following disclaimer.
- ** Redistributions in binary form must reproduce the above copyright
- *  notice, this list of conditions and the following disclaimer in
- *  the documentation and/or other materials provided with the
- *  distribution.
- ** Neither the name of Broadcom Corporation nor the names of its
- *  contributors may be used to endorse or promote products derived
- *  from this software without specific prior written permission.
- *
- *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
- *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
- *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
- *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
- *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
- *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
- *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
- *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
- *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- */
-
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
 /dts-v1/;
 
 #include "mt7620a_zbtlink_we1026-5g.dtsi"
 
 / {
-   compatible = "zbtlink,we1026-5g-16m", "ralink,mt7620a-soc";
+   compatible = "zbtlink,we1026-5g-16m", "zbtlink,we1026-5g",
+"zbtlink,we1026", "ralink,mt7620a-soc";
model = "ZBT WE1026-5G (16M)";
 };
 
- {
-   status = "okay";
-
-   en25q128@0 {
-   compatible = "jedec,spi-nor";
-   reg = <0>;
-   spi-max-frequency = <1000>;
-
-   partitions {
-   compatible = "fixed-partitions";
-   #address-cells = <1>;
-   #size-cells = <1>;
-
-   partition@0 {
-   label = "u-boot";
-   reg = <0x0 0x3>;
-   read-only;
-   };
-
-   partition@3 {
-   label = "u-boot-env";
-   reg = <0x3 0x1>;
-   read-only;
-   };
-
-   factory: partition@4 {
-   label = "factory";
-   reg = <0x4 0x1>;
-   read-only;
-   };
-
-   firmware: partition@5 {
-   compatible = "denx,uimage";
-   label = "firmware";
-   reg = <0x5 0xfb>;
-   };
-   };
-   };
+ {
+   reg = <0x5 0xfb>;
 };
diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_we1026-5g.dtsi 
b/target/linux/ramips/dts/mt7620a_zbtlink_we1026-5g.dtsi
index e7e64e251a..b90179fe1f 100644
--- a/target/linux/ramips/dts/mt7620a_zbtlink_we1026-5g.dtsi
+++ b/target/linux/ramips/dts/mt7620a_zbtlink_we1026-5g.dtsi
@@ -1,47 +1,9 @@
-/*
- *  BSD LICENSE
- *
- *  Copyright(c)

Re: [OpenWrt-Devel] [ramips] Linkit Smart 7688 and libmraa

2019-09-24 Thread Ivan Hörler 
Hi
I opend a issue in the mraa git repo and got some new information about why and 
where libmraa breaks.
It seams related to a change in the system. At some point openWRT must have 
dropped  or changed some parts of `/dev/mem`.
This now makes libmraa break and maybe not only for my target.
Im not the C dev that can handel such a thing. 
May somebody with C knowledge have a minute to look in to it and tell me what 
possibilities i have and how many targets possibly are affected by this?
https://github.com/intel-iot-devkit/mraa/issues/983 

Thanks, Ivan 

> Am 20.09.2019 um 15:10 schrieb Ivan Hörler :
> 
> I tried to compile the package libmraa as single and have some problems with 
> the dependencies:
> 
> Followed this: https://openwrt.org/docs/guide-developer/single.package 
> 
> First i searched for all dependencies:
> 
> root@OpenWrt:/# opkg info libmraa
> Package: libmraa
> Version: 2.0.0-2
> Depends: libc, libstdcpp6, libjson-c4
> Status: install user installed
> Section: libs
> Architecture: mipsel_24kc
> Size: 64409
> Filename: libmraa_2.0.0-2_mipsel_24kc.ipk
> 
> root@OpenWrt:/# opkg info libc
> Package: libc
> Version: 1.1.23-2
> Depends: libgcc1
> Status: install hold installed
> Essential: yes
> Architecture: mipsel_24kc
> Installed-Time: 1568571183
> 
> then i tried to make menuconfig so i can tick the dependencies but i did not 
> find the dependencie of libc named libgcc1. 
> A try to compile after installing tools and toolchain fails as well:
> 
> novski@ubuntu:~/Documents/openwrt$ make package/libgcc1/compile V=s
> make[1]: Entering directory '/home/novski/Documents/openwrt'
> make[1]: *** No rule to make target 'package/libgcc1/compile'.  Stop.
> make[1]: Leaving directory '/home/novski/Documents/openwrt'
> /home/novski/Documents/openwrt/include/toplevel.mk:216: recipe for target 
> 'package/libgcc1/compile' failed
> make: *** [package/libgcc1/compile] Error 2
> 
> Why do i not find the dependency libgcc1 in 'make menuconfig' search (/)?
> 
> Thanks, Ivan 
> 
> 
>> Am 19.09.2019 um 20:18 schrieb Ivan Hörler > >:
>> 
>> Hi
>> I have problems makeing libmraa working on Linkit Smart 7688.
>> The installation worked without problems and i tested with a python script. 
>> See details below:
>> 
>> what i did: 
>> - Compiled a openWRT 18.6
>> - opkg update 
>> - opkg install libmraa
>> - opkg install python3-light
>> - opkg install libmraa-python3
>> 
>> - copied this skript to /root: 
>> 
>> import mraa
>> import time
>> 
>> try:
>> print (mraa.getVersion())
>> except:
>> print("no mraa available")
>> 
>> # Refer to the pin-out digram for the GPIO number to silk print mapping
>> # in this example the number 44 maps to Wi-Fi LED.
>> pin = mraa.Gpio(2)
>> pin.dir(mraa.DIR_OUT)
>> while True:
>> pin.write(1)
>> time.sleep(1)
>> pin.write(0)
>> time.sleep(1)
>> 
>> - and executed:
>> root@OpenWrt:~# python3 mraa-test-simple.py 
>> v2.0.0
>> Traceback (most recent call last):
>>   File "mraa-test-simple.py", line 11, in 
>> pin = mraa.Gpio(2)
>>   File "/usr/lib/python3.7/site-packages/mraa.py", line 391, in __init__
>> _mraa.Gpio_swiginit(self, _mraa.new_Gpio(pin, owner, raw))
>> ValueError: Invalid GPIO pin specified
>> 
>> 
>> - checked with a LED on pin2 like this if GPIO2 works:
>> root@OpenWrt:~# cd /sys/class/gpio/
>> root@OpenWrt:/sys/class/gpio# ls
>> export  gpiochip0   gpiochip32  gpiochip64  unexport
>> root@OpenWrt:/sys/class/gpio# echo 2 > export
>> root@OpenWrt:/sys/class/gpio# ls
>> export  gpio2   gpiochip0   gpiochip32  gpiochip64  unexport
>> root@OpenWrt:/sys/class/gpio# cd gpio2
>> root@OpenWrt:/sys/devices/platform/1000.palmbus/1600.gpio/gpiochip0/gpio/gpio2#
>>  echo "out" > direction
>> root@OpenWrt:/sys/devices/platform/1000.palmbus/1600.gpio/gpiochip0/gpio/gpio2#
>>  cat value
>> 0
>> root@OpenWrt:/sys/devices/platform/1000.palmbus/1600.gpio/gpiochip0/gpio/gpio2#
>>  echo 1 > value
>> 
>> - redone previous step with no changes in error output.
>> 
>> what am i missing?
>> 
>> Thanks for comments, Ivan Hörler
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org 
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [Suggestions] Streamline localization by using Weblate for the project, use LiberaPay or OpenCollective to enable people to donate

2019-09-24 Thread Paul Spooren 

Hi Scott,

On 23.09.19 16:15, Scott via openwrt-devel wrote:

First and foremost, as a user of OpenWrt and LuCI by way of TurrisOS thanks for 
everyone who has contributed to OpenWrt. As someone who's seeking to give back 
to the project via localization I noticed that while OpenWrt has relatively 
straightforward documentation on contributing localization 
(https://github.com/openwrt/luci/wiki/i18n), the process could be streamlined a 
great deal more. In particular by using Weblate thus making easier it for those 
who don't know Git and providing significant quality of life improvements even 
for those who do know Git. Those who want to do offline localization could 
continue to do so w/o issue.

For those who aren't familiar with localization, Weblate is basically a web 
based tool that allows to contribute by simply entering in a localized string 
and hitting 'suggest' rather than having to Git clone, download an offline 
client like Lokalize, and then make a PR. There's also a good number of nice 
things to improve localization. It's easy to visually see what languages need 
localization work, you can be notified when there's new strings or a few other 
trigger events, and you can utilize not only the 'translation memory' of 
OpenWrt itself, but other FOSS such as related routing projects like Foris. The 
great thing is that while you can self host your own Weblate server, because 
OpenWrt is FOSS, the folk behind Weblate would likely offer free hosting given 
their Gratis for libre projects pricing. To better see what I'm talking about 
in action please check out:https://hosted.weblate.org/projects/


I think that's a good idea! As it doesn't need to be directly integrated 
in any existing workflow nor requires privileges on any Git, it's 
basically just a fancy front-end with translation suggestions for .po 
files right?


Out of curiosity I requested a libre account for a quick evaluation, if 
anyone is in serious doubt on evaluation it I'll instantly cancel the 
request. However I think this is in line with 
https://openwrt.org/meetings/hamburg2019/start#luci_translations



As a secondary note in what sounds like was written in late 2016, there were 
private discussions about public crowdfunding to help pay for servers 
(https://openwrt.org/infrastructure). Talking with tmomas on the forums it 
sounds like the current bottleneck is people power. Any surplus donations 
beyond infrastructure could be used to pay for part or full time development or 
for bounties. Between the LiberaPay and OpenCollective, OpenCollective may be 
preferable because it is designed to allow both reoccurring and one off 
donations.


Also a nice idea, I heard a couple of times people want to donate but 
there is no convenient way to do so. Having some funding for 
rpcd-doc-writing or a simplified web interface would be great!


Maybe jow can come up with a comment on this, I remember there were some 
issues on how to manage the money in an organizational way...


Best,
Paul


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ipq40xx: remove redundant ucidef_set_interfaces_* in 02_network

2019-09-24 Thread David Bauer 
Hello Adrian,

On 9/23/19 3:34 PM, Adrian Schmutzler wrote:
>   qxwlan,e2600ac-c1 |\
>   qxwlan,e2600ac-c2)
> - ucidef_set_interfaces_lan_wan "eth0" "eth1"
>   ucidef_add_switch "switch0" \
>   "0u@eth0" "3:lan" "4:lan" "0u@eth1" "5:wan"
>   ;;

While from the coding it looks like multiple cpu port distribution is supported,
I'm not sure if this is handled correctly for untagged ports.

Furthermore, the switch initialization is a bit "messed up", as the mapping 
between
external phy <-> ess-switch <--> cpu interfaces is not very obvious.

1) All devices with eth1 interface have it utilize the 5th PHY (displayed
as switchport 5)
2) All devices with a QCA8072 utilize PHY 4 (displayed as switchport 4) for eth0
3) Devices using an RGMII attached PHY (currently only MR33) do not have a 
switch-construct.

So if we really want to clean this up correctly, there are some more things to 
consider
(which also brings the opportunity to simplify this further). Also, the first 
point gives
you the opportunity to test the dual-untagged-cpuport on another ipq40xx 
device. :)

On the other hand there's ipqess and qca8k on the horizon to end the ar40xx 
mess.
But i don't think this is a showstopper for this.

Best wishes
David

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel