OpenWrt One - celebrating 20 years of OpenWrt

[Daniel Golle]

Hi!

On Wed, Jan 10, 2024 at 11:47:08AM +0100, Bjørn Mork wrote:
> John Crispin <john at 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

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.