date:20190823

Re: [OpenWrt-Devel] Squashfs breakage lottery with UBI WAS: [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24

2019-08-23 Thread Russell Senior

> "Russell" == Russell Senior  writes:

> "Christian" == Christian Lamparter  writes:

Russell> It's mostly inferred from the fact that I saw the error and
Russell> kernel panic, and glancing at the kernel squashfs code. I am
Russell> not pretending to understand completely how the squashfs kernel
Russell> code works, but the position of the error relative to the size
Russell> of the rootfs in my panic case strongly suggests it was trying
Russell> to read past the end of the ubi volume.

Oh, and I got important help finding this from Jonas Gorski. I was
remiss in not mentioning that.

-- 
Russell Senior, President
russ...@personaltelco.net

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

Re: [OpenWrt-Devel] Squashfs breakage lottery with UBI WAS: [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24

2019-08-23 Thread Russell Senior

> "Christian" == Christian Lamparter  writes:

> I've posted a similar message to the bugreport:
> 

I should have filed the bug first and linked it in my patch.

> What's happening here is that mksquashfs4 is being told
> through the "-nopad" option to "do not pad filesystem to a
> multiple of 4K" [0].

> |define Image/mkfs/squashfs |
> $(STAGING_DIR_HOST)/bin/mksquashfs4 $(call
> mkfs_target_dir,$(1)) $@ \ | -nopad -noappend -root-owned \ |
> -comp $(SQUASHFSCOMP) $(SQUASHFSOPT) \ | -processors 1 |endef

> My guess is that this affects more than just the MR24 (I'm
> looking at you too: pad2jffs and various pad-to $value)
> . I've tried tracking down the change that added the "-nopad"
> and found it in a commit from 2005 titled: "add some changes
> from whiterussian to head" [1] [2]:

I agree that other devices where rootfs is squashfs and lives on a ubi
volume are probaby also vulnerable to this problem. Regrettably, I haven't
thought of any other of those devices that I have on hand to test. 

> | $(KDIR)/root.squashfs: | @mkdir -p $(KDIR)/root/jffs |-
> $(STAGING_DIR)/bin/mksquashfs-lzma $(KDIR)/root $@ -noappend
> -root-owned -le |+ $(STAGING_DIR)/bin/mksquashfs-lzma
> $(KDIR)/root $@ -nopad -noappend -root-owned -le

> So, this is really old...

> Question is, should we just drop the -nopad? Since as you
> established, in the described corner-case (see above)
> squashfs needs this 4k padding and the generated squashfs
> could be considered broken otherwise?

I'm under the impression that the -nopad makes sense for NOR flash where
the kernel and rootfs are glued together, padding the isolated rootfs
would cause alignment problems or wasted space in the combined blobs.

> (Judging from your
> message, you went through the kernel code. Can you please
> share the place where the lack of the padding is breaking the
> fs?)

It's mostly inferred from the fact that I saw the error and kernel
panic, and glancing at the kernel squashfs code. I am not pretending to
understand completely how the squashfs kernel code works, but the
position of the error relative to the size of the rootfs in my panic
case strongly suggests it was trying to read past the end of the ubi
volume.

The error comes in the kernel's fs/squashfs/block.c in the
squashfs_read_data() function. There are a bunch of conditions (at least
5) within the function (see "goto read_failure;") that will lead to that
message being printed.

-- 
Russell Senior, President
russ...@personaltelco.net

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

[OpenWrt-Devel] [lantiq] help in supporting FRITZ!BOX 3272 (Fritz_Box_HW198))

2019-08-23 Thread Enrico Mioso


Sat, 24 Aug 2019 01:14:40 +0200 (CEST)ear OpenWRt list,
I was looking at trying to add support to the FRITZ!BOX 3272 to OpenWRt.
It is based on the Lantiq AR10 platform - for which I wasn't able to find any 
informations, even tought I see kernel code to support it is already available.

From where may I start ?

E.g.: is there any similar devices or places I might start looking?

I see there is EVA - I ad only a minimal experience with ADAM so any hint on 
useful commands would be good. I guess I may also GET the flash partitions with 
an FTP client?

Attached the bootlog of the device via UART, where you can see it has two flash 
chips: a NOR for boot I guess, and a NAND for the OS.
Thanks!!

reboot
starting pid 1414, tty '/dev/ttyS0': '/bin/sh -c /var/post_install'
# telefon: SIGTERM received!
stopping USB-Subsystem ..
killall: printserv: no process killed
ls: /var/USB-*-bus-usb-*: No such file or directory
USB-Subsystem .. stopped
stopping WLAN ...
rc.wlan: Stop WLAN...
WLAND_CTL:wland_hello_response: hello response, status: 0, user_data: (nil), 
version: 257
WLAND_CTL:wland_ctl exit (rc = 0)
WLAN ... stopped
ls: /proc/1198/fd: No such file or directory
ls: /proc/1201/fd: No such file or directory
unmounting '/var/media/ftp/*' ..
[1415]++ ++ do internalflash 'prepare unmount'... ++ ++
ls: /proc/1607/cwd: No such file or directory
[1415]++ ++ ...done ++ ++
unmounting '/var/dev/nand' ..
unload dsl and dependend driver ..
[dsl_sds] stopping ar10 dsl
[dsl_sds] killing ar10 dsl processes
[dsl_sds] stop oamd...
[dsl_sds] oamd stopped
[dsl_sds] check if dsl_control is running
[dsl_sds] exit dsl_control...


- Start supportlog: -
01:00:29: open
WLAND:[01092]:01:00.29/[29.59]:derived config 'AP off', ID: 5 (0x)
WLAND:[01092]:01:36.38/[2198.24]:Unload 'libwlanrext'((nil))
WLAND:[01092]:01:36.38/[2198.24]:util_deinit:28: ENTER
- End supportlog -

AVM safe quit dsl_control
turn off autoboot...

quit dsl_control...

[dsl_sds] dsl_control exited
[dsl_sds] killed ar10 dsl processes
[dsl_sds] invoke notify_avmnet_hw_exit
[dsl_sds] stop dsl_monitor
/etc/init.d/e40-dsl: line 61: syntax error: unterminated quoted string
+ ps
+ grep -v grep
+ grep -q dtrace
+ lsmod
Module  Size  Used byTainted: P 
userman_mod88438  2 
krtp  147669  0 
kdsldmod 1907296  7 userman_mod
drv_dsl_cpe_api   334726  0 
ifxmips_mei3  1 drv_dsl_cpe_api
ifxusb_host   112960  0 
usbcore   173244  2 ifxusb_host
capi_codec433638  0 
isdn_fbox_fon5838358  2 krtp

pcmlink   416391  3 capi_codec,isdn_fbox_fon5
rtc_avm 5880  1 pcmlink
led_modul_Fritz_Box_HW198   110703  4 
+ echo stopping modules using ubik2/pcmlink ..

stopping modules using ubik2/pcmlink ..
+ lsmod
+ grep -q ulpcmlink
+ lsmod
+ grep -q dect_io
+ lsmod
+ grep -q avm_dect
+ lsmod
+ grep -q pcmlink
+ rmmod pcmlink
rmmod: can't unload 'pcmlink': Resource temporarily unavailable
+ set +x
still running:
  PID USER   VSZ STAT COMMAND
1 root  1312 Sinit
2 root 0 SW   [kthreadd]
3 root 0 SW   [migration/0]
4 root 0 SW   [ksoftirqd/0]
5 root 0 SW   [watchdog/0]
6 root 0 SW   [migration/1]
7 root 0 SW   [ksoftirqd/1]
8 root 0 SW   [watchdog/1]
9 root 0 SW   [yield_w/0]
   10 root 0 SW   [yield_w/1]
   11 root 0 SW   [events/0]
   12 root 0 SW   [events/1]
   13 root 0 SW   [khelper]
   16 root 0 SW   [async/mgr]
   33 root 0 SW   [sync_supers]
   34 root 0 SW   [bdi-default]
   36 root 0 SW   [kblockd/0]
   37 root 0 SW   [kblockd/1]
   56 root 0 SW   [kswapd0]
   57 root 0 SWN  [ksmd]
   58 root 0 SW   [aio/0]
   59 root 0 SW   [aio/1]
   73 root 0 SW   [pm_info]
   80 root 0 SWN  [avm_debugd]
  106 root 0 SW   [mtdblockd]
  117 root 0 DW   [ifx_ssc]
  128 root 0 SW   [l2tp]
  132 root 0 SW   [tffsd]
  133 root 0 SW   [avmnet_workqueu]
  138 root 0 SW   [avmnet_timer]
  140 root 0 SW<  [loop0]
  180 root 0 SW   [yaffs-bg-1]
  270 root 0 SW   [cleanup_timer_f]
  367 root 0 SW   [capi_pipew/0]
  368 root 0 SW   [capi_pipew/1]
  369 root 0 SW   [capi_schedw/0]
  370 root 0 SW   [capi_schedw/1]
  371 root 0 SW   [pcmlink_ctrl/1]
  372 root 0 SW   [capitransp]
  444 root  1308 Stail -f /nohup.out
  448 root  1332 S <  /sbin/udevd --daemon
  461 root 0 SW   [khubd]
  655 root  1308 S <  /sbin/udevd --daemon
  656 root  1308 S <  /sbin/udevd --daemon
  744 root  2444 S/bin/configd
  768 root  3304 Savmipcd
  871 root  4492 Sdsl_monitor -d
  882 root 0 DW   [pmex_ne]
  883 root 0 DW   [pmex_fe]
 1004 root  4048

[OpenWrt-Devel] [RFC PATCH 2/2] apm821xx: utilize softoff on the MyBook Live Series

2019-08-23 Thread Christian Lamparter

This was a requested feature on the forum some long time ago.
The original vendor firmware from Western Digital allowed the
device to enter a shutdown-like state and remain there
indefinitely.

Because OpenWrt sets the platform's nowayout watchdog, this
device will reboot after some time even when poweroff gets
called and the kernel supposed to just do its infinite loop
thing.

With this somewhat universal "softoff" the device will be
able to enter a similar-but-different shutdown-like state
with the HDDs in a safer standby mode so it can be moved
and disconnected.

Signed-off-by: Christian Lamparter 
---
 target/linux/apm821xx/image/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/target/linux/apm821xx/image/Makefile 
b/target/linux/apm821xx/image/Makefile
index acfd478755..82e84f72f9 100644
--- a/target/linux/apm821xx/image/Makefile
+++ b/target/linux/apm821xx/image/Makefile
@@ -230,7 +230,8 @@ ifeq ($(SUBTARGET),sata)
 define Device/wd_mybooklive
   DEVICE_VENDOR := Western Digital
   DEVICE_MODEL := My Book Live Series (Single + Duo)
-  DEVICE_PACKAGES := kmod-usb-dwc2 kmod-usb-ledtrig-usbport kmod-usb-storage 
kmod-fs-vfat wpad-basic
+  DEVICE_PACKAGES := kmod-usb-dwc2 kmod-usb-ledtrig-usbport kmod-usb-storage \
+kmod-fs-vfat wpad-basic softoff
   DEVICE_TYPE := nas
   DEVICE_DTS := wd-mybooklive
   SUPPORTED_DEVICES += mbl wd,mybooklive-duo
-- 
2.23.0


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

[OpenWrt-Devel] [RFC PATCH 1/2] softoff: add softoff utility

2019-08-23 Thread Christian Lamparter

The softoff package replaces the poweroff command with a
scripts that utilize the existing sysupgrade code to perform
a "soft" poweroff (in a way that the device is no longer
responsive). So this makes it safer to disconnect and
be moved.

By design, sysupgrade already stops services and closes
any running application, as well as unmounts any active
partition.
This scripts piggybacks on what's provided by sysupgrade,
but also puts all active SATA/SCSI/UAS/USB-attached HDDs
into standby by telling the kernel they are no longer
needed (and the kernel will do the rest) and tries to
switch all available LEDs to the off state (the trigger
"none" will only switch off managed LEDs) before causes
the device to enter a infinite loop.

This works especially well with embedded devices without a
real poweroff method (many SoC platform drivers just map
the shutdown() to reset()) or suffer because the platform
has a no-way-out watchdog that can trigger a hardware
reboot which can bring the device out of its "poweroff"
state.

Signed-off-by: Christian Lamparter 
---
 package/utils/softoff/Makefile  | 36 +
 package/utils/softoff/files/softoff | 36 +
 2 files changed, 72 insertions(+)
 create mode 100644 package/utils/softoff/Makefile
 create mode 100644 package/utils/softoff/files/softoff

diff --git a/package/utils/softoff/Makefile b/package/utils/softoff/Makefile
new file mode 100644
index 00..28930e9bde
--- /dev/null
+++ b/package/utils/softoff/Makefile
@@ -0,0 +1,36 @@
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=softoff
+PKG_RELEASE:=1
+PKG_LICENSE:=GPL-2.0
+PKG_MAINTAINER:=Christian Lamparter 
+
+include $(INCLUDE_DIR)/package.mk
+
+define Package/softoff
+   PKGARCH:=all
+   SECTION:=utils
+   CATEGORY:=Utilities
+   TITLE:=softoff utility
+endef
+
+define Package/softoff/description
+  the softoff package replaces the poweroff command with scripts that
+  utilize the sysupgrade code to perform a "softer" poweroff.
+  The script will try to close any running application, unmount any active
+  partition as well as putting any connected HDD to standby (for shutdown).
+  This allows embedded devices with out a working poweroff method to become
+  unavailable.
+endef
+
+define Build/Compile
+   true
+endef
+
+define Package/softoff/install-overlay
+   $(INSTALL_DIR)  $(1)/sbin
+   $(INSTALL_BIN)  ./files/softoff $(1)/sbin/softoff
+   $(LN) softoff $(1)/sbin/poweroff
+endef
+
+$(eval $(call BuildPackage,softoff))
diff --git a/package/utils/softoff/files/softoff 
b/package/utils/softoff/files/softoff
new file mode 100644
index 00..e25bdba8f2
--- /dev/null
+++ b/package/utils/softoff/files/softoff
@@ -0,0 +1,36 @@
+#!/bin/sh
+
+. /lib/functions.sh
+. /lib/functions/system.sh
+. /lib/upgrade/common.sh
+
+case "$1" in
+stage2)
+   for dev in /sys/block/sd*[a-z]; do
+   [ -d "$dev" ] && echo "1" > "$dev/device/delete"
+   done
+
+   for led in /sys/class/leds/*; do
+   [ -d "$led" ] && {
+   echo "none" > "$led/trigger"
+   echo "0" > "$led/brightness"
+   }
+   done
+
+   while :; do
+   sleep 1;
+   done
+   ;;
+*)
+   install_bin /sbin/upgraded
+   install_bin "$0"
+
+   ifdown -a
+
+   ubus call system sysupgrade "{
+   \"prefix\": $(json_string "$RAM_ROOT"),
+   \"path\": $(json_string "badfile"),
+   \"command\": $(json_string "$0 stage2")
+   }"
+   ;;
+esac
-- 
2.23.0


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

[OpenWrt-Devel] Squashfs breakage lottery with UBI WAS: [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24

2019-08-23 Thread Christian Lamparter

On Thursday, August 22, 2019 1:00:21 PM CEST Russell Senior wrote:
> 
> Using pad-squashfs ensures that the root.squashfs is assigned sufficient
> LEBs on UBI such that all reads of the rootfs succeed, in order to avoid
> read failures and kernel panics.
> 
> This fixes one such kernel panic observed on Meraki MR24 where an
> inopportune-sized unpadded root.squashfs occurred.
> 
> Note: ext4-sysupgrade firmware binaries will build with this patch, but
> they are as nonsensical as before the patch. Finding a way to disable
> ext4 builds for Meraki MR24 is left as a TODO.
> 
> Signed-off-by: Russell Senior 
> ---
>  target/linux/apm821xx/image/Makefile | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/target/linux/apm821xx/image/Makefile 
> b/target/linux/apm821xx/image/Makefile
> index acfd478755..53192bb448 100644
> --- a/target/linux/apm821xx/image/Makefile
> +++ b/target/linux/apm821xx/image/Makefile
> @@ -133,7 +133,8 @@ define Device/meraki_mr24
>IMAGE_SIZE := 8191k
>KERNEL := kernel-bin | lzma | uImage lzma | MerakiAdd-dtb | MerakiNAND
>KERNEL_INITRAMFS := kernel-bin | lzma | dtb | MuImage-initramfs lzma
> -  IMAGE/sysupgrade.bin := sysupgrade-tar | append-metadata
> +  IMAGE/sysupgrade.bin/squashfs := pad-squashfs | sysupgrade-tar | 
> append-metadata
> +  IMAGE/sysupgrade.bin/ext4 := sysupgrade-tar | append-metadata
>UBINIZE_OPTS := -E 5
>SUPPORTED_DEVICES += mr24
>  endef
> 

I've posted a similar message to the bugreport:


What's happening here is that mksquashfs4 is being told through the "-nopad" 
option
to "do not pad filesystem to a multiple of 4K" [0].

|define Image/mkfs/squashfs
|$(STAGING_DIR_HOST)/bin/mksquashfs4 $(call mkfs_target_dir,$(1)) $@ \
|-nopad -noappend -root-owned \
|-comp $(SQUASHFSCOMP) $(SQUASHFSOPT) \
|-processors 1
|endef

My guess is that this affects more than just the MR24 (I'm looking at you too:
pad2jffs and various pad-to $value) . I've tried tracking down the change that
added the "-nopad" and found it in a commit from 2005 titled:
"add some changes from whiterussian to head" [1] [2]:

| $(KDIR)/root.squashfs:
|@mkdir -p $(KDIR)/root/jffs
|-   $(STAGING_DIR)/bin/mksquashfs-lzma $(KDIR)/root $@ -noappend 
-root-owned -le
|+   $(STAGING_DIR)/bin/mksquashfs-lzma $(KDIR)/root $@ -nopad -noappend 
-root-owned -le


So, this is really old... 

Question is, should we just drop the -nopad? Since as you established, in
the described corner-case (see above) squashfs needs this 4k padding and
the generated squashfs could be considered broken otherwise?
(Judging from your message, you went through the kernel code. Can you
please share the place where the lack of the padding is breaking the fs?)

Cheers,
Christian

[0] 

[1] 

[2] 




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

[OpenWrt-Devel] [PATCH] uqmi: separate into libuqmi library and uqmi util itself

2019-08-23 Thread Denis Kalashnikov

It is needed to reuse qmi code, e.g. in a modem manager util
which is useful on routers with several cell modems.

Signed-off-by: Denis Kalashnikov 

---
 package/network/utils/uqmi/Makefile   | 25 +-
 .../utils/uqmi/patches/1-libuqmi.patch| 46 +++
 2 files changed, 70 insertions(+), 1 deletion(-)
 create mode 100644 package/network/utils/uqmi/patches/1-libuqmi.patch

diff --git a/package/network/utils/uqmi/Makefile 
b/package/network/utils/uqmi/Makefile
index dee4bd051e..49386c9f7a 100644
--- a/package/network/utils/uqmi/Makefile
+++ b/package/network/utils/uqmi/Makefile
@@ -24,7 +24,7 @@ define Package/uqmi
   SECTION:=net
   CATEGORY:=Network
   SUBMENU:=WWAN
-  DEPENDS:=+libubox +libblobmsg-json +kmod-usb-net +kmod-usb-net-qmi-wwan +wwan
+  DEPENDS:=+libubox +libblobmsg-json +kmod-usb-net +kmod-usb-net-qmi-wwan 
+wwan +libuqmi
   TITLE:=Control utility for mobile broadband modems
 endef
 
@@ -33,6 +33,17 @@ define Package/uqmi/description
   the QMI-protocol.
 endef
 
+define Package/libuqmi
+  SECTION:=libs
+  CATEGORY:=Libraries
+  DEPENDS:=+libubox +kmod-usb-net +kmod-usb-net-qmi-wwan +wwan
+  TITLE:=Control library for mobile broadband modems
+endef
+
+define Package/libuqmi/description
+ Shared library for controlling mobile broadband modems using the QMI-protocol.
+endef
+
 TARGET_CFLAGS += \
-I$(STAGING_DIR)/usr/include -ffunction-sections -fdata-sections
 
@@ -41,10 +52,22 @@ TARGET_LDFLAGS += -Wl,--gc-sections
 CMAKE_OPTIONS += \
-DDEBUG=1
 
+define Build/InstallDev
+   $(INSTALL_DIR) $(STAGING_DIR)/usr/include/libuqmi
+   $(CP) $(PKG_BUILD_DIR)/*.h $(STAGING_DIR)/usr/include/libuqmi
+   $(CP) $(PKG_BUILD_DIR)/libuqmi.so $(STAGING_DIR)/usr/lib
+endef
+
 define Package/uqmi/install
$(INSTALL_DIR) $(1)/sbin
$(INSTALL_BIN) $(PKG_BUILD_DIR)/uqmi $(1)/sbin/
$(CP) ./files/* $(1)/
 endef
 
+define Package/libuqmi/install
+   $(INSTALL_DIR) $(1)/usr/lib
+   $(CP) $(PKG_BUILD_DIR)/libuqmi.so $(1)/usr/lib
+endef
+
 $(eval $(call BuildPackage,uqmi))
+$(eval $(call BuildPackage,libuqmi))
diff --git a/package/network/utils/uqmi/patches/1-libuqmi.patch 
b/package/network/utils/uqmi/patches/1-libuqmi.patch
new file mode 100644
index 00..b17aecb078
--- /dev/null
+++ b/package/network/utils/uqmi/patches/1-libuqmi.patch
@@ -0,0 +1,46 @@
+Index: uqmi-2019-06-27-1965c713/CMakeLists.txt
+===
+--- uqmi-2019-06-27-1965c713.orig/CMakeLists.txt
 uqmi-2019-06-27-1965c713/CMakeLists.txt
+@@ -8,7 +8,8 @@ ADD_DEFINITIONS(-Os -ggdb -Wall -Werror
+ 
+ SET(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS "")
+ 
+-SET(SOURCES main.c dev.c commands.c qmi-message.c mbim.c)
++SET(SOURCES main.c commands.c)
++SET(LIB_SOURCES dev.c qmi-message.c mbim.c)
+ 
+ FIND_PATH(ubox_include_dir libubox/usock.h)
+ FIND_PATH(blobmsg_json_include_dir libubox/blobmsg_json.h)
+@@ -61,11 +62,15 @@ ADD_CUSTOM_COMMAND(
+ ADD_CUSTOM_TARGET(gen-errors DEPENDS qmi-errors.c)
+ ADD_CUSTOM_TARGET(gen-headers DEPENDS ${service_headers})
+ 
+-ADD_EXECUTABLE(uqmi ${SOURCES} ${service_sources})
++ADD_LIBRARY(uqmi SHARED ${LIB_SOURCES} ${service_sources})
+ ADD_DEPENDENCIES(uqmi gen-headers gen-errors)
+ 
+-TARGET_LINK_LIBRARIES(uqmi ${LIBS})
++ADD_EXECUTABLE(uqmi_bin ${SOURCES})
++TARGET_LINK_LIBRARIES(uqmi_bin ${LIBS} uqmi)
++SET_TARGET_PROPERTIES(uqmi_bin PROPERTIES OUTPUT_NAME uqmi)
+ 
+-INSTALL(TARGETS uqmi
++INSTALL(TARGETS uqmi_bin
+   RUNTIME DESTINATION sbin
+ )
++
++INSTALL(TARGETS uqmi LIBRARY DESTINATION /usr/lib)
+Index: uqmi-2019-06-27-1965c713/dev.c
+===
+--- uqmi-2019-06-27-1965c713.orig/dev.c
 uqmi-2019-06-27-1965c713/dev.c
+@@ -353,8 +353,6 @@ int qmi_device_open(struct qmi_dev *qmi,
+   struct ustream *us = >sf.stream;
+   int fd;
+ 
+-  uloop_init();
+-
+   fd = open(path, O_RDWR | O_EXCL | O_NONBLOCK | O_NOCTTY);
+   if (fd < 0)
+   return -1;
-- 
2.19.2


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

[OpenWrt-Devel] Questions about IPv6 and NDP-Proxy

2019-08-23 Thread Fernando Frediani


Hello

I have seen on some old OpenWrt documentation 
(https://openwrt.org/docs/guide-user/network/ipv6/start#router_advertisement_dhcpv6) 
that by default when the router cannot receive a IPv6 Prefix Delegation 
(IPv6-PD) but only an IPv6 in the WAN it can automatically detect it and 
act as a NDP-Proxy so the clients in the LAN interface have IPv6 
connectivity.


I have tested it and was unable to observe this behavior without 
changing any configurations. If however I configured both the LAN and 
WAN6 interfaces as DHCPv6, RA and NDP in Relay mode plus WAN6 with 
'option master 1' then it works as expected.


Does anyone know if this automated behavior is expected or if in these 
cases it is always necessary to configured the interfaces in such way to 
make that work ?


This is useful as many people inadvertently connects the LAN port of a 
home router to a WAN port of a second router in order to extend signal 
and by using this technique allows that users connected to the secondary 
routers to keep IPv6 connectivity.


Thanks
Fernando


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

[OpenWrt-Devel] [PATCH v2 5/7] ath79: image: add supported string for routerstations and ja76pf2

2019-08-23 Thread Tomasz Maciej Nowak

Now that the md5 check is fixed and metadata present, sysupgrade on
ar71xx will complain about device not being supported by the image.
Since the cause is not matching strings for supported devices add them
accordingly.

Signed-off-by: Tomasz Maciej Nowak 
---
 target/linux/ath79/image/generic-ubnt.mk | 2 ++
 target/linux/ath79/image/generic.mk  | 1 +
 2 files changed, 3 insertions(+)

diff --git a/target/linux/ath79/image/generic-ubnt.mk 
b/target/linux/ath79/image/generic-ubnt.mk
index 3af1f2676e..c696aac3a8 100644
--- a/target/linux/ath79/image/generic-ubnt.mk
+++ b/target/linux/ath79/image/generic-ubnt.mk
@@ -223,6 +223,7 @@ define Device/ubnt_routerstation
   UBNT_TYPE := RSx
   UBNT_CHIP := ar7100
   DEVICE_PACKAGES += -swconfig
+  SUPPORTED_DEVICES += routerstation
 endef
 TARGET_DEVICES += ubnt_routerstation
 
@@ -232,6 +233,7 @@ define Device/ubnt_routerstation-pro
   UBNT_BOARD := RSPRO
   UBNT_TYPE := RSPRO
   UBNT_CHIP := ar7100pro
+  SUPPORTED_DEVICES += routerstation-pro
 endef
 TARGET_DEVICES += ubnt_routerstation-pro
 
diff --git a/target/linux/ath79/image/generic.mk 
b/target/linux/ath79/image/generic.mk
index c1cd347baf..b4e709de3e 100644
--- a/target/linux/ath79/image/generic.mk
+++ b/target/linux/ath79/image/generic.mk
@@ -648,6 +648,7 @@ define Device/jjplus_ja76pf2
   KERNEL := kernel-bin | append-dtb | lzma | pad-to $$(BLOCKSIZE)
   KERNEL_INITRAMFS := kernel-bin | append-dtb
   IMAGE_SIZE := 16000k
+  SUPPORTED_DEVICES += ja76pf2
 endef
 TARGET_DEVICES += jjplus_ja76pf2
 
-- 
2.23.0


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

[OpenWrt-Devel] [PATCH v2 6/7] ath79: fix FIS partition detection for 4.19 kernel

2019-08-23 Thread Tomasz Maciej Nowak

When bumping to 4.19 the patch responsible for scaning flash for FIS
partition got left out. Without it devices with RedBoot bootloader using
automatic partitions detection in dts won't boot with the new kernel.

Fixes: 3771176 ("ath79: add support for linux 4.19")
Signed-off-by: Tomasz Maciej Nowak 
---
 .../408-mtd-redboot_partition_scan.patch  | 44 +++
 1 file changed, 44 insertions(+)
 create mode 100644 
target/linux/ath79/patches-4.19/408-mtd-redboot_partition_scan.patch

diff --git 
a/target/linux/ath79/patches-4.19/408-mtd-redboot_partition_scan.patch 
b/target/linux/ath79/patches-4.19/408-mtd-redboot_partition_scan.patch
new file mode 100644
index 00..cd41e7ceb2
--- /dev/null
+++ b/target/linux/ath79/patches-4.19/408-mtd-redboot_partition_scan.patch
@@ -0,0 +1,44 @@
+--- a/drivers/mtd/redboot.c
 b/drivers/mtd/redboot.c
+@@ -76,12 +76,18 @@ static int parse_redboot_partitions(stru
+   static char nullstring[] = "unallocated";
+ #endif
+ 
++  buf = vmalloc(master->erasesize);
++  if (!buf)
++  return -ENOMEM;
++
++ restart:
+   if ( directory < 0 ) {
+   offset = master->size + directory * master->erasesize;
+   while (mtd_block_isbad(master, offset)) {
+   if (!offset) {
+   nogood:
+   printk(KERN_NOTICE "Failed to find a non-bad 
block to check for RedBoot partition table\n");
++  vfree(buf);
+   return -EIO;
+   }
+   offset -= master->erasesize;
+@@ -94,10 +100,6 @@ static int parse_redboot_partitions(stru
+   goto nogood;
+   }
+   }
+-  buf = vmalloc(master->erasesize);
+-
+-  if (!buf)
+-  return -ENOMEM;
+ 
+   printk(KERN_NOTICE "Searching for RedBoot partition table in %s at 
offset 0x%lx\n",
+  master->name, offset);
+@@ -170,6 +172,11 @@ static int parse_redboot_partitions(stru
+   }
+   if (i == numslots) {
+   /* Didn't find it */
++  if (offset + master->erasesize < master->size) {
++  /* not at the end of the flash yet, maybe next block :) 
*/
++  directory++;
++  goto restart;
++  }
+   printk(KERN_NOTICE "No RedBoot partition table detected in 
%s\n",
+  master->name);
+   ret = 0;
-- 
2.23.0


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

