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 <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.
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
