date:20190915

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

2019-09-15 Thread Ivan Hörler

> Am 15.09.2019 um 22:46 schrieb Daniel Golle :
> 
> Hi Ivan,
> 
> On Sun, Sep 15, 2019 at 09:28:35PM +0200, Ivan Hörler wrote:
>> Hi
>> Now after nowing how to make a PR, im interested to know how you think about 
>> some thaughts of me.
>> 
>> Linkit Smart 7688 has a blast of tools they offer in the original firmware 
>> bild. Compared the one openWRT offers is verry slim.
>> Is that ment to be so or did nobody care until me?
>> 
>> Some of the Tools:
>> 1. Automatic activation as Accesspoint, because the board is ment for IOT 
>> and has no Ethernet port. Right now with the official OpenWRT build can not 
>> be connected to any network without addtional Serial converter.
> 
> This has been a lengthy debate and if at all, then activating wifi
> by default should only be done on devices without any ethernet.
> LinkIt Smart is a devboard and Ethernet may well be attached, but
> there are examples of consumer systems without any Ethernet port
> which are useless unless wifi is enabled by default.
> Most recent debate is here
> https://github.com/openwrt/openwrt/pull/2408 
> 

It looks to me as the Devolo Magic 2 Device has Ethernet ports. The Linkit 
Smart 7688 is a bare Development board with no Ethernet socket. The only way to 
configure a openWRT without wifi, is to buy another tool. A serial to usb 
adapter and wire the bins to the RX/TX of the board.
In my eyes its no security risk to enable the accesspoint feature in the same 
way as Mediatek does in the official firmware on a dev-board.
I would also apply the same forced self defined password to the same mac-adress 
based ssid as described in the manual  
 so a user that buy’s that 
device can switch to recent openWRT OS without to read separate doc’s.
proposal:
ssid=LinkIt_Smart_7688-[ending6digid-MAC-address]
could look like:
ssid=LinkIt_Smart_7688-6AYR2N

do you agree in this?

> 
>> 
>> 2. Luci WebGUI
> 
> LuCI is shipped with OpenWrt releases by default, but not in the
> development snapshots.

Good. I noticed that already.
Does Luci already provide a check if a password exists before login?
Mediatek developed a selfmade reduced GUI to force Users to set a Password 
before a Login is possible.
Its made as a Web-form that checks if a password exists and forces the user to 
set a password if none exists.

If not, do you agree to let me develop such forced password seting?

> 
>> 
>> 3. Language: Python with PIP
>> 
>> 4. Language: Node with NPM
>> 
>> 5. mraa from Intel
>> 
>> 6. some upm modules from Intel
>> 
>> What of this list wold be possible to integrate in to a official openWRT 
>> release without scratching rules?
> 
> All those other things are installable using 'opkg' on the running
> system. Or you may use the ImageBuilder to build images with software
> of your choice preinstalled.

I will test this packages after solveing Number 1 & 2.

> 
> 
> Cheers
> 
> 
> Daniel
> 
>> 
>> Regards, Ivan Hörler
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

Re: [OpenWrt-Devel] [PATCH 3/3] treewide: sysupgrade: use $UPGRADE_BACKUP to check for backup

2019-09-15 Thread Rafał Miłecki


On 2019-09-11 12:55, Adrian Schmutzler wrote:
diff --git a/package/base-files/files/lib/upgrade/common.sh 
b/package/base-files/files/lib/upgrade/common.sh