[OpenWrt-Devel] [PATCH v2 4/7] ath79: image: append metadata to routerstations and ja76pf2 images

2019-08-23 Thread Tomasz Maciej Nowak

This target enforces metadata check so add the necessary information. It
was previously removed because md5 sum check. When using these sysupgrade
images on ar71xx target the check would complain about them not matching.

Signed-off-by: Tomasz Maciej Nowak 
---
 target/linux/ath79/image/generic-ubnt.mk | 2 +-
 target/linux/ath79/image/generic.mk  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/target/linux/ath79/image/generic-ubnt.mk 
b/target/linux/ath79/image/generic-ubnt.mk
index 6db083861f..3af1f2676e 100644
--- a/target/linux/ath79/image/generic-ubnt.mk
+++ b/target/linux/ath79/image/generic-ubnt.mk
@@ -210,7 +210,7 @@ define Device/ubnt_routerstation_common
   IMAGE_SIZE := 16128k
   IMAGES += factory.bin
   IMAGE/factory.bin := append-rootfs | pad-rootfs | mkubntimage | check-size 
(IMAGE_SIZE)
-  IMAGE/sysupgrade.bin := append-rootfs | pad-rootfs | combined-image | 
check-size (IMAGE_SIZE)
+  IMAGE/sysupgrade.bin := append-rootfs | pad-rootfs | combined-image | 
append-metadata | check-size (IMAGE_SIZE)
 #  IMAGE/sysupgrade.bin := append-rootfs | pad-rootfs | check-size 
