[PATCH v2 3/3] bcm63xx: add support for Tp-Link Archer VR400 v1
The Archer VR400 v1 is an EOL xDSL router with 802.11bgn/802.11ac wifi.
Hardware:
- SoC: Broadcom BCM63167
- CPU: dual core BMIPS4350 V8.0 @400MHz
- RAM: 128 MB DDR2
- Flash: 16 MB SPI NOR
- Ethernet LAN: 3x 100Mbit
- Ethernet WAN: 1x GbE
- Wifi 2.4 GHz: SoC integrated BCM435F 802.11b/g/n
- WiFi 5 GHz: onboard BCM4352 802.11ac
- USB: 1x 2.0
- Buttons: 3x, 1 reset
- LEDs: 10x, all green
Installation via UART serial console and TFTP:
- Configure a static IP on the computer e.g: 192.168.1.7
- Put the openwrt-factory.bin in a TFTP server in the computer
- Power on the router with the serial console connected
- While initializing the bootloader press any key to reach the CLI
- At the CFE command line, execute the command:
f 192.168.1.7:openwrt-factory.bin image
- Wait until it finish.
Back to OEM firmware:
- Stop the bootloader with the serial console
- Flash the OEM firmware using the CFE web UI: http://192.168.1.1
Unsupported:
- xDSL
- Wifi 2.4 GHz
- WiFi 5 GHz, BCM4352, might eventually get basic support.
Signed-off-by: Daniel González Cabanelas
Signed-off-by: Artemii Karavashkin
---
Changes in v2:
- added USB packages.
.../bcm63xx/base-files/etc/board.d/01_leds| 4 +
.../bcm63xx/base-files/etc/board.d/02_network | 4 +
.../dts/bcm63167-tplink-archer-vr400-v1.dts | 177 ++
target/linux/bcm63xx/image/bcm63xx.mk | 14 ++
.../patches-5.10/519-board_bcm63268.patch | 52 -
...31-board_bcm6348-bt-voyager-2500v-bb.patch | 2 +-
.../patches-5.15/519-board_bcm63268.patch | 52 -
...31-board_bcm6348-bt-voyager-2500v-bb.patch | 2 +-
8 files changed, 299 insertions(+), 8 deletions(-)
create mode 100644 target/linux/bcm63xx/dts/bcm63167-tplink-archer-vr400-v1.dts
diff --git a/target/linux/bcm63xx/base-files/etc/board.d/01_leds
b/target/linux/bcm63xx/base-files/etc/board.d/01_leds
index 75e8afef9d..92fb1bc408 100644
--- a/target/linux/bcm63xx/base-files/etc/board.d/01_leds
+++ b/target/linux/bcm63xx/base-files/etc/board.d/01_leds
@@ -94,6 +94,10 @@ sercomm,h500-s-vfes)
telsey,cpva502plus)
ucidef_set_led_netdev "lan" "LAN" "amber:link" "eth0"
;;
+tplink,archer-vr400-v1)
+ ucidef_set_led_netdev "wan" "WAN" "green:wan" "eth0.2"
+ ucidef_set_led_usbdev "usb" "USB" "green:usb" "1-1"
+ ;;
esac
board_config_flush
diff --git a/target/linux/bcm63xx/base-files/etc/board.d/02_network
b/target/linux/bcm63xx/base-files/etc/board.d/02_network
index b48aa57d2e..32547bf448 100644
--- a/target/linux/bcm63xx/base-files/etc/board.d/02_network
+++ b/target/linux/bcm63xx/base-files/etc/board.d/02_network
@@ -159,6 +159,10 @@ sky,sr102)
ucidef_add_switch "switch0" \
"0:lan" "1:lan" "2:lan" "3:wan" "8t@eth0"
;;
+tplink,archer-vr400-v1)
+ ucidef_add_switch "switch0" \
+ "0:lan:3" "1:lan:2" "2:lan:1" "3:wan" "8t@eth0"
+ ;;
*)
ucidef_set_interfaces_lan_wan "eth1" "eth0"
;;
diff --git a/target/linux/bcm63xx/dts/bcm63167-tplink-archer-vr400-v1.dts
b/target/linux/bcm63xx/dts/bcm63167-tplink-archer-vr400-v1.dts
new file mode 100644
index 00..a3dbca7d78
--- /dev/null
+++ b/target/linux/bcm63xx/dts/bcm63167-tplink-archer-vr400-v1.dts
@@ -0,0 +1,177 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Device Tree file for TP-Link Archer VR400 v1
+ *
+ * Copyright (C) 2022 Daniel González Cabanelas
+ * Copyright (C) 2022 Artemii Karavashkin
+ */
+
+#include "bcm63268.dtsi"
+
+#include
+#include
+
+/ {
+ model = "TP-Link Archer VR400 v1";
+ compatible = "tplink,archer-vr400-v1", "brcm,bcm63167", "brcm,bcm63268";
+
+ aliases {
+ led-boot = _power_green;
+ led-failsafe = _power_green;
+ led-running = _power_green;
+ led-upgrade = _power_green;
+ };
+
+ chosen {
+ bootargs = "rootfstype=squashfs,jffs2 noinitrd
console=ttyS0,115200";
+ stdout-path = "serial0:115200n8";
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ reset {
+ label = "reset";
+ gpios = < 32 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ debounce-interval = <60>;
+ };
+
+ wps {
+ label = "wps";
+ gpios = < 33 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ debounce-interval = <60>;
+ };
+
+ rfkill {
+ label = "rfkill";
+ gpios = < 35 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ debounce-interval = <60>;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ wifi2g_green {
+ label = "green:wifi2g";
+ gpios = < 36 GPIO_ACTIVE_LOW>;
+
[PATCH v2 2/3] bcm63xx: build tplink images
Add macros and a python script to build images compatible with tplink
CFE bootloaders.
Signed-off-by: Daniel González Cabanelas
---
Changes in v2:
- factory image fixed. (cfe-tplink-crcfix.py doesn't work if CFE
already prepended)
scripts/cfe-tplink-crcfix.py | 48 +++
target/linux/bcm63xx/image/Makefile | 23 +
target/linux/bcm63xx/image/bcm63xx.mk | 19 +++
3 files changed, 90 insertions(+)
create mode 100755 scripts/cfe-tplink-crcfix.py
diff --git a/scripts/cfe-tplink-crcfix.py b/scripts/cfe-tplink-crcfix.py
new file mode 100755
index 00..2db6d6cce9
--- /dev/null
+++ b/scripts/cfe-tplink-crcfix.py
@@ -0,0 +1,48 @@
+#!/usr/bin/python3
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (C) 2022 OpenWrt.org, based on cameo-tag.py
+#
+# this tool fixes the CRC32 (kernel+rootfs) found in CFE headers from
+# Tp-Link bcm63xx devices. It doesn't recalculate header checksums
+# since CFE doesn't make any header integrity verification to boot OpenWrt.
+
+import argparse
+import os
+import struct
+import zlib
+
+READ_UNTIL_EOF = -1
+CFE_HEADER_SIZE = 512
+
+def read_buffer(offset, count):
+args.cfeimage_file.seek(offset)
+return bytearray(args.cfeimage_file.read(count))
+
+def write_buffer(whence, buf):
+args.cfeimage_file.seek(0, whence)
+args.cfeimage_file.write(buf)
+
+def invertcrc(buf):
+return (zlib.crc32(buf) ^ 0x).to_bytes(4, 'big')
+
+def checksum_header(buf):
+BINCRC32 = args.crc_offset
+ROOTFSADDRESS = buf[124:128]
+ROOTFSLEN = buf[128:132]
+IMLEN = struct.unpack('>i', ROOTFSADDRESS)[0] + struct.unpack('>i',
ROOTFSLEN)[0] + CFE_HEADER_SIZE
+buf[BINCRC32:BINCRC32+4] = invertcrc(buf[CFE_HEADER_SIZE:IMLEN])
+return buf
+
+parser = argparse.ArgumentParser(description='Insert CRC in tplink CFE
firmware tags.')
+parser.add_argument('cfeimage_file', type=argparse.FileType('r+b'))
+# crc_offset should be 148 or 152
+parser.add_argument('crc_offset', type=int)
+args = parser.parse_args()
+
+args.cfeimage_file.seek(0, os.SEEK_END)
+if args.cfeimage_file.tell() <= CFE_HEADER_SIZE:
+raise ValueError(f"CFE image must be larger than {CFE_HEADER_SIZE} bytes")
+
+buf = checksum_header(read_buffer(0, READ_UNTIL_EOF))
+write_buffer(os.SEEK_SET, buf)
diff --git a/target/linux/bcm63xx/image/Makefile
b/target/linux/bcm63xx/image/Makefile
index f35358173c..cbd0f7787d 100644
--- a/target/linux/bcm63xx/image/Makefile
+++ b/target/linux/bcm63xx/image/Makefile
@@ -143,6 +143,15 @@ define Build/cfe-jffs2-cferam
rm -f $@.kernel
endef
+define Build/cfe-kernel-header
+ $(TOPDIR)/scripts/cfe-bin-header.py \
+ --input-file $@ \
+ --output-file $@-tmp \
+ --load-addr $(if
$(DEVICE_LOADADDR),$(DEVICE_LOADADDR),$(LOADER_ENTRY)) \
+ --entry-addr $(if
$(DEVICE_LOADADDR),$(DEVICE_LOADADDR),$(LOADER_ENTRY))
+ mv $@-tmp $@
+endef
+
define Build/cfe-jffs2-kernel
rm -rf $@-kernel
mkdir -p $@-kernel
@@ -274,6 +283,20 @@ define Build/zyxel-bin
mv $@.zyxel $@
endef
+define Build/tplink-prepend-cfe
+ dd if=$(KDIR)/bcm63xx-cfe/$(CFE_BIN_FILE) bs=128k conv=sync
of=cfeprepend.bin
+ dd if=$@ >> cfeprepend.bin
+ mv cfeprepend.bin $@
+endef
+
+define Build/tplink-sysupgrade
+ # append 512 bytes to avoid computing CRC for data beyond jffs2 EOF mark
+ dd if=/dev/null bs=512 count=1 >> $(IMAGE_ROOTFS)
+ $(call Build/tplink-v2-image, -v 0.9.1 -s)
+ # insert ~CRC32 (rootfs+kernel) to allow CFE booting Openwrt
+ $(TOPDIR)/scripts/cfe-tplink-crcfix.py $@ $(TPLINK_CRC_OFFSET)
+endef
+
define Build/redboot-bin
# Prepare kernel and rootfs
dd if=$(IMAGE_KERNEL) of=$(BIN_DIR)/$(REDBOOT_PREFIX)-vmlinux.gz
bs=65536 conv=sync
diff --git a/target/linux/bcm63xx/image/bcm63xx.mk
b/target/linux/bcm63xx/image/bcm63xx.mk
index 97959d7819..bbf4da6505 100644
--- a/target/linux/bcm63xx/image/bcm63xx.mk
+++ b/target/linux/bcm63xx/image/bcm63xx.mk
@@ -5,9 +5,12 @@
DEVICE_VARS += HCS_MAGIC_BYTES HCS_REV_MIN HCS_REV_MAJ
DEVICE_VARS += BLOCK_SIZE FLASH_MB IMAGE_OFFSET
+DEVICE_VARS += CFE_BIN_FILE
DEVICE_VARS += CFE_BOARD_ID CFE_EXTRAS
DEVICE_VARS += NETGEAR_BOARD_ID NETGEAR_REGION
DEVICE_VARS += REDBOOT_PREFIX
+DEVICE_VARS += TPLINK_HWID TPLINK_HWREV TPLINK_FLASHLAYOUT
+DEVICE_VARS += TPLINK_HWREVADD TPLINK_HVERSION TPLINK_CRC_OFFSET
define Device/bcm33xx
KERNEL_INITRAMFS := kernel-bin | append-dtb | lzma | loader-lzma bin |
hcs-initramfs
@@ -59,6 +62,22 @@ define Device/bcm63xx_redboot
REDBOOT_PREFIX := $$(DEVICE_IMG_PREFIX)
endef
+define Device/bcm63xx_tplink
+ FILESYSTEMS := squashfs
+ DEVICE_VENDOR := TP-Link
+ TPLINK_HWID := 0x0
+ TPLINK_HWREV := 0x1
+ TPLINK_HWREVADD := 0x0
+ TPLINK_HVERSION := 3
+ TPLINK_FLASHLAYOUT :=
+ TPLINK_CRC_OFFSET := 152
+ CFE_BIN_FILE :=
+ KERNEL := kernel-bin | append-dtb | relocate-kernel | lzma |
[PATCH v2 1/3] bcm63xx: kernel: enable the tplink image parser
Enable the tplink mtd firmware splitter to allow booting images with tplink headers. Since known devices with these headers are dual core, only enable this driver in the SMP subtarget. Signed-off-by: Daniel González Cabanelas --- Changes in v2: no changes target/linux/bcm63xx/smp/config-default | 1 + 1 file changed, 1 insertion(+) diff --git a/target/linux/bcm63xx/smp/config-default b/target/linux/bcm63xx/smp/config-default index a6eae6e41d..b09989da70 100644 --- a/target/linux/bcm63xx/smp/config-default +++ b/target/linux/bcm63xx/smp/config-default @@ -39,3 +39,4 @@ CONFIG_ZLIB_DEFLATE=y CONFIG_ZLIB_INFLATE=y CONFIG_ZSTD_COMPRESS=y CONFIG_ZSTD_DECOMPRESS=y +CONFIG_MTD_SPLIT_TPLINK_FW=y -- 2.38.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
mt7621 - validate mt7603/mt762e calibration
Our vendor has put calibration data into flash for the onboard WiFi. They've made some changes which I have to their supplied 4.14.131 driver to read from the "factory" flash partition to read calibration data. As per my previous post on u-boot, getting exact details out of them has proved tricky due to language challenges and whatnot. This is kernel 5.10.154. The driver code here in question is substantially different. [ 22.298838] pci :00:00.0: enabling device (0004 -> 0007) [ 22.310143] mt7603e :01:00.0: enabling device ( -> 0002) [ 22.322339] mt7603e :01:00.0: ASIC revision: 76030010 [ 23.511774] mt7603e :01:00.0: Firmware Version: ap_pcie [ 23.522944] mt7603e :01:00.0: Build Time: 20160107100755 [ 23.570908] mt7603e :01:00.0: firmware init done [ 23.770019] mt7621-pci 1e14.pcie: bus=2 slot=1 irq=24 [ 23.780950] pci :00:01.0: enabling device (0004 -> 0007) [ 23.792240] mt76x2e :02:00.0: enabling device ( -> 0002) [ 23.804437] mt76x2e :02:00.0: ASIC revision: 76120044 [ 24.471734] mt76x2e :02:00.0: ROM patch build: 20141115060606a [ 24.488470] mt76x2e :02:00.0: Firmware Version: 0.0.00 [ 24.499444] mt76x2e :02:00.0: Build: 1 [ 24.507607] mt76x2e :02:00.0: Build Time: 201607111443 [ 24.540896] mt76x2e :02:00.0: Firmware running! On modern kernels, the location of the data is determined by the DTB of course, and this all appears to be in order, and having looked in some detail at the code, everything seems to be there for calibration to happen with no additional effort, but I don't see any debug one way or another. My question is, how to verify the calibration data has been correctly set, both on the driver level and in practical testing? I'm not an RF engineer, so by all means educate me here. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Add swig/host build dependency [Was: Re: [PATCH] uboot-mediatek: clean up build dependencies]
On Fri, Nov 18, 2022 at 09:38:55AM -0500, Peter Naulls wrote: > On 11/17/22 14:33, Petr Štetiar wrote: > > Daniel Golle [2022-11-17 17:01:43]: > > > > Hi, > > > > > Add swig/host to build dependencies. > > > > this doesn't looks like a cleanup as commit subject suggests, but rather > > contrary :-) > > Thanks all in any case for looking at this. We have a possible need to modify > our vendor (or vendor's vendor, hard to be sure) U-Boot. On our MT7621 > boards we have vendor versions 2.0.0 aka Ralink version 2.0.0 and 1.1.3 aka > Ralink > version 4.3.0.0. And I have the Mediatek SDK with source for what claims to > be version 5.0.0.0. > > Attempts to clarify with the vendor what's going on or get exact sources > or history have proven challenging due to timezones and language barriers, > and I think they simply may not know. > > Obviously using the OpenWrt version is going to be probably more satisfactory, > although there may well be vendor changes to support MCU etc. > > It's been many many years since I did u-boot work, but is there some magic to > load u-boot image into RAM on mt7621 and run it to try it out before flashing? > I know there are configuration options for DDR and CPU frequency, etc, but > tftping the u-boot binaries variously and using 'go' result in an apparently > stopped system. @lynxis has done this on Aarch64 MediaTek SoC just a few days ago and wrote a nice blog post summarizing the process. Probably most of it is the same on MIPS-based targets: https://lunarius.fe80.eu/blog/openwrt-u-boot-boot-u-boot.html > > This is the only meaningful documentation I have found. > > https://u-boot.readthedocs.io/en/latest/board/mediatek/mt7621.html > > Thanks! > > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Add swig/host build dependency [Was: Re: [PATCH] uboot-mediatek: clean up build dependencies]
On 11/17/22 14:33, Petr Štetiar wrote: Daniel Golle [2022-11-17 17:01:43]: Hi, Add swig/host to build dependencies. this doesn't looks like a cleanup as commit subject suggests, but rather contrary :-) Thanks all in any case for looking at this. We have a possible need to modify our vendor (or vendor's vendor, hard to be sure) U-Boot. On our MT7621 boards we have vendor versions 2.0.0 aka Ralink version 2.0.0 and 1.1.3 aka Ralink version 4.3.0.0. And I have the Mediatek SDK with source for what claims to be version 5.0.0.0. Attempts to clarify with the vendor what's going on or get exact sources or history have proven challenging due to timezones and language barriers, and I think they simply may not know. Obviously using the OpenWrt version is going to be probably more satisfactory, although there may well be vendor changes to support MCU etc. It's been many many years since I did u-boot work, but is there some magic to load u-boot image into RAM on mt7621 and run it to try it out before flashing? I know there are configuration options for DDR and CPU frequency, etc, but tftping the u-boot binaries variously and using 'go' result in an apparently stopped system. This is the only meaningful documentation I have found. https://u-boot.readthedocs.io/en/latest/board/mediatek/mt7621.html Thanks! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] iwinfo: nl80211: fix wpa supplicant ctrl socket permissions
I updated the patches and added a few more. But instead of posting them here again I opened a PR: https://github.com/openwrt/openwrt/pull/11280 Please let me know if I should post them here again instead. Thanks, Andre ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Can I install OpenWRT 22.03.2 on my Asus RT-AC1200G+ wireless router?
On 16.11.2022 11:35, Turritopsis Dohrnii Teo En Ming wrote: On Wed, 16 Nov 2022 at 20:31, Arınç ÜNAL wrote: On 15.11.2022 17:16, Turritopsis Dohrnii Teo En Ming wrote: Subject: Can I install OpenWRT 22.03.2 on my Asus RT-AC1200G+ wireless router? Good day from Singapore, Can I install OpenWRT 22.03.2 on my Asus RT-AC1200G+ wireless router? I have searched the Table of Hardware but my device is not listed. Is it not supported? Looks like it isn't. This device has got bcm47189 / bcm53573 SoC which is supported on mainline Linux. Shouldn't be too hard to support this device. I'm not sure about wireless though. Looking at the pictures from the FCC[1], There's an 802.11n PHY, Broadcom BCM43217. It seems to be supported on mainline[2]. I can't make out the 802.11ac PHY though. If you can open the device and send me a picture, I can check if it's supported. Hi, I don't think I want to open my Asus RT-AC1200G+ wireless router. I don't want to damage it. Sure. The 802.11ac PHY is in the BCM47189 SoC and there's currently no support for that. I can build an image for you to test 2.4 GHz Wi-Fi. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