index 8e7866f698..0d3162d4fc 100644
--- a/package/base-files/files/lib/upgrade/common.sh
+++ b/package/base-files/files/lib/upgrade/common.sh
@@ -220,7 +220,7 @@ indicate_upgrade() {
 # $(2): (optional) pipe command to extract firmware, e.g. dd bs=n 
skip=m

 default_do_upgrade() {
sync
-   if [ "$UPGRADE_OPT_SAVE_CONFIG" -eq 1 ]; then
+   if [ -n "$UPGRADE_BACKUP" ]; then


Any reason why this is "-n" and not "-f" as below?


I kept the old logic which wasn't checking for file existence. Feel free
to develop, test & send a patch changing that.


 		get_image "$1" "$2" | mtd $MTD_ARGS $MTD_CONFIG_ARGS -j 
"$UPGRADE_BACKUP" write - "${PART_NAME:-

image}"
else
get_image "$1" "$2" | mtd $MTD_ARGS write - 
"${PART_NAME:-image}"
diff --git a/package/base-files/files/lib/upgrade/do_stage2 
b/package/base-files/files/lib/upgrade/do_stage2

index 0e6cc1bfc3..0e32445743 100755
--- a/package/base-files/files/lib/upgrade/do_stage2
+++ b/package/base-files/files/lib/upgrade/do_stage2
@@ -11,7 +11,7 @@ else
default_do_upgrade "$IMAGE"
 fi

-if [ "$UPGRADE_OPT_SAVE_CONFIG" -eq 1 ] && type 
'platform_copy_config' >/dev/null 2>/dev/null; then
+if [ -n "$UPGRADE_BACKUP" ] && type 'platform_copy_config' >/dev/null 
2>/dev/null; then


Here I'm not so sure about "-f" vs. "-n" ...


platform_copy_config
 fi

diff --git a/package/base-files/files/sbin/sysupgrade 
b/package/base-files/files/sbin/sysupgrade

index f18143bff4..935d08048e 100755
--- a/package/base-files/files/sbin/sysupgrade
+++ b/package/base-files/files/sbin/sysupgrade
@@ -371,7 +371,6 @@ else
$backup_attr
\"command\": $(json_string "$COMMAND"),
\"options\": {
-   \"save_config\": $SAVE_CONFIG,
\"save_partitions\": $SAVE_PARTITIONS
}
}"
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/dir825.sh 
b/target/linux/ar71xx/base-files/lib/upgrade/dir825.sh