(IMAGE_SIZE) | sysupgrade-tar rootfs=@ | append-metadata
   KERNEL := kernel-bin | append-dtb | lzma | pad-to $$(BLOCKSIZE)
   KERNEL_INITRAMFS := kernel-bin | append-dtb
diff --git a/target/linux/ath79/image/generic.mk 
b/target/linux/ath79/image/generic.mk
index 45a1baa632..c1cd347baf 100644
--- a/target/linux/ath79/image/generic.mk
+++ b/target/linux/ath79/image/generic.mk
@@ -643,7 +643,7 @@ define Device/jjplus_ja76pf2
   DEVICE_VENDOR := jjPlus
   DEVICE_MODEL := JA76PF2
   DEVICE_PACKAGES += -kmod-ath9k -swconfig -wpad-mini -uboot-envtools fconfig
-  IMAGE/sysupgrade.bin := append-rootfs | pad-rootfs | combined-image | 
check-size (IMAGE_SIZE)
+  IMAGE/sysupgrade.bin := append-rootfs | pad-rootfs | combined-image | 
append-metadata | check-size (IMAGE_SIZE)
 #  IMAGE/sysupgrade.bin := append-rootfs | pad-rootfs | check-size 
(IMAGE_SIZE) | sysupgrade-tar rootfs=@ | append-metadata
   KERNEL := kernel-bin | append-dtb | lzma | pad-to $$(BLOCKSIZE)
   KERNEL_INITRAMFS := kernel-bin | append-dtb
-- 
2.23.0


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

[OpenWrt-Devel] [PATCH v2 7/7] ath79: image: disable sysupgrade images for routerstations and ja76pf2

2019-08-23 Thread Tomasz Maciej Nowak

Because a bug in handling partial erase blocks in 4.19 kernel, using
sysupgrade images will hard brick devices that use RedBoot bootloader
and have "FIS directory" with "RedBoot config" on the same erase block.
Since flashing the devices from bootloader is safe, and to not cause a
situation where external chip programmer or JTAG is needed, disable
sysupgrade images for affected boards while creating kernel.bin and
rootfs.bin for jjPlus JA76PF2 board, which doesn't have factory image.

To set up the JA76PF2 board follow "Installation" instructions in b3a0c97
("ath79: add support for jjPlus JA76PF2") except the part of loading
initramfs image and using sysupgrade image for flashing (point 6 and 7).
Enter following commands to flash the board from bootloader:
  fis init
  load -r -b 0x8006 
  fis create linux
  load -r -b %{FREEMEMLO} 
  fis create rootfs
  fis load -l linux
  exec -c ""

For RouterStations use TFTP recovery procedure.

Ref: FS#2428
Cc: Matt Merhar 
Signed-off-by: Tomasz Maciej Nowak 
---
 target/linux/ath79/image/generic-ubnt.mk | 4 +---
 target/linux/ath79/image/generic.mk  | 5 +++--
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/target/linux/ath79/image/generic-ubnt.mk 
b/target/linux/ath79/image/generic-ubnt.mk
index c696aac3a8..368da8e01b 100644
--- a/target/linux/ath79/image/generic-ubnt.mk
+++ b/target/linux/ath79/image/generic-ubnt.mk
@@ -208,10 +208,8 @@ define Device/ubnt_routerstation_common
   DEVICE_VENDOR := Ubiquiti
   ATH_SOC := ar7161
   IMAGE_SIZE := 16128k
-  IMAGES += factory.bin
+  IMAGES := factory.bin
   IMAGE/factory.bin := append-rootfs | pad-rootfs | mkubntimage | check-size 
(IMAGE_SIZE)
-  IMAGE/sysupgrade.bin := append-rootfs | pad-rootfs | combined-image | 
append-metadata | check-size (IMAGE_SIZE)
-#  IMAGE/sysupgrade.bin := append-rootfs | pad-rootfs | check-size 
(IMAGE_SIZE) | sysupgrade-tar rootfs=@ | append-metadata
   KERNEL := kernel-bin | append-dtb | lzma | pad-to $$(BLOCKSIZE)
   KERNEL_INITRAMFS := kernel-bin | append-dtb
 endef
diff --git a/target/linux/ath79/image/generic.mk 
b/target/linux/ath79/image/generic.mk
index b4e709de3e..eca1f80947 100644
--- a/target/linux/ath79/image/generic.mk
+++ b/target/linux/ath79/image/generic.mk
@@ -643,8 +643,9 @@ define Device/jjplus_ja76pf2
   DEVICE_VENDOR := jjPlus
   DEVICE_MODEL := JA76PF2
   DEVICE_PACKAGES += -kmod-ath9k -swconfig -wpad-mini -uboot-envtools fconfig
-  IMAGE/sysupgrade.bin := append-rootfs | pad-rootfs | combined-image | 
append-metadata | check-size (IMAGE_SIZE)
-#  IMAGE/sysupgrade.bin := append-rootfs | pad-rootfs | check-size 
(IMAGE_SIZE) | sysupgrade-tar rootfs=@ | append-metadata
+  IMAGES := kernel.bin rootfs.bin
+  IMAGE/kernel.bin := append-kernel
+  IMAGE/rootfs.bin := append-rootfs | pad-rootfs
   KERNEL := kernel-bin | append-dtb | lzma | pad-to $$(BLOCKSIZE)
   KERNEL_INITRAMFS := kernel-bin | append-dtb
   IMAGE_SIZE := 16000k
-- 
2.23.0


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

[OpenWrt-Devel] [PATCH v2 0/7] ath79: fixes for devices with RedBoot bootloader

2019-08-23 Thread Tomasz Maciej Nowak

Few fixes with common denominator being RedBoot bootloader, mostly
related to images generation. Some of these will need a cherry-pick to
19.07 branch - I'll prepare the patches if theese will be commited.
I would like to also put some focus on FS#2428 [1] bug, which will
disable sysupgrade for few devices and which I don't have knowledge to
tackle. Hope someone will help.

1. https://bugs.openwrt.org/index.php?do=details_id=2428

Changes in v2:
- remove also sysupgrade image recipes instead of only disabling them, as
  requested by Adrian Schmutzler in:
  "ath79: image: disable sysupgrade images for routerstations and
  ja76pf2"

Tomasz Maciej Nowak (7):
  ath79: dts: fix ja76pf2 spi frequency
  ath79: image: retire combined-image for Adtran/Bluesocket devices
  ar71xx: sysupgrade: accept ath79 combined-image
  ath79: image: append metadata to routerstations and ja76pf2 images
  ath79: image: add supported string for routerstations and ja76pf2
  ath79: fix FIS partition detection for 4.19 kernel
  ath79: image: disable sysupgrade images for routerstations and ja76pf2

 .../ar71xx/base-files/lib/upgrade/platform.sh |  2 +-
 .../linux/ath79/dts/ar7161_jjplus_ja76pf2.dts |  2 +-
 target/linux/ath79/image/generic-ubnt.mk  |  6 +--
 target/linux/ath79/image/generic.mk   |  8 ++--
 .../408-mtd-redboot_partition_scan.patch  | 44 +++
 5 files changed, 54 insertions(+), 8 deletions(-)
 create mode 100644 
target/linux/ath79/patches-4.19/408-mtd-redboot_partition_scan.patch

-- 
2.23.0


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

[OpenWrt-Devel] [PATCH v2 3/7] ar71xx: sysupgrade: accept ath79 combined-image

2019-08-23 Thread Tomasz Maciej Nowak

There is md5 sum of whole image embedded in combined-image header which
is checked on sysupgrade. The check will fail for ath79 images which
may have embedded metadata. This is because metadata are appended after
the combined image is created. To allow smooth transition from ar71xx to
ath79, strip metadata before calculating md5 sum for whole image.

Signed-off-by: Tomasz Maciej Nowak 
---
 target/linux/ar71xx/base-files/lib/upgrade/platform.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh 
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 6898c0e0c2..3853140702 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -394,7 +394,7 @@ platform_check_image() {
}
 
local md5_img=$(dd if="$1" bs=2 skip=9 count=16 2>/dev/null)
-   local md5_chk=$(dd if="$1" bs=$CI_BLKSZ skip=1 2>/dev/null | 
md5sum -); md5_chk="${md5_chk%% *}"
+   local md5_chk=$(fwtool -q -t -i /dev/null "$1"; dd if="$1" 
bs=$CI_BLKSZ skip=1 2>/dev/null | md5sum -); md5_chk="${md5_chk%% *}"
 
if [ -n "$md5_img" -a -n "$md5_chk" ] && [ "$md5_img" = 
"$md5_chk" ]; then
return 0
-- 
2.23.0


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

[OpenWrt-Devel] [PATCH v2 2/7] ath79: image: retire combined-image for Adtran/Bluesocket devices

2019-08-23 Thread Tomasz Maciej Nowak

