[LEDE-DEV] [PATCH] ar71xx: tp-link.mk: always include device version in image and DEVICE_TITLE
There are currently several supported TP-Link devices without specified version number in image name and/or DEVICE_TITLE (e.g. WBS210, WBS510, TL-WR810N, TL-WA7510N, TL-WPA8630), but vendor website shows that there are already more than one version of them on the market. For devices like Archer C5, which second version is based on a total different platform, missing version number in DEVICE_TITLE (used in menuconfig) might be misleading for users. To make it less confusing for users and easier to maintain in future, include version number in image name and DEVICE_TITLE for all TP-Link devices, even if there is only one version of device at the moment. Also, keep DEVICE_TITLE in same format for all TP-Link devices. Signed-off-by: Piotr Dymacz --- target/linux/ar71xx/image/tp-link.mk | 108 +-- 1 file changed, 54 insertions(+), 54 deletions(-) diff --git a/target/linux/ar71xx/image/tp-link.mk b/target/linux/ar71xx/image/tp-link.mk index 7971213..529f6a3 100644 --- a/target/linux/ar71xx/image/tp-link.mk +++ b/target/linux/ar71xx/image/tp-link.mk @@ -134,8 +134,8 @@ define Device/archer-c60-v1 endef TARGET_DEVICES += archer-c60-v1 -define Device/cpe510-520 - DEVICE_TITLE := TP-LINK CPE510/520 +define Device/cpe510-520-v1 + DEVICE_TITLE := TP-LINK CPE510/520 v1 DEVICE_PACKAGES := rssileds MTDPARTS := spi0.0:128k(u-boot)ro,64k(pation-table)ro,64k(product-info)ro,1536k(kernel),6144k(rootfs),192k(config)ro,64k(ART)ro,7680k@0x4(firmware) IMAGE_SIZE := 7680k @@ -149,33 +149,33 @@ define Device/cpe510-520 IMAGE/factory.bin := append-rootfs | tplink-safeloader factory endef -define Device/cpe210-220 - $(Device/cpe510-520) - DEVICE_TITLE := TP-LINK CPE210/220 +define Device/cpe210-220-v1 + $(Device/cpe510-520-v1) + DEVICE_TITLE := TP-LINK CPE210/220 v1 DEVICE_PACKAGES := rssileds BOARDNAME := CPE210 TPLINK_BOARD_NAME := CPE210 endef -define Device/wbs210 - $(Device/cpe510-520) - DEVICE_TITLE := TP-LINK WBS210 +define Device/wbs210-v1 + $(Device/cpe510-520-v1) + DEVICE_TITLE := TP-LINK WBS210 v1 DEVICE_PACKAGES := rssileds BOARDNAME := WBS210 TPLINK_BOARD_NAME := WBS210 endef -define Device/wbs510 - $(Device/cpe510-520) - DEVICE_TITLE := TP-LINK WBS510 +define Device/wbs510-v1 + $(Device/cpe510-520-v1) + DEVICE_TITLE := TP-LINK WBS510 v1 DEVICE_PACKAGES := rssileds BOARDNAME := WBS510 TPLINK_BOARD_NAME := WBS510 endef -TARGET_DEVICES += cpe210-220 cpe510-520 wbs210 wbs510 +TARGET_DEVICES += cpe210-220-v1 cpe510-520-v1 wbs210-v1 wbs510-v1 -define Device/re450 - DEVICE_TITLE := TP-LINK RE450 +define Device/re450-v1 + DEVICE_TITLE := TP-LINK RE450 v1 DEVICE_PACKAGES := kmod-ath10k ath10k-firmware-qca988x MTDPARTS := spi0.0:128k(u-boot)ro,1344k(kernel),4672k(rootfs),64k(pation-table)ro,64k(product-info)ro,1856k(config)ro,64k(art)ro,6016k@0x2(firmware) IMAGE_SIZE := 7936k @@ -188,10 +188,10 @@ define Device/re450 IMAGE/sysupgrade.bin := append-rootfs | tplink-safeloader sysupgrade IMAGE/factory.bin := append-rootfs | tplink-safeloader factory endef -TARGET_DEVICES += re450 +TARGET_DEVICES += re450-v1 -define Device/eap120 - DEVICE_TITLE := TP-LINK EAP120 +define Device/eap120-v1 + DEVICE_TITLE := TP-LINK EAP120 v1 MTDPARTS := spi0.0:128k(u-boot)ro,64k(pation-table)ro,64k(product-info)ro,1536k(kernel),14336k(rootfs),192k(config)ro,64k(ART)ro,15872k@0x4(firmware) IMAGE_SIZE := 15872k BOARDNAME := EAP120 @@ -203,7 +203,7 @@ define Device/eap120 IMAGE/sysupgrade.bin := append-rootfs | tplink-safeloader sysupgrade IMAGE/factory.bin := append-rootfs | tplink-safeloader factory endef -TARGET_DEVICES += eap120 +TARGET_DEVICES += eap120-v1 define Device/tl-wdr4300-v1 $(Device/tplink-8mlzma) @@ -236,7 +236,7 @@ endef define Device/tl-wdr4300-v1-il $(Device/tplink-8mlzma) - DEVICE_TITLE := TP-LINK TL-WDR4300 v1 IL + DEVICE_TITLE := TP-LINK TL-WDR4300 v1 (IL) DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ledtrig-usbport BOARDNAME := TL-WDR4300 DEVICE_PROFILE := TLWDR4300 @@ -261,7 +261,7 @@ TARGET_DEVICES += tl-wdr3500-v1 tl-wdr3600-v1 tl-wdr4300-v1 tl-wdr4300-v1-il tl- define Device/tl-wdr6500-v2 $(Device/tplink-8mlzma) - DEVICE_TITLE := TP-LINK TL-WDR6500v2 + DEVICE_TITLE := TP-LINK TL-WDR6500 v2 DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ledtrig-usbport kmod-ath10k ath10k-firmware-qca988x KERNEL := kernel-bin | patch-cmdline | lzma | uImage lzma KERNEL_INITRAMFS := kernel-bin | patch-cmdline | lzma | uImage lzma | mktplinkfw-combined @@ -274,7 +274,7 @@ TARGET_DEVICES += tl-wdr6500-v2 define Device/tl-wdr3320-v2 $(Device/tplink-4mlzma) - DEVICE_TITLE := TP-LINK TL-WDR3320v2 + DEVICE_TITLE := TP-LINK TL-WDR3320 v2 DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ledtrig-usbport BOARDNAME = TL-WDR3320-v2 DEVICE_PROFILE = TLWDR3320V2 @@ -285,7 +285,7 @@ TARGET_DEVICES += tl-wdr3320-v2 define
Re: [LEDE-DEV] [PATCH] ar71xx: Add TP-LINK TL-WR841N v12 support.
Hello Vittorio, On 25.03.2017 18:08, Vittorio Gambaletta (VittGam) wrote: This router has the same hardware of TP-LINK TL-WR841N v11 (same FCC ID, same TFTP image name...). The stock firmware web interface does not seem to accept the LEDE factory image, but it can be flashed via the u-boot TFTP recovery by long-pressing the reset button after power on. Did you try factory image but with changed filename (sometimes TP-Link web gui doesn't accept files with long name)? What kind of error are you getting with LEDE factory image? BTW. It seems that TP-Link already released v13 version of this device in Europe but this time it's (surprise!) MediaTek (MT7628?) based. The TFTP image name is wr841nv11_tp_recovery.bin (yes, v11, not v12). Signed-off-by: Vittorio Gambaletta --- target/linux/ar71xx/image/tp-link.mk | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/target/linux/ar71xx/image/tp-link.mk b/target/linux/ar71xx/image/tp-link.mk index cf2e5e7..705e400 100644 --- a/target/linux/ar71xx/image/tp-link.mk +++ b/target/linux/ar71xx/image/tp-link.mk @@ -736,6 +736,17 @@ define Device/tl-wr841-v11 IMAGE/factory-eu.bin := append-rootfs | mktplinkfw factory -C EU endef +define Device/tl-wr841-v12 + $(Device/tplink-4mlzma) Can you use here $(Device/tl-wr841-v11) instead and then overwrite only two variables which are different: DEVICE_TITLE and TPLINK_HWID? -- Best regards, Piotr Dymacz + DEVICE_TITLE := TP-LINK TL-WR841N/ND v12 + BOARDNAME := TL-WR841N-v11 + DEVICE_PROFILE := TLWR841 + TPLINK_HWID := 0x08410012 + IMAGES += factory-us.bin factory-eu.bin + IMAGE/factory-us.bin := append-rootfs | mktplinkfw factory -C US + IMAGE/factory-eu.bin := append-rootfs | mktplinkfw factory -C EU +endef + define Device/tl-wr842n-v1 $(Device/tplink-8m) DEVICE_TITLE := TP-LINK TL-WR842N/ND v1 @@ -778,7 +789,7 @@ define Device/tl-wr847n-v8 DEVICE_PROFILE := TLWR841 TPLINK_HWID := 0x08470008 endef -TARGET_DEVICES += tl-wr840n-v2 tl-wr840n-v3 tl-wr841-v1.5 tl-wr841-v3 tl-wr841-v5 tl-wr841-v7 tl-wr841-v8 tl-wr841-v9 tl-wr841-v10 tl-wr841-v11 tl-wr842n-v1 tl-wr842n-v2 tl-wr842n-v3 tl-wr843nd-v1 tl-wr847n-v8 +TARGET_DEVICES += tl-wr840n-v2 tl-wr840n-v3 tl-wr841-v1.5 tl-wr841-v3 tl-wr841-v5 tl-wr841-v7 tl-wr841-v8 tl-wr841-v9 tl-wr841-v10 tl-wr841-v11 tl-wr841-v12 tl-wr842n-v1 tl-wr842n-v2 tl-wr842n-v3 tl-wr843nd-v1 tl-wr847n-v8 define Device/tl-wr941nd-v2 $(Device/tplink-4m) ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v2] ar71xx: Add TP-LINK TL-WR841N v12 support.
Hello Vittorio, On 26.03.2017 09:55, Vittorio Gambaletta (VittGam) wrote: This router has the same hardware of TP-LINK TL-WR841N v11 (same FCC ID, same TFTP image name...). The stock firmware web interface does not seem to accept the LEDE factory image, but it can be flashed via the u-boot TFTP recovery by long-pressing the reset button after power on. So, I have just made a test (using TL-WR841N v9 "converted" to v12 EU) and factory-eu image works without any problems (Firefox 52). I'm going to pick up your patch with small change in commit message and subject (please, don't add dot at the end of the subject next time). -- Best regards, Piotr Dymacz The TFTP image name is wr841nv11_tp_recovery.bin (yes, v11, not v12). Signed-off-by: Vittorio Gambaletta --- diff --git a/target/linux/ar71xx/image/tp-link.mk b/target/linux/ar71xx/image/tp-link.mk index cf2e5e7..cea039d 100644 --- a/target/linux/ar71xx/image/tp-link.mk +++ b/target/linux/ar71xx/image/tp-link.mk @@ -736,6 +736,12 @@ define Device/tl-wr841-v11 IMAGE/factory-eu.bin := append-rootfs | mktplinkfw factory -C EU endef +define Device/tl-wr841-v12 + $(Device/tl-wr841-v11) + DEVICE_TITLE := TP-LINK TL-WR841N/ND v12 + TPLINK_HWID := 0x08410012 +endef + define Device/tl-wr842n-v1 $(Device/tplink-8m) DEVICE_TITLE := TP-LINK TL-WR842N/ND v1 @@ -778,7 +784,7 @@ define Device/tl-wr847n-v8 DEVICE_PROFILE := TLWR841 TPLINK_HWID := 0x08470008 endef -TARGET_DEVICES += tl-wr840n-v2 tl-wr840n-v3 tl-wr841-v1.5 tl-wr841-v3 tl-wr841-v5 tl-wr841-v7 tl-wr841-v8 tl-wr841-v9 tl-wr841-v10 tl-wr841-v11 tl-wr842n-v1 tl-wr842n-v2 tl-wr842n-v3 tl-wr843nd-v1 tl-wr847n-v8 +TARGET_DEVICES += tl-wr840n-v2 tl-wr840n-v3 tl-wr841-v1.5 tl-wr841-v3 tl-wr841-v5 tl-wr841-v7 tl-wr841-v8 tl-wr841-v9 tl-wr841-v10 tl-wr841-v11 tl-wr841-v12 tl-wr842n-v1 tl-wr842n-v2 tl-wr842n-v3 tl-wr843nd-v1 tl-wr847n-v8 define Device/tl-wr941nd-v2 $(Device/tplink-4m) ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] ar71xx: add support for TP-Link TL-WDR5600 v1
Hello Jie,
Thank you for your patch, unfortunately it fails to apply, please rebase
and resend it.
Also, please see my comments inline, below.
On 31.03.2017 13:06, Jie Ke wrote:
From: Soundtrack9407
Full and real name, please.
Specifications:
- SoC: Qualcomm QCA9561 (750MHz)
- RAM: 64MB
- Storage: 8MB (Winbond w25q64)
- Wireless: Qualcomm QCA9561 + QCA9887
- Ethernet: 4+1 x 100M
http://www.tp-link.com.cn/product_415.html
The most important question here is:
How the user can install LEDE on this device?
In fact, I have this device here and I know that the vendor firmware
(both the bootloader and the system) contains RSA signature verification
and when I try factory image, built based on your patch, in vendor GUI
I'm getting: "RSA signature verification failed" (translation).
Also, the U-Boot HTTP recovery mode doesn't accept the image:
CC 96 72 CA DA F7 FE 1C 67 4B A4 67 1A BC 35 57
error: RSA check failed.
check firmware failed, exit
So, why should we include support for this device if there is no
common/normal way to use it at all (at least for now)?
Signed-off-by: Soundtrack9407
Full and real name, please.
---
target/linux/ar71xx/base-files/etc/board.d/01_leds | 7 +
.../linux/ar71xx/base-files/etc/board.d/02_network | 1 +
target/linux/ar71xx/base-files/etc/diag.sh | 1 +
.../etc/hotplug.d/firmware/11-ath10k-caldata | 1 +
target/linux/ar71xx/base-files/lib/ar71xx.sh | 6 +
.../ar71xx/base-files/lib/upgrade/platform.sh | 2 +
target/linux/ar71xx/config-4.4 | 1 +
.../ar71xx/files/arch/mips/ath79/Kconfig.openwrt | 10 ++
target/linux/ar71xx/files/arch/mips/ath79/Makefile | 1 +
.../files/arch/mips/ath79/mach-tl-wdr5600-v1.c | 143 +
.../linux/ar71xx/files/arch/mips/ath79/machtypes.h | 1 +
target/linux/ar71xx/image/tp-link.mk | 13 ++
12 files changed, 187 insertions(+)
create mode 100644
target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wdr5600-v1.c
diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds
b/target/linux/ar71xx/base-files/etc/board.d/01_leds
index 32d4931..82b08f4 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -644,6 +644,13 @@ tl-wdr4900-v2)
ucidef_set_led_wlan "wlan2g" "WLAN2G" "tp-link:blue:wlan2g" "phy0tpt"
ucidef_set_led_wlan "wlan5g" "WLAN5G" "tp-link:blue:wlan5g" "phy1tpt"
;;
+tl-wdr5600-v1)
+ ucidef_set_led_netdev "wan" "WAN" "tp-link:green:wan" "eth0"
+ ucidef_set_led_switch "lan1" "LAN1" "tp-link:green:lan1" "switch0"
"0x02"
+ ucidef_set_led_switch "lan2" "LAN2" "tp-link:green:lan2" "switch0"
"0x04"
+ ucidef_set_led_switch "lan3" "LAN3" "tp-link:green:lan3" "switch0"
"0x08"
+ ucidef_set_led_switch "lan4" "LAN4" "tp-link:green:lan4" "switch0"
"0x10"
+ ;;
This one looks almost the same as for tl-wdr6500-v2 and as these boards
seem to be very similar from h/w point of view... there is a bug
somewhere here.
I suppose WAN LED for tl-wdr6500-v2 is assigned to a wrong interface
(eth1 instead of eth0)... just a side note.
tl-wdr6500-v2|\
tl-wr741nd)
ucidef_set_led_netdev "wan" "WAN" "tp-link:green:wan" "eth1"
diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network
b/target/linux/ar71xx/base-files/etc/board.d/02_network
index a55e50a..6ea3e73 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -292,6 +292,7 @@ ar71xx_setup_interfaces()
r6100|\
smart-300|\
tl-mr3420-v2|\
+ tl-wdr5600-v1|\
tl-wdr6500-v2|\
tl-wr841n-v8|\
tl-wr940n-v4|\
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
b/target/linux/ar71xx/base-files/etc/diag.sh
index 461d0da..3d23502 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -409,6 +409,7 @@ get_status_led() {
tl-wr2543n)
status_led="tp-link:green:wps"
;;
+ tl-wdr5600-v1|\
tl-wdr6500-v2)
status_led="tp-link:white:system"
;;
diff --git
a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 4938e26..bdb1c35 100644
--- a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -94,6 +94,7 @@ case "$FIRMWARE" in
;;
archer-c59-v1|\
archer-c60-v1|\
+ tl-wdr5600-v1|\
tl-wdr6500-v2)
ath10kcal_extract "art" 20480 2116
ath10kcal_patch_mac $(macaddr_add $(cat
/sys/class/net/eth1/address) -2)
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 8c87737.
Re: [LEDE-DEV] [PATCH] ar71xx: add Engenius ENH200EXT support
Hello Paul,
On 31.03.2017 22:38, Paul Oranje wrote:
This POE access point suited for outside usage needs an external antenna.
According FCC documentation the ENH200EXT (needs external antenna) and the
ENH200 (with internal antenna) are electrically equal to the Allnet ALL0258N.
The stock image does not allow install of a LEDE factory image, but an
initramfs image (lede-ar71xx-generic-enh200ext-initramfs-uImage.bin) can be
loaded via u-boot recovery procedure (long press reset at power-on until all
LEDS burn). The u-boot recovery procedure boots an image named
vmlinux-art-ramdisk from 192.168.1.101.
Once booted the sysupgrade image can be flashed from the booted iniramfs LEDE.
Only abnormality is that for some unknown reason the txpower cannot be set
higher than 16 dBm whereas the Engenius stock firmware allows a maximum of 27
dBm.
First of all, thank you for your patch.
Unfortunately, it doesn't apply and seems to be corrupted:
./scripts/checkpatch.pl 745796.patch
ERROR: patch seems to be corrupt (line wrapped?)
#45: FILE: package/boot/uboot-envtools/files/ar71xx:26:
cr3000|\
WARNING: line over 80 characters
#170: FILE: target/linux/ar71xx/files/arch/mips/ath79/mach-enh200ext.c:5:
+ * Copyright (C) 2017 Paul Oranje (ENH200EXT is same
device as ALL0258N)
Please, fix it (you can use above script and/or 'git apply --check
--verbose' to test if your patch is ok and can be applied cleanly) and
resend.
Also, make sure you follow rules from [1], especially the one about
commit message/description (line wrap).
And, one more comment inline, below.
Signed-off-by: Paul Oranje
---
package/boot/uboot-envtools/files/ar71xx | 1 +
target/linux/ar71xx/base-files/etc/board.d/01_leds | 3 +-
.../linux/ar71xx/base-files/etc/board.d/02_network | 1 +
target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 +
.../ar71xx/base-files/lib/upgrade/platform.sh | 6 +-
target/linux/ar71xx/config-4.4 | 1 +
.../ar71xx/files/arch/mips/ath79/Kconfig.openwrt | 9 +++
target/linux/ar71xx/files/arch/mips/ath79/Makefile | 1 +
.../ar71xx/files/arch/mips/ath79/mach-enh200ext.c | 89 ++
.../linux/ar71xx/files/arch/mips/ath79/machtypes.h | 1 +
target/linux/ar71xx/image/legacy-devices.mk| 6 ++
target/linux/ar71xx/image/legacy.mk| 2 +
Please, include image support for this device in generic.mk. We really
don't want to (and won't) include more devices in legacy.mk.
[1] https://lede-project.org/submitting-patches
--
Cheers,
Piotr
target/linux/ar71xx/mikrotik/config-default| 1 +
target/linux/ar71xx/nand/config-default| 1 +
14 files changed, 122 insertions(+), 3 deletions(-)
create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-enh200ext.c
diff --git a/package/boot/uboot-envtools/files/ar71xx
b/package/boot/uboot-envtools/files/ar71xx
index 3a5d269..a104c3a 100644
--- a/package/boot/uboot-envtools/files/ar71xx
+++ b/package/boot/uboot-envtools/files/ar71xx
@@ -27,6 +27,7 @@ cpe870|\
cr3000|\
cr5000|\
eap300v2|\
+enh200ext|\
gl-ar300m|\
hornet-ub|\
hornet-ub-x2|\
diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds
b/target/linux/ar71xx/base-files/etc/board.d/01_leds
index 686ae31..cf9c3ae 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -28,7 +28,8 @@ alfa-nx)
ucidef_set_led_netdev "lan" "LAN" "alfa:green:led_3" "eth1"
;;
all0258n|\
-all0315n)
+all0315n|\
+enh200ext)
ucidef_set_rssimon "wlan0" "20" "1"
ucidef_set_led_rssi "rssilow" "RSSILOW" "$board:red:rssilow" "wlan0" "1" "40" "0"
"6"
ucidef_set_led_rssi "rssimedium" "RSSIMEDIUM" "$board:yellow:rssimedium" "wlan0" "30" "80"
"-29" "5"
diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network
b/target/linux/ar71xx/base-files/etc/board.d/02_network
index 20b34e8..014404e 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -155,6 +155,7 @@ ar71xx_setup_interfaces()
dlan-hotspot|\
dlan-pro-500-wp|\
dr344|\
+ enh200ext|\
ja76pf2|\
rocket-m-ti|\
ubnt-unifi-outdoor)
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 4951e5b..f365feb 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -619,6 +619,9 @@ ar71xx_board_detect() {
*"EmbWir-Dorin-Router")
name="ew-dorin-router"
;;
+ *"ENH200EXT")
+ name="enh200ext"
+ ;;
*"EPG5000")
name="epg5000"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 364a32f..b4a84c2 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platfo
Re: [LEDE-DEV] [PATCH] ar71xx: add Engenius ENH200EXT support
Hello Paul, On 05.04.2017 23:23, Paul Oranje wrote: Hello, I’m wondering how to make LEDE build automatically an initramfs image (for use with u-boot tftp recovery boot), when the ENH200EXT is selected as the target device. By setting "CONFIG_TARGET_ROOTFS_INITRAMFS=y" a working image is build that can be tftp-booted alright, but I would prefer that it is build automatically beside the sysupgrade image. The context would, as requested, be "target/linux/ar71xx/image/generic.mk". The "generic" subtarget doesn't have included "ramdisk" feature: https://github.com/lede-project/source/blob/master/target/linux/ar71xx/generic/target.mk#L2 It's the one responsible for selecting the "TARGET_ROOTFS_INITRAMFS": https://github.com/lede-project/source/blob/master/scripts/target-metadata.pl#L34 https://github.com/lede-project/source/blob/master/config/Config-images.in#L11 On the other hand, "mikrotik" subtarget uses initramfs images as they are required for initial LEDE flash: https://github.com/lede-project/source/blob/master/target/linux/ar71xx/mikrotik/target.mk#L2 Is the initramfs image required for initial LEDE image flash on your device or is it just useful with recovery mode? From what I have understood so far, the clause would be something like: define Device/enh200ext DEVICE_TITLE := Engenius ENH200EXT DEVICE_PACKAGES := rssileds BOARDNAME := ENH200EXT CONSOLE := ttyS0,115200 Side note: this is default under ar71xx target, drop this line in your next patch please. Defaults: https://github.com/lede-project/source/blob/master/target/linux/ar71xx/image/Makefile#L99 -- Cheers, Piotr IMAGE_SIZE := 8192k IMAGES := initramfs.bin sysupgrade.bin MTDPARTS := spi0.0:256k(u-boot)ro,64k(u-boot-env),6272k(firmware),1536k(failsafe),64k(art)ro endef TARGET_DEVICES += enh200ext The sysupgrade image is build, but the initramfs image is not build. I suppose an IMAGE/initramfs declaration must be added, but I do not know what to declare or call. Some help would be appreciated, ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] ar71xx: add Engenius ENH200EXT support
Hello Paul, Sorry for a late reply. On 06.04.2017 14:24, Paul Oranje wrote: Thanks for the info. The systematics for the generation of the build config from the makefiles is still quite obscure to me. A wiki lemma that puts some light in this would be welcome; once I do understand I may write one. That would be really kind. See my questions/comments/replies in-line below. Ciao, Paul Op 6 apr. 2017, om 09:51 heeft Piotr Dymacz het volgende geschreven: Hello Paul, On 05.04.2017 23:23, Paul Oranje wrote: Hello, I’m wondering how to make LEDE build automatically an initramfs image (for use with u-boot tftp recovery boot), when the ENH200EXT is selected as the target device. By setting "CONFIG_TARGET_ROOTFS_INITRAMFS=y" a working image is build that can be tftp-booted alright, but I would prefer that it is build automatically beside the sysupgrade image. The context would, as requested, be "target/linux/ar71xx/image/generic.mk". The "generic" subtarget doesn't have included "ramdisk" feature: https://github.com/lede-project/source/blob/master/target/linux/ar71xx/generic/target.mk#L2 It's the one responsible for selecting the "TARGET_ROOTFS_INITRAMFS": https://github.com/lede-project/source/blob/master/scripts/target-metadata.pl#L34 Does that mean that the initramfs can only be triggered by manually setting “CONFIG_TARGET_ROOTFS_INITRAMFS=y” ? AFAIK, yes. That would mean that the LEDE build-bots would not generate initramfs images and people would need for the initial install to build such images themselves. Likely I’ve not understood well how it works and what follows hints how to do it. https://github.com/lede-project/source/blob/master/config/Config-images.in#L11 On the other hand, "mikrotik" subtarget uses initramfs images as they are required for initial LEDE flash: https://github.com/lede-project/source/blob/master/target/linux/ar71xx/mikrotik/target.mk#L2 Adding "FEATURES += ramdisk” to the "Device/enh200ext” definition in "target/linux/ar71xx/image/generic.mk” does not work (tried it). "FEATURES" variable belongs to the target, not particular device and thus cannot be changed/extended like this. Since the initramfs is only needed for some ar71xx target profiles, the FEATURES declaration should not be set in “target/linux/ar71xx/generic/target.mk”. If the FEATURE should be set in the context of a target.mk, then a new makefile "target/linux/ar71xx/engenius/target.mk" would be needed, or to what other makefile could/should "FEATURES += ramdisk” then be added ? A separate subtarget just for one device is a bad idea. AFAIK, the only way to include initramfs by default would require extending "FEATURES" in ar71xx/generic subtarget target.mk config, but... Is the initramfs image required for initial LEDE image flash on your device or is it just useful with recovery mode? The stock firmware cannot install a LEDE factory image, so the initramfs image is indeed needed for the initial install. I'm not sure if enabling initramfs images for a whole subtarget just because of a single device makes sense at all. The preferred way is to have a working "factory" image for this device or at least detailed how-to for installing "sysupgrade" image inside vendor firmware, using some custom approach (failsafe?). Can you explain what/where is exactly problem with upgrade from vendor firmware to LEDE on your device? I have just extracted enh200ext-etsi-v1.5.1.0.bin (downloaded from [1]), and I see that it's based on very old OpenWrt version (KAMIKAZE, r20146). mtd and sysupgrade tools are there, also failsafe could be working. What's more, vendor upgrade script is just a regular shell script (/etc/fwupgrade.sh) and doesn't look complicated. With little bit more effort you should be able to find out (based on this script code) how to prepare a working "factory" image. If there is a working failsafe in this device, you could also make use of it and install LEDE with "mtd -r write...". [1] http://www.engeniusnetworks.com/product/product.php?c=14&s=34&p=92 -- Cheers, Piotr From what I have understood so far, the clause would be something like: define Device/enh200ext DEVICE_TITLE := Engenius ENH200EXT DEVICE_PACKAGES := rssileds BOARDNAME := ENH200EXT CONSOLE := ttyS0,115200 Side note: this is default under ar71xx target, drop this line in your next patch please. OK, I’ll drop the CONSOLE line. Defaults: https://github.com/lede-project/source/blob/master/target/linux/ar71xx/image/Makefile#L99 -- Cheers, Piotr IMAGE_SIZE := 8192k IMAGES := initramfs.bin sysupgrade.bin MTDPARTS := spi0.0:256k(u-boot)ro,64k(u-boot-env),6272k(firmware),1536k(failsafe),64k(art)ro
Re: [LEDE-DEV] [PATCH] ramips: Add support for GL-MT300N-V2
Hello,
Please, make sure to add a proper SoB line as described in "Submitting
patches": [1].
Also, could you please include in your commit message short description
about the hardware and how to install LEDE on it? Have a look at the
recent ramips board additions for some examples: [2].
[1] https://lede-project.org/submitting-patches
[2]
https://github.com/lede-project/source/search?&q=ramips+add+support+for&type=Commits
--
Cheers,
Piotr
On 04.05.2017 08:41, kysonlok wrote:
This patches adds support for GL-MT300N-V2 router.
Signed-off-by: kysonlok
---
target/linux/ramips/base-files/etc/board.d/01_leds | 1 +
.../linux/ramips/base-files/etc/board.d/02_network | 1 +
target/linux/ramips/base-files/lib/ramips.sh | 3 +
.../ramips/base-files/lib/upgrade/platform.sh | 1 +
target/linux/ramips/dts/GL-MT300N-V2.dts | 135 +
target/linux/ramips/image/mt7628.mk| 8 ++
6 files changed, 149 insertions(+)
create mode 100644 target/linux/ramips/dts/GL-MT300N-V2.dts
diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds
b/target/linux/ramips/base-files/etc/board.d/01_leds
index 52542ec..101c1c2 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -186,6 +186,7 @@ fonera20n)
;;
gl-mt300a|\
gl-mt300n|\
+gl-mt300n-v2|\
gl-mt750)
set_wifi_led "$board:wlan"
;;
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 80a3bc2..6af0065 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -156,6 +156,7 @@ ramips_setup_interfaces()
f5d8235-v2|\
gl-mt300a|\
gl-mt300n|\
+ gl-mt300n-v2|\
gl-mt750|\
hg255d|\
jhr-n805r|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh
b/target/linux/ramips/base-files/lib/ramips.sh
index 87cb7ff..1e031cd 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -214,6 +214,9 @@ ramips_board_detect() {
*"GL-MT300N")
name="gl-mt300n"
;;
+ *"GL-MT300N-V2")
+ name="gl-mt300n-v2"
+ ;;
*"GL-MT750")
name="gl-mt750"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index adad8da..2c50c3c 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -64,6 +64,7 @@ platform_check_image() {
freestation5|\
gl-mt300a|\
gl-mt300n|\
+ gl-mt300n-v2|\
gl-mt750|\
hc5*61|\
hc5661a|\
diff --git a/target/linux/ramips/dts/GL-MT300N-V2.dts
b/target/linux/ramips/dts/GL-MT300N-V2.dts
new file mode 100644
index 000..bf64c99
--- /dev/null
+++ b/target/linux/ramips/dts/GL-MT300N-V2.dts
@@ -0,0 +1,135 @@
+/dts-v1/;
+
+#include "mt7628an.dtsi"
+
+#include
+#include
+
+/{
+ compatible = "GL-MT300N-V2", "ralink,mt7620an-soc";
+ model = "GL-MT300N-V2";
+
+ chosen {
+ bootargs = "console=ttyS0,115200";
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x400>;
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ usbpow {
+ label = "gl-mt300n-v2:usbpow";
+ gpios = <&gpio0 11 1>;
+ };
+
+ wan {
+ label = "gl-mt300n-v2:wan";
+ gpios = <&gpio1 11 1>;
+ };
+
+ wlan {
+ label = "gl-mt300n-v2:wlan";
+ gpios = <&gpio1 12 1>;
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys-polled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ poll-interval = <20>;
+
+ reset {
+ label = "reset";
+ gpios = <&gpio1 6 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ BIT_0 {
+ label = "BIT_0";
+ gpios = <&gpio0 0 1>;
+ linux,code = <0x100>;
+ };
+
+ BIT_1 {
+ label = "BIT_1";
+ gpios = <&gpio0 3 1>;
+ linux,code = <0x101>;
+ };
+ };
+
+};
+
+&pinctrl {
+ state_default: pinctrl0 {
+ gpio {
+ ralink,group = "refclk", "gpio", "wled_an", "p0led_an", "p1led_an",
"i2c", "i2s";
+ ralink,function = "gpio";
+ };
+ };
+};
+
+ðernet {
+ mtd-mac-a
Re: [LEDE-DEV] [PATCH] ramips: Add support for GL-MT300N-V2
Hello Thomas, On 04.05.2017 21:30, Thomas Endt wrote: -Ursprüngliche Nachricht- von Piotr Dymacz Gesendet: Donnerstag, 4. Mai 2017 10:30 Hello, Please, make sure to add a proper SoB line as described in "Submitting patches": [1]. Also, could you please include in your commit message short description about the hardware and how to install LEDE on it? Have a look at the recent ramips board additions for some examples: [2]. [1] https://lede-project.org/submitting-patches [2] https://github.com/lede- project/source/search?&q=ramips+add+support+for&type=Commits I think it would make sense to add a note to [1] regarding hardware description and install instructions. This is really helpful information for adding devices to the Table of Hardware, especially for devices where not much if any information can be found on the net. Hopefully it will also save you from having to repeat that note with each new "add support for..." commit. Thomas I just saw that you already did it 2 days ago: https://lede-project.org/submitting-patches?rev=1494176457 Thank you! -- Cheers, Piotr ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v2 1/3] base-files: add/convert generic board detection scripts
Hello Roman,
Your mail addresses in from header and in SoB line don't match.
Also, some questions inline, below.
On 09.05.2017 11:16, Roman Yeryomin wrote:
Signed-off-by: Roman Yeryomin
---
package/base-files/files/lib/board_detect.sh | 9 +
package/base-files/files/lib/preinit/03_preinit_board_detect | 11 +++
package/base-files/files/lib/preinit/10_sysinfo | 10 --
3 files changed, 20 insertions(+), 10 deletions(-)
create mode 100644 package/base-files/files/lib/board_detect.sh
create mode 100644 package/base-files/files/lib/preinit/03_preinit_board_detect
delete mode 100644 package/base-files/files/lib/preinit/10_sysinfo
diff --git a/package/base-files/files/lib/board_detect.sh
b/package/base-files/files/lib/board_detect.sh
new file mode 100644
index 000..e2f0f89
--- /dev/null
+++ b/package/base-files/files/lib/board_detect.sh
@@ -0,0 +1,9 @@
+board_detect()
+{
+ [ -d /proc/device-tree ] || return
+ mkdir -p /tmp/sysinfo
+ [ -e /tmp/sysinfo/board_name ] || \
+ echo "$(strings /proc/device-tree/compatible | head -1)" >
/tmp/sysinfo/board_name
+ [ ! -e /tmp/sysinfo/model -a -e /proc/device-tree/model ] && \
+ echo "$(cat /proc/device-tree/model)" > /tmp/sysinfo/model
+}
diff --git a/package/base-files/files/lib/preinit/03_preinit_board_detect
b/package/base-files/files/lib/preinit/03_preinit_board_detect
new file mode 100644
index 000..739ab02
--- /dev/null
+++ b/package/base-files/files/lib/preinit/03_preinit_board_detect
@@ -0,0 +1,11 @@
+#!/bin/sh
+#
+# Copyright (c) 2017 The Linux Foundation. All rights reserved.
Why LF? Shouldn't you use here your own copyright or none at all?
What's more, does it really make sense for you to copyright shell code
which length is almost the same as the copyright line?
--
Cheers,
Piotr
+#
+
+do_board_detect()
+{
+ . /lib/board_detect.sh && board_detect
+}
+
+boot_hook_add preinit_main do_board_detect
diff --git a/package/base-files/files/lib/preinit/10_sysinfo
b/package/base-files/files/lib/preinit/10_sysinfo
deleted file mode 100644
index 65b5096..000
--- a/package/base-files/files/lib/preinit/10_sysinfo
+++ /dev/null
@@ -1,10 +0,0 @@
-do_sysinfo_generic() {
- [ -d /proc/device-tree ] || return
- mkdir -p /tmp/sysinfo
- [ -e /tmp/sysinfo/board_name ] || \
- echo "$(strings /proc/device-tree/compatible | head -1)" >
/tmp/sysinfo/board_name
- [ ! -e /tmp/sysinfo/model -a -e /proc/device-tree/model ] && \
- echo "$(cat /proc/device-tree/model)" > /tmp/sysinfo/model
-}
-
-boot_hook_add preinit_main do_sysinfo_generic
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v2 1/3] base-files: add/convert generic board detection scripts
Hello Roman,
On 09.05.2017 22:24, Roman Yeryomin wrote:
On 9 May 2017 at 12:51, Piotr Dymacz wrote:
Hello Roman,
Hi
Your mail addresses in from header and in SoB line don't match.
is that a problem?
AFAIK, not a big one but in general, yes. Someone would need to fix that
before merging.
[snip]
diff --git a/package/base-files/files/lib/preinit/03_preinit_board_detect
b/package/base-files/files/lib/preinit/03_preinit_board_detect
new file mode 100644
index 000..739ab02
--- /dev/null
+++ b/package/base-files/files/lib/preinit/03_preinit_board_detect
@@ -0,0 +1,11 @@
+#!/bin/sh
+#
+# Copyright (c) 2017 The Linux Foundation. All rights reserved.
Why LF? Shouldn't you use here your own copyright or none at all?
Probably because that script is actually just a copy from ipq target.
As far as I can see, it's not a 1:1 copy.
Please, use your own copyrights or none at all.
Also I would ask the same question -- why LF? Maybe there is an answer
buried somewhere in the mail list...
It could be just a copy&paste from vendor SDK (QLSDK?).
What's more, does it really make sense for you to copyright shell code which
length is almost the same as the copyright line?
I don't care much about that but technically you are right.
And still, I would make it consistent. So, you can propose a patch
which removes all copyrights from scripts. That could even increase
performance by some us.
I really don't think that you can just drop all copyright lines from
code if they are already there.
--
Cheers,
Piotr
--
Cheers,
Piotr
+#
+
+do_board_detect()
+{
+ . /lib/board_detect.sh && board_detect
+}
+
+boot_hook_add preinit_main do_board_detect
diff --git a/package/base-files/files/lib/preinit/10_sysinfo
b/package/base-files/files/lib/preinit/10_sysinfo
deleted file mode 100644
index 65b5096..000
--- a/package/base-files/files/lib/preinit/10_sysinfo
+++ /dev/null
@@ -1,10 +0,0 @@
-do_sysinfo_generic() {
- [ -d /proc/device-tree ] || return
- mkdir -p /tmp/sysinfo
- [ -e /tmp/sysinfo/board_name ] || \
- echo "$(strings /proc/device-tree/compatible | head -1)" >
/tmp/sysinfo/board_name
- [ ! -e /tmp/sysinfo/model -a -e /proc/device-tree/model ] && \
- echo "$(cat /proc/device-tree/model)" > /tmp/sysinfo/model
-}
-
-boot_hook_add preinit_main do_sysinfo_generic
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH usbmode] fix indices of messages
Hello Julian, Bastian, On 18.05.2017 21:02, Julian Labus wrote: Hi Bastian, to me it looks like LEDE has its own implementation of usb-modeswitch and only uses usb-modeswitch-data from the upstream project or is this just a mirror? Yes, that is correct. I was going to send something similar (Mathias did a quick hack-fix here: [1]) as the current version of the conversion script doesn't work correctly with updated usb-modeswitch-data (I have already locally merged this PR: [2]). [1] https://gist.github.com/mkresin/c89882289a0f8569f99829224ffc96fe [2] https://github.com/lede-project/source/pull/1067 -- Cheers, Piotr https://git.lede-project.org/?p=project/usbmode.git Regards, Julian On 05/18/2017 08:21 PM, Bastian Bittorf wrote: * Julian Labus [18.05.2017 20:16]: the way how the script checked if a key already exists in a hash leads to wrong indices for %messages. Signed-off-by: Julian Labus --- convert-modeswitch.pl | 9 + thanks for your patch. it seems you must send your patch upstream: http://www.draisberghof.de/usb_modeswitch lede does only use this package. bye, bastian ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 2/3] usbmode: update usb-modeswitch-data to 20170205
Hello Julian, On 24.05.2017 16:32, Julian Labus wrote: add support for new hardware Thanks for taking care of this. If you want to keep usb-modeswitch-data version bump in a separate commit, I suppose that the PKG_RELEASE should be increased, according to the "Packaging guidelines" [1]. Or, maybe it make sense to squash both versions update commits. [1] https://forum.lede-project.org/t/packaging-guidelines/65/2 -- Cheers, Piotr Signed-off-by: Julian Labus --- package/utils/usbmode/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/package/utils/usbmode/Makefile b/package/utils/usbmode/Makefile index a5c9b19ddf..7f0195fdce 100644 --- a/package/utils/usbmode/Makefile +++ b/package/utils/usbmode/Makefile @@ -15,7 +15,7 @@ PKG_LICENSE_FILES:= PKG_MAINTAINER:=Felix Fietkau -PKG_DATA_VERSION:=20150115 +PKG_DATA_VERSION:=20170205 PKG_DATA_URL:=http://www.draisberghof.de/usb_modeswitch PKG_DATA_PATH:=usb-modeswitch-data-$(PKG_DATA_VERSION) PKG_DATA_FILENAME:=$(PKG_DATA_PATH).tar.bz2 @@ -26,7 +26,7 @@ include $(INCLUDE_DIR)/cmake.mk define Download/data FILE:=$(PKG_DATA_FILENAME) URL:=$(PKG_DATA_URL) - HASH:=90549f589835a68279369c3dc0d47eb7338ee3bad09d737e7b85e1ab15bd2d8b + HASH:=e2dcfd9d28928d8d8f03381571a23442b3c50d48d343bc40a1a07d01662738d1 endef $(eval $(call Download,data)) ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 2/3] usbmode: update usb-modeswitch-data to 20170205
Hi Felix, On 24.05.2017 17:54, Felix Fietkau wrote: On 2017-05-24 17:14, Piotr Dymacz wrote: Hello Julian, On 24.05.2017 16:32, Julian Labus wrote: add support for new hardware Thanks for taking care of this. If you want to keep usb-modeswitch-data version bump in a separate commit, I suppose that the PKG_RELEASE should be increased, according to the "Packaging guidelines" [1]. Or, maybe it make sense to squash both versions update commits. [1] https://forum.lede-project.org/t/packaging-guidelines/65/2 I think a PKG_RELEASE bump makes no sense here, neither does squashing the commits together. OK, PKG_RELEASE value maintaining was always confusing for me. -- Cheers, Piotr Since the commits are going to be pushed at the same time, there will not be a snapshot build inbetween... - Felix ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] openwrt and lede - remerge proposal V3
On 29.05.2017 09:03, John Crispin wrote: (resend, this time as plain text) Hi, here is a V3 of the remerge proposal, I tried to fold all the comments people made into it, if anything is missing let me know. Please remeber that post remerge anything can be voted on, so cluttering the proposal with many details will delay the remerge even more. Ideally we manage to vote during this week. ACK. Thanks all involved for preparing the remerge proposal. -- Cheers, Piotr ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] firmware-utils: mktplinkfw2: fix MD5 salt
Hello Rafał,
On 02.07.2017 17:17, Rafał Miłecki wrote:
From: Rafał Miłecki
LEDE supports 6 devices using TP-Link firmware format (V2 or V3):
ArcherC20i, ArcherC50, ArcherMR200, TDW8970, TDW8980 and VR200v.
I included (in 24043a0d2e01b9843c0dc529205b3b0bc7ecbbf9) another two
TP-Link devices (TL-WR840N v4 and TL-WR841N v13) which use v3 header.
--
Cheers,
Piotr
Testing mktplinkfw2 tool with official (vendor generated) firmware files
for all above devices has shown an error when comparing calculated and
included MD5 sum, e.g.:
mktplinkfw2 -i
Archer_C20iv1_0.9.1_3.2_up_boot\(170221\)_2017-02-21_17.14.03.bin | grep -A 1
MD5Sum1
Header MD5Sum1 : 22 5a cb 92 10 d2 95 7b df 62 9a f8 62 17 37 10
(*ERROR*)
--> expected : ad 19 11 d1 78 98 a7 42 5f 2e 64 da 8a 34 ec cb
This problem has been verified to occur with:
Archer_C20iv1_0.9.1_3.2_up_boot(170221)_2017-02-21_17.14.03.bin
Archer_C50v3_EU_0.9.1_0.3_up_boot[170417-rel52298].bin
Archer MR200v1_0.9.1_1.1_up_boot_v004a.0 Build 160905 Rel.60037n.bin
TD-W8970v3_0.9.1_2.0_up_boot(160816)_2016-08-16_10.40.57.bin
TD-W8980v1_0.6.0_1.8_up_boot(150514)_2015-05-14_11.16.43.bin
Archer_VR200vv2_0.2.0_0.8.0_up_boot(161202)_2016-12-05_14.39.06.bin
It's most likely that MD5 salt used in mktplinkfw2 has been always wrong
(and it's not a matter of e.g. a vendor change). Update it to fix MD5
calculation.
One problem that remains is zero MD5 sum calculated for:
Archer_C50v3_EU_0.9.1_0.3_up_boot[170417-rel52298].bin
Signed-off-by: Rafał Miłecki
---
tools/firmware-utils/src/mktplinkfw2.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/firmware-utils/src/mktplinkfw2.c
b/tools/firmware-utils/src/mktplinkfw2.c
index cfedf81d3b..ae7c6b7875 100644
--- a/tools/firmware-utils/src/mktplinkfw2.c
+++ b/tools/firmware-utils/src/mktplinkfw2.c
@@ -153,8 +153,8 @@ char md5salt_normal[MD5SUM_LEN] = {
};
char md5salt_boot[MD5SUM_LEN] = {
- 0x8c, 0xef, 0x33, 0x5b, 0xd5, 0xc5, 0xce, 0xfa,
- 0xa7, 0x9c, 0x28, 0xda, 0xb2, 0xe9, 0x0f, 0x42,
+ 0x8c, 0xef, 0x33, 0x5f, 0xd5, 0xc5, 0xce, 0xfa,
+ 0xac, 0x9c, 0x28, 0xda, 0xb2, 0xe9, 0x0f, 0x42,
};
static struct flash_layout layouts[] = {
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] firmware-utils: mktplinkfw: rework combined image option
We use combined option in "mktplinkfw" tool for generating initramfs
kernel images and header for kernel inside "safeloader" image type (in
fact, only for TL-WR1043ND v4 at this moment).
There is also "mktplinkfw-kernel" tool, a stripped-down version, used
only for generating "simple" header, for safeloader image types.
This changes how "mktplinkfw" handles combined images (which then will
allow us to drop the stripped-down version of the tool):
- drop "ignore size" command line option (it was used only for combined
images anyway)
- don't require "flash layout id" for combined images (we don't need and
shouldn't limit size of the initramfs kernel and for kernels inside
safeloader images, the "tplink-safeloader" tool does the size check)
- require kernel address and entry point in command line parameters for
combined images (consequence of previous point)
- don't include md5 sum and firmware length values in header (they are
needed only for update from vendor GUI and are ingored in case of
initramfs and "tplink-safeloader" images)
- drop "fake" flash layout for TL-WR1043ND v4 as it's no longer needed
Also, adjust "mktplinkfw-combined" command in ar71xx/image/tp-link.mk to
match introduced changes in "mktplinkfw" tool.
Signed-off-by: Piotr Dymacz
---
target/linux/ar71xx/image/tp-link.mk | 7 ++-
tools/firmware-utils/src/mktplinkfw.c | 99 +++
2 files changed, 44 insertions(+), 62 deletions(-)
diff --git a/target/linux/ar71xx/image/tp-link.mk
b/target/linux/ar71xx/image/tp-link.mk
index f717707..f393d15 100644
--- a/target/linux/ar71xx/image/tp-link.mk
+++ b/target/linux/ar71xx/image/tp-link.mk
@@ -40,11 +40,11 @@ endef
# -c combined image
define Build/mktplinkfw-combined
$(STAGING_DIR_HOST)/bin/mktplinkfw \
- -H $(TPLINK_HWID) -W $(TPLINK_HWREV) -F $(TPLINK_FLASHLAYOUT)
-N OpenWrt -V $(REVISION) $(1) \
- -m $(TPLINK_HEADER_VERSION) \
+ -H $(TPLINK_HWID) -W $(TPLINK_HWREV) -N OpenWrt -V $(REVISION)
$(1) \
+ -L $(KERNEL_LOADADDR) -m $(TPLINK_HEADER_VERSION) \
+ -E $(if $(KERNEL_ENTRY),$(KERNEL_ENTRY),$(KERNEL_LOADADDR)) \
-k $@ \
-o $@.new \
- -s -S \
-c
@mv $@.new $@
endef
@@ -707,7 +707,6 @@ define Device/tl-wr1043nd-v4
BOARDNAME := TL-WR1043ND-v4
DEVICE_PROFILE := TLWR1043
TPLINK_HWID := 0x10430004
- TPLINK_FLASHLAYOUT := 16Msafeloader
MTDPARTS :=
spi0.0:128k(u-boot)ro,1536k(kernel),14016k(rootfs),128k(product-info)ro,320k(config)ro,64k(partition-table)ro,128k(logs)ro,64k(ART)ro,15552k@0x2(firmware)
IMAGE_SIZE := 15552k
TPLINK_BOARD_ID := TLWR1043NDV4
diff --git a/tools/firmware-utils/src/mktplinkfw.c
b/tools/firmware-utils/src/mktplinkfw.c
index 93db441..c537862 100644
--- a/tools/firmware-utils/src/mktplinkfw.c
+++ b/tools/firmware-utils/src/mktplinkfw.c
@@ -117,7 +117,6 @@ static uint32_t rootfs_align;
static struct file_info boot_info;
static int combined;
static int strip_padding;
-static int ignore_size;
static int add_jffs2_eof;
static unsigned char jffs2_eof_mark[4] = {0xde, 0xad, 0xc0, 0xde};
static uint32_t fw_max_len;
@@ -181,20 +180,6 @@ static struct flash_layout layouts[] = {
.kernel_ep = 0xc000,
.rootfs_ofs = 0x2a,
}, {
- /*
- Some devices (e.g. TL-WR1043 v4) use a mktplinkfw
kernel image
- embedded in a tplink-safeloader image as os-image
partition.
-
- We use a 1.5MB partition for the compressed kernel,
which should
- be sufficient, but not too wasteful (the flash of the
TL-WR1043 v4
- has 16MB in total).
- */
- .id = "16Msafeloader",
- .fw_max_len = 0x18,
- .kernel_la = 0x8006,
- .kernel_ep = 0x8006,
- .rootfs_ofs = 0,
- }, {
/* terminating entry */
}
};
@@ -272,7 +257,6 @@ static void usage(int status)
" -R overwrite rootfs offset with (hexval prefixed with
0x)\n"
" -owrite output to the file \n"
" -s strip padding from the end of the image\n"
-" -S ignore firmware size limit (only for combined images)\n"
" -j add jffs2 end-of-filesystem markers\n"
" -N set image vendor to \n"
" -V set image version to \n"
@@ -362,7 +346,7 @@ static int check_options(void)
}
hw_id = strtoul(opt_hw_id, NULL, 0);
- if (layout_id == NULL) {
+ if (!combined && layout_id == NULL) {
Re: [LEDE-DEV] [PATCH] firmware-utils: mktplinkfw: rework combined image option
Hello Matthias,
On 10.07.2017 01:27, Matthias Schiffer wrote:
On 07/10/2017 01:02 AM, Piotr Dymacz wrote:
We use combined option in "mktplinkfw" tool for generating initramfs
kernel images and header for kernel inside "safeloader" image type (in
fact, only for TL-WR1043ND v4 at this moment).
There is also "mktplinkfw-kernel" tool, a stripped-down version, used
only for generating "simple" header, for safeloader image types.
I haven't had a detailed look at your patch yet, but I think we should
unify this: either build the 1043v4 using mktplinkfw-kernel, or get rid of
mktplinkfw-kernel and use mktplinkfw-combined instead.
Rework combined mode in mktplinkfw and then drop the mktplinkfw-kernel
tool is my target plan, already done in my staging tree [0]. This patch
is just a first step - I wanted to make sure that there are no other use
cases of the combined mode in mktplinkfw I'm not aware of.
[0]
https://git.lede-project.org/?p=lede/pepe2k/staging.git;a=shortlog;h=refs/heads/tools-build_rework-mktplink-combined_20170710
--
Cheers,
Piotr
Matthias
This changes how "mktplinkfw" handles combined images (which then will
allow us to drop the stripped-down version of the tool):
- drop "ignore size" command line option (it was used only for combined
images anyway)
- don't require "flash layout id" for combined images (we don't need and
shouldn't limit size of the initramfs kernel and for kernels inside
safeloader images, the "tplink-safeloader" tool does the size check)
- require kernel address and entry point in command line parameters for
combined images (consequence of previous point)
- don't include md5 sum and firmware length values in header (they are
needed only for update from vendor GUI and are ingored in case of
initramfs and "tplink-safeloader" images)
- drop "fake" flash layout for TL-WR1043ND v4 as it's no longer needed
Also, adjust "mktplinkfw-combined" command in ar71xx/image/tp-link.mk to
match introduced changes in "mktplinkfw" tool.
Signed-off-by: Piotr Dymacz
---
target/linux/ar71xx/image/tp-link.mk | 7 ++-
tools/firmware-utils/src/mktplinkfw.c | 99 +++
2 files changed, 44 insertions(+), 62 deletions(-)
diff --git a/target/linux/ar71xx/image/tp-link.mk
b/target/linux/ar71xx/image/tp-link.mk
index f717707..f393d15 100644
--- a/target/linux/ar71xx/image/tp-link.mk
+++ b/target/linux/ar71xx/image/tp-link.mk
@@ -40,11 +40,11 @@ endef
# -c combined image
define Build/mktplinkfw-combined
$(STAGING_DIR_HOST)/bin/mktplinkfw \
- -H $(TPLINK_HWID) -W $(TPLINK_HWREV) -F $(TPLINK_FLASHLAYOUT)
-N OpenWrt -V $(REVISION) $(1) \
- -m $(TPLINK_HEADER_VERSION) \
+ -H $(TPLINK_HWID) -W $(TPLINK_HWREV) -N OpenWrt -V $(REVISION)
$(1) \
+ -L $(KERNEL_LOADADDR) -m $(TPLINK_HEADER_VERSION) \
+ -E $(if $(KERNEL_ENTRY),$(KERNEL_ENTRY),$(KERNEL_LOADADDR)) \
-k $@ \
-o $@.new \
- -s -S \
-c
@mv $@.new $@
endef
@@ -707,7 +707,6 @@ define Device/tl-wr1043nd-v4
BOARDNAME := TL-WR1043ND-v4
DEVICE_PROFILE := TLWR1043
TPLINK_HWID := 0x10430004
- TPLINK_FLASHLAYOUT := 16Msafeloader
MTDPARTS :=
spi0.0:128k(u-boot)ro,1536k(kernel),14016k(rootfs),128k(product-info)ro,320k(config)ro,64k(partition-table)ro,128k(logs)ro,64k(ART)ro,15552k@0x2(firmware)
IMAGE_SIZE := 15552k
TPLINK_BOARD_ID := TLWR1043NDV4
diff --git a/tools/firmware-utils/src/mktplinkfw.c
b/tools/firmware-utils/src/mktplinkfw.c
index 93db441..c537862 100644
--- a/tools/firmware-utils/src/mktplinkfw.c
+++ b/tools/firmware-utils/src/mktplinkfw.c
@@ -117,7 +117,6 @@ static uint32_t rootfs_align;
static struct file_info boot_info;
static int combined;
static int strip_padding;
-static int ignore_size;
static int add_jffs2_eof;
static unsigned char jffs2_eof_mark[4] = {0xde, 0xad, 0xc0, 0xde};
static uint32_t fw_max_len;
@@ -181,20 +180,6 @@ static struct flash_layout layouts[] = {
.kernel_ep = 0xc000,
.rootfs_ofs = 0x2a,
}, {
- /*
- Some devices (e.g. TL-WR1043 v4) use a mktplinkfw
kernel image
- embedded in a tplink-safeloader image as os-image
partition.
-
- We use a 1.5MB partition for the compressed kernel,
which should
- be sufficient, but not too wasteful (the flash of the
TL-WR1043 v4
- has 16MB in total).
- */
- .id = "16Msafeloader",
- .fw_max_len = 0x18,
- .kernel_la = 0x8006,
- .kernel_ep = 0x8006,
- .rootfs_ofs = 0,
- }, {
Re: [LEDE-DEV] [PATCH] ar71xx: add ew-balin platform from Embedded Wireless
Hello Catrinel, On 19.07.2017 14:19, Catrinel Catrinescu wrote: [...] diff --git a/target/linux/ar71xx/config-4.4 b/target/linux/ar71xx/config-4.4 index e8d907fcd3..2b105fa32b 100644 --- a/target/linux/ar71xx/config-4.4 +++ b/target/linux/ar71xx/config-4.4 @@ -106,6 +106,7 @@ CONFIG_ATH79_MACH_ENS202EXT=y CONFIG_ATH79_MACH_EPG5000=y CONFIG_ATH79_MACH_ESR1750=y CONFIG_ATH79_MACH_ESR900=y +CONFIG_ATH79_MACH_EW_BALIN=y Please, disable this in nand and mikrotik subtargets kernel configs. -- Cheers, Piotr ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] ar71xx: Chipidea USB device support for QCA953x
Hello Sergey,
On 01.09.2017 06:16, ad...@yapic.net wrote:
From: Sergey Sergeev
Changes the platform to use the Chipidea driver instead of the
generic USB host driver which has support for both host and
device modes (selected on boot) for QCA953x based boards.
It was tested on GL.iNet GL-AR300M with USB DEVICE mode config.
More details is available here:
https://github.com/adron-s/QCA953x-usb-device-mode
Please, have a look at 'ar71xx_qca9k-usb-device-mode' branch in my
staging tree [1]. There is a slightly modified version of Felix's
'ar71xx: rework chipidea usb controller patch' change, from his staging
tree [2].
I tested it successfully on AR9331, AR9344, QCA9531 and QCA9557 based
devices (I plan to make some tests on QCA956x later), with USB in device
and host mode. I also dropped 'ar933x_usb_setup_ctrl_config()' function
which was toggling 'HOST_ONLY' bit in 'USB_CONFIG' register as it wasn't
make any difference on all tested platforms.
[1] https://git.lede-project.org/?p=lede/pepe2k/staging.git;a=summary
[2] https://git.lede-project.org/?p=lede/nbd/staging.git;a=summary
--
Cheers,
Piotr
Signed-off-by: Sergey Sergeev
---
...940-usb-chipidea-QCA953x-platform-support.patch | 87 ++
1 file changed, 87 insertions(+)
create mode 100644
target/linux/ar71xx/patches-4.4/940-usb-chipidea-QCA953x-platform-support.patch
diff --git
a/target/linux/ar71xx/patches-4.4/940-usb-chipidea-QCA953x-platform-support.patch
b/target/linux/ar71xx/patches-4.4/940-usb-chipidea-QCA953x-platform-support.patch
new file mode 100644
index 000..a3e2509
--- /dev/null
+++
b/target/linux/ar71xx/patches-4.4/940-usb-chipidea-QCA953x-platform-support.patch
@@ -0,0 +1,87 @@
+--- a/arch/mips/ath79/dev-usb.c
b/arch/mips/ath79/dev-usb.c
+@@ -286,6 +286,51 @@
+ &ath79_ehci_pdata_v2, sizeof(ath79_ehci_pdata_v2));
+ }
+
++#if IS_ENABLED(CONFIG_USB_CHIPIDEA)
++static void __init qca953x_usb_setup_ctrl_config(void)
++{
++ void __iomem *usb_ctrl_base, *usb_config_reg;
++ u32 usb_config;
++
++ usb_ctrl_base = ioremap(AR71XX_USB_CTRL_BASE, AR71XX_USB_CTRL_SIZE);
++ usb_config_reg = usb_ctrl_base + AR71XX_USB_CTRL_REG_CONFIG;
++ usb_config = __raw_readl(usb_config_reg);
++ usb_config &= ~QCA953X_USB_CONFIG_HOST_ONLY;
++ __raw_writel(usb_config, usb_config_reg);
++ iounmap(usb_ctrl_base);
++}
++
++static void __init qca953x_ci_usb_setup(u32 bootstrap)
++{
++ enum usb_dr_mode dr_mode;
++ struct ci_hdrc_platform_data ci_pdata;
++
++ if (bootstrap & QCA953X_BOOTSTRAP_USB_MODE_DEVICE) {
++ dr_mode = USB_DR_MODE_PERIPHERAL;
++ qca953x_usb_setup_ctrl_config();
++ } else {
++ dr_mode = USB_DR_MODE_HOST;
++ }
++
++ memset(&ci_pdata, 0, sizeof(ci_pdata));
++ ci_pdata.name = "ci_hdrc_qca953x";
++ ci_pdata.capoffset = DEF_CAPOFFSET;
++ ci_pdata.dr_mode = dr_mode;
++ ci_pdata.flags = CI_HDRC_DUAL_ROLE_NOT_OTG | CI_HDRC_DP_ALWAYS_PULLUP;
++ ci_pdata.vbus_extcon.edev = ERR_PTR(-ENODEV);
++ ci_pdata.id_extcon.edev = ERR_PTR(-ENODEV);
++ ci_pdata.itc_setting = 1;
++
++ platform_device_register_simple("usb_phy_generic",
++ PLATFORM_DEVID_AUTO, NULL, 0);
++
++ ath79_usb_register("ci_hdrc", -1,
++ QCA953X_EHCI_BASE, QCA953X_EHCI_SIZE,
++ ATH79_CPU_IRQ(3),
++ &ci_pdata, sizeof(ci_pdata));
++}
++#endif
++
+ static void __init qca953x_usb_setup(void)
+ {
+ u32 bootstrap;
+@@ -304,10 +349,14 @@
+ ath79_device_reset_clear(QCA953X_RESET_USB_HOST);
+ udelay(1000);
+
++#if IS_ENABLED(CONFIG_USB_CHIPIDEA)
++ qca953x_ci_usb_setup(bootstrap);
++#else
+ ath79_usb_register("ehci-platform", -1,
+ QCA953X_EHCI_BASE, QCA953X_EHCI_SIZE,
+ ATH79_CPU_IRQ(3),
+ &ath79_ehci_pdata_v2, sizeof(ath79_ehci_pdata_v2));
++#endif
+ }
+
+ static void qca955x_usb_reset_notifier(struct platform_device *pdev)
+--- a/arch/mips/include/asm/mach-ath79/ar71xx_regs.h
b/arch/mips/include/asm/mach-ath79/ar71xx_regs.h
+@@ -660,6 +660,7 @@
+ #define AR933X_BOOTSTRAP_MDIO_GPIO_EN BIT(18)
+ #define AR933X_BOOTSTRAP_EEPBUSY BIT(4)
+ #define AR933X_BOOTSTRAP_USB_MODE_HOSTBIT(3)
++#define QCA953X_BOOTSTRAP_USB_MODE_DEVICE BIT(7)
+ #define AR933X_BOOTSTRAP_REF_CLK_40 BIT(0)
+
+ #define AR934X_BOOTSTRAP_SW_OPTION8 BIT(23)
+@@ -690,6 +691,7 @@
+ #define QCA956X_BOOTSTRAP_REF_CLK_40 BIT(2)
+
+ #define AR933X_USB_CONFIG_HOST_ONLY BIT(8)
++#define QCA953X_USB_CONFIG_HOST_ONLY BIT(4)
+
+ #define AR934X_PCIE_WMAC_INT_WMAC_MISCBIT(0)
+ #define AR934X_PCIE_WMAC_INT_WMAC_TX BIT(1)
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-d
Re: [LEDE-DEV] Kernel version in next major release
Hello Hauke, On 07.10.2017 13:43, Hauke Mehrtens wrote: [...] What is your opinion on this topic? Am I missing some arguments? Currently I would prefer solution 3 going with kernel 4.9 and 4.14. I prefer option 3 as well. -- Cheers, Piotr ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Serial data getting lost - bug or a feature?
Hi Valent, On 16.10.2017 22:04, Valent Turkovic wrote: Hi, I'm working with Lede on ar71xx platform (Carambola2 wifi module) to gather sensor data over serial, save it and transfer it to "could". Previous firmware was based on OpenWrt Chaos Calmer but latest one is based upon Lede 17.01.01. I'll test it also with 17.01.03 soon. What I have discovered is that now with using Lede sometimes there are missing characters while reading data from serial connection. Data is not constantly being read, but sensor device is logging data usually for 8 hours and then data is read via serial in one big "download". During these downloads I have never seen a character go missing while Chaos Calmer was used. What was even stranger is that sometimes I did get these "bad logs" (ie ones with few missing characters) but sometimes log download went perfectly! After some head scratching and troubleshooting I managed to reproduce this "bug" 100% and it was due to wifi! But only if wifi was enabled and not being used! So if radio was enabled, in sta mode but not connected to AP errors would happen! It I would disable wifi or if radio was associated with AP then there would be no errors during reading data from serial connection. Is there any explanation for this behaviour? Is this a bug or a feature? Is there any change between OpenWrt CC version and Lede that could explain this? Are you using AR9331 built-in UART or some external, USB to UART adapter? -- Cheers, Piotr Thanks in advance for any insight and answers, Valent. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 9/9] ar71xx: add support for Comfast E214N V2 Outdoor CPE
Hello Zoltan,
On 22.10.2017 22:21, Zoltan HERPAI wrote:
Based on Robert Budde's patch, with additional reworks.
https://github.com/openwrt/openwrt/pull/390
Signed-off-by: Zoltan HERPAI
---
target/linux/ar71xx/base-files/etc/board.d/01_leds | 10 ++
target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 +
.../ar71xx/base-files/lib/upgrade/platform.sh | 1 +
target/linux/ar71xx/config-4.4 | 1 +
target/linux/ar71xx/config-4.9 | 1 +
.../ar71xx/files/arch/mips/ath79/Kconfig.openwrt | 8 ++
target/linux/ar71xx/files/arch/mips/ath79/Makefile | 1 +
.../files/arch/mips/ath79/mach-cf-e214n-v2.c | 124 +
.../linux/ar71xx/files/arch/mips/ath79/machtypes.h | 1 +
target/linux/ar71xx/image/generic.mk | 8 ++
10 files changed, 158 insertions(+)
create mode 100644
target/linux/ar71xx/files/arch/mips/ath79/mach-cf-e214n-v2.c
We have some COMFAST devices already supported under ar71xx target in
LEDE and as they are very similar, support for all of them (IIRC) is
kept in single mach file [1]. This limits code duplication, e.g. for
their external watchdog, network initialization, etc.
Also, after a brief review, I found some issues here:
- LED names don't follow general naming convention (color is missing)
- support for reset button is missing
- COMFAST keeps ART copy in last 64 KB mtd partition, thus we have a
"art-backup" partition defined [2], not "nvram" as in the patch
Personally, I would prefer to include support for this model in the same
way as we did for rest from this vendor. How would you like to proceed
with this one then?
--
Cheers,
Piotr
[1]
https://github.com/lede-project/source/blob/master/target/linux/ar71xx/files/arch/mips/ath79/mach-cf-e316n-v2.c
[2]
https://github.com/lede-project/source/blob/master/target/linux/ar71xx/image/generic.mk#L142
diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds
b/target/linux/ar71xx/base-files/etc/board.d/01_leds
index 27e6c8a..5707624 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -182,6 +182,16 @@ carambola2)
ucidef_set_led_netdev "wan" "WAN" "$board:orange:eth1" "eth1"
ucidef_set_led_wlan "wlan" "WLAN" "$board:green:wlan" "phy0tpt"
;;
+cf-e214n-v2)
+ ucidef_set_led_netdev "lan" "LAN" "$board:lan" "eth0"
+ ucidef_set_led_netdev "wan" "WAN" "$board:wan" "eth1"
+ ucidef_set_led_wlan "wlan" "WLAN" "$board:wlan" "phy0tpt"
+ ucidef_set_rssimon "wlan" "20" "1"
+ ucidef_set_led_rssi "rssilow" "RSSILOW" "$board:link1" "wlan" "1" "100" "0"
"13"
+ ucidef_set_led_rssi "rssimediumlow" "RSSIMEDIUMLOW" "$board:link2" "wlan" "26" "100"
"-25" "13"
+ ucidef_set_led_rssi "rssimediumhigh" "RSSIMEDIUMHIGH" "$board:link3" "wlan" "51" "100"
"-50" "13"
+ ucidef_set_led_rssi "rssihigh" "RSSIHIGH" "$board:link4" "wlan" "76" "100" "-75"
"13"
+ ;;
cf-e316n-v2)
ucidef_set_led_netdev "lan" "LAN" "$board:blue:lan" "eth0"
ucidef_set_led_netdev "wan" "WAN" "$board:blue:wan" "eth1"
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index bdba81b..1c1317d 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -504,6 +504,9 @@ ar71xx_board_detect() {
*"Carambola2"*)
name="carambola2"
;;
+ *"CF-E214N v2")
+ name="cf-e214n-v2"
+ ;;
*"CF-E316N v2")
name="cf-e316n-v2"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index a60e44c..e768386 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -215,6 +215,7 @@ platform_check_image() {
bullet-m|\
c-55|\
carambola2|\
+ cf-e214n-v2|\
cf-e316n-v2|\
cf-e320n-v2|\
cf-e355ac|\
diff --git a/target/linux/ar71xx/config-4.4 b/target/linux/ar71xx/config-4.4
index 4793bf4..d8f94e3 100644
--- a/target/linux/ar71xx/config-4.4
+++ b/target/linux/ar71xx/config-4.4
@@ -67,6 +67,7 @@ CONFIG_ATH79_MACH_C55=y
CONFIG_ATH79_MACH_CAP324=y
CONFIG_ATH79_MACH_CAP4200AG=y
CONFIG_ATH79_MACH_CARAMBOLA2=y
+CONFIG_ATH79_MACH_CF_E214N_V2=y
CONFIG_ATH79_MACH_CF_E316N_V2=y
CONFIG_ATH79_MACH_CF_E320N_V2=y
CONFIG_ATH79_MACH_CF_E355AC=y
diff --git a/target/linux/ar71xx/config-4.9 b/target/linux/ar71xx/config-4.9
index 285c638..df90b20 100644
--- a/target/linux/ar71xx/config-4.9
+++ b/target/linux/ar71xx/config-4.9
@@ -66,6 +66,7 @@ CONFIG_ATH79_MACH_C55=y
CONFIG_ATH79_MACH_CAP324=y
CONFIG_ATH79_MACH_CAP4200AG=y
CONFIG_ATH79_MACH_CARAMBOLA2=y
+CONFIG_ATH79_MACH_CF_E214N_V2=y
CONFIG_ATH79_MACH_CF_E316N_V2=y
CONFIG
Re: [LEDE-DEV] [source] ar71xx: deactivate some boards with too small kernel partitions
Hello Hauke,
AFAIK, "{image,kernel,rootfs} is too big" errors are/were just ignored
before. As I understand this, with such approach, we can keep support
for device and allow users to build images with custom configuration
(different kernel options, set of packages, etc.) which makes image
generation possible. If you look closer at the yesterday buildbot log
[1], this was true for (some of) below devices (grep for "WARNING.*too
big").
What I don't really understand here is why disabling image generation
only for below boards made buildbot happy again if there are many other
which have similar issues now [2] and are just ignored. How below boards
were selected and why image for, for example "re450", wasn't disabled if
it also fails?
Also, please have a look at my comments inline, below.
[1]
http://phase1.builds.lede-project.org/builders/ar71xx%2Fgeneric/builds/388/steps/images/logs/stdio
[2]
http://phase1.builds.lede-project.org/builders/ar71xx%2Fgeneric/builds/389/steps/images/logs/stdio
On 22.10.2017 23:19, LEDE Commits wrote:
hauke pushed a commit to source.git, branch master:
https://git.lede-project.org/f7a6fd31539be54d14d7c52b491b40b26bf8f740
commit f7a6fd31539be54d14d7c52b491b40b26bf8f740
Author: Hauke Mehrtens
AuthorDate: Sun Oct 22 23:10:08 2017 +0200
ar71xx: deactivate some boards with too small kernel partitions
This affects the following boards:
* dr344
The only way to fix this one I can think about, is to change mtd order
(use kernel/rootfs instead of rootfs/kernel). But this would break
backward compatibility and require change of "bootcmd" variable in
U-Boot environment _before_ upgrade to new image.
* archer-c58-v1
* archer-c60-v1
* tl-wr902ac-v1
* tl-wr942n-v1
These should be easily fixable. They use TP-Link "safeloader" image type
with kernel/rootfs order (os-image/file-system), so we can increase
kernel partition size and reduce the rootfs.
* ubnt-uap-pro
* ubnt-unifi-outdoor-plus
No idea about these two.
--
Cheers,
Piotr
The build fails for any of these boards because the resulting kernel
image will not fit into the kernel partition.
When CONFIG_KERNEL_KALLSYMS is not set it could be that the kernel will
fit onto the board again, this is the case for release images.
Signed-off-by: Hauke Mehrtens
---
target/linux/ar71xx/image/generic.mk | 1 -
target/linux/ar71xx/image/tp-link.mk | 5 ++---
target/linux/ar71xx/image/ubnt.mk| 1 -
3 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/target/linux/ar71xx/image/generic.mk
b/target/linux/ar71xx/image/generic.mk
index 6f5a701..3c5fcc3 100644
--- a/target/linux/ar71xx/image/generic.mk
+++ b/target/linux/ar71xx/image/generic.mk
@@ -358,7 +358,6 @@ define Device/dr344
MTDPARTS :=
spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,6336k(rootfs),1408k(kernel),64k(nvram),64k(art)ro,7744k@0x5(firmware)
IMAGE/sysupgrade.bin := append-rootfs | pad-rootfs | pad-to
(ROOTFS_SIZE) | append-kernel | check-size (IMAGE_SIZE)
endef
-TARGET_DEVICES += dr344
define Device/dr531
DEVICE_TITLE := Wallys DR531
diff --git a/target/linux/ar71xx/image/tp-link.mk
b/target/linux/ar71xx/image/tp-link.mk
index ae711e7..868bbda 100644
--- a/target/linux/ar71xx/image/tp-link.mk
+++ b/target/linux/ar71xx/image/tp-link.mk
@@ -150,7 +150,7 @@ define Device/archer-c60-v1
MTDPARTS :=
spi0.0:64k(u-boot)ro,64k(mac)ro,1344k(kernel),6592k(rootfs),64k(tplink)ro,64k(art)ro,7936k@0x2(firmware)
SUPPORTED_DEVICES := archer-c60-v1
endef
-TARGET_DEVICES += archer-c25-v1 archer-c58-v1 archer-c59-v1 archer-c60-v1
+TARGET_DEVICES += archer-c25-v1 archer-c59-v1
define Device/archer-c5-v1
$(Device/tplink-16mlzma)
@@ -1043,7 +1043,6 @@ define Device/tl-wr902ac-v1
append-metadata | check-size (IMAGE_SIZE)
MTDPARTS := spi0.0:128k(u-boot)ro,7360k(firmware),640k(tplink)ro,64k(art)ro
endef
-TARGET_DEVICES += tl-wr902ac-v1
define Device/tl-wr940n-v4
$(Device/tplink-4mlzma)
@@ -1118,4 +1117,4 @@ define Device/tl-wr942n-v1
MTDPARTS :=
spi0.0:128k(u-boot)ro,1344k(kernel),13120k(rootfs),64k(product-info)ro,64k(partition-table)ro,256k(oem-config)ro,1344k(oem-vars)ro,64k(ART)ro,14464k@0x2(firmware)
SUPPORTED_DEVICES := tl-wr942n-v1
endef
-TARGET_DEVICES += tl-wr940n-v4 tl-wr941nd-v2 tl-wr941nd-v3 tl-wr941nd-v4
tl-wr941nd-v5 tl-wr941nd-v6 tl-wr941nd-v6-cn tl-wr942n-v1
+TARGET_DEVICES += tl-wr940n-v4 tl-wr941nd-v2 tl-wr941nd-v3 tl-wr941nd-v4
tl-wr941nd-v5 tl-wr941nd-v6 tl-wr941nd-v6-cn
diff --git a/target/linux/ar71xx/image/ubnt.mk
b/target/linux/ar71xx/image/ubnt.mk
index f80f2f1..dfc795b 100644
--- a/target/linux/ar71xx/image/ubnt.mk
+++ b/target/linux/ar71xx/image/ubnt.mk
@@ -256,4 +256,3 @@ define Device/ubnt-unifi-outdoor-plus
BOARDNAME := UBNT-UOP
DEVICE_PROFILE := UBNT
endef
-TARGET_DEVICES += ubnt-uap-pro ubnt-unifi-outdoor-plus
Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 6/9] ar71xx: add support for Anonabox Pro
Hello Zoltan, August, On 23.10.2017 21:58, Zoltan HERPAI wrote: L. D. Pinney wrote: Why does this patch use "legacy" ? On Monday, October 23, 2017, 4:23:20 AM GMT+8, Zoltan HERPAI wrote: Because this seemed to build, and without access to the actual hardware, I had to rely on the PR sent. [snip] Please, move image generation code for this device to the new building code. You can follow definition for "zbt-we1526" which also uses rootfs-kernel mtd order and is based on the same h/w platform. -- Cheers, Piotr ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] merge: add OpenWrt branding
Hello Zoltan, Hauke, Just one, small comment, inline below. On 24.10.2017 13:46, Zoltan HERPAI wrote: [...] diff --git a/include/image-commands.mk b/include/image-commands.mk index aaece70..3507578 100644 --- a/include/image-commands.mk +++ b/include/image-commands.mk @@ -7,7 +7,7 @@ define Build/uImage mkimage -A $(LINUX_KARCH) \ -O linux -T kernel \ -C $(1) -a $(KERNEL_LOADADDR) -e $(if $(KERNEL_ENTRY),$(KERNEL_ENTRY),$(KERNEL_LOADADDR)) \ - -n '$(if $(UIMAGE_NAME),$(UIMAGE_NAME),$(call toupper,$(LINUX_KARCH)) LEDE Linux-$(LINUX_VERSION))' -d $@ $@.new + -n '$(if $(UIMAGE_NAME),$(UIMAGE_NAME),$(call toupper,$(LINUX_KARCH)) OpenWrt Linux-$(LINUX_VERSION))' -d $@ $@.new I think it would make sense to use VERSION_DIST(_SANITIZED) variable here (and in all similar places below) instead of hardcoded value. -- Cheers, Piotr mv $@.new $@ endef @@ -60,7 +60,7 @@ endef define Build/netgear-dni $(STAGING_DIR_HOST)/bin/mkdniimg \ - -B $(NETGEAR_BOARD_ID) -v LEDE.$(REVISION) \ + -B $(NETGEAR_BOARD_ID) -v OpenWrt.$(REVISION) \ $(if $(NETGEAR_HW_ID),-H $(NETGEAR_HW_ID)) \ -r "$(1)" \ -i $@ -o $@.new @@ -83,7 +83,7 @@ define Build/append-uImage-fakeroot-hdr rm -f $@.fakeroot $(STAGING_DIR_HOST)/bin/mkimage \ -A $(LINUX_KARCH) -O linux -T filesystem -C none \ - -n '$(call toupper,$(LINUX_KARCH)) LEDE fakeroot' \ + -n '$(call toupper,$(LINUX_KARCH)) OpenWrt fakeroot' \ -s \ $@.fakeroot cat $@.fakeroot >> $@ diff --git a/include/image.mk b/include/image.mk index 3f5b454..eccf943 100644 --- a/include/image.mk +++ b/include/image.mk @@ -136,7 +136,7 @@ endef define Image/BuildKernel/MkuImage mkimage -A $(ARCH) -O linux -T kernel -C $(1) -a $(2) -e $(3) \ - -n '$(call toupper,$(ARCH)) LEDE Linux-$(LINUX_VERSION)' -d $(4) $(5) + -n '$(call toupper,$(ARCH)) OpenWrt Linux-$(LINUX_VERSION)' -d $(4) $(5) endef define Image/BuildKernel/MkFIT diff --git a/include/prereq-build.mk b/include/prereq-build.mk index 7d96921..0fab326 100644 --- a/include/prereq-build.mk +++ b/include/prereq-build.mk @@ -18,7 +18,7 @@ $(eval $(call TestHostCommand,working-make, \ $(MAKE) -v | grep -E 'Make (3\.8[1-9]|3\.9[0-9]|[4-9]\.)')) $(eval $(call TestHostCommand,case-sensitive-fs, \ - LEDE can only be built on a case-sensitive filesystem, \ + OpenWrt can only be built on a case-sensitive filesystem, \ rm -f $(TMP_DIR)/test.*; touch $(TMP_DIR)/test.fs; \ test ! -f $(TMP_DIR)/test.FS)) diff --git a/include/version.mk b/include/version.mk index 1a0d3c9..4a8ac0b 100644 --- a/include/version.mk +++ b/include/version.mk @@ -40,23 +40,23 @@ VERSION_NICK:=$(call qstrip_escape,$(CONFIG_VERSION_NICK)) VERSION_NICK:=$(if $(VERSION_NICK),$(VERSION_NICK),$(RELEASE)) VERSION_REPO:=$(call qstrip_escape,$(CONFIG_VERSION_REPO)) -VERSION_REPO:=$(if $(VERSION_REPO),$(VERSION_REPO),http://downloads.lede-project.org/snapshots) +VERSION_REPO:=$(if $(VERSION_REPO),$(VERSION_REPO),http://downloads.openwrt.org/snapshots) VERSION_DIST:=$(call qstrip_escape,$(CONFIG_VERSION_DIST)) -VERSION_DIST:=$(if $(VERSION_DIST),$(VERSION_DIST),LEDE) +VERSION_DIST:=$(if $(VERSION_DIST),$(VERSION_DIST),OpenWrt) VERSION_DIST_SANITIZED:=$(call sanitize,$(VERSION_DIST)) VERSION_MANUFACTURER:=$(call qstrip_escape,$(CONFIG_VERSION_MANUFACTURER)) -VERSION_MANUFACTURER:=$(if $(VERSION_MANUFACTURER),$(VERSION_MANUFACTURER),LEDE) +VERSION_MANUFACTURER:=$(if $(VERSION_MANUFACTURER),$(VERSION_MANUFACTURER),OpenWrt) VERSION_MANUFACTURER_URL:=$(call qstrip_escape,$(CONFIG_VERSION_MANUFACTURER_URL)) -VERSION_MANUFACTURER_URL:=$(if $(VERSION_MANUFACTURER_URL),$(VERSION_MANUFACTURER_URL),http://lede-project.org/) +VERSION_MANUFACTURER_URL:=$(if $(VERSION_MANUFACTURER_URL),$(VERSION_MANUFACTURER_URL),http://openwrt.org/) VERSION_BUG_URL:=$(call qstrip_escape,$(CONFIG_VERSION_BUG_URL)) -VERSION_BUG_URL:=$(if $(VERSION_BUG_URL),$(VERSION_BUG_URL),http://bugs.lede-project.org/) +VERSION_BUG_URL:=$(if $(VERSION_BUG_URL),$(VERSION_BUG_URL),http://bugs.openwrt.org/) VERSION_SUPPORT_URL:=$(call qstrip_escape,$(CONFIG_VERSION_SUPPORT_URL)) -VERSION_SUPPORT_URL:=$(if $(VERSION_SUPPORT_URL),$(VERSION_SUPPORT_URL),http://forum.lede-project.org/) +VERSION_SUPPORT_URL:=$(if $(VERSION_SUPPORT_URL),$(VERSION_SUPPORT_URL),http://forum.openwrt.org/) VERSION_PRODUCT:=$(call qstrip_escape,$(CONFIG_VERSION_PRODUCT)) VERSION_PRODUCT:=$(if $(VERSION_PRODUCT),$(VERSION_PRODUCT),Generic) diff --git a/package/base-files/Makefile b/package/base-files/Makefile index 216e457..a5511c4 100644 --- a/package/base-files/Makefile +++ b/package/base-files/Makefile @@ -34,7 +34,7 @@ define Package/ba
Re: [LEDE-DEV] [PATCH] ramips: Add support for the Unielec U7621-6
Hello Kristian,
On 04.11.2017 21:53, Kristian Evensen wrote:
The Unielec U7621-6
(http://www.unielecinc.com/q/news/cn/p/product/detail.html?qd_guid=pyrEjfTmYf)
is an MT7621-based router with the following specifications:
I got the same board last week and had some initial support ready
locally. I pushed it now to my staging tree, please have a look:
https://git.lede-project.org/?p=lede/pepe2k/staging.git;a=shortlog;h=refs/heads/ramips_unielec-u7621-06
Maybe we can combine our patches and work out a common version.
Please, find also my comments below.
--
Cheers,
Piotr
[snip]
Notes:
* According to the specifications on the Unielec website, two LEDs
should be controllable via GPIO. I was not able to find the pins.
GPIOs 10, 11 and 12 control LEDs 3, 4 and 5 in top row. At least on my
board, some of these LEDs were rotated (wrong polarization).
* The device can be delivered with different amounts of RAM and
storage. I have only added support for devices with 256MB RAM and 16MB
storage, as that is the configuration of my device. However, I have
added all the required infrastructure for making adding support for the
other configurations easy.
AFAIK, board with 256/16 MB is the default one (mass production?). Any
change means MOQ and customized version. The default one can be easily
purchased from Ali..., directly from the vendor.
* I have assumed that the placement of wifi cards will be as on the image on
the Unielec website linked to above.
I have problem with this and I don't know how we should proceed here
(Mathias, what do you think?).
Actually, the board by default comes without any Wi-Fi card installed
and they need to be ordered separately (if someone needs them at all).
Personally, I don't think we should force any type of card and/or order
in slots. The board comes with two miniPCIe slots which can be used for
almost anything. I've been testing it with ath9k and mt7603 based cards,
a different configuration than yours :)
* The factory firmware reads the MAC address from offset e000 on the
factory partition. On my device, this offset contains 0xffs, but I have
chosen to keep the offset in the dts to ensure we are consistent with
the factory firmware.
AFAIK, the firmware vendor provides board with doesn't come from them.
They installed some version dedicated for PandoraBox PBR-M1.
There is also some dedicated Padavan version but I have no idea where it
can be downloaded from.
Installation:
See Recovery below. The router comes pre-installed with OpenWRT (Pandora
Box), but sysupgrade fails due to board name mismatch.
sysupgrade -F ...
Recovery:
The U7621-6 supports web recovery. If you keep the reset-button pressed
for ~5 seconds during boot, a webserver is started.Your machine will be
assigned an IP through DHCP, and the router has address 192.168.1.1. The
recovery website is in Chinese, but is easy to use. Click on the second
item in the list to access the recovery page, then the second item on
the next page is where you select the firmware. In order to start the
recovery, you click the button at the bottom.
At least on my board, button just stops autobooting process. Web server
seems to be enabled in the bootloader all the time - with a static IP on
my PC I can access it even during autobooting countdown.
Signed-off-by: Kristian Evensen
---
.../linux/ramips/base-files/etc/board.d/02_network | 1 +
target/linux/ramips/base-files/lib/ramips.sh | 3 +
.../ramips/base-files/lib/upgrade/platform.sh | 1 +
target/linux/ramips/dts/U7621-6-256M-16M.dts | 54
target/linux/ramips/dts/U7621-6.dtsi | 147 +
target/linux/ramips/image/mt7621.mk| 9 ++
6 files changed, 215 insertions(+)
create mode 100644 target/linux/ramips/dts/U7621-6-256M-16M.dts
create mode 100644 target/linux/ramips/dts/U7621-6.dtsi
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
b/target/linux/ramips/base-files/etc/board.d/02_network
index 1c8505e8c7..8530ca5170 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -102,6 +102,7 @@ ramips_setup_interfaces()
r6220|\
sap-g3200u3|\
sk-wb8|\
+ u7621-6-256M-16M|\
The board name is U7621-06 (not U7621-6).
As the 256/16 MB configuration is (seems to be) the default one, I don't
see any reason for a different board name.
[snip]
+/dts-v1/;
+
+#include "U7621-6.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "unielec,u7621-6-256m-16m", "unielec,u7621-6",
"mediatek,mt7621-soc";
+ model = "Unielec U7621-6 (256M RAM/16M flash)";
According to the vendor website and datasheet, it should be "UniElec
U7621-06".
+ gpio_export {
+ compatible = "gpio-export";
+ #size-cells = <0>;
+
+ modem_power {
+ gpio-export,name = "modem_power";
Th
Re: [LEDE-DEV] [PATCH] ar71xx: add support for TP-Link TL-WDR7500v6
Hello Karol,
Thank you for your patch but it seems that it got whitespace mangled and
tabs were replaced with spaces. Please, send v2 using git send-email.
Also, please see my comments inline, below.
On 30.10.2017 20:32, Bizon wrote:
Add support for TP-Link TL-WDR7500 V6.
Specifications:
- WiSoC: QCA9563 - 3x3 2.4GHz
- Radio2: QCA9880 - 3x3 5GHz
- RAM: 64MB DDR2
- Storage: 8MB NOR SPI flash, can be replaced with 16M
- Switch: RTL8367S, now unmanaged
- Ethernet: 5x1G
- Misc: 2x button, 2x LED
Please, include in commit message how to install LEDE on this device as
described under "commit description" section on [1].
Signed-off-by: Karol Bizewski
---
package/boot/uboot-envtools/files/ar71xx| 2 ++
target/linux/ar71xx/base-files/etc/board.d/02_network | 2 ++
target/linux/ar71xx/base-files/etc/diag.sh | 4
.../base-files/etc/hotplug.d/firmware/11-ath10k-caldata | 5 +
target/linux/ar71xx/base-files/lib/ar71xx.sh| 6 ++
target/linux/ar71xx/config-4.4 | 1 +
target/linux/ar71xx/config-4.9 | 1 +
.../linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt | 10 ++
target/linux/ar71xx/files/arch/mips/ath79/Makefile | 1 +
target/linux/ar71xx/files/arch/mips/ath79/machtypes.h | 1 +
target/linux/ar71xx/image/generic.mk| 17 +
.../files/arch/mips/ath79/mach-tl-wdr7500-v6.c | 112
+
12 files changed, 162 insertions(+)
create mode 100644
target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wdr7500-v6.c
diff --git a/package/boot/uboot-envtools/files/ar71xx
b/package/boot/uboot-envtools/files/ar71xx
index 0bdb6de..789c317 100644
--- a/package/boot/uboot-envtools/files/ar71xx
+++ b/package/boot/uboot-envtools/files/ar71xx
@@ -46,6 +46,8 @@ om5p-acv2|\
om5p-an|\
sr3200|\
tube2h|\
+tl-wdr7500-v6|\
+tl-wdr7500-v6-16M|\
Please, drop this "tl-wdr7500-v6-16M" thing. As far as I understand,
this is only your custom hardware modification and the default/factory
version comes with just 8 MB of FLASH.
And I really don't think this device has a writable U-Boot environment
in a separate sector. Please, provide some explanation.
wndr3700|\
xd3200)
ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x1" "0x1"
diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network
b/target/linux/ar71xx/base-files/etc/board.d/02_network
index d838352..6cdd2fe 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -122,6 +122,8 @@ ar71xx_setup_interfaces()
tl-wa901nd-v2|\
tl-wa901nd-v3|\
tl-wa901nd-v4|\
+ tl-wdr7500-v6|\
+ tl-wdr7500-v6-16M|\
tl-wr703n|\
tl-wr802n-v1|\
tl-wr802n-v2|\
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
b/target/linux/ar71xx/base-files/etc/diag.sh
index ade726f..f0ec9e6 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -20,6 +20,10 @@ get_status_led() {
all0305)
status_led="eap7660d:green:ds4"
;;
+ tl-wdr7500-v6|\
+ tl-wdr7500-v6-16M)
+ status_led="$board:blue:system"
+ ;;
antminer-s1|\
antminer-s3|\
antminer-r1|\
diff --git
a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 85a2a63..bd0cf2e 100644
--- a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -98,6 +98,11 @@ case "$FIRMWARE" in
rb-952ui-5ac2nd)
ath10kcal_from_file "/sys/firmware/routerboot/ext_wlan_data" 20480 2116
;;
+ tl-wdr7500-v6|\
+ tl-wdr7500-v6-16M)
+ ath10kcal_extract "art" 8192 2116
+ ath10kcal_patch_mac $(macaddr_add $(cat /sys/class/net/eth0/address) +2)
+ ;;
re450|\
tl-wr902ac-v1)
ath10kcal_extract "art" 20480 2116
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 835ced6..dbf132b 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -1109,6 +1109,12 @@ ar71xx_board_detect() {
*"TL-WDR6500 v2")
name="tl-wdr6500-v2"
;;
+ *"TL-WDR7500 v6")
+local size="$(mtd_get_part_size 'firmware')"
+
+[ "$size" = "8060928" ] && name="tl-wdr7500-v6"
+[ "$size" = "16449536" ] && name="tl-wdr7500-v6-16M"
As above.
Please don't include support for custom modified hardware.
[snip]
diff --git a/target/linux/ar71xx/image/generic.mk
b/target/linux/ar71xx/image/generic.mk
index 6f5a701..39be043 100644
--- a/target/linux/ar71xx/image/generic.mk
+++ b/target/linux/ar71xx/image/generic.mk
@@ -713,6 +713,23 @@ define Device/tellstick-znet-lite
endef
TARGET_DEVICES += tellstick-znet-lite
+define Device/tl-wdr7500-v6
+ DEVICE_TITLE := TP-LINK WDR7500 v6
Re: [LEDE-DEV] [PATCH] ramips: Add support for the Unielec U7621-6
Hello Mathias, On 05.11.2017 22:43, Mathias Kresin wrote: 05.11.2017 22:24, Piotr Dymacz: [snip] AFAIK, board with 256/16 MB is the default one (mass production?). Any change means MOQ and customized version. The default one can be easily purchased from Ali..., directly from the vendor. It is the same as with some of the ZBT boards. They're advertised with different RAM sizes, but so far all known boards have the same amount of ram. Not sure about the flash size. Especially for the ZBT boards it is known that they are shipped with different sized flash chips. I wouldn't be surprised if they change FLASH chips manually. And that's why different versions are widely available :) For BGA DRAM chips they probably run separate batch. But since you pepe have a way better insight what the OEMs/ODMs tend to do, it would be the best to follow your advice. * I have assumed that the placement of wifi cards will be as on the image on the Unielec website linked to above. I have problem with this and I don't know how we should proceed here (Mathias, what do you think?). Actually, the board by default comes without any Wi-Fi card installed and they need to be ordered separately (if someone needs them at all). Oh, I missed that detail. Personally, I don't think we should force any type of card and/or order in slots. The board comes with two miniPCIe slots which can be used for almost anything. I've been testing it with ath9k and mt7603 based cards, a different configuration than yours :) I totally agree. If the board isn't ship with a particular set of wireless cards, we shouldn't enforce anything. OK, lets just find out what they actually put inside factory partition. [snip] Pepe, are you fine if I handle this patch over to you? Doesn't make much sense to me if I do the review, while you are having the hardware. Sure, I will take care of this one. -- Cheers, Piotr ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] ramips: Add support for the Unielec U7621-6
Hello Kristian, On 05.11.2017 23:26, Kristian Evensen wrote: Hi Piotr and Mathias, On Sun, Nov 5, 2017 at 10:24 PM, Piotr Dymacz wrote: Hello Kristian, On 04.11.2017 21:53, Kristian Evensen wrote: The Unielec U7621-6 (http://www.unielecinc.com/q/news/cn/p/product/detail.html?qd_guid=pyrEjfTmYf) is an MT7621-based router with the following specifications: I got the same board last week and had some initial support ready locally. I pushed it now to my staging tree, please have a look: https://git.lede-project.org/?p=lede/pepe2k/staging.git;a=shortlog;h=refs/heads/ramips_unielec-u7621-06 Maybe we can combine our patches and work out a common version. Please, find also my comments below. Sure, that sounds great. I will take a look and reply in a separate email. GPIOs 10, 11 and 12 control LEDs 3, 4 and 5 in top row. At least on my board, some of these LEDs were rotated (wrong polarization). Ok, then my test was bogus. Thanks for letting me know. * The device can be delivered with different amounts of RAM and storage. I have only added support for devices with 256MB RAM and 16MB storage, as that is the configuration of my device. However, I have added all the required infrastructure for making adding support for the other configurations easy. AFAIK, board with 256/16 MB is the default one (mass production?). Any change means MOQ and customized version. The default one can be easily purchased from Ali..., directly from the vendor. I agree with Mathias comments in his reply to you. While the default sample board has 256/16, based on my discussions with Unielec it seems that the other configurations are also easy to get hold of. I think we should keep my (minimum) attempt at making it easy to support the other configurations. I'm fully OK with your dtsi+dts approach. * I have assumed that the placement of wifi cards will be as on the image on the Unielec website linked to above. I have problem with this and I don't know how we should proceed here (Mathias, what do you think?). Actually, the board by default comes without any Wi-Fi card installed and they need to be ordered separately (if someone needs them at all). Personally, I don't think we should force any type of card and/or order in slots. The board comes with two miniPCIe slots which can be used for almost anything. I've been testing it with ath9k and mt7603 based cards, a different configuration than yours :) I agree and have no problem removing the mt76-part from the pcie node. One thing I am unsure of is how to specify the EEPROM offset for mt76 cards, since the driver reads that from the dts. There seems to be no other way to pass configuration data to the driver. However, since there are so many potential configurations, perhaps some customization has to be required in order to support specific configs. I think we should first find out if that EEPROM content in factory partition is correct. I bet it's some default one they put on every board, no matter what they ship it with. * The factory firmware reads the MAC address from offset e000 on the factory partition. On my device, this offset contains 0xffs, but I have chosen to keep the offset in the dts to ensure we are consistent with the factory firmware. AFAIK, the firmware vendor provides board with doesn't come from them. They installed some version dedicated for PandoraBox PBR-M1. There is also some dedicated Padavan version but I have no idea where it can be downloaded from. Yeah, I know. There is a MAC at e006, but that one is the same for my two boards at least. Installation: See Recovery below. The router comes pre-installed with OpenWRT (Pandora Box), but sysupgrade fails due to board name mismatch. sysupgrade -F ... True, but I would argue that using web recovery is quicker than scp + ssh. However, explaining both options sounds good to me. Recovery: The U7621-6 supports web recovery. If you keep the reset-button pressed for ~5 seconds during boot, a webserver is started.Your machine will be assigned an IP through DHCP, and the router has address 192.168.1.1. The recovery website is in Chinese, but is easy to use. Click on the second item in the list to access the recovery page, then the second item on the next page is where you select the firmware. In order to start the recovery, you click the button at the bottom. At least on my board, button just stops autobooting process. Web server seems to be enabled in the bootloader all the time - with a static IP on my PC I can access it even during autobooting countdown. Yes, that is true, so the text should be rewritten a bit I guess. Signed-off-by: Kristian Evensen --- .../linux/ramips/base-files/etc/board.d/02_network | 1 + target/linux/ramips/base-files/lib/ramips.sh | 3 + .../ramips/base-files/lib/upgrade/platform.sh | 1 + target/linux/ramips/dts/U7621-6-256M-16M.dts | 54 target
Re: [LEDE-DEV] [PATCH] ar71xx: add support for TP-Link TL-WDR7500v6
Hello Karol,
Sorry for a late reply.
On 06.11.2017 18:58, Bizon wrote:
Hi Piotr,
Thank You for comments.
Before sending v2 patch lets clarify all doubts.
2017-11-05 23:22 GMT+01:00 Piotr Dymacz :
Hello Karol,
Thank you for your patch but it seems that it got whitespace mangled and
tabs were replaced with spaces. Please, send v2 using git send-email.
Also, please see my comments inline, below.
On 30.10.2017 20:32, Bizon wrote:
Add support for TP-Link TL-WDR7500 V6.
Specifications:
- WiSoC: QCA9563 - 3x3 2.4GHz
- Radio2: QCA9880 - 3x3 5GHz
- RAM: 64MB DDR2
- Storage: 8MB NOR SPI flash, can be replaced with 16M
- Switch: RTL8367S, now unmanaged
- Ethernet: 5x1G
- Misc: 2x button, 2x LED
Please, include in commit message how to install LEDE on this device as
described under "commit description" section on [1].
Ok, will prepare manual how to change bootloader to non-RSA one, move art and
install LEDE.
I'm sorry but I'm against accepting support for devices which requires
such invasive modifications. We always try to make it possible for users
to get back to the stock firmware which wouldn't be easy (or possible at
all) with your changes in mtd layout and after bootloader swap.
--
Cheers,
Piotr
Signed-off-by: Karol Bizewski
---
package/boot/uboot-envtools/files/ar71xx| 2 ++
target/linux/ar71xx/base-files/etc/board.d/02_network | 2 ++
target/linux/ar71xx/base-files/etc/diag.sh | 4
.../base-files/etc/hotplug.d/firmware/11-ath10k-caldata | 5 +
target/linux/ar71xx/base-files/lib/ar71xx.sh| 6 ++
target/linux/ar71xx/config-4.4 | 1 +
target/linux/ar71xx/config-4.9 | 1 +
.../linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt | 10 ++
target/linux/ar71xx/files/arch/mips/ath79/Makefile | 1 +
target/linux/ar71xx/files/arch/mips/ath79/machtypes.h | 1 +
target/linux/ar71xx/image/generic.mk| 17
+
.../files/arch/mips/ath79/mach-tl-wdr7500-v6.c | 112
+
12 files changed, 162 insertions(+)
create mode 100644
target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wdr7500-v6.c
diff --git a/package/boot/uboot-envtools/files/ar71xx
b/package/boot/uboot-envtools/files/ar71xx
index 0bdb6de..789c317 100644
--- a/package/boot/uboot-envtools/files/ar71xx
+++ b/package/boot/uboot-envtools/files/ar71xx
@@ -46,6 +46,8 @@ om5p-acv2|\
om5p-an|\
sr3200|\
tube2h|\
+tl-wdr7500-v6|\
+tl-wdr7500-v6-16M|\
Please, drop this "tl-wdr7500-v6-16M" thing. As far as I understand, this is
only your custom hardware modification and the default/factory version comes
with just 8 MB of FLASH.
Ok. 16MB flash is hw mod.
And I really don't think this device has a writable U-Boot environment in a
separate sector. Please, provide some explanation.
Original bootloader checks RSA for second bootloader and system.
To install LEDE I chose to replace bootloader instead of using any
workarounds (if even exists).
Working bootloader is available at:
https://github.com/bizongod/u-boot_wdr7500v6
It is based on u-boot from TL-WDR1043v4 plus initializing routines for
switch and other usable mods. It has also writable env.
With changing bootloader I decided also that's good opportunity to move
art to better address, that's end of flash.
wndr3700|\
xd3200)
ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x1" "0x1"
diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network
b/target/linux/ar71xx/base-files/etc/board.d/02_network
index d838352..6cdd2fe 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -122,6 +122,8 @@ ar71xx_setup_interfaces()
tl-wa901nd-v2|\
tl-wa901nd-v3|\
tl-wa901nd-v4|\
+ tl-wdr7500-v6|\
+ tl-wdr7500-v6-16M|\
tl-wr703n|\
tl-wr802n-v1|\
tl-wr802n-v2|\
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
b/target/linux/ar71xx/base-files/etc/diag.sh
index ade726f..f0ec9e6 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -20,6 +20,10 @@ get_status_led() {
all0305)
status_led="eap7660d:green:ds4"
;;
+ tl-wdr7500-v6|\
+ tl-wdr7500-v6-16M)
+ status_led="$board:blue:system"
+ ;;
antminer-s1|\
antminer-s3|\
antminer-r1|\
diff --git
a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 85a2a63..bd0cf2e 100644
---
a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++
b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -98,6 +98,11 @@ case "$FIRMWARE" in
rb-952ui-5ac2nd)
ath10kcal_from_file "/sys/firmware/routerboot/ext
Re: [LEDE-DEV] add support for Comfast E314N
Hello Bill,
Thank you for your patch but it seems that it got whitespace mangled and
tabs were replaced with spaces. Please, send v2 using git send-email.
Also, please see our submitting patches guide: [1]. Your patch is
missing at least:
- SoB line
- correct prefix in the subject
- information how to install LEDE on the device
[1] https://lede-project.org/submitting-patches
--
Cheers,
Piotr
On 28.11.2017 21:21, Bill Moffitt wrote:
Comfast E314N is a 2.4 GHz. outdoor directional wireless radio with two
Ethernet ports and PoE pass-through (controlled by a slide switch).
diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds
b/target/linux/ar71xx/base-files/etc/board.d/01_leds
index e5baa90..f1e29c7 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -182,6 +182,11 @@ carambola2)
ucidef_set_led_netdev "wan" "WAN" "$board:orange:eth1" "eth1"
ucidef_set_led_wlan "wlan" "WLAN" "$board:green:wlan" "phy0tpt"
;;
+cf-e314n)
+ ucidef_set_led_netdev "lan" "LAN" "$board:white:lan" "eth0"
+ ucidef_set_led_netdev "wan" "WAN" "$board:white:wan" "eth1"
+ ucidef_set_led_wlan "wlan" "WLAN" "$board:white:wlan" "phy0tpt"
+ ;;
cf-e316n-v2)
ucidef_set_led_netdev "lan" "LAN" "$board:blue:lan" "eth0"
ucidef_set_led_netdev "wan" "WAN" "$board:blue:wan" "eth1"
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
b/target/linux/ar71xx/base-files/etc/diag.sh
index 6cbb357..93b9e76 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -119,6 +119,7 @@ get_status_led() {
cap4200ag)
status_led="senao:green:pwr"
;;
+ cf-e314n|\
cf-e316n-v2|\
cf-e520n|\
cf-e530n)
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 285fa68..ee7b93a 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -504,6 +504,9 @@ ar71xx_board_detect() {
*"Carambola2"*)
name="carambola2"
;;
+ *"CF-E314N")
+ name="cf-e314n"
+ ;;
*"CF-E316N v2")
name="cf-e316n-v2"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 172a58b..159bd49 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -215,6 +215,7 @@ platform_check_image() {
bullet-m|\
c-55|\
carambola2|\
+ cf-e314n|\
cf-e316n-v2|\
cf-e320n-v2|\
cf-e355ac|\
diff --git a/target/linux/ar71xx/config-4.4 b/target/linux/ar71xx/config-4.4
index 3ba3853..134352b 100644
--- a/target/linux/ar71xx/config-4.4
+++ b/target/linux/ar71xx/config-4.4
@@ -67,6 +67,7 @@ CONFIG_ATH79_MACH_C55=y
CONFIG_ATH79_MACH_CAP324=y
CONFIG_ATH79_MACH_CAP4200AG=y
CONFIG_ATH79_MACH_CARAMBOLA2=y
+CONFIG_ATH79_MACH_CF_E314N=y
CONFIG_ATH79_MACH_CF_E316N_V2=y
CONFIG_ATH79_MACH_CF_E320N_V2=y
CONFIG_ATH79_MACH_CF_E355AC=y
diff --git a/target/linux/ar71xx/config-4.9 b/target/linux/ar71xx/config-4.9
index 1d47246..7047aa4 100644
--- a/target/linux/ar71xx/config-4.9
+++ b/target/linux/ar71xx/config-4.9
@@ -65,6 +65,7 @@ CONFIG_ATH79_MACH_C55=y
CONFIG_ATH79_MACH_CAP324=y
CONFIG_ATH79_MACH_CAP4200AG=y
CONFIG_ATH79_MACH_CARAMBOLA2=y
+CONFIG_ATH79_MACH_CF_E314N=y
CONFIG_ATH79_MACH_CF_E316N_V2=y
CONFIG_ATH79_MACH_CF_E320N_V2=y
CONFIG_ATH79_MACH_CF_E355AC=y
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
index 1198fcb..bd21f40 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
+++ b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
@@ -2051,6 +2051,16 @@ config ATH79_MACH_RAMBUTAN
select ATH79_DEV_USB
select ATH79_DEV_WMAC
+config ATH79_MACH_CF_E314N
+ bool "COMFAST CF-E314N support"
+ select SOC_QCA953X
+ select ATH79_DEV_ETH
+ select ATH79_DEV_GPIO_BUTTONS
+ select ATH79_DEV_LEDS_GPIO
+ select ATH79_DEV_M25P80
+ select ATH79_DEV_USB
+ select ATH79_DEV_WMAC
+
config ATH79_MACH_CF_E316N_V2
bool "COMFAST CF-E316N v2 support"
select SOC_AR934X
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Makefile
b/target/linux/ar71xx/files/arch/mips/ath79/Makefile
index 455af76..148c3a3 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/Makefile
+++ b/target/linux/ar71xx/files/arch/mips/ath79/Makefile
@@ -74,6 +74,7 @@ obj-$(CONFIG_ATH79_MACH_C60) += mach-c60.o
obj-$(CONFIG_ATH79_MACH_CAP324) += mach-cap324.o
obj-$(CONFIG_ATH79_MACH_CAP4200AG) += mach-cap4200ag.o
obj-$(CONFIG_ATH79_MACH_CARAMBOLA2) += mach-carambola2.o
+obj-$(CONFIG_ATH79_MACH_CF_E314N) += mach-cf-e316n-v2.o
obj-
Re: [LEDE-DEV] Add support for Comfast E312A
Hello Bill,
Thank you for your patch but it seems that it got whitespace mangled and
tabs were replaced with spaces. Please, send v2 using git send-email.
Also, please see our submitting patches guide: [1]. Your patch is
missing at least:
- SoB line
- correct prefix in the subject
- information how to install LEDE on the device
On 29.11.2017 19:53, Bill Moffitt wrote:
This unit is the 5 GHz cousin to the E314N - a 5 GHz. 2x2 radio with
built-in directional antenna. Very similar to a Ubiquiti NanoStation M5.
This version of the patch seems to have everything working.
I need some help generating a pull request (I'm a git newbie) - I have
followed the directions here:
https://lede-project.org/submitting-patches, but, when I get to the step
"git push --all" I get the response, "fatal: unable to access
'https://git.lede-project.org/source.git/': The requested URL returned
error: 403" and I can't seem to get past that.
From our submitting patches guide: "Patches can be submitted as a pull
request on Github or via the mailing list.". Please, use our GitHub
mirror for sending pull requests: [2].
[1] https://lede-project.org/submitting-patches
[2] https://github.com/lede-project/source
--
Cheers,
Piotr
Thanks!
diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds
b/target/linux/ar71xx/base-files/etc/board.d/01_leds
index e101d55..1c506d0 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -182,6 +182,11 @@ carambola2)
ucidef_set_led_netdev "wan" "WAN" "$board:orange:eth1" "eth1"
ucidef_set_led_wlan "wlan" "WLAN" "$board:green:wlan" "phy0tpt"
;;
+cf-e312a)
+ ucidef_set_led_netdev "lan" "LAN" "$board:white:lan" "eth0"
+ ucidef_set_led_netdev "wan" "WAN" "$board:white:wan" "eth1"
+ ucidef_set_led_wlan "wlan" "WLAN" "$board:white:wlan" "phy0tpt"
+ ;;
cf-e316n-v2)
ucidef_set_led_netdev "lan" "LAN" "$board:blue:lan" "eth0"
ucidef_set_led_netdev "wan" "WAN" "$board:blue:wan" "eth1"
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
b/target/linux/ar71xx/base-files/etc/diag.sh
index 5ef620b..6274841 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -118,6 +118,7 @@ get_status_led() {
cap4200ag)
status_led="senao:green:pwr"
;;
+ cf-e312a|\
cf-e316n-v2|\
cf-e520n|\
cf-e530n)
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 9903563..98ed277 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -504,6 +504,9 @@ ar71xx_board_detect() {
*"Carambola2"*)
name="carambola2"
;;
+ *"CF-E312A")
+ name="cf-e312a"
+ ;;
*"CF-E316N v2")
name="cf-e316n-v2"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 18e5e41..1b13230 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -215,6 +215,7 @@ platform_check_image() {
bullet-m|\
c-55|\
carambola2|\
+ cf-e312a|\
cf-e316n-v2|\
cf-e320n-v2|\
cf-e355ac|\
diff --git a/target/linux/ar71xx/config-4.4 b/target/linux/ar71xx/config-4.4
index 4793bf4..e86837f 100644
--- a/target/linux/ar71xx/config-4.4
+++ b/target/linux/ar71xx/config-4.4
@@ -67,6 +67,7 @@ CONFIG_ATH79_MACH_C55=y
CONFIG_ATH79_MACH_CAP324=y
CONFIG_ATH79_MACH_CAP4200AG=y
CONFIG_ATH79_MACH_CARAMBOLA2=y
+CONFIG_ATH79_MACH_CF_E312A=y
CONFIG_ATH79_MACH_CF_E316N_V2=y
CONFIG_ATH79_MACH_CF_E320N_V2=y
CONFIG_ATH79_MACH_CF_E355AC=y
diff --git a/target/linux/ar71xx/config-4.9 b/target/linux/ar71xx/config-4.9
index 84b2a0b..231e78e 100644
--- a/target/linux/ar71xx/config-4.9
+++ b/target/linux/ar71xx/config-4.9
@@ -65,6 +65,7 @@ CONFIG_ATH79_MACH_C55=y
CONFIG_ATH79_MACH_CAP324=y
CONFIG_ATH79_MACH_CAP4200AG=y
CONFIG_ATH79_MACH_CARAMBOLA2=y
+CONFIG_ATH79_MACH_CF_E312A=y
CONFIG_ATH79_MACH_CF_E316N_V2=y
CONFIG_ATH79_MACH_CF_E320N_V2=y
CONFIG_ATH79_MACH_CF_E355AC=y
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
index 5cb4f7e..e0484f2 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
+++ b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
@@ -2021,6 +2021,16 @@ config ATH79_MACH_RAMBUTAN
select ATH79_DEV_USB
select ATH79_DEV_WMAC
+config ATH79_MACH_CF_E312A
+ bool "COMFAST CF-E312A support"
+ select SOC_AR934X
+ select ATH79_DEV_ETH
+ select ATH79_DEV_GPIO_BUTTONS
+ select ATH79_DEV_LEDS_GPIO
+ select ATH79_DEV_M25P80
+ select ATH79_DEV_USB
+ select ATH79_DEV_WMAC
+
config ATH79_MACH_CF_E316N_V2
bool "COM
Re: [LEDE-DEV] [PATCH] ar71xx: add support for TP-Link TL-WDR7500v6
Hello Bill, On 29.11.2017 20:17, Bill Moffitt wrote: Hello Piotr and Karol, [snip] Please, include in commit message how to install LEDE on this device as described under "commit description" section on [1]. Ok, will prepare manual how to change bootloader to non-RSA one, move art and install LEDE. I'm sorry but I'm against accepting support for devices which requires such invasive modifications. We always try to make it possible for users to get back to the stock firmware which wouldn't be easy (or possible at all) with your changes in mtd layout and after bootloader swap. In general, of course, I agree. However, we are seeing an increasing number of vendors (TP-Link and Ubiquiti, to name 2) using some form of locking in the bootloader to prevent loading of third-party firmware. Then buy and use hardware from vendors who are open source friendly and allow users to actually fully own the hardware they paid for! :) The only option for loading OpenWRT (permanently - not using initramfs) on these devices will be replacing the bootloader, as Karol does in this patch. Swapping bootloader isn't the only issue I see here. Moving ART which is essential and unique per device might end up in a data loss which cannot be recovered in any way. If the only objection is that it involves invasive modifications that may not (probably won't) allow the device to be re-flashed to stock, I would prefer we accept the patch and make a very strongly-worded note in the ToH and the device's wiki page explaining the situation. This is not the only one objection. Personally I don't have problems with swapping bootloader and for ar71xx target we already have a dedicated package with old U-Boot sources: [1] The problem here is that the bootloader the user has to use for this device comes from some random GitHub repository which exist today but may disappear tomorrow. Who will make sure that the bootloader image the author of the support mentions in his patch will be still available in next years and is correct and won't break users device? If the bootloader code was in our repository or in upstream, I would be first one accepting support for this device. What's also important to notice here, devices with QCA WiSoCs and SPI NOR flash chips aren't easy to recover from a failed bootloader flash. If there is no JTAG on the board the only way to bring device back to life is to use flash chip programmer. [1] https://github.com/lede-project/source/tree/master/package/boot/uboot-ar71xx -- Cheers, Piotr FWIW, Bill ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] fixing of image file names
Hello Mathias,
On 29.11.2017 09:33, Mathias Kresin wrote:
28.11.2017 19:24, Daniel Golle:
Hi Moritz,
thanks for stepping forward and adressing this issue.
It'd be good to include the two assertions added to your list beelow.
On Tue, Nov 28, 2017 at 07:05:23PM +0100, Moritz Warning wrote:
Hi,
I noticed that there are some image file names that do not follow the "common"
name scheme.
Is it ok to change it? I would like to submit a patch.
Some examples:
- all lower case image names
- lede-ipq806x-EA8500-squashfs-sysupgrade.tar =>
lede-ipq806x-ea8500-squashfs-sysupgrade.tar
- revision between -
- lede-mvebu-linksys-wrt1900acv2-squashfs-sysupgrade.bin =>
lede-mvebu-linksys-wrt1900ac-v2-squashfs-sysupgrade.bin
- region specific images with region identifiers (us, eu, il, ...)
- lede-ramips-rt305x-wnce2001-squashfs-factory-northamerica.bin =>
lede-ramips-rt305x-wnce2001-us-squashfs-factory.bin
- separate images for each version
- lede-brcm47xx-mips74k-linksys-e1000-v1-v2-v2.1-squashfs.bin =>
lede-brcm47xx-mips74k-linksys-e1000-v1-squashfs.bin, ...
- board_name (in target userspace) == profile (in imagebuilder) == DTS name
- image_filename ==
${distro}-${target}-${subtarget}-${board_name}-${fstype}-${imgtype}
that would make identifying sysupgrade images much more straight
forward (and hence automatizable).
See also
https://github.com/aparcar/attendedsysupgrade-server/issues/80
I would like to propose something different which basically aims the same.
We already discussed this outside the list, let me make a summary and
share my comments below.
1. fix the compatible strings in the DTS files
I think we should start at the same time upstreaming vendor prefixes to
[1], to avoid possible incompatibility/inconsistency later.
2. use the compatible string from the DTS in userspace (boardname)
This is a great idea and I fully support it.
3. use the compatible string for the image filename (board_name in above
example)
This one might be a bit more complicated as we thought before, see below.
The DTS compatible string is supposed to be unique across the whole
kernel and this way we can prevent duplicates in big targets like ramips.
The compatible string includes the vendor, which will make it way easier
to find a particular image in directories with a lot of images. In
theory, it should be even possible to provide all images in a single
directory without target/subtarget prefix.
FWIW, this would also solve boardname collision problems in userspace.
For example, we have support for boards from different vendors in ar71xx
target (it's legacy but I believe we will convert it to dts at some
point) with the same names: Atheros AP96 and ALFA Network AP96.
Since the underscore isn't a valid character in compatible strings, we
can use it in the image filename as replacement for the comma to split
vendor from boardname.
The assumption about the underscore character was my suggestion but it
seems that it's not (fully) valid. At least, after researching this
more, I was able to find only one reference in kernel patchwork: [2].
I suppose it's only a general convention rather than a documented
requirement (I'm might be wrong here, anyone? Maybe we should just ask
upstream about this) as there are already some examples in upstream
which contain underscores inside compatible strings: [3], [4].
Assuming above and the fact that and parts used in
compatible string, based on dt specification: [5], might contain any
printable characters (which might not be filename and Makefile safe), we
shouldn't make any assumptions about that.
Due to the sync of runtime boardname and the boardname used in the image
filename, it should be possible to guess the used image filename more
reliably as requested.
I would like to propose here slightly extended version of compatible
string -> boardname part in image filename (and our building code)
conversion function:
1. Convert all letters to lowercase.
2. Replace characters different than [a-z], [0-9] and comma with dash.
3. Replace comma with underscore.
I think that we could even include above function in userspace and
expose the value somewhere, maybe in /tmp/sysinfo?
This would make searching for dedicated image for a specific device much
easier. I think, it could solve some other issues too, already reported
in [6] and in community projects like [7].
And personally, I would like to see same naming convention (no matter
which one we select) in use across all (sub)targets. At now, as the
"common" scheme isn't documented, there are different approaches as
Mortiz already pointed out.
[snip]
Any feedback on this approach (and help in migrating exists boards of
course) is highly welcome.
I still have here some concerns/thoughts:
1. I don't know how to deal in above approach with region variant images
but I'm sure we should _somehow_ separate region code from boardname and
other parts of the image filename.
Re: [LEDE-DEV] [PATCH] ar71xx: add support for GL.iNet GL-AR750
Hello Luochongjun,
On 06.12.2017 07:47, Luochongjun wrote:
From: Luochongjun <1464691...@qq.com>
This patch adds supports for the GL.iNet GL-AR750
Thanks for your patch.
I have support for this device in my staging tree [1]. I will look at
your patch and add missing parts (like I2C over GPIO).
[1] https://git.lede-project.org/?p=lede/pepe2k/staging.git;a=summary
--
Cheers,
Piotr
Specifiation:
- SoC: QCA9531 at 650 MHz
- Flash: 16 MiB (W25Q128FVSG)
- RAM: 128 MiB DDR
- Ethernet: 1 x WAN (100 Mbps) and 2 x LAN (100 Mbps)
- USB: 1 x USB 2.0 port
- Button: 1 x switch button, 1 x reset button
- LED: 3 x LEDS
- UART: 1 x UART on PCB (JP1: GND, RX, TX, 3.3V)
Installation through Luci:
- The original firmware is LEDE, so both LuCI or sysupgrade can be used.
- Do not keep settings, for sysupgrade please use the -n option.
Installation through bootloader webserver:
- Plug power and hold reset button until red LED blink to bright.
- Install sysupgrade image using web interface on 192.168.1.1.
Signed-off-by: chongjun Luo <1464691...@qq.com>
---
target/linux/ar71xx/base-files/etc/board.d/01_leds | 4 +
.../linux/ar71xx/base-files/etc/board.d/02_network | 1 +
target/linux/ar71xx/base-files/etc/diag.sh | 3 +-
.../etc/hotplug.d/firmware/11-ath10k-caldata | 4 +
target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 +
.../ar71xx/base-files/lib/upgrade/platform.sh | 1 +
target/linux/ar71xx/config-4.4 | 1 +
.../ar71xx/files/arch/mips/ath79/Kconfig.openwrt | 10 ++
target/linux/ar71xx/files/arch/mips/ath79/Makefile | 1 +
.../ar71xx/files/arch/mips/ath79/mach-gl-ar750.c | 187 +
.../linux/ar71xx/files/arch/mips/ath79/machtypes.h | 1 +
target/linux/ar71xx/image/generic.mk | 10 ++
12 files changed, 225 insertions(+), 1 deletion(-)
mode change 100644 => 100755 target/linux/ar71xx/base-files/etc/diag.sh
mode change 100644 => 100755
target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
mode change 100644 => 100755 target/linux/ar71xx/config-4.4
mode change 100644 => 100755
target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
mode change 100644 => 100755
target/linux/ar71xx/files/arch/mips/ath79/Makefile
create mode 100755 target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar750.c
mode change 100644 => 100755
target/linux/ar71xx/files/arch/mips/ath79/machtypes.h
mode change 100644 => 100755 target/linux/ar71xx/image/generic.mk
diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds
b/target/linux/ar71xx/base-files/etc/board.d/01_leds
index e5baa90..c948902 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -391,6 +391,10 @@ dlan-pro-1200-ac)
gl-ar300m)
ucidef_set_led_wlan "wlan" "WLAN" "$board:red:wlan" "phy0tpt"
;;
+gl-ar750)
+ ucidef_set_led_wlan "wlan-2g" "WLAN-2G" "gl-ar750:wlan-2g" "phy1tpt"
+ ucidef_set_led_wlan "wlan-5g" "WLAN-5G" "gl-ar750:wlan-5g" "phy0tpt"
+ ;;
gl-mifi)
ucidef_set_led_wlan "wlan" "WLAN" "$board:green:wlan" "phy0tpt"
ucidef_set_led_netdev "wan" "WAN" "$board:green:wan" "eth0"
diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network
b/target/linux/ar71xx/base-files/etc/board.d/02_network
index 7cf4212..01887f2 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -145,6 +145,7 @@ ar71xx_setup_interfaces()
dr344|\
gl-ar150|\
gl-ar300m|\
+ gl-ar750|\
gl-domino|\
gl-inet|\
gl-mifi|\
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
b/target/linux/ar71xx/base-files/etc/diag.sh
old mode 100644
new mode 100755
index 6cbb357..6e5341d
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -75,7 +75,7 @@ get_status_led() {
ap90q|\
cpe830|\
cpe870|\
- gl-ar300m|\
+ gl-ar300m|\
gl-inet|\
gl-mifi)
status_led="$board:green:lan"
@@ -521,6 +521,7 @@ set_state() {
done)
status_led_on
case $(board_name) in
+ gl-ar750|\
gl-ar300m)
fw_printenv lc >/dev/null 2>&1 && fw_setenv "bootcount" 0
;;
diff --git
a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
old mode 100644
new mode 100755
index 6a0a59f..d0e7b76
--- a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -81,6 +81,10 @@ case "$FIRMWARE" in
ath10kcal_extract "art" 20480 2116
ath10kcal_patch_mac $(mtd_get_mac_binary art 18)
Re: [LEDE-DEV] [PATCH] ar71xx: add support for TP-Link TL-WDR7500v6
Hello Bill, On 30.11.2017 22:06, Bill Moffitt wrote: Piotr- Good points all... [snip] In general, of course, I agree. However, we are seeing an increasing number of vendors (TP-Link and Ubiquiti, to name 2) using some form of locking in the bootloader to prevent loading of third-party firmware. Then buy and use hardware from vendors who are open source friendly and allow users to actually fully own the hardware they paid for! :) Hey, THERE'S a good idea!!! Suggestions??? :-D (especially for outdoors - that's why I'm working with the Comfast devices...) There are great people working on the Wiki and table of hardware [1]. The ToH is now mostly driven by information included in commits which add support for new devices. You can also ask on the forum [2] for hardware suggestions. The only option for loading OpenWRT (permanently - not using initramfs) on these devices will be replacing the bootloader, as Karol does in this patch. Swapping bootloader isn't the only issue I see here. Moving ART which is essential and unique per device might end up in a data loss which cannot be recovered in any way. Yes, that's true. But the only other option is not use the hardware. I wouldn't be surprised if there is some other way but people usually prefer "make it working and forget" approach (I follow it very often, too). [snip] But I'd still rather endorse a notation in the ToH and the wiki than just prevent the patch from being accepted. I think it's always up to the person who takes care (and spends time reviewing, merging and then maintaining related code in future) about the patch/PR as we don't have any strictly defined rule/s about what device/platform can be accepted. If someone else feels that this patch should be included, I won't argue - I have already pointed out what's in my opinion wrong with it. Everything in OpenWRT is pretty much "use at your own risk." Could we make a distinction between "Use at your own risk - might cause problems that will be hard to get around" and "Use at your own risk - you have a pretty good chance of bricking this thing?" Or, put another way, instead of just saying "supported" could we have platforms that are "Supported and easy" to "Supported, but, hey, this thing is ugly and will hurt you if you're not careful?" I hope some day in future OpenWrt/LEDE will have all the code required to support every platform from top to bottom, including bootloader/s, radio firmware, JTAG configs, etc. But we are not there yet. FWIW, there is an ongoing work on making Barebox bootloader support MIPS based QCA WiSoCs [3] and a PR with packaging it is under review: [4]. We should do everything we can to reduce the risk of a repo going away, etc., but I'd endorse using some sketchy sources if necessary to gain support of a particular device. I think it's always a trade off and every single person would have different opinion here. It is good and necessary to look out for the naive beginner (as we all were at one time). But, at the same time, there is value in supporting the wisened and experienced user who can go to some extra effort and undertake some risk for a particular purpose. As Mathias wrote, the patch was sent to a public mailing list and now any [experienced] user can take it and make use of it... assuming that (s)he would magically find out where to get, compile and write the custom bootloader. The patch doesn't include any clue about that. That's how I feel about it. As always, FWIW. Thanks, I appreciate every valuable comment! [1] https://lede-project.org/toh/start [2] https://forum.lede-project.org/ [3] https://git.pengutronix.de/cgit/barebox/log/?qt=grep&q=ath79 [4] https://github.com/lede-project/source/pull/1556 -- Cheers, Piotr ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] ar71xx: add support for Comfast CF-E312A V2
Hello Bill,
Please see below some more comments (excluding those from John).
I closed your PR on GitHub [1] as it's a copy of your patch (there is no
need to send it here and on GitHub).
On 06.12.2017 20:37, bmoff...@bmoffitt.com wrote:
The Comfast CF-E312A V2 is a 5 GHz radio with a built-in directional antenna,
much like a Ubiquiti NanoStation M5.
Specifiation:
- SoC: AR9344 at 650 MHz
- Flash: 16 MiB (W25Q128FVSG)
- RAM: 64 MiB DDR2 (W9751G6KB)
- Ethernet: 1 x WAN (100 Mbps) and 1 x LAN (100 Mbps)
- Button: 1 x reset button, 1 x PoE pass-through switch
- LED: 8 x LEDS (Power, LAN, WAN, Wireless, 4 signal LEDs)
- UART: 1 x UART with header on PCB (GND, RX, TX, 3.3V)
It is very similar to the CF-316N - similar chipset, etc. The major
differences are:
* It operates at 5 GHz, not 2.4
* All the LEDs are white
* It has 4 signal LEDs
Of note: the eth1 port has an optional PoE pass-through, controlled with a
slider switch.
Most of the changes are in the file
target/linux/ar71xx/files/arch/mips/ath79/mach-cf-e316n-v2.c - the code
for the E316N was copied and modified to support the additional LEDs, the
LED colors, and a few changes in the GPIOs.
Firmware can be flashed on these units by the following method:
1.) Apply power to the unit
2.) Immediately AFTER applying power, hold down the reset button
3.) The WAN, LAN, and wireless lights will flash - wait three seconds
(three flashes) and then release the button.
4.) After a second, the lights will "flutter" quickly and the unit will
be visible at 192.168.1.1. A web page will be available to enable quick
and simple uploading and flashing of firmware.
During the boot process, these units also look for a tftp server at
192.168.1.10. If one is present, the firmware can be uploaded as a file
called "firmware-auto.bin"
Signed-off-by: bmoff...@bmoffitt.com
---
target/linux/ar71xx/base-files/etc/board.d/01_leds | 5 +
target/linux/ar71xx/base-files/etc/diag.sh | 1 +
target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 +
.../ar71xx/base-files/lib/upgrade/platform.sh | 1 +
target/linux/ar71xx/config-4.4 | 1 +
target/linux/ar71xx/config-4.9 | 1 +
.../ar71xx/files/arch/mips/ath79/Kconfig.openwrt | 10 ++
target/linux/ar71xx/files/arch/mips/ath79/Makefile | 1 +
.../files/arch/mips/ath79/mach-cf-e316n-v2.c | 127 +
.../linux/ar71xx/files/arch/mips/ath79/machtypes.h | 1 +
target/linux/ar71xx/image/generic.mk | 8 ++
11 files changed, 159 insertions(+)
diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds
b/target/linux/ar71xx/base-files/etc/board.d/01_leds
index e5baa90..c55a8bc 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -182,6 +182,11 @@ carambola2)
ucidef_set_led_netdev "wan" "WAN" "$board:orange:eth1" "eth1"
ucidef_set_led_wlan "wlan" "WLAN" "$board:green:wlan" "phy0tpt"
;;
+cf-e312a)
If it's CF-E312A v2, please follow the general approach (example is just
a few lines below) and use "cf-e312a-v2" for the board name. If not
(COMFAST surprises me all the time with their weird and broken version
scheme), please change your commit subject and description (drop v2).
+ ucidef_set_led_netdev "lan" "LAN" "$board:white:lan" "eth0"
+ ucidef_set_led_netdev "wan" "WAN" "$board:white:wan" "eth1"
+ ucidef_set_led_wlan "wlan" "WLAN" "$board:white:wlan" "phy0tpt"
+ ;;
cf-e316n-v2)
ucidef_set_led_netdev "lan" "LAN" "$board:blue:lan" "eth0"
ucidef_set_led_netdev "wan" "WAN" "$board:blue:wan" "eth1"
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
b/target/linux/ar71xx/base-files/etc/diag.sh
index 6cbb357..45939ea 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -119,6 +119,7 @@ get_status_led() {
cap4200ag)
status_led="senao:green:pwr"
;;
+ cf-e312a|\
cf-e316n-v2|\
cf-e520n|\
cf-e530n)
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 285fa68..7491f2d 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -504,6 +504,9 @@ ar71xx_board_detect() {
*"Carambola2"*)
name="carambola2"
;;
+ *"CF-E312A")
+ name="cf-e312a"
+ ;;
*"CF-E316N v2")
name="cf-e316n-v2"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 172a58b..fd81bf1 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -215,6 +215,7 @@ platform_check_image() {
bullet-m|\
c-55|\
Re: [LEDE-DEV] fixing of image file names
Hi Jo, On 01.12.2017 14:37, Jo-Philipp Wich wrote: Hi, I still have here some concerns/thoughts: 1. I don't know how to deal in above approach with region variant images but I'm sure we should _somehow_ separate region code from boardname and other parts of the image filename. IMHO, dash character won't work here. 2. We have some boards versions like "v2.1" which with my above approach would end up as "v2-1". Maybe we should keep dot as a valid character in version part? 3. Some of devices come in different RAM/flash configurations and in case where common image can't support all of them, we include information about RAM/flash variant sometimes only in image name and sometimes in both the image name and boardname/compatible string. A common and defined approach would be required for this as well. A number of these issues can also be addressed by producing a Manifest file in the same directory which allows users to map unique board identifications to an appropriate image file. This would also work for cases where multiple boards share the very same file. That might be a solution but wouldn't it mean more meta data/information about devices included in building code? Or how could that manifest file be automatically generated otherwise? -- Cheers, Piotr ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] fixing of image file names
Hi Mathias, On 01.12.2017 16:12, Mathias Kresin wrote: Hey Piotr , thanks a lot for thinking about my proposal. Sorry for a very late reply. 2017-12-01 14:30 GMT+01:00 Piotr Dymacz : On 29.11.2017 09:33, Mathias Kresin wrote: 1. fix the compatible strings in the DTS files I think we should start at the same time upstreaming vendor prefixes to [1], to avoid possible incompatibility/inconsistency later. I really doubt that upstream is going to accept vendor prefixes if they aren't used anywhere. I would prefer to use what already exists, add our own prefixes where required and upstream them at the time the dts is send upstream. I don't know but have a look at "opalkelly" [1] (recent example). The assumption about the underscore character was my suggestion but it seems that it's not (fully) valid. At least, after researching this more, I was able to find only one reference in kernel patchwork: [2]. I suppose it's only a general convention rather than a documented requirement (I'm might be wrong here, anyone? Maybe we should just ask upstream about this) as there are already some examples in upstream which contain underscores inside compatible strings: [3], [4]. Assuming above and the fact that and parts used in compatible string, based on dt specification: [5], might contain any printable characters (which might not be filename and Makefile safe), we shouldn't make any assumptions about that. I share your understanding of the devicetree spec. So far I have only seen a handful of distortions in compat strings, like underlines. Never noticed any (special) charter beside [a-z], [0-9] and [-_]. I was able to find also examples of: '+' in [2], '.' in [3] and '/' in [4]. What's more, we have '+', '@' and '/' in our tree: [5], [6], [7]. Due to the sync of runtime boardname and the boardname used in the image filename, it should be possible to guess the used image filename more reliably as requested. I would like to propose here slightly extended version of compatible string -> boardname part in image filename (and our building code) conversion function: 1. Convert all letters to lowercase. 2. Replace characters different than [a-z], [0-9] and comma with dash. 3. Replace comma with underscore. 3. is already done. I would prefer to add code for 1. and 2. at the time it is required. Agree. Just be aware of above findings. Beside of that, ACK to the filename specs. I think that we could even include above function in userspace and expose the value somewhere, maybe in /tmp/sysinfo? Same as above. Fine with me, but I prefer to add such code at the time it is required. So far, all dts compat strings I've touched only consists of [a-z], [0-9] and [-], which allows an easy conversion of dts compat string to boardname. Agree here as well. Any feedback on this approach (and help in migrating exists boards of course) is highly welcome. I still have here some concerns/thoughts: 1. I don't know how to deal in above approach with region variant images but I'm sure we should _somehow_ separate region code from boardname and other parts of the image filename. IMHO, dash character won't work here. It would be illusionary to assume that the compat string to image filename matching will work in all cases. I'm fine if it works in most cases. For edge cases we can use some kind of mapping file. Maybe that mapping file isn't a bad idea. Could be useful also for some external projects already mentioned before. 2. We have some boards versions like "v2.1" which with my above approach would end up as "v2-1". Maybe we should keep dot as a valid character in version part? Yeah why not. As the devicetree spec doesn't prohibit any chars, it should be fine. Is anyone aware that such a compatible string was rejected upstream? There are some compatible strings with dots in upstream so I would say it's allowed or at least it was at some point before. 3. Some of devices come in different RAM/flash configurations and in case where common image can't support all of them, we include information about RAM/flash variant sometimes only in image name and sometimes in both the image name and boardname/compatible string. A common and defined approach would be required for this as well. Shouldn't different devicetree source files be used in that case? I mean, they need a different image for a reason. Maybe because the memory and/or the partition node in the dts is different. Yes, I just wanted to point out that most of the manufacturers don't care about properly naming different variants of their boards/devices and thus we have to deal with that. Anyway, we have other examples for the mentioned issue in the lantiq tree: dgn3500/dgn3500b and wbmrA/wbmrB. The only difference between the boards is the sup
Re: [LEDE-DEV] [PATCH v4] ar71xx: add ew-balin platform from Embedded Wireless
Hello Catrinel,
As John already wrote, it seems that your patch got whitespace mangled.
Please, send new version using git send-email.
Also, please see minor comments inline, below.
On 13.01.2018 11:36, Catrinel Catrinescu wrote:
Add the Embedded Wireless "Balin" platform, based on AR9344:
http://www.embeddedwireless.de/uploads/Balin_data_2016_10.pdf
Please, drop url from commit message.
SoC: QCA AR9344 or AR9350
RAM: DDR2-RAM 64MBytes
Flash: SPI-NOR 16MBytes
WLAN: 2 x 2 MIMO 2.4 & 5 GHz IEEE802.11 a/b/g/n
Ethernet: 3 x 10/100 Mb/s
USB: 1 x USB2.0 Host/Device bootstrap-pin at power-up
PCI-Express: 1 x lane PCIe 1.2
UART: 1 x Normal, 1 x High-Speed
JTAG: 1 x EJTAG
GPIO: 10 x Input/Output multiplexed
The module comes already with the current vanilla OpenWRT firmware, so no need to install
"factory"-image, or any other stuff :-)
OpenWRT -> OpenWrt.
If the boards already runs OpenWrt, maybe it would be better to write
something like this instead: Use "sysupgrade" image directly in vendor
firmware which is based on OpenWrt.
I don't see any reason to mention that "factory" image is not required
when your patch doesn't include code for it.
And please, drop ":-)" ;)
Signed-off-by: Catrinel Catrinescu
---
.../linux/ar71xx/base-files/etc/board.d/02_network | 6 ++
target/linux/ar71xx/base-files/etc/diag.sh | 3 +
.../etc/uci-defaults/03_network-switchX-migration | 1 +
target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 +
.../ar71xx/base-files/lib/upgrade/platform.sh | 1 +
target/linux/ar71xx/config-4.4 | 1 +
target/linux/ar71xx/config-4.9 | 1 +
.../ar71xx/files/arch/mips/ath79/Kconfig.openwrt | 11 ++
target/linux/ar71xx/files/arch/mips/ath79/Makefile | 1 +
.../ar71xx/files/arch/mips/ath79/mach-ew-balin.c | 112 +
.../linux/ar71xx/files/arch/mips/ath79/machtypes.h | 1 +
target/linux/ar71xx/image/generic.mk | 9 ++
target/linux/ar71xx/mikrotik/config-default| 1 +
target/linux/ar71xx/nand/config-default| 1 +
14 files changed, 152 insertions(+)
create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-ew-balin.c
diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network
b/target/linux/ar71xx/base-files/etc/board.d/02_network
index fb61792bf4..4919e7c983 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -368,6 +368,12 @@ ar71xx_setup_interfaces()
ucidef_add_switch "switch0" \
"0@eth0" "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "5:wan"
;;
+ ew-balin)
+ ucidef_set_interface_raw "usb2" "usb0" "static"
+ ucidef_set_interface_raw "usb3" "usb0" "static"
Could you please explain these two lines?
This code will create two static interfaces with the same netdev (usb0).
Is USB in this module/board set to device mode by default?
+ ucidef_add_switch "switch0" \
+ "0@eth0" "5:lan:4" "4:lan:5" "3:wan"
+ ;;
ew-dorin)
ucidef_add_switch "switch0" \
"0@eth0" "1:lan" "2:lan" "3:wan"
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
b/target/linux/ar71xx/base-files/etc/diag.sh
index 6cbb3576d8..ca73d5f62b 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -193,6 +193,9 @@ get_status_led() {
el-mini)
status_led="easylink:green:system"
;;
+ ew-balin)
+ status_led="balin:green:status"
+ ;;
ew-dorin|\
ew-dorin-router)
status_led="dorin:green:status"
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index b5440230a5..162742a94c 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -640,6 +640,9 @@ ar71xx_board_detect() {
*"EL-MINI")
name="el-mini"
;;
+ *EmbWir-Balin)
*"EmbWir-Balin")
+ name="ew-balin"
+ ;;
*"EmbWir-Dorin")
name="ew-dorin"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index ecf6820a2b..9dceadc563 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -237,6 +237,7 @@ platform_check_image() {
epg5000|\
esr1750|\
esr900|\
+ ew-balin|\
ew-dorin|\
ew-dorin-router|\
gl-ar150|\
diff --git a/target/linux/ar71xx/config-4.4 b/target/linux/ar71xx/config-4.4
index 5a8004a03e..36b266f21c 100644
--- a/target/linux/ar71xx/config-4.4
+++ b/target/linux/ar71xx/config-
Re: [LEDE-DEV] [PATCH] ar71xx: add support for Ubiquiti Litebeam M5
Hello Arne, Minor thing inline, below. On 16.01.2018 21:43, Arne Zachlod wrote: [...] +lbe-m5) + ucidef_set_led_netdev "lan" "LAN" "ubnt:green:lan" "eth0" + ucidef_set_led_wlan "wlan" "WLAN" "ubnt:green:wlan" "phy0tpt" + ucidef_set_led_default "sys" "SYS" "ubnt:green:sys" "1" There is no need to setup "ubnt:green:sys" LED here as it's already handled in diag.sh (below). If the LED doesn't light up after boot then probably polarity is wrong (active_low). [...] + lbe-m5) + status_led="ubnt:green:sys" + ;; [...] -- Cheers, Piotr ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] ar71xx: uniform GL iNet products mach name
Hello Kyson,
On 19.01.2018 02:54, Kyson Lok wrote:
The mach name of GL AR150 and GL AR300 is inconsistent
with other products.
Thank you for your patch.
Please, include also vendor name (GL.iNet) in the machine name.
--
Cheers,
Piotr
Signed-off-by: Kyson Lok
---
target/linux/ar71xx/base-files/lib/ar71xx.sh | 4 ++--
target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar150.c | 2 +-
target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar300.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index b664249..7d414ed 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -664,10 +664,10 @@ ar71xx_board_detect() {
*"FRITZ!WLAN Repeater 300E")
name="fritz300e"
;;
- *"GL AR150")
+ *"GL-AR150")
name="gl-ar150"
;;
- *"GL AR300")
+ *"GL-AR300")
name="gl-ar300"
;;
*"GL-AR300M")
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar150.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar150.c
index df52784..9824bb8 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar150.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar150.c
@@ -122,4 +122,4 @@ static void __init gl_ar150_setup(void)
ath79_register_wmac(art + GL_AR150_CALDATA_OFFSET, art +
GL_AR150_WMAC_MAC_OFFSET);
}
-MIPS_MACHINE(ATH79_MACH_GL_AR150, "GL-AR150", "GL AR150",gl_ar150_setup);
+MIPS_MACHINE(ATH79_MACH_GL_AR150, "GL-AR150", "GL-AR150",gl_ar150_setup);
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar300.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar300.c
index 6f01b9e..ae96635 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar300.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar300.c
@@ -100,4 +100,4 @@ static void __init gl_ar300_setup(void)
ath79_register_wmac(art + GL_AR300_CALDATA_OFFSET, art +
GL_AR300_WMAC_MAC_OFFSET);
}
-MIPS_MACHINE(ATH79_MACH_GL_AR300, "GL-AR300", "GL AR300",gl_ar300_setup);
+MIPS_MACHINE(ATH79_MACH_GL_AR300, "GL-AR300", "GL-AR300",gl_ar300_setup);
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] patchwork
Hi Val, On 19.01.2018 02:02, Val Kulkov wrote: On 18 January 2018 at 19:49, Alberto Bursi wrote: On 01/19/2018 01:05 AM, Val Kulkov wrote: There is more than a handful of PRs currently bit-rotting in openwrt/packages that are ready for merging, with all requested changes in place since many months ago. Auto-closing such PRs will offend the contributors who would see their effort go down the drain only because no one in the LEDE/OpenWrt community had the time to review and merge their PRs. Github has "labels" for PRs, so I think such timeout should look for "needs changes" label or something like that. See this PR https://github.com/openwrt/openwrt/pull/655 (on the right, the red label) -Alberto Problem is, the "Change requested" label does not necessarily mean that the requested changes have not been implemented by the contributors. At least for me, the problem is that GitHub doesn't notify when the PR is changed (for example author force pushes some changes). I usually ask authors to ping me (using @username) in a separate comment in PR when the requested changes are made. There have been cases where a PRs gets labelled with "Change requested", then the contributor makes all changes as requested, and then nothing happens for many months because no one among members with write privileges has the time to review and merge the PR. Agree, it happens. Maybe the script John is working on could help here reminding reviewer/s. -- Cheers, Piotr ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] Enable DCO check on Github OpenWrt organisation
Hi Etienne, On 18.01.2018 22:59, Etienne Champetier wrote: Hi All, Could someone enable this https://github.com/integration/dco on the whole OpenWrt github org? (or at least on the packages repo) I think that packages repository already uses Travis CI which checks for such thing like a missing SoB, have a look at [1]. It seems that for openwrt/openwrt drone.io CI is used (I don't know who manages that) but only to check if build fails or not. Maybe we could extend it and include scripts/checkpatch.pl before build? That would save reviewers time pointing out formal issues, not only the missing SoB. [1] https://travis-ci.org/openwrt/packages/builds/329031205 -- Cheers, Piotr ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v3 1/2] ar71xx: uniform GL iNet products mach name
Hello Kyson,
Thank you for your patch, I merged it into my staging tree:
https://git.openwrt.org/openwrt/staging/pepe2k.git
--
Cheers,
Piotr
On 19.01.2018 09:36, Kyson Lok wrote:
The mach name of GL AR150 and GL AR300 is inconsistent
with other products.
Signed-off-by: Kyson Lok
---
target/linux/ar71xx/base-files/lib/ar71xx.sh | 4 ++--
target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar150.c | 2 +-
target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar300.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index b664249..7d414ed 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -664,10 +664,10 @@ ar71xx_board_detect() {
*"FRITZ!WLAN Repeater 300E")
name="fritz300e"
;;
- *"GL AR150")
+ *"GL-AR150")
name="gl-ar150"
;;
- *"GL AR300")
+ *"GL-AR300")
name="gl-ar300"
;;
*"GL-AR300M")
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar150.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar150.c
index df52784..9824bb8 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar150.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar150.c
@@ -122,4 +122,4 @@ static void __init gl_ar150_setup(void)
ath79_register_wmac(art + GL_AR150_CALDATA_OFFSET, art +
GL_AR150_WMAC_MAC_OFFSET);
}
-MIPS_MACHINE(ATH79_MACH_GL_AR150, "GL-AR150", "GL AR150",gl_ar150_setup);
+MIPS_MACHINE(ATH79_MACH_GL_AR150, "GL-AR150", "GL-AR150",gl_ar150_setup);
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar300.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar300.c
index 6f01b9e..ae96635 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar300.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar300.c
@@ -100,4 +100,4 @@ static void __init gl_ar300_setup(void)
ath79_register_wmac(art + GL_AR300_CALDATA_OFFSET, art +
GL_AR300_WMAC_MAC_OFFSET);
}
-MIPS_MACHINE(ATH79_MACH_GL_AR300, "GL-AR300", "GL AR300",gl_ar300_setup);
+MIPS_MACHINE(ATH79_MACH_GL_AR300, "GL-AR300", "GL-AR300",gl_ar300_setup);
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v3 2/2] ar71xx: include vendor name for GL iNet products
Hello Kyson, Thank you for your patch, I merged it into my staging tree: https://git.openwrt.org/openwrt/staging/pepe2k.git -- Cheers, Piotr On 19.01.2018 09:36, Kyson Lok wrote: This patch include GL.iNet vendor name in the machine name for GL.iNet vendor products. Signed-off-by: Kyson Lok --- target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar150.c | 2 +- target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar300.c | 2 +- target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar300m.c | 3 +-- target/linux/ar71xx/files/arch/mips/ath79/mach-gl-mifi.c | 2 +- 4 files changed, 4 insertions(+), 5 deletions(-) diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar150.c b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar150.c index 9824bb8..9febc7a 100644 --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar150.c +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar150.c @@ -122,4 +122,4 @@ static void __init gl_ar150_setup(void) ath79_register_wmac(art + GL_AR150_CALDATA_OFFSET, art + GL_AR150_WMAC_MAC_OFFSET); } -MIPS_MACHINE(ATH79_MACH_GL_AR150, "GL-AR150", "GL-AR150",gl_ar150_setup); +MIPS_MACHINE(ATH79_MACH_GL_AR150, "GL-AR150", "GL.iNet GL-AR150", gl_ar150_setup); diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar300.c b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar300.c index ae96635..1708d69 100644 --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar300.c +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar300.c @@ -100,4 +100,4 @@ static void __init gl_ar300_setup(void) ath79_register_wmac(art + GL_AR300_CALDATA_OFFSET, art + GL_AR300_WMAC_MAC_OFFSET); } -MIPS_MACHINE(ATH79_MACH_GL_AR300, "GL-AR300", "GL-AR300",gl_ar300_setup); +MIPS_MACHINE(ATH79_MACH_GL_AR300, "GL-AR300", "GL.iNet GL-AR300", gl_ar300_setup); diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar300m.c b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar300m.c index c4e537f..2a2d270 100644 --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar300m.c +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-ar300m.c @@ -162,5 +162,4 @@ static void __init gl_ar300m_setup(void) ath79_register_pci(); } -MIPS_MACHINE(ATH79_MACH_GL_AR300M, "GL-AR300M", "GL-AR300M", -gl_ar300m_setup); +MIPS_MACHINE(ATH79_MACH_GL_AR300M, "GL-AR300M", "GL.iNet GL-AR300M", gl_ar300m_setup); diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-mifi.c b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-mifi.c index 412c562..9f8ca2f 100644 --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-mifi.c +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-gl-mifi.c @@ -111,4 +111,4 @@ static void __init gl_mifi_setup(void) ath79_register_wmac(art + GL_MIFI_CALDATA_OFFSET, art + GL_MIFI_WMAC_MAC_OFFSET); } -MIPS_MACHINE(ATH79_MACH_GL_MIFI, "GL-MIFI", "GL-MIFI",gl_mifi_setup); +MIPS_MACHINE(ATH79_MACH_GL_MIFI, "GL-MIFI", "GL.iNet GL-MIFI", gl_mifi_setup); ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] Enable DCO check on Github OpenWrt organisation
Hi Etienne, On 19.01.2018 13:09, Etienne Champetier wrote: Hi Piotr, 2018-01-19 9:54 GMT+01:00 Piotr Dymacz : Hi Etienne, On 18.01.2018 22:59, Etienne Champetier wrote: Hi All, Could someone enable this https://github.com/integration/dco on the whole OpenWrt github org? (or at least on the packages repo) I think that packages repository already uses Travis CI which checks for such thing like a missing SoB, have a look at [1]. I'm well aware that the package repo uses Travis, as I'm the one fixing it from time to time ;) Sorry, I don't follow closely packages repository ;) It seems that for openwrt/openwrt drone.io CI is used (I don't know who manages that) but only to check if build fails or not. Maybe we could extend it and include scripts/checkpatch.pl before build? That would save reviewers time pointing out formal issues, not only the missing SoB. The interest of using DCO is to have an instant response directly into the PR (you don't have to jump into Travis logs) Makes sense, agree. We can also make it mandatory (show "required" on the fail test line) Also this is a good minimum check to have on ALL repo There are many ways to do it, enabling DCO is a 2 minutes job (if someone want to do a similar script and host it that's totally fine with me) I'm OK with DCO enabled for all repos. We should probably give some time others to comment and if there are no objections, we can enable it. -- Cheers, Piotr ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] ar71xx: add support for Gainstrong Oolite V5.2
Hi Daniel,
Few minor comments inline, below.
On 14.02.2018 02:01, Daniel Golle wrote:
The Oolite V5.2 is a dual-radio system-on-a-module.
Specs:
- QCA9531 @ 550MHz with integrated 2T2R 802.11bgn
- 64 MB DDR2 RAM
- 16 MB SPI NOR Flash (W25Q128FV)
- 1+4x 10/100 Mbps Ethernet
- QCA9887 1T1R 802.11ac
Signed-off-by: Daniel Golle
---
.../linux/ar71xx/base-files/etc/board.d/02_network | 1 +
.../etc/hotplug.d/firmware/11-ath10k-caldata | 1 +
target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 ++
.../ar71xx/base-files/lib/upgrade/platform.sh | 1 +
target/linux/ar71xx/config-4.4 | 1 +
target/linux/ar71xx/config-4.9 | 1 +
.../ar71xx/files/arch/mips/ath79/Kconfig.openwrt | 11 ++
target/linux/ar71xx/files/arch/mips/ath79/Makefile | 1 +
.../ar71xx/files/arch/mips/ath79/mach-gs-oolite.c | 41 ++
.../linux/ar71xx/files/arch/mips/ath79/machtypes.h | 1 +
target/linux/ar71xx/generic/config-default | 1 +
target/linux/ar71xx/image/generic.mk | 10 ++
12 files changed, 73 insertions(+)
diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network
b/target/linux/ar71xx/base-files/etc/board.d/02_network
index f131b3b633..002ad977b7 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -322,6 +322,7 @@ ar71xx_setup_interfaces()
;;
dir-615-i1|\
omy-g1|\
+ oolite-v5.2|\
If you reorder ath79_register_eth() calls in your mach file, you could
use a more common lan/wan mapping: eth0/eth1.
With your current setup, failsafe probably doesn't work (eth0 is the
default interface in failsafe mode).
r6100|\
smart-300|\
tl-wdr6500-v2|\
diff --git
a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 8284550e92..f7bffe8232 100644
--- a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -67,6 +67,7 @@ case "$FIRMWARE" in
cf-e380ac-v1|\
cf-e380ac-v2|\
dlan-pro-1200-ac|\
+ oolite-v5.2|\
sr3200|\
xd3200)
ath10kcal_extract "art" 20480 2116
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index a255b83802..0dfb278792 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -850,6 +850,9 @@ ar71xx_board_detect() {
*"Oolite V1.0")
name="oolite"
;;
+ *"Oolite V5.2")
+ name="oolite-v5.2"
+ ;;
*"PB42")
name="pb42"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 8f56d1a8f6..23e45e941f 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -391,6 +391,7 @@ platform_check_image() {
omy-x1|\
onion-omega|\
oolite|\
+ oolite-v5.2|\
re355|\
re450|\
rut900|\
diff --git a/target/linux/ar71xx/config-4.4 b/target/linux/ar71xx/config-4.4
index 068b83ce8a..d2c4472cd3 100644
--- a/target/linux/ar71xx/config-4.4
+++ b/target/linux/ar71xx/config-4.4
@@ -123,6 +123,7 @@ CONFIG_ATH79=y
# CONFIG_ATH79_MACH_GL_USB150 is not set
# CONFIG_ATH79_MACH_GS_MINIBOX_V1 is not set
# CONFIG_ATH79_MACH_GS_OOLITE is not set
+# CONFIG_ATH79_MACH_GS_OOLITE_V5_2 is not set
# CONFIG_ATH79_MACH_HIVEAP_121 is not set
# CONFIG_ATH79_MACH_HIWIFI_HC6361 is not set
# CONFIG_ATH79_MACH_HORNET_UB is not set
diff --git a/target/linux/ar71xx/config-4.9 b/target/linux/ar71xx/config-4.9
index e495f6b4c2..dd5c63dcd5 100644
--- a/target/linux/ar71xx/config-4.9
+++ b/target/linux/ar71xx/config-4.9
@@ -121,6 +121,7 @@ CONFIG_ATH79=y
# CONFIG_ATH79_MACH_GL_USB150 is not set
# CONFIG_ATH79_MACH_GS_MINIBOX_V1 is not set
# CONFIG_ATH79_MACH_GS_OOLITE is not set
+# CONFIG_ATH79_MACH_GS_OOLITE_V5_2 is not set
# CONFIG_ATH79_MACH_HIVEAP_121 is not set
# CONFIG_ATH79_MACH_HIWIFI_HC6361 is not set
# CONFIG_ATH79_MACH_HORNET_UB is not set
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
index 248bffb1f5..e7fc8db78c 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
+++ b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
@@ -878,6 +878,17 @@ config ATH79_MACH_GS_OOLITE
select ATH79_DEV_USB
select ATH79_DEV_WMAC
+config ATH79_MACH_GS_OOLITE_V5_2
+ bool "GS Oolite V5.2 support"
+ select SOC_QCA953X
+ select ATH79_DEV_AP9X_PCI if PCI
+ select A
[LEDE-DEV] [PATCH] ar71xx: rework chipidea controller support, add QCA9531
Rework (again) platform support for dual-role chipidea USB controller:
- include support for QCA9531
- use correct EHCI block size
- drop ar933x_usb_setup_ctrl_config() function
- simplify code after previous "register chipidea only in device mode"
change (fa22714181)
Reworked patch was tested on devices with below QCA WiSOCs (signal/GPIO
name with required bootstrap state for USB bus 0 in device mode):
- AR9331 (GPIO13 pull-down)
- AR9342 (RGMII_TXD1/ETXD1 pull-up)
- AR9344 (GPIO20 pull-up)
- QCA9531 (GPIO13 pull-up)
- QCA9558 (GPIO13 pull-up)
The only way to select device mode for bus 0 is to change SOC bootstrap
configuration which is sampled only once, at hard reset. Likely, other
models, like QCA9556 or AR9341, should also support dual-role USB mode
but they were not tested.
Signed-off-by: Piotr Dymacz
---
.../920-usb-chipidea-AR933x-platform-support.patch | 70 ++
1 file changed, 31 insertions(+), 39 deletions(-)
diff --git
a/target/linux/ar71xx/patches-4.9/920-usb-chipidea-AR933x-platform-support.patch
b/target/linux/ar71xx/patches-4.9/920-usb-chipidea-AR933x-platform-support.patch
index fc6a088932..b0e69af9c1 100644
---
a/target/linux/ar71xx/patches-4.9/920-usb-chipidea-AR933x-platform-support.patch
+++
b/target/linux/ar71xx/patches-4.9/920-usb-chipidea-AR933x-platform-support.patch
@@ -29,48 +29,35 @@
#include
#include
-@@ -170,6 +173,64 @@ static void __init ar913x_usb_setup(void
+@@ -170,6 +173,44 @@ static void __init ar913x_usb_setup(void
&ath79_ehci_pdata_v2, sizeof(ath79_ehci_pdata_v2));
}
-+static void __init ar933x_usb_setup_ctrl_config(void)
-+{
-+ void __iomem *usb_ctrl_base, *usb_config_reg;
-+ u32 usb_config;
-+
-+ usb_ctrl_base = ioremap(AR71XX_USB_CTRL_BASE, AR71XX_USB_CTRL_SIZE);
-+ usb_config_reg = usb_ctrl_base + AR71XX_USB_CTRL_REG_CONFIG;
-+ usb_config = __raw_readl(usb_config_reg);
-+ usb_config &= ~AR933X_USB_CONFIG_HOST_ONLY;
-+ __raw_writel(usb_config, usb_config_reg);
-+ iounmap(usb_ctrl_base);
-+}
-+
-+static void __init ar9xxx_ci_usb_setup(int irq)
++static void __init ar9xxx_ci_usb_setup(int bus_id, int irq)
+{
+ struct ci_hdrc_platform_data ci_pdata;
-+ enum usb_dr_mode dr_mode;
+ bool host_mode = true;
+
+ if (soc_is_ar933x())
+ host_mode = ath79_reset_rr(AR933X_RESET_REG_BOOTSTRAP) &
+ AR933X_BOOTSTRAP_USB_MODE_HOST;
-+ else if (soc_is_ar934x() || soc_is_qca955x())
++ else
+ host_mode = !(ath79_reset_rr(AR934X_RESET_REG_BOOTSTRAP) &
+AR934X_BOOTSTRAP_USB_MODE_DEVICE);
+
+ if (host_mode) {
-+ dr_mode = USB_DR_MODE_HOST;
-+ } else {
-+ dr_mode = USB_DR_MODE_PERIPHERAL;
-+ if (soc_is_ar933x())
-+ ar933x_usb_setup_ctrl_config();
++ ath79_usb_register("ehci-platform", bus_id,
++ AR934X_EHCI_BASE, AR934X_EHCI_SIZE,
++ irq, &ath79_ehci_pdata_v2,
++ sizeof(ath79_ehci_pdata_v2));
++
++ return;
+ }
+
+ memset(&ci_pdata, 0, sizeof(ci_pdata));
+ ci_pdata.name = "ci_hdrc_ar9xxx";
+ ci_pdata.capoffset = DEF_CAPOFFSET;
-+ ci_pdata.dr_mode = dr_mode;
++ ci_pdata.dr_mode = USB_DR_MODE_PERIPHERAL;
+ ci_pdata.flags = CI_HDRC_DUAL_ROLE_NOT_OTG | CI_HDRC_DP_ALWAYS_PULLUP;
+ ci_pdata.vbus_extcon.edev = ERR_PTR(-ENODEV);
+ ci_pdata.id_extcon.edev = ERR_PTR(-ENODEV);
@@ -79,22 +66,15 @@
+ platform_device_register_simple("usb_phy_generic",
+ PLATFORM_DEVID_AUTO, NULL, 0);
+
-+ if (!host_mode)
-+ ath79_usb_register("ci_hdrc", -1,
-+ AR933X_EHCI_BASE, AR933X_EHCI_SIZE,
-+ irq, &ci_pdata, sizeof(ci_pdata));
-+ else
-+ ath79_usb_register("ehci-platform", -1,
-+ AR933X_EHCI_BASE, AR933X_EHCI_SIZE,
-+ irq, &ath79_ehci_pdata_v2,
-+ sizeof(ath79_ehci_pdata_v2));
-+
++ ath79_usb_register("ci_hdrc", -1,
++ AR934X_EHCI_BASE, AR934X_EHCI_SIZE,
++ irq, &ci_pdata, sizeof(ci_pdata));
+}
+
static void __init ar933x_usb_setup(void)
{
ath79_device_reset_set(AR933X_RESET_USBSUS_OVERRIDE);
-@@ -181,10 +242,7 @@ static void __init ar933x_usb_setup(void
+@@ -181,10 +222,7 @@ static void __init ar933x_usb_setup(void
ath79_device_reset_clear(AR933X_RESET_USB_PHY);
mdelay(10);
@@ -102,11 +82,11 @@
- AR933X_EHCI_BASE, AR933X_EHCI_SIZE,
- ATH79_CPU_IRQ(3),
Re: [LEDE-DEV] [PATCH] Add support for Comfast E380AC v1 and v2
Hello Gareth,
Please, take a look how I made support for other Comfast devices
(QCA953x based) [1].
I will rebase, update and send PR when I'm back from my holidays.
Maybe we could keep everything in one mach-*.c file as there are some
common parts, ex. timer for external watchdog.
[1]
https://github.com/pepe2k/lede-project-source/commit/9bb9b210ad483611304a2f6bcba418866b550e17
Cheers,
Piotr
2016-10-17 19:14 GMT+09:00 Gareth Parker :
> The Comfast E380AC is a single port PoE Dual Band AP.
>
> There are two versions which are only identifiable through the web
> administration interface, v1 has 128mb ram and a uboot size of 128k, v2 has
> 256mb ram and a uboot size of 256k, the remaining hardware and PCB markings
> are the same.
>
> The factory firmware is built on openwrt and will accept a sysupgrade file,
> this patch produces two sysupgrade files for both versions.
>
> Signed-off-by: Gareth Parker
> ---
> target/linux/ar71xx/base-files/etc/diag.sh |4 +
> .../etc/hotplug.d/firmware/11-ath10k-caldata |5 +
> target/linux/ar71xx/base-files/lib/ar71xx.sh |6 +
> .../ar71xx/base-files/lib/upgrade/platform.sh | 12 ++
> target/linux/ar71xx/config-4.4 |1 +
> .../ar71xx/files/arch/mips/ath79/Kconfig.openwrt | 10 +
> target/linux/ar71xx/files/arch/mips/ath79/Makefile |1 +
> .../ar71xx/files/arch/mips/ath79/mach-cf-e380ac.c | 197
>
> .../linux/ar71xx/files/arch/mips/ath79/machtypes.h |2 +
> target/linux/ar71xx/image/generic.mk | 18 ++
> 10 files changed, 256 insertions(+)
> create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-cf-e380ac.c
>
> diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
> b/target/linux/ar71xx/base-files/etc/diag.sh
> index d6e257d..c8e6b48 100644
> --- a/target/linux/ar71xx/base-files/etc/diag.sh
> +++ b/target/linux/ar71xx/base-files/etc/diag.sh
> @@ -82,6 +82,10 @@ get_status_led() {
> cf-e316n-v2)
> status_led="$board:blue:wan"
> ;;
> + cf-e380ac-v1|\
> + cf-e380ac-v2)
> + status_led="cfe380ac:green"
> + ;;
> cpe510)
> status_led="tp-link:green:link4"
> ;;
> diff --git
> a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> index 0e93feb..7598a83 100644
> --- a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> +++ b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
> @@ -47,6 +47,11 @@ board=$(ar71xx_board_name)
> case "$FIRMWARE" in
> "ath10k/cal-pci-:00:00.0.bin")
> case $board in
> + cf-e380ac-v1 | \
> + cf-e380ac-v2)
> + ath10kcal_extract "art" 20480 2116
> + ath10kcal_patch_mac $(macaddr_add $(cat
> /sys/class/net/eth0/address) +3)
> + ;;
> dlan-pro-1200-ac)
> ath10kcal_extract "art" 20480 2116
> ;;
> diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
> b/target/linux/ar71xx/base-files/lib/ar71xx.sh
> index dae6fb2..fb017f5 100755
> --- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
> +++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
> @@ -488,6 +488,12 @@ ar71xx_board_detect() {
> *"COMFAST CF-E316N v2")
> name="cf-e316n-v2"
> ;;
> + *"COMFAST CF-E380AC-V1")
> + name="cf-e380ac-v1"
> + ;;
> + *"COMFAST CF-E380AC-V2")
> + name="cf-e380ac-v2"
> + ;;
> *"CPE210/220")
> name="cpe210"
> tplink_pharos_board_detect
> diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> index 559f97d..2463587 100755
> --- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> @@ -495,6 +495,16 @@ platform_check_image() {
> alfa_check_image "$1" && return 0
> return 1
> ;;
> +
> + cf-e380ac-v1|\
> + cf-e380ac-v2)
> + [ "$magic_long" != "27051956" ] && {
> + echo "Invalid image type."
> + return 1
> + }
> + return 0
> + ;;
> +
> wndr3700|\
> wnr1000-v2|\
> wnr2000-v3|\
> @@ -597,6 +607,8 @@ platform_do_upgrade() {
> om5p)
> platform_do_upgrade_openmesh "$ARGV"
> ;;
> + cf-e380ac-v1|\
> + cf-e380ac-v2|\
> uap-pro|\
> unifi-outdoor-plus)
> MTD_CONFIG_ARGS="-s 0x18"
> diff --git a/target/linux/ar71xx/config-4.4 b/target/linux/ar71xx/config-4.4
> index 7aeac89..9232c4c 100644
> --- a/target/linux/ar71xx/config-4.4
> +++ b/target/linu
Re: [LEDE-DEV] [PATCH] Add support for Comfast E380AC v1 and v2
Hello Gareth,
I will be back in ~2 weeks, there is no need to wait for me. You can
push your changes and I will update/rebase my patches later and
combine your code into one, common mach-*.c file.
Greetings from Japan!
Piotr
2016-10-19 18:56 GMT+09:00 Gareth Parker :
> Hi Piotr
> Thanks for your input, I have fixed up all the issues in my patch and was
> about to re-submit it, however having seen your email below what would be
> the best approach from here?
>
> I can submit my patch as is if you want? Then you can move all comfast
> devices into one mach file later?
>
> I also have a cf-e355ac which I'm going to be submitting a patch for, plus
> my company is also going to be importing more comfast gear soon (outdoor
> high power ap's) and hence will be adding support for this also.
>
> Cheers,
>
> Gareth
>
> -Original Message-
> From: Lede-dev [mailto:lede-dev-boun...@lists.infradead.org] On Behalf Of
> Piotr Dymacz
> Sent: Wednesday, 19 October 2016 4:32 p.m.
> To: Gareth Parker
> Cc: LEDE Development List; gar...@zappie.net.nz
> Subject: Re: [LEDE-DEV] [PATCH] Add support for Comfast E380AC v1 and v2
>
> Hello Gareth,
>
> Please, take a look how I made support for other Comfast devices (QCA953x
> based) [1].
>
> I will rebase, update and send PR when I'm back from my holidays.
> Maybe we could keep everything in one mach-*.c file as there are some common
> parts, ex. timer for external watchdog.
>
> [1]
> https://github.com/pepe2k/lede-project-source/commit/9bb9b210ad483611304a2f6
> bcba418866b550e17
>
> Cheers,
> Piotr
>
> 2016-10-17 19:14 GMT+09:00 Gareth Parker :
>> The Comfast E380AC is a single port PoE Dual Band AP.
>>
>> There are two versions which are only identifiable through the web
> administration interface, v1 has 128mb ram and a uboot size of 128k, v2 has
> 256mb ram and a uboot size of 256k, the remaining hardware and PCB markings
> are the same.
>>
>> The factory firmware is built on openwrt and will accept a sysupgrade
> file, this patch produces two sysupgrade files for both versions.
>>
>> Signed-off-by: Gareth Parker
>> ---
>> target/linux/ar71xx/base-files/etc/diag.sh |4 +
>> .../etc/hotplug.d/firmware/11-ath10k-caldata |5 +
>> target/linux/ar71xx/base-files/lib/ar71xx.sh |6 +
>> .../ar71xx/base-files/lib/upgrade/platform.sh | 12 ++
>> target/linux/ar71xx/config-4.4 |1 +
>> .../ar71xx/files/arch/mips/ath79/Kconfig.openwrt | 10 +
>> target/linux/ar71xx/files/arch/mips/ath79/Makefile |1 +
>> .../ar71xx/files/arch/mips/ath79/mach-cf-e380ac.c | 197
>
>> .../linux/ar71xx/files/arch/mips/ath79/machtypes.h |2 +
>> target/linux/ar71xx/image/generic.mk | 18 ++
>> 10 files changed, 256 insertions(+)
>> create mode 100644
>> target/linux/ar71xx/files/arch/mips/ath79/mach-cf-e380ac.c
>>
>> diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
>> b/target/linux/ar71xx/base-files/etc/diag.sh
>> index d6e257d..c8e6b48 100644
>> --- a/target/linux/ar71xx/base-files/etc/diag.sh
>> +++ b/target/linux/ar71xx/base-files/etc/diag.sh
>> @@ -82,6 +82,10 @@ get_status_led() {
>> cf-e316n-v2)
>> status_led="$board:blue:wan"
>> ;;
>> + cf-e380ac-v1|\
>> + cf-e380ac-v2)
>> + status_led="cfe380ac:green"
>> + ;;
>> cpe510)
>> status_led="tp-link:green:link4"
>> ;;
>> diff --git
>> a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-cald
>> ata
>> b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-cald
>> ata
>> index 0e93feb..7598a83 100644
>> ---
>> a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-cald
>> ata
>> +++ b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-
>> +++ caldata
>> @@ -47,6 +47,11 @@ board=$(ar71xx_board_name) case "$FIRMWARE" in
>> "ath10k/cal-pci-:00:00.0.bin")
>> case $board in
>> + cf-e380ac-v1 | \
>> + cf-e380ac-v2)
>> + ath10kcal_extract "art" 20480 2116
>> + ath10kcal_patch_mac $(macaddr_add $(cat
> /sys/class/net/eth0/address) +3)
>> + ;;
>> dlan-pro-1200-ac)
>> ath10kcal_extract "art" 20480 2116
>> ;;
>> diff --git a/target/linux/ar71xx/base-files/lib/ar7
Re: [LEDE-DEV] [PATCH v2] ramips: Add support for Sanlinking D240
Hi Kristian,
My two cents: the general convention for board name is to not include
the manufacturer name (Sanlinking here).
As you can see, (almost) all other boards follow this rule, so please
use "d240" instead of "sanlinking-d240" (also for dts filename).
Cheers,
Piotr
2017-02-03 9:54 GMT+01:00 Kristian Evensen :
> The Sanlinking Technologies D240
> (http://www.sanlinking.com/en/29-dual-4g-wifi-router.html) is basically the
> same
> device as the ZBT WE826, so adding support for it in LEDE is straight forward.
> The differences is that the D240 has two mini-PCIe slots (instead of one),
> blue
> LEDs and supports PoE.
>
> Wifi, USB, switch and both mini-PCIe slots are working. I have not been able
> to
> test the SD card reader on the device.
>
> v1->v2:
>
> * Misc. code cleanup (thanks Mathias Kresin)
>
> Signed-off-by: Kristian Evensen
>
> Cleanup
> ---
> target/linux/ramips/base-files/etc/board.d/01_leds | 4 +
> .../linux/ramips/base-files/etc/board.d/02_network | 1 +
> target/linux/ramips/base-files/etc/diag.sh | 1 +
> target/linux/ramips/base-files/lib/ramips.sh | 3 +
> .../ramips/base-files/lib/upgrade/platform.sh | 1 +
> target/linux/ramips/dts/SANLINKING-D240.dts| 120
> +
> target/linux/ramips/image/mt7620.mk| 8 ++
> 7 files changed, 138 insertions(+)
> create mode 100644 target/linux/ramips/dts/SANLINKING-D240.dts
>
> diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds
> b/target/linux/ramips/base-files/etc/board.d/01_leds
> index 545d6a4..409854f 100755
> --- a/target/linux/ramips/base-files/etc/board.d/01_leds
> +++ b/target/linux/ramips/base-files/etc/board.d/01_leds
> @@ -300,6 +300,10 @@ rt-n14u)
> set_wifi_led "$board:blue:air"
> set_usb_led "$board:blue:usb"
> ;;
> +sanlinking-d240)
> + set_wifi_led "$board:blue:wifi"
> + set_usb_led "$board:blue:usb"
> + ;;
> tew-714tru)
> set_usb_led "$board:red:usb"
> set_wifi_led "$board:green:wifi"
> 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 c001dfe..bf2edf0 100755
> --- a/target/linux/ramips/base-files/etc/board.d/02_network
> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
> @@ -92,6 +92,7 @@ ramips_setup_interfaces()
> pbr-m1|\
> psg1208|\
> psg1218|\
> + sanlinking-d240|\
> sap-g3200u3|\
> sk-wb8|\
> vr500|\
> diff --git a/target/linux/ramips/base-files/etc/diag.sh
> b/target/linux/ramips/base-files/etc/diag.sh
> index 5fb2213..b92d871 100644
> --- a/target/linux/ramips/base-files/etc/diag.sh
> +++ b/target/linux/ramips/base-files/etc/diag.sh
> @@ -115,6 +115,7 @@ get_status_led() {
> rt-n14u|\
> rt-n15|\
> rt-n56u|\
> + sanlinking-d240|\
> wl-330n|\
> wl-330n3g|\
> wli-tx4-ag300n|\
> diff --git a/target/linux/ramips/base-files/lib/ramips.sh
> b/target/linux/ramips/base-files/lib/ramips.sh
> index d9918cc..dc86a82 100755
> --- a/target/linux/ramips/base-files/lib/ramips.sh
> +++ b/target/linux/ramips/base-files/lib/ramips.sh
> @@ -442,6 +442,9 @@ ramips_board_detect() {
> *"SamKnows Whitebox 8")
> name="sk-wb8"
> ;;
> + *"SANLINKING-D240")
> + name="sanlinking-d240"
> + ;;
> *"SAP-G3200U3")
> name="sap-g3200u3"
> ;;
> diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh
> b/target/linux/ramips/base-files/lib/upgrade/platform.sh
> index d83e5c1..afc6014 100755
> --- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
> @@ -123,6 +123,7 @@ platform_check_image() {
> rt-n15|\
> rt-n56u|\
> rut5xx|\
> + sanlinking-d240|\
> sap-g3200u3|\
> sk-wb8|\
> sl-r7205|\
> diff --git a/target/linux/ramips/dts/SANLINKING-D240.dts
> b/target/linux/ramips/dts/SANLINKING-D240.dts
> new file mode 100644
> index 000..888f5aa
> --- /dev/null
> +++ b/target/linux/ramips/dts/SANLINKING-D240.dts
> @@ -0,0 +1,120 @@
> +/dts-v1/;
> +
> +#include "mt7620a.dtsi"
> +
> +#include
> +#include
> +
> +/ {
> + compatible = "sanlinking,sanlinking-d240", "ralink,mt7620a-soc";
> + model = "SANLINKING-D240";
> +
> + chosen {
> + bootargs = "console=ttyS0,115200";
> + };
> +
> + gpio-leds {
> + compatible = "gpio-leds";
> + power {
> + label = "sanlinking-d240:blue:power";
> + gpios = <&gpio1 14 GPIO_ACTIVE_HIGH>;
> + };
> + usb {
> + label = "sanlinking-d240:blue:usb";
> + gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>;
> + };
> + air {
> +
Re: [LEDE-DEV] [PATCH v2] ramips: Add support for Sanlinking D240
Hi Mathias, 2017-02-03 12:13 GMT+01:00 Mathias Kresin : > 2017-02-03 11:49 GMT+01:00 Kristian Evensen : >> Hi >> >> On Fri, Feb 3, 2017 at 11:02 AM, Piotr Dymacz wrote: >>> Hi Kristian, >>> >>> My two cents: the general convention for board name is to not include >>> the manufacturer name (Sanlinking here). >>> As you can see, (almost) all other boards follow this rule, so please >>> use "d240" instead of "sanlinking-d240" (also for dts filename). >>> >> >> I have no strong feelings for the manufacturer name, so I will remove >> it if that is what it takes to get the patch accepted. However, I can >> easily imagine a second manufacturer naming their device something >> something D240, so perhaps shortening the name to for example SL- is a >> good compromise between the two? > > I'm for using SL-D240. I share Kristians concerns about possible name > collisions in targets supporting a lot of boards like ar71xx and > ramips. Piotr, are fine with SL-D240? I don't think we should modify model names given by manufacturers unless it's really needed. Of course, in case of name conflict, we should take care of it, but only when it happens, not in advance and/or "just in case". And, as Larry already pointed out, SL-* prefix is used by Skyline products (I suppose SL-something is a real model name, and prefix wasn't added by us) which might be misleading for users when they look for ready image. We already have at least one name conflict under ar71xx target (ap96) and IMHO it wasn't solved properly. We have there board names "ap96" and "alfa-ap96" and ready images also use these names (actually, image for "Atheros AP96 Reference Board" is not generated as the kernel grew too much...). Question here is why only ALFA board got the prefix and Atheros one didn't? As this is a general problem and I'm sure it's going to grow in time, maybe we should start thinking about different approach for naming boards in system, dts files and image filenames? Including there also the manufacturer name would be one of possible options, but... I'm pretty sure this problem is also kernel related (upstream dts filenames convention). Cheers, Piotr ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v3] ramips: Add support for Sanlinking D240
Hi Kristian,
Thanks a lot for considering all our comments, it looks (almost) OK for me now.
There are just some minor, only cosmetic things (below, inline) which
I think still need to be fixed (yes, I'm kind of pedantic type).
Cheers,
Piotr
2017-02-04 13:56 GMT+01:00 Kristian Evensen :
[...]
> diff --git a/target/linux/ramips/dts/D240.dts
> b/target/linux/ramips/dts/D240.dts
> new file mode 100644
> index 000..051204a
> --- /dev/null
> +++ b/target/linux/ramips/dts/D240.dts
> @@ -0,0 +1,153 @@
> +/*
> + * BSD LICENSE
> + *
> + * Copyright(c) 2017 Kristian Evensen .
> + * All rights reserved.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + *
> + ** Redistributions of source code must retain the above copyright
> + * notice, this list of conditions and the following disclaimer.
> + ** Redistributions in binary form must reproduce the above copyright
> + * notice, this list of conditions and the following disclaimer in
> + * the documentation and/or other materials provided with the
> + * distribution.
> + ** Neither the name of Broadcom Corporation nor the names of its
> + * contributors may be used to endorse or promote products derived
> + * from this software without specific prior written permission.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
> + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
> + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +/dts-v1/;
> +
> +#include "mt7620a.dtsi"
> +
> +#include
> +#include
> +
> +/ {
> + compatible = "d240", "ralink,mt7620a-soc";
> + model = "D240";
You should put here full model name, including manufacturer name:
"Sanlinking Technologies D240".
> +
> + chosen {
> + bootargs = "console=ttyS0,115200";
> + };
> +
> + gpio-leds {
> + compatible = "gpio-leds";
New line here, please.
> + power {
> + label = "d240:blue:power";
> + gpios = <&gpio1 14 GPIO_ACTIVE_HIGH>;
> + };
New line here, please.
> + usb {
> + label = "d240:blue:usb";
> + gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>;
> + };
New line here, please.
> + air {
> + label = "d240:blue:wifi";
> + gpios = <&gpio3 0 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + gpio-keys-polled {
> + compatible = "gpio-keys-polled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + poll-interval = <20>;
New line here, please.
> + reset {
> + label = "reset";
> + gpios = <&gpio0 1 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> + };
> +};
> +
> +&gpio1 {
> + status = "okay";
> +};
> +
> +&gpio3 {
> + status = "okay";
> +};
> +
> +&spi0 {
> + status = "okay";
> +
> + en25q128@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <1000>;
> +
> + 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 {
> + label = "firmware";
> + reg = <0x5 0xfb>;
> + };
> + };
> +};
> +
> +&sdhci {
> + status = "okay";
> +};
> +
> +&ehci {
> + status = "okay";
> +};
> +
> +&ohci {
> + status = "okay";
> +};
> +
> +ðernet {
> + mtd-mac-ad
Re: [LEDE-DEV] ar71xx: tl-wr940n v4: invalid default switch config
Hi Daniel, Default network configuration under ar71xx needs adjustment/fix, because of [1]. [1] https://github.com/lede-project/source/commit/73d923ed6baabe3f8844f13216c50a6383a79a46 Cheers, Piotr 2017-02-06 22:29 GMT+01:00 daniel : > I just flashed a brand new tl-wr940n and the network wasn't configured > correctly on the first boot. > I needed to start it in recovery mode, otherwise LAN was not reachable. > > This is the generated invalid default config: > --- > ... > config interface 'lan' > option type 'bridge' > option ifname 'eth1 eth1.1' > option proto 'static' > option ipaddr '192.168.1.1' > option netmask '255.255.255.0' > option ip6assign '60' > > config switch > option name 'switch0' > option reset '1' > option enable_vlan '1' > > config switch_vlan > option device 'switch0' > option vlan '1' > option ports '0 1 2 3 4t' > > ... > --- > > I changed it to this one an now LAN + WAN is working properly. > --- > ... > config interface 'lan' > option type 'bridge' > option ifname 'eth1' > option proto 'static' > option ipaddr '192.168.1.1' > option netmask '255.255.255.0' > option ip6assign '60' > > config switch > option name 'switch0' > option reset '1' > option enable_vlan '1' > > config switch_vlan > option device 'switch0' > option vlan '1' > option ports '0 1 2 3 4' > ... > --- > > > Somebody here has the same router and can verify this ? > > -- > Regards > > Daniel Danzberger > embeDD GmbH, Breitenweg 10, CH-6370 Stans > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Is there a Image for TP-Link TL-WA854RE (WiFi Range Extender) ?
Hello, 2017-02-19 11:41 GMT+01:00 Daniel Golle : [...] >> Maybe a similar one that does what the "force enable wifi" script did >> would do the trick? > > Well, it's not as simple as that. We need to generate a config for > hostapd which matches the wifi hardware in terms of capabilities and > band and launch it and bring up the interface (configure IP address and > stuff) once hostapd comes up... possible, but quite a lot of work... If we assume that the problem is only inside wrong configuration applied to the device, reverting it back to the defaults (I assume here that default config for devices without Ethernet interface means also that the Wi-Fi is enabled by default) should be enough to bring back device to life. For devices without Ethernet/serial access, with our current approach, button (if there is any at all...) is the only interface left between the user and the system. What if we make use of it inside running failsafe mode and allow to initiate "firstboot"/"factory reset" based on button state, like we already do inside the "regular" system mode [1]? Of course, for devices without Ethernet interface, serial access and button... Wi-Fi inside failsafe mode would be the only way. Dennis, please take a look also here, where support for TL-WA854RE v2 was discussed: [2]. There was also a discussion about buttons which have more than one function assigned in vendor's firmware: [3]. [1] https://github.com/lede-project/source/blob/master/package/base-files/files/etc/rc.button/reset#L23 [2] https://github.com/lede-project/source/pull/808#issuecomment-279686189 [3] https://github.com/lede-project/source/pull/812#issuecomment-279342644 --- Cheers, Piotr ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Is there a Image for TP-Link TL-WA854RE (WiFi Range Extender) ?
Hi Mathias, 2017-02-19 13:34 GMT+01:00 Mathias Kresin : > 19.02.2017 13:10, Alberto Bursi: >> >> After Mathias's commit (as noted by other mails above) the devices we >> are talking about have wifi disabled by default but you can enable it >> with the wps button. >> >> https://github.com/lede-project/source/commit/bcfbeae79f799cf1087d692e4869589eb20d2080 >> >> Imho makes no sense as in most cases you will have to configure them >> anyway to be of any use (you can't just place them in a network with >> default config as they lack a ethernet port), so this "wifi off by >> default" and "remapping wps button to rfkill" imho is only an annoyance >> and removal of a potentially useful button that could be used for other >> things (enabling/disabling something else with scripts after user setup). > > > I'm still the opinion that bringing up an unencrypted wireless without user > interaction is really bad idea. Fully agree. Topic about having the Wi-Fi enabled by default is appearing from time to time, whenever someone is asking about support for device without an Ethernet interface. I don't think there is any good/secure enough approach which everybody would agree to implement by default in LEDE (but I might be wrong here). > The commit fixed the following problem: A user flashes one of the mentioned > devices and is not aware that the flash is finished or (s)he get distracted > in between. During this time period anyone can connect to the AP and can do > harmful things. [...] This is more like offtopic, but there is another one problem with similar devices. Lets forget now about "Wi-Fi enabled or not enabled by default" issue and assume we have a device which: - doesn't have Ethernet interface - serial access is not possible or very difficult to get - has _only one button_, configured as rfkill (because there must be some way to enable Wi-Fi after the flash) - is or could be supported in LEDE What will happen if the user breaks wireless configuration (it happens, I know it from experience) in this kind of device? Maybe, just by an accident, (s)he configured channel "17" instead of "7", saved changes, restarted Wi-Fi and... ended up with a nice paperweight. In this kind of situation, the "rfkill" button is useless (wireless configuration is broken, Wi-Fi can't be started). Failsafe mode can be enabled but is not accessible. AFAIK, there is no way to perform "firstboot"/"factory reset" in this situation. Of course, this is more like an extreme case (no Ethernet, no serial access, only one button), but IMHO it shows that if we want to support devices without Ethernet interface, we should make failsafe mode working for them. --- Cheers, Piotr ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] ar71xx: fix vlan settings for some boards
Hello, 2017-02-20 13:11 GMT+01:00 Conor O'Gorman : > On 18/02/17 14:32, Weijie Gao wrote: >> >> For AR71XX devices, GMAC1 always connects port 0 of the built-in switch, >> as the CPU port. >> >> This patch sets correct vlan for some devices with wrong settings: >> a) mark port 0 as CPU port, tagged >> b) reverse port order, marking these ports untagged >> > This change affects all these boards: > dir-615-i1|\ > omy-g1|\ > r6100|\ > smart-300|\ > tl-mr3420-v2|\ > tl-wdr6500-v2|\ > tl-wr841n-v8|\ > tl-wr940n-v4|\ > tl-wr941nd-v5|\ > tl-wr941nd-v6|\ > wnr1000-v2|\ > wnr2000-v4|\ > wnr2200|\ > wnr612-v2|\ > wpn824n) > > Which ones have you tested? At least for TL-WR841N v8 and TL-MR3420 v2 switch port mapping should be: "0@eth1" "1:lan:4" "2:lan:1" "3:lan:2" "4:lan:3" --- Cheers, Piotr ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] ar71xx: Need advice on parsing specific board config data on TP-Link TL-WR942N
Hello Sergey, 2017-02-21 0:00 GMT+01:00 Sergey Studzinski : > I'm currently working on LEDE port for TP-Link TL-WR942N v1 N450 router. > Hardware is mostly like Archer C59 QCA9561 platform but no 5GHz ac > radio and two USB2.0 ports. > Most work is already done against 17.01-rc2 and there is working > factory and sysupgrade images. Please, base your work on master branch. > Special thanks to Henryk Heisig and Felix Fietkau for their work! > Pecularities are found with MAC and some other specific board config > data which are not stored on first > mtd0(u-boot) partition like on Archers but right after rootfs > partition in a slightly different format (ASCII instead > of binary). Due this router starts with random MACs now. Just checking, have you tried to look for MAC in binary format in whole flash dump? [...] > root@LEDE:~# hexdump -C /dev/mtd4 > 00 00 00 16 00 00 00 00 4d 41 43 3a 38 34 2d 31 |MAC:84-1| > 0010 36 2d 12 34 2d 56 78 2d 9a bc 2d de f0 0a ff ff |6-F9-12-34-56...| TP-Link surprises me with every new device... [...] > Is there already special parser for this data somewhere in LEDE tree > or should we write new one? We have a shell function mtd_get_mac_ascii() in [1] and some boards under ar71xx target utilize it [2]. But I'm sure it won't work with such format - equal sign as separator is hardcoded there. Maybe we can extend it, add another one parameter with separator and keep it as "=" by default, for backward compatibility. You would also need to take a look at macaddr_canonicalize() function and check if it can work with this MAC format. > Or can we move this data on the second mtd0 sector on the first boot > and have it mostly like and > compatible with Archer C59/c60 code? BTW factory u-boot fits on first > 64kbytes and second 64K > sector is completely 0xFF. [...] IMHO, overwriting any kind of factory data in flash should be at the very end of list with possible solutions/workarounds, especially if we are talking here about second sector of flash, just after the U-Boot image. As I can see, "fs-boot" partition in factory firmware for this device is 128 KB size and I'm pretty sure not without a reason. I can imagine someday TP-Link will release update for this device with U-Boot image bigger than 64 KB and from that point our image will start breaking user's devices. [1] https://github.com/lede-project/source/blob/master/package/base-files/files/lib/functions/system.sh#L11 [2] https://github.com/lede-project/source/blob/master/target/linux/ar71xx/base-files/etc/board.d/02_network#L483 --- Cheers, Piotr ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] multi-function buttons
Hello, 2017-02-20 9:11 GMT+01:00 Mathias Kresin : > 19.02.2017 14:31, Piotr Dymacz: > > This is more like offtopic, but there is another one problem with > > similar devices. Lets forget now about "Wi-Fi enabled or not enabled > > by default" issue and assume we have a device which: > > - doesn't have Ethernet interface > > - serial access is not possible or very difficult to get > > - has _only one button_, configured as rfkill (because there must be > > some way to enable Wi-Fi after the flash) > > - is or could be supported in LEDE > > > > What will happen if the user breaks wireless configuration (it > > happens, I know it from experience) in this kind of device? Maybe, > > just by an accident, (s)he configured channel "17" instead of "7", > > saved changes, restarted Wi-Fi and... ended up with a nice > > paperweight. > > > > In this kind of situation, the "rfkill" button is useless (wireless > > configuration is broken, Wi-Fi can't be started). Failsafe mode can be > > enabled but is not accessible. AFAIK, there is no way to perform > > "firstboot"/"factory reset" in this situation. > > > > Of course, this is more like an extreme case (no Ethernet, no serial > > access, only one button), but IMHO it shows that if we want to support > > devices without Ethernet interface, we should make failsafe mode > > working for them. > > Hey Pepe, > > let me start a new thread regarding this issues. > > After I pushed > https://git.lede-project.org/bcfbeae79f799cf1087d692e4869589eb20d2080 we had > a discussion in IRC because what I've done in the commit wasn't that > correct. > > I've changed the linux,code of the buttons to RF_KILL/0xf7 to have this > enable WLAN functionality. But the with that change the send keycode doesn't > match any longer what is printed in the case. Means, a WPS button should > send the KEY_WPS_BUTTON keycode, a Wifi button should send KEY_WLAN, a Wifi > on/off button should send KEY_RFKILL and so on. I agree and I think we should keep this as a general rule: if the button/switch has a known _single_ function (e.g. it's printed on the device enclosure or we know how it works inside the vendor firmware) we should assign the same key code in LEDE. But, as in the message subject, what should we do with multi-function buttons regarding the key code (there is no way to use more than one key code in kernel)? Who should decide what key code will send button marked as "reset/wps", "wps/reset" or "wifi/reset" (in fact, these are existing examples)? Can we maybe agree about some general rule here too? Like, we prefer "reset" key code over "wps" and/or "rfkill" etc.? Or maybe we should leave this decision for the person who adds device support in code? > Jonas came up with the idea of interpreting the "wps" button press as > "rfkill" in userspace instead of changing the meaning of the buttons in the > dts file(s). John and Felix joined the discussion and we agreed that having > something configurable in userspace for interpreting the keycodes would be a > good idea. It can be extended to have timer based interpretations as well > (10sec press do A, 20sec press do B and so on). [...] I really like the idea of having something configurable. Personally I prefer to have it in system config as for LEDs and actually, that kind of "configurable user space code" was for long time already in the repository and got dropped not that long time ago [1]. I'm not convinced here only about static role assignments, like interpreting "wps" button press as "rfkill". What if the device has both buttons, what if it doesn't have the "reset" button? I'm worried that this could bring a lot of additional code needed to configure all of this in advance (board.d/uci-defaults). I was thinking about a slightly different and hopefully more universal approach: 1. Keep default functions for known buttons (same as now in /etc/rc.button/*). 2. Allow configuration from userspace, with support for timer based handlers. 3. Include "wildcard button" support with two interpretation set by default. For last point, we could define some general, timer based handlers for _any_ button (wildcard), e.g. (take below values only as examples): - 15-29s: rfkill - 30-...s: factory reset IMHO, above two functions are the most important from user perspective (there might be more of them). With this approach, we are solving two issues at once: 1. Wi-Fi can be enabled with any button (no need to change original key code) in devices with only Wi-Fi interface and at least one b
Re: [LEDE-DEV] [PATCH] ramips: Improve Sanlinking D240 config
Hi Kristian, 2017-03-02 11:55 GMT+01:00 Kristian Evensen : > * The left most mini-PCIe (USB) slot (the one attached to SIM2) can be > power-cycled by setting GPIO 0 to high/low. I have no strong opinion on the > name, but since the slot can be used for other things than modems I went for > usb2. [...] What about "power_mpcieX" (or something similar), where X is 1 or 2, depending on what is printed on the PCB (I wasn't able to find hi-res photo)? Take a look at other examples: grep -rn "gpio-export.*power" target/linux/ramips/dts/ target/linux/ramips/dts/HC5861.dts:43:gpio-export,name = "usbpower"; target/linux/ramips/dts/HC5861.dts:49:gpio-export,name = "sdpower"; target/linux/ramips/dts/PBR-M1.dts:78:gpio-export,name = "power_usb2"; target/linux/ramips/dts/PBR-M1.dts:84:gpio-export,name = "power_usb3"; target/linux/ramips/dts/PBR-M1.dts:90:gpio-export,name = "power_sata"; target/linux/ramips/dts/WNDR3700V5.dts:63:gpio-export,name = "usbpower"; target/linux/ramips/dts/TINY-AC.dts:49:gpio-export,name = "usbpower"; target/linux/ramips/dts/ArcherMR200.dts:92:gpio-export,name = "power_usb1"; target/linux/ramips/dts/HC5XXX.dtsi:28:gpio-export,name = "usbpower"; target/linux/ramips/dts/Newifi-D1.dts:56:gpio-export,name = "usb2power"; target/linux/ramips/dts/Newifi-D1.dts:62:gpio-export,name = "usb3power"; --- Cheers, Piotr ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] ramips: Improve Sanlinking D240 config
Hi Kristian, 2017-03-02 12:46 GMT+01:00 Kristian Evensen : > Hi, > > On Thu, Mar 2, 2017 at 12:39 PM, Piotr Dymacz wrote: >> What about "power_mpcieX" (or something similar), where X is 1 or 2, >> depending on what is printed on the PCB (I wasn't able to find hi-res >> photo)? > > Good idea and thanks for the pointer. There does not seem to be any > easy-to-find value or id printed on the PCB. However, in some material > I was sent from Sanlinking then the slot that can be power-cycled is > referred to as mini PCIe 2, so I will rename the slot to power_mpcie_2 > and send a v2. OK, I think you can also drop the comment with new gpio name. --- Cheers, Piotr ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] ugps: fix and improve init script
The ugps tool expects device path in last argument. If it's provided
before other options, they won't be processed at all.
Additionally, make it possible to use absolute path for gps character
device in related uci configuration.
Signed-off-by: Piotr Dymacz
---
package/utils/ugps/Makefile| 2 +-
package/utils/ugps/files/ugps.init | 8 ++--
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/package/utils/ugps/Makefile b/package/utils/ugps/Makefile
index 8744300..1dad863 100644
--- a/package/utils/ugps/Makefile
+++ b/package/utils/ugps/Makefile
@@ -8,7 +8,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=ugps
-PKG_RELEASE:=2
+PKG_RELEASE:=3
PKG_SOURCE_URL=$(LEDE_GIT)/project/ugps.git
PKG_SOURCE_PROTO:=git
diff --git a/package/utils/ugps/files/ugps.init
b/package/utils/ugps/files/ugps.init
index a7a88c2..157043c 100644
--- a/package/utils/ugps/files/ugps.init
+++ b/package/utils/ugps/files/ugps.init
@@ -14,11 +14,15 @@ start_service() {
local tty="$(uci get gps.@gps[-1].tty)"
local atime="$(uci get gps.@gps[-1].adjust_time)"
- [ -d "/sys/class/tty/$tty/" ] || return
+ [ -c "$tty" ] || {
+ tty="/dev/$tty"
+ [ -c "$tty" ] || return
+ }
procd_open_instance
- procd_set_param command "$PROG" "/dev/$tty"
+ procd_set_param command "$PROG"
[ "$atime" -eq 0 ] || procd_append_param command "-a"
+ procd_append_param command "$tty"
procd_set_param respawn
procd_close_instance
}
--
2.7.4
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [RFC] sysntpd: restore support for peer-less (standalone) mode
ntpd from Busybox supports peer-less (standalone) mode when it's started
with option -l and without any peer provided with option -p. In this
mode ntpd uses local time as reference and acts as stratum 1 server.
This mode can be used in isolated networks, where Internet access and/or
other NTP server/s are not available, but the device has some other way
of getting correct time, like e.g. GPS (ugps supports setting local time
by default).
Support for this mode was incorrectly disabled/removed in:
1527f96ca6e196fa17c96fdb3ae520158fa5943f
Signed-off-by: Piotr Dymacz
---
package/utils/busybox/files/sysntpd | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/utils/busybox/files/sysntpd
b/package/utils/busybox/files/sysntpd
index 98260be..e693e40 100755
--- a/package/utils/busybox/files/sysntpd
+++ b/package/utils/busybox/files/sysntpd
@@ -45,7 +45,7 @@ start_service() {
[ $use_dhcp = 1 ] && get_dhcp_ntp_servers "$dhcp_interface"
- [ -z "$server" ] && return
+ [ -z "$server" -a "$enable_server" = "0" ] && return
procd_open_instance
procd_set_param command "$PROG" -n -N
--
2.7.4
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v3 1/2] ar71xx: Add support for TP-Link MR6400
Hello Filip, On 05.03.2017 18:03, Filip Moc wrote: You can flash via u-boot tftp (serve factory image as /mr6400_tp_recovery.bin on 192.168.0.66/24, connect to any ethernet port and power on device while holding the reset button). [...] Is there any problem with upgrade under vendor gui on this device? Could you please also include more information about the device in commit message, like e.g. in [1], [2], [3]. There is no strict format or requirements (at least for now) how it should look like or what should be included, feel free to follow any of the examples below. These information could be then used by people working on the Wiki or just as reference. [1] https://github.com/lede-project/source/commit/f9278337cf4b9c699a41dfc1e4c448213be53e61 [2] https://github.com/lede-project/source/commit/edae3479e64e93275dce4a928ea70279282eef9d [3] https://github.com/lede-project/source/commit/9b35815f0f0e10125d144c82595bbccbc83d6812 -- Cheers, Piotr ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC] sysntpd: restore support for peer-less (standalone) mode
Hello Philip,
On 09.03.2017 00:40, Philip Prindeville wrote:
On Mar 6, 2017, at 3:20 PM, Piotr Dymacz wrote:
ntpd from Busybox supports peer-less (standalone) mode when it's
started with option -l and without any peer provided with option
-p. In this mode ntpd uses local time as reference and acts as
stratum 1 server.
This mode can be used in isolated networks, where Internet access
and/or other NTP server/s are not available, but the device has
some other way of getting correct time, like e.g. GPS (ugps
supports setting local time by default).
It’s not enough to have your clock set to the correct time initially:
you also need to assure the accuracy of your clock as time goes by,
i.e. ensuring that it’s not running too fast or head or too slow
behind.
Fully agree.
All clocks will have some inherent inaccuracy (due to thermal noise,
age, inconsistent power, etc). But comparing them regularly to other
clocks (i.e. peers or servers) allows you to understand how your own
clock is behaving and to adjust it (i.e. “discipline it”)
accordingly.
Agree.
I don’t think that lying about the accuracy of your clock by
declaring it stratum 1 is a good thing.
At least “fudge” the local clock and downgrade its stratum (however
busybox does that).
This is only an optional, already included "feature" of Busybox ntpd
applet (if it's built with support for server mode/-l option which is
true in our case), which was just disabled in our sysntpd init script,
probably by a mistake. Related Busybox change is here: [1].
By default, we use ntpd in client-only mode, with our upstream servers
listed with -p option.
As far as I can see in code [2], there is no way to change default
stratum value for for this "standalone" mode, but it was discussed on
Busybox mailing list: [3].
[1]
https://git.busybox.net/busybox/commit/?id=d678257c26e0993efc48ac4433d153e1e9dfc954
[2] https://git.busybox.net/busybox/tree/networking/ntpd.c?h=1_26_stable
[3] http://lists.busybox.net/pipermail/busybox/2010-October/073518.html
--
Cheers,
Piotr
Support for this mode was incorrectly disabled/removed in:
1527f96ca6e196fa17c96fdb3ae520158fa5943f
Signed-off-by: Piotr Dymacz ---
package/utils/busybox/files/sysntpd | 2 +- 1 file changed, 1
insertion(+), 1 deletion(-)
diff --git a/package/utils/busybox/files/sysntpd
b/package/utils/busybox/files/sysntpd index 98260be..e693e40
100755 --- a/package/utils/busybox/files/sysntpd +++
b/package/utils/busybox/files/sysntpd @@ -45,7 +45,7 @@
start_service() {
[ $use_dhcp = 1 ] && get_dhcp_ntp_servers "$dhcp_interface"
- [ -z "$server" ] && return + [ -z "$server" -a "$enable_server" =
"0" ] && return
procd_open_instance procd_set_param command "$PROG" -n -N -- 2.7.4
___ Lede-dev mailing
list Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] ramips: Improve Archer C20i support
Hello Paul,
Please use board name instead of manufacturer name for LEDs as it's
done in (almost, C50 should be fixed) all other DTS under ramips
target.
You should also provide full name in the SoB line.
---
Cheers,
Piotr
2016-07-28 12:10 GMT+02:00 :
> From: P.Wassi
>
> Improve / finalise TP-Link Archer C20i support.
>
> Signed-off-by: P.Wassi
> ---
> This patch adds proper LED and Button support and
> sets up a correct switch configuration.
> The only missing thing (which is likely to never be fixed) is
> the 5GHz phy (Mediatek MT7610) - due to the missing driver.
> Additional info: https://pwassi.privatedns.org/lede/archerc20i/
> The added define in kernel config is needed for the LEDs
> to work properly (some are triggered by the switch0 device)
>
> linux/ramips/base-files/etc/board.d/01_leds|6 +
> linux/ramips/base-files/etc/board.d/02_network |1
> linux/ramips/dts/ArcherC20i.dts| 46 +--
> linux/ramips/mt7620/config-4.4 |1
> 4 files changed, 49 insertions(+), 5 deletions(-)
>
> diff -rupN a/target/linux/ramips/base-files/etc/board.d/01_leds
> b/target/linux/ramips/base-files/etc/board.d/01_leds
> --- a/target/linux/ramips/base-files/etc/board.d/01_leds
> +++ b/target/linux/ramips/base-files/etc/board.d/01_leds
> @@ -78,6 +78,12 @@ broadway)
> set_usb_led "$board:red:diskmounted"
> set_wifi_led "$board:red:wps_active"
> ;;
> +c20i)
> + ucidef_set_led_switch "lan" "lan" "tp-link:blue:lan" "switch0" "0x1e"
> + ucidef_set_led_switch "wan" "wan" "tp-link:blue:wan" "switch0" "0x01"
> + set_usb_led "tp-link:blue:usb" "2-1"
> + ucidef_set_led_wlan "wlan" "wlan" "tp-link:blue:wlan" "phy0radio"
> + ;;
> c50)
> ucidef_set_led_default "power" "power" "tp-link:blue:power" "0"
> ucidef_set_led_netdev "lan" "lan" "tp-link:blue:lan" "eth0.2"
> diff -rupN a/target/linux/ramips/base-files/etc/board.d/02_network
> b/target/linux/ramips/base-files/etc/board.d/02_network
> --- a/target/linux/ramips/base-files/etc/board.d/02_network
> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
> @@ -114,6 +114,7 @@ ramips_setup_interfaces()
> atp-52b|\
> awm002-evb|\
> awm003-evb|\
> + c20i|\
> c50|\
> dir-645|\
> dir-860l-b1|\
> diff -rupN a/target/linux/ramips/dts/ArcherC20i.dts
> b/target/linux/ramips/dts/ArcherC20i.dts
> --- a/target/linux/ramips/dts/ArcherC20i.dts
> +++ b/target/linux/ramips/dts/ArcherC20i.dts
> @@ -12,20 +12,57 @@
>
> gpio-leds {
> compatible = "gpio-leds";
> + lan {
> + label = "tp-link:blue:lan";
> + gpios = <&gpio0 1 1>;
> + };
> + usb {
> + label = "tp-link:blue:usb";
> + gpios = <&gpio0 11 1>;
> + };
> + wps {
> + label = "tp-link:blue:wps";
> + gpios = <&gpio1 15 1>;
> + };
> + wan {
> + label = "tp-link:blue:wan";
> + gpios = <&gpio2 0 1>;
> + };
> + wlan {
> + label = "tp-link:blue:wlan";
> + gpios = <&gpio3 0 1>;
> + };
> };
>
> - gpio-keys-polled {
> - compatible = "gpio-keys-polled";
> + gpio-keys {
> + compatible = "gpio-keys";
> #address-cells = <1>;
> #size-cells = <0>;
> - poll-interval = <20>;
> + rfkill {
> + label = "rfkill";
> + gpios = <&gpio0 2 1>;
> + linux,code = <0xf7>;
> + };
> + reset_wps {
> + label = "reset_wps";
> + gpios = <&gpio0 13 1>;
> + linux,code = <0x198>;
> + };
> };
> };
>
> +&gpio1 {
> + status = "okay";
> +};
> +
> &gpio2 {
> status = "okay";
> };
>
> +&gpio3 {
> + status = "okay";
> +};
> +
> &spi0 {
> status = "okay";
>
> @@ -73,7 +110,7 @@
> &pinctrl {
> state_default: pinctrl0 {
> gpio {
> - ralink,group = "i2c", "uartf", "rgmii1", "rgmii2",
> "wled", "nd_sd";
> + ralink,group = "i2c", "uartf", "rgmii1", "rgmii2",
> "wled", "nd_sd", "ephy", "spi refclk";
> ralink,function = "gpio";
> };
> };
> @@ -81,7 +118,6 @@
>
> ðernet {
> pinctrl-names = "default";
> - pinctrl-0 = <&ephy_pins>;
> mtd-mac-address = <&rom 0xf100>;
> mediatek,portmap = "w";
> };
> diff -rupN a/target/linux/ramips/mt7620/config-4.4
> b/target/linux/ramips/mt7620/config-4.4
> --- a/target/linux/ramips/mt7620/confi
Re: [LEDE-DEV] [PATCH] ramips: Improve Archer C20i support
Hello Paul, 2016-07-28 14:39 GMT+02:00 : > Hi Piotr, > > here we go. I've just sent in a PATCH v2 with the board name as the > LED's name. Thanks! > Additionally I've create a patch for the C50 - is there any reason > the LEDs of the C50 aren't renamed (yet)? It seems that we didn't spot this and it just went to repository. Anyway, thanks for fixing that too! --- Cheers, Piotr ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Fwd: porting arduino/linino boards into LEDE trunk
Hello Arturo, Just my two cents, little bit off the topic. Is there any specific reason to keep Arduino/Linino boards in "legacy category" (ex. to have rootfs before kernel in image)? Plus, why do all your boards have specified 64 KB nvram mtd partition? AFAIK, nvram is not used on QC/A based devices. --- Cheers, Piotr 2016-08-03 10:59 GMT+02:00 Arturo Rinaldi : > Hello folks, > > I'm in the process of integrating all the set of Arduino/Linino boards > in the LEDE main trunk. I have noticed some changes in the main ar71xx > main Makefile comparing the code with the one of the OpenWRT trunk. > > As far as I have understood, now there is a separate makefile for the > category of "legacy devices" like ours. For this very reeason I have > written a legacy-linino.mk containing all the build profile which will > be called in the main legacy.mk after of course inserting all the > needed entries for the different profiles. > > In addition to this, I need to override the kernel image cmdline hack > setting by disabling it otherwise our image won't properly build. > Please take a look at the attached patch in which I also reinstated > the Multiprofile function since I usually need to build the images for > multiple boards. > > Unfortunately, when launching the kernel "install" process of the > image (to test if the image actually builds) I get this error : > > export MAKEFLAGS= ;make -w legacy-images > make[5]: Entering directory > `/home/arturo/temp/lede-source/target/linux/ar71xx/image' > cp > /home/arturo/temp/lede-source/build_dir/target-mips_34kc_musl-1.1.15/linux-ar71xx_generic/vmlinux > /home/arturo/temp/lede-source/build_dir/target-mips_34kc_musl-1.1.15/linux-ar71xx_generic/tmp/vmlinux-linino-yun > echo "2" > 2 > ifneq (,) > bash: -c: line 0: syntax error near unexpected token `,' > bash: -c: line 0: `ifneq (,)' > make[5]: *** [legacy-image-LININO] Error 1 > make[5]: Leaving directory > `/home/arturo/temp/lede-source/target/linux/ar71xx/image' > make[4]: *** [legacy-images-make] Error 2 > make[4]: Leaving directory > `/home/arturo/temp/lede-source/target/linux/ar71xx/image' > make[3]: *** [install] Error 2 > make[3]: Leaving directory `/home/arturo/temp/lede-source/target/linux/ar71xx' > make[2]: *** [install] Error 2 > make[2]: Leaving directory `/home/arturo/temp/lede-source/target/linux' > make[1]: *** [target/linux/install] Error 2 > make[1]: Leaving directory `/home/arturo/temp/lede-source > > as reported in the first lines, the comparison statement given by : > > ifneq ($(CONFIG_IMAGE_CMDLINE_HACK),) > ... > endef > > is detected as a syntax error by the build system so, any hints on > this ? I think I might close in getting a working lede build on our > series of devices. > > Best, Arturo > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev > ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Call defines for minifying scripting languages
Hello, 2016-10-03 13:14 GMT+02:00 Karl Palsson : > > Jan-Tarek Butt wrote: [snip] >> 1. Reducing memory size on firmware images. > > But will it? They're in the squashfs image, it's already been > demonstrated before that compressing things before can actually > have negative impacts. That's true, my vote for 'optimization-only' approach and keep fs do the rest (compression). >> 2. Strip out all comments (which makes us able to do better >> code commenting) 3. and so on. IMHO, we could remove all comments from all scripts (not only Lua) in target rootfs and work on better documentation outside the code. As an example of a huge, old comment, left in one of ar71xx base-files scripts, please see [1]. It's inside every ar71xx image... does it really make sense to have it there, for devices without related hardware? >> One negative point will be there: >> >> the minified code an not realy human readable but if some one >> want to read this script or work on it on routers, they can >> easily copy the unminified script via scp. > > This is a _massive_ downside IMO, and absolutely not something > that should be enabled by default. There's already far too much > undocumented/underdocumented internal behaviours of scripts and > processes in LEDE/OpenWrt, and minifying scripts and stripping > comments actively works to preserve that situation. [snip] +1 for keeping scripts human readable. +10 for getting scripts documented, someday, somewhere... Wiki? [1] https://goo.gl/yQFpDV Cheers, Piotr ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v2 2/2] ar71xx: add support for the Airtight C-60
Hello Christian,
Small comments below, inline.
2016-10-04 22:55 GMT+02:00 Christian Lamparter :
[snip]
> diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
> b/target/linux/ar71xx/base-files/etc/diag.sh
> index d6e257d..5f2056e 100644
> --- a/target/linux/ar71xx/base-files/etc/diag.sh
> +++ b/target/linux/ar71xx/base-files/etc/diag.sh
> @@ -76,6 +76,9 @@ get_status_led() {
> c-55)
> status_led="$board:green:pwr"
> ;;
> + c-60)
> + status_led="c-60:green:pwr"
> + ;;
Please, use $board variable here and combine c-60 with c55 as both
boards use same LED name.
[snip]
> diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> index 559f97d..e89cc24 100755
> --- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> @@ -484,6 +484,7 @@ platform_check_image() {
>
> return 0
> ;;
> + c-60|\
> nbg6716|\
> r6100|\
> wndr3700v4|\
> @@ -540,6 +541,7 @@ platform_pre_upgrade() {
> z1)
> merakinand_do_upgrade "$1"
> ;;
> + c-60|\
> nbg6716|\
> r6100|\
> wndr3700v4|\
This breaks alphabetical order.
Boards are ordered in two steps: within every case block and then
whole case blocks are ordered, based on first board.
Please reorder case blocks here too.
[snip]
> diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-c60.c
> b/target/linux/ar71xx/files/arch/mips/ath79/mach-c60.c
> new file mode 100644
> index 000..26930a9
> --- /dev/null
> +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-c60.c
[snip]
> +/* can be used to "lock" the console port */
> +#define C60_GPIO_LOCK_CONSOLE_PORT 9
I'm not sure why did you define it here as it's not used.
Plus, GPIO9 is by default configured as UART0 RX signal on AR934x.
[snip]
Thanks for your contribution!
Cheers,
Piotr
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