index c694c2e6f2..e991a06b7a 100644
--- a/target/linux/ar71xx/base-files/lib/upgrade/dir825.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/dir825.sh
@@ -75,7 +75,7 @@ dir825b_do_upgrade_combined() {

if [ -n "$fw_mtd" ] &&  [ ${fw_blocks:-0} -gt 0 ]; then
local append=""
-		[ -f "$UPGRADE_BACKUP" -a "$UPGRADE_OPT_SAVE_CONFIG" -eq 1 ] && 
append="-j $UPGRADE_BACKUP"

+   [ -f "$UPGRADE_BACKUP" ] && append="-j $UPGRADE_BACKUP"

sync
dd if="$fw_file" bs=64k skip=1 count=$fw_blocks 2>/dev/null | \
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh 
b/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh

index 8536d4ba4a..f43bdcea7f 100644
--- a/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh
@@ -159,7 +159,7 @@ platform_do_upgrade_openmesh()
local cfg_size= kernel_size= rootfs_size=
local append=""

-	[ -f "$UPGRADE_BACKUP" -a "$UPGRADE_OPT_SAVE_CONFIG" -eq 1 ] && 
append="-j $UPGRADE_BACKUP"

+   [ -f "$UPGRADE_BACKUP" ] && append="-j $UPGRADE_BACKUP"

cfg_size=$(dd if="$img_path" bs=2 skip=35 count=4 2>/dev/null)
kernel_size=$(dd if="$img_path" bs=2 skip=71 count=4 2>/dev/null)
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh 
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh

index 726163291d..86e7b6386b 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -65,7 +65,7 @@ platform_do_upgrade_combined() {
then
 		local rootfspart=$(platform_find_rootfspart "$partitions" 
"$kernelpart")

local append=""
-		[ -f "$UPGRADE_BACKUP" -a "$UPGRADE_OPT_SAVE_CONFIG" -eq 1 ] && 
append="-j $UPGRADE_BACKUP"

+   [ -f "$UPGRADE_BACKUP" ] && append="-j $UPGRADE_BACKUP"

if [ "$PLATFORM_DO_UPGRADE_COMBINED_SEPARATE_MTD" -ne 1 ]; then
 		( dd if="$1" bs=$CI_BLKSZ skip=1 count=$kern_blocks 
2>/dev/null; \

@@ -164,7 +164,7 @@ platform_do_upgrade_compex() {

if [ -n "$fw_mtd" ] &&  [ ${fw_blocks:-0} -gt 0 ]; then
local append=""
-		[ -f "$UPGRADE_BACKUP" -a "$UPGRADE_OPT_SAVE_CONFIG" -eq 1 ] && 
append="-j $UPGRADE_BACKUPs"

+   [ -f "$UPGRADE_BACKUP" ] && append="-j $UPGRADE_BACKUPs"


Is there a reason for the trailing "s" here or is this a typo: ="-j
$UPGRADE_BACKUPs" ?


Try to check when it has appeared there:
git log -p target/linux/ar71xx/base-files/lib/upgrade/platform.sh

It's a typo.

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

Re: [OpenWrt-Devel] [PATCH 3/3] treewide: sysupgrade: use $UPGRADE_BACKUP to check for backup

2019-09-15 Thread Rafał Miłecki


Hi,

please use text/plain for your e-mails

On 2019-09-15 11:54, m...@adrianschmutzler.de wrote:
please also backport this to 19.07, since the variables for ath79 are 
still wrong there.


That was on my list and I've just done that

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

[OpenWrt-Devel] [sdwalker/sdwalker.github.io] 4b1ac0: This week's update

2019-09-15 Thread Stephen Walker

  Branch: refs/heads/master
  Home:   https://github.com/sdwalker/sdwalker.github.io
  Commit: 4b1ac0e52c1d0f0bac5b464e6a01d2bda1b97102
  
https://github.com/sdwalker/sdwalker.github.io/commit/4b1ac0e52c1d0f0bac5b464e6a01d2bda1b97102
  Author: Stephen Walker 
  Date:   2019-09-15 (Sun, 15 Sep 2019)

  Changed paths:
M uscan/index-18.06.html
M uscan/index.html

  Log Message:
  ---
  This week's update



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

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

2019-09-15 Thread Daniel Golle

Hi Ivan,

On Sun, Sep 15, 2019 at 09:28:35PM +0200, Ivan Hörler wrote:
> Hi
> Now after nowing how to make a PR, im interested to know how you think about 
> some thaughts of me.
> 
> Linkit Smart 7688 has a blast of tools they offer in the original firmware 
> bild. Compared the one openWRT offers is verry slim.
> Is that ment to be so or did nobody care until me?
> 
> Some of the Tools:
> 1. Automatic activation as Accesspoint, because the board is ment for IOT and 
> has no Ethernet port. Right now with the official OpenWRT build can not be 
> connected to any network without addtional Serial converter.

This has been a lengthy debate and if at all, then activating wifi
by default should only be done on devices without any ethernet.
LinkIt Smart is a devboard and Ethernet may well be attached, but
there are examples of consumer systems without any Ethernet port
which are useless unless wifi is enabled by default.
Most recent debate is here
https://github.com/openwrt/openwrt/pull/2408

> 
> 2. Luci WebGUI

LuCI is shipped with OpenWrt releases by default, but not in the
development snapshots.

> 
> 3. Language: Python with PIP
> 
> 4. Language: Node with NPM
> 
> 5. mraa from Intel
> 
> 6. some upm modules from Intel
> 
> What of this list wold be possible to integrate in to a official openWRT 
> release without scratching rules?

All those other things are installable using 'opkg' on the running
system. Or you may use the ImageBuilder to build images with software
of your choice preinstalled.

Cheers

Daniel

> 
> Regards, Ivan Hörler
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

[OpenWrt-Devel] [PATCH] gemini: dir685: Restore graphics

2019-09-15 Thread Linus Walleij

One of the v4.19 patches had a bug, this is fixed upstream,
but in OpenWrt we can fix it by just fixing the bug in the
patch.

We also need to augment the config file to select the
CONFIG_DRM_FBDEV_EMULATION symbol.

This restores the display controller on the DIR-685 to
working state: penguin and graphics on the little screen
with default OpenWrt install.

Signed-off-by: Linus Walleij 
---
 target/linux/gemini/config-4.19   |  1 +
 ...8-ARM-dts-Enable-Gemini-flash-access.patch | 19 +--
 2 files changed, 6 insertions(+), 14 deletions(-)

diff --git a/target/linux/gemini/config-4.19 b/target/linux/gemini/config-4.19
index a817303ec8a0..ac295f085787 100644
--- a/target/linux/gemini/config-4.19
+++ b/target/linux/gemini/config-4.19
@@ -146,6 +146,7 @@ CONFIG_DRM=y
 CONFIG_DRM_BRIDGE=y
 # CONFIG_DRM_CDNS_DSI is not set
 # CONFIG_DRM_DEBUG_SELFTEST is not set
+CONFIG_DRM_FBDEV_EMULATION=y
 CONFIG_DRM_GEM_CMA_HELPER=y
 # CONFIG_DRM_I2C_NXP_TDA9950 is not set
 CONFIG_DRM_KMS_CMA_HELPER=y
diff --git 
a/target/linux/gemini/patches-4.19/0008-ARM-dts-Enable-Gemini-flash-access.patch
 
b/target/linux/gemini/patches-4.19/0008-ARM-dts-Enable-Gemini-flash-access.patch
index 372242c68b44..4a33c43f08c9 100644
--- 
a/target/linux/gemini/patches-4.19/0008-ARM-dts-Enable-Gemini-flash-access.patch
+++ 
b/target/linux/gemini/patches-4.19/0008-ARM-dts-Enable-Gemini-flash-access.patch
@@ -1,7 +1,7 @@
-From 74631102645df8984acbdf67b731e4d437f27fed Mon Sep 17 00:00:00 2001
+From 928681e6b46cb70317f7721aae8435ea89fcfd80 Mon Sep 17 00:00:00 2001
 From: Linus Walleij 
 Date: Thu, 11 Oct 2018 20:06:23 +0200
-Subject: [PATCH 08/18] ARM: dts: Enable Gemini flash access
+Subject: [PATCH] ARM: dts: Enable Gemini flash access
 
 Some Gemini platforms have a parallel NOR flash which conflicts
 with use cases reusing some of the flash lines (such as CE1)
@@ -16,9 +16,9 @@ access.
 
 Signed-off-by: Linus Walleij 
 ---
- arch/arm/boot/dts/gemini-dlink-dir-685.dts | 35 +++---
- arch/arm/boot/dts/gemini-sq201.dts | 31 ++-
- 2 files changed, 41 insertions(+), 25 deletions(-)
+ arch/arm/boot/dts/gemini-dlink-dir-685.dts | 33 +++---
+ arch/arm/boot/dts/gemini-sq201.dts | 31 +++-
+ 2 files changed, 40 insertions(+), 24 deletions(-)
 
 --- a/arch/arm/boot/dts/gemini-dlink-dir-685.dts
 +++ b/arch/arm/boot/dts/gemini-dlink-dir-685.dts
@@ -84,15 +84,6 @@ Signed-off-by: Linus Walleij 
pinctrl-gmii {
mux {
function = "gmii";
-@@ -430,7 +443,7 @@
-   };
- 
-   display-controller@6a00 {
--  status = "okay";
-+  status = "disabled";
- 
-   port@0 {
-   reg = <0>;
 --- a/arch/arm/boot/dts/gemini-sq201.dts
 +++ b/arch/arm/boot/dts/gemini-sq201.dts
 @@ -41,14 +41,12 @@
-- 
2.21.0


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

[OpenWrt-Devel] [ramips] Linkit Smart 7688

2019-09-15 Thread Ivan Hörler

Hi
Now after nowing how to make a PR, im interested to know how you think about 
some thaughts of me.

Linkit Smart 7688 has a blast of tools they offer in the original firmware 
bild. Compared the one openWRT offers is verry slim.
Is that ment to be so or did nobody care until me?

Some of the Tools:
1. Automatic activation as Accesspoint, because the board is ment for IOT and 
has no Ethernet port. Right now with the official OpenWRT build can not be 
connected to any network without addtional Serial converter.

2. Luci WebGUI

3. Language: Python with PIP

4. Language: Node with NPM

5. mraa from Intel

6. some upm modules from Intel

What of this list wold be possible to integrate in to a official openWRT 
release without scratching rules?

Regards, Ivan Hörler
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

2019-09-15 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

v6: Rebased to latest master

v7: Removed unnecessary mtd-mac-address definitions
Fixed indentation mt7621_asus_rt-ac85p.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 b4634e0928..80e6a91c88 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -230,6 +230,18 @@ 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|\
+   iptime,a604m)
+   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)
@@ -297,17 +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|\
-   iptime,a604m)
-   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"
@@ -551,6 +552,9 @@ ramips_setup_macs()
zbtlink,zbt-we3526)
wan_mac=$(mtd_get_mac_binary factory 0xe006)
;;
+   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 0x8004)
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 9889079db9..a62ded4b9d 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,r6260|\
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..8084178faa
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_asus_rt-ac85p.dts
@@ -0,0 +1,162 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7621.dtsi"
+
+#incl

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

2019-09-15 Thread Birger Koblitz




On 15.09.19 12:31, m...@adrianschmutzler.de wrote:
> Hi,
> 
> see additions to the newer-ending-story below.
Well, at least in fiction it made for an excellent book. Not sure in 
engineering never-ending stories are so great.



>> +&pcie0 {
>> +wifi0: wifi@0,0 {
>> +compatible = "pci14c3,7615";
>> +reg = <0x 0 0 0 0>;
>> +mediatek,mtd-eeprom = <&factory 0x>;
>> +ieee80211-freq-limit = <240 250>;
>> +mtd-mac-address = <&factory 0x4>;
> 
> With mtd-eeprom reading from 0x0, the MAC address at 0x4 should be read by 
> default. So, you should get the same result with the mtd-mac-address line 
> removed.
Indeed, this works, I get the correct MAC address by default.

> 
>> +};
>> +};
>> +
>> +&pcie1 {
>> +wifi1: wifi@0,0 {
>> +compatible = "pci14c3,7615";
>> +reg = <0x 0 0 0 0>;
>> +mediatek,mtd-eeprom = <&factory 0x8000>;
>> +ieee80211-freq-limit = <500 600>;
>> +mtd-mac-address = <&factory 0x8004>;
> 
> See above: address is mtd-eeprom +4, so try to remove it.
Here as well.


>> +
>> +&i2c {
>> +status = "disabled";
> 
> Indent is wrong here.
Oops.

> 
> Best
> 
> Adrian
> 

will send a v7.

Best,
  Birger


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

[OpenWrt-Devel] [ramips] Linkit Smart 7688 kmod-sdhci-mt7620

2019-09-15 Thread Ivan Hörler

again from not DMARC rejected google account. see below. thanks

> Am 15.09.2019 um 12:57 schrieb Ivan Hörler via openwrt-devel 
> :
> 
> The sender domain has a DMARC Reject/Quarantine policy which disallows
> sending mailing list messages using the original "From" header.
> 
> To mitigate this problem, the original message has been wrapped
> automatically by the mailing list software.
> Von: Ivan Hörler 
> Betreff: [OpenWrt-Devel] [ramips] Linkit Smart 7688 kmod-sdhci-mt7620
> Datum: 15. September 2019 um 12:57:33 MESZ
> An: Adrian Schmutzler 
> Kopie: openwrt-devel@lists.openwrt.org
> 
> 
> Hi Adrian
> So i did: https://github.com/openwrt/openwrt/pull/2411 
> 
> Thanks for the help!
> Ivan
> 
>> Am 14.09.2019 um 22:18 schrieb Adrian Schmutzler > >:
>> 
>> Hi, thanks for implementing my suggestions. However, please do not open a 
>> new PR when doing changes, but rebase your commits in the existing branch in 
>> the future, so discussion etc. is kept.
>> 
>> For this PR, I would like you to address the following minor issues:
>> 
>> You are changing only Linkit Smart 7688, but your commit title does not 
>> express that. Maybe choose something more specific like
>> "ramips: add SD-Card support to Linkit Smart 7688"
>> In the commit description, please remove the reference to 18.06. Your commit 
>> will be applied to master, and then might be backported to older stable 
>> branches, so the reference to 18.06 is wrong in this case. Just state that 
>> the SD-Card reader is not working ATM.
>> —
>> You are receiving this because you authored the thread.
>> Reply to this email directly, view it on GitHub 
>> ,
>>  or mute the thread 
>> .
>> 
> 
> 
> 
> ___
> 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] [ramips] Linkit Smart 7688 kmod-sdhci-mt7620

2019-09-15 Thread Ivan Hörler via openwrt-devel

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hi Adrian
So i did: https://github.com/openwrt/openwrt/pull/2411
Thanks for the help!
Ivan

> Am 14.09.2019 um 22:18 schrieb Adrian Schmutzler :
> 
> Hi, thanks for implementing my suggestions. However, please do not open a new 
> PR when doing changes, but rebase your commits in the existing branch in the 
> future, so discussion etc. is kept.
> 
> For this PR, I would like you to address the following minor issues:
> 
> You are changing only Linkit Smart 7688, but your commit title does not 
> express that. Maybe choose something more specific like
> "ramips: add SD-Card support to Linkit Smart 7688"
> In the commit description, please remove the reference to 18.06. Your commit 
> will be applied to master, and then might be backported to older stable 
> branches, so the reference to 18.06 is wrong in this case. Just state that 
> the SD-Card reader is not working ATM.
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub 
> ,
>  or mute the thread 
> .
> 

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

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

2019-09-15 Thread Paul Spooren


What you suggest is about what we have right now. This kind of creates a misleading situation where 
for some targets subtargets are present, while for others paths and image names are 
"fixed" in several places to include a "generic". The reason for Paul's patch 
was to get rid of the fixes at individual places (which was/is applied somewhat inconsistently) by 
just making all targets apply to the same logic (i.e. that there is at least one subtarget).
So, the empty files are introduced to make the process of building and creating 
images afterwards simpler (to follow/understand).

I was suffering from the same problem when I dealt with OpenWrt-derived 
firmware, where I suddenly encountered a target without subtargets and had to 
implement extra code to work around that.

However, I also wondered whether one couldn't code around the necessity of the 
empty file, and just add the SUBTARGET/SUBTARGETS variables here...


Thanks for commenting, that's very much my point!

Maybe the easiest solution is to add `SUBTARGET ?= generic` to 
include/image.mk instead of introducing empty files. Will try that tomorrow.


Best,
Paul


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

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

2019-09-15 Thread mail

Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Jonas Gorski
> Sent: Samstag, 14. September 2019 11:54
> To: Paul Spooren 
> Cc: Sergey Ryazanov ; Tomasz Maciej Nowak
> ; Roman Yeryomin ; Tim Harvey
> ; Luka Perkov ; Jason Wu
> ; Alexander Couzens ; John
> Crispin ; OpenWrt Development List  de...@lists.openwrt.org>; Felix Fietkau 
> Subject: Re: [OpenWrt-Devel] [PATCH] treewide: add Generic subtarget if
> missing
> 
> On Fri, 23 Aug 2019 at 11:04, Paul Spooren  wrote:
> > 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.
> 
> If it's about (I assume generated) filenames, wouldn't it be easier to just 
> use
> "Generic" for the subtarget part of the filename if there are no subtargets?
> I'm not really a fan of unnecessary code fluff without any real function,
> especially if it means additional, mainly empty files.

What you suggest is about what we have right now. This kind of creates a 
misleading situation where for some targets subtargets are present, while for 
others paths and image names are "fixed" in several places to include a 
"generic". The reason for Paul's patch was to get rid of the fixes at 
individual places (which was/is applied somewhat inconsistently) by just making 
all targets apply to the same logic (i.e. that there is at least one subtarget).
So, the empty files are introduced to make the process of building and creating 
images afterwards simpler (to follow/understand).

I was suffering from the same problem when I dealt with OpenWrt-derived 
firmware, where I suddenly encountered a target without subtargets and had to 
implement extra code to work around that.

However, I also wondered whether one couldn't code around the necessity of the 
empty file, and just add the SUBTARGET/SUBTARGETS variables here...

Best

Adrian

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

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 v6] ramips: add support for Asus RT-AC85P

2019-09-15 Thread mail

Hi,

see additions to the newer-ending-story below.

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Birger Koblitz
> Sent: Samstag, 14. September 2019 10:52
> To: openwrt-devel@lists.openwrt.org
> Subject: [OpenWrt-Devel] [PATCH v6] ramips: add support for Asus RT-
> AC85P
> 
> 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
> 
> v6: Rebased to latest master
> 
> 
> 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 b4634e0928..80e6a91c88 100755
> --- a/target/linux/ramips/base-files/etc/board.d/02_network
> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
> @@ -230,6 +230,18 @@ 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|\
> + iptime,a604m)
> + 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)
> @@ -297,17 +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|\
> - iptime,a604m)
> - 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"
> @@ -551,6 +552,9 @@ ramips_setup_macs()
>   zbtlink,zbt-we3526)
>   wan_mac=$(mtd_get_mac_binary factory 0xe006)
>   ;;
> + 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 0x8004) diff --git
> a/target/linux/ramips/base-files/lib/upgrade/platform.sh
> b/target/linux/ramips/base-files/lib/upgrade/platform.sh
> index 9889079db9..a62ded4b9d 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|\
>