During review it slipped by that these devices use combined-image which
should never be used for newly added ones. Therefore switch to
sysupgrade-tar generated images introduced in 8f6f260 ("ath79:
routerstation: prepare to use sysupgrade-tar format image"). The
sysupgrade accepts both images for now so no reression should occur.

Cc: Brian Gonyer 
Cc: Daniel Gimpelevich 
Signed-off-by: Tomasz Maciej Nowak 
---
 target/linux/ath79/image/generic.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/ath79/image/generic.mk 
b/target/linux/ath79/image/generic.mk
index 6f1ad5b708..45a1baa632 100644
--- a/target/linux/ath79/image/generic.mk
+++ b/target/linux/ath79/image/generic.mk
@@ -108,7 +108,7 @@ define Device/adtran_bsap1880
   IMAGES += kernel.bin rootfs.bin
   IMAGE/kernel.bin := append-kernel | pad-to (BLOCKSIZE)
   IMAGE/rootfs.bin := append-rootfs | pad-rootfs
-  IMAGE/sysupgrade.bin := append-rootfs | pad-rootfs | combined-image | 
append-metadata | check-size (IMAGE_SIZE)
+  IMAGE/sysupgrade.bin := append-rootfs | pad-rootfs | check-size 
(IMAGE_SIZE) | sysupgrade-tar rootfs=@ | append-metadata
 endef
 
 define Device/adtran_bsap1800-v2
-- 
2.23.0


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

[OpenWrt-Devel] [PATCH v2 1/7] ath79: dts: fix ja76pf2 spi frequency

2019-08-23 Thread Tomasz Maciej Nowak

The frequency was filled acording the information from datasheet for
particular chip (Winbond 25Q128BVFG). Unfortunately this led to
coruption and introduced bad blocks on the chip. Reducing the frequency
to commonly used in ath79, made the board more stable and no new bad
blocks were spoted.

Fixes: b3a0c97 ("ath79: add support for jjPlus JA76PF2")
Signed-off-by: Tomasz Maciej Nowak 
---
 target/linux/ath79/dts/ar7161_jjplus_ja76pf2.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/ath79/dts/ar7161_jjplus_ja76pf2.dts 
b/target/linux/ath79/dts/ar7161_jjplus_ja76pf2.dts
index 76f140fa55..b983d1b994 100644
--- a/target/linux/ath79/dts/ar7161_jjplus_ja76pf2.dts
+++ b/target/linux/ath79/dts/ar7161_jjplus_ja76pf2.dts
@@ -111,7 +111,7 @@
flash@0 {
compatible = "jedec,spi-nor";
reg = <0>;
-   spi-max-frequency = <10400>;
+   spi-max-frequency = <2500>;
 
partitions {
#address-cells = <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] ath79: add support for gl-ar750

2019-08-23 Thread Chuanhong Guo

Hi!

On Fri, Aug 23, 2019 at 5:08 PM Luochongjun  wrote:
>
> This patch supports gl-ar750, which was previously supported by ar71xx.
>
> Specification:
> - SOC: QCA9531 (650MHz)
> - Flash: 16 MiB (W25Q128FVSG)
> - RAM: 128 MiB DDR2
> - Ethernet: 10/100: 2xLAN + 10/100: 1xWAN
> - Wireless: 2.4GHz (bgn) and 5GHz (ac)
> - USB: 1x USB 2.0 port
> - Switch: 1x switch
> - Button: 1x reset button
> - LED: 3x LEDS (white)
>
> Flash instruction:
> Support for sysupgrade directive upgrades, as well as luci upgrades.
>
> Signed-off-by: Luochongjun 
> ---

Merged into my staging tree at:
https://git.openwrt.org/?p=openwrt/staging/981213.git
Thanks!

Regards,
Chuanhong Guo

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

Re: [OpenWrt-Devel] [PATCH v2] ramips: use gpio_hog instead of gpio-exp

2019-08-23 Thread Kristian Evensen

Hi,

On Fri, Aug 23, 2019 at 1:40 PM Birger Koblitz  wrote:
>
> ramips: use gpio_hog instead of gpio-export
>
> The `gpio-export` functionality is a hack for
> missing kernel functionality, which was rejected in upstream kernel long
> time
> ago, for details see this email
> http://lists.infradead.org/pipermail/openwrt-devel/2019-February/015772.html,
> discussion in PR#1366 or
> https://github.com/openwrt/openwrt/pull/1814#issuecomment-462942022.
>
> This patch converts all ramips .dts(i) files which were
> using export-gpio for powering USB/SATA ports to using gpio_hog instead

While clean-ups are nice, the patch in its current form will break a
lot of functionality that users depend on. By changing for example the
D240 power_mpcieX nodes to gpio-hog, it is no longer possible to
power-cycle the devices inserted in these slots. Power-cycling is for
example convenient when recovering LTE-modems that have crashed/hung
due to firmware bugs. While I am not familiar with some of the other
devices, I suspect a lot of the nodes names "power_usb" or similar
have the same functionality.

I would start by moving the GPIOs used for power-control of USB to
03_gpio_switches and then take a look at the GPIOs that are left. This
probably requires going through the commits adding support for the
different devices.

BR,
Kristian

BR,
Kristian

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

Re: [OpenWrt-Devel] Cannot compile cryptodev-linux using x86-64 SDK

2019-08-23 Thread Jeffery To

On Sat, Aug 17, 2019 at 2:25 AM Jeffery To  wrote:

> As the subject of this email says, I get an error when trying to compile
> cryptodev-linux using the x86-64 SDK. (Though a different error than the
> one I found with the armvirt-64 SDK.)
>
> This error has been happening for a while, at least a month. (I haven't
> had time to follow up until now.) I suspect this is also related to the
> switch to the 4.19 kernel, though I have no direct evidence.
>
> The error message (included below) doesn't seem too helpful. Any help in
> fixing this would be appreciated.
>

This is still happening with the latest snapshot SDK. I'm not asking for
someone to fix this for me, but I'm not familiar enough with Kbuild to know
what is missing for the SDK target.

(Honestly, I work around this issue by using the SDK of another arch for my
package testing, but I would like to get this fixed anyway.)

Any pointers or other help would be greatly appreciated.

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

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

2019-08-23 Thread Birger Koblitz

ramips: add support for Asus RT-AC85P

SoC:MediaTek MT7621AT dual-core @ 880MHz
RAM:256M (Winbond W632GG6KB-1)
FLASH:  128MB (Macronix MX30LF1G18AC-TI)
WiFi:   - 2.4GHz MediaTek MT7615N bgn
- 5GHz MediaTek MT7615N nac
Switch: SoC integrated Gigabit Switch (4 x LAN, 1 x WAN)
USB:1 x USB 3.1 (Gen 1)
BTN:Reset, WPS
LED:- Power (blue)
- 5Ghz (blue)
- 2.4GHz (blue)
- Internet (blue)
- 4x LAN (blue)
(LAN/WAN leds are not controllable by GPIOs)
UART:   UART is present as Pads marked J4 on the PCB.
3.3V - TX - RX - GND / 57600-8N1
3.3V is the square pad
MAC:The MAC address on the router-label matches the MAC of
the 2.4 GHz WiFi.
LAN and WAN MAC are identical: MAC_LABEL+4
5 GHz WiFi MAC: also MAC_LABEL+4


Installation

Via U-Boot tftpd:
Switch on device, within 2s press reset button and keep pressed
until power LED starts blinking slowly.
Upload factory image via tftp put, the router's ip is 192.168.1.1
and expects the client on 192.168.1.75.

The images also work on the Asus RT-AC65P models as tested by Gabor.

Signed-off-by: Birger Koblitz 
Tested-by: Gabor Varga 

---

v2: Corrected sorting of entries in 02_network
Model name corrected in .dts
Whitespace fixes in .dts
wifi0/1 labels added to wifi nodes in .dts
Device name capitalized in mt7621.mk

v3: Added firmware backup to firmware2 partition before sysupgrade
Corrected modules included in image

v4: Corrected MT7615N PCI IDs

v5: Fixed indentation in platform.sh

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 2f9a02256e..ab90041d92 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -231,6 +231,17 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"0:lan" "1:wan" "6@eth0"
;;
+   asus,rt-ac85p|\
+   dlink,dir-860l-b1|\
+   elecom,wrc-1167ghbk2-s|\
+   elecom,wrc-1900gst|\
+   elecom,wrc-2533gst|\
+   huawei,hg255d|\
+   iodata,wn-ax1167gr|\
+   iodata,wn-gx300gr)
+   ucidef_add_switch "switch0" \
+   "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "0:wan" "6@eth0"
+   ;;
asus,rt-n15|\
belkin,f9k1109v1|\
sitecom,wl-351)
@@ -298,16 +309,6 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"0:lan:4" "1:lan:3" "2:lan:2" "3:lan:1" "4:wan:5" 
"6@eth0"
;;
-   dlink,dir-860l-b1|\
-   elecom,wrc-1167ghbk2-s|\
-   elecom,wrc-1900gst|\
-   elecom,wrc-2533gst|\
-   huawei,hg255d|\
-   iodata,wn-ax1167gr|\
-   iodata,wn-gx300gr)
-   ucidef_add_switch "switch0" \
-   "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "0:wan" "6@eth0"
-   ;;
dlink,dwr-118-a1)
ucidef_add_switch "switch0" \
"1:lan:2" "2:lan:3" "3:lan:1" "4:lan:0" "5:wan" "6@eth0"
@@ -531,6 +532,9 @@ ramips_setup_macs()
lan_mac=$(mtd_get_mac_binary factory 57344)
wan_mac=$(mtd_get_mac_binary factory 57350)
;;
+   asus,rt-ac85p)
+   wan_mac=$(mtd_get_mac_ascii u-boot-env et1macaddr)
+   ;;
asus,rt-n56u)
lan_mac=$(macaddr_setbit_la "$(cat 
/sys/class/net/eth0/address)")
wan_mac=$(mtd_get_mac_binary factory 32772)
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index a65492a309..cd9d8ae650 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -18,9 +18,16 @@ platform_do_upgrade() {
mikrotik,rbm33g)
[ -z "$(rootfs_type)" ] && mtd erase firmware
;;
+   asus,rt-ac85p)
+   echo "Backing up firmware"
+   dd if=/dev/mtd4 bs=1024 count=4096  > /tmp/backup_firmware.bin
+   dd if=/dev/mtd5 bs=1024 count=52224 >> /tmp/backup_firmware.bin
+   mtd -e firmware2 write /tmp/backup_firmware.bin firmware2
+   ;;
esac

case "$board" in
+   asus,rt-ac85p|\
hiwifi,hc5962|\
netgear,r6220|\
netgear,r6350|\
diff --git a/target/linux/ramips/dts/mt7621_asus_rt-ac85p.dts
b/target/linux/ramips/dts/mt7621_asus_rt-ac85p.dts
new file mode 100644
index 00..7aea207fad
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_asus_rt-ac85p.dts
@@ -0,0 +1,164 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7621.dtsi"
+
+#include 
+#include 
+
+/ {
+   compatible = "asus,rt-ac85p", "mediatek,mt7621-soc";
+   model = "Asus RT-AC85P";
+
+   aliases {
+

[OpenWrt-Devel] [PATCH v2] ramips: use gpio_hog instead of gpio-exp

2019-08-23 Thread Birger Koblitz

ramips: use gpio_hog instead of gpio-export

The `gpio-export` functionality is a hack for
missing kernel functionality, which was rejected in upstream kernel long
time
ago, for details see this email
http://lists.infradead.org/pipermail/openwrt-devel/2019-February/015772.html,
discussion in PR#1366 or
https://github.com/openwrt/openwrt/pull/1814#issuecomment-462942022.

This patch converts all ramips .dts(i) files which were
using export-gpio for powering USB/SATA ports to using gpio_hog instead

Signed-off-by: Birger Koblitz 

---

v2: Limited conversion to only usb ports/hubs and sata

diff --git a/target/linux/ramips/dts/mt7620a_asus_rt-ac51u.dts
b/target/linux/ramips/dts/mt7620a_asus_rt-ac51u.dts
index 3e54ffdad2..c573b38284 100644
--- a/target/linux/ramips/dts/mt7620a_asus_rt-ac51u.dts
+++ b/target/linux/ramips/dts/mt7620a_asus_rt-ac51u.dts
@@ -53,16 +53,16 @@
linux,code = ;
};
};
+};

-   gpio_export {
-   compatible = "gpio-export";
-   #size-cells = <0>;
+ {
+   status = "okay";

-   enable-leds {
-   gpio-export,name = "enable-leds";
-   gpio-export,output = <1>;
-   gpios = < 10 GPIO_ACTIVE_HIGH>;
-   };
+   enable-leds {
+   gpio-hog;
+   line-name = "enable-leds";
+   gpios = <10 GPIO_ACTIVE_HIGH>;
+   output-high;
};
 };

diff --git a/target/linux/ramips/dts/mt7620a_dlink_dwr-118-a1.dts
b/target/linux/ramips/dts/mt7620a_dlink_dwr-118-a1.dts
index 707bc1c3d3..7af90c6908 100644
--- a/target/linux/ramips/dts/mt7620a_dlink_dwr-118-a1.dts
+++ b/target/linux/ramips/dts/mt7620a_dlink_dwr-118-a1.dts
@@ -63,21 +63,17 @@
linux,default-trigger = "usbport";
};
};
-
-   gpio_export {
-   compatible = "gpio-export";
-   #size-cells = <0>;
-
-   usb {
-   gpio-export,name = "usb";
-   gpio-export,output = <0>;
-   gpios = < 14 GPIO_ACTIVE_LOW>;
-   };
-   };
 };

  {
status = "okay";
+
+   usb {
+   gpio-hog;
+   line-name = "usb";
+   gpios = <14 GPIO_ACTIVE_LOW>;
+   output-low;
+   };
 };

  {
diff --git a/target/linux/ramips/dts/mt7620a_dlink_dwr-118-a2.dts
b/target/linux/ramips/dts/mt7620a_dlink_dwr-118-a2.dts
index 26b23aa6d1..17ec47b9d5 100644
--- a/target/linux/ramips/dts/mt7620a_dlink_dwr-118-a2.dts
+++ b/target/linux/ramips/dts/mt7620a_dlink_dwr-118-a2.dts
@@ -61,21 +61,17 @@
linux,default-trigger = "usbport";
};
};
-
-   gpio_export {
-   compatible = "gpio-export";
-   #size-cells = <0>;
-
-   usb {
-   gpio-export,name = "usb";
-   gpio-export,output = <1>;
-   gpios = < 14 GPIO_ACTIVE_HIGH>;
-   };
-   };
 };

  {
status = "okay";
+
+   usb {
+   gpio-hog;
+   line-name = "usb";
+   gpios = <14 GPIO_ACTIVE_HIGH>;
+   output-high;
+   };
 };

  {
diff --git a/target/linux/ramips/dts/mt7620a_dovado_tiny-ac.dts
b/target/linux/ramips/dts/mt7620a_dovado_tiny-ac.dts
index e36af1dc7f..acb3524e3d 100644
--- a/target/linux/ramips/dts/mt7620a_dovado_tiny-ac.dts
+++ b/target/linux/ramips/dts/mt7620a_dovado_tiny-ac.dts
@@ -39,16 +39,16 @@
linux,code = ;
};
};
+};

