John Crispin <j...@phrozen.org> 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