Re: [OpenWrt-Devel] [PATCH 3/3] treewide: sysupgrade: use $UPGRADE_BACKUP to check for backup

2019-09-15 Thread mail

Hi,

 

please also backport this to 19.07, since the variables for ath79 are still 
wrong there.

 

Despite, maybe have a look at my annotations below, at least one of them might 
require a fix…

 

Best

 

Adrian

 

From: Adrian Schmutzler [mailto:m...@adrianschmutzler.de] 
Sent: Mittwoch, 11. September 2019 12:56
To: 'Rafał Miłecki' ; openwrt-devel@lists.openwrt.org
Cc: 'Rafał Miłecki' ; 'Jonas Gorski' 
; 'Jo-Philipp Wich' ; 'John Crispin' 

Subject: RE: [OpenWrt-Devel] [PATCH 3/3] treewide: sysupgrade: use 
$UPGRADE_BACKUP to check for backup

 

Hi, 

when looking at the merged patch (unfortunately only then), I found some 
"issues" (see below): 

> -Original Message- 
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On 
> Behalf Of Rafal Milecki 
> Sent: Freitag, 6. September 2019 07:11 
> To: openwrt-devel@lists.openwrt.org   
> Cc: Rafał Miłecki mailto:ra...@milecki.pl> >; Jonas Gorski 
> mailto:jonas.gor...@gmail.com> >; Jo-Philipp Wich 
> mailto:j...@mein.io> >; John Crispin