-   gpio_export {
-   compatible = "gpio-export";
-   #size-cells = <0>;
+ {
+   status = "okay";

-   usbpower {
-   gpio-export,name = "usbpower";
-   gpio-export,output = <1>;
-   gpios = < 5 GPIO_ACTIVE_HIGH>;
-   };
+   usbpower {
+   gpio-hog;
+   line-name = "usbpower";
+   gpios = <5 GPIO_ACTIVE_HIGH>;
+   output-high;
};
 };

@@ -56,10 +56,6 @@
status = "okay";
 };

- {
-   status = "okay";
-};
-
  {
status = "okay";
 };
diff --git a/target/linux/ramips/dts/mt7620a_edimax_br-6478ac-v2.dts
b/target/linux/ramips/dts/mt7620a_edimax_br-6478ac-v2.dts
index 5c90aa1549..d329c3380c 100644
--- a/target/linux/ramips/dts/mt7620a_edimax_br-6478ac-v2.dts
+++ b/target/linux/ramips/dts/mt7620a_edimax_br-6478ac-v2.dts
@@ -66,22 +66,17 @@
linux,default-trigger = "usbport";
};
};
-
-
-   gpio_export {
-   compatible = "gpio-export";
-   #size-cells = <0>;
-   usb-power {
-   gpio-export,name="usb-power";
-   gpio-export,output=<1>;
-   gpios = < 5 GPIO_ACTIVE_HIGH>;
-   };
-   };
 };

-

Re: [OpenWrt-Devel] [PATCH v4] ramips: add support for Asus RT-AC85P

2019-08-23 Thread mail

Hi,

> a/target/linux/ramips/base-files/lib/upgrade/platform.sh
> b/target/linux/ramips/base-files/lib/upgrade/platform.sh
> index a65492a309..cd9d8ae650 100755
> --- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
> @@ -18,9 +18,16 @@ platform_do_upgrade() {
>   mikrotik,rbm33g)
>   [ -z "$(rootfs_type)" ] && mtd erase firmware
>   ;;
> +   asus,rt-ac85p)

Wrong indent here.

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 v3] ramips: add Asus RT-AC85P

2019-08-23 Thread Gábor Varga

Hi!

Birger Koblitz  ezt írta (időpont: 2019. aug. 23.,
P, 11:56):

> Hi,
>
> On 23.08.19 11:04, Gábor Varga wrote:
> > Hi!
> >
> > Although it looks like the Asus RT-AC85P and the Asus RT-AC65P models
> > are identical, but I have separated them into two dts and have
> > introduced the HW version into the names (for the new versions in the
> > future).
>
> Are you sure that is necessary? AFAIK there are no different versions of
> the routers around and Asus seems to have a policy of constantly
> churning out new router models without upgrading existing routers to new
> revisions.


I introduced the HW revision because according to the Asus specification
the two routers should be different at least at the radio hardware. Maybe
Asus can't buy only temporarily MT7615S and MT7615B radios, and fix this in
the next hardware release. Otherwise the Asus has more routers with same
name and different HW version with fully different hardware. For example:
RT-N10 rev A1 has a BroadCom SoC, the rev. C1 has a RaLink SoC.
Or you mean, why have I separated the two models? I have made this, because
with only one dts the model of the router under OpenWrt would be in both
case Asus RT-AC85P.


> >
> > I have an alternative installation method 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-r01-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-r01-squashfs-factory.bin -d
> linux
> > 6. Reboot the router
> >  > reboot
> >
> > Another thing: I don't know, if it's good method to replace the second
> > firmware partition with OpenWrt image during sysupgrade. When we don't
> > do that, than we have always a factory firmware on the secondary
> > firmware partition, so the back to the factory firmware would be much
> > easier.
>
> I don't have a strong opinion on this. Both ways have their advantages.
> If during sysupgrade both copies of the FW are written, then this is
> consistent with the original software's behavior and additionally, the
> outcome is independent of the OpenWRT initial installation method. When
> using tftp (or the Web-GUI should someone figure out the exact format)
> both copies are written, only ssh and serial port allow to install only
> one copy. Not copying over the previous OpenWRT image to the second
> partition during sysupgrade allows having a copy of the factory firmware
> around (but which needs to be written to the first partition again to be
> booted).
>

I don't know what is the best option. But, when we leave the second
partition untouched, than the user go back to the factory firmware, when he
write only one block to the firmware partition (and the checksum will be
wrong, so the bootloader overwrites the first partition with the second
one.

Cheers,

Gabor Varga

>
> ___
> 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] [RFC]remove outdated targets from snapshots

2019-08-23 Thread Paul Spooren


Hi,

various targets at OpenWrt/snapshots[0] are no longer build and cause 
(at least for me) from time to time some trouble. Would it be possible 
to add a cron job removing all files from snapshots/ which are older 
than, a week? The folder is not intented as an archive, right?


Sunshine,
    Paul

[0]: https://downloads.openwrt.org/snapshots/targets/


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

Re: [OpenWrt-Devel] [PATCH v3] ramips: add Asus RT-AC85P

2019-08-23 Thread Birger Koblitz

Hi,

On 23.08.19 11:04, Gábor Varga wrote:
> Hi!
>
> Although it looks like the Asus RT-AC85P and the Asus RT-AC65P models
> are identical, but I have separated them into two dts and have
> introduced the HW version into the names (for the new versions in the
> future).

Are you sure that is necessary? AFAIK there are no different versions of
the routers around and Asus seems to have a policy of constantly
churning out new router models without upgrading existing routers to new
revisions.

>
> I have an alternative installation method 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-r01-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-r01-squashfs-factory.bin -d linux
> 6. Reboot the router
>  > reboot
>
> Another thing: I don't know, if it's good method to replace the second
> firmware partition with OpenWrt image during sysupgrade. When we don't
> do that, than we have always a factory firmware on the secondary
> firmware partition, so the back to the factory firmware would be much
> easier.

I don't have a strong opinion on this. Both ways have their advantages.
If during sysupgrade both copies of the FW are written, then this is
consistent with the original software's behavior and additionally, the
outcome is independent of the OpenWRT initial installation method. When
using tftp (or the Web-GUI should someone figure out the exact format)
both copies are written, only ssh and serial port allow to install only
one copy. Not copying over the previous OpenWRT image to the second
partition during sysupgrade allows having a copy of the factory firmware
around (but which needs to be written to the first partition again to be
booted).

Cheers,

  Birger

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

[OpenWrt-Devel] [PATCH v2] ath79: add support for gl-ar750

2019-08-23 Thread Luochongjun

This patch supports gl-ar750, which was previously supported by ar71xx.

Specification:
- SOC: QCA9531 (650MHz)
- Flash: 16 MiB (W25Q128FVSG)
- RAM: 128 MiB DDR2
- Ethernet: 10/100: 2xLAN + 10/100: 1xWAN
- Wireless: 2.4GHz (bgn) and 5GHz (ac)
- USB: 1x USB 2.0 port
- Switch: 1x switch
- Button: 1x reset button
- LED: 3x LEDS (white)

Flash instruction:
Support for sysupgrade directive upgrades, as well as luci upgrades.

Signed-off-by: Luochongjun 
---
 .../linux/ath79/base-files/etc/board.d/02_network  |   5 +
 .../etc/hotplug.d/firmware/11-ath10k-caldata   |   1 +
 target/linux/ath79/dts/qca9531_glinet_gl-ar750.dts | 142 +
 target/linux/ath79/image/generic.mk|  10 ++
 4 files changed, 158 insertions(+)
 create mode 100644 target/linux/ath79/dts/qca9531_glinet_gl-ar750.dts

