OpenWrt One - celebrating 20 years of OpenWrt

Piotr Dymacz pepe2k at gmail.com
Wed Jan 10 03:50:00 PST 2024


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

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



More information about the openwrt-devel mailing list