> mailto:j...@phrozen.org> > 
> Subject: [OpenWrt-Devel] [PATCH 3/3] treewide: sysupgrade: use 
> $UPGRADE_BACKUP to check for backup 
> 
> From: Rafał Miłecki mailto:ra...@milecki.pl> > 
> 
> Now that $UPGRADE_BACKUP is set conditionally there is no need to check 
> the $UPGRADE_OPT_SAVE_CONFIG anymore. All conditions can be simplified. 
> 
> Signed-off-by: Rafał Miłecki mailto:ra...@milecki.pl> > 
> --- 
>  package/base-files/files/lib/upgrade/common.sh  | 2 +- 
>  package/base-files/files/lib/upgrade/do_stage2  | 2 +- 
>  package/base-files/files/sbin/sysupgrade| 1 - 
>  target/linux/ar71xx/base-files/lib/upgrade/dir825.sh| 2 +- 
>  target/linux/ar71xx/base-files/lib/upgrade/openmesh.sh  | 2 +- 
>  target/linux/ar71xx/base-files/lib/upgrade/platform.sh  | 4 ++-- 
>  target/linux/ath25/base-files/lib/upgrade/platform.sh   | 2 +- 
>  target/linux/ath79/base-files/lib/upgrade/platform.sh   | 4 ++-- 
>  target/linux/imx6/base-files/lib/upgrade/platform.sh| 2 +- 
>  target/linux/ipq40xx/base-files/lib/upgrade/openmesh.sh | 2 +- 
>  target/linux/ipq40xx/base-files/lib/upgrade/platform.sh | 2 +- 
>  target/linux/ixp4xx/base-files/lib/upgrade/platform.sh  | 2 +- 
>  12 files changed, 13 insertions(+), 14 deletions(-) 
> 
> diff --git a/package/base-files/files/lib/upgrade/common.sh 
> b/package/base-files/files/lib/upgrade/common.sh 
> index 8e7866f698..0d3162d4fc 100644 
> --- a/package/base-files/files/lib/upgrade/common.sh 
> +++ b/package/base-files/files/lib/upgrade/common.sh 
> @@ -220,7 +220,7 @@ indicate_upgrade() { 
>  # $(2): (optional) pipe command to extract firmware, e.g. dd bs=n skip=m 
>  default_do_upgrade() { 
>   sync 
> - if [ "$UPGRADE_OPT_SAVE_CONFIG" -eq 1 ]; then 
> + if [ -n "$UPGRADE_BACKUP" ]; then 

Any reason why this is "-n" and not "-f" as below? 

>   get_image "$1" "$2" | mtd $MTD_ARGS $MTD_CONFIG_ARGS -j 
> "$UPGRADE_BACKUP" write - "${PART_NAME:- 
> image}" 
>   else 
>   get_image "$1" "$2" | mtd $MTD_ARGS write - 
> "${PART_NAME:-image}" 
> diff --git a/package/base-files/files/lib/upgrade/do_stage2 
> b/package/base-files/files/lib/upgrade/do_stage2 
> index 0e6cc1bfc3..0e32445743 100755 
> --- a/package/base-files/files/lib/upgrade/do_stage2 
> +++ b/package/base-files/files/lib/upgrade/do_stage2 
> @@ -11,7 +11,7 @@ else 
>   default_do_upgrade "$IMAGE" 
>  fi 
> 
> -if [ "$UPGRADE_OPT_SAVE_CONFIG" -eq 1 ] && type 'platform_copy_config' 
> >/dev/null 2>/dev/null; then 
> +if [ -n "$UPGRADE_BACKUP" ] && type 'platform_copy_config' >/dev/null 
> 2>/dev/null; then 

Here I'm not so sure about "-f" vs. "-n" ... 

>   platform_copy_config 
>  fi 
> 
> diff --git a/package/base-files/files/sbin/sysupgrade 
> b/package/base-files/files/sbin/sysupgrade 
> index f18143bff4..935d08048e 100755 
> --- a/package/base-files/files/sbin/sysupgrade 
> +++ b/package/base-files/files/sbin/sysupgrade 
> @@ -371,7 +371,6 @@ else 
>   $backup_attr 
>   \"command\": $(json_string "$COMMAND"), 
>   \"options\": { 
> - \"save_config\": $SAVE_CONFIG, 
>   \"save_partitions\": $SAVE_PARTITIONS 
>   } 
>   }" 
> diff --git a/target/linux/ar71xx/base-files/lib/upgrade/dir825.sh 
> b/target/linux/ar71xx/base-files/lib/upgrade/dir825.sh