diff --git a/target/linux/ath79/base-files/etc/board.d/02_network 
b/target/linux/ath79/base-files/etc/board.d/02_network
index cb0853e..454f57d 100755
--- a/target/linux/ath79/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/base-files/etc/board.d/02_network
@@ -156,6 +156,11 @@ ath79_setup_interfaces()
etactica,eg200)
ucidef_set_interface_lan "eth0" "dhcp"
;;
+   glinet,gl-ar750)
+   ucidef_set_interface_wan "eth1"
+   ucidef_add_switch "switch0" \
+   "0@eth0" "1:lan" "2:lan"
+   ;;
glinet,gl-ar750s)
ucidef_add_switch "switch0" \
"0@eth0" "2:lan:2" "3:lan:1" "1:wan"
diff --git 
a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata 
b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 421fb7d..ed34322 100644
--- a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -122,6 +122,7 @@ case "$FIRMWARE" in
ath10kcal_extract "art" 0x5000 0x844
ath10kcal_patch_mac $(macaddr_add $(cat 
/sys/class/net/eth0/address) +1)
;;
+   glinet,gl-ar750|\
glinet,gl-ar750s)
ath10kcal_extract "art" 0x5000 0x844
ath10kcal_patch_mac $(macaddr_add $(mtd_get_mac_binary art 0x0) 
+1)
diff --git a/target/linux/ath79/dts/qca9531_glinet_gl-ar750.dts 
b/target/linux/ath79/dts/qca9531_glinet_gl-ar750.dts
new file mode 100644
index 000..54aad32
--- /dev/null
+++ b/target/linux/ath79/dts/qca9531_glinet_gl-ar750.dts
@@ -0,0 +1,142 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include 
+#include 
+
+#include "qca953x.dtsi"
+
+/ {
+   compatible = "glinet,gl-ar750", "qca,qca9531";
+   model = "GL.iNet GL-AR750";
+
+   keys {
+   compatible = "gpio-keys";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_disable_pins>;
+
+   reset {
+   label = "reset";
+   linux,code = ;
+   gpios = < 3 GPIO_ACTIVE_LOW>;
+   };
+
+   mode {
+   label = "mode";
+   linux,code = ;
+   gpios = < 0 GPIO_ACTIVE_LOW>;
+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   power {
+   label = "gl-ar750:white:power";
+   gpios = < 12 GPIO_ACTIVE_LOW>;
+   default-state = "on";
+   };
+
+   wlan2g {
+   label = "gl-ar750:white:wlan2g";
+   gpios = < 14 GPIO_ACTIVE_LOW>;
+   linux,default-trigger = "phy1tpt";
+   };
+
+   wlan5g {
+   label = "gl-ar750:white:wlan5g";
+   gpios = < 13 GPIO_ACTIVE_LOW>;
+   linux,default-trigger = "phy0tpt";
+   };
+
+   };
+
+   i2c {
+   compatible = "i2c-gpio";
+
+   sda-gpios = < 17 GPIO_ACTIVE_LOW>;
+   scl-gpios = < 16 GPIO_ACTIVE_LOW>;
+   };
+
+
+};
+
+ {
+   status = "okay";
+
+   wifi@0,0 {
+   compatible = "qcom,ath10k";
+   reg = <0 0 0 0 0>;
+   device_type = "pci";
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_phy {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+   num-cs = <0>;
+
+   flash@0 {
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <2500>;
+
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "u-boot";
+   reg = <0x00 0x04>;
+

Re: [OpenWrt-Devel] [PATCH v3] ramips: add Asus RT-AC85P

2019-08-23 Thread Gábor Varga

Hi!

Although it looks like the Asus RT-AC85P and the Asus RT-AC65P models are
identical, but I have separated them into two dts and have introduced the
HW version into the names (for the new versions in the future).

I have an alternative installation method 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-r01-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-r01-squashfs-factory.bin -d linux
6. Reboot the router
 > reboot

Another thing: I don't know, if it's good method to replace the second
firmware partition with OpenWrt image during sysupgrade. When we don't do
that, than we have always a factory firmware on the secondary firmware
partition, so the back to the factory firmware would be much easier.

So, the new patch for the separated models:

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 c0de9d4e50..110e921f38 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -300,6 +300,8 @@ ramips_setup_interfaces()
  ucidef_add_switch "switch0" \
  "0:lan:4" "1:lan:3" "2:lan:2" "3:lan:1" "4:wan:5" "6@eth0"
  ;;
+ asus,rt-ac65p-r01|\
+ asus,rt-ac85p-r01|\
  dlink,dir-860l-b1|\
  elecom,wrc-1167ghbk2-s|\
  elecom,wrc-1900gst|\
@@ -537,6 +539,10 @@ ramips_setup_macs()
  lan_mac=$(mtd_get_mac_binary factory 0xe000)
  wan_mac=$(mtd_get_mac_binary factory 0xe006)
  ;;
+ asus,rt-ac65p-r01|\
+ asus,rt-ac85p-r01)
+ wan_mac=$(mtd_get_mac_ascii u-boot-env et1macaddr)
+ ;;
  asus,rt-n56u)
  lan_mac=$(macaddr_setbit_la "$(cat /sys/class/net/eth0/address)")
  wan_mac=$(mtd_get_mac_binary factory 0x8004)
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index a65492a309..7a50c61b1d 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -18,9 +18,18 @@ platform_do_upgrade() {
  mikrotik,rbm33g)
  [ -z "$(rootfs_type)" ] && mtd erase firmware
  ;;
+ asus,rt-ac65p-r01|\
+ asus,rt-ac85p-r01)
+ echo "Backing up firmware"
+ dd if=/dev/mtd4 bs=1024 count=4096  > /tmp/backup_firmware.bin
+ dd if=/dev/mtd5 bs=1024 count=52224 >> /tmp/backup_firmware.bin
+ mtd -e firmware2 write /tmp/backup_firmware.bin firmware2
+ ;;
  esac

  case "$board" in
+ asus,rt-ac65p-r01|\
+ asus,rt-ac85p-r01|\
  hiwifi,hc5962|\
  netgear,r6220|\
  netgear,r6350|\
diff --git a/target/linux/ramips/dts/mt7621_asus_rt-ac65p-r01.dts
b/target/linux/ramips/dts/mt7621_asus_rt-ac65p-r01.dts
new file mode 100644
index 00..3d2d1bfe6d
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_asus_rt-ac65p-r01.dts
@@ -0,0 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7621_asus_rt-ac85p.dtsi"
+
+/ {
+compatible = "asus,rt-ac65p-r01", "mediatek,mt7621-soc";
+model = "Asus RT-AC65P R01";
+};
diff --git a/target/linux/ramips/dts/mt7621_asus_rt-ac85p-r01.dts
b/target/linux/ramips/dts/mt7621_asus_rt-ac85p-r01.dts
new file mode 100644
index 00..115d52c71c
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_asus_rt-ac85p-r01.dts
@@ -0,0 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7621_asus_rt-ac85p.dtsi"
+
+/ {
+compatible = "asus,rt-ac85p-r01", "mediatek,mt7621-soc";
+model = "Asus RT-AC85P R01";
+};
diff --git a/target/linux/ramips/dts/mt7621_asus_rt-ac85p.dtsi
b/target/linux/ramips/dts/mt7621_asus_rt-ac85p.dtsi
new file mode 100644
index 00..aa1229ab03
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_asus_rt-ac85p.dtsi
@@ -0,0 +1,161 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7621.dtsi"
+
+#include 
+#include 
+
+/ {
+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 =

[OpenWrt-Devel] [PATCH] treewide: add Generic subtarget if missing

2019-08-23 Thread Paul Spooren

As in 853e4dd OpenWrt should follow a unified structure, where every
device has a target/subtarget combination, if there is only one
subtarget, call it "Generic". This introduces predictable filenames.

CC: Alexander Couzens 
CC: Felix Fietkau 
CC: Jason Wu 
CC: John Crispin 
CC: Luka Perkov 
CC: Roman Yeryomin 
CC: Sergey Ryazanov 
CC: Tim Harvey 
CC: Tomasz Maciej Nowak 

Signed-off-by: Paul Spooren 
---
 target/linux/ath25/Makefile  | 1 +
 target/linux/ath25/generic/target.mk | 1 +
 target/linux/cns3xxx/Makefile| 1 +
 target/linux/cns3xxx/generic/target.mk   | 1 +
 target/linux/gemini/Makefile | 1 +
 target/linux/gemini/generic/target.mk| 1 +
 target/linux/imx6/Makefile   | 1 +
 target/linux/imx6/generic/target.mk  | 1 +
 target/linux/kirkwood/Makefile   | 1 +
 target/linux/kirkwood/generic/target.mk  | 1 +
 target/linux/octeon/Makefile | 1 +
 target/linux/octeon/generic/target.mk| 1 +
 target/linux/octeontx/Makefile   | 1 +
 target/linux/octeontx/generic/target.mk  | 1 +
 target/linux/omap/Makefile   | 1 +
 target/linux/omap/generic/target.mk  | 1 +
 target/linux/pistachio/Makefile  | 1 +
 target/linux/pistachio/generic/target.mk | 1 +
 target/linux/rb532/Makefile  | 1 +
 target/linux/rb532/generic/target.mk | 1 +
 target/linux/tegra/Makefile  | 1 +
 target/linux/tegra/generic/target.mk | 1 +
 target/linux/zynq/Makefile   | 1 +
 target/linux/zynq/generic/target.mk  | 1 +
 24 files changed, 24 insertions(+)
 create mode 100644 target/linux/ath25/generic/target.mk
 create mode 100644 target/linux/cns3xxx/generic/target.mk
 create mode 100644 target/linux/gemini/generic/target.mk
 create mode 100644 target/linux/imx6/generic/target.mk
 create mode 100644 target/linux/kirkwood/generic/target.mk
 create mode 100644 target/linux/octeon/generic/target.mk
 create mode 100644 target/linux/octeontx/generic/target.mk
 create mode 100644 target/linux/omap/generic/target.mk
 create mode 100644 target/linux/pistachio/generic/target.mk
 create mode 100644 target/linux/rb532/generic/target.mk
 create mode 100644 target/linux/tegra/generic/target.mk
 create mode 100644 target/linux/zynq/generic/target.mk

diff --git a/target/linux/ath25/Makefile b/target/linux/ath25/Makefile
index cb8b7ec1be..a253b4ceb3 100644
--- a/target/linux/ath25/Makefile
+++ b/target/linux/ath25/Makefile
@@ -10,6 +10,7 @@ ARCH:=mips
 BOARD:=ath25
 BOARDNAME:=Atheros AR231x/AR5312
 FEATURES:=squashfs low_mem small_flash
+SUBTARGETS:=generic
 MAINTAINER:=Sergey Ryazanov 
 
 KERNEL_PATCHVER:=4.14
diff --git a/target/linux/ath25/generic/target.mk 
b/target/linux/ath25/generic/target.mk
new file mode 100644
index 00..f5cb1fb19b
--- /dev/null
+++ b/target/linux/ath25/generic/target.mk
@@ -0,0 +1 @@
+BOARDNAME:=Generic
diff --git a/target/linux/cns3xxx/Makefile b/target/linux/cns3xxx/Makefile
index f21ad06248..7930b959b6 100644
--- a/target/linux/cns3xxx/Makefile
+++ b/target/linux/cns3xxx/Makefile
@@ -12,6 +12,7 @@ BOARDNAME:=Cavium Networks Econa CNS3xxx
 FEATURES:=squashfs fpu gpio pcie usb usbgadget
 CPU_TYPE:=mpcore
 CPU_SUBTYPE:=vfp
+SUBTARGETS:=generic
 MAINTAINER:=Felix Fietkau , \
Koen Vandeputte 
 KERNEL_PATCHVER:=4.19
diff --git a/target/linux/cns3xxx/generic/target.mk 
b/target/linux/cns3xxx/generic/target.mk
new file mode 100644
index 00..f5cb1fb19b
--- /dev/null
+++ b/target/linux/cns3xxx/generic/target.mk
@@ -0,0 +1 @@
+BOARDNAME:=Generic
diff --git a/target/linux/gemini/Makefile b/target/linux/gemini/Makefile
index 3afc643023..1f1486f0c5 100644
--- a/target/linux/gemini/Makefile
+++ b/target/linux/gemini/Makefile
@@ -11,6 +11,7 @@ BOARD:=gemini
 BOARDNAME:=Cortina Systems CS351x
 FEATURES:=squashfs pci rtc usb dt gpio display ext4 rootfs-part boot-part
 CPU_TYPE:=fa526
+SUBTARGETS:=generic
 MAINTAINER:=Roman Yeryomin 
 
 KERNEL_PATCHVER:=4.19
diff --git a/target/linux/gemini/generic/target.mk 
b/target/linux/gemini/generic/target.mk
new file mode 100644
index 00..f5cb1fb19b
--- /dev/null
+++ b/target/linux/gemini/generic/target.mk
@@ -0,0 +1 @@
+BOARDNAME:=Generic
diff --git a/target/linux/imx6/Makefile b/target/linux/imx6/Makefile
index ac4300f7eb..570898cb9c 100644
--- a/target/linux/imx6/Makefile
+++ b/target/linux/imx6/Makefile
@@ -12,6 +12,7 @@ BOARDNAME:=Freescale i.MX 6
 FEATURES:=audio display fpu gpio pcie rtc usb usbgadget squashfs targz nand 
ubifs boot-part rootfs-part
 CPU_TYPE:=cortex-a9
 CPU_SUBTYPE:=neon
+SUBTARGETS:=generic
 MAINTAINER:=Luka Perkov 
 
 KERNEL_PATCHVER:=4.19
diff --git a/target/linux/imx6/generic/target.mk 
b/target/linux/imx6/generic/target.mk
new file mode 100644
index 00..f5cb1fb19b
--- /dev/null
+++ b/target/linux/imx6/generic/target.mk
@@ -0,0 +1 @@
+BOARDNAME:=Generic
diff --git a/target/linux/kirkwood/Makefile b/target/linux/kirkwood/Makefile
index adc7a496e1..e185eca093 100644
---

[OpenWrt-Devel] [PATCH] bcm53xx: add generic subtarget

2019-08-23 Thread Paul Spooren

Same game as for 853e4dd3062df7cb5704b15d6af6730e3194b571. Add generic
to the filenames.

CC: Hauke Mehrtens 

Signed-off-by: Paul Spooren 
---
 target/linux/bcm53xx/Makefile  | 1 +
 target/linux/bcm53xx/generic/target.mk | 1 +
 2 files changed, 2 insertions(+)
 create mode 100644 target/linux/bcm53xx/generic/target.mk

diff --git a/target/linux/bcm53xx/Makefile b/target/linux/bcm53xx/Makefile
index 4171a04ee4..6c19263fdf 100644
--- a/target/linux/bcm53xx/Makefile
+++ b/target/linux/bcm53xx/Makefile
@@ -12,6 +12,7 @@ BOARDNAME:=Broadcom BCM47xx/53xx (ARM)
 FEATURES:=squashfs nand usb pci pcie gpio
 MAINTAINER:=Hauke Mehrtens 
 CPU_TYPE:=cortex-a9
+SUBTARGETS:=generic
 
 KERNEL_PATCHVER:=4.14
 KERNEL_TESTING_PATCHVER := 4.19
diff --git a/target/linux/bcm53xx/generic/target.mk 
b/target/linux/bcm53xx/generic/target.mk
new file mode 100644
index 00..f5cb1fb19b
--- /dev/null
+++ b/target/linux/bcm53xx/generic/target.mk
@@ -0,0 +1 @@
+BOARDNAME:=Generic
-- 
2.23.0.rc1


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

[OpenWrt-Devel] need help regarding flash layout for new device

2019-08-23 Thread Michael Schwingen


Hi,


I am in the process of getting OpenWRT running on a new device (Lancom 
LN-1702: NXP T1013).


I have a working u-boot and kernel 4.19, and now I am a bit lost 
regarding what flash/partition layout to use to get OpenWRT running with 
minimal modifications.


I have: NAND flash on T1013 IFC bus, with 4 MTD partitions, and UBI on 
the last one. UBI has 3 volumes: kernel, dts and rootfs.


If I tftpboot and start kernel/initramfs, I get a running system without 
any r/w filesystem. ubi0 on mtd4 is auto-detected, and I can manually 
mount the rootfs_data volume - but this does not happen automatically on 
boot.


When I boot the kernel from flash, with root=ubi0:rootfs_data, it finds 
init but hangs when trying to mount an overlay.


I am looking for some guidance how this is supposed to work - since this 
device never had Linux on it, I don't have an "original" layout, and 
https://openwrt.org/docs/techref/flash.layout is a bit thin regardings 
NAND/UBI.


Do I need special volume names? How is the boot process supposed to work 
on a NAND/UBI setup (with or without initramfs, and what is mounted 
where by whom)?


Sorry for being vague about error messages - I can provide exact 
bootlogs in the evening, but I am more looking for pointers to the 
general concept from where I can find what I am doing wrong.


best regards,

Michael


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

[OpenWrt-Devel] [PATCH v5] ramips: add support for Edimax RG21S

2019-08-23 Thread Birger Koblitz

ramips: add support for Edimax RG21S

SoC:MediaTek MT7621AT dual-core @ 880MHz
RAM:256M (Nanya NT5CC128M)
FLASH:  16MB (Macronix MX25L12835F)
WiFi:   - 2.4GHz MediaTek MT7615N bgn
- 5GHz MediaTek MT7615N nac
Switch: SoC integrated Gigabit Switch (4 x LAN, 1 x WAN)
USB:No
BTN:Reset, WPS
LED:4 red LEDs, indistinguishable when casing closed
UART:   UART is present as Pads marked J1 on the PCB.
3.3V - RX - GND - TX / 57600-8N1
3.3V is the square pad

Installation

Update the factory image via the OEM web-interface
(by default:http://192.168.1.1)
The sysupgrade image can be installed via TFTP from
the U-Boot bootloader. Connect ethernet port 2.

Signed-off-by: Birger Koblitz 

---

v3: Update to DEVICE_VENDOR / DEVICE_MODEL in mt7621.mk
renamed .dts according to new conventions
Removed memory node from .dts
Correct image size
Whitespace fixes
v4: Added wifi0/1 labels to wifi nodes
Model name corrected in dts
Comments removed from .dts
v5: Corrected MT7615N PCI IDs
Unnecessary kernel-modules removed from image

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 c0de9d4e50..91685508db 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -336,6 +336,10 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"0:lan" "4:wan" "6@eth0"
;;
+   edimax,rg21s)
+   ucidef_add_switch "switch0" \
+   "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "0:wan" "6@eth0"
+   ;;
gehua,ghl-r-001)
ucidef_add_switch "switch0" \
"0:lan" "1:lan" "2:lan" "4:wan" "6@eth0"
@@ -594,6 +598,10 @@ ramips_setup_macs()
edimax,br-6478ac-v2)
wan_mac=$(macaddr_add "$(cat /sys/class/net/eth0/address)" 2)
;;
+   edimax,rg21s)
+   lan_mac=$(mtd_get_mac_ascii u-boot-env ethaddr)
+   wan_mac=$(mtd_get_mac_ascii u-boot-env wanaddr)
+   ;;
elecom,wrc-1167ghbk2-s|\
elecom,wrc-1900gst|\
elecom,wrc-2533gst|\
diff --git a/target/linux/ramips/dts/mt7621_edimax_rg21s.dts
b/target/linux/ramips/dts/mt7621_edimax_rg21s.dts
new file mode 100644
index 00..dfccae102b
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_edimax_rg21s.dts
@@ -0,0 +1,157 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7621.dtsi"
+
+#include 
+#include 
+
+/ {
+   compatible = "edimax,rg21s", "mediatek,mt7621-soc";
+   model = "Edimax RG21S";
+
+   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 = < 16 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+
+   wps {
+   label = "wps";
+   gpios = < 18 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   led_power: led_1 {
+   label = "rg21s:red:led1";
+   gpios = < 7 GPIO_ACTIVE_HIGH>;
+   };
+
+   led_2 {
+   label = "rg21s:red:led2";
+   gpios = < 12 GPIO_ACTIVE_HIGH>;
+   };
+
+   led_3 {
+   label = "rg21s:red:led3";
+   gpios = < 14 GPIO_ACTIVE_HIGH>;
+   };
+
+   led_4 {
+   label = "rg21s:red:led4";
+   gpios = < 15 GPIO_ACTIVE_HIGH>;
+   };
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+
+   m25p80@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>;

[OpenWrt-Devel] [PATCH v5] ramips: add support for Edimax RG21S

2019-08-23 Thread Birger Koblitz

ramips: add support for Asus RT-AC85P

SoC:MediaTek MT7621AT dual-core @ 880MHz
RAM:256M (Winbond W632GG6KB-1)
FLASH:  128MB (Macronix MX30LF1G18AC-TI)
WiFi:   - 2.4GHz MediaTek MT7615N bgn
- 5GHz MediaTek MT7615N nac
Switch: SoC integrated Gigabit Switch (4 x LAN, 1 x WAN)
USB:1 x USB 3.1 (Gen 1)
BTN:Reset, WPS
LED:- Power (blue)
- 5Ghz (blue)
- 2.4GHz (blue)
- Internet (blue)
- 4x LAN (blue)
(LAN/WAN leds are not controllable by GPIOs)
UART:   UART is present as Pads marked J4 on the PCB.
3.3V - TX - RX - GND / 57600-8N1
3.3V is the square pad
MAC:The MAC address on the router-label matches the MAC of
the 2.4 GHz WiFi.
LAN and WAN MAC are identical: MAC_LABEL+4
5 GHz WiFi MAC: also MAC_LABEL+4


Installation

Via U-Boot tftpd:
Switch on device, within 2s press reset button and keep pressed
until power LED starts blinking slowly.
Upload factory image via tftp put, the router's ip is 192.168.1.1
and expects the client on 192.168.1.75.

The images also work on the Asus RT-AC65P models as tested by Gabor.

Signed-off-by: Birger Koblitz 
Tested-by: Gabor Varga 

---

v2: Corrected sorting of entries in 02_network
Model name corrected in .dts
Whitespace fixes in .dts
wifi0/1 labels added to wifi nodes in .dts
Device name capitalized in mt7621.mk

v3: Added firmware backup to firmware2 partition before sysupgrade
Corrected modules included in image

v4: Corrected MT7615N PCI IDs

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 c0de9d4e50..91685508db 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -336,6 +336,10 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"0:lan" "4:wan" "6@eth0"
;;
+   edimax,rg21s)
+   ucidef_add_switch "switch0" \
+   "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "0:wan" "6@eth0"
+   ;;
gehua,ghl-r-001)
ucidef_add_switch "switch0" \
"0:lan" "1:lan" "2:lan" "4:wan" "6@eth0"
@@ -594,6 +598,10 @@ ramips_setup_macs()
edimax,br-6478ac-v2)
wan_mac=$(macaddr_add "$(cat /sys/class/net/eth0/address)" 2)
;;
+   edimax,rg21s)
+   lan_mac=$(mtd_get_mac_ascii u-boot-env ethaddr)
+   wan_mac=$(mtd_get_mac_ascii u-boot-env wanaddr)
+   ;;
elecom,wrc-1167ghbk2-s|\
elecom,wrc-1900gst|\
elecom,wrc-2533gst|\
diff --git a/target/linux/ramips/dts/mt7621_edimax_rg21s.dts
b/target/linux/ramips/dts/mt7621_edimax_rg21s.dts
new file mode 100644
index 00..dfccae102b
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_edimax_rg21s.dts
@@ -0,0 +1,157 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7621.dtsi"
+
+#include 
+#include 
+
+/ {
+   compatible = "edimax,rg21s", "mediatek,mt7621-soc";
+   model = "Edimax RG21S";
+
+   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 = < 16 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+
+   wps {
+   label = "wps";
+   gpios = < 18 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   led_power: led_1 {
+   label = "rg21s:red:led1";
+   gpios = < 7 GPIO_ACTIVE_HIGH>;
+   };
+
+   led_2 {
+   label = "rg21s:red:led2";
+   gpios = < 12 GPIO_ACTIVE_HIGH>;
+   };
+
+   led_3 {
+   label = "rg21s:red:led3";
+   gpios = < 14 GPIO_ACTIVE_HIGH>;
+   };
+
+   led_4 {
+   label = "rg21s:red:led4";
+   gpios = < 15 GPIO_ACTIVE_HIGH>;
+   };
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+
+   m25p80@0 {
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <1000>;
+
+   partitions {
+   compatible = "fixed-partitions";
+

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

2019-08-23 Thread Birger Koblitz

ramips: add support for Asus RT-AC85P

SoC:MediaTek MT7621AT dual-core @ 880MHz
RAM:256M (Winbond W632GG6KB-1)
FLASH:  128MB (Macronix MX30LF1G18AC-TI)
WiFi:   - 2.4GHz MediaTek MT7615N bgn
- 5GHz MediaTek MT7615N nac
Switch: SoC integrated Gigabit Switch (4 x LAN, 1 x WAN)
USB:1 x USB 3.1 (Gen 1)
BTN:Reset, WPS
LED:- Power (blue)
- 5Ghz (blue)
- 2.4GHz (blue)
- Internet (blue)
- 4x LAN (blue)
(LAN/WAN leds are not controllable by GPIOs)
UART:   UART is present as Pads marked J4 on the PCB.
3.3V - TX - RX - GND / 57600-8N1
3.3V is the square pad
MAC:The MAC address on the router-label matches the MAC of
the 2.4 GHz WiFi.
LAN and WAN MAC are identical: MAC_LABEL+4
5 GHz WiFi MAC: also MAC_LABEL+4


Installation

Via U-Boot tftpd:
Switch on device, within 2s press reset button and keep pressed
until power LED starts blinking slowly.
Upload factory image via tftp put, the router's ip is 192.168.1.1
and expects the client on 192.168.1.75.

The images also work on the Asus RT-AC65P models as tested by Gabor.

Signed-off-by: Birger Koblitz 
Tested-by: Gabor Varga 

---

v2: Corrected sorting of entries in 02_network
Model name corrected in .dts
Whitespace fixes in .dts
wifi0/1 labels added to wifi nodes in .dts
Device name capitalized in mt7621.mk

v3: Added firmware backup to firmware2 partition before sysupgrade
Corrected modules included in image

v4: Corrected MT7615N PCI IDs

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 2f9a02256e..ab90041d92 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -231,6 +231,17 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"0:lan" "1:wan" "6@eth0"
;;
+   asus,rt-ac85p|\
+   dlink,dir-860l-b1|\
+   elecom,wrc-1167ghbk2-s|\
+   elecom,wrc-1900gst|\
+   elecom,wrc-2533gst|\
+   huawei,hg255d|\
+   iodata,wn-ax1167gr|\
+   iodata,wn-gx300gr)
+   ucidef_add_switch "switch0" \
+   "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "0:wan" "6@eth0"
+   ;;
asus,rt-n15|\
belkin,f9k1109v1|\
sitecom,wl-351)
@@ -298,16 +309,6 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"0:lan:4" "1:lan:3" "2:lan:2" "3:lan:1" "4:wan:5" 
"6@eth0"
;;
-   dlink,dir-860l-b1|\
-   elecom,wrc-1167ghbk2-s|\
-   elecom,wrc-1900gst|\
-   elecom,wrc-2533gst|\
-   huawei,hg255d|\
-   iodata,wn-ax1167gr|\
-   iodata,wn-gx300gr)
-   ucidef_add_switch "switch0" \
-   "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "0:wan" "6@eth0"
-   ;;
dlink,dwr-118-a1)
ucidef_add_switch "switch0" \
"1:lan:2" "2:lan:3" "3:lan:1" "4:lan:0" "5:wan" "6@eth0"
@@ -531,6 +532,9 @@ ramips_setup_macs()
lan_mac=$(mtd_get_mac_binary factory 57344)
wan_mac=$(mtd_get_mac_binary factory 57350)
;;
+   asus,rt-ac85p)
+   wan_mac=$(mtd_get_mac_ascii u-boot-env et1macaddr)
+   ;;
asus,rt-n56u)
lan_mac=$(macaddr_setbit_la "$(cat 
/sys/class/net/eth0/address)")
wan_mac=$(mtd_get_mac_binary factory 32772)
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index a65492a309..cd9d8ae650 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -18,9 +18,16 @@ platform_do_upgrade() {
mikrotik,rbm33g)
[ -z "$(rootfs_type)" ] && mtd erase firmware
;;
+   asus,rt-ac85p)
+   echo "Backing up firmware"
+   dd if=/dev/mtd4 bs=1024 count=4096  > /tmp/backup_firmware.bin
+   dd if=/dev/mtd5 bs=1024 count=52224 >> /tmp/backup_firmware.bin
+   mtd -e firmware2 write /tmp/backup_firmware.bin firmware2
+   ;;
esac

case "$board" in
+   asus,rt-ac85p|\
hiwifi,hc5962|\
netgear,r6220|\
netgear,r6350|\
diff --git a/target/linux/ramips/dts/mt7621_asus_rt-ac85p.dts
b/target/linux/ramips/dts/mt7621_asus_rt-ac85p.dts
new file mode 100644
index 00..7aea207fad
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_asus_rt-ac85p.dts
@@ -0,0 +1,164 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7621.dtsi"
+
+#include 
+#include 
+
+/ {
+   compatible = "asus,rt-ac85p", "mediatek,mt7621-soc";
+   model = "Asus RT-AC85P";
+
+   aliases {
+   led-boot = _power;
+

[OpenWrt-Devel] [PATCH v5] ramips: add support for Edimax RG21S

2019-08-23 Thread Birger Koblitz

ramips: add Edimax RG21S

SoC:    MediaTek MT7621AT dual-core @ 880MHz
RAM:    256M (Nanya NT5CC128M)
FLASH:    16MB (Macronix MX25L12835F)
WiFi:    - 2.4GHz MediaTek MT7615N bgn
    - 5GHz MediaTek MT7615N nac
Switch: SoC integrated Gigabit Switch (4 x LAN, 1 x WAN)
USB:    No
BTN:    Reset, WPS
LED:    4 red LEDs, indistinguishable when casing closed
UART:     UART is present as Pads marked J1 on the PCB.
    3.3V - RX - GND - TX / 57600-8N1
    3.3V is the square pad

Installation

Update the factory image via the OEM web-interface
(by default:http://192.168.1.1)
The sysupgrade image can be installed via TFTP from
the U-Boot bootloader. Connect ethernet port 2.

Signed-off-by: Birger Koblitz 

---

v3: Update to DEVICE_VENDOR / DEVICE_MODEL in mt7621.mk
    renamed .dts according to new conventions
    Removed memory node from .dts
    Correct image size
    Whitespace fixes
v4: Added wifi0/1 labels to wifi nodes
    Model name corrected in dts
    Comments removed from .dts
v5: Corrected MT7615N PCI IDs
    Unnecessary kernel-modules removed from image

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 c0de9d4e50..91685508db 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -336,6 +336,10 @@ ramips_setup_interfaces()
     ucidef_add_switch "switch0" \
         "0:lan" "4:wan" "6@eth0"
     ;;
+    edimax,rg21s)
+        ucidef_add_switch "switch0" \
+            "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "0:wan" "6@eth0"
+        ;;
 gehua,ghl-r-001)
     ucidef_add_switch "switch0" \
         "0:lan" "1:lan" "2:lan" "4:wan" "6@eth0"
@@ -594,6 +598,10 @@ ramips_setup_macs()
 edimax,br-6478ac-v2)
     wan_mac=$(macaddr_add "$(cat /sys/class/net/eth0/address)" 2)
     ;;
+    edimax,rg21s)
+        lan_mac=$(mtd_get_mac_ascii u-boot-env ethaddr)
+        wan_mac=$(mtd_get_mac_ascii u-boot-env wanaddr)
+        ;;
 elecom,wrc-1167ghbk2-s|\
 elecom,wrc-1900gst|\
 elecom,wrc-2533gst|\
