Re: [PATCH v3] ramips: mt76x8: add support for TP-Link RE365 v1
Hi Tomasz, On Wed, 2024-01-10 at 16:39 +0100, Tomasz Maciej Nowak wrote: > From: Tomasz Maciej Nowak > > TP-Link RE365 is a wireless range extender, hardware-wise resembles > RE305 with slight changes regarding buttons and LEDs. > > Specification > SoC: MediaTek MT7628AN > RAM: 64 MiB DDR2 > Flash: 8 MiB SPI NOR > WiFi: 2.4 GHz 2T2R integrated > 5 GHz 2T2R MediaTek MT7612EN conncted to PCIe lanes > Ethernet: 1x 10/100 Mbps integrated > LEDs: 6x GPIO controlled > Buttons: 4x GPIO controlled > UART: row of 4 holes marked on PCB as J1, starting count from white > triangle > 1. VCC (3.3V), 2. GND, 3. RX, 4. TX > baud: 57600, parity: none, flow control: none > > Installation > 1. Open web management interface. > 2. Go to Settings > System Tools > Firmware upgrade. > 3. Select "Browse" and select the OpenWrt image with factory.bin suffix. > 4. After selecting "Upgrade" firmware writing process will start. > 5. Wait till device reboots, power LED should stay solid when it's fully > booted, then it's ready for configuration through LAN port. > > Additional information > With how device manufacturer patrtitioned the flash memory, it's possible > that with default packages set, initial factory.bin image won't be > created. In such case, try to reduce packages amount or use older release > for initial conversion to OpenWrt. Later You can use sysupgrade.bin > image with full set of packages because OpenWrt uses unpartitioned flash > memory space unused by vendor firmware. > > Reverting to vendor firmware involves converting firmware using > tplink-safeloader with -z option (can be found in ImageBuilder or SDK) > and forcibly applying converted firmware as sysupgrade. > > Known issues > WARNING: after removing casing of the device one is exposed to high > voltage and is in a risk of being electrocuted. > > Caution when interfacing whith bootloader, saving its environment either > by issuing "saveenv" or selecting option "1: Load system code to SDRAM > via TFTP." in boot menu, any of those will lead to overwriting part of > kernel. This will lead to need of firmware recovery. The cause of this > issue is bootloader having environment offset on flash at 0x4, > while kernel starts from 0x2. > > Signed-off-by: Tomasz Maciej Nowak > --- > v2 -> v3 > - list virtual flash devices as separate objects > - add kernel size restriction Thanks for the update! [...] > + groups = "refclk", "wdt", "p0led_an", "p1led_an", "p2led_an", > "p3led_an", "p4led_an"; I'll wrap this line (it's one measly character over the 100 limit) and apply the patch to main. Best, Sander ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ramips: mt76x8: enable small_flash feature
Hi Tomasz, On Wed, 2024-01-10 at 16:59 +0100, Tomasz Maciej Nowak wrote: > From: Tomasz Maciej Nowak > > Some of devices in this target have only 8 MiB space and are closing to > borders of usable space. Particularly, TP-Link RE305 v1 already suffers > from this issue[1], where with current partition layout, on release > images, there's not enough space for overlay. So activate small_flash > feature, which will remove some userspace hardening but will gain almost > 1 MiB additional flash memory space. Here is small size comparison of > similar device (RE365 v1) with default config + LuCI: > > kernel rootfs sysupgrade > current: 2305728 3635044 5964584 > small_flash: 1713571 3320132 5047080 > > 1. https://github.com/openwrt/openwrt/issues/14215 > > Suggested-by: Sander Vanheule > Signed-off-by: Tomasz Maciej Nowak > --- > target/linux/ramips/mt76x8/target.mk | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/target/linux/ramips/mt76x8/target.mk > b/target/linux/ramips/mt76x8/target.mk > index 862736cb2f38..cfc2655cac18 100644 > --- a/target/linux/ramips/mt76x8/target.mk > +++ b/target/linux/ramips/mt76x8/target.mk > @@ -4,7 +4,7 @@ > > SUBTARGET:=mt76x8 > BOARDNAME:=MT76x8 based boards > -FEATURES+=usb ramdisk > +FEATURES+=usb ramdisk small_flash Thanks for the patch. More than half the devices in this subtarget have a flash size < 16 MB (the current recommended minimum), so I agree with the approach here. If somebody has strong opinions on this, and would for example rather see something like ath79/tiny, feel free to speak up (and to send a patch ;-) Otherwise I'll probably merge this patch early next week. Or sooner if some stakeholders send their Acked-by. Best, Sander ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] mvebu: fill additional info for mvneta tx queue workaround patch
From: Tomasz Maciej Nowak Because some still unresolved bugs in this driver, which sprout occasional questions what this patch works around, point to the issue which started this. Being here, fill headers required by git am. Signed-off-by: Tomasz Maciej Nowak --- .../mvebu/patches-5.15/700-mvneta-tx-queue-workaround.patch | 5 + .../mvebu/patches-6.1/700-mvneta-tx-queue-workaround.patch | 5 + 2 files changed, 10 insertions(+) diff --git a/target/linux/mvebu/patches-5.15/700-mvneta-tx-queue-workaround.patch b/target/linux/mvebu/patches-5.15/700-mvneta-tx-queue-workaround.patch index 32e8ef4b7d87..039dbc06dd04 100644 --- a/target/linux/mvebu/patches-5.15/700-mvneta-tx-queue-workaround.patch +++ b/target/linux/mvebu/patches-5.15/700-mvneta-tx-queue-workaround.patch @@ -1,3 +1,6 @@ +From: Felix Fietkau +Subject: mvneta: tx queue workaround + The hardware queue scheduling is apparently configured with fixed priorities, which creates a nasty fairness issue where traffic from one CPU can starve traffic from all other CPUs. @@ -5,6 +8,8 @@ CPU can starve traffic from all other CPUs. Work around this issue by forcing all tx packets to go through one CPU, until this issue is fixed properly. +Ref: https://github.com/openwrt/openwrt/issues/5411 + Signed-off-by: Felix Fietkau --- --- a/drivers/net/ethernet/marvell/mvneta.c diff --git a/target/linux/mvebu/patches-6.1/700-mvneta-tx-queue-workaround.patch b/target/linux/mvebu/patches-6.1/700-mvneta-tx-queue-workaround.patch index 15762be81d40..f80d4e301ada 100644 --- a/target/linux/mvebu/patches-6.1/700-mvneta-tx-queue-workaround.patch +++ b/target/linux/mvebu/patches-6.1/700-mvneta-tx-queue-workaround.patch @@ -1,3 +1,6 @@ +From: Felix Fietkau +Subject: mvneta: tx queue workaround + The hardware queue scheduling is apparently configured with fixed priorities, which creates a nasty fairness issue where traffic from one CPU can starve traffic from all other CPUs. @@ -5,6 +8,8 @@ CPU can starve traffic from all other CPUs. Work around this issue by forcing all tx packets to go through one CPU, until this issue is fixed properly. +Ref: https://github.com/openwrt/openwrt/issues/5411 + Signed-off-by: Felix Fietkau --- --- a/drivers/net/ethernet/marvell/mvneta.c -- 2.43.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Real name vs. known identity in contributions
Hi one-d-wide, > Unfortunately I was refused to contribute under my usual nickname due to > real-name-only rule I adopted the `submitting-patches` page and create PRs for both openwrt.git and packages.git. Thanks for reminding me of this. https://github.com/openwrt/packages/pull/23084 https://github.com/openwrt/openwrt/pull/14380 Please have a nice day. Paul ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] uhttpd: uhttpd-mod-ubus: reload uhttpd only if it's runtime install
On 26.11.2023 21:47, Rafał Miłecki wrote:
From: Rafał Miłecki
Reloading service from uci-defaults script is a hack to workaround
postinst limitation. It should not be executed during boot as other
uci-defaults scripts may want to adjust uhttpd's config too.
Cc: Hauke Mehrtens
Fixes: d25d281fd668 ("uhttpd: Reload config after uhttpd-mod-ubus was added")
Signed-off-by: Rafał Miłecki
PATCH obsoleted by
[PATCH] uhttpd: handle reload after uhttpd-mod-ubus installation using postinst
https://patchwork.ozlabs.org/project/openwrt/patch/20231227152045.18336-1-zaj...@gmail.com/
---
package/network/services/uhttpd/Makefile | 2 +-
package/network/services/uhttpd/files/ubus.default | 13 -
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/package/network/services/uhttpd/Makefile
b/package/network/services/uhttpd/Makefile
index 02a02405fd..9405070626 100644
--- a/package/network/services/uhttpd/Makefile
+++ b/package/network/services/uhttpd/Makefile
@@ -8,7 +8,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=uhttpd
-PKG_RELEASE:=1
+PKG_RELEASE:=2
PKG_SOURCE_PROTO:=git
PKG_SOURCE_URL=$(PROJECT_GIT)/project/uhttpd.git
diff --git a/package/network/services/uhttpd/files/ubus.default
b/package/network/services/uhttpd/files/ubus.default
index 474016c1c5..e2240a1018 100644
--- a/package/network/services/uhttpd/files/ubus.default
+++ b/package/network/services/uhttpd/files/ubus.default
@@ -12,6 +12,17 @@ fi
commit=1
}
-[ "$commit" = 1 ] && uci commit uhttpd && /etc/init.d/uhttpd reload
+# Normally (when executing this script during boot) we want to adjust config
+# only. Actual uhttpd start will happen later.
+#
+# If this is package installation in a running system however then we need to
+# reload uhttpd to make ubus access work right after. Ideally this should be
+# handled by a "postinst" script but those get executed *before* uci-defaults
+# scripts. For that reason we abuse uci-defaults to call init.d script.
+#
+# Check for $PKG_ROOT to detect "opkg install" case in a running system.
+if [ -n "$PKG_ROOT" ]; then
+ [ "$commit" = 1 ] && uci commit uhttpd && /etc/init.d/uhttpd reload
+fi
exit 0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v3] ramips: mt76x8: add support for TP-Link RE365 v1
From: Tomasz Maciej Nowak
TP-Link RE365 is a wireless range extender, hardware-wise resembles
RE305 with slight changes regarding buttons and LEDs.
Specification
SoC: MediaTek MT7628AN
RAM: 64 MiB DDR2
Flash: 8 MiB SPI NOR
WiFi: 2.4 GHz 2T2R integrated
5 GHz 2T2R MediaTek MT7612EN conncted to PCIe lanes
Ethernet: 1x 10/100 Mbps integrated
LEDs: 6x GPIO controlled
Buttons: 4x GPIO controlled
UART: row of 4 holes marked on PCB as J1, starting count from white
triangle
1. VCC (3.3V), 2. GND, 3. RX, 4. TX
baud: 57600, parity: none, flow control: none
Installation
1. Open web management interface.
2. Go to Settings > System Tools > Firmware upgrade.
3. Select "Browse" and select the OpenWrt image with factory.bin suffix.
4. After selecting "Upgrade" firmware writing process will start.
5. Wait till device reboots, power LED should stay solid when it's fully
booted, then it's ready for configuration through LAN port.
Additional information
With how device manufacturer patrtitioned the flash memory, it's possible
that with default packages set, initial factory.bin image won't be
created. In such case, try to reduce packages amount or use older release
for initial conversion to OpenWrt. Later You can use sysupgrade.bin
image with full set of packages because OpenWrt uses unpartitioned flash
memory space unused by vendor firmware.
Reverting to vendor firmware involves converting firmware using
tplink-safeloader with -z option (can be found in ImageBuilder or SDK)
and forcibly applying converted firmware as sysupgrade.
Known issues
WARNING: after removing casing of the device one is exposed to high
voltage and is in a risk of being electrocuted.
Caution when interfacing whith bootloader, saving its environment either
by issuing "saveenv" or selecting option "1: Load system code to SDRAM
via TFTP." in boot menu, any of those will lead to overwriting part of
kernel. This will lead to need of firmware recovery. The cause of this
issue is bootloader having environment offset on flash at 0x4,
while kernel starts from 0x2.
Signed-off-by: Tomasz Maciej Nowak
---
v2 -> v3
- list virtual flash devices as separate objects
- add kernel size restriction
.../ramips/dts/mt7628an_tplink_re365-v1.dts | 213 ++
target/linux/ramips/image/mt76x8.mk | 12 +
.../mt76x8/base-files/etc/board.d/01_leds | 3 +
.../mt76x8/base-files/etc/board.d/02_network | 1 +
4 files changed, 229 insertions(+)
create mode 100644 target/linux/ramips/dts/mt7628an_tplink_re365-v1.dts
diff --git a/target/linux/ramips/dts/mt7628an_tplink_re365-v1.dts
b/target/linux/ramips/dts/mt7628an_tplink_re365-v1.dts
new file mode 100644
index ..5743ae1bbc5c
--- /dev/null
+++ b/target/linux/ramips/dts/mt7628an_tplink_re365-v1.dts
@@ -0,0 +1,213 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "mt7628an.dtsi"
+
+#include
+#include
+#include
+
+/ {
+ model = "TP-Link RE365 v1";
+ compatible = "tplink,re365-v1", "mediatek,mt7628an-soc";
+
+ aliases {
+ led-boot = _power;
+ led-failsafe = _power;
+ led-running = _power;
+ led-upgrade = _power;
+ label-mac-device =
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ button-led {
+ label = "led";
+ gpios = < 44 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ button-power {
+ label = "power";
+ gpios = < 11 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ button-reset {
+ label = "reset";
+ gpios = < 37 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ button-wps {
+ label = "wps";
+ gpios = < 38 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led-lan {
+ color = ;
+ function = LED_FUNCTION_LAN;
+ gpios = < 4 GPIO_ACTIVE_LOW>;
+ };
+
+ led_power: led-power {
+ color = ;
+ function = LED_FUNCTION_POWER;
+ gpios = < 39 GPIO_ACTIVE_LOW>;
+ panic-indicator;
+ };
+
+ led-rssi-bad {
+ color = ;
+ function = LED_FUNCTION_INDICATOR;
+ gpios = < 43 GPIO_ACTIVE_HIGH>;
+ };
+
+ led-rssi-good {
+ color = ;
+ function = LED_FUNCTION_INDICATOR;
+ gpios = < 42 GPIO_ACTIVE_HIGH>;
+ };
+
+
[PATCH] ramips: mt76x8: enable small_flash feature
From: Tomasz Maciej Nowak Some of devices in this target have only 8 MiB space and are closing to borders of usable space. Particularly, TP-Link RE305 v1 already suffers from this issue[1], where with current partition layout, on release images, there's not enough space for overlay. So activate small_flash feature, which will remove some userspace hardening but will gain almost 1 MiB additional flash memory space. Here is small size comparison of similar device (RE365 v1) with default config + LuCI: kernel rootfs sysupgrade current:2305728 3635044 5964584 small_flash:1713571 3320132 5047080 1. https://github.com/openwrt/openwrt/issues/14215 Suggested-by: Sander Vanheule Signed-off-by: Tomasz Maciej Nowak --- target/linux/ramips/mt76x8/target.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/ramips/mt76x8/target.mk b/target/linux/ramips/mt76x8/target.mk index 862736cb2f38..cfc2655cac18 100644 --- a/target/linux/ramips/mt76x8/target.mk +++ b/target/linux/ramips/mt76x8/target.mk @@ -4,7 +4,7 @@ SUBTARGET:=mt76x8 BOARDNAME:=MT76x8 based boards -FEATURES+=usb ramdisk +FEATURES+=usb ramdisk small_flash CPU_TYPE:=24kc DEFAULT_PACKAGES += kmod-mt7603 wpad-basic-mbedtls swconfig -- 2.43.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
On Tue, Jan 9, 2024 at 4:52 AM John Crispin wrote: > ---SNIP--- > > * Why is there no USB 3.x host port on the device? > - the USB 3.x and PCIe buses are shared in the selected SoC silicon, > hence only a single High-Speed USB port is available Perhaps you've already considered this, but it may be possible to route the shared PCIe/USB 3 traces to both an M.2 slot and a USB 3 host port using a high-speed dual-channel differential 1:2/2:1 switch/mux. It wouldn't enable both interfaces to be used at the same time, but it would make it possible to select which interface is enabled using a GPIO pin. Then U-boot could either automatically enable one port or the other depending on what devices it detects (e.g., enable PCIe and disable USB 3 if a PCIe device is connected, otherwise enable USB 3 and disable PCIe), or it could be statically configurable via a U-boot environment variable. From some quick searching, the switches/muxes that would enable this cost less than $1 each in qty. 1000. For a <$100 product I understand that may be too much of an increase to the BoM cost and PCB complexity, but I think users would really appreciate being able to choose between being able to add an M.2 SSD, WiFi card, or SATA controller and being able to plug in a USB 3.x 2.5 GbE adapter, SSD/flash drive, WiFi dongle, or 5G modem. All the best, Forest ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Real name vs. known identity in contributions
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi, I'm new to openwrt and recently I have submitted github pull request to openwrt/packages repository. Unfortunately I was refused to contribute under my usual nickname due to real-name-only rule. And it seems I'm not the only one who faced this problem ([1], [2], [3], [4]), so I decided to ask for clarifications here. [1]: https://github.com/openwrt/packages/pull/17993#issuecomment-1059783673 [2]: https://github.com/openwrt/packages/pull/20312#issuecomment-1601308511 [3]: https://github.com/openwrt/packages/pull/22060#issuecomment-1751717855 [4]: https://github.com/openwrt/packages/pull/20540#issuecomment-1443679327 The aforementioned rule is listed on [submitting-patches] page in openwrt wiki: [submitting-patches]: https://openwrt.org/submitting-patches > ## Submissions should follow the following guidelines: > > ... > > * **all commits must contain `Signed-off-by: My Name ` > where you write your real name and real email address**, in accordance with > [Section 11 of the Linux Kernel patches guide] > > ... [Section 11 of the Linux Kernel patches guide]: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=HEAD#n416 I believe that the explicit requirement of real name isn't up to date with the upstream and doesn't reflect the original intent of the [Section 11 of the Linux Kernel patches guide] which was clarified by Linus in February 2023. See the [linux kernel commit] description and changes. [linux kernel commit]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/Documentation/process/submitting-patches.rst?id=d4563201f33a022fc0353033d9dfeb1606a88330 tldr; Linux now accepts known identities for contributions and does not require real names anymore. (Taken from [Jan-Niklas's mail].) This issue had been already mentioned in [Jan-Niklas's mail] and [Petr's mail] via openwrt-adm mailing list, but no action to update openwrt wiki had been taken since. [Jan-Niklas's mail]: https://lists.openwrt.org/pipermail/openwrt-adm/2023-February/002358.html [Petr's mail]: https://lists.openwrt.org/pipermail/openwrt-adm/2023-February/002364.html I'd like to ask openwrt core developers to revisit the aforementioned rule as it has been proven to cause misunderstanding in the community. With best regards, one-d-wide --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
Hi Daniel, Bjørn, On 10.01.2024 12:14, Daniel Golle wrote: Hi! On Wed, Jan 10, 2024 at 11:47:08AM +0100, Bjørn Mork wrote: John Crispin writes: > At the beginning we focused on the most powerful (and > expensive) configurations possible but finally ended up with something > rather simple and above all,feasible. That's a very wise choice. And most of the compromises make sense to me. Except the > * Storage: M.2 2042 for NVMe SSD (PCIe gen 2 x1) This seems like a strange priority for an OpenWrt device. It's not useful to most OpenWrt users or applications. Having two different boot devices is more than enough. > * What will the M.2 slot be used for? > - we will use M.2 with M-key for NVMe storage. There is a > work-in-progress patch to make PCIe work inside the U-Boot > bootloader. This will allow booting other Linux distributions such > as Debian and Alpine directly from NVMe And you even make a point of it being more suitable for other Linux distros. That should not be an OpenWrt priority. > * Why is there no USB 3.x host port on the device? > - the USB 3.x and PCIe buses are shared in the selected SoC silicon, > hence only a single High-Speed USB port is available And here's the biggest problem with that choice. USB3 would have allowed storage expansion as well as more OpenWrt applicable use cases like additional ethernet adapters or modems. And with a limited connector and board space cost compared to an m.2 slot. The USB A port is already there. Regarding all of the above: exposing the PCIe lane gives you the biggest possible flexibility. If you want USB 3 you can use an adapter like this: https://www.delock.com/produkt/63174/merkmale.html Exactly, you can easily find adapters for SATA, USB, NIC and even mechanical connector type change (M.2 to desktop PCIe). Including USB 3 will significantly increase the cost of the design not because of connectors, but because of the interference problems we will have to deal with and somehow mitigate (and the smaller the board the harder that will get). I've seen too many devices with such problems and only very few manage to have well-working 2.4 GHz Wi-Fi next to a USB 3 host. Even with a good shielding on the device's side, a low quality USB cable will have impact on the 2.4 GHz interface. There is an official white paper about this: [1]. > * What is the purpose of the console USB-C port? > - Holtek UART to USB bridge with CDC-ACM support on USB-C makes the > device ultra easy to communicate with. No extra hardware or drivers > will be required. Android for example has CDC-ACM support enabled by > default This is nice. But how about making it a real advantage over the traditional 4 pin header? You could have used a UART bridge with some additional GPIO pins, and connected them to useful SoC IOs. Possibly via some mux. I'd love to see reset and bootsel controlled by the USB UART bridge. Good point. That would also make it more accessible and easy automated testing a lot. My only concern here would be compatibility with other OS/platforms. Ideally we would have a more advanced USB bridge with open source firmware and more than one USB function. But I guess that adds a lot of complexity to the project. Reusing/abusing RS232 control signals is an alternative. Finally, I'd prefer a much more compact board than the BPi-R4 size. Along with a well designed minimalistic case with sufficient passive cooling and optional integrated antennas. Thinking something along the Flirc RPi4 cases, using the case itself as a cooler. With half the case radio transparent and a choice between antenna pigtails and integrated antennas. I realize that such a case will be relatively expensive. But without it all you have is yet another midrange dev board. This is your chance to make a device which shouts "OpenWrt!!!" whenever someone sees it. Just like the original WRT did. Not that that design was something to brag about beauty wise :-) I also think we should should have a pre-assembled-with-case-and-antennas option in addition to just offering the plain board. +1. [1] https://www.usb.org/sites/default/files/327216.pdf -- Cheers, Piotr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
Hi Chuanhong, On 9.01.2024 14:51, Chuanhong Guo wrote: Hi! On Tue, Jan 9, 2024 at 6:52 PM John Crispin wrote: [...] FAQ * Why are there are 2 different flash chips? - the idea is to make the device (almost!) unbrickable and very easy to recover What about a built-in JTAG probe instead of SPI-NOR+USB-UART? It'll be actually unbrickable instead. We were considering similar idea but that would involve additional testing and extra work on the manufacturer's side procedures (programming and testing the MCU). I believe avoiding this would speed up things and getting the device made. The dual-flash solution with a mechanical switch seems as simple as possible in terms of required user's actions for unbricking the device and at the same time, doesn't force user to use specific tools and/or OS. Experienced users could still use the regular JTAG connector on-board. - NAND will hold the main loader (U-Boot) and the Linux image and will be the default boot device - NOR will be write-protected by default (with WP jumper available on the board) and will hold a recovery bootloader (and other essential data, like Wi-Fi calibration) - a dedicated boot select switch will allow changing between NOR and NAND [...] * What is the purpose of the console USB-C port? - Holtek UART to USB bridge with CDC-ACM support on USB-C makes the device ultra easy to communicate with. No extra hardware or drivers will be required. Android for example has CDC-ACM support enabled by default There are several MCU-based CMSIS-DAP projects out there. They can provide a CDC-ACM serial with a JTAG interface. It may be a bit slow if a USB1.1 MCU is picked, but it should be enough to start a bootloader to unbrick the device. Here's one with USB2.0 Hi-speed interface: https://github.com/cherry-embedded/CherryDAP The Sipeed M0S module used costs 20CNY on Taobao (or 2.81 USD according to google) I like the idea, could be probably combined with some of the suggestions from Bjørn. But at least for now, let's KISS and keep these ideas for future, maybe. -- Cheers, Piotr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
Hi Janusz, On 9.01.2024 19:14, Janusz Dziedzic wrote: wt., 9 sty 2024 o 18:59 Daniel Golle napisał(a): On Tue, Jan 09, 2024 at 06:49:04PM +0100, Janusz Dziedzic wrote: > wt., 9 sty 2024 o 18:02 Robert Marko napisał(a): > > > > On Tue, 9 Jan 2024 at 17:53, Rafał Miłecki wrote: > > > > > > On 9.01.2024 13:29, John Crispin wrote: > > > > On 09.01.24 12:56, Robert Marko wrote: > > > >> ---SNIP--- > > > >> > > > >>> Why not 6GHz? > > > >> 6GHz requires an external card, and I doubt you can fit that in the > > > >> target price. > > > >> > > > >> Regards, > > > >> Robert > > > > > > > > correct. as mentioned in the email, we wanted to start out small. also upstream mac80211 is still missing a bunch of 11be related features. > > > > > > 6 GHz doesn't imply 802.11be, does it? I'm really not sure. > > > > > > Does MediaTek have any 802.11ax solutions that cover both: 5 GHz and > > > 6 GHz? Maybe it'd be worth checking if that's an option and then use > > > voting to see if people care? > > > > You can use 6GHz as part of 802.11ax as well, but you need an external card or > > you need to sacrifice the built-in 5GHz for 6GHz and that isn't really > > a good idea > > in my opinion. > > > Even will be 150$ it is still good price for router with 2.4/5/6GHz > (MTK base ACER predator W6 is about 200$). > Or at least add extra m2 AE Key slot - then we can put there mt7916 > card, as possible extension (eg. > https://asiarf.com/product/wi-fi-6e-m-2-ae-key-module-mt7916-aw7916-aed/). > What will be price in case of this extra m2 AE Key slot? You can use M.2 key adapters for that https://www.delock.com/produkt/63343/merkmale.html An additional slot is *not* an option as we got only a single PCIe lane. Hopefully there are also going to be single-band (6 GHz only) 4T4R or even 4T5R modules based on MT7916E available at some point... Seems bpi-r4 will use two miniPCIe slots for that: https://wiki.banana-pi.org/Getting_Started_with_BPI-R4#4.29_Wi-Fi7_NIC If we don't have two PCIe then probably no option for 6ghz I believe this is a preliminary approach, same as it was done with MT7621 + MT7915 (oversized modules). As this is not compliant with the standard and thus limiting platforms these modules will work with, I believe the target will be embedded design only or maybe some oversized M.2. Either way, this is a custom design. I'm pretty sure that when MediaTek designs solutions for AP platforms they consider only the "everything on-board" approach, even if the BB/MAC part utilizes PCIe bus. Usually, chipsets dedicated for module (mini PCIe or the M.2 these days) design are not part of the "AP" product line and are focused on "STA" operation. Anyway, some compromises had to be made. -- Cheers, Piotr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
Hi Enrico, On 9.01.2024 13:55, Enrico Mioso wrote: Hello!! First of all, let me thank You all for this great project. I wll do my best to buy some units - even tough I am not contributing by any mean to OpenWrt in terms of code, or very little, I am very passionate about this project and the overall router freedom. As most of you know by now, I am a blind person and OpenWrt has always been a great opportunity for accessibility as well. The OpenWrt design itself helps accessibility, and the fact you can use it entirely with no web interface is really a plus for me. It would be great if the hardware could be easily operable - and the exposed consoly and flashy plastic case. Would have loved to see that happen, but the lead time for mould casting is insane as well as the cost, specifically for small production runs. hence the choice for re-using something that already exists.e port is - indeed - an enormous plus for me. So, here are my probably unpopular opinions: 1 - I would like for the device to come pre-mounted with a case: having different cases with different designs is not great. And finding someone to help me mount one and/or shipping the device might not be as easy. Some great friends here do help me, but I think it would be a better experience to have a ready-to-use device from the beginning. 2 - Switches for booting could be exposed and easily operable without removing the case: having to open the device case could make it easier to damage the device, the case or both. :) This hasn't been decided yet but we were discussing about offering the device in just two versions: bare PCB and fully-assembled. Plan for the boot select mechanical switch is to make it available from outside, without the need to open the case. As for the Wi-Fi, I would omit itentirely - leaving the device as it is for the rest of the specs. I know the motto has been - for years - Wireless Freedom... but, personally, I am under the impression Wi-Fi is a fast moving targets these days, so packing Wi-Fi on the device wouldnt make so much sense here, to have it "deprecated" in months. You get a robust router device that you can plug in your setup. Hey - I told you this wasn't popular. :) We are heading to Wi-Fi 7 but my guess is that even the Wi-Fi 6 hasn't become the dominant standard and most people are (still?) using Wi-Fi 5 (or even 4!) in their daily usage scenarios. It will be always a personal choice but having a modern, open, stable and widely available Wi-Fi 6 platform with a great community driven support is a key here. As for the NVME storage - it would be great if there was an easy way to install / change the NVME card as well, but here I know I am asking too much. It could be enough it there was an option to purchase a device with NVME pre-installed. This would really help for me. IMHO, limited number of available "bundles" would make things easier. But I can imagine resellers offering extra versions for some additional cost (like the unofficial bundles for Raspberry Pi offered by numbers of different online shops). -- Cheers, Piotr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
On 10.01.24 12:17, Robert Marko wrote: Along with a well designed minimalistic case with sufficient passive cooling and optional integrated antennas. Thinking something along the Flirc RPi4 cases, using the case itself as a cooler. With half the case radio transparent and a choice between antenna pigtails and integrated antennas. I realize that such a case will be relatively expensive. But without it all you have is yet another midrange dev board. This is your chance to make a device which shouts "OpenWrt!!!" whenever someone sees it. Just like the original WRT did. Not that that design was something to brag about beauty wise :-) I also think we should should have a pre-assembled-with-case-and-antennas option in addition to just offering the plain board. I think this is crucial for any OpenWrt board, as that is where the biggest audience is. Regards, Robert yes, there should be 2 SKUs. * raw PCB * fully assembled inside case SFC emphasized that they think having a fully assembled option is crucial in their opinion. regarding having a fancy and flashy plastic case. Would have loved to see that happen, but the lead time for mould casting is insane as well as the cost, specifically for small production runs. hence the choice for re-using something that already exists. John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
> > > > Along with a well designed minimalistic case with sufficient passive > > cooling and optional integrated antennas. Thinking something along the > > Flirc RPi4 cases, using the case itself as a cooler. With half the case > > radio transparent and a choice between antenna pigtails and integrated > > antennas. I realize that such a case will be relatively expensive. But > > without it all you have is yet another midrange dev board. This is your > > chance to make a device which shouts "OpenWrt!!!" whenever someone sees > > it. Just like the original WRT did. Not that that design was something > > to brag about beauty wise :-) > > I also think we should should have a pre-assembled-with-case-and-antennas > option in addition to just offering the plain board. I think this is crucial for any OpenWrt board, as that is where the biggest audience is. Regards, Robert > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
Hi! On Wed, Jan 10, 2024 at 11:47:08AM +0100, Bjørn Mork wrote: > John Crispin writes: > > > At the beginning we focused on the most powerful (and > > expensive) configurations possible but finally ended up with something > > rather simple and above all,feasible. > > That's a very wise choice. And most of the compromises make sense to > me. Except the > > > * Storage: M.2 2042 for NVMe SSD (PCIe gen 2 x1) > > This seems like a strange priority for an OpenWrt device. It's not > useful to most OpenWrt users or applications. Having two different boot > devices is more than enough. > > > * What will the M.2 slot be used for? > > - we will use M.2 with M-key for NVMe storage. There is a > > work-in-progress patch to make PCIe work inside the U-Boot > > bootloader. This will allow booting other Linux distributions such > > as Debian and Alpine directly from NVMe > > And you even make a point of it being more suitable for other Linux > distros. That should not be an OpenWrt priority. > > > * Why is there no USB 3.x host port on the device? > > - the USB 3.x and PCIe buses are shared in the selected SoC silicon, > > hence only a single High-Speed USB port is available > > And here's the biggest problem with that choice. USB3 would have > allowed storage expansion as well as more OpenWrt applicable use cases > like additional ethernet adapters or modems. And with a limited > connector and board space cost compared to an m.2 slot. The USB A > port is already there. Regarding all of the above: exposing the PCIe lane gives you the biggest possible flexibility. If you want USB 3 you can use an adapter like this: https://www.delock.com/produkt/63174/merkmale.html Including USB 3 will significantly increase the cost of the design not because of connectors, but because of the interference problems we will have to deal with and somehow mitigate (and the smaller the board the harder that will get). I've seen too many devices with such problems and only very few manage to have well-working 2.4 GHz Wi-Fi next to a USB 3 host. > > > * What is the purpose of the console USB-C port? > > - Holtek UART to USB bridge with CDC-ACM support on USB-C makes the > > device ultra easy to communicate with. No extra hardware or drivers > > will be required. Android for example has CDC-ACM support enabled by > > default > > This is nice. But how about making it a real advantage over the > traditional 4 pin header? You could have used a UART bridge with some > additional GPIO pins, and connected them to useful SoC IOs. Possibly > via some mux. I'd love to see reset and bootsel controlled by the USB > UART bridge. Good point. That would also make it more accessible and easy automated testing a lot. > > Ideally we would have a more advanced USB bridge with open source > firmware and more than one USB function. But I guess that adds a lot of > complexity to the project. Reusing/abusing RS232 control signals is an > alternative. > > Finally, I'd prefer a much more compact board than the BPi-R4 size. > > Along with a well designed minimalistic case with sufficient passive > cooling and optional integrated antennas. Thinking something along the > Flirc RPi4 cases, using the case itself as a cooler. With half the case > radio transparent and a choice between antenna pigtails and integrated > antennas. I realize that such a case will be relatively expensive. But > without it all you have is yet another midrange dev board. This is your > chance to make a device which shouts "OpenWrt!!!" whenever someone sees > it. Just like the original WRT did. Not that that design was something > to brag about beauty wise :-) I also think we should should have a pre-assembled-with-case-and-antennas option in addition to just offering the plain board. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt One - celebrating 20 years of OpenWrt
John Crispin writes: > At the beginning we focused on the most powerful (and > expensive) configurations possible but finally ended up with something > rather simple and above all,feasible. That's a very wise choice. And most of the compromises make sense to me. Except the > * Storage: M.2 2042 for NVMe SSD (PCIe gen 2 x1) This seems like a strange priority for an OpenWrt device. It's not useful to most OpenWrt users or applications. Having two different boot devices is more than enough. > * What will the M.2 slot be used for? > - we will use M.2 with M-key for NVMe storage. There is a > work-in-progress patch to make PCIe work inside the U-Boot > bootloader. This will allow booting other Linux distributions such > as Debian and Alpine directly from NVMe And you even make a point of it being more suitable for other Linux distros. That should not be an OpenWrt priority. > * Why is there no USB 3.x host port on the device? > - the USB 3.x and PCIe buses are shared in the selected SoC silicon, > hence only a single High-Speed USB port is available And here's the biggest problem with that choice. USB3 would have allowed storage expansion as well as more OpenWrt applicable use cases like additional ethernet adapters or modems. And with a limited connector and board space cost compared to an m.2 slot. The USB A port is already there. > * What is the purpose of the console USB-C port? > - Holtek UART to USB bridge with CDC-ACM support on USB-C makes the > device ultra easy to communicate with. No extra hardware or drivers > will be required. Android for example has CDC-ACM support enabled by > default This is nice. But how about making it a real advantage over the traditional 4 pin header? You could have used a UART bridge with some additional GPIO pins, and connected them to useful SoC IOs. Possibly via some mux. I'd love to see reset and bootsel controlled by the USB UART bridge. Ideally we would have a more advanced USB bridge with open source firmware and more than one USB function. But I guess that adds a lot of complexity to the project. Reusing/abusing RS232 control signals is an alternative. Finally, I'd prefer a much more compact board than the BPi-R4 size. Along with a well designed minimalistic case with sufficient passive cooling and optional integrated antennas. Thinking something along the Flirc RPi4 cases, using the case itself as a cooler. With half the case radio transparent and a choice between antenna pigtails and integrated antennas. I realize that such a case will be relatively expensive. But without it all you have is yet another midrange dev board. This is your chance to make a device which shouts "OpenWrt!!!" whenever someone sees it. Just like the original WRT did. Not that that design was something to brag about beauty wise :-) Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