> index c694c2e6f2..e991a06b7a 100644 
> --- a/target/linux/ar71xx/base-files/lib/upgrade/dir825.sh 
> +++ b/target/linux/ar71xx/base-files/lib/upgrade/dir825.sh 
> @@ -75,7 +75,7 @@ dir825b_do_upgrade_combined() { 
> 
>   if [ -n "$fw_mtd" ] &&  [ ${fw_blocks:-0} -gt 0 ]; then 
>   local append="" 
> - [ -f "$UPGRADE_BACKUP" -a "$UPGRADE_OPT_SAVE_CONFIG" -eq 1 ] && 
> append="-j $UPGRADE_BACKUP" 
> + [ -f "$UPGRADE_BACKUP" ] && append="-j $UPGRADE_BACKUP" 
> 
>   sync 
>   dd

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

Re: [OpenWrt-Devel] [PATCH 3/3] treewide: sysupgrade: use $UPGRADE_BACKUP to check for backup

Re: [OpenWrt-Devel] [PATCH 3/3] treewide: sysupgrade: use $UPGRADE_BACKUP to check for backup

[OpenWrt-Devel] [sdwalker/sdwalker.github.io] 4b1ac0: This week's update

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

[OpenWrt-Devel] [PATCH] gemini: dir685: Restore graphics

[OpenWrt-Devel] [ramips] Linkit Smart 7688

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

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

[OpenWrt-Devel] [ramips] Linkit Smart 7688 kmod-sdhci-mt7620

[OpenWrt-Devel] [ramips] Linkit Smart 7688 kmod-sdhci-mt7620

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

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

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

Re: [OpenWrt-Devel] [PATCH 3/3] treewide: sysupgrade: use $UPGRADE_BACKUP to check for backup

15 matches

Site Navigation

Mail list logo

Footer information