diff --git a/target/linux/ramips/dts/mt7621_edimax_rg21s.dts
b/target/linux/ramips/dts/mt7621_edimax_rg21s.dts
new file mode 100644
index 00..dfccae102b
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_edimax_rg21s.dts
@@ -0,0 +1,157 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7621.dtsi"
+
+#include 
+#include 
+
+/ {
+    compatible = "edimax,rg21s", "mediatek,mt7621-soc";
+    model = "Edimax RG21S";
+
+    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 = < 16 GPIO_ACTIVE_LOW>;
+            linux,code = ;
+        };
+
+        wps {
+            label = "wps";
+            gpios = < 18 GPIO_ACTIVE_LOW>;
+            linux,code = ;
+        };
+    };
+
+    leds {
+        compatible = "gpio-leds";
+
+        led_power: led_1 {
+            label = "rg21s:red:led1";
+            gpios = < 7 GPIO_ACTIVE_HIGH>;
+        };
+
+        led_2 {
+            label = "rg21s:red:led2";
+            gpios = < 12 GPIO_ACTIVE_HIGH>;
+        };
+
+        led_3 {
+            label = "rg21s:red:led3";
+            gpios = < 14 GPIO_ACTIVE_HIGH>;
+        };
+
+        led_4 {
+            label = "rg21s:red:led4";
+            gpios = < 15 GPIO_ACTIVE_HIGH>;
+        };
+    };
+};
+
+ {
+    status = "okay";
+};
+
+ {
+    status = "okay";
+
+    m25p80@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;
+            };
+
+            partition@5 {
+                compatible = "denx,uimage";
+                label = "firmware";
+                reg = <0x5 0xfb>;
+            };
+        };
+    };
+};
+
+ {
+    status = "okay";
+};
+
+ {
+    wifi0: wifi@0,0 {
+        compatible = "pci14c3,7615";
+        reg = <0x 0 0 0 0>;
+        mediatek,mtd-eeprom = < 0x>;
+        ieee80211-freq-limit = <240 250>;
+        mtd-mac-address = < 0x4>;
+

Re: [OpenWrt-Devel] [PATCH v4] ramips: add support for Edimax RG21S

2019-08-23 Thread Birger Koblitz

Dear Daniel,

thanks for spotting this. Indeed, the correct PCI device-id of the
MT7615N is 7615. 

Interestingly, the kernel module did not care. I'll submit a new v5
patch for the Edimax RG21S and also a new patch for the ASUS RT-AC85p
where I made the same mistake.

Birger


On 22.08.19 16:47, Daniel Golle wrote:
> Hi,
>
> I believe the PCI-IDs of the devices in your device tree are wrong,
> see below:
>
> On Sun, Jul 21, 2019 at 07:43:51AM +0200, Birger Koblitz wrote:
>> ramips: add Edimax RG21S
>>
>> SoC: MediaTek MT7621AT dual-core @ 880MHz
>> RAM: 256M (Nanya NT5CC128M)
>> FLASH:   16MB (Macronix MX25L12835F)
>> WiFi:- 2.4GHz MediaTek MT7615N bgn
>>  - 5GHz MediaTek MT7615N nac
>> Switch: SoC integrated Gigabit Switch (4 x LAN, 1 x WAN)
>> USB: No
>> BTN: Reset, WPS
>> LED: 4 red LEDs, indistinguishable when casing closed
>> UART:UART is present as Pads marked J1 on the PCB.
>>  3.3V - RX - GND - TX / 57600-8N1
>>  3.3V is the square pad
>>
>> Installation
>> 
>> Update the factory image via the OEM web-interface
>> (by default:http://192.168.1.1)
>> The sysupgrade image can be installed via TFTP from
>> the U-Boot bootloader. Connect ethernet port 2.
>>
>> Signed-off-by: Birger Koblitz 
>>
>> ---
>>
>> v3: Update to DEVICE_VENDOR / DEVICE_MODEL in mt7621.mk
>> renamed .dts according to new conventions
>> Removed memory node from .dts
>> Correct image size
>> Whitespace fixes
>> v4: Added wifi0/1 labels to wifi nodes
>> Model name corrected in dts
>> Comments removed from .dts
>>
>> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
>> b/target/linux/ramips/base-files/etc/board.d/02_network
>> index a2b7d1cf33..252d2f4e50 100755
>> --- a/target/linux/ramips/base-files/etc/board.d/02_network
>> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
>> @@ -329,6 +329,10 @@ ramips_setup_interfaces()
>>  ucidef_add_switch "switch1" \
>>  "1:lan" "2:lan" "3:lan" "4:lan" "0:wan" "6@eth0"
>>  ;;
>> +edimax,rg21s)
>> +ucidef_add_switch "switch0" \
>> +"1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "0:wan" "6@eth0"
>> +;;
>>  gehua,ghl-r-001)
>>  ucidef_add_switch "switch0" \
>>  "0:lan" "1:lan" "2:lan" "4:wan" "6@eth0"
>> @@ -587,6 +591,10 @@ ramips_setup_macs()
>>  lan_mac=$(cat /sys/class/net/eth0/address)
>>  wan_mac=$(macaddr_add "$lan_mac" 2)
>>  ;;
>> +edimax,rg21s)
>> +lan_mac=$(mtd_get_mac_ascii u-boot-env ethaddr)
>> +wan_mac=$(mtd_get_mac_ascii u-boot-env wanaddr)
>> +;;
>>  elecom,wrc-1167ghbk2-s|\
>>  elecom,wrc-1900gst|\
>>  elecom,wrc-2533gst|\
>> diff --git a/target/linux/ramips/dts/mt7621_edimax_rg21s.dts 
>> b/target/linux/ramips/dts/mt7621_edimax_rg21s.dts
>> new file mode 100644
>> index 00..80b644b7a7
>> --- /dev/null
>> +++ b/target/linux/ramips/dts/mt7621_edimax_rg21s.dts
>> @@ -0,0 +1,157 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
>> +/dts-v1/;
>> +
>> +#include "mt7621.dtsi"
>> +
>> +#include 
>> +#include 
>> +
>> +/ {
>> +compatible = "edimax,rg21s", "mediatek,mt7621-soc";
>> +model = "Edimax RG21S";
>> +
>> +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 = < 16 GPIO_ACTIVE_LOW>;
>> +linux,code = ;
>> +};
>> +
>> +wps {
>> +label = "wps";
>> +gpios = < 18 GPIO_ACTIVE_LOW>;
>> +linux,code = ;
>> +};
>> +};
>> +
>> +leds {
>> +compatible = "gpio-leds";
>> +
>> +led_power: led_1 {
>> +label = "rg21s:red:led1";
>> +gpios = < 7 GPIO_ACTIVE_HIGH>;
>> +};
>> +
>> +led_2 {
>> +label = "rg21s:red:led2";
>> +gpios = < 12 GPIO_ACTIVE_HIGH>;
>> +};
>> +
>> +led_3 {
>> +label = "rg21s:red:led3";
>> +gpios = < 14 GPIO_ACTIVE_HIGH>;
>> +};
>> +
>> +led_4 {
>> +label = "rg21s:red:led4";
>> +gpios = < 15 GPIO_ACTIVE_HIGH>;
>> +};
>> +};
>> +};
>> +
>> + {
>> +status = "okay";
>> +};
>> +
>> + {
>> +status = "okay";
>> +
>> +m25p80@0 {
>> +compatible =

[OpenWrt-Devel] [PATCH 2/2] brcm47xx: extend firmware validation

2019-08-23 Thread Rafał Miłecki

From: Rafał Miłecki 

This provides TRX validation result, so final JSON may look like:
{
"tests": {
"fwtool_signature": true,
"fwtool_device_match": true,
"trx_valid": true
},
"valid": true,
"forceable": true
}

It also prevents users from installing broken firmware files, e.g.:

$ sysupgrade -F /tmp/dhcp.leases
Image metadata not found
Invalid image type. Please use firmware specific for this device.
Image check failed. This firmware can't be installed.

Signed-off-by: Rafał Miłecki 
---
 .../brcm47xx/base-files/lib/upgrade/platform.sh  | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/target/linux/brcm47xx/base-files/lib/upgrade/platform.sh 
b/target/linux/brcm47xx/base-files/lib/upgrade/platform.sh
index dfd4e97ed2..cc3fabb7f4 100644
--- a/target/linux/brcm47xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/brcm47xx/base-files/lib/upgrade/platform.sh
@@ -98,7 +98,10 @@ platform_check_image() {
 
if ! otrx check "$1" -o "$header_len"; then
echo "No valid TRX firmware in the CHK image"
+   notify_check_test_result "trx_valid" 0
error=1
+   else
+   notify_check_test_result "trx_valid" 1
fi
;;
"cybertan")
@@ -113,17 +116,24 @@ platform_check_image() {
 
if ! otrx check "$1" -o 32; then
echo "No valid TRX firmware in the CyberTAN 
image"
+   notify_check_test_result "trx_valid" 0
error=1
+   else
+   notify_check_test_result "trx_valid" 1
fi
;;
"trx")
if ! otrx check "$1"; then
echo "Invalid (corrupted?) TRX firmware"
+   notify_check_test_result "trx_valid" 0
error=1
+   else
+   notify_check_test_result "trx_valid" 1
fi
;;
*)
-   echo "Invalid image type. Please use only .trx files"
+   echo "Invalid image type. Please use firmware specific 
for this device."
+   notify_check_broken
error=1
;;
esac
-- 
2.21.0


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

[OpenWrt-Devel] [PATCH 1/2] base-files: use JSON for storing firmware validation info

2019-08-23 Thread Rafał Miłecki

From: Rafał Miłecki 

So far firmware validation result was binary limited: it was either
successful or not. That meant various limitations, e.g.:
1) Lack of proper feedback on validation problems
2) No way of marking firmware as totally broken (impossible to install)

This change introduces JSON for storing detailed validation info. It
provides a list of performed validation tests and their results. It
allows marking firmware as non-forceable (broken image that can't be
even forced to install).
Example:
{
"tests": {
"fwtool_signature": true,
"fwtool_device_match": true
},
"valid": true,
"forceable": true
}

Implementation is based on *internal* check_image bash script that:
1) Uses existing validation functions
2) Provides helpers for setting extra validation info

This allows e.g. platform_check_image() to call notify_check_broken()
when needed & prevent user from bricking a device.

Right now the new JSON info is used by /sbin/sysupgrade only. It's
already a nice gain as it stops users from installing broken images.

Further plans for this feature are:
1) Expose firmware validation using some new ubus method
2) Move validation step from /sbin/sysupgrade into "sysupgrade" ubus
   method so:
   a) It's possible to safely sysupgrade using ubus only
   b) /sbin/sysupgrade can be more like just a CLI

Signed-off-by: Rafał Miłecki 
---
 package/base-files/files/sbin/sysupgrade  | 24 +---
 .../base-files/files/usr/libexec/check_image  | 59 +++
 2 files changed, 74 insertions(+), 9 deletions(-)
 create mode 100755 package/base-files/files/usr/libexec/check_image

diff --git a/package/base-files/files/sbin/sysupgrade 
b/package/base-files/files/sbin/sysupgrade
index c27c1fbc47..903449d3e5 100755
--- a/package/base-files/files/sbin/sysupgrade
+++ b/package/base-files/files/sbin/sysupgrade
@@ -2,6 +2,7 @@
 
 . /lib/functions.sh
 . /lib/functions/system.sh
+. /usr/share/libubox/jshn.sh
 
 # initialize defaults
 export MTD_ARGS=""
@@ -191,9 +192,6 @@ add_overlayfiles() {
return 0
 }
 
-# hooks
-sysupgrade_image_check="fwtool_check_signature fwtool_check_image 
platform_check_image"
-
 if [ $SAVE_OVERLAY = 1 ]; then
[ ! -d /overlay/upper/etc ] && {
echo "Cannot find '/overlay/upper/etc', required for '-c'" >&2
@@ -316,17 +314,25 @@ case "$IMAGE" in
;;
 esac
 
-for check in $sysupgrade_image_check; do
-   ( $check "$IMAGE" ) || {
+json_load "$(/usr/libexec/check_image "$IMAGE")" || {
+   echo "Failed to check image"
+   exit 1
+}
+json_get_var valid "valid"
+json_get_var forceable "forceable"
+[ "$valid" -eq 0 ] && {
+   [ "$forceable" -eq 1 ] && {
if [ $FORCE -eq 1 ]; then
-   echo "Image check '$check' failed but --force given - 
will update anyway!" >&2
-   break
+   echo "Image check failed but --force given - will 
update anyway!" >&2
else
-   echo "Image check '$check' failed." >&2
+   echo "Image check failed. Use --force if needed." >&2
exit 1
fi
+   } || {
+   echo "Image check failed. This firmware can't be installed." >&2
+   exit 1
}
-done
+}
 
 if [ -n "$CONF_IMAGE" ]; then
case "$(get_magic_word $CONF_IMAGE cat)" in
diff --git a/package/base-files/files/usr/libexec/check_image 
b/package/base-files/files/usr/libexec/check_image
new file mode 100755
index 00..b9e74c62b2
--- /dev/null
+++ b/package/base-files/files/usr/libexec/check_image
@@ -0,0 +1,59 @@
+#!/bin/sh
+
+. /lib/functions.sh
+. /lib/functions/system.sh
+. /usr/share/libubox/jshn.sh
+
+include /lib/upgrade
+
+VALID=1
+FORCEABLE=1
+
+# Mark image as invalid but still possible to install
+notify_check_invalid() {
+   VALID=0
+}
+
+# Mark image as broken (impossible to install)
+notify_check_broken() {
+   VALID=0
+   FORCEABLE=0
+}
+
+# Add result of validation test
+notify_check_test_result() {
+   local old_ns
+
+   json_set_namespace check_image old_ns
+   json_add_boolean "$1" "$2"
+   json_set_namespace $old_ns
+}
+
+err_to_bool() {
+   [ "$1" -ne 0 ] && echo 0 || echo 1
+}
+
+fwtool_check_signature "$1" >&2
+FWTOOL_SIGNATURE=$?
+[ "$FWTOOL_SIGNATURE" -ne 0 ] && notify_check_invalid
+
+fwtool_check_image "$1" >&2
+FWTOOL_DEVICE_MATCH=$?
+[ "$FWTOOL_DEVICE_MATCH" -ne 0 ] && notify_check_invalid
+
+json_set_namespace check_image old_ns
+json_init
+   json_add_object "tests"
+   json_add_boolean fwtool_signature "$(err_to_bool 
$FWTOOL_SIGNATURE)"
+   json_add_boolean fwtool_device_match "$(err_to_bool 
$FWTOOL_DEVICE_MATCH)"
+
+   # Call platform_check_image() here so it can add its test
+   # results and still mark image properly.
+   json_set_namespace $old_ns
+

37 matches

Mail